Reflection #4

For my fourth Design Challenge, I decided to use the game that I’ve been working on as my thesis project, which was a 2D Turn-Based Strategy game. As a result, this was the result of a lot more work than the games submitted in previous design challenges, and there is far more that I can discuss. When I chose this to be my thesis project, I knew it would be difficult, and I was absolutely correct about that. However, creating the game ended up being even harder than I had initially expected, and I ended up falling a bit short of the goals I intended to reach by the end of the semester.

As mentioned in the video, I at least managed to get the general framework of the game set up, along with most of the mechanics working. This was not easy, as many things that seemed simple on paper ended up being far more complex in practice. For instance, movement is deceptively hard; you may think that it’s as easy as translating the characters by a few units within Unity, but all this accomplishes is the physical movement of the sprite. In reality, I needed to keep track of the location of every single unit at all times, and I needed each unit to know the information of whatever tile it was on. For starters, this meant that I needed to divide the board into 484 individual tiles, each of which contains unique information regarding its terrain and its position. Then I needed to create a two dimensional array to store all of those tiles in the correct order so that they could be easily accessed by the characters on the board. When these characters moved, they first needed to check to see if the tile was occupied or impassable, as you can’t move through water or other characters. Then they would need to check to make sure that they had enough movement to reach that tile, as some terrain types require more movement than others. Finally, the character is moved and its stats are updated to reflect the modifiers of its new tile. This is a simplified explanation of the easiest mechanic that I had to implement.

I’ll spare you the details of everything else, as I could write an entire essay on all of the problems that I ran into just while implementing the combat. In previous reflections I would discuss all of the bugs that I ran into, and this was usually possible because there was a fairly limited number of bugs. In this case, dealing with bugs and unintended side effects of new changes was a constant problem that I’ve had to deal with for months. I don’t even have any interesting stories about my dad’s playtesting this time, because most of the things he discovered were issues that I already knew existed, and was planning to fix at a future date. My dad was primarily focused on giving me feedback regarding the overall design of the game, and sometimes he would suggest implementing a mechanic in a different way than I had initially planned. The end result of all of this work and feedback from my dad is that I finally have a solid foundation for what I hope will turn out to be a fun strategy game.

I wish I could end the post there, and I genuinely considered doing that, but the reality is that making the game up until this point was brutal. So brutal, in fact, that it actually killed any real excitement I have to continue, and I’m debating on whether or not to do something else for the second half of my thesis. I love game design, and this 2D Strategy game is something that has been in my head for years, but as it stands I feel that I would need to sacrifice a lot of my initial plans for it if I want to finish my thesis by the end of the next semester. I’m well aware that this is a constant struggle in game design, and that many times teams will be forced to sacrifice part of their original vision in order to release something on time. However, it’s one thing to be told something and another thing entirely to go through it yourself. I’m not entirely sure if I’m ready to half-ass my game just for the sake of having a complete thesis project, and I may very well prefer to start something different from scratch.