For the first hands-on module of university, we were tasked with designing and developing a 2D shoot-em-up independently. I designed the game to be system-heavy, requiring a min-max approach to the builds the player is able to create. To rapidly prototype these dense mechanics, I built the game entirely using Unity’s visual scripting tools, allowing me to focus on the design of the game itself and the variety of enchantments and playstyles that come with them.

​

My personal development goals with this project were to refamiliarise myself with Unity, as well as learn the very basics of node-based visual scripting. Because Tinker relies heavily on bullet-hell mechanics, the game demands high-frequency projectile generation and high enemy density. During development, I relied on constant prefab instantiation and destruction for every bullet and enemy. Given the overhead of visual scripting, this created a significant performance bottleneck and frame drops during play.

​

This project was a massive learning experience in technical optimisation and visual scripting. Analysing the performance deficit taught me the critical importance of memory management in system and object heavy games. If I were to rebuild this project today with my current C# workflows, I would immediately implement an Object Pooling system to recycle projectile and enemy assets, eliminating the instantiation overhead.

​

Despite the performance limits, I still love the framework I created for this game and occasionally boot it up for a quick run or two.