Traffic systems look simple until you build one. Two roads, one intersection, obvious right answer — and then every player does something you did not anticipate.
The first twenty minutes decide everything
When I looked at where players quit, it was never the hard levels. It was the third or fourth decision, when the game had introduced enough systems that the player could no longer hold them all at once.
The fix was not a tutorial. It was removing a system from the early levels and reintroducing it later, once the first one was automatic.
Teach one variable at a time
A beginner guide has the same problem as a beginner level. If it explains cost, throughput, and layout in the same paragraph, the reader retains none of them.
What worked:
- One decision per section. Cost first. Then throughput. Then layout.
- Name the failure, not the rule. "Players build the long route first and run out of budget" teaches more than "budget matters".
- Say what to ignore. Half of a beginner's anxiety comes from systems they do not need yet.
The metric that mattered
Not time on page. Whether the reader took one more action — built the thing, tried the layout, came back the next day.
That changed how I wrote. Instead of explaining the whole system up front, every section ends with one concrete thing to try, and the next section assumes they tried it.
Write the guide as a sequence of decisions
If you are writing a beginner's guide for a systems game, structure it like the game structures its levels: one new variable at a time, a named failure mode, and a reason to keep going.
Notes from building and rebuilding the same traffic sandbox three times.
Top comments (0)