// Early gameplay — forgiving mechanic showcase

Mechanics Design is a Level 5 module at Staffordshire University (GDEV50024 — Introduction to Mechanics Design), split across two assessments that together form one complete project: a 2D platformer built in Unity 6 with C#.

The central question across both halves is the same — how do you make a game feel good to play? Assessment 1 answers it through forgiving mechanics: systems that catch human error without removing challenge. Assessment 2 answers it through game juice and game feel: responsiveness, viscerality, and the tactile feedback layer that elevates interaction above input.

The game has a deliberate personality. A death-driven corruption system floods the screen with brutal taunt text as the player dies more — "WHY ARE YOU STILL TRYING", "YOU KNOW THIS ENDS BADLY", "YOU'RE WORTHLESS" — implemented through a real event-driven architecture in Unity UI Toolkit. Version control used a self-hosted Perforce P4V depot on a personal PC running 24/7 via client VPN.

The brief: implement a suite of forgiving platformer mechanics — systems that compensate for human inaccuracy without removing difficulty. These are mechanics the player never consciously notices, but feels immediately if they are absent.

Game Feel = Responsiveness + Intuitiveness + Viscerality. Assessment 2 builds the full feedback layer on top of the forgiving mechanics foundation — every action the player takes should produce a physical, audio, and visual response that makes the interaction feel like it has weight.

The corruption system is driven by a single float — the player's death count mapped to a [0,1] range via an AnimationCurve. DeathCorruptionManager routes this value to four independent subsystems simultaneously:

// Health, stamina, and energy bars — runtime display

The DualShock / DualSense lightbar is wired to a configurable event-to-colour mapping via Inspector-serialised EventLightbarMapping structs. All transitions lerp smoothly over m_lightbarTransitionDuration (default 0.35s). The idle state adds a gentle sine-wave pulse on top of the base colour.

The player controller was refactored from a monolithic MonoBehaviour into a partial-class architecture across eight C# files. Each file owns a distinct responsibility. All handler instances are initialised through a chain-init pattern in Awake(): DetectorHandler → MovementHandler → StepHandler → JumpHandler.

The physics loop runs as a coroutine (C_PhysicsLoop) rather than FixedUpdate directly — this gives full control over execution order relative to other subsystems and simplifies coroutine lifecycle management.

ScriptableObject data assets decouple all numeric parameters from code. Every value the designer might want to tune lives in one of five SOs:

The player controller runs a six-state machine dispatched inside the coroutine-based physics loop. Each state owns its own movement logic, transition conditions, and feedback hooks:

The biggest architectural challenge was the conflict between Edge Detection and Coyote Time. Both systems respond to the same moment — the player at a ledge edge — but with contradictory logic. Edge detection tries to keep the player on the platform; coyote time grants a jump window after leaving it. Running both together created situations where the player could neither walk off nor jump correctly. Edge Detection was removed; Sticky Feet was designed as a replacement that only acts as a passive drag, disengaging immediately when the player gives directional input.

The coroutine-based physics loop was a deliberate deviation from Unity convention. Using FixedUpdate directly caused ordering issues when subsystems needed to communicate in a defined sequence each tick. Running the loop as a WaitForFixedUpdate coroutine made the execution order explicit and allowed all coroutine lifetimes to be controlled from one place.