Stage 1
We started by researching games to mod and pitched a comparison to our client: Darkest Dungeon, Tetris, Invisible Inc., Slay the Spire, and Into the Breach. Into the Breach won, but we built it from scratch instead of modding. Starting fresh gave us the architectural flexibility we'd need for the AI integration later.
We chose Godot with C++ through GDExtension. C++ for performance and team familiarity, Godot for its 2D tooling and open source license.
The first month was foundation work. We built the core data structures, a basic procedural map, and the first player and enemy units with sprite rendering. The last piece was a refactor that didn't add visible features, just cleaned up overlapping responsibilities so we'd have a place to plug in the external AI later. It was a hard sell on a demo timeline, but it paid off the rest of the semester.
Stage 2
Stage two was about giving the foundation something to do. Units could move and the map rendered, but there was no combat and no real game. This stage correlated to Demo 2
We started with terrain. Each terrain type got its own rules for what could move through it, what could be destroyed, and how it interacted with attacks. The combat system came next. We decided to create a generalized attack framework so that new attacks could be defined in a few lines rather than making new subclasses for each attack. We created knockback chains, status effects like fire and web, and a turn system that allowed the game to run. We also added win and loss conditions tied to city survival, enemy spawning, an undo system that allowed players to take back moves, and a deployment phase for player mechs.
Along with that, we built a simulation layer that lets the UI preview attack outcomes without changing the game state. What the player sees is exactly what will happen when they commit their attack. We also did a refactor on enemy logic, splitting it into separate components for pathfinding, decision making, and execution.
The other part of stage 2 was the API integration. We added save a load using JSON serialization, then built async HTTP communication so the AI's response wouldn't block the game loop. We also pre-compute legal moves on our side before sending them to the AI, so the AI's job is selection, not validation. That kept the contract small and made illegal move handling rare.
By the end of stage two, we had our Minimum viable product and it was able to communicate with the grad teams AI.
Stage 3
Stage three correlated with demo 3. Our main focus during this stage was polishing the game and fine tuning the grad teams control over the difficulty of the game. We had completed our MVP and wanted to create a polished and playable game, rather than just a tech demo.
We gave the AI control over enemy spawning, so it now decides what threatens the player and where. We also created a difficulty engine that gave us the ability to fine tune the difficulty of each game. We rebuilt map generation with proper validation, since the original generator could produce unfair maps with trapped units or unreachable cities. We added a persistent run structure that chains missions into a continuous experience with progression between them, including a shop for mech upgrades and new weapons.
The last weeks of stage three was focused on handoff and presentation. We finalized documentation for our handoff documents and final report, cleaned up our codebase, and prepared our final presentation and demos. We ended with a complete game with replay value, an AI opponent with real agency, and difficulty options that meet players where they are.