Gameplay Programming
I built train movement and routing, track placement, passenger pickup and drop-off, scoring, destruction, and the rules connecting a moving train to a player-built rail network.
Brackeys Game Jam 2025.1 · Nothing Can Go Wrong...
Train Track
Trouble
A mouse-only arcade game about laying track, delivering passengers, and keeping a moving train alive as the network gets harder to manage.
- Role
- Main Programmer · Game Designer · Asset Implementation
- Team
- 3 people
- Engine
- GameMaker / GML
- Time
- 1-week jam + post-jam redesign
- Result
- #44 / 2,155
My Work
Systems Design
I designed and tuned acceleration, delivery recovery, passenger population, rail durability, loop counterplay, and the post-jam difficulty curve.
Implementation & Polish
I integrated my teammates' art and music, built the HUD and rail-state feedback, and tuned the mouse-only interaction flow for readability.
Track Placement
The route should be the puzzle, not the controls.
In the jam build, placing one rail ended placement mode. Jam feedback repeatedly called out having to reselect track and the easy-to-miss rotation input.
I changed placement to stay active after each click. The preview reads nearby connections and open space, then suggests an orientation that fits the route.
Straights can still be manually overridden, while corners only cycle through plausible connections. The player chooses the route; the tool removes the repetitive input around that decision.
Placement logic
Read nearby track
Find valid connections
Remove blocked directions
Suggest orientation
Manual override if needed
Old
Jam Build
Manual placement
Revised
Current Build
Context-aware placement
Difficulty Curve
Pressure rises continuously, but deliveries buy time.
The map is large, and the original train moved slowly enough that players could build far ahead before it became dangerous. The jam build tried to add late-game pressure with random bombs after ten deliveries.
The bombs made the game busier, but the pressure felt disconnected from the core loop. A random attack elsewhere on the map could interrupt the player without reflecting how well they were managing the train.
I removed random bomb spawns. After the first delivery, the train now continuously accelerates. Each successful drop-off lowers its speed, buying a short recovery window before the pressure starts climbing again.
Difficulty now comes from the main objective. Players can see the danger building and earn breathing room by completing another delivery.
Build ahead
Pressure rises
Make a delivery
Breathing room
Pressure rises again
Rail Durability
The exploit was fun, so I gave it a cost.
A playtester discovered that putting the train into a loop could effectively pause the challenge. Once it was circling safely, the player had unlimited time to build the rest of the network.
My first solution was simple: make every rail break after one use. It stopped infinite loops, but it also removed one of my favorite parts of the game.
When the train is about to run out of track, an older piece can become the rail that saves the route for one more pass. Routing back onto existing track at the last second creates the messy improvisation I want from the game, and it makes every placement matter.
So rails now survive long enough to be reused, but not forever. The first traversal adds visible wear. After the second, the rail becomes critical, shakes, and breaks once the train clears it. A loop can still buy time, but it spends the track that makes the loop possible.
Other Systems
Supporting design, feedback, and implementation work.
These changes are smaller than the three systems above, but each solves a specific readability, pacing, or player-control problem.
Spawning
Dynamic Passenger Spawning
Keep enough passengers in play without making
spawning its own difficulty spike.
Problem
A fixed or random spawn rate can create two bad states: passengers pile up while the player is already overwhelmed, or the map goes quiet after several fast deliveries.
Solution
After the first delivery, the game checks the active passenger count every eight seconds. If the map is below its current target, it adds one passenger.
Why it matters
The map stays active without flooding the player. More importantly, there is usually another delivery available when the player needs to earn a speed recovery.
Legacy System
From Random Bombs to a Player Tool
Turn the old random threat into deliberate,
risky demolition.
Problem
In the legacy jam build, bombs started spawning randomly after ten deliveries. They created pressure, but that pressure came from an unrelated attack instead of the train and route the player was already managing.
Solution
I removed random bomb attacks and moved difficulty into train acceleration. Bombs still exist, but the player places them. They explode in a 3×3 area instead of deleting one precise rail.
Why it matters
I did not want track removal to become an easy undo button. A bomb can fix a bad route, but its blast may also destroy useful nearby rails. Choosing where to place one stays chaotic, risky, and strategic.
Readability
Rail Wear Feedback
Make a hidden durability rule readable while the
player is already tracking a moving train.
Problem
Durability only feels fair if the player can predict failure. A hidden use count followed by a sudden break would make the system feel arbitrary.
Solution
Each use has a visible state. The first traversal adds wear. After the second, the rail darkens, pulses, and shakes before it breaks once the train clears it.
Why it matters
Players can judge whether an old rail is worth risking before the train reaches it. I built the feedback procedurally so the rule stays readable without covering the original art or requiring new rail assets.
UI
HUD Redesign
Expose the new pacing rules without asking the
player to stop watching the track.
Problem
The new difficulty curve depends on continuous acceleration, but the original HUD gave the player no clear read on how much speed pressure was building.
Solution
I separated score, passenger capacity, and speed into clearer groups. Passenger carts show capacity directly, while the speed meter stays visible without covering the map.
Why it matters
The player is already watching the train and track, so the HUD has to work at a glance. The speed meter eases toward its current value and uses clear bands to make rising danger and delivery recovery easy to read.
Playtesting
Jam Feedback
The post-jam redesign came directly from recurring
friction and an unexpected player strategy.
Jam comments repeatedly pointed to track reselection and unclear rotation, while one player discovered the infinite-loop strategy. Those observations became the placement and durability changes above.
Read the jam comments ↗Result
#44out of 2,155 entries
#10
Audio
#13
Theme
#82
Visuals
The one-week jam build placed #44 overall. I returned to it later because the player feedback exposed problems worth solving, turning a finished jam game into a focused redesign of controls, pacing, and emergent strategy.
Play Train Track Trouble ↗Team
Train Track Trouble was a three-person jam game. George and John gave a very small mechanic far more personality than I could have built alone.
Art + Intro Animation
George Boutwell ↗
George made all of the pixel art and the opening animation. The intro is still one of my favorite parts of the game, giving a very small mechanic a surprisingly authored opening for a one-week jam game.
Music
John Johnson ↗
John created the game's immersive soundtrack. His intro composition was so strong that it inspired me to implement dynamic, alternating tracks during longer runs to prevent the audio from looping repetitively.
Programming + Design + Implementation
Harrison Alonso
I programmed and designed the game, implemented the team's art and audio, tuned the pacing, and led the post-jam redesign.
The tiny garbled passenger yells when you drop someone off are also me.
Reflection
The post-jam pass taught me that fixing one system often exposes the next problem underneath it. Better placement made the pacing weakness obvious. Stronger pacing made loops more valuable. Rail durability let me keep that strategy without letting it solve the game. The useful lesson was to treat playtest problems as connected systems, not isolated fixes.
