Development & Iteration

Ver 1 - Basic Loop for Game

After the development of the foundational framework was complete, I raised a question regarding the original design: How could we visually convey the intended scenario—where numerous monsters are chasing RED—and how should we handle the associated monster stacking logic?


At the time, our plan was to create a secondary interface to display this information.


However, how could information belonging to such a critical UI layer be relegated to a secondary interface that required players to perform additional clicks and interpretative effort?


Consequently, in the subsequent version, we completely refactored the entire monster system.

Monster System Rebuild

The system was rebuilt around a single-monster pursuit model. Only one monster chases RED at a time, and it follows a two-tier progression:

  • Progress levels (1.1, 1.2…) incrementally increase HP as the run continues

  • Stage levels (1, 2…) raise both ATK and HP, and visually transform the monster's appearance

This change shifted the game's tension from "survive the swarm" to "manage a single escalating threat" which aligned far better with the strategic pacing the tile placement system was designed for. The monster now also collects resources as it passes through tiles and drops them on death, turning every chase into a risk-reward calculation rather than pure threat.

Ver 2 - New Monster System & UI implemented

Ver 3
1. Fixed bugs related to monster level up and progression;
2. Added Environmental Threat Levels
3. Further updated the UI;
4. Updated the logic for resource acquisition by players and monsters on individual tiles;

Ver 4
Following the previous update, the remaining issues within the monster module (based on my observations during gameplay) were as follows:

  1. The Attack Power icon did not update correctly.

  2. There were minor issues with the turning logic.

  3. There were display issues with the Skill Panel (skills should have been displayed simultaneously).

  4. There were issues related to the accumulation of Skill Rage points.

  5. The first slot in the monster's resource inventory would repeatedly generate duplicate resource icons.

  6. The monsters' skills had not yet been implemented.

This latest update has effectively resolved the first five issues; however, the monsters' skills remain unimplemented.

Alpha Playtest

On October 16, 2025, I showed the game to my classmates for the first time and let them play it.

Playtesting revealed that players consistently misread the core loop. Specific observations:

These issues pointed to a single underlying problem: information was too scattered for players to process while the game was actively running.

Design change: resource feedback and card clarity

One of the clearest player-centered iterations involved the card and resource system. Players consistently failed to understand when they could build something, or that resources were being spent at all.

Changes made

Cards that can be built now have distinct color states. Hovering over non-interactive cards shows required materials, with insufficient materials highlighted in red.

Process

Week 5 - Identified 5 clarity issues from observation

Player didn't notice card color changes, didn't understand resource loop, didn't realize card page toggle existed

Week 6 - Designed story-based tutorial sequence

Completed a progressive tutorial: place tile → gain resources → monster spawns → build first trap/tower. Each step introduced one mechanic at a time to reduce cognitive load.

Week 8 - Implemented contextual material display

Mouse hover on any card now shows required materials with red highlights for shortfalls. Card generation per level was also restricted — if a structure doesn't require certain materials, those cards won't appear yet.

How the change addressed player needs

  1. Players needed to know at a glance whether a card was usable — color differentiation and hover states gave them that signal without adding text.

  1. Players were overwhelmed by too much information at once — the tutorial sequence was restructured to introduce mechanics progressively, matching the pacing of player attention.

  1. Players needed immediate cause-and-effect feedback on resource use, the red highlight on insufficient materials made the cost relationship visible in context rather than forcing players to compare separate UI panels.

What I learned about my players

Players in general didn't read much, they acted first and expected the system to respond clearly. When feedback was delayed or indirect (like a card changing color without explanation), they missed it entirely.

This taught me that clarity in a real-time game isn't about adding more information, it's about placing the right information at the moment of decision.

I also learned that the first few minutes of a play session are almost entirely about building mental models, not playing the game itself. A poorly sequenced tutorial doesn't just confuse, it breaks the player's confidence in their own understanding of the rules, and they disengage. Restructuring the tutorial around one mechanic at a time significantly reduced early drop-off.

Playable Build after Alpha

In this Build version I want to show:
A pick-up and play version of game that can be launched and played without instructor guidance, and also demonstrates the potential for a full game.

Demonstrates the core loop, tone, and player experience we aiming for.

Ver 5 - November 6, 2025 Version

Main Page

Design Process