Stage I Report
Stage I focused on the design document and the initial planning required to clearly define the project. During this stage, we established the project’s core goal: to build a turn-based tactical strategy game that could serve as a platform for adversarial modeling. We also identified the project's overall direction, selected the game style to guide development, and divided the work into major subsystems so implementation could proceed in parallel.
This stage was primarily about design rather than demonstration. The report should emphasize our proposed system architecture, the expected game flow, the responsibilities of each subsystem, and the technical approach we planned to use moving forward. It should also describe how the design document served as the foundation for our later prototype work, particularly in areas such as the game loop, entity handling, map logic, UI support, and communication with the modeling side of the project.
Stage II Report
Stage II corresponds to Demo 1 and represents our first substantial prototype. At this point, we had organized the project structure into four main areas: Game Loop and API, Entities, Map Design, and UI/Save & Load/Data. The demo presented the project as a turn-based strategy game on an 8x8 grid where the player controls up to three mechs, protects structures, and responds to visible enemy actions. It also described our decision to implement the project in Python so the modeling team could work with it directly as a package.
The first demo also outlined our intended technical design for the prototype. It introduced the planned game loop phases, the bidirectional API for exchanging state and actions with the adversarial model, early procedural map generation ideas, and the first versions of UI and save/load support. In addition, we designed the entity subsystem around a base Entity class and an EntityManager responsible for map-dependent spawning, movement, and attack logic. Altogether, Stage II showed that we had moved from planning into a functional early prototype with clearly defined subsystems and integration goals.
Stage III Report
Stage III corresponds to Demo 2 and reflects a much more complete and integrated version of the project. By this stage, we had implemented a state-machine-based game loop with defined phases, along with more formal state and action spaces for both player and enemy behavior. The demo also showed that we had progressed beyond initial planning into a working game structure that included entities, map state, power-grid tracking, enemy intents, and turn progression.
In addition, Stage III highlighted substantial progress in gameplay systems and usability. We presented the current heuristic-based enemy behavior, the expanded entity system, map and tile health rules, power grid loss mechanics, UI improvements for movement and attacks, save/load functionality, and backend fixes that improved the reliability of connecting the different parts of the game. The demo also identified remaining issues and next steps, including increasing difficulty, expanding enemy and mech variety, expanding environmental interactions, and continuing to refine the game as a platform for adversarial model testing.
Stage IV Report
Stage IV corresponds to the final demo and represents the completed version of the project. By this stage, we had built a playable single-player PvE turn-based strategy game that supported multiple playstyles through distinct mech and enemy types, biome-based terrain, positioning-based combat, and an AI adversary that pressured both player mechs and buildings. The final version added substantial polish and structure beyond the earlier prototypes, including new biomes and tile types, improved procedural map generation using clustering, BFS growth, and connectivity validation, a deploy phase before the match starts, clearer enemy intents, more complete UI features, enemy attack animations, and a cleaner frontend/backend separation where the backend owned game logic and command validation.
Stage IV also showed that the game had become more complete and replayable, with maps that were more visually appealing, clearer player interaction through separate movement and attack controls, and a codebase that was easier for us to work with. Remaining limitations included balance issues that still favored the player, some unfinished save/load concerns, and possible future UX improvements such as friendly attack and movement animations.