Design goal
Make every portal an exciting, readable decision without breaking the flow of the race.
Intended audience
Mobile players who enjoy quick competitive races, readable controls, and unpredictable opportunities.
← All game studies
CONCEPT STUDY / Multiplayer clarity & risk/reward
Flipside Rush
Two worlds. One race. Catch a portal, adapt, and keep chasing the finish.
Design goalMake every portal an exciting, readable decision without breaking the flow of the race.
01 / PROJECT SNAPSHOT
Game Concept Statement
A competitive multiplayer mobile runner where players race through the Normal World and the mysterious Flipside, dodging obstacles, switching lanes, and catching randomly appearing portals that shift them between realities as they compete to reach the finish first.
- Genre / mode
- Competitive multiplayer mobile runner
- Stage
- Concept / design development
- Case-study focus
- Multiplayer clarity & risk/reward
- Available material
- Concept artwork & design document
The design challenge
How can unpredictable portals create anticipation without allowing randomness to decide the race?
Player promise
Two worlds. One race. Catch a portal, adapt, and keep chasing the finish.
02 / CORE GAMEPLAY LOOP
From action to experience.
- 01Race forward
- 02Read obstacles
- 03Switch lanes / jump / slide
- 04Spot a portal
- 05Catch and flip / miss and stay
- 06Adapt & reach the finish
Concept loop: the next challenge returns the player to observation and a new decision.
03 / SYSTEM DESIGN
What creates the experience.
Design intent and rules to validate in a prototype.
Persistent world switching
Catching a portal toggles the runner between Normal and Flipside; missing it preserves the current world.
Rules & design considerations
Current direction
Racers can occupy different realities at the same time. The next caught portal switches the individual player back.
What needs testing
A missed portal must never trigger an automatic transition or reset the player’s reality.
Runner readability
Keep familiar movement readable while the environment changes around the player.
Rules & design considerations
Current direction
The initial runner uses three lanes, jumping, sliding, and obstacles. Transitions should preserve momentum.
What needs testing
Portal effects and the darker Flipside presentation must not hide hazards on a mobile screen.
Portal opportunity & competitive fairness
Create anticipation through calculated, player-unpredictable portal appearances.
Rules & design considerations
Current direction
Spawn spacing, safe placement, world-specific advantages, and catch-up rules are open design questions.
What needs testing
Test why players choose a portal before assigning permanent advantages to either world.
04 / VISUAL DIRECTION
Inside the world.
Concept visuals communicate the intended experience; they are not evidence of a finished playable build.
05 / DEVELOPMENT & VALIDATION
The next playable question.
First prototype target
One short track, one runner, two environment states, portal catch/miss detection, basic obstacles, and a finish line. A ghost or bot can support early tests before production networking.
Planned playtest
Compare portal catches and misses, obstacle collisions after transitions, and players’ explanations of their current world. Later multiplayer tests should examine portal use alongside win rate.
Next design step
Prototype the portal state machine and annotate a short track. Tune telegraphing and spawn safety before adding networking, economy, or power-ups.
Evidence & iteration status
This case study currently presents concept design and visual material. Playable builds, implementation breakdowns, and measured playtest revisions are not yet included.
06 / DESIGN DOCUMENTATION
Explore the full design.
Flipside Rush GDD
GDD v0.1 / October 2026. The statement above defines the current concept direction.