Projects - Saparkour
Saparkour
Movement Design | Player Controller | Level Prototyping | Systems Iteration
Play The Game →Summary
Saparkour is a 3D precision movement prototype built in Unity over two weeks. The game focuses on high-stakes jump commitment, physics-driven bounce interactions, and a modular grappling system designed to enable controlled mid-air traversal.
Project Details
5 handcrafted levels
14 interactive props
Custom rigidbody-based character controller
Power-bar jump charge system
Physics bounce system (configurable bounciness > 1)
Spring-damper grapple system
Checkpoint + reset architecture
Encrypted local leaderboard persistence
Team and Time
Team Size: 1 (Solo project)
Time: 2 weeks
Goals
My goals for Saparkour were to make a 2-week game with as much detail and polishing as I could, while
providing to the player the unique racing-rage-platforming feel.
My time over the 2 weeks was spent in 3 pillars: Design (over the first 2 days), Gameplay programming
(over 9 days), and UI polishing (over the last 3 days).
I took special time to develop and make tutorials of the game's main mechanics, jumping and grappling. I
used the remaining gameplay programming time to make interactable props and combine action blocks into 3
well-developed and more challenging levels.
Systems
Movement System
Custom rigidbody-based character controller
Jump charge calculates impulse force based on input duration
Air movement intentionally restricted to increase stakes
Bounce system supports per-object configurable bounciness (including >1 multipliers for momentum
amplification)
Grapple System
Spring-damper implementation for elastic tongue behavior
Grapple state overrides air immobility constraint
Modular attachment points defined via grappleable surface class
Integrated into movement state transitions
Reset System
Objects reset to initial position for fast checkpoint iteration
Movement state resets every reset event
Different types of reset (soft vs. hard level reset)
Leaderboard System
Local leaderboard persistence
Encrypted JSON storage
Time-based ranking logic
Designed for future online extensibility
Technical Challenge: Hybrid Movement Controller
Saparkour was developed under a strict two-week production window. To accelerate early development,
I initially implemented player movement using Unity's built-in CharacterController,
which allowed me to quickly prototype the core jumping mechanics and begin level iteration.
However, once I began implementing the grappling mechanic, I discovered a major limitation:
the CharacterController does not interact with physics forces in a way that allows for natural
swinging or elastic movement,
making it unsuitable for the grappling system I had designed.
Rather than rebuilding the entire movement system from scratch late in development, I designed a
hybrid controller architecture that allowed the player to switch between two different movement
implementations depending on gameplay context.
Solution
I implemented two separate movement controllers inside the player:
CharacterController-based movement for standard ground movement and jumping
RigidBody-based movement for grappling interactions and physics-driven traversal
To manage these behaviors cleanly, I structured the movement system using a State design pattern.
A manager class tracked the player's current movement context and activated the appropriate controller
depending on the character's state.
Example state transitions:
Normal Movement → CharacterController active
Grapple attached → Rigidbody controller activated
Grapple released → return to CharacterController movement
This state-driven architecture allowed the grappling system to use physics-based motion while
preserving the responsiveness of the CharacterController for standard traversal —
all without a full rewrite late in development.
Outcome
This hybrid system allowed the grappling mechanic to function as intended without requiring a full rewrite
of the movement architecture.
More importantly, it reinforced the importance of designing gameplay systems that remain flexible under
tight production constraints —
which was made possible through the State design pattern.