THE MAP IS
THE LEVEL.

LAST REVIEWED · 12 OCT 2026 · INDEPENDENT EXPLAINER

A real-world driving game sounds like a simple pitch: take a map, add a car, drive. In practice Hop.Earth makes one design choice that changes almost everything else — the place you select is the level, and that level is generated rather than authored.

It is not a map viewer with a car on top.

The project's public development notes describe roads, intersections and physical meshes being generated from road-curve data as players move through a selected location. The goal is a drivable world, but early access means each area can still behave differently.

1. 01

   Select a place

   Location choice is part of the experience: a dense city, a coast, or a familiar local route each creates a different first drive.

2. 02

   Load nearby roads first

   Development updates describe a tile-based approach that starts with nearby terrain and roads, then continues generation as you move.

3. 03

   Expect an evolving result

   Generated intersections, terrain and physics make this distinct from a hand-authored track—and also explain why a practical troubleshooting checklist matters.

How a chosen place becomes a drivable world.

Two ideas from the public notes explain most of what you will see on screen. The first is that geometry is derived from road-curve data: rather than placing pre-made buildings and junctions, the project builds road surfaces, intersections and physical meshes from the shape of the roads in the chosen area. The second is that loading is tile-based. Generation begins with the terrain and roads near you and extends outward as you drive, which is why a new area can look finished in one direction and still filling in behind you.

Together those two choices produce a specific feel. A familiar city can arrive convincingly enough to navigate by landmarks, while a stretch you know well may still resolve differently at the level of an individual junction or kerb. That gap between a real place and its generated version is the defining trait of this kind of driving game, and it is worth understanding before you decide an area is broken.

What “real-world” does and does not mean here.

Real-world means the input is a real location, not that the output is a survey-grade replica. Public developer notes discuss OpenStreetMap paths and terrain-elevation sources as the raw material, which sets both the strength and the ceiling of the result: the road network can be recognisably right while buildings, signage, road markings and surface detail stay generic or absent.

The same distinction applies to comparisons with navigation products. Hop.Earth is not affiliated with Google Maps, and it is not trying to reproduce street-level imagery. If you want to understand where the road data itself comes from, the road data explainer covers how map paths become driving geometry, and the gameplay overview covers the location-to-drive loop that wraps around it.

Why early access changes what to expect.

Generated worlds fail differently from authored ones. A hand-built track either loads or it does not; a generated location can load partially, prioritise the wrong tile, or produce an intersection that is drivable but odd. That is why the useful question in early access is not “is this area accurate?” but “did this area generate well enough to drive?”

It also explains why checklists matter more than opinions here. A blank scene, a slow first load and a missing vehicle look like three different problems and are usually one of two: loading, or session state. The not-working checklist separates those, and a first drive is easier to judge once you have decided which category you are in.

How to test your own area without over-claiming.

Testing a local area is the most interesting thing you can do with a game like this, and it is easy to do badly. Pick one place, drive a short objective with a visible finish, and record what actually happened: start point, finish point, whether the road network held together, and where it did not. Change one variable — location, browser or device — between attempts so that a difference means something.

Be equally careful about the conclusion. A single successful drive in your own city does not establish that the area is fully supported, and a single failed one does not establish that it is unsupported. On this site the same standard is applied to the Route Lab records: each is labelled with its evidence type, and a planning record stays marked as not drive tested until a documented start-to-finish attempt exists. If you want to plan a first deliberate route rather than improvise, start with the first-drive guide and treat any planned route as a hypothesis to test.