City Map
Compressing Auckland into a recognisable game-sized region, while protecting its coastline and important shapes.
City Map is an experiment in turning a real city into an authored region for GTA V and FiveM. Auckland is the development region, with Melbourne used to test whether the process transfers. The ambition is a recognisable city whose regional travel distances fit inside a much smaller game space.
The implemented work is geographic tooling: align source layers, assign importance, redistribute space and inspect the resulting coastlines and shapes. It is not yet a city generator, a game exporter or a playable map. The project is shown through a workflow illustration rather than unverified map imagery.
Highlights
- Repeatable geographic layer alignment
- Density-based compression and shape refinement
- Auckland development with a Melbourne transfer test
In action
A real city, with shorter journeys
The idea behind City Map is to make an authored game region feel like a real place without requiring its real travel distances. Auckland supplies the development geography. Its coast, centres and relationships need to remain recognisable, while the region fits into an approximately seven-by-eleven-kilometre composition for GTA V and FiveM.
This is a spatial-compression problem before it is a game-building problem. The intended approach shortens regional distances while retaining the ordinary scale of buildings, roads and objects. That requires deciding where space is valuable and where it can be compressed, rather than simply shrinking a map uniformly.
The layers have to agree
The implemented tools begin with alignment. Source geography is rotated and registered so land, importance and coastline layers refer to the same region. A bitmap palette defines the meaning of different cells, and conversion and validation tools turn that representation into repeatable inputs for the next steps.
Those contracts matter because a convincing result cannot emerge from mismatched coordinates. The project records the source placement and layer relationships explicitly, then checks them. Melbourne is used as a transfer fixture, helping test whether the workflow describes a process that can be repeated beyond the original Auckland composition.
Compression follows importance
A density-based warp redistributes space according to the importance assigned to different parts of the region. Areas that need room can retain more of it, while lower-priority distances compress. The result is a transformation to inspect, with transport and mesh checks making the spatial changes visible and testable.
Protected shapes then need more attention. Auckland's coastline is part of its identity, so shape refinement and comparison tools examine what the warp has preserved or distorted. The work is an iterative negotiation between compact geography and recognisable features, with source alignment and coastal review documented alongside the implementation.
The current result is a pipeline
The first implementation work dates to October 2026. The repository currently contains Python geographic tooling, asset contracts and development reviews. It does not yet generate a complete city, export a RAGE environment or provide a playable game map. Those are later stages of the intended project.
The portfolio visual explains that process. The repeatable treatment of layers, density and protected shapes is the useful result so far. Recording the inputs and checks makes it possible to compare iterations, see where a coastline moved and understand why a composition changed. That provides a foundation for building the city, with the geography decisions available to revisit as the game environment develops.