For our second project we were making a mobile puzzle game in Unity. Having just finished Rad Game I felt a lot more confident in the Unity workflow. As a team we suffered from overscope in this project. At a surface level mobile puzzle games seem like an easy task, which made the team seek out innovative gameplay. Having no good reference material for our game made our end goal blurry and I think that really showed in the outcome. Regardless this resulted in a lot of new challenges for me which is why I still look back fondly at this project. I got to wear a lot of hats, jumping between areas of the game and learning so much on the way. For the first time I got to work closely with the other disciplines making a versatile tool that could be used to alter the environment. It was used to open doors, spawn enemies and create puzzles. Looking back it was simple, but I am proud that working together with the level designers I could break down their design problems to something easy to use.
If I could go back and remake this project I would let myself know that sometimes it is better to say no. There comes a time in projects like these where adding new features will clutter the game or introduce bugs too late in development. I think we should have stuck to our core mechanics and polished them further by adding more feedback using particles and sounds. An even safer option would be to pick an existing game as a reference to have a clear goal and avoid prototype testing heavy design problems.