Buried city map design: building navigable lost-city levels
Any level designer sketching a buried city map runs into two problems on the first day. The first is layout: which streets, plazas, and chambers connect, how vertical layers stack, and how the player builds a single mental model of the space. The second is presentation: how that layout becomes legible inside a 3D engine, on a hand-drawn journal page, on a UI minimap, or on a fast-travel screen. Both problems show up on every lost-city project, and both reward the same discipline. Design the map as data first, then decide how the player will see it.
This guide focuses on the GameDev side of that process. It walks through the layout decisions that affect navigation, the technical work needed to make a buried city map readable in-engine, the trade-offs between hand-painted and procedural approaches, and the QA passes that catch the worst navigation failures before a build reaches players. Whether the project is a single-player adventure, an extraction shooter set among toppled temples, or a survival sandbox under volcanic ash, the underlying layout logic stays similar, and the failure modes look surprisingly alike across genres.
Defining the buried city map as a data structure
Before a single wall is modelled, the buried city map has to exist as a navigable graph. Designers can draw it on paper first, but the engine does not read paper. It reads nodes and edges, room volumes, portals, and metadata. Choosing the right abstraction early prevents the most common disaster: a beautiful level where the player gets lost because the data underneath it was never coherent.
The minimum useful structure is a set of cells, where each cell represents a space the player can stand in, plus the portals that connect those cells. Add vertical layers for rooftops, sewers, and catacombs, then add choke points, landmarks, and resource nodes. Once those primitives exist, navigation, streaming, and minimap rendering all become downstream problems rather than separate design crises.
Cells, portals, and layers
A cell is a convex space bounded by walls, with one or more portals leading to neighbouring cells. A buried city map is rarely one cell. It is usually dozens or hundreds of cells stacked across three or four vertical layers: the surface streets, interior courtyards, collapsed lower districts, and the catacomb or sewer network beneath. Defining cells explicitly lets the team answer navigation questions with data, not with guesses.
Portals deserve their own metadata. A door that always opens, a collapsed arch the player has to clear, a flooded passage that opens later in the story, and a ladder up to a rooftop are all portals, but they have very different gameplay effects. Tagging portals with conditions during the layout phase saves a lot of refactoring once scripting, AI, and streaming rules are layered on top.
Landmarks, anchors, and choke points
Players do not navigate using the cell graph. They navigate using landmarks. A buried city map needs obvious anchors: a half-buried obelisk, a temple with a cracked dome, a tilted aqueduct, a central forum. Place at least one landmark visible from every major approach. Choke points are the opposite: narrow passages that funnel the player. The best level layouts place landmarks near choke points so the player’s mental map stays clear after every fight, scripted event, or loading screen.
Layout patterns that survive player testing
Most successful buried city maps use a small number of repeatable patterns. They are not a style guide; they are a checklist of shapes that have been tested against real player behaviour across many projects. Layering them inside a single city, rather than committing to one pattern, is what makes the level feel like a place rather than a diagram.
- Hub-and-spoke around a forum. A central plaza with four or five major streets radiating outward, each street ending in a sub-district with its own identity. Easy to teach, easy to expand with DLC.
- Layered colonnade. Long covered walkways stacked over sunken markets, with vertical drops that double as combat arenas and traversal puzzles.
- Branching catacomb network. A grid of tunnels under the city, with light and risk increasing as the player moves away from known entrances. Best when paired with a contrasting upper city that looks orderly.
- Ringed sanctuary. A circular sacred district enclosed by a wall, with one or two breach points. Strong for boss arenas, rituals, and set-piece story moments.
- Hidden civic spine. A straight service corridor (aqueduct, maintenance tunnel, noble’s passage) connecting major districts out of sight. Useful for fast travel and stealth routes.
Combining two or three of these patterns within a single buried city map gives the player texture without forcing the team to invent a new architecture every district. The pattern also helps the art team: if every district has a forum, a colonnade, and a sub-level, the modular kit list becomes manageable, and the visual language of the city stays coherent.
From paper blockout to engine data
Paper blockouts are useful, but they must be translated into engine data before any unique art is modelled. The translation step is where most buried city map projects lose time: a beautiful paper plan becomes a navigation headache because the cells were never marked, the portals were never tagged, and the streaming volumes were never drawn. Spending a day on that translation saves weeks of rework later.
The translation is also the moment when the layout’s assumptions are exposed. A street that looked fine on paper turns out to be fifteen metres wide, which doubles the player’s sprint time and breaks pacing. A courtyard that should host a boss fight turns out to have three sight lines into adjacent rooms, which makes the encounter trivial. Catching these problems on a greybox build, with collision turned on and art turned off, is the highest-value QA pass a buried city project can do.
Streaming, memory, and load boundaries
Open-world or semi-open city levels live or die by streaming. Designers should mark streaming cells on the same diagram used for navigation. Each streaming cell should contain a stable set of meshes and a clear unload trigger, so the engine can predict memory pressure. A buried city map is particularly tricky because vertical layers, interior rooms, and catacombs all demand their own streaming rules. The designer’s job is to keep those rules boring: predictable, evenly sized, and easy to debug from a single diagnostic overlay.
AI and encounter placement
Encounters are not decoration. They are part of the buried city map. Every combat or stealth space needs at least two entry points for the player, at least one flanking route for enemies, and a defined retreat. Marking encounter zones explicitly on the navigation graph prevents the common failure where a beautifully lit plaza feels empty in playtest because the AI was never given a reason to use it.
Drawing the buried city map for the player
The internal data structure is invisible to the player. What they see is a combination of in-world signage, journal art, a UI minimap, and possibly a hand-drawn map that fills in as exploration progresses. Each of these layers should be designed against the same underlying cells, or the map will contradict itself.
A useful test is to print the navigation graph next to each player-facing map. If the in-world journal shows a street that the navigation data treats as a dead end, the player will eventually notice, and trust in the map collapses. Consistency between layers is what makes a buried city map feel like a real document of a real place, rather than four different maps that happen to share a name. The Wikipedia entry on The Buried City offers a useful comparison point: the way a real-world lost site is reconstructed on paper versus how it is read by visitors in the field.
Hand-painted versus procedural cartography
Hand-painted cartography gives the strongest identity. An artist can suggest depth, ruin, and atmosphere in a way that procedural generation rarely matches. The cost is iteration: every layout change requires redrawing. Procedural cartography, generated from the navigation data, is cheap to update and stays accurate, but it can feel sterile. Most teams use both: a hand-painted overview map for menus and loading screens, and a procedural minimap for live gameplay, with the procedural layer styled to match the painted one.
Whichever mix is chosen, the input data should be the same navigation cells, not a separate set of shapes. A common mistake is to give the UI team a different map file from the level team, then wonder why the icons drift as the level is edited. Treat the navigation graph as the single source of truth and derive every other representation from it.
Icons, fog of war, and named regions
Icons should map to gameplay, not to art preference. A door icon, a save point, a vendor, a fast-travel node, and a quest objective all need distinct, readable shapes. Fog of war should reveal at the cell level, not pixel by pixel, so the player can see district boundaries. Named regions should match the names used in dialogue, quest text, and achievements. A buried city map that calls a district the Temple of Ash in the journal but the Old Quarter in the quest log creates a small but persistent confusion that erodes trust.
Fast travel, waypoints, and the cost of skipping
Fast travel is a design tool, not just a convenience feature. In a buried city map, fast travel shapes how the player experiences scale. Unlocked fast travel from the start turns the city into a series of disconnected arenas. No fast travel at all turns exploration into a slog once the player has seen each district once. The interesting design space is between those extremes: limited, conditional, or risky fast travel that rewards the player for choosing it but does not punish them for walking.
Common fast-travel conditions
Buried city projects tend to converge on a small set of fast-travel conditions. They are worth listing because each one implies a different layout discipline.
- Discover and unlock. Player must physically reach a node before it can be used. Encourages full exploration before convenience.
- Cost-based. Each use consumes a resource, such as a consumable map, a coin, or a stamina charge. Encourages walking for minor trips.
- Risk-based. The player can fast travel but arrives at a random nearby node, or arrives with reduced health. Discourages abuse during combat.
- Story-gated. Fast travel expands as the story unlocks new routes, which lets the layout grow across acts without breaking pacing.
- Layered. Surface and catacomb networks have separate fast-travel maps, so a player who has explored only the surface cannot skip past a story-locked lower section.
The buried city map must be designed with the chosen fast-travel model in mind. A layout that depends on long, atmospheric walks between districts collapses if fast travel becomes too cheap; a layout that depends on quick combat resets collapses if fast travel is too expensive. Choose the model early, then test the layout against it.
Verticality, sight lines, and the readability budget
Verticality is the easiest way to make a city feel buried. A sunken forum two storeys below the current street level, a rooftop reachable by a half-collapsed tower, a sewer accessible from a basement that also opens onto a cliff path. Each of these vertical moves is a navigation decision the player has to make, and each one is a sight line the camera has to handle. Designers and camera programmers should review the buried city map together before greybox is locked.
Readability has a budget. The player can hold a small number of landmarks in working memory at once: usually three to five. Every additional landmark competes for that budget. When the budget is exceeded, the player starts using arbitrary cues, such as the colour of a wall, which makes later navigation unreliable. Audit the map for landmark count per district and trim anything that is not load-bearing.
Sight lines, cover, and combat readability
Long sight lines feel impressive but create combat problems. A player at one end of a colonnade can see enemies at the other end, but the AI may not have a path to reach them, which leads to confused behaviour. Long sight lines also create audio bleed, where distant encounters bleed into the current one and erode tension. The remedy is the sight-line break: a deliberate column, arch, or turn that interrupts a long view without breaking the player’s sense of the space.
Lighting, atmosphere, and the buried feeling
A buried city map is as much an atmosphere problem as a layout problem. Ash, sand, dust, and water all change how the player reads a space. The lighting team needs the layout data as much as the art team does, because lighting decisions follow the navigation graph: a street with three portals and a landmark wants different lighting treatment from a sealed tomb with a single entrance.
Atmosphere also has a cost. Heavy volumetric fog, dense particle systems, and global illumination updates can crush frame rates on the hardware the team is targeting. The layout should support, not fight, the atmosphere budget. Open courtyards where the camera can see the sky are cheaper than enclosed corridors lit by a dozen dynamic lights. Plan for the worst case: a district with continuous rain, dust storms, and torchlight on every NPC.
Sound design and spatial audio
Sound is what turns a layout into a place. Distant wind across a forum, the drip of water in a catacomb, the echo of footsteps on a stone stair, the hum of an old civic generator: each of these needs a source placed in the navigation graph. When the player walks away from a sound source, the engine has to know which cell the player is in to apply the right occlusion and reverb. That knowledge comes from the same cells used for streaming, navigation, and minimap rendering, which is another reason to keep one graph as the single source of truth.
Production pipeline and asset ownership
Buried city projects tend to share a production pattern: a small design team produces the layout, a larger art team fills it, an audio team brings it to life, and an engineering team keeps the technical layer coherent. Each group needs a clear owner for the buried city map data, and each group needs a way to read the latest version without breaking the others. A version-controlled graph file, exported into engine formats on build, is usually the most reliable setup. A book review such as the Times piece on The Buried City is a useful reference for how writers and editors coordinate on a single document, and the same coordination model applies to a level team working from one shared graph.
Modular kits and district identity
A buried city map covers a lot of unique geometry. To keep the art budget sane, teams build modular kits: reusable wall sections, column variants, floor tiles, doorway frames, balcony pieces, and rubble sets. Each district picks from a shared kit, then layers unique set pieces on top. The trade-off is that too much reuse makes districts feel identical, while too little explodes the art budget. Aim for at least one or two unique landmarks per district and let the kit do the rest.
Naming, file structure, and review discipline
Review discipline is where buried city projects go wrong. A cell renamed in the design tool but not in the export script leaves the minimap pointing at empty space. A streaming volume tweaked for memory but not updated in the navigation graph creates a soft lock. The remedy is a checklist used on every review pass: navigation, streaming, AI, audio, lighting, quest triggers, and player-facing maps. Running through the list catches the cross-discipline bugs that a single discipline review will miss.
Common navigation failure modes in buried city maps
Player testing tends to surface the same handful of failure modes across very different projects. Listing them is useful because each one has a known cause and a known fix, and the team can audit the buried city map against the list before external playtesting.
| Symptom | Likely cause | Where to look in the data | First fix to try |
|---|---|---|---|
| Player gets lost in a district they have already visited. | Landmark budget exceeded, or landmarks are visually similar. | Landmark list per district; cell screenshots. | Replace one repeated landmark with a unique anchor and adjust lighting on both landmarks so they read differently. |
| Player cannot find a quest objective even with a waypoint. | Waypoint points at a non-walkable cell, or to a cell on the wrong layer. | Quest trigger data, navigation graph, layer tags. | Re-tag the objective cell with the correct layer, then re-export the minimap and quest data. |
| AI enemies cluster in one room and ignore the player. | Encounter zones do not have a path to the player’s current cell. | Encounter zone data, AI navigation mesh, portal conditions. | Open a second portal, or add a flanking route, then re-test with the AI debug overlay on. |
| Streaming hitch when crossing a district boundary. | Streaming cell sizes are uneven, or unload triggers fire too late. | Streaming volumes, memory overlays, frame-time captures. | Split the larger cell, then bias unload triggers to fire one cell earlier than the visual boundary. |
| Audio does not change when entering a new district. | Audio zones are not aligned to navigation cells, or reverb snapshots are missing. | Audio zone data, navigation cell tags. | Re-tag audio zones against the navigation graph, then verify in engine with the audio debug view. |
This is not an exhaustive list, but it covers the failures that show up most often in buried city projects. A team that runs the list on every major build will catch the majority of navigation problems before they reach external testing.
QA passes specific to a buried city map
Standard bug triage misses a lot of buried city problems. A QA pass designed around the map’s specific failure modes catches more. The pass does not need to be long, but it does need to be systematic: the same tester follows the same route, on the same build, with the same debug overlays.
A repeatable pre-release route
The route should cover every fast-travel node, every quest-critical cell, and at least one path between each pair of major districts. The tester records: time to reach each landmark, any soft locks, any pathing oddities, and any visual contradictions between the in-world signage and the minimap. Running the route on multiple hardware targets catches streaming and lighting problems that desktop-only testing misses. The route also doubles as a stress test for save and load: many buried city bugs hide in the transition between fast travel, save, and resume.
Accessibility and player guidance
Accessibility is part of the layout, not a layer on top. Players with reduced vision rely heavily on audio cues and contrast. Players with mobility considerations need to know which routes avoid climbing or jumping. A buried city map should expose this data to the game’s accessibility options: a contrast toggle, an audio cue toggle, and a high-contrast icon set. The navigation graph can carry the data, and the minimap and in-world UI can render it. When the data is not in the graph, the team ends up hand-tagging every accessibility feature, which is unsustainable for a project of any size.
Working with archaeological reference without copying it
Many buried city projects draw on real archaeological sites for visual reference. The aim is to capture the feel of a real place without reproducing a specific site’s protected features, and to avoid implying an official connection to a real heritage site. Treat reference material as inspiration for proportion, material, and wear, not as a kit to copy. A book review of The Buried City in The Times describes how writers have approached this kind of material, and the same discipline of synthesis rather than reproduction applies to level design.
Real-world reference also helps with historical plausibility. Drainage gradients, street widths, and the placement of civic buildings all follow patterns in real cities. Borrowing those patterns gives the buried city map a quiet sense of correctness that players feel without naming. The team should document the references used and the liberties taken, so future patches and DLC stay consistent with the original research.
Performance budgets and the cost of detail
Detail has a cost, and a buried city map is where that cost accumulates. Every extra column, every unique rubble set, every dynamic light on a flickering torch shows up in frame time and memory. The design team should know the budget for the target hardware, and the layout should fit inside that budget before art is added. A useful discipline is to lock the layout in greybox, profile it, then spend the performance budget on art in order of player visibility. Decorative set pieces in the player’s peripheral vision cost less than landmarks in the player’s focus area.
Memory follows the same logic. A buried city map can easily run into several gigabytes of texture and mesh data if the art team is not careful. Streaming cells help, but they do not save a project that has too much unique content. Track unique content per cell during art production, and review the totals at every milestone. A cell with three times the average unique content is a cell that will hurt the project in late production.
Live operations and post-launch map work
Even a single-player buried city map gets patched. Bug fixes, balance changes, new quests, and DLC all require changes to the navigation data. Without a clear change process, those updates create drift: a new quest points at a cell that has been removed, a DLC district sits on top of an old streaming cell, the minimap lies. The process should treat the navigation graph as a shared asset, with the same review discipline used for any other shippable system.
Post-launch work is also where the buried city map earns its keep. A well-designed level supports new content without re-architecture. A new district slots into an unused street, a new fast-travel node plugs into an existing hub, a new catacomb section extends the existing sewer network. The opposite is also true: a level designed without those hooks becomes a straightjacket, and every patch becomes a redesign.
Player-facing decisions buried in the data
Players do not see the data structure behind a buried city map, but they feel the decisions it encodes. A level that respects the player’s time, that explains itself through landmarks, and that rewards exploration with new routes is the product of hundreds of small decisions made on a navigation graph. The job of the level designer is to make those decisions consciously, document them, and test them against real player behaviour rather than against internal assumptions.
The buried city map is also the place where the game’s design pillars become measurable. If the team’s stated pillar is exploration, the map’s landmark density and fast-travel model should prove it. If the pillar is tactical combat, the encounter data and sight-line decisions should prove it. A map that contradicts the pillars is a map that will quietly pull the project off course, no matter how beautiful the art.
Reference table: map decisions and their gameplay effect
The table below summarises the layout decisions discussed above and the gameplay effect each one has on a buried city map. It is meant as a quick audit aid for design reviews.
| Decision | Default on most projects | Risk if misapplied | What to verify in greybox |
|---|---|---|---|
| Navigation graph source of truth | Single cell-and-portal graph drives AI, audio, minimap. | Player-facing map drifts from gameplay data. | Print the graph beside the in-game minimap; check for dead ends. |
| Landmarks per district | One unique anchor visible from each major approach. | Players confuse districts and lose track of progress. | Count visible landmarks from each entry cell; cap at three to five. |
| Vertical layers | Surface, interior, lower district, catacombs. | Streaming spikes and AI pathing errors at layer transitions. | Profile memory at each boundary; test AI on layered portals. |
| Fast travel model | Discover and unlock, with story gates. | Layout pacing breaks if travel is too cheap or too costly. | Play a full act using only the intended travel rules. |
| Hand-painted vs procedural map | Painted overview, procedural minimap, single data source. | Icons and labels diverge between menus and HUD. | Diff the two map layers after every layout change. |
| Encounter zones | Each zone has two entries and one retreat path. | AI clusters, encounters feel staged, flanks do not work. | Run the AI debug overlay through each zone and record idle cells. |
| Streaming cell sizes | Even, predictable, with early unload triggers. | Hitches when crossing district boundaries. | Capture frame times across every boundary in the route. |
| Accessibility data in graph | Contrast, audio cue, and climb flags stored per cell. | Accessibility features require manual upkeep and break on edits. | Toggle each accessibility option and walk a full district. |
Frequently asked questions
What is a buried city map in game development?
In game development, a buried city map is the data structure and player-facing representation of a lost-city level. It includes the navigation graph, streaming cells, landmark placement, fast-travel nodes, and the journal or minimap the player sees. The data layer drives AI, audio, and quest triggers, while the player-facing layer turns that data into something legible.
How do level designers plan a buried city map?
Designers usually start with a paper blockout that defines the city’s overall shape, then translate it into a navigation graph of cells and portals. Landmarks, choke points, and vertical layers are marked on the same diagram. The graph is imported into the engine, where greybox geometry replaces the paper, and AI, audio, and quest data are layered on top of the same cells.
Should a buried city map be hand-painted or procedural?
Most projects use both. A hand-painted overview map gives the city its identity on menus and loading screens. A procedural minimap, generated from the navigation graph, stays accurate as the level changes. The procedural layer should be styled to match the painted one, so the two representations feel like the same document.
How do you keep a buried city map from feeling repetitive?
Combine two or three layout patterns within a single city, and give each district a unique landmark. Keep a shared modular kit to control art cost, then add a small number of unique set pieces per district. Audit the landmark budget so the player’s working memory is not overwhelmed, and review the minimap regularly for visual consistency.
What is the biggest navigation mistake in buried city levels?
The most common mistake is relying on a single map document for both gameplay data and player-facing cartography. When the two diverge, players notice. The fix is to treat the navigation graph as the single source of truth and derive every other representation from it, including the journal map, the minimap, and the quest waypoints.
How does fast travel affect the design of a buried city map?
Fast travel shapes how the player experiences scale. Designers should pick a model early, such as discover-and-unlock or story-gated, and design the layout around it. A layout that depends on long walks collapses if fast travel is too cheap; a layout that depends on quick combat resets collapses if fast travel is too expensive.
How do you test a buried city map before release?
Run a repeatable pre-release route that covers every fast-travel node, every quest-critical cell, and at least one path between each major district. Record time to landmark, soft locks, pathing oddities, and any visual contradiction between in-world signage and the minimap. Run the route on multiple hardware targets to catch streaming and lighting problems.
How do you add DLC or new content to a buried city map without breaking it?
Treat the navigation graph as a shared asset with the same review discipline as any other shippable system. New districts should slot into unused streets, new fast-travel nodes should plug into existing hubs, and new sub-levels should extend existing catacomb networks. Without that discipline, post-launch updates create drift, and the minimap stops matching the level.
Leave a Reply