No level editor
Every 3D tile was placed individually in Unity. The layout had to stay achievable at jam speed.
Level Design · GMTK Game Jam 2022
You Only Die Once
Building three readable strategy levels around one unstable resource: the action points produced by a die roll.
Overview
A movement puzzle disguised as an action game.
The player controls a die through trials inspired by Hercules. Each roll determines the available action points, so every route and enemy placement affects the player's next decision.
- Format
- 48-hour game jam
- Engine
- Unity
- Platforms
- HTML5 and Windows
- Scope
- Three complete levels
My role
I designed and assembled all three levels.
I manually placed every walkable tile, then positioned enemies, encounters, objectives, hazards, checkpoints, and progression gates. I also dressed the spaces with trees and fog to make the routes legible inside the fantasy setting.
Siddharth created the 3D assets. Venkat and Rutvij handled programming, including the system that detected walkable tiles, enemy positions, and the player's relative position. I designed within that system; I did not program it.
Problem
Make uncertainty create planning—not confusion.
A die roll changes what the player can do. If a route is unreadable or an enemy arrives without enough decision space, randomness feels punitive. The level layout therefore had to expose choices early enough for the player to spend uncertain action points deliberately.
Goals
Give each level one clear learning job.
- 01
Orient
Begin with fewer enemies and a smaller playable area so the grid and action economy can be read.
- 02
Complicate
Add walkable tiles and enemies so movement becomes a route-planning problem rather than a straight advance.
- 03
Test
Ask the player to combine movement, positioning, and combat planning under the same action-point constraint.
Constraints
Forty-eight hours. Manual construction. One shared ruleset.
System dependency
Paths and encounters had to remain compatible with the programmers' detection system.
Finite scope
Experimental levels were cut so three complete, escalating levels could ship on time.
Research
Reduce the mechanic to the variables a level can control.
The design work focused on four observable variables: available action points, walkable tile count, enemy position, and the player's relative position. That kept spatial decisions connected to the mechanic instead of treating the environment as decoration.
Action pointsPath lengthEnemy positionPlayer position
Iterations
Playtesting exposed dead space and broken access.
Observed
Some sections were inaccessible.
Other areas could be reached but offered no meaningful interaction.
Changed
Rebuild the affected paths.
I replaced tiles and rerouted pathways to restore access and create useful gameplay opportunities.
No before-state capture survives. The iteration is described here without inventing a visual comparison.
Design decisions
Escalation came from relationships, not new rules.
Increase the number of walkable tiles.
More possible positions meant the player had to evaluate routes instead of following a corridor.
Increase enemy count across later levels.
Each additional threat changed the value of a move and made positioning more consequential.
Use dressing to reinforce the playable space.
Trees and fog supported the atmosphere while the tile grid retained responsibility for navigation.
Gameplay thinking
Failure had to teach the cost of the previous route.
The player's roll supplies opportunity, but the level determines whether that opportunity can be converted into progress. Clear threats and paths make a failed run readable: the player can reconsider positioning rather than blaming an opaque space.
Process
Build the route, test access, then add pressure.
- Define the learning job.Choose what the level should ask the player to understand.
- Place the playable path.Build the route manually from individual 3D tiles.
- Stage encounters.Position enemies, hazards, objectives, checkpoints, and gates against the route.
- Playtest access.Find unreachable sections and spaces without useful interaction.
- Rebuild and dress.Replace affected tiles, reconnect paths, and reinforce the space with trees and fog.
Screenshots
Three public frames, three different pieces of evidence.
Gameplay: shows the readable grid, action-point display, enemy spacing, and elevated camera.
Title framing: establishes the temple language that carries into the levels.
Failure: shows the immediate replay decision after a run ends.
Videos
Use the playable build as the primary evidence.
No verified walkthrough video is available, so this case study does not substitute an edited reel. The public HTML5 build lets reviewers inspect movement, camera behavior, route readability, and encounter pacing directly.
Play on itch.io ↗Lessons learned
A reachable space is not automatically a useful space.
The most important revision was not visual polish. It was removing routes that failed to produce decisions. The project reinforced a practical rule: validate access and meaningful interaction before spending limited time on additional content.
Credits
A four-person jam team.
- Saurabh Gajwe
- Level design and level assembly
- Siddharth / Darthsid
- 3D assets
- Venkat / WickedCube
- Programming
- Rutvij Joshi
- Programming and public project page
The team used pre-existing audio. Individual contributions are stated explicitly because the public itch.io page lists only Rutvij as its author.