Intended as an opportunity for senior students to engage in an open-ended group effort and develop their own vision of a video game, my senior capstone course definitely provided an experience to remember and cherish. Upon beginning the course with my classmates, I don’t believe I was alone in feeling a bit overwhelmed by the sheer possibilities of the course project, in which our lone instructions were to develop a complete video game in Unity as groups of six or seven students for demonstration by the end of the class semester. Because groups could choose to make literally any video game they desired, even the prospect of narrowing down a genre and theme felt daunting, never mind actually going through with and developing the idea from scratch.

As students got to know each other and sort through the myriad of ideas, one game genre that kept floating around in my mind was the turn-based strategy (TBS) framework. There are many reasons why I eventually convinced myself this genre would make a great capstone project. For starters, I was personally quite familiar with the genre, as one of my all-time favorite titles has always been Sid Meier’s Civilization V. From that game I was able to get a rough idea of how the systems of our game would have to interact as well as how best to make some of the core systems more engaging. Additionally, because much of a player’s engagement within a TBS game is based on determining strategic actions and not flashy action sequences, it seemed much more realistic to build a polished TBS experience than, for example, a high-speed racing game. Given these convincing advantages, our project team decided the TBS genre was our best option. Our next order of business revolved around team communication expectations. It was quickly decided that typical Agile practices like regular standup meetings, a visual kanban task board, and a dedicated scrum master to hold post-Sprint reviews and retrospectives. With the genre decided and Agile practices established, we transitioned towards determining a suitable theme for the game. Our options were limited given that the team had to choose from course-offered Unity assets lest we pay for them ourselves; as such, we opted for the most widely available provided asset theme: medieval warfare. This provided us with the most flexibility down the line as we got further into development.

With the genre and theme finalized, the team decided it was best to model much of our TBS game off of popular titles like Civilization V and XCOM. The most obvious example of this is For the Crown!‘s grid map system, which dictates where units could be placed, moved, and attacked. During the early stages of development, this core game functionality was almost exclusively my responsibility, and I aimed to create as intuitive a codebase as possible to facilitate more productive development from all team members down the line. This worked very well, as even though over time much of the initial grid code was improved and expanded, the core ideas I laid out in the earliest weeks stuck throughout the project and provided the entire team a springboard for future development. With the core tile and camera system developed along with initial versions of units (knights, archers, etc.), the team solidified its ideas for core gameplay modes and features. Three modes were ultimately selected for further development: training, endless, and multiplayer. Out of these, my personal responsibilities centered on creating the core game logic to handle endless mode. This provided me a truly fun and interesting challenge, and the end result showed the time and dedication put into the gameplay, including rules and pacing. I personally also branched off and greatly expanded the unit capabilities for the game, adding in both unique abilities for each type of unit as well as a unit promotion system very similar to Civilization V‘s. This coincided well with the game’s endless mode, as it provided the player an incentive to want to keep veteran units alive. The special abilities in general greatly elevated the skill cap of the game, which became important for multiplayer.

When it came time to demonstrate our completed game for the class and allow everyone to play it directly, the team successfully completed what it set out to do. Not only did we succeed in implementing all of the core features we discussed, we delivered For the Crown! with an impressive level of polish given the extreme time constraints of the project. Given the (relatively) smooth and bug-free gameplay when compared to the high-intensity and flashy games developed by other teams, our TBS title held up incredibly well and managed to take home two distinctions as voted on by the class: “Most Technical Game” and “Best Overall Game”. This came as a complete surprise to the entire team, but in hindsight, given our extreme dedication and level of commitment to making a quality product in such a limited time, it is definitely believable. The team’s desire to impress and its extremely effective ability to communicate successes, roadblocks, and concerns allowed for such a polished final product.