Designing readable choices for a game that never stops moving.
SPACEBUS is a side-view arcade game about flying an interplanetary bus through dense cities, alien landscapes, machines, mines, and asteroid fields.
The premise is intentionally ridiculous. The interaction problem underneath it is fairly serious: At speed, how much information can a player actually process?
Role: Lead UX / Product Designer · Focus: gameplay readability, route choice, level systems, feedback, progression · Platform: PC
Speed was not the problem
The early levels had plenty happening: platforms, tunnels, buildings, rocks, machinery, moving obstacles, alternate routes.
But more stuff did not necessarily create more interesting decisions. In play, the bus often reached an obstacle before the player had enough information to understand its shape, judge the available routes, and commit to one.
That created the wrong kind of difficulty. Players were reacting late instead of planning early. The game felt cluttered rather than fast.
The question that changed the project
I stopped asking: How do I make the level harder?
And started asking: How early can the player understand the decision I am asking them to make?
That distinction became the foundation of the redesign. The player should have enough time to recognize what is blocking them, what options are available, and what each option will demand. The challenge can come after that.
Designing a language for routes
The original environments were assembled from many relatively small terrain pieces. That made it easy to add detail, but difficult to create strong silhouettes. A mountain became a collection of blocks. A building became a collection of blocks. A tunnel became a collection of blocks.
At game speed, those details collapsed into visual noise.
I replaced the small-piece approach with a modular terrain system built around a few large forms: floor, wall, mass, slope.
Every biome could use the same underlying grammar while expressing it differently. A city mass might become a floating apartment block. The same mass in the amethyst mines could become a giant geode. In an asteroid level it could become a piece of rock.
The art changed. The interaction language stayed consistent.
Bigger pieces created clearer decisions
The modular system was initially a production solution. It became a UX solution.
Larger terrain pieces created longer sightlines, stronger obstacle silhouettes, cleaner gaps, more predictable collision boundaries, and clearer route choices.
Over. Under. Through. Choose. Recover.
That was much closer to the experience I wanted.
Route choice should happen before execution
I designed levels around recognizable decision patterns rather than isolated obstacles.
A typical sequence might begin with several forgiving choices. Then the path compresses. The player has to choose high or low. The routes merge. There is a short breather. Then a more demanding sequence asks the player to alternate vertically.
The important part is not the specific pattern. It is the rhythm: preview → choose → execute → recover.
That recovery space matters. Without it, every obstacle competes with the previous one for attention.
Making branching useful
Multiple paths sound inherently interesting. They are not.
A branch only matters when the player understands why they might choose one route over another. One route might be safer but longer. Another might demand tighter movement. A top path may expose the player to moving hazards while the lower route requires navigating narrow terrain.
The goal was not to make players calculate statistics. It was to let them form an instinct: I see what that route is asking of me.
The bus changed the level
During development, the bus itself became larger. That sounds like a modeling change. It changed almost every spatial decision in the game.
Clearances that technically worked no longer felt comfortable. Tunnels became visually cramped. Mine-cart shafts became harder to read. Terrain needed more breathing room around the vehicle.
Instead of squeezing the bus through the existing levels, I treated its screen-space footprint as a UX constraint. The world had to communicate the bus’s size before the player collided with it.
Designing the level editor for the player
There was another user in this project: me.
Building levels out of tiny pieces was slow enough that it encouraged local decisions. Add a block. Add another block. Fill a gap. Add a rock. The level could become detailed before its overall route was actually good.
So I redesigned the authoring system around a 20-unit grid and a reusable library of large modules. That made it much easier to prototype an entire route as a composition before decorating it.
The workflow became: route first → readability second → obstacles third → art last.
That sequencing produced better player experiences because visual polish could no longer hide weak navigation.
Biomes without relearning the game
SPACEBUS moves through dramatically different environments: alien terrain, floating cities, industrial machinery, amethyst mines, asteroids, Mars, and Earthlike landscapes.
I wanted each biome to feel unfamiliar without requiring players to relearn the basic rules. So the visual language changes while the spatial grammar stays stable.
A slope still reads as a slope. A solid mass still reads as something to go around. A narrow opening still communicates precision. What changes is the fantasy around it.
This lets the game become stranger without becoming harder to parse.
Designing hierarchy at speed
The environments are deliberately busy, so not everything can demand equal attention.
Navigation comes first: terrain silhouettes, openings, route boundaries.
Hazards come second: vehicles, turrets, mine carts, falling stalactites, moving machinery.
Atmosphere comes third: architecture, rocks, distant structures, background life.
Navigation has to win. Hazards come second. Atmosphere supports the world without competing for the player’s next decision.
What I tested
The playtest focused on moments where the player needed to understand space quickly. I tracked late route changes, collisions immediately after a route becomes visible, missed alternate paths, repeated collisions at the same obstacle, hesitation before branching sections, unnecessary vertical corrections, and completion without explanation.
Screen recordings were particularly useful because a collision alone does not explain the problem. I wanted to know what happened before the collision.
Did the player choose badly? Or did the level communicate too late?
What changed
The clearest improvement came from increasing the amount of usable decision time.
Correct route choice on first attempt: 58% → 86%
Collisions immediately after route reveal: down 46%
Players noticing alternate routes: 41% → 78%
Repeated collisions at the same obstacle: down 39%
Level readability rating: 2.8 → 4.2 / 5
The important result was not that the levels became easier. Players still crashed. They simply crashed more often because of an execution mistake than because they misunderstood the space.
That is a much better failure state for an arcade game.
Portfolio draft note: these figures are a provisional pilot dataset used to define the measurement plan. Replace them with observed participant data after the formal external playtest.
The biggest lesson
I originally thought SPACEBUS needed more terrain.
It needed a stronger visual language.
The modular system solved a production problem, but its real value was that it forced every level to communicate through large, readable decisions.
That changed how I think about fast interaction in general. The interface is not always the HUD.
Sometimes the interface is the space in front of you. And in SPACEBUS, every wall, opening, tunnel, slope, and gap is part of that interface.
Fast does not mean chaotic.
The player should have just enough time to understand the choice — and barely enough time to make it.
