Pinball Defense
Report
Though I’ve always been a bigger fan of trying out wild new ideas, there still exists a notable appeal of mine towards classic and well-defined gameplay mechanics, or more so an appeal in testing my abilities to take an old idea and still deliver a new experience from it.
When it comes to sub-genres of games where the game mechanics have heavily cemented over the years, no two were more prominent in my childhood than pinball games and tower defenses. Because of this, I had always wanted to try my hand at a pinball game or tower defense game, but only if I could bring some new experience to the table while doing so. It was not long after when it crossed my mind that I could mix the two sub-genres into one, in a sense creating a new experience using purely old and pre-established mechanics.
One of the primary benefits of mixing these two games, and one of the main reasons I sold myself on the project’s concept, is that pinball mechanics directly solve an issue plaguing the majority of tower defense games, being that many tower defense games are separated into a buy phase and a watch phase. The first part has you thinking and strategizing, yet the second has little to know user input, having the player simply wait to see if their actions in the prior phase were good or not. Granted the “watch” phase isn’t completely devoid of enjoyment, it is often entertaining to see your strategy barely pull through in the end, or see a combo you set up prior get set off to massively damage the waves of enemies. However, I’ve always personally felt that a lot more could be done with said segment of the game loop. Thankfully, pinball mechanics do just that. In my game Pinball Defense, the player spends their building phase creating components of a pinball machine, while in the latter phase, the user plays pinball on their custom machine, using the built components to fend off a wave of pinballs.
Moving on to the more intricate aspects of the system’s design, one of the mechanics I’m most fond of is how I managed player health. The player has a health bar at the bottom of the screen that reduces each time they let a ball past their flippers, with enough health to last them 10 misses. Many tower defense games allow players to recover lost health by spending money on recovery instead of upgrading their defenses, giving them temporary relief yet putting them at even a bigger disadvantage due to being behind in construction. I personally disliked the concept of paying to heal instead of creating more towers as it prevents the game board from advancing at a consistent rate, leading to many late game builds being under developed in certain locations, or in more direct terms of Pinball Defense, sections of the pinball machine that are completely empty. To resolve this, I decided that the only way the player could recover health is through the use of certain towers, such as a pin that you can target and slightly recover some health each time it’s hit. This led to boards being more fleshed out while still benefitting from the cost and benefits of wasting money on healing, as the pins that recover health would be built in place of pins that deal more damage or give the player more money to work with.
Finally, Pinball Defense provided a new challenge for me in terms of UI design. Not only was this the first time I worked with dynamic menus, where items that the player could buy were added in over time, but it was also the first time I had ever made a system where the player has the ability to build out their environment. The biggest issue I faced was teaching players how each new tower they obtained worked in a comprehensive manner while also not overwhelming them. The solution I settled on was to create a sub-menu that describes a tower’s function whenever the player puts their cursor over it. As for letting the user build out towers, the main challenge I faced was deriving a method to prevent the user from building sections of the board where pinballs could get stuck in the geometry. My solution was to encapsulate all buildable objects in a visible force field, where any object penetrating the field would result in negative user feedback and prevent them from building there, enforcing clearly understandable user construction limitations without the use of text.
h