We Built a Track Analyzer and 2D Route Trainer for PolyTrack

A PolyTrack track can be shared as a single long string. That is wonderfully portable, but it creates an awkward gap between having a track code and understanding the track.

Before importing it into the game, a player cannot easily answer basic questions:

• Where does the route go?
• How much does the elevation change?
• Are there checkpoints?
• Which sections are likely to need braking or careful steering?
• Does the analysis tool actually understand the special parts used by the creator?

Reviewers have a related problem. They need evidence that a submitted code is complete and structurally sensible, but an automated preview must not be allowed to quietly turn into an automated approval.

We built Track Lab to serve both groups without forcing them into the same interface.

Try it here: PolyTrackCodes Track Lab

The first version taught us what not to claim

Our early prototype had two tools:

1. A decoder that could extract data from a PolyTrack2 code.
2. A small browser racer that could follow the decoded structure.

Technically, both worked. Product-wise, they were too confident.

The decoder exposed part IDs and coordinates that were useful to us but mostly meaningless to a regular player. The racer could complete a simplified path, but that did not prove that the original track was playable with real PolyTrack physics.

We also found contradictions. The estimated route time and the observed demo time could come from different calculations. One panel could report zero key turns while the map clearly showed several. Large tracks could spend too long building a practice route. The desktop version had keyboard controls, while mobile players could only watch.

The main lesson was simple:

A visualization is not the same thing as a verdict.

That sentence became the product boundary for the rebuild.

One analysis result, two user experiences

Track Lab now has two modes:

• A public player mode for understanding, learning, practicing, and sharing tracks.
• A reviewer mode inside the submission dashboard for evidence, notes, and traceability.

Both modes use the same underlying structural result. We do not calculate one “truth” for players and a different one for moderators.

A simplified version of that shared result looks like this:

{
  "verdict": "attention",
  "supportCoverage": 78,
  "unsupportedParts": [102, 118],
  "startCount": 1,
  "finishCount": 1,
  "routeCapable": true,
  "mustConfirmInGame": true,
  "analysisVersion": "2026.07.16-v1",
  "codeHash": "..."
}

The player interface turns this into plain-language route guidance. The reviewer interface adds the code version, saved notes, and a clear warning when a submission changes after it was checked.

The analysis helps a human make a decision. It never approves a submission by itself.

Track Analyzer: make the route understandable first

The public analyzer supports two starting points:

• Paste a private PolyTrack2 code.
• Select a track already published in the PolyTrackCodes library.

Pasted codes stay in the browser by default. Published tracks get stable URLs that can be shared without copying the full code.

The first screen focuses on information a player can use immediately:

• Track name, author, and environment.
• Route support percentage.
• Start, finish, and checkpoint counts.
• Height range.
• A conservative result: normal, needs attention, problem found, or unable to determine.

Notice the wording in the result above. The route structure is recognized, but the tool still asks the player to confirm jumps, height changes, special surfaces, and unknown parts in the real game.

That is intentional. “100% route support” only means that the current structural rules recognize the decoded part types. It is not a promise that we have reproduced the game engine.

A map you can actually inspect

The route overview supports:

• Zooming and dragging.
• Fitting the complete route into view.
• Switching between all parts, roads, control points, and unknown parts.
• Separating lower and upper height layers.
• Inspecting a part in plain language, with raw coordinates kept in advanced information.

The analyzer also produces an estimated height profile and calls out unsupported content instead of hiding it behind a green status.

This progressive disclosure mattered more than we expected. Most players want the route and its difficult sections. A smaller group wants part IDs, rotations, bounds, and raw decoded data. Both can get what they need without making the first screen look like a debugging console.

Review Racer: a trainer, not a physics clone

The subtitle now states the boundary directly:

2D route trainer based on decoded track structure

Review Racer can:

• Demonstrate a simplified route with Auto Coach.
• Let the player drive manually with a keyboard.
• Restart or respawn.
• Start practice from a specific sector.
• Show route progress, braking guidance, target speed, and turn-in suggestions.
• Keep a personal best in the player’s own browser.

Every automatic result uses deliberately limited language:

• Simplified route connected
• Route gap found
• Current tool cannot determine
• Confirm in the real game

You will not see “this track is playable” generated from an Auto Coach finish.

Mobile controls are part of the product

The original prototype treated mobile as a smaller display. That was not enough for a player tool.

Review Racer now provides large touch targets for steering, driving, and braking. The route remains visible above the controls, and coach feedback continues below them.

This sounds like a small UI addition, but it changed our acceptance criteria. We now test the tool as something a player should be able to use, not merely something that happens to render on a phone.

The most important performance feature is knowing when to stop

Large community tracks are valuable test cases because they expose optimistic algorithms quickly.

Instead of always attempting to build a complete trainer model, Track Lab now separates structural inspection from route training.

If a track is too large or too poorly supported:

1. The analyzer still shows the useful structural result.
2. Review Racer does not start an expensive route build.
3. The page explains that the limitation belongs to the tool, not necessarily to the track.
4. The player can still inspect the map and confirm the uncertain areas in PolyTrack.

This prevents two bad outcomes at once: a frozen page and a false “broken track” report.

The reviewer workflow keeps its history

Inside the submission dashboard, reviewers can run the same analysis without copying the code into another page.

Each saved check records:

• The analysis version.
• A fingerprint of the submitted code.
• Route support coverage.
• Unsupported content.
• Whether route training is reliable enough to open.
• Items that require a real-game check.
• The reviewer’s playtest result and notes.

When the creator submits a changed code, the old result is marked as outdated. This is important because “we checked this submission” is only meaningful if we can also answer “which version did we check?”

The dashboard remains ad-free, and the final approval remains a human action.

How we tested it

We built a fixed set of 31 real PolyTrack2 tracks covering small layouts, large layouts, missing controls, low support, and complex community tracks.

Together, those tracks contained 84,087 decoded parts.

In the current test set:

• 20 tracks produced a route that was suitable for the simplified trainer.
• 11 tracks were safely limited because they were too large or had insufficient supported route data.
• Missing-start and missing-finish cases were prevented from entering route practice.
• Desktop Auto Coach, keyboard controls, mobile touch controls, large-track protection, and ad-free tool pages were checked in a real browser.

The point of this test set is not to prove that the analyzer understands every PolyTrack component. It is to make sure unsupported cases stay visible and predictable as we add support over time.

What we learned

1. Product language is part of correctness

Changing “playable” to “simplified route connected” was not a copy edit. It corrected the meaning of the result.

2. Unknown must be a first-class state

A tool that only has pass and fail will eventually turn uncertainty into a false pass. We use four states: normal, attention, problem, and unable to determine.

3. Derived numbers need one source

Route points, sectors, hazards, turn counts, and time estimates now come from the same route result. This removes a whole category of contradictory UI.

4. Player tools and moderation tools can share logic without sharing a page

Players need route understanding. Reviewers need evidence and history. A shared result plus different presentations gives us consistency without a cluttered interface.

5. A graceful limit is better than an ambitious freeze

When the tool does not know enough, it stops and explains why. That is a feature, not a failure.

What comes next

Our next steps are deliberately incremental:

• Recognize more PolyTrack2 road and special components.
• Improve jump, gap, and multi-level route analysis.
• Compare a player’s driven line with the suggested route.
• Calibrate difficulty and practice advice with real player feedback.
• Connect track analysis more deeply with published track pages.

Community challenges, voting, and leaderboards may come later, after the analysis itself has earned enough trust.

For now, Track Lab is already useful for the thing we originally wanted: helping a player look at an opaque code and understand the track waiting inside it.

Try the tools:

• Open Track Lab
• Analyze a published track
• Open Review Racer

If you build developer tools for games, I would love to hear how you draw the line between a useful approximation and an overconfident verdict.