01 | Project Overview
Overview
Snacube is a grid-based puzzle game developed as a solo project for the course Introduction to Game Development. The player leads a chain of cubes through constrained spaces, placing followers on targets while each successful placement reverses the orientation of the remaining chain.
Design Challenge
How can a simple movement rule and a single reversal mechanic generate a complete sequence of increasingly demanding spatial puzzles?
Design Direction
Levels are built around narrow routes and limited maneuvering space, requiring the player to consider both how to reach each target and where the chain will be positioned after every reversal. Later levels introduce moving hazards, adding timing pressure without changing the core movement rules.
02 | How it plays
MOVE
Movement is restricted to a one-unit grid, making positioning predictable and allowing each move to become part of the puzzle.
PLACE & REVERSE
COMPLETE LEVEL
When every standard target has been filled, the final target appears. Reaching it completes the puzzle and opens the route to the next area.
MOVE → TARGET → DROP FOLLOWER → REVERSE CHAIN → REASSESS ROUTE
When every standard target has been filled, the final target appears. Reaching it completes the puzzle and opens the route to the next area.
03 | Puzzle & Level Design
The level sequence develops the same central mechanic rather than continuously introducing new rules. Early puzzles focus on spatial planning and constrained movement, while later levels combine the same decisions with timing pressure.
A | Spatial Planning
Early levels use narrow routes and limited turning space to teach the consequences of each placement. The player must plan several moves ahead to avoid leaving the remaining chain in an unusable position.
Some puzzles strongly constrain the solution, while others allow alternative routes once the reversal rule is understood.
B | Adding Timing Pressure
Later levels introduce animation-driven hazards. The underlying puzzle rules remain unchanged, but valid routes now have to be executed within safe timing windows.
C | Combining Spatial and Timing Constraints
As the game progresses, tighter spaces, longer sequences, and moving hazards are combined. Difficulty increases through the interaction of existing rules rather than through a constant addition of new mechanics.
04 | Technical Implementation
Snacube is built around a small set of interconnected C# systems handling grid movement, follower propagation, target interactions, level progression, failure states, and the final sequence.
A | Grid Movement & Chain Reversal
Movement is handled in discrete one-unit steps. Before the leader moves, the system stores the current position of every follower. After the move, each cube advances into the position previously occupied by the cube ahead of it, preserving the chain structure.
When a target is reached, the stored chain positions are reversed before one follower is placed on the target and removed from the active chain. The remaining cubes therefore continue from the opposite end, turning a successful placement into a new spatial state for the next part of the puzzle.
B | Single-Scene Level Progression
Switching level configurations without loading a new scene
All 11 levels exist inside a single Unity scene. Each area uses a separate GridPlayerMovement configuration containing its own followers, targets, final target, completion message, and barrier references. When the player enters a new area, a ChangeLevel trigger disables the currently active configuration and enables the next one. The barrier removed at the end of the previous puzzle is then restored behind the player, dividing the continuous environment into a sequence of self-contained levels.
C | States, Hazards & Completion
Late-game hazards move along predefined animation paths rather than using AI behaviour. Collision detection is handled separately: contact with the player activates the shared Game Over state and pauses play.
Reaching the final trigger coordinates the game’s closing sequence: player control and gameplay UI are disabled, the camera changes, the music is replaced, and timed zoom-out and emission effects lead into the return to the main menu.
05 | Outcome & Reflection
01 — What the project became
OUTCOME
Snacube developed one central reversal mechanic into an 11-level puzzle progression built around spatial planning, constrained movement, and later timing pressure. Rather than continuously adding new rules, the level sequence increasingly combines the same small set of interactions in more demanding ways. The final result is a complete playable course project with a tutorial, progressive level sequence, failure states, moving hazards, and a dedicated ending.
02 — What I learned
KEY TAKEAWAY
Designing the game showed me how much variety can emerge from a small mechanical rule when level geometry changes the consequences of each action. The reversal mechanic remained almost unchanged throughout the game, while increasingly constrained space s created different planning problems around it. It was also an early opportunity to connect several Unity systems into a complete game flow: grid movement, follower behaviour, targets, level transitions, failure conditions, animated hazards, UI, audio, and an ending sequence.
03 — What I would improve
IF I REBUILT IT TODAY
The project was implemented pragmatically within the scope of the course, and some systems would benefit from a more reusable structure. Each level currently uses a separately configured GridPlayerMovement component; if I rebuilt the game, I would keep a single movement system and move level-specific targets, followers, barriers, and completion data into reusable level configurations. Failure also reloads the entire scene, which means the player restarts the full run rather than the current puzzle. I would replace this with a checkpoint-based reset that restores only the active level and its state.