Gravity-flip traversal
One action that changes routing and timing decisions, letting the player “save” a run by switching tracks at the last moment.
Game Case Study
Out of Sight
Endless gravity-flip runner where you switch orientation instead of jumping, built to explore telegraphing, difficulty curves and procedural chunk design.
Overview
Out of Sight is an endless, forward-scrolling precision runner where the camera never stops moving. You only steer left and right, but you also flip gravity to switch tracks and survive gaps and hazards as the pace ramps up. The design goal was sustained tension through speed and spatial pressure, while keeping every death readable and deserved—short recovery windows, clear telegraphs, and instant restarts that make “one more run” feel natural.
Design goals
What I was trying to achieve.
-
Single, expressive input
Design a game where one simple action—gravity flip—produces interesting decisions over time.
-
Readable procedural chunks
Create modular level pieces that can be recombined without unfair, unreadable obstacles.
-
Tension curves
Use spacing, speed and obstacle patterns to alternate between calm stretches and sharp, focused sections.
My contribution
What I personally owned.
-
Mechanics & systems
Designed the gravity-flip rules, fail states and how speed ramps over time.
-
Procedural layout
Implemented modular chunks and logic for stitching them together while avoiding impossible combos.
-
Game feel & pacing
Tuned speeds, camera and timing to give players enough information to react without removing pressure.
Process & learnings
How the project evolved and what I took away.
Most iteration on Out of Sight was about fairness under pressure. In an endless runner, players retry dozens of times, so any unclear hazard, bad spawn, or timing edge case shows up immediately. I tuned readability first (minimum reaction windows, consistent silhouettes, and safe recovery beats), then used speed and spacing to raise difficulty without introducing cheap deaths.
Procedural generation needed strict guardrails—chunk-based assembly plus validation rules—so runs stayed surprising but never impossible.
Core loop
The moment-to-moment flow I focused on.
Loop
Read the upcoming track → steer into safe lanes → flip gravity to transition between tracks → recover into a stable lane → repeat as speed and density ramp up.
Controls & fail states
Movement is limited to left/right to keep inputs simple under stress. Gravity flip is the expressive action: it turns a “dead end” into a new route. Failure happens when you leave the camera bounds or miss the track, followed by an instant restart.
Key features
What’s implemented in the prototype right now.
Procedural track assembly
Modular chunks stitched together with rules so patterns stay learnable and readable, even as layouts vary run to run.
Escalating pressure
Difficulty increases primarily through camera speed and spacing, preserving clarity while tightening reaction windows.
Procedural generation & fairness
How I kept runs surprising without creating impossible layouts.
-
Chunk-based assembly
Tracks are built from hand-authored modules with clear “entry/exit” expectations, keeping navigation consistent across combinations.
-
Validation rules
I enforced constraints like minimum landing space, maximum gap length, and “no double-threat” zones to avoid unwinnable spawns.
-
Recovery windows
Patterns include brief safe beats after high-intensity moments so players can reset their position and re-read the next hazard.
What I learned
In procedural endless games, the generator is effectively a designer. If the rules are weak, players read failures as bugs. Strong constraints and a consistent pattern language make randomness feel intentional—and keep players willing to retry.
Difficulty ramp & pacing
The levers I used to increase challenge without adding noise.
Ramp levers
Speed is the primary driver. As runs progress, I adjust camera velocity, obstacle spacing, and decision density, while keeping telegraph distance above a minimum threshold so reactions remain possible.
Pattern language
I treated obstacles as a small “vocabulary” and built sequences that escalate logically (easy → mixed → tight), so players feel like they’re improving—not just surviving randomness.