This semester, I am taking a Systems and Experience Design class all about making game systems revolving around different ideas. For the second project, the central theme was strategy and logic. I have a weird relationship with this genre of games; card games like Hearthstone, Yu-Gi-Oh!, or even LEGO Ninjago have all been central games of mine at different points of my life and all fall under the umbrella of strategy and logic, yet I am not familiar with most strategy and logic games outside of the aforementioned card games and a few tower defense games. Since I wanted to push myself while still remaining somewhat in my comfort zone, I developed "By The Elements", a resource-focused tower defense!
If you want to check out the full documentation I did on this project, check it out here!
I intend to create a tower-placement system for a tower defense style game which not only focuses on complete customization of each individual tower but also moves the focus away from solely combat and into more resource generation mechanics.
Playing Kingdom Rush Frontiers helped a lot with ensuring I knew the genre of tower defense before attempting to make a system for it. This game is seen as one of the staples of the genre, and it is obvious to me why. Every single tower has some sort of impact on the gameplay in its own unique way, and player choice was usually at the forefront of the game since there was hardly a moment where I felt pigeonholed into doing one thing. Note how I said “usually”; while I knew the developers of this game did a lot correct, I wasn’t a big fan of how you could only place towers in predefined locations or how you would usually never interact with a tower once you had placed it down. I wanted to be able to give the player a plethora of choices while still making the game feel like a tower defense.
Lars Doucet’s article on optimizing the tower defense genre to avoid bad practices gave me a good start on what I should and should not do. That being said, there was a couple of “do-not-do” things in the article (like having multiple tower types) that I wanted to integrate anyways since they play into the issues I have had with tower defense games in the past. Another article, written by Tracey Fullerton about improving player choices, helped solidify my though process on ensuring every choice in the game was meaningful. Originally, I had plans to add a third menu for Towers that gave them different ammunition types, but in the current state of the prototype, they really did not add any level of interesting choice, so I ended up cutting it. Asides from ammunition, everything else in the game provides some sort of interesting choice since the player needs to be able to think ahead to when they will need to use certain resources and if the infrastructure they are setting up right now allows for their needs in the future.
I also placed a little bit of emphasis on the UI and UX of tower defense games in my research since I am a UI/UX designer at heart. I also thought that because I wanted to do something with resources, making sure the player knew what was happening with their resources was important. Both of the sources I found on UI/UX design within tower defense games – one by Josh Bycer and the other by Desi Quintans – emphasized that players must have access to all information at all times, which for the most part I achieved in the prototype. The only thing that goes against this is that the upgrades menus must be opened up manually, but this was mainly due to a technical oversight when I was setting up the system. Even still, the upgrades are only 1 click away and aren’t core to the game; everything that is needed is shown to the player at all times, like the colors of the tiles, the amount of resources they have, and the health of enemies.
The prototype succeeded in my intent of making a tower-defense game focused on resource generation/management! During testing, people said that they could definitely see the prototype be more fleshed out and become something really interesting. That being said, when compared to my previous Game Systems project, "By The Elements" did not attract as much attention and retain as many players. This could be attributed to both some bugs that affected usability and the slow-pacing of the prototype coupled with a lack of a win/lose condition.
But let's take a look at the QA data! At its core, I wanted to make sure players felt like they had options with their actions and that those options each had their own consequences and rewards, all intertwined together to have the player make interesting decisions. This core aspect of choice was definitely present in the prototype, with a majority of testers sharing the feeling that their actions were not linear and their own choice factored into the gameplay.
Going in deeper, I wanted to see what specific decisions contributed to this feeling and to see if there were any completely useless decisions players made that they felt had little to no impact on the prototype. The epitome of the meaningful choices in the prototype was the type of structure the player was building, which makes sense seeing as the Tower, Generator, and Painter all have such different roles that play off one another.
I had also designed the prototype to make the elements each important in their own right; with each one being required to build a different tower, I had thought that choosing which elements were being painted, generated, or shot was going to be important, but the data shows otherwise. This may be in part due to the lack of a end-goal in the prototype or even the lack of proper feedback and information being given to the player. Either way, this is definitely something that would need to be addressed in any future iteration of "By The Elements".
And finally the location of where towers were being built was pretty important to the testers. Because of how Generators need to be nearby Painters of the same element in order to create resources and how Towers need to be on top of tiles corresponding to their element in order to actually function, the spacial planning required from the player plays a huge part in the choices the player makes.
Overall the prototype was successful, but admittedly not without its fair share of hiccups. While most testers thought that their decisions with the choices the prototype presented actually had an impact (which was the goal of the prototype), bugs and lack of information given to the player made the path to right now a very bumpy ride. On top of that, the system is still not in a perfect spot, since there is some level of hollow decisions seen through the elemental types when building structures. But all in all, I certainly learned a lot with this project, and I know I can take all of this into my future endeavors!