Academic References

Procedural city/parcel/street generation literature we're drawing on for Roads, Arc-Spline Transport, Procedural Buildings, and Planning (parcel subdivision and junction co-generation). Sourced from jamessimo's "Making my dream city builder: Part 1 - Parcels", who is a developer building the same kind of gridless, procedurally-subdivided city and prototyping against much of this same literature; this page is our running bibliography, not a lit review.

Each entry below is a short paraphrase of the paper's approach, not its abstract.

MetaTransportBuildingsNarrative

Primary Source

The paper the video itself cites.

Basil Weber, one of its authors, is the founder of Urban Games, makers of Transport Fever.

Subdivides the interior of a city block into parcels using a small set of designer-facing style parameters (parcel-area targets, skeleton offsets, split angles) rather than fixed geometric rules, so the same algorithm produces recognizably different parcel "textures" (dense downtown grid vs. sprawling suburban lots) from the same block shape. Its standout contribution for us is persistence: parcel identities are tracked through edits to the block boundary (a road gets redrawn, a block gets resized), so a parcel keeps its identity and any player customization instead of the whole block re-subdividing from scratch. That's still an open problem for our parcel subdivision — re-running subdivision after a road edit regenerates every parcel with a fresh ID.

Street & Parcel Generation

These six are rule-based procedural approaches — the same family as our own pipeline — spanning street-network generation, block subdivision, and real-world planning-tool validation of subdivision rules.

The foundational paper in this space. Generates a street network from an extended L-system driven by input image maps (population density, land/water boundaries, terrain), then subdivides the resulting blocks into building lots and extrudes simple building geometry. First to establish that the street network — not the buildings — is the key structural driver of a believable city layout; nearly every later paper on this list either extends or reacts to this pipeline.

Replaces Parish & Müller's L-system with a tensor-field-guided street graph the designer can edit interactively, either by reshaping the underlying field or editing the graph directly, mixing hand-authored and procedural control at whatever granularity the designer wants. Closest prior art to our own Roads doc's "sketch a rough polyline, the editor fits a curvature-bounded spline live" approach — the live-editing feel is the same goal, tensor fields vs. our arc-spline fit is the differing mechanism.

A GIS-oriented (not graphics-oriented) automated subdivision tool aimed at real planners evaluating zoning-regulation impact before adoption, not at rendering. Takes arbitrary parcel-shaped vector input and produces lot + street layouts respecting real subdivision ordinances (frontage, setback, minimum lot area). Useful as a cross-check for our road-facing frontage split against what real-world planning software actually validates against.

Applied to a real Turkish zoning case (Konya), this paper compares three binary-search subdivision strategies — split by edge length, by parcel area, or both together — against a target lot-size distribution mandated by zoning code. Directly relevant to how Planning picks frontage width and folds remainders; their edge-vs-area comparison is a concrete alternative to the remainder-folding heuristic we're using.

Argues that generating streets and parcels as two separate passes (street network first, then subdivide the resulting blocks) produces worse results than co-generating them: it recursively splits parcels and grows the connecting street graph together at each hierarchy level, using graph search to guarantee every parcel gets street access, then optimizes the combined geometry. Planning adopts that close-by-construction stance for open-network junctions (wedge parcels + frontage trims) rather than emitting overlapping road-facing fans and patching the gap afterward.

A three-stage CGA-rule (CityEngine-style) pipeline — parcel subdivision/clustering, building extrusion, then texture mapping — applied to two real Guangzhou redevelopment projects, generating multiple design proposals per site for planners to compare. The parcel-clustering step (grouping adjacent parcels before subdividing, rather than subdividing block-by-block) is a technique our block-based subdivision path doesn't currently do; worth revisiting if isolated small-block artifacts show up in testing.

Real-world minimum lot dimensions and area requirements from San Francisco's planning code, providing concrete constraints for parcel subdivision validation and cross-reference against our own frontage/area split heuristics.

Municipal subdivision standards covering lot divisions, frontage requirements, and street connectivity, grounding our procedural rules against real-world planning compliance criteria.

Transport Networks & Routing

Foundational references for $G^1$ arc-spline curve geometry, multi-agent mesoscopic transport simulation, and heuristic network graph search.

The foundational open-source framework for large-scale multi-agent transport modeling. Proposes dynamic traffic assignment (DTA) using deterministic spatial queue models on network links, balancing macroscopic speed-flow relationships with individual microscopic agent plans without full physics simulation. Informs Civica's hybrid mesoscopic simulation approach for resident commuting.

Introduces the A* search algorithm for shortest-path graph traversal using admissible heuristics ($h \le h^*$). Civica uses A* over directed lane-level road graphs with travel-time edge costs ($t = \text{length} / \text{speed}$) and Euclidean distance divided by maximum network speed as the admissible heuristic.

Fits discrete polyline input to curvature-bounded, $G^1$ continuous biarc and arc-spline sequences. Provides the mathematical foundation for Civica's road network geometry where lane bundles maintain piecewise-constant curvature, closed-form arc lengths, and exact parallel offset splines.

Dialogue & Narrative Systems

Industry-standard architectures and game design literature for dialogue runners, state machines, and player onboarding conversations.

The seminal narrative scripting language and runtime engine powering games like 80 Days and Heaven's Vault. Establishes the decoupled architecture where dialogue content is compiled into deterministic, immutable bytecode/JSON sequences evaluated by a runtime state machine. Informs Civica's separation of static conversation data from runtime runner state.

Node-based dialogue system widely adopted in narrative games (e.g. Night in the Woods, A Short Hike). Highlights the pattern of linear sequences interrupted by action triggers, timed pauses, and external game state mutations, informing our approach to interactive Mayor onboarding and resident opinion querying.

Learned / Generative Layout Models

These are deep-learning approaches, not rule-based procedural generation. Out of scope for our current rule-based pipeline, but relevant if we ever want learned layouts trained on real-city data rather than hand-authored rules.

Given an arbitrary-shaped city block (from a real road network), a graph attention network generates a plausible building layout inside it by first "unrolling" the irregular block into a canonical rectangular form, generating in that canonical space, then mapping back. Trained/evaluated across 28 real cities. The canonicalization trick — normalize irregular geometry to a regular working space before applying a generation rule, then map back — is a pattern worth stealing even without adopting the learned model.

Follow-up to GlobalMapper: encodes an entire city (buildings, blocks, communities) as one unified graph and trains a masked graph autoencoder on it, so generation is context-sensitive at city scale rather than one isolated block at a time — a downtown block and a suburban block generate differently because the model has seen the whole city's context. Demonstrated across 330 US cities. Relevant to our "growth over time" regeneration goal in Procedural Buildings if we ever want a parcel's generated massing to respond to its neighbors, not just its own zone/density/land-value tuple.

Frames laying out land use and roads within a community as a sequential decision process on a graph, solved with deep RL, and reports outperforming both human planners and prior automated baselines on real Beijing sites by simulation metrics (accessibility, greenspace, etc). Farthest from our current scope — a macro land-use planner, not a geometry-generation tool — but relevant prior art if the city's political/zoning simulation layer (Civics & Politics) ever wants an AI opponent or advisor that proposes zoning plans.

Couldn't independently verify this paper — no matching indexed publication turned up under this exact title. The general technique it names (L-systems extended with global goals/local constraints for street-map generation, following Parish & Müller) is well covered by the SIGGRAPH 2001 and 2008 entries above. Leaving this row as a placeholder in case the source screenshot resurfaces with a clearer citation.

Terrain Data Structures & Modeling

References on heightmap vs. voxel vs. other terrain representations, with considerations for cut/fill, tunnels, and landscape-architecture-informed approaches.

Benchmarks the memory and CPU trade-offs: heightmaps are O(1) writes but strictly 2.5D (no caves, tunnels, overhangs), while voxel terrain supports full 3D but requires mesh regeneration on edits. Key takeaway for cut/fill: heightmap edits are fast and cheap, voxel edits are expensive unless using sparse data structures or chunking.

Proposes a hybrid approach: a sparse voxel grid for sub-surface simulation (water, soil, erosion) coupled to a surface heightmap for rendering. Enables hydrologically-realistic cut/fill (earth moves, water flow) without full volumetric voxel costs. Directly relevant to our "cut/fill and tunnels" requirement.

A 2024 voxel engine's approach to bridging the heightmap/voxel gap: imports 16-bit heightmaps and colormaps, then uses sparse voxels underground. Shows that a production voxel renderer still treats heightmap-sourced data differently from fully destructible terrain — heightmap regions can be optimized differently (compressed, LODed) than interactive voxel regions.

GIS primer on terrain data: DSMs capture surface (trees, buildings), DTMs capture bare ground, and both are typically regular grids or TINs (Triangulated Irregular Networks — vector-based elevation at key points). For landscape-architecture grading and cut/fill, distinguishing bare-ground (DTM) from surface (DSM) is standard practice; relevant if we want to model site grading that works with existing vegetation/structures.

Recent (2025) GIS-to-voxel pipeline research: integrates DEMs, building footprints, and land cover into a unified voxel 3D city model. Shows that GIS workflows increasingly treat terrain as 3D volumetric data when integrating buildings/infrastructure, not as a flat heightmap — relevant precedent for justifying voxel investment if we want semantic terrain layers (soil type, buildability, water table).

Generates multivariate terrain (elevation + vegetation + hydrology) procedurally. Notes that terrain is not just geometry but a bundle of correlated attributes (slope, aspect, soil moisture, vegetation class) that influence navigation and cost; a single heightmap conflates these. Relevant to our "future considerations" if terrain attributes (buildability, water runoff, slope) should drive zoning or road placement beyond just elevation.