# How AI should generate functional FPS maps ## Technical survey and experimental report **Survey date:** August 18, 2026 **Scope:** AI-assisted generation of greybox geometry for tactical FPS maps, including CS/Valorant-style layouts, Call of Duty arena maps, and Rainbow Six–style multi-storey/destructible buildings. ## Executive conclusion The fundamental problem is not that current coding models do not know enough Blender, Three.js, Unity, Godot, Unreal, Hammer, or Doom syntax. The problem is that a language model is being asked to emit a representation whose correctness depends on thousands of globally coupled geometric decisions. Raw mesh generation has an unfavorable error surface: - one reversed index makes a face disappear or point inward; - one duplicated plane causes z-fighting; - one almost-shared coordinate creates a crack or sliver; - one independently generated room duplicates a wall already owned by its neighbor; - one wrong axis conversion moves floors sideways; - one missing vertical relation makes a multi-storey route disconnected; and - a mesh can be manifold and still be tactically unusable. The most reliable architecture is therefore: 1. **The AI authors intent in a compact semantic intermediate representation.** 2. **A deterministic compiler constructs geometry from that representation.** 3. **Robust geometry kernels fuse or regularize the static solids.** 4. **Dynamic gameplay surfaces remain separate semantic actors.** 5. **Automated validators test topology, solids, physics, navigation, timing, visibility, and game rules.** 6. **The AI iterates from structured errors, metrics, renders, and simulated play—not from its own confidence.** This pattern is now visible across recent research in floorplan reasoning, multi-floor scene generation, domain-specific layout languages, executable CAD generation, and closed-loop scene agents. Systems improve when an LLM handles semantic decomposition while a solver, DSL, simulator, CAD kernel, or renderer enforces physical constraints. The same lesson applies even more strongly to FPS maps because a level is simultaneously a solid model, a navigation graph, a visibility system, a collision environment, and a game-balance object. ## 1. Why direct AI geometry fails ### 1.1 Autoregressive text is local; a level is globally coupled A language model chooses the next token using a bounded representation of previous context. A level mesh has long-range invariants: - all triangles around a closed surface must agree on orientation; - every shared edge should have the intended number of incident faces; - both sides of a doorway must refer to the same opening; - floors above and below must agree about stair and hatch holes; - every attacker route must eventually reach an objective; - a wall destroyed at runtime must reveal a valid space behind it. The model can produce code that looks locally plausible while violating a constraint introduced hundreds of lines earlier. Increasing context length does not turn free-form text into a geometric constraint solver. ### 1.2 Coordinates are a high-entropy interface A semantic instruction such as “place a two-cell-wide doorway between Lobby and Bar near the south end” is low entropy. Twelve floating-point vertex coordinates and six triangle indices are high entropy. The latter contain multiple equivalent orderings, engine conventions, and opportunities for tiny disagreement. Recent layout work repeatedly moves from raw numeric generation toward scene graphs, DSL operations, coarse-to-fine decomposition, and solver-owned placement. FloorplanQA documents persistent failures on distance, visibility, placement feasibility, and pathfinding even when the input is structured. MANSION uses a constrained-growth geometry process for multi-floor alignment rather than asking the model to place an entire building directly. LayoutDSL explicitly projects spatial computation into a domain-specific action space. Scene-generation systems such as SAGE, SceneCraft-like pipelines, Scenethesis, GraLa3D, and newer agentic world generators similarly insert scene graphs, numeric constraint stages, physics, or render feedback between language and final scene. ### 1.3 Winding is a convention, not a visual intention A triangle has no intrinsic “front” until its vertices are ordered. Engines differ in coordinate handedness and axis conventions, and some APIs document clockwise front faces. A model that copies a cross-product formula from one environment into another can reverse every polygon even when all coordinates are otherwise correct. The right solution is not to remind the model more emphatically to “use correct winding.” The compiler should construct each primitive from a tested template and have one adapter per engine. A validator should check signed volume, normal consistency, and expected outward orientation before export. ### 1.4 Z-fighting is usually a representation/ownership failure Z-fighting often appears because two surfaces occupy the same or nearly the same plane: - adjacent room generators each create their own wall; - a decorative floor is placed over a structural floor; - a wall cap overlaps a ceiling; - a Boolean result retains an internal face; - modular pieces meet with duplicated end caps; or - the model “fixes” a missing surface by adding another almost-identical one. A depth-buffer tweak is not the fundamental fix. The data model must decide who owns every shared boundary. Static solids should be unioned or generated without internal faces. Deliberate layered surfaces should use clear offsets, decals, or material blending rather than coincident geometry. ### 1.5 “Connected in prose” is not connected geometrically Models often describe two rooms as connected while producing: - walls that miss by a fraction; - doors cut only on one side; - corridors that stop short; - stairs whose top landing is outside the upper room; - a hatch without a matching floor opening; or - portals whose endpoints refer to nonexistent areas. Connectivity must be represented explicitly as graph data and checked independently of the render. The geometry compiler should derive door cuts from a verified shared edge, not trust arbitrary opening coordinates. ### 1.6 Multi-floor maps multiply hidden constraints A tactical multi-storey map needs more than a stack of floorplans. It needs: - storey elevations and headroom; - vertical alignment of stairs, shafts, and hatches; - knowledge of which room lies above another; - floor/ceiling destruction relationships; - exterior façade positions for rappel; - drone routes and holes; - line-of-fire through vertical openings; and - navigation links that update when a hatch or wall changes state. This is why a single 2D SVG or image is not sufficient for Rainbow Six–style generation. A multi-layer semantic model with explicit vertical links is required. ### 1.7 Geometry validity and level validity are different A mesh can be watertight and consistently wound yet still fail as a game map because: - one team cannot reach a site; - a spawn sees another spawn; - every route shares one chokepoint; - defenders rotate too quickly; - a corridor is narrower than the player capsule; - a doorway clips the camera or weapon; - a site has no viable plant locations; - a rappel window has no exterior clearance; or - destruction creates an unreachable nav island. A production generator needs both geometric and gameplay validators. ## 1.8 Exact reconstruction is a different task from generation When the goal is a truly exact private reference copy, a language model should not infer the map from prose. Use the most authoritative structured source available, then translate it into the semantic pipeline: 1. **Original editable source**, when the developer has released it or the user owns it. 2. **Official mod/workshop tools and example sources.** CS2 provides Workshop Tools and Hammer; the COD4 Mod Tools include Radiant and selected official source maps. 3. **Compiled-map decompilation for research**, where permitted. Source 1 BSP files can be reconstructed to VMF with BSPSource; Source 2 Viewer/ValveResourceFormat can inspect and decompile Source 2 resources. Decompiled output is not the original source and can contain reconstruction errors, so it must still be normalized and validated. 4. **Official blueprints and tactical maps.** Ubisoft currently offers downloadable blueprints on its map pages, including Clubhouse. These establish rooms and adjacency but do not provide exact wall thicknesses, elevations, collision, or all destruction data. 5. **Authorized scan/photogrammetry or point-cloud capture** when no source plan exists. Fit walls and floors to the scan, snap them to tolerances, and recover semantics separately. For an exact-copy benchmark, the AI's role is extraction cleanup, semantic labeling, and discrepancy repair. The source geometry—not a prompt—is authoritative. For an original generated map, the AI/solver creates the LevelSpec under tactical constraints. These should be treated as two distinct modes. The included benchmarks use manually authored approximate topology because the experiment is about representation reliability, not asset extraction. No proprietary textures, props, or shipped collision are included. ## 2. What has been tried, and where each technique belongs ## 2.1 Raw triangle or vertex generation ### Strengths - universal output; - no dependency on a particular level editor; and - potentially compact after optimization. ### Failure modes - reversed winding; - non-manifold edges; - missing or duplicated faces; - T-junctions and cracks; - zero-area/sliver triangles; - inconsistent normals; - invalid UVs; - coplanar overlaps; - difficult semantic editing; and - no natural representation of rooms, routes, or destruction. ### Verdict Use triangles only as a **compiler output**, never as the AI’s authoritative editing format. The included `raw_triangle_failure.obj` demonstrates three defects in a tiny example: a missing top face, an inconsistent triangle orientation, and two floor surfaces separated by only 0.00001 m. The mesh fails watertightness and winding consistency. A full FPS map multiplies this risk enormously. ## 2.2 Doom-style sectors and portal graphs Classic sector-based representations are much better than raw meshes for mostly 2.5D environments. The model can describe a planar subdivision, floor and ceiling heights, and adjacency portals; a compiler extrudes walls. ### Advantages - compact; - easy connectivity graph; - deterministic wall extrusion; - excellent for orthogonal indoor maps and retro/web renderers; and - simple collision and visibility partitioning. ### Limits - the planar subdivision itself must still be valid and non-self-intersecting; - classic room-over-room is awkward without extensions; - free-form stairs, overhangs, balconies, destructible floors, and complex exterior traversal exceed a simple sector model; and - a language model should still not independently list unverified polygon vertices. ### Correct use Let the model define spaces and adjacency. Use a planar-arrangement library or integer-grid compiler to derive polygons. Add explicit layers and portal links for room-over-room. This becomes a strong LevelSpec rather than “AI writes a WAD by hand.” ## 2.3 Convex brushes and BSP-style geometry Quake/Source-style brushes are one of the best greybox targets. A brush is an intersection of plane half-spaces and is therefore convex by construction. TrenchBroom’s documentation explains that brush geometry is reconstructed from plane triples and that the interior is the intersection of the selected half-spaces. ### Advantages - robust, editable greyboxing; - exact planar walls; - natural collision volumes; - mature editors and compilers; - easy Boolean-like architectural construction; and - far fewer degrees of freedom than arbitrary triangles. ### Failure modes when authored directly by an LLM - plane normals face the wrong way; - a non-convex room is mistakenly expressed as one brush; - three plane points are collinear; - tiny plane discrepancies produce invalid or micro brushes; - overlapping brushes retain unwanted surfaces depending on the downstream pipeline; and - openings are made by stacking independent wall pieces with duplicated caps. ### Correct use The AI should emit box/extrusion intent or a semantic floorplan. A deterministic exporter should generate the six ordered planes for every convex brush and test a known interior point against every half-space. The included benchmark does this. All 122 Dust-style and 229 R6-style brush centers pass the half-space test with zero positive violation. ## 2.4 Modular kits and socket graphs A modular kit uses authored walls, corners, doors, stairs, floors, windows, and trims snapped to a grid with typed connection sockets. ### Advantages - production art quality; - known collision and UVs; - semantic pieces for doors, soft walls, and windows; - fast engine runtime through instancing; - easy style changes; and - safer AI action space: choose modules and sockets instead of triangles. ### Failure modes - incompatible sockets; - repeated end caps causing z-fighting; - gaps from scale or unit mismatch; - kit monotony; - combinatorial search; and - global tactical layout still unsolved. ### Correct use Use a two-stage system: 1. solve the abstract topology and metric floorplan; then 2. tile the approved shell with a socket-constrained modular kit. The kit placer should trim hidden faces or keep modules slightly separated behind intentional seams. WFC can help with local module selection, but should not be trusted to create the global tactical topology. ## 2.5 CSG and Boolean solids Constructive solid geometry represents a map as unions, differences, and intersections of simple solids. ### Advantages - openings and unions are explicit operations; - topology is more stable than raw triangle editing; - easy parametric generation; - suitable for architectural greyboxes; and - outputs can be baked to a mesh. ### Failure modes - exact coincident surfaces can be numerically troublesome; - near-zero slivers from almost-aligned cuts; - operation order matters; - deeply nested trees become slow; - runtime CSG is often too expensive; and - dynamic gameplay panels must not be fused into the static shell. ### Correct use Generate CSG from a snapped semantic model; regularize touching solids with a small, documented overlap epsilon; perform the Boolean offline; validate the result; and bake it. Godot’s own documentation positions CSG primarily as a prototyping tool and warns about its CPU cost relative to ordinary mesh instances. The benchmark uses a 1 mm overlap epsilon for the OpenSCAD and CadQuery union passes. This is large enough to avoid exact face-touch ambiguity while remaining far below gameplay-relevant dimensions. ## 2.6 Exact CAD/B-rep and NURBS CAD kernels represent solids using boundary representation: faces, edges, vertices, loops, shells, and exact analytic or spline surfaces. NURBS are a way to represent curved surfaces; they are not by themselves a complete level topology system. ### Where CAD helps - exact dimensions and constraints; - robust boxes, extrusions, fillets, and Boolean operations; - parametric editing; - STEP exchange; - validation of closed solids; and - natural generation of curved tunnels, stairs, ramps, and architectural profiles. ### Where CAD does not solve the problem automatically - a valid solid has no knowledge of bomb sites, rotations, soft walls, or rappel; - direct STEP text has a graph-like cross-reference structure that is hostile to left-to-right generation; - selector code can break when topology changes; - tessellation still must choose normals, tolerances, and UVs; - exact Booleans dislike pathological coincident inputs; and - an enormous building B-rep is not automatically a good real-time render/collision mesh. Text-to-CadQuery and subsequent CAD-agent work support an important distinction: **generate executable parametric operations, run them, and feed execution/geometry feedback back to the model**. This is much more reliable than asking the model to produce a final exchange file without execution. STEP-LLM demonstrates progress on direct STEP generation, but its need for retrieval, reserialization, and refinement also illustrates how structurally demanding the format is. ### Verdict Use CadQuery/OpenCascade, CGAL, Manifold, or another geometry kernel **behind the compiler**. Let NURBS handle curved local features. Do not replace a semantic level graph with free-form NURBS patches or raw STEP tokens. The included CadQuery path creates valid input solids, an editable compound STEP, and a fused STEP. The fused Dust-style result has seven valid closed solids and a watertight 1,414-triangle tessellation; the R6-style result has seven valid closed solids and a watertight 2,396-triangle tessellation. ## 2.7 BIM and IFC Building Information Modeling formats add semantics absent from ordinary CAD: projects, sites, buildings, storeys, spaces, walls, slabs, doors, windows, placements, and openings. ### Advantages - explicit storey hierarchy; - walls and openings are first-class objects; - useful architectural interchange; - room labels and property sets; and - potential source for real or generated buildings. ### Limits - verbose and complex; - architectural semantics do not include FPS balance; - IFC geometry can arrive in many representations; - game collision and destructibility still require conversion; and - arbitrary real buildings are usually poor competitive maps. ### Correct use Treat IFC as an import/export boundary or a semantic reference, not the AI’s primary token stream. Convert selected storeys/spaces/walls/openings into a game-specific LevelSpec, then deliberately redesign routes and gameplay surfaces. The included DXF output demonstrates the lighter-weight CAD-plan version of this idea: each storey, wall role, portal, marker, and room label is placed on a semantic layer, while the deterministic compiler remains authoritative. ## 2.8 Voxels, occupancy grids, and signed-distance fields A voxel/SDF representation trades exact surfaces for a sampled volume. ### Advantages - union is simple occupancy logic; - easy flood-fill and connectivity analysis; - robust watertight extraction with marching cubes; - supports caves, tunnels, and destruction fields; - avoids explicit winding during authoring; and - useful for repairing unreliable polygonal input. ### Trade-offs - memory cost; - stair stepping or dimensional quantization; - very high triangle count after extraction; - thin surfaces can vanish; - semantic wall boundaries become blurred unless retained separately; and - runtime collision/nav may require simplification. ### Verdict Excellent as a repair/fallback or for destructible terrain; usually not the primary representation for a precise tactical building. The included voxel path generates one watertight component for each benchmark, but at 162,908 and 188,840 triangles—roughly two orders of magnitude heavier than the fused CSG/B-rep outputs. ## 2.9 Scene graphs, DSLs, and constraint solvers This is the strongest general solution family. A scene/level graph stores nodes such as rooms, corridors, sites, spawns, stairs, windows, and cover; edges encode adjacency, visibility, containment, above/below, and traversal. A DSL adds constrained operations. A solver converts relationships into metric placement. ### Advantages - stable semantic IDs; - compact AI output; - explicit global constraints; - easier repair and diffing; - supports multiple downstream geometry backends; - natural automated tests; and - separates tactical design from surface tessellation. ### Solver choices - integer-grid search for an initial system; - constraint programming/CP-SAT for adjacency, dimensions, non-overlap, and timing bounds; - mixed-integer programming for metric layout; - SMT for logical invariants; - graph grammar for topology; - nonlinear optimization for visibility and distances; and - simulated annealing/evolutionary search for soft objectives. ### Best division of labor The LLM is good at: - interpreting the design brief; - proposing room roles and adjacency; - explaining trade-offs; - choosing which constraint to relax; and - performing semantic edits. The solver is good at: - exact non-overlap; - shared-boundary consistency; - coordinate placement; - path and timing bounds; - alignment; and - objective optimization. The compiler is good at: - geometry; - booleans; - winding; - collision; - engine conversion; and - export. ## 2.10 Shape grammars and Wave Function Collapse WFC reproduces local neighborhood patterns learned from examples. Shape grammars apply production rules such as corridor → junction + room. ### Good uses - façade variation; - props and dressing; - local room-module tiling; - repeated architectural motifs; - cover micro-layout after global routes are fixed; and - generating diverse candidates within a constrained envelope. ### Bad uses - guaranteeing balanced attacker/defender timings; - ensuring two independent routes to both sites; - multi-storey vertical strategy; - global visibility and rotation constraints; and - reproducing an entire complex map from only local tile compatibility. WFC is local consistency, not global tactical intelligence. Combine it with a graph/solver layer. ## 2.11 Evolutionary search and quality diversity Procedural-content-generation research has long optimized levels using fitness functions, simulation, novelty, and quality diversity. Recent FPS MAP-Elites work compares several genomes, including grid, graph, point-line, and spatial-layout representations, and distinguishes topological metrics from emergent properties measured through gameplay. This is highly relevant after a reliable compiler exists. ### Candidate descriptors/objectives - attacker/defender route-time difference; - number of independent routes; - graph centrality distribution; - chokepoint count and width; - average sightline length; - cover exposure; - rotation time; - site retake difficulty; - vertical-link density; - soft-wall option count; - spawn safety; and - bot win-rate balance. ### Correct use Generate thousands of valid LevelSpecs, compile and simulate them, then use MAP-Elites to preserve diverse high-quality solutions. An LLM can name, critique, and mutate candidates, but should not replace the measurable archive. ## 2.12 Neural world models, NeRFs, Gaussian splats, and image-to-3D Modern systems can generate visually compelling, sometimes explorable environments from text or images. They are valuable for: - mood and style exploration; - distant scenery; - reference generation; - rapid concept walkthroughs; and - suggesting prop compositions. They are not yet the authoritative source for a competitive map because visual plausibility does not guarantee: - exact collision; - stable topology; - deterministic dimensions; - clean material boundaries; - editable destruction semantics; - network-replicable gameplay actors; or - reproducible route timing. The right hybrid is to use a neural world as a concept/reference layer and fit a validated semantic shell beneath it. ## 3. The recommended compiler architecture ## 3.1 Use several representations, not one A production system should have explicit stages: ### Stage A: tactical topology A graph of: - spawns; - objectives; - route zones; - chokepoints; - rotations; - vertical links; - exterior entries; and - optional/destructible edges. No metric geometry is required yet. ### Stage B: metric semantic layout A LevelSpec containing: - storeys and elevations; - spaces and dimensions; - adjacency portals; - boundary materials/roles; - cover volumes; - vertical connections; and - gameplay markers. ### Stage C: compiled constructive geometry Compiler-owned: - maximal floor polygons/rectangles; - one wall segment per owned boundary; - headers and frames around openings; - stairs/ramps/hatches; - static and dynamic groups; and - exact coordinates. ### Stage D: solid regularization Choose one or more: - brush/BSP compile; - robust manifold Boolean; - exact B-rep Boolean; - voxel/SDF union; or - modular-kit hidden-face removal. ### Stage E: engine representation - visual mesh; - collision mesh/primitives; - navmesh sources and off-mesh links; - occlusion/visibility data; - semantic actors; and - lightmap/UV data. Keeping these stages distinct makes errors diagnosable. A topology error should not be repaired by moving arbitrary triangles. A tessellation error should not change route design. ## 3.2 Stable IDs are essential Every room, portal, wall run, stair, hatch, cover object, spawn, and site needs a stable ID. This enables: - meaningful diffs; - targeted validation errors; - AI repair without rewriting the map; - runtime destruction state; - network replication; - analytics; and - designer overrides that survive regeneration. ## 3.3 Separate hard constraints from soft objectives ### Hard constraints - schema-valid; - no accidental room overlap; - minimum corridor/door/player clearance; - every required portal lies on a shared boundary; - every required route exists; - no spawn inside solid geometry; - vertical links align with floor holes; - no invalid/negative dimensions; - static fused shell is valid; - dynamic panels have valid frames; and - engine import succeeds. ### Soft objectives - target route times; - balanced exposure; - desired sightline distribution; - appropriate cover cadence; - map compactness; - recognizability/readability; - defender rotation pressure; - utility opportunities; - destruction choice quality; and - aesthetic composition. A solver rejects hard violations. An optimizer ranks soft trade-offs. An LLM explains and chooses among them. ## 4. Geometry and gameplay validation stack ## 4.1 Schema validation Validate JSON types, IDs, enumerations, required fields, and units before any geometry work. ## 4.2 Semantic/topological validation - IDs unique; - referenced spaces/layers exist; - portal spaces are adjacent; - exterior portals are on the exterior; - vertical endpoints are occupied; - markers snap to traversable cells; - required route graph connected; and - optional/destructible links have state-dependent graph tests. ## 4.3 Solid/mesh validation - positive dimensions; - finite coordinates; - no zero-area triangles; - manifoldness/watertightness where required; - consistent winding; - outward normals/signed volume; - no unintended self-intersections; - no same-facing coplanar overlap; - no unapproved intersecting volumes; - no sliver faces below tolerance; - no open boundaries in static collision; and - expected connected-component count. Trimesh’s definition of a valid volume—watertight, consistent winding, and outward normals—is a useful baseline, but a game map also needs the semantic and gameplay checks above. ## 4.4 Physics validation Run headless capsule sweeps for: - every corridor; - every doorway; - stairs and landings; - crouch/standing transitions; - jump/drop paths; - ledge snagging; - door frames; and - destruction states. Use simplified collision separate from render detail. Primitive colliders are preferable for moving/dynamic objects; large static environments can use a carefully prepared concave/static collision mesh according to the engine’s physics rules. ## 4.5 Navigation validation - navmesh bake succeeds; - expected islands/components; - spawn-to-site paths; - rotations; - vertical off-mesh links; - alternate path after blocking a route; - dynamic rebuild or link toggle after destruction; and - AI agent clearance. ## 4.6 Visibility and tactical validation Sample eye positions and rays to compute: - spawn visibility; - first-contact positions; - longest sightlines; - crossfire overlap; - exposed route fraction; - cover spacing; - objective entrance visibility; - vertical lines through hatches/floors; and - defender anchor visibility. ## 4.7 Simulation and playtest validation Use bots or simplified agents to estimate: - time-to-contact; - site arrival distributions; - engagement heatmaps; - route selection; - win rate by side; - utility value; - reinforcement/destruction choices; and - dead areas. A map should only be called “playable” after geometry, physics, nav, and at least basic simulated or human playtesting. ## 5. Game-family-specific requirements ## 5.1 CS/Valorant-style maps The semantic model should support: - two teams and two sites; - multiple lanes with controlled convergence; - defender rotations; - attacker staging areas; - elevation layers such as Catwalk over Lower/Mid; - utility lineups and occlusion volumes; - boost/jump/crouch traversal metadata; - plant zones and post-plant positions; - spawn-to-first-contact timing; and - retake paths. Dust II illustrates why “2D plan” is not enough: Catwalk/Short and nearby ground-level zones overlap in XY but differ in elevation and connect through explicit stairs. Model these as separate layers, not as accidental overlapping geometry. ## 5.2 Rainbow Six–style maps The map compiler must retain semantic surfaces after geometry generation: - `hard/static structural`; - `soft/destructible`; - `reinforcement slot`; - `window/barricade`; - `rappel entry`; - `hatch`; - `destructible floor/ceiling zone`; - `drone-sized portal`; and - `bullet-penetrable but non-traversable`. Each dynamic surface needs stateful runtime behavior. The ideal compiler generates a static frame plus a replaceable panel and registers every state with collision, nav, visibility, audio, VFX, damage, and networking systems. Rappel requires: - a façade traversal surface; - top/bottom limits; - corner transitions or exclusions; - stand-off distance; - window/door entry frames; - clearance against roofs and props; - valid landing locations; and - camera/weapon collision tests. Vertical destruction requires room-above/room-below queries and floor cells with explicit structural/non-structural roles. ## 5.3 Call of Duty–style maps COD arena maps often benefit from the same topology system with different objectives: - faster spawn-to-contact; - spawn zones that dynamically flip; - loops and flank routes; - mantles and windows; - more frequent cover; - domination/hardpoint zones; - killstreak visibility constraints; and - broader traversal permission than a CS map. The compiler can remain the same; the gameplay validator and optimizer change. ## 6. Experiments in this package ## 6.1 Benchmark design Two deliberately approximate layouts were authored in LevelSpec: 1. **Dust-style topology benchmark:** a two-site, multi-lane layout with a separate elevated Catwalk layer and two stair links. 2. **Clubhouse legacy topology benchmark:** a three-storey R6-style building with explicit rooms, internal portals, wall roles, windows/rappel entries, stairs, hatches, and objectives. The objective was not millimeter-accurate reconstruction. It was to test whether one semantic source could produce valid outputs through materially different geometry methods. ## 6.2 Direct separate primitives ### Dust-style - 122 boxes - 976 vertices - 1,464 triangles - every box individually closed - consistent winding - 122 connected components - 156 same-facing coplanar face pairs - 136 intersecting-volume pairs - correctly flagged `runtime_ready: false` ### R6-style - 229 boxes - 1,832 vertices - 2,748 triangles - every box individually closed - consistent winding - 229 connected components - 304 same-facing coplanar face pairs - 259 intersecting-volume pairs - correctly flagged `runtime_ready: false` This is the most important negative result: merely switching from hand-written triangles to box primitives does not eliminate z-fighting/internal-face risk. A collection-level ownership/union step is still required. ## 6.3 Quake convex brushes - Dust-style: 122 brushes, all interior-center half-space tests pass. - R6-style: 229 brushes, all tests pass. This validates deterministic plane orientation. It also produces an editable `.map` route for brush-based workflows. ## 6.4 OpenSCAD Boolean union ### Dust-style - 705 vertices - 1,414 triangles - watertight - consistent winding - seven connected closed components - approximately 2.4 seconds in the recorded run ### R6-style - 1,142 vertices - 2,396 triangles - watertight - consistent winding - seven connected closed components - approximately 4.6 seconds in the recorded run The remaining components correspond to intentionally disconnected cover/structural pieces. Watertightness does not require the entire level to be one connected shell. ## 6.5 CadQuery exact B-rep ### Dust-style fused result - valid B-rep - seven solids - 705 tessellated vertices - 1,414 triangles - watertight and consistently wound - Boolean fuse approximately 0.85 seconds ### R6-style fused result - valid B-rep - seven solids - 1,142 tessellated vertices - 2,396 triangles - watertight and consistently wound - Boolean fuse approximately 2.06 seconds The OpenSCAD and CadQuery fused tessellations converge to nearly the same geometry, providing a useful cross-check between a polygonal CSG route and an exact B-rep route. ## 6.6 Voxel/SDF reconstruction ### Dust-style - 0.30 m pitch - 81,444 vertices - 162,908 triangles - watertight - one component ### R6-style - 0.25 m pitch - 94,358 vertices - 188,840 triangles - watertight - one component This path is exceptionally robust but clearly inferior for precise lightweight architectural geometry unless followed by simplification and semantic reprojection. ## 6.7 Navigation/gameplay graph ### Dust-style - 2,233 traversable nodes - 4,270 edges - one connected component - T spawn → A: 65 grid cells - T spawn → B: 59 cells - CT spawn → A: 18 cells - CT spawn → B: 34 cells ### R6-style - 1,342 nodes - 2,354 edges - one connected component - all declared attacker/defender-to-objective paths exist - distances include vertical links through stairs/hatches These are not claims that the approximate maps are competitively balanced. They demonstrate machine-checkable topology and timing inputs. ## 6.8 Semantic runtime split The R6-style manifest identifies: - 121 static shell candidates; - 16 destructible soft-wall pieces; - 10 reinforcement/hard-wall slots; - 16 window/rappel surfaces; - 56 stair pieces; - four hatches; - six cover pieces; and - eight rappel portals. This is the representation needed to turn a building mesh into a game system. ## 7. Ranking the approaches | Rank | Approach | Recommended role | |---:|---|---| | 1 | Semantic LevelSpec + deterministic compiler + robust union | Default architecture for original tactical maps. | | 2 | Semantic topology + modular kit/socket placer | Best route to production art after greybox validation. | | 3 | Compiler-generated convex brushes | Excellent editable greybox and collision workflow. | | 4 | Exact B-rep/CadQuery behind the compiler | Strong for exact architecture, curves, STEP, and solid validation. | | 5 | CSG behind the compiler | Strong greybox bake; avoid expensive runtime trees. | | 6 | CP-SAT/SMT/optimization over LevelSpec | Best next step for automated layout solving and balance. | | 7 | Voxel/SDF | Repair, caves, terrain, and volumetric destruction fallback. | | 8 | BIM/IFC interchange | Import/export semantics, not the game-authoring core. | | 9 | WFC/shape grammar | Local modules and dressing after topology is fixed. | | 10 | Neural world generation / splats | Concept/reference layer, not authoritative competitive geometry. | | 11 | Direct AI triangles/STEP/engine scene code | Avoid as the primary representation. | ## 8. Practical implementation recommendation Build a map compiler rather than a “map prompt.” The smallest credible product consists of: 1. a JSON/DSL LevelSpec; 2. a schema and semantic validator; 3. a deterministic snapped geometry compiler; 4. static/dynamic semantic grouping; 5. one robust Boolean backend; 6. one engine adapter; 7. nav/connectivity/timing tests; 8. floorplan/isometric render feedback; and 9. an AI agent restricted to editing the spec. Then add, in order: - LOS and cover metrics; - player-capsule sweeps; - stair/ramp generation; - modular-kit tiling; - destructible wall runtime actors; - bot simulation; - constraint solving; and - MAP-Elites or another quality-diversity search over valid maps. This architecture works for Three.js, Unity, Godot, and Unreal because the canonical source is engine-independent. Only the final adapter knows that Three.js/Godot are Y-up in the chosen mapping, Unity has its own handedness and front-face conventions, or Unreal is Z-up and centimeter-based. ## 9. What not to do - Do not ask an AI to produce the complete map as one huge Blender/Three.js script. - Do not let each room generate its own four walls independently. - Do not treat a successful render as proof of collision or connectivity. - Do not add tiny Z offsets as a universal z-fighting repair. - Do not embed dynamic soft walls in a fused immutable shell. - Do not make the AI hand-convert every engine’s axes. - Do not use a single image as the only source of multi-floor relationships. - Do not optimize aesthetics before the topology and movement graph pass. - Do not expect WFC to solve global competitive balance. - Do not expect NURBS to solve room adjacency or gameplay semantics. - Do not ship exact copies of proprietary maps merely because the geometry pipeline can reconstruct them. ## 10. Research sources surveyed The conclusions above were informed by the following representative primary sources and official documentation. This list is broad rather than literally exhaustive; new scene/CAD papers appear frequently. ### Spatial reasoning, scene generation, and DSLs - *FloorplanQA: A Benchmark for Spatial Reasoning in LLMs* (arXiv:2507.07644) - *MANSION: Multi-floor Language-to-3D Scene Generation* (arXiv:2603.11554) - *SpatialGrammar: A Domain-Specific Language for LLM-Based 3D Indoor Scene Generation* (arXiv:2604.27555) - *LayoutDSL: Learning an Interior Layout Policy in a Domain Specific Language* (arXiv:2608.07547) - *Scenethesis: A Language and Vision Agentic Framework for 3D Scene Generation* (arXiv:2505.02836) - *GraLa3D: Scene Graph and Layout Guided Complex 3D Scene Generation* (arXiv:2412.20473) - *Open-Universe Indoor Scene Generation using LLM Program Synthesis and Uncurated Object Databases* (arXiv:2403.09675) - *WorldGen: From Text to Traversable and Interactive 3D Worlds* (arXiv:2511.16825) - *PlanCraft: Sketch, Refine, and Furnish for Architect-Level 3D Scene Generation* (arXiv:2607.23491) - *Text2Villa: Hierarchical Generation of 3D Indoor Scenes* (arXiv:2607.17145) - *3D Scene Generation: A Survey* (arXiv:2505.05474) ### CAD generation and closed-loop agents - *Text-to-CadQuery: A New Paradigm for CAD Generation with Large Language Models* (arXiv:2505.06507) - *STEP-LLM: Generating CAD STEP Models from Natural Language* (arXiv:2601.12641) - *FutureCAD: High-Fidelity CAD Generation via LLM-Driven B-Rep Grounding* (arXiv:2603.11831) - *CADReasoner: Iterative Program Editing for CAD Reverse Engineering* (arXiv:2603.29847) - *Self-Improving CAD Generation Agents with Finite Element Feedback* (arXiv:2605.17448) - CadQuery official documentation - OpenSCAD official documentation - Manifold geometry library documentation ### Procedural level generation and optimization - *Procedural Generation of First Person Shooter Maps using MAP-Elites* (arXiv:2605.30570) - *WaveFunctionCollapse* by Maxim Gumin (reference implementation and algorithm description) - Google OR-Tools CP-SAT official documentation - broader PCG/quality-diversity literature summarized in *Evolutionary Machine Learning and Games* (arXiv:2311.16172) ### Engine and geometry documentation - TrenchBroom Reference Manual: brush planes and half-space construction - Unity Manual: mesh index data and clockwise winding - Unity ProBuilder documentation - Unreal Engine documentation: left-handed Z-up coordinate system, PCG, and Geometry Scripting - Godot documentation: CSG prototyping, procedural geometry, collision shapes, and navigation performance - buildingSMART IFC documentation for storeys, spaces, walls, doors, windows, and openings - Trimesh documentation for watertightness, winding consistency, and volume validation ## Final answer The highest-leverage change is to stop asking AI to “make a map” in the final geometry format. Ask it to **design and revise a constrained semantic map program**, then compile that program with the same discipline used by a programming-language toolchain: - typed intermediate representation; - deterministic lowering passes; - geometry kernels; - static analysis; - tests; - simulation; and - engine-specific backends. That turns AI from an unreliable triangle typist into a high-level level designer operating inside a system that makes illegal geometry difficult or impossible to express.