Overview
What is Game Prototype 1?
// Game Prototype 1 — in-engine screenshot
Game Prototype 1 was built for GDEV40010 Game Prototyping at Staffordshire University (Level 4, 2024/25). The brief was strict: all mechanics must emerge from a single input constraint — one joystick and one button. Every mechanic had to be multiplicative, flowing from and amplifying the others rather than functioning in isolation.
The result is a 3D Unity cube platformer in which the player is a rolling dice-like cube. The goal: reach the end goal within a time limit, avoid red obstacles (instant game over), and push white obstacles off the map to build score. Starting at 100,000 points, the score drains with time — speed and skill are rewarded.
The project was structured across three sprints (14–22 March 2025), each documented in a Digital Academy Forum thread. Sprint 1 laid the foundation; Sprint 2 added controller support and hazards; Sprint 3 introduced the most complex mechanics — Adaptive Dash, Momentum-Based Jump Boost, and tornado physics — along with final level design and code cleanup.
- Awarded 84% — First Class for the module
- Three iterative sprints building up from a single mechanic
- Full DualSense haptics and lightbar feedback wired in
- Adaptive Dash and Momentum-Based Jump Boost mechanics
- Cinemachine camera system integrated
- One joystick, one button — layered complexity from minimal input
Core Mechanics
Systems Built
Every mechanic was designed to interact with at least one other. The button's single action changes meaning based on whether the cube is grounded, airborne, near a tornado, or carrying explosion energy — multiplicative layering through context.
Extension Hold = glide mid-air
Synergy Rolling speed amplifies jump height
Adaptive Timing changes dash direction/range
Synergy Tornado momentum boosts dash range
Effect Faster roll = exponentially higher jump
Risk Overshooting platforms
Trigger Player-activated burst
Effect Clears nearby obstacles, score gain
Counter Dash through it for speed boost
Audio Wind SFX on activation
Synergy Use with momentum jump to chain bounces
Risk Can launch into red tiles
Pressure Forces quick movement decisions
Combo Glide to safety after activation
Purpose Pacing and routing variety
Constraint Must detour from direct path
Sprint Breakdown
Three Sprints, Eight Days
Each sprint had a formal task table with estimated vs. final time and difficulty ratings, documented on the Digital Academy Forum. Sprint duration was kept intentionally short to match rapid prototyping constraints.
Controller Integration
DualSense & DualShock 4
The lightbar changes colour dynamically using Color.Lerp based on game state — health remaining, score threshold, and game over all produce distinct hues. This was planned as Sprint 2 Task 17 (25 min estimate) and completed as part of the controller pass.
Vibration applications tracked in the Trello board included: Floor Collision, Obstacle Collision, Gliding, Dash Collision, and Explosion — each with distinct intensity and pulse patterns.
Obstacles & Hazards
What's in the Level
The level was built in Sprint 3 and took approximately four hours — far beyond the 80-minute estimate. Every obstacle type was designed to interact with the movement system, not just block paths.
Development Video
Prototype in Motion
Development progress was captured across multiple short recordings uploaded to the NomNom YouTube channel as unlisted videos — each showing a specific mechanic as it was built. The final playable was recorded for submission.
Reflection
Challenges & Lessons
The single-button constraint forces creativity — When the design is limited to one joystick and one button, every new mechanic must emerge from context rather than new input. The Adaptive Dash's timing-based behaviour is a direct product of that constraint; it would be a far simpler mechanic if it had its own button. The constraint produced better, more intertwined design.
Physics estimation is consistently wrong — The Adaptive Dash took 3 hours against a 1-hour estimate. The tornado physics took similar unplanned time. Momentum-based systems are inherently hard to predict in Unity because small tuning changes cascade into unexpected behaviour. Level design, too, ran from 80 minutes estimate to 4 hours actual. By Sprint 3, this pattern was recognised — and documented — but not yet solved.
Burnout avoidance — Sprint 1 reflection explicitly noted the tendency to over-perfect minor details, wasting hours on insignificant parts of game prototyping. The discipline of ignoring that impulse — keeping realistic goals and shipping rather than polishing — was a core lesson carried forward from this module.
Multiplicative design works — The most satisfying moment in the prototype is using rolling momentum to launch into a tornado, dashing through it for a speed boost, and landing with enough velocity to chain a Momentum Jump over an obstacle that would otherwise be impassable. None of those three mechanics are interesting alone. Together, they are the game.