The Cold City, developed in August 2026 by Team Rhiz at Stanford Summer Program
Game Link: https://the-cold-city.vercel.app
Team Rhiz Credits: Divyesh Khatri, Joey Gu, Yixun Su(Emily), Zerui Li, Xin Yue
P2: Level Design and Architecture Project
1.Artist’s Statement
The Cold City is a turn-based tactical game set in a futuristic cyberpunk city. The player takes the role of a lone vigilante moving through hostile spaces, fighting enemies, gaining skills, meeting NPCs, and gradually progressing deeper into the city.
Our main design goal was to make the player feel small and uncertain at first, then increasingly capable as they learn how the city works. Combat emphasizes movement, positioning, and adaptation rather than simply dealing more damage. Different enemies create different spatial problems: some punish poor positioning, some make cover important, and others force the player to keep moving.
Visually, we use minimalist cyberpunk pixel art, dark environments, and neon accents to create a cold, technological atmosphere while keeping important gameplay information readable. Narrative is introduced through NPC interactions, encounters, and short contextual moments rather than long explanations.
Ultimately, we wanted The Cold City to combine tactical challenge, spatial progression, and environmental storytelling into a focused playable experience.
2.System Model
2.1 System Map
Figure 1. Our system model showing the relationship between rewards, player upgrades, combat performance, and progression.
Our system model focuses on the relationship between combat, rewards, and player progression. By defeating enemies and surviving encounters, the player progresses through the game and earns rewards and credits. These resources can be converted into active skills, passive skills, equipment, and other upgrades that affect attributes such as damage, range, health, defense, and mobility. These changes then influence how the player approaches later encounters, creating a feedback loop between combat and progression.
Importantly, upgrades do not only make the player numerically stronger. Different abilities change how the player interacts with space—for example, by increasing attack range, improving survivability, or providing new ways to respond to enemy positioning.
As light of this, we decided to narrow our target audience to accommodate those whose interest in challenging platforming perhaps matched (or even exceeded) their interest in compelling narratives.
By limiting the scope of our core gameplay loop, we were also able to turn more of our attention to the complexity of everything surrounding it: most notably, the story. Though our game would focus heavily on exploring different environments, we wanted that exploration to be situated in a high-stakes context. From there came our initial ideas for the game’s central narrative conflict (a species and society on the brink of extinction), as well as the protagonist’s role and objective within it (a researcher searching for a new home in unfamiliar, dangerous territory). To complement the Fun as Challenge in the platforming mechanics, we wanted our players to experience Fun as Narrative as they navigate each level and unlock the hidden details about Gerbloff’s history.
One last initial decision worth noting concerned the Playdate’s unique crank controller. The crank lends itself to many rotational gameplay mechanics unlikely to be found in other games on other platforms. After seeing how it worked in games like Fulcrum Defender and Diora, finding compelling ways to use the crank in our game became an important priority for us. Many of our early playtesters cited the crank as a particular source of Fun as Sensation, which further incentivized us to find more creative uses for it as a creative storytelling and mechanical device.
3.Initial Decisions and Formal Elements
Our initial concept for The Cold City was a single-player tactical RPG set in a futuristic cyberpunk city. During our early ideation process, each team member developed an individual concept and storyboard exploring different ways that space could shape gameplay. After comparing these ideas, we combined elements that emphasized spatial progression, tactical combat, environmental storytelling, and a strong sense of atmosphere.
Our original concept imagined a city divided into different districts, each with its own visual identity, environmental challenges, enemies, micronarratives, and a major enemy controlling the area. The player would take the role of a vigilante traveling through these districts, becoming stronger and gradually changing the city through their actions.
We wanted to create something that gave players room to customize their own builds and arrive at unique solutions, even while working within the constraints of a grid-based system. Even with movement and positioning locked to a grid, I wanted the underlying strategy to still feel open ended, where different combinations of skills, gear, and playstyles could lead to genuinely different ways of solving the same encounter.
3.1 Individual Initial Ideas / Storyboards
Before deciding on a shared direction, each team member developed an individual concept exploring how space could shape the player experience. These proposals experimented with different settings, mechanics, spatial progressions, and narrative structures.
When we compared our ideas, we found several recurring interests: progression through distinct spaces, strong environmental atmosphere, combat influenced by the player’s surroundings, and a world that could communicate story through movement and exploration. Rather than selecting one proposal unchanged, we combined elements from several ideas into a shared concept.
Figure 2. Our team member’s design theme concepts
3.2 Initial Shared Concept
Our shared concept became an urban-fantasy action RPG set in a futuristic cyberpunk city. We imagined the city as a collection of districts, each with its own visual identity, mechanics, micronarratives, and a ringleader controlling the area.
The player would take the role of a vigilante attempting to challenge the city’s authoritarian power structure. Defeating a district’s ringleader would restore that area and unlock the next part of the city.
Our original gameplay loop was:
Explore District → Encounter Environmental Challenges → Fight Enemies → Gain Abilities and Gear → Defeat the Ringleader → Restore the District → Unlock the Next District
From the beginning, we wanted the city to feel cold and oppressive without being completely hopeless. The player would begin as a small figure within an enormous hostile environment, but progression would gradually show that their actions could create change.
3.3 MDA & Formal Elements
Figure 3. Cold City’s MDA Chart
MDA Explanation
Our concept map shows how the game’s mechanics work together to create the intended player experience. From an MDA perspective, the mechanics include grid-based movement, turn-based combat, enemy behaviors, skills, MP, credits, upgrades, and boss encounters. These mechanics create dynamics of positioning, resource management, build choices, and adapting to increasingly difficult encounters. These dynamics are intended to produce aesthetics of challenge, discovery, and narrative engagement.
Playtesting also helped us refine this relationship. When players found combat too easy, we added minimum enemy damage and enemy scaling. When movement and attack rules were unclear, we improved onboarding and clarified the one-move + one-strike turn structure. We also delayed the introduction of MP until spells became relevant and strengthened narrative integration based on feedback. These iterations helped the mechanics better support the intended player experience.
Player: A single player controlling a vigilante.
Objective: Progress through the city, survive encounters, gain abilities, and defeat major enemies controlling each area.
Procedures: Explore, move through grid-based spaces, attack, use abilities, collect rewards, acquire upgrades, interact with NPCs, and progress to new areas.
Resources: HP, MP, credits, skills, equipment, consumables, and spatial resources such as safe tiles and cover.
Conflict: Enemy behaviors, limited health and MP, hazardous spaces, positioning constraints, and increasingly difficult encounters.
Boundaries: Grid-based combat spaces, movement and attack ranges, obstacles, and turn-based actions.
Outcome: Defeating enemies and bosses allows the player to continue deeper into the city; defeat ends the attempt.
3.4 Initial Values / Intended Experience
We initially wanted The Cold City to create four major types of player experience:
Challenge through tactical combat and positioning.
Discovery through new spaces, characters, abilities, and enemy types.
Fantasy through becoming an increasingly capable cyberpunk vigilante.
Narrative through uncovering the city and gradually challenging its oppressive structure.
These values became criteria for later design decisions. A mechanic was more valuable to us when it did more than increase a statistic—ideally, it should create a new decision, reveal something about the world, or change how the player understood and used space.
3.5 Initial Skill System
One of our first detailed mechanical decisions concerned character progression. Our initial system gave the player one skill choice after completing each floor. Three random skills would appear and the player would choose one. Most were passive, while a smaller number were active abilities. Players could hold a maximum of five skills, meaning that later upgrades could require replacing an existing ability.
Early ideas included Power Strike, Double Slash, Shield Block, Dodge, Magic Barrier, Second Wind, Healing, Bow, Magic Staff, and different forms of armor. At this stage, however, these were primarily individual ability concepts rather than parts of a fully balanced combat system.
Please click on this link for Initial skill system doc & further information:
https://docs.google.com/document/d/1uGjkHNUFwcxEktnTpNOTO77jGPk_q_bSYL_AMRva5b8/edit?usp=drivesdk
Our first balancing pass began defining shared statistics such as HP, MP, damage, defense, movement distance, and attack range. Abilities also began receiving trade-offs. Double Slash, for example, could still attack twice, but each hit used reduced basic damage.
This changed the question we were asking from:
“What would be a cool ability?” to: “What decision does this ability create, and how does it interact with the rest of the system?”
3.6 Initial Art Direction
We defined our early visual direction using four keywords: Cyberpunk, Pixel Art, Futuristic, and Neon. Our goal was to combine a dark industrial environment with synthetic neon lighting, creating a city that felt technologically advanced but emotionally cold.
Readability was also a major consideration. Because characters and environments would appear at a relatively small pixel scale, silhouettes and high-contrast colors needed to communicate information quickly. Our early palette therefore treated color as both atmosphere and interface, with particularly bright colors reserved for information requiring immediate attention.
Our initial typography choice was Rajdhani SemiBold because its geometric forms supported the futuristic identity while remaining readable. This visual system would later change as we tested the actual interface.
For Cold City art style design methodology, please follow this link:
https://docs.google.com/document/d/10SYg39ZppFiczUT7n51c2vPI7rGNwDW_YWAiX2raaZE/edit?usp=drivesdk
4.Scope:
The final version of The Cold City is best described as a playable slice rather than an MVP of our entire original concept.
Our original concept imagined multiple districts with distinct environments, environmental challenges, ringleaders, character builds, equipment, and a larger interconnected narrative. Attempting to build every part of this vision at the same level of fidelity would have spread our development time too thin.
We therefore reduced the geographical scope and focused on creating a smaller sequence that could represent the experience of the larger imagined game. The playable slice still needed to demonstrate meaningful progression: the player begins with limited knowledge and abilities, encounters increasingly complex enemies, develops a build, interacts with NPCs and shops, and eventually faces major bosses.
This change allowed us to spend more time testing and polishing the systems that mattered most: tactical combat, spatial challenge, onboarding, progression, narrative integration, and visual feedback.
Our definition of success therefore changed from “build the city” to “build a small portion of the city that convincingly demonstrates what the full game could become.”
5.Testing and Iteration History:
Iteration 0: Storyboards & Basic Ideas
Figure 4. A photo of Singapore’s stunning urban greenery – an early inspiration for our game.
You might be wondering: why a cyberpunk city theme? It started during our team’s first brainstorming session on game themes, when we noticed something interesting. Each member’s individual pitch kept circling back to ideas of “nature,” “plants,” or “the environment.” That got us thinking: how could we build a game that felt dark and challenging, yet still carried a spark of vibrant, living energy? That’s when Singapore came to mind. Several of us have visited Singapore, and what stays with you is how the city keeps pulling you back into pockets of tranquil, green calm gardens growing right out of the skyline itself. Standing among them, it barely feels real that you’re still in the heart of a city. So we decided to build our world around this idea: an urban theme where players move like a shadow (a native “ninja”) through this green concrete jungle, tracking down merchants and city bosses hidden within it. Merging this with our earlier ideas gave us our first truly solid gameplay concept: a ninja who rises through the city, challenging the bosses who control it, one by one, to reclaim it as their own.
Iteration 1: Map Design & Verbal Concepts (July 27)
Figure 5. An early concept map depicting how players navigate through the map
We began by simply getting a concept map down on the iPad. In the beginning, we went back and forth on whether to let players roam freely across an open map, or to adopt a grid based system where movement happens step by step. Since this is a digital game, we would like to have a more dynamic and responsive experience than an analog game. In the end, we landed on the grid map, drawing inspiration from Spellsided, Hollow Knight: Silksong, and Slay the Spire.
Figure 6. Our initial map inspiration
We chose this approach specifically so that we could build a system that allowed for tactical, engaging decisions while keeping the technical scope manageable within our three week project timeline. With this decision made, we began writing out the game and pitching our concept to classmates, branding it as a combat and exploration game set in a cyberpunk world. The response was encouraging, with many people expressing genuine interest in the concept. At this stage, we successfully completed our game’s first playable version as a Python terminal simulator.
- Core mechanics: a 5×7 grid, turn based combat, distinct enemy types, randomized power placement, and collectible powerups.
- Art direction: low res pixel melancholy paired with eco brutalist scale. The player begins as a small figure in a cold, indifferent city, one that slowly warms as the game progresses.
- Designer’s Talk: For a short game like this, having a randomly generated level layout matters a great deal for replayability. It gives players a reason to run through the game more than once, since no two playthroughs feel exactly the same, and it introduces flexibility into how each run unfolds rather than locking players into a fixed, memorized path.
Iteration 2: First Rendered Build (July 28)
Following this milestone, we gathered feedback on our terminal prototype, and we all felt like the game felt too bare, lacking the visual and tactical depth needed to make combat feel meaningful. Taking this to heart, we rebuilt the game in a browser canvas, giving us far more flexibility than the terminal ever could. We shifted the board to a landscape orientation and narrowed our scope down to a single district, allowing us to focus our efforts on depth rather than breadth.
With this new foundation, we introduced cover mechanics and distinct enemy behaviors, each designed to punish a specific type of player mistake. The Grunt targeted poor positioning, the Archer capitalized on players who ignored cover, the Mage exploited those who stood still for too long, and the Warden challenged players who relied solely on blade attacks. Together, these enemy types became the backbone of our core combat design, shaping how players would need to think and move through every encounter that followed.
Iteration 3: Playtests!!!
Playtests 1: July 28, 2026
Our first playtester was a millennial male who is fairly experienced in gaming, especially in combat games.
Figure 7. First Playtest
First Playtest recording: https://drive.google.com/drive/folders/1L8tRE2YaLSfwwjNPOE-wFj34DeuWc8bj
Our second playtester was a female who has some experience in overall gaming (e.g. Plants vs Zombies)
Figure 8. Second Playtest
Second Playtest recording: https://drive.google.com/drive/folders/1L8tRE2YaLSfwwjNPOE-wFj34DeuWc8bj
What we iterated for error:
- Our next round of feedback centered on the turn system. Players found the “End Turn” confusing, so our first change was to have turns auto resolve instead. This, however, introduced a new problem: without a clear stopping point, players could move multiple times in a row and then attack every enemy on the board in a single turn, breaking the balance we had worked to establish. To fix this, we limited players to just one action per turn. But this fix went too far in the other direction.
- A second round of feedback pointed out that a turn should naturally allow for both one move and one strike, and that the mortar enemy should also be attacking every turn rather than sitting idle. Taking this feedback into account, we restored both rules to their original form.
- The key lesson here was an important one for our design process going forward: a UI clarity problem does not always call for a rules change. What players actually needed was a clearer turn indicator, not a stricter turn structure. The final turn system settled on allowing one move and one strike per turn, striking the balance we had been aiming for all along.
What we think we did alright:
There were several aspects of the game we felt we got right from early on. Even though the game was still fairly raw at this point, players understood it intuitively, without needing a formal tutorial. Without any help from us, players could figure out how the game worked: how to move across the grid, where the enemies were positioned and what they represented, and how to initiate an attack. The exit was clearly visible, and players understood exactly when a new round began. They also had a clear sense of when they had reached the end of the game. This intuitive clarity, even in such an early build, gave us confidence that our core design instincts were pointing in the right direction.
At this stage, the overall satisfaction score of Cold City, according to playtesters, was around ~7/10.
Iteration 4: Playtests 4-5 (Rules Sheet & Online Deployment Update) – August 3rd
After several iterations from iteration 3 with a first few rounds of playtesting among classmates and our own team members, we entered Iteration 4. At this stage, we focused on rules and deployment, aiming to make the game more comprehensive, logical, and accessible to new players. During this stage, we created a formal RULES.md document, along with a two page printable rules PDF that players could reference outside the game itself. We also completed our Vercel deployment, making the game accessible online for the first time (YAY :D)
To access rules PDF, please follow this link:
Phase 5 was a big one, as our full skill system finally came to life. We rolled out twelve levels of progression, with level-gated skill pools that gradually unlocked new abilities as players leveled up. Four active skills made their debut here: Fireball, Fire Rain, Whirlwind, and Slash, plus a set of buffs that kicked in at fixed levels along the way. Oh, and this phase also marked the first time our teammates’ hand-made sprites showed up in the game. Big moment for us.
We published our damage formula: *damage = floor(max(0, (basic + extra) × hits − defense) × amp × (1 + vulnerability))*
Two quirks worth calling out: defense only applies once per attack, no matter how many hits land, and magic damage cuts straight through fifty percent of defense. Why does this matter? Because it turned the Warden from a boring stat check into an actual tactical puzzle. Suddenly players had to think about when to swap from blades to spells instead of just mashing the strongest button.
Following this phase, we received feedback from the team: our teammates’ artwork needed to appear in the game. In response, we replaced our placeholder sprites with the team-made sprites, bringing the game’s visuals in line with the art direction we had been working toward all along. Finally, the game started looking like it was finally coming all together.
Figure 9. Initial design for main character and skillsets
Figure 10. Updated design for main character and skillsets
Figure 11. Initial “Merchant” design
Figure 12. Finalized Merchant Design
At this stage, the overall satisfaction score of Cold City, according to playtesters, was around ~7.5/10.
Click to see changes in the Skill System:
https://docs.google.com/document/d/1fIDFSCJrsM8C3JXKV0698Ao4cE2nRV1fvKoTUOUVKZ0/edit?tab=t.0
Iteration 5-6: Playtests Continue… (August 5)
In this round, our playtester is a millennial male who has around a 4/10 experience in combat games.
6th Playtest
Playtest recording:
Phase 6 focused on the idea of “show, don’t tell.” The feedback here was pretty pointed: visualizing raw combat math on screen during battles broke playtesters’ immersion.
To solve this problem, we removed the math from the play area. In its place, we added things players could see and feel: hit flashes, a camera kick on impact, floating damage numbers, and HP preview pips. The formulas didn’t disappear; we just moved them into the rules panel for anyone who wanted to check them.
We also heard that the repeated “city moves” message was confusing and added clutter. So we deleted it.
While fixing these issues, we also cleaned up two smaller bugs: broken emoji and text encoding, and a softlock after enemies died that still let players target them.
At this stage, the overall satisfaction score of Cold City, according to playtesters, was around ~7.5-8/10.
Iteration 7-8: MORE.. Bug Fixing… & Tutorial Updates!! (August 5-6)
Phase 7 focused on a diagonal combat bug. Playtesters noticed that a Grunt should attack when the player moves next to it, including diagonally. But there was a problem: the player could attack diagonally, while Grunts could not. This meant players could stand diagonally to a Grunt and attack it for free, without ever risking a counterattack.
To fix this, we changed both the player and the Grunts to use Chebyshev distance, so diagonal and straight-line distances would be treated the same way for both sides. The bigger lesson was that we didn’t catch this exploit by reading the code. A playtester found it just by playing and noticing that the fight felt unfair.
Phase 8 was about “getting the player to learn by doing” through a full redesign of our tutorial, guided by George Fan’s tutorial principles. We have been hearing a lot of playtesters’ feedback about adding a quick onboarding tutorial to get the game going. So we want to make sure our playtesters understand exactly what to do very early on in the game. So we introduced our first real tutorial attempt, built around three core mechanics we wanted players to come away understanding: (1) grabbing objects from each level; (2) walking toward and attacking bosses, and (3) buying items from the Merchant. We implemented the combat tutorial very early in the game (at the start) using brief sentences to guide players through the process.
Step 1 – Introduce the player: the pilgrim.
Step 2 – Instruct how to move through the grid.
Step 3: Instruct what to do with diamonds.
Step 4: Instruct where the exit is. (Where the game ends).
Step 5: After the player walks out the gate, the first round ends. Instruct how to use the game mechanics to choose skills.
Step 6: Instruct on goon location and how to move closer to it.
Step 7: Instruct how to attack an enemy.
Step 8: Introduce the Merchant.
That said, we intentionally chose to introduce the Merchant tutorial much later in the game. This gave players room to get a feel for the world and explore freely first, allowing them to arrive at a natural understanding of what to do rather than being told outright. This approach was inspired by a GDC talk on onboarding in Plants vs. Zombies, which we had studied earlier as part of our coursework. We wanted to weave the tutorial into gameplay itself, have players perform each action only once to learn it, and keep dialogue prompts light and unobtrusive. The core principles behind this were simple: teach players at the moment they actually need the information, use as few words as possible, teach one idea at a time, and only offer extra help when a player genuinely needs it.
With these principles guiding us, we made several concrete changes. Large blocks of instructional text were replaced with short, contextual prompts, each one under seven words, appearing right at the moment a player needed that specific piece of guidance.
Iteration 9: Playtests 8-11 (August 5-6)
Difficulty Model & In-Class Playtest Feedback Updates
Our Playtester is a female with moderate experiences in gaming.
Phase 9 tackled our difficulty model.
Our Problem:
Up to this point, we relied mostly on intuition to judge whether the game felt fair or too easy, but the feedback was clear: difficulty needed measurable rules behind it, not just gut feeling. We built a difficulty model that reads the game’s actual combat stats and calculates a single combat pressure value. Below 0.30, the model considers combat trivial. Between 0.30 and 0.60, it is fair. Between 0.60 and 0.85, it becomes tense. Between 0.85 and 1.00, it is brutal. And above 1.00, it is lethal.
Running this model revealed something important: defense could reduce most enemy attacks to zero. Around the same time, a playtester reported this exact issue in their own words, saying the player felt “immortal.” It was a striking moment; our data and a real player had independently landed on the same problem.
Our solution:
To fix this, we set a minimum enemy damage of one, so no attack could ever be fully negated, and we made enemy scaling increase alongside player level. The real lesson from this phase was that the model and the player had found the same balance problem through completely different methods, which gave us a lot of confidence that we were looking at a genuine issue rather than a fluke.
Phase 10, on August 6th, was our largest playtest round yet, and it generated a long list of concrete feedback. Players said other on-screen text was still too small, so we increased the type size across the board. They asked for bigger HP and MP bars, so we enlarged the HUD pips. We noticed players were ignoring instructions entirely, which pushed us to continue refining our tutorial redesign. The “immortal” defense buff issue came up again here too, reinforcing our earlier fix of minimum damage and enemy scaling. Several players said they didn’t realize they could move and attack in the same turn, so we added a turn economy tutorial beat to make that clearer. Players also had no idea what shrines did, so we added feedback to make their purpose visible. Two issues remained open by the end of this phase: enemy conditions were still unclear, and several levels needed stronger overall design. Alongside all this feedback driven work, we also introduced Lance, a new boss who marks danger zones on the ground before attacking, giving players a visual warning to react to.
In-class Playtest
At this stage, the overall satisfaction score of Cold City, according to playtesters, was around ~8-8.5/10.
Iteration 10: Phase 11-12 (MP Clarity, Typography Updates) August 7-9
Phase 11 focused on MP clarity.
Our Problem:
Players simply did not understand what MP was or how it worked.
Our Solutions:
We hid MP entirely for the first two levels, only showing and explaining it once the player actually received their first spell. This followed a rule we had learned earlier in our tutorial work: introduce a system only when it becomes useful, not before. During this phase, we also corrected a misunderstanding on our end. We had assumed shrine feedback had stopped working, but it turned out the feedback itself was fine. What was actually missing was persistent HUD information showing that state over time.
Phase 12 was a smaller, more focused update centered on typography. We updated our fonts, choosing Jersey 10 for display text and Kode Mono for body text.
Iteration 11: Phase 13-14 (Team merge & Format Adjusting Updates) August 10
Phase 13 was our team merge.
Our Problem:
One of our teammates had rebuilt Act 1 and expanded the game significantly, growing it from twelve levels to nineteen. This merge revealed a serious problem though: the repository had two separate copies of pilgrim.html, and they had slowly drifted apart over time. As a result, teammate work was quietly disappearing from the deployed build without anyone noticing right away. When we discussed this, one teammate asked a simple but important question: could we give an error if someone uploaded the wrong file?
Our Solutions:
In response, we deleted the duplicate file, kept a single source of truth, and added a build check that would fail automatically if another root level copy ever appeared again. The lesson here was an important one for how we approached problems going forward: it is better to prevent an error at the system level than to rely on documentation or memory to avoid it.
Phase 14 dealt with a tutorial affordance issue.
Our Problem:
We received a report saying, “I can’t move the player anymore.” After investigating, we found that movement itself was working fine. The real issue was that tutorial boxes were blocking player input, and players did not realize they needed to dismiss the box first. Feedback pushed us to make the tutorial box visually communicate that it was clickable, without resorting to text like “click this box.”
Our Solutions:
To solve this, we added a gently bobbing chevron, desaturated the game board while a tutorial box was waiting for input, and made the tutorial box shake if a player clicked elsewhere on the board instead. The broader lesson was that a good affordance should communicate how to interact with something without needing extra explanatory text. Around the same time, we also revised a hint that read “Cross to the far side” into a more specific and useful instruction: “Hint: tap the gate once it opens,” ensuring the hint actually described the real interaction players needed to perform.
Iteration 12: OUR !!!FINAL!!! UPDATES – Tutorial correctness (August 10)
Phase 15 focused on tutorial correctness, fixing cases where the tutorial system was technically working but giving players incorrect or broken information.
Our 1st Problem:
The first problem was that some tutorial pop ups were not dismissing correctly. After digging into it, we found the cause: the tutorial state itself was blocking the very code responsible for clearing the box and unlocking player input.
Our Solution:
We corrected this dismissal logic so tutorial boxes would close properly and reliably hand control back to the player.
Our 2nd Problem:
The second problem was more subtle. Tutorial messages were sometimes appearing even after their text was no longer accurate. A few examples made this clear. A one hit kill could prevent the game from ever recording that the player had struck an enemy, since the enemy was gone before that state registered. A one turn delay could shift a tutorial message so it appeared out of context, no longer matching what was actually happening on screen. And in some cases, messages simply had no check at all for whether their statement was still true at the moment they appeared.
Our Solution:
To fix this, we added when() conditions to our tutorial messages. Now, a tutorial message only appears if its underlying statement is actually true at that moment. If the right moment has already passed, the game simply skips the message rather than showing something misleading. This led us to a final guiding principle for tutorial design going forward: silence is better than a false instruction.
Some FINAL Designs of the Game:
Added more characters that serve as different functions for the game!
Designer’s Reflection: Challenges
One of the biggest challenges we faced was making each boss feel genuinely unique rather than just a reskinned version of the same fight with higher stats. It would have been easy to simply scale up health and damage numbers for each new boss encounter, but that approach risks making every fight feel mechanically identical, just slower or more punishing. Instead, we had to design distinct behaviors, attack patterns, and weaknesses for each boss, giving players a real reason to adapt their strategy each time rather than repeating the same winning move over and over.
Another major challenge was keeping the combat system readable and easy to understand, especially as we layered in more mechanics over time. With turn based movement, attacks, skills, defense calculations, and enemy behaviors all interacting at once, there was a real risk of overwhelming players, particularly early on. We had to constantly balance depth against clarity, making sure that as we added more tactical options, players never lost track of what was actually happening on screen or why an outcome occurred the way it did.
Finally, we faced the challenge of weaving the game’s other elements, its NPCs, story, and world, into the combat system itself, rather than treating combat as an isolated mechanic bolted onto a separate narrative layer. We wanted fights to feel like a meaningful part of the story players were moving through, not just an obstacle standing between story beats. This meant thinking carefully about how bosses connected to the game’s larger narrative of reclaiming the city, and how NPCs and merchants could inform or contextualize the battles players were about to face, rather than existing purely as separate systems running in parallel.
Final Playtest Video Link (FULL):
https://drive.google.com/drive/folders/1X_F0VYwlR53i0WVVIaqquJqxM3N7gZ3T?usp=drive_link
| Playtest moment | Course concept / interpretation |
| Part 1, 1:05 | Affordances, feedback, onboarding. The glowing tile functions as a visual signifier. This is a useful example of the game teaching a rule through interaction rather than text. You could ask whether the initial hesitation is productive discovery or evidence that the affordance needs strengthening. |
| Part 1, 2:58 | Emergent dynamics + learning through feedback. The underlying movement/attack rules generate a hit-and-run strategy that seemingly was not explicitly prescribed. This is almost a textbook MDA example: mechanics produce a player-created tactic. |
| Part 2, 0:52 | Information hierarchy / cognitive load / UI legibility. The underlying system may be interesting, but difficulty parsing categories creates interface difficulty rather than strategic difficulty. Also pairs well with their earlier comment: “Text is really small.” |
| Part 2, 4:06 | Affordance → expectation → feedback. The design needs especially strong feedback explaining what cover does. This is a breakdown between our system image and the player’s mental model. |
| Part 2, 6:21 | MDA + evolving possibility space. New enemy mechanics create a new dynamic of mobility and spatial planning. The resulting aesthetic is greater tension and tactical competence. This is especially strong because you can contrast it against the earlier “hit-and-run” moment and show how additional enemy types improved the combat system. |
EXTRA CREDITS
Extra – Accessibility:
Accessibility was improved throughout development in response to playtest feedback. We increased the size of instructional text and enlarged the HP and MP indicators to make important information easier to read. We also selected clear pixel-style fonts and used visual feedback—including hit flashes, floating damage numbers, HP previews, danger-zone markers, and tutorial animations—to communicate game states without relying only on written explanations or sound.
Tutorial information is introduced gradually and only when it becomes relevant. MP, for example, remains hidden until the player receives their first spell. Interactive tutorial boxes use a moving chevron, background desaturation, and a shake response to indicate when player input is required. The introduction also prevents repeated inputs from accidentally skipping unread text and provides a separate Skip button for players who prefer to bypass it. The Game Guide and accessible Loadout menu allow players to review enemy information, items, and skill effects when needed.
Extra – Extended Narrative and Game Design:
Inspired by Movie/Novel:
Cyberpunk: Edgerunners influenced the game’s neon cyberpunk aesthetic, oppressive urban environment, and depiction of an individual struggling against a powerful system. However, The Cold City adopts a more hopeful direction: rather than emphasizing inevitable tragedy, the player gradually becomes stronger, liberates parts of the city, and creates the possibility of meaningful change.
Ethical Implications:
The game explores resistance against authoritarian power, inequality, and the control of urban spaces by powerful leaders and institutions. The player is positioned as a vigilante attempting to reclaim the city, but this premise also raises questions about whether violence alone can create lasting social change and who has the right to decide what “liberation” means.
We attempted to frame combat as part of a broader struggle for community and recovery rather than violence for its own sake. NPC interactions, merchants, environmental storytelling, and the gradual restoration of the city show that ordinary residents are affected by the player’s actions. The game does not ask players to harm civilians, and enemies are presented primarily as agents of the oppressive system. Nevertheless, future development could provide more nonviolent choices and give the city’s residents a greater role in determining its future.
Extra – Divyesh’s Notes on Design:
I admire a lot of retro animations and designs. Leaning into this aesthetic during the development of the game was quite rewarding! In terms of developing the music, I really leaned on my own music style I have developed while also leaning on a lot of synthy trancelike elements to add to the game. I’m a big fan of artists like Yaego who bring a retro feel to their sound, as if there is a yearning for the parties of the 2000s. Also cult member. Ultimately if I am unsuccessful in designing this soundtrack, I will rely on these two artists’ tracks.
Extra – Joseph’s Notes on Design:
My role in the development of this game was the implementation and polishing of concepts and experimenting with potential mechanics. I was responsible for taking any and all feedback given by the playtesters and using it to further refine the game.
The process was intended to really make the game feel as intuitive as possible, allowing players to think about strategies instead of using all their brain power for figuring out how something worked.putting the player inside the world instead of having them feel like an outside force is what makes or breaks a game for me.
In addition, I was responsible for writing the plot/dialogues in the game, as well as balancing the progression of the player as they go along. The point is to allow the player to feel like they’re a character who’s getting stronger as the story progresses, but not so strong as to make the combat meaningless.
Overall, it was an extremely fun experience being able to bring our ideas to life in the form of a video game. I think one of the most rewarding parts of game design is taking feedback and push the game to become something beyond the original scope, and I think it’d be fun to further develop the game even after this course.
Extra – Zerui’s Notes on Design:
My main responsibility is to supplement game mechanics and conduct playtests. To be honest, my workload is relatively small, but I still think it’s important.
The various combat mechanisms of the game are extremely important, especially how to consider allowing players to play the game normally instead of being brainless and constantly confused. I think the most important thing is to let players know how the things they choose will help them fight, help them become stronger, and ultimately allow them to enjoy the game. These mechanisms may be small, but they are an important part of the game.
Finally, I would like to say that if I could do it again, I would definitely make more adjustments to the balance of the mechanism, really!
Extra – Clare’s Artist Notes:
During the development of Cold City, my main focus was project management. As a first-time game developer, it has been a fun and thrilling experience. My main responsibilities included setting sectional goals and deadlines, tracking the project pipeline, and keeping the game on schedule to meet its target release date. I also worked to keep every team member on track, motivated, and clear on our goals during each phase of development. I also recorded playtests and playtester feedback, summarizing what we did well and what we needed to improve in our group chat. Game development is truly a team effort, but I found that through making games together, a team can bond more closely than ever before.
Extra – Yixun’s Artist Notes:
My main contribution to the game focused on its visual design and player experience. I created and refined pixel-art assets for the player character, NPCs, merchants, enemies, bosses, skill icons, and other interface elements. My goal was to establish a consistent cyberpunk-fantasy style while ensuring that each character’s role could be understood visually. For example, melee and ranged enemies were given different weapons, colors, and silhouettes so that players could distinguish their abilities before entering combat.
Throughout development, I revised many designs in response to playtest feedback. When players found certain enemies too visually similar or had difficulty understanding skills and game information, I simplified shapes, strengthened color differences, and created clearer icons and interface elements. I also helped design bosses whose visual appearance communicated their mechanics, such as technological armor, ranged weapons, and laser-based attacks. This process taught me that game art should not only make a game attractive—it should also communicate information and support gameplay.
I was especially interested in balancing the game’s dark cyberpunk atmosphere with readable and approachable pixel art. Rather than making every asset highly detailed, I used simplified forms, limited colors, and recognizable silhouettes to keep the visuals consistent at a small scale. Through this project, I learned how visual design, mechanics, narrative, and player feedback influence one another during an iterative development process.
Extra – Playtest Logs on Notable Quotes:
- “The player feels ‘immortal.’”
This comment revealed that defense could reduce enemy attacks to zero, removing most of the tension from combat. In response, we introduced a minimum enemy damage of one and made enemy strength scale with player progression.
- “I can’t move the player anymore.”
Although movement was functioning correctly, the tutorial dialogue was blocking player input, and the player did not realize that the dialogue box had to be dismissed first. We added a bobbing chevron, visually muted the game board, and made the dialogue box shake when the player clicked elsewhere.
- “I didn’t realize I could move and attack during the same turn.” (Paraphrased)
This feedback showed that the turn economy was not communicated clearly. We added tutorial guidance explaining that each turn allows one movement and one strike.
- “What does the shrine do?” (Paraphrased)
Players did not understand the purpose of shrines or recognize their lasting effects. We added clearer visual feedback and persistent HUD information.
- “What is MP, and how does it work?” (Paraphrased)
Players encountered MP before it became meaningful to them. We therefore hid MP during the first two levels and introduced it only when the player received their first spell.
- “The text and HP/MP indicators are too small.” (Paraphrased)
In response, we increased the general text size and enlarged the HP and MP pips to improve readability.
- “The combat math on screen is distracting.” (Paraphrased)
We removed raw calculations from the main play area and replaced them with hit flashes, camera movement, floating damage numbers, and HP previews.
AI Disclosure:
The game was entirely ideated and created by team members, with the only exception being the use of AI tools for vibe coding and debugging. All art, music, storyline, level design, combat systems, et cetera were done by members of the team.
Hey, I was one of your play testers! I had a great time playing your game! I also love the merchant’s design! Great work!