Yeonsu's Portfolio
File
Edit
View
Go
Window
NAVIGATOR
FAVOURITES
Recent
ON THIS PAGE
Problem Statement
Hypothesis
Design Decisions
What Failed
Outcome
Key Takeaway
Princess Escape — Case Study
Princess Escape
Role
Solo Designer & Developer
Type
Game Design / Development
Tools
p5.js, JavaScript
Context
University Module Project
Princess Escape
A 2D RPG where the story writes the mechanics — enemies never attack first, because a princess would never be.
PROBLEM STATEMENT
Most beginner game projects use stock assets and copy-paste mechanics. Can narrative intent drive mechanical decisions instead of the other way around — and produce a more coherent experience as a result?
DESIGN HYPOTHESIS
Standard game development workflow: pick a genre → implement mechanics → add story. I inverted this deliberately. Starting point was a character and a world, then letting narrative truth dictate interaction rules.
The central narrative truth: a princess would never be attacked first. No one in her world would dare. That single story rule became the core game mechanic — the player must always initiate combat. The rule and the story are the same thing.
HYPOTHESIS / BET
BET
If narrative decisions drive mechanical decisions, the game will feel coherent even with simple systems. A small, intentional game is more memorable than a large, generic one.
DESIGN DECISIONS
Turn-Based Combat with Dice Rolls
Dice rolls (base damage 15, variance ±10) introduce genuine unpredictability without requiring real-time skill. A weak roll creates tension; a strong roll creates satisfaction. The randomness reflects the narrative — the princess is improvising an escape.
Single Interaction Key (E) for Everything
Playtesting revealed hesitation when players weren't sure which key to use. Collapsing all interactions into one key eliminates that micro-decision. The player explores freely; the game interprets context.
Always-Visible Health and Inventory UI
Hiding player information creates tension in horror — but this is not a horror game. Showing health clearly gives players the information they need to make the interesting decision: when to use a potion.
Self-Made Sprites
When every visual element comes from the same hand, the world reads as unified. Mixed-source assets create visual dissonance that breaks immersion even in technically simple games.
WHAT FAILED
ISSUE
CAUSE
OUTCOME
Battle screen is text-only
Text version built as placeholder; no time to replace
Breaks visual continuity; world to text interface with no transition
Exit sprite invisible
Rendering order bug placed text layer over sprite
Exit functional but visually unfinished
Only one enemy type shipped
Time over-allocated to sprite creation early in project
Strategic depth limited; 3 intended enemy types reduced to 1
OUTCOME & REFLECTION
Submitted to IM Showcase. Post-submission feedback from reviewers: (1) "Combat flow was confusing — it wasn't clear what was happening during battle"; (2) "No sound made the experience feel incomplete." Both confirmed the two largest unresolved gaps: the text-only battle screen breaks visual continuity, and there is no audio layer. These are not polish issues — they are UX failures that affect the core game loop.
ROOT CAUSE: Sprite production consumed disproportionate time early in the project. The correct sequence — grey-box prototype first, replace assets once mechanics are stable — is standard game development practice. I understood it fully only after making the mistake.
What I would fix first in v2: animated battle screen with clear state indicators, and ambient audio tied to game states.
KEY TAKEAWAY
The decision that enemies never attack first is invisible as a mechanic — players experience a princess who feels in control, not a rule they have to learn. That design works. The battle UX didn't — and the reviewer feedback proved it. Good narrative intent isn't enough if the interaction layer fails to communicate what's happening. Both have to work.
‹
›
Yeonsu's Portfolio / Princess Escape
⊞
☰
⌘
Search
KEY TAKEAWAY