Level Design for Games

Level Design for Games

A level is space that manages player behavior without words. Correctly placed walls guide the eye. Enemy placement dictates tactics. Lighting points to the next goal. When it all works — the player doesn't notice the design, they just "know" where to go.

Why bad level design is invisible in the editor

The "god" problem in the editor

The designer who created the level knows every corner. They won't get stuck in geometry, won't miss a hidden passage, won't get lost in corridors. Testing a level by its creator is useless. First principle: only someone seeing the level first tests it.

Specific tool for Unity: Analytics + Heatmap. Record player positions every N seconds, visualize via Unity Analytics Heatmap SDK or custom tool with Gizmos.DrawSphere. A death heatmap instantly shows where players get stuck, get lost, hit unexpected difficulty.

NavMesh and AI pathfinding

A beautiful level in the editor can be impassable for AI. NavMeshSurface doesn't bake automatically — needs explicit Agent Radius, Agent Height, Max Slope setup. Gaps narrower than agent + incorrect NavMesh Link = enemies freezing before a 5cm step.

For dynamic levels (destructibility, opening doors) use NavMeshSurface.UpdateNavMesh() with Coroutine instead of full rebake — avoids frame freeze. For large levels — Navmesh.CalculateTriangulation() async via Job System.

Another common problem: NavMeshAgent stuck at boundary between two NavMeshSurface during zone transition. Not a Unity bug — missing NavMeshLink between surfaces. For multi-level locations mandatory explicit Link creation for each transition.

Collision geometry vs. Visual geometry

One of the most expensive mistakes to fix: collision geometry matches visual. Mesh Collider on complex 3D mesh — thousands of triangles for physics engine. On a level with 50 complex props this kills performance.

Rule: collisions — simple primitives (Box Collider, Capsule Collider, Convex Mesh Collider limited to 255 triangles). Visual mesh — separate, detailed. In Blender — separate object with _collision suffix, export together via FBX settings.

How we build levels

Process: grey box to final art

A level goes through three stages before the artist touches it:

Blockout (grey box). Geometry only — ProBuilder in Unity or primitives. No textures, only placeholder materials different colors for different surface types (floor, walls, platforms). At this stage we check: player path, pacing, encounter difficulty, space readability.

Rule: if the level is uninteresting in blockout — final art won't fix this.

Gameplay polish. Place exact enemy positions, event triggers, spawn points, interactive objects. Balance difficulty. Test with playtesters.

Art pass. Only after gameplay approval — artists work on final geometry. This avoids "redo the beautiful level because it's unplayable."

Tools and pipeline

• ProBuilder — quick geometry creation in Unity. For blockout and simple level-specific meshes.
• Blender — complex geometry, modular tileset exports via FBX with configured colliders.
• Cinemachine — camera management based on player position. CinemachineConfiner constrains camera to level bounds without code.
• Timeline — scripted level events: door opening on trigger, ambient animations, cutscene inserts.
• Terrain Tools — for open locations with organic relief. Terrain Layer with PBR materials + Detail Mesh for vegetation.

Modular design

For efficient production we build modular tileset: standardized modules (walls, corners, floors, ceilings) with uniform grid size. Modules snap via ProGrids or built-in vertex snap. Lets an artist create 20-30 modules and cover infinite rooms.

Grid size depends on character scale. Rule: passage width = minimum 2 character size units. For standard 2m tall character — 1m grid, 2-3 cell passages.

Procedural generation

For roguelike and procedural-heavy projects: BSP (Binary Space Partitioning) for space division into rooms, Cellular Automata for cave levels, Wave Function Collapse for tiled levels with connectivity rules.

WFC works via TileRule ScriptableObject: each tile has allowed neighbors in each direction. Algorithm collapses tile superposition into specific level respecting all constraints. Ready implementations for Unity: WFC Unity (open source), Tessera (paid, more functional).

Work process

Concept and reference (1-3 days). Analyze target game feel: pacing, difficulty, atmosphere. Reference levels from similar games. Level narrative tasks.

Blockout (2-5 days per level). Geometry, navigation, basic encounters. First playtest round.

Gameplay iteration (3-7 days). Per playtest results — correction. Repeat until level works consistently across playtesters.

Art pass (depends on volume and style).

Cost calculated after analyzing level count, genre, and AI/navigation requirements.