Game Prototype 1
A 3D Unity cube platformer built from one joystick and one button — every mechanic multiplies the others, across three sprints in eight days.
- Module
- GDEV40010
- Engine
- Unity 3D
- Camera
- Cinemachine
- Input
- Unity New Input System
- Controller
- DualSense / DS4
- Type
- Solo · Level 4
- Dev Period
- 14–22 Mar 2025
What is Game Prototype 1?
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.
// Game Prototype 1 — in-engine screenshot
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.
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.
Jump + Glide
Aerial · FoundationExtension Hold = glide mid-air
Synergy Rolling speed amplifies jump height
Adaptive Dash
Aerial · MultiplicativeAdaptive Timing changes dash direction/range
Synergy Tornado momentum boosts dash range
Momentum Jump
Physics · MultiplicativeEffect Faster roll = exponentially higher jump
Risk Overshooting platforms
Explosion Powerup
Economy · ActiveTrigger Player-activated burst
Effect Clears nearby obstacles, score gain
Tornado
Hazard · ToolCounter Dash through it for speed boost
Audio Wind SFX on activation
Bounce Obstacle
Obstacle · ReactiveSynergy Use with momentum jump to chain bounces
Risk Can launch into red tiles
Fragile Floor
Environment · TimedPressure Forces quick movement decisions
Combo Glide to safety after activation
Door / Key
Puzzle · NavigationPurpose Pacing and routing variety
Constraint Must detour from direct path
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.
-
14–15 Mar
Sprint 1 — Foundation (14–15 Mar)
Core player movement and rolling. Out-of-bounds detection, game over, and restart mechanics. White and red obstacle creation. Countdown timer. Glide and dash mechanic (initial version — took 80 min vs 40 min estimate, difficulty 5). Velocity limiter. Sprint reflection: over-ambitious planning; taught self to ignore perfecting minor details to avoid burnout. -
16–17 Mar
Sprint 2 — Controller + Hazards (16–17 Mar)
Polished jump and dash (both not triggering reliably). Switched to Unity's new Input System. Added DualShock / DualSense controller support with varied force feedback haptics and lightbar colour-change (Colour.Lerp). Started hazard creation. Initial level design blocked. Player-triggerable explosion mechanic added. Full Trello board tracking with tagged tasks (Player Movement, Core Mechanic, Game Over Trigger, Needs Polishing/Bug). -
18–22 Mar
Sprint 3 — Polish + Level Design (18–22 Mar)
Adaptive Dash / Phase Dash (3 hours, expected 1). Tornado Force Push mechanic with wind SFX. Momentum-Based Jump Boost (multiplicative velocity scaling). Full level design (4 hours — significantly longer than planned). Sci-Fi skybox from Asset Store. Bounce obstacle and Fragile Floor. Door/Key puzzle. Velocity cap tuning. Code cleanup and MonoBehaviour separation into relevant scripts. Sprint reflection: recurring crunch pattern; time estimation consistently wrong on physics-heavy tasks.
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.
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.
- Red Obstacle (instant death)
- White Obstacle (score + explosion charge)
- Bounce Obstacle (inverse launch)
- Fragile Floor (1.5s break)
- Tornado (pull + spin + dash boost)
- Door + Key Puzzle
- Out-of-Bounds Kill Zone
- Sci-Fi Skybox (Asset Store)
- Cinemachine Camera
- Countdown Timer
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.
Watch on YouTube
NomNom · Mar 15, 2025 · Unlisted
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.