How to Submit a PolyTrack Code That Gets Approved

Submitting a track is more than pasting a code

PolyTrackCodes accepts community track submissions through the Submit Your Track page. The goal is simple: help good custom PolyTrack maps become clear, playable, public track pages that other players can trust.

But a strong submission is not just a working code. It needs enough context for reviewers to understand the track, enough visual information for players to preview it, and enough accuracy that the final page does not mislead someone who is deciding what to play next.

This guide explains how to submit a track, what kind of submissions are most likely to pass review, what usually blocks approval, and what happens after you click submit.

Before you submit: test the track yourself

Before opening the form, import your own code back into PolyTrack and drive the track at least once from start to finish.

This quick check catches the most common problems:

• The code was copied incompletely.
• The track does not load in the current version.
• The start, checkpoints, or finish are missing or broken.
• The difficulty feels very different from what you planned.
• A jump or landing that seemed fun in the editor is unreliable in a real run.
• The submitted version is not the final version you meant to share.

If the track cannot be imported, reviewers cannot approve it. If the track imports but feels unfinished, it may need revision before it becomes a public page.

What the submit form asks for

The submission form asks for the information needed to build a useful public track page.

The required fields are required for a reason. They are not just form rules; they are the basic information needed to review and publish a track responsibly.

Email is required, but it is not public

Email is required so we can send the result of the review. It is not displayed publicly on the track page.

We may use it to send:

• The published track link if your submission is approved
• A revision note if the track needs changes
• A short rejection reason if the track is not a fit

Use an email address you can actually receive. If your email is invalid, the form will not accept the submission.

The overview image matters a lot

Every new submission needs a full track overview image. The best image is a zoomed-out editor screenshot that shows the entire layout.

A good overview image should:

• Show the whole track, not only the starting area
• Be taken from the editor or a top-down view when possible
• Make the route shape readable
• Include enough visual context for players to understand the layout
• Be clear enough that the track does not look like a random close-up

The overview image should not be:

• A driving-camera screenshot
• A cropped image of only the car
• A blurry preview
• A random thumbnail unrelated to the track
• A placeholder or default image

Players often decide whether to import a track by looking at the preview first. A strong overview image makes your track easier to trust.

Choose the right difficulty

Difficulty should describe the real driving experience, not the creator's personal skill level.

Use this rough guide:

Overrating a track can scare away the right audience. Underrating it can frustrate new players. The best rating is honest.

Pick the category that describes the main experience

The category should tell players what kind of track they are about to play.

• Racing: Standard route, corners, flow, and lap-style driving
• Speedrun: Built around time optimization, fast lines, and repeatable runs
• Drift: Sliding, angle control, and linked corners are central
• Stunt: Jumps, loops, flips, wall rides, or spectacle sections
• Technical: Precision, narrow paths, difficult turns, or control training
• Art: Visual design or creative layout is the main point
• Tutorial: Built to teach a mechanic or help new players practice

If a track has multiple elements, pick the one that defines the experience. A racing track with one jump is usually still Racing. A jump-heavy route where landing is the whole challenge is probably Stunt.

Write a useful description

A good description helps both reviewers and players. It does not need to be long, but it should be specific.

Weak description:

Cool track. Try it.

Better description:

A medium racing track with two fast tunnel sections, a downhill jump after checkpoint 3, and a tight final chicane. Brake early before the last corner if you want a clean finish.

Try to include at least two concrete details, such as:

• What kind of route it is
• The hardest section
• A driving tip
• Whether it is beginner-friendly or built for experienced players
• Any unusual mechanic, shortcut, or theme
• What changed if this is an updated version

Specific descriptions make approval easier because reviewers can compare the submitted text with the actual track.

If this is an update, explain what changed

If you are improving a previously submitted or published track, choose the update option.

For updates, include:

• The original track link or title
• What changed in the new version
• Whether the difficulty changed
• Whether checkpoints, finish, jumps, or route shape changed
• Why the new version is better

Good update note:

Fixed the landing after checkpoint 3, widened the final chicane, and changed the difficulty from Hard to Medium because the new route is more forgiving.

This helps reviewers compare the new code against the earlier version instead of guessing.

What reviewers check

After a track is submitted, reviewers look at both the form details and the track itself.

The review usually includes these checks:

1. Import check: Does the code load correctly?
2. Basic structure: Does the track have a usable start, route, checkpoints, and finish?
3. Title and author: Is the creator credit clear and reasonable?
4. Description match: Does the description match what the track actually does?
5. Difficulty match: Is the selected difficulty fair?
6. Category match: Is the track in the right browsing group?
7. Overview image: Is the submitted image a real full-track preview?
8. Duplicate check: Is this original, or is it too similar to something already published?
9. Playability check: Does the track feel like a real playable submission rather than a fragment?
10. Policy check: Is the content appropriate for a public community library?

Some tracks also get a deeper review through internal tools such as the decoder and review racer. Those tools help inspect route shape, checkpoints, preview quality, and possible risk sections before a final decision.

What makes a submission more likely to pass

Strong submissions usually have these traits:

• The code imports cleanly.
• The track can be finished.
• The title is readable and not random characters.
• The description names real parts of the track.
• The difficulty is honest.
• The category matches the actual gameplay.
• The overview image shows the full layout.
• The route has a clear idea, not just random blocks.
• The track is original or clearly improved from an earlier version.
• The submission includes enough information that the final page can help other players.

The review is not only about whether the track is hard or beautiful. We care about whether the final public page will be useful.

Common reasons submissions do not pass

Submissions may be declined or sent back for revision when:

• The code cannot be imported.
• The overview image is missing, cropped, or not a full-track view.
• The title is unclear or looks like spam.
• The description is too vague to help players.
• The selected difficulty is far from the actual experience.
• The selected category is misleading.
• The video link is not a public web URL.
• The submission is a duplicate or too similar to an existing track.
• The route is unfinished, broken, or only a fragment.
• The track uses inappropriate or policy-violating content.

If your track is declined, that does not always mean the idea is bad. Often it means the submission needs a cleaner code, a better overview image, clearer notes, or a more accurate difficulty rating.

What happens after approval

Approval is not the final step by itself. We separate the workflow so public pages do not go live half-finished.

The normal path looks like this:

1. The submission is reviewed.
2. If it is approved, the track record is prepared for publication.
3. The public track page is checked online.
4. The image and detail page are confirmed.
5. A result email is sent to the submitter.

This separation matters. A track can be approved internally but still need online confirmation before we send the final published link.

When everything is confirmed, the creator receives a link to the public page. That page can then be shared with other players.

How long review takes

Review time depends on the current queue and the quality of the submission.

A clean submission is faster to review because the important pieces are already there: working code, clear image, useful description, accurate category, and valid email.

A messy submission takes longer because reviewers may need to decode the track, test it, inspect whether it is a duplicate, rewrite unclear information, or decide whether to request changes.

How to submit a better second version

If your first version needs changes, submit an improved version instead of sending the same code again.

Before resubmitting:

• Fix the issue mentioned in the review note.
• Import-test the new code.
• Capture a fresh full-track overview image.
• Choose the update option.
• Include the original title or link.
• Explain exactly what changed.

A clear update note helps reviewers move faster and gives your improved version a better chance.

Final checklist before you submit

Use this checklist before clicking submit:

• I tested the code by importing it myself.
• The track can be finished.
• The title is readable.
• The author name is how I want to be credited.
• My email is valid.
• The description explains the actual track.
• The difficulty is honest.
• The category matches the main gameplay.
• The overview image shows the full layout.
• The video link, if included, starts with http or https.
• If this is an update, I explained what changed.

If you can check all of those, your submission is much easier to review and much more likely to become a useful public track page.

Ready to share your track? Start here: Submit Your Track.