We started our design process by thinking of ideas for games we would want to make for mobile. We wanted to make something that didn't involve a player-character, since the natural controls for a player character would likely involve virtual controllers. To us, making something that essentially emulated a keyboard/controller defeated the purpose of designing a game for mobile in the first place. Instead, we wanted to think of ideas that more naturally fit the touch screen input.

The game concept we ended up choosing was a combat card game, similar to Hearthstone or Inscryption, but with visual and mechanical design similar to Super Auto Pets. We wanted our player to have a diverse deck of cards that allowed them to slowly customize their gameplay as they advanced through the encounters, but we thought that making an AI opponent behave similarly would be very complicated and not ultimately optimal for making the game fun, so we instead determined that the enemy units would be fixed depending on what kind of encounter is being fought. Here is our initial sketch of how the game was going to look:

In terms of the system design for our game, we decided to do something drastically different compared to previous projects. We knew this game would have lots of complex and interdependent logic, and that having bits and pieces of logic and state spread across many components would be a nightmare to manage, so we instead went with a two-layer design consisting of what we call the "front-end" and the "back-end". The back-end of the system contains all of the state and logic of the combat system and is separate from Unity, handled in pure C#. It has methods that allow the front-end to communicate what the player wants to do, and it responds by returning a list of events that happened when updating the state of the game after that request. The front-end, on the other hand, is in charge of player input and visuals. It determines what the player wants to do, tells the back-end to do it, and then updates the display and shows animations based on the returned events. We chose this design for three reasons: first, it allows separation of responsibilities, which greatly simplifies the work on both ends of the system; second, it allows us to establish interfaces to use upfront, then work simultaneously and independently to implement the systems to meet the requirements of these interfaces; third, it allows us to implement system logic without having to figure out how the game design maps onto the Unity framework. Here is a diagram that roughly visualizes how the system works:

Our initial rounds of playtesting did not go particularly well. Our first two weeks were mostly spent solidifying the game design writing the back-end, but this work isn't easily appreciable without a working front end. By the end of our third week we had a half-working front-end, but it wasn't finished, and, due to misunderstandings, we did not have PC controls ready before playtesting, which lead to last-minute changes which broke things in the front-end to the point of unplayability. Based on what we did have, however, and our description of the game, we got valuable feedback regarding the visuals of the game, how players would want controls to feel and animations to look, and, crucially, that a tutorial of some kind is desperately needed for our game. We took this into consideration when making a final list of all tasks that needed to be done before the game could be considered complete, and we are currently working on finishing the front-end, adding some supporting game elements like menus and a progression system, and finishing up the visuals, SFX, and music.

Our development docs and notes were exported from Notion and are attached to this post in a zip file, as these documents were requested in the submission instructions.