Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The Level Design Book gathers level design knowledge for 3D video games in an approachable, up-to-date, and critical way. It is for designers of all experience levels and game engines.
This book is heavily under construction. Structure may change a lot, and some pages may have little / no content yet.
November 2025: minor cleanup of /
January 2025: added
This online book is free to read forever, under a license. We will never sell or paywall access to this book. If you translate parts of this book, you may not sell copies or access to the translation. For more info, see our page.
the core idea / concept of a layout
In architecture, the parti is the central idea / concept of a project. Can you reduce the building down to its most important structural aspects in 1 sentence?
Similarly, level design benefits from defining a central core idea that anchors the rest of the design. If you're able to pitch your level with a clear parti statement or sketch, then your collaborators (or even the player) will understand your intent better.
Price Tower, "The Tree that Escaped the Crowded Forest"
plan: a square with a cross in the middle
different ways that NPCs and AI can move and path around levels
Steering vs pathfinding
Obstacle avoidance
Flocking
Formations
basics of A star
but also AI hinting, cover
Debug tools (show destination, add AI follow debug)
recast or grid, vs manual markup
basic combat AI considerations
Read David Sirlin's collectibles article about Donkey Kong Country
Draw a 2D platformer layout with collectibles
For specific setpieces, markup the outline of the player's screen; what can the player see exactly
Present and talk through the plan
file formats / specifications for file types used in mapping and modding
For this design test, you will adapt a real-world building or location into a single player level.
Focus on these design considerations:
Typology: what are the main structural patterns of the real world site, and how can this logic be simplified while still maintaining a strong resemblance?
Massing: what parts feel light or heavy, thin or thick, strong or delicate, and how do we distil those qualities into a 3D recreation?
Scope: how much of the location should we seek to adapt, a full exterior with a partial interior, or vice versa?
Go beyond the brief
Define experience goals
Plot out the major beats for the level
other levels that do similar things?
practice looking at layout drawings... why did they draw it that way? what does it communicate?
Parti
Bubble diagram
Layout
Spatial interior design lighting theory with six lighting strategies
D6 lighting uses the six faces of an ordinary six-sided game die (1d6) (⚀ ⚁ ⚂ ⚃ ⚄ ⚅) to help you remember different lighting strategies.
This strategy is about lighting for flow, not just lighting from a specific view or camera perspective. It represents a more architectural and spatial approach to lighting a level, and in most cases, we encourage you to prioritize this type of lighting theory over three point lighting.
Place a lone light source to emphasize a specific point or place, to suggest the player approach this exact location.
A point light treats all angles equally, while the directionality of a spotlight suggests more of a specific angle of approach or intention. Imagine a lone window, campfire, car headlights, flood light, a dramatic lone stage light angled down.
Place two similar light sources next to each other to frame something in the space between. It will suggest an approach that is perpendicular to the frame.
Frame an entrance or exit. Torches, sconces.
Angle spotlights toward a wall to "wash" the surface evenly
vertical massing, height, "z-levels", floors
Of course, it is difficult to plan in the vertical dimension with a top-down layout drawing. That's why architects draw elevations and sections to depict the vertical profile of a building. But for level design planning purposes, that is too much detail. Think more abstract.
(layout with verticality)
Group your areas into major ground planes / elevations, and shade it like a heightmap: darker areas are lower, while lighter areas are higher.
Omit any minor height changes or shallow terrain sloping.
Reserve enough space for ramps, stairs, and any approaches or landings.
If your map consists of overlapping floors over floors, draw the floors separately and label the transitions between floors. But for structures with trivial ground floors, like a watchtower, then you can simply omit it. Draw what will best communicate the core ideas of the level.
To build up lighting skills, start as simple as possible: ignore all the fancy lighting features of your game engine or renderer, and instead manually hand-place every light source, including any bounce lights or fill lights. This is a labor-intensive "old fashioned" way of lighting a 3D space, but it is a useful exercise to force you to think about what your light is doing. This workflow is also more relevant than you may think; relatively recent games like Fallout 4 feature no precomputed light baking.
Light a simple blockout room with realtime direct lights and hand-placed indirect lighting.
If this is your first time thinking about lighting, texture the blockout with grayscale textures and use desaturated grayscale lighting.
If you'd like more of a challenge, use colored prototyping textures and colored lights.
Disable precomputed light baking, use only realtime lights, consult the lighting page on how to setup a fill light
(unfinished stub)
Early 20th century modernist architects debated: what is the soul of a building?
The architect Louis Sullivan famously argued in an article "The Tall Office Building Artistically Considered" (1896) that a boxy featureless industrial office building had its own beauty that was timeless and universal -- that "form follows function."
So this is one (outdated) way to understand environment art: extra details and ornament, form WITHOUT function.
For more on modernist architects being wrong, see History of architecture.
(TODO: compare art nouveau vs. modernist architecture image)
More directly, env art has roots in two crafts: model miniatures and film set construction.
People used to play with physical doll houses, model trains, and Warhammer battles. You had to assemble and paint the pieces yourself, but that construction and customization was part of the fun. It must be beautiful, but it must also be usable for play.
The film industry used to build physical film sets / FX with matte paintings and prop design. Some env art terminology (like "hero prop") even comes from the film industry. Many artists have worked in both film and games, and these industries / traditions converge more every day.
(TODO: train miniatures, film set miniatures, etc.)
critical level design primer on the city that game design built
TODO: summarize Learning From Las Vegas


Different ways of classifying players and their motivations / long-term behavior
A player persona is a player's long term pattern of behavior and overall motivation for playing a game.
Classifying players under various personas / categories can help you study players and interpret playtest data.
In reality, players are never just one category. People are a complex combination of all these motivations and more.
Nonetheless, this reductive simplicity can be useful for making design decisions and imagining your audience. Ideally, every level can satisfy every persona.
(TODO: flesh this out a lot more)
Player
Cheater
Spoil-Sport
The 1996 was one of the earliest attempts to classify video game players. Bartle was studying player behavior in early text-based MMOs called , and sorted all these MUD players into four general categories:
achievers want to score the most points, maximize game progress
explorers want to discover new places or systems, map-out the game space
killers focus on PvP / competitive conflict with other players, sometimes unfairly
(TODO: include 4 quadrant matrix image)
On this page, we list various level design project plans / assignments. These are useful for teachers to plan lessons, but also useful for anyone seeking to learn and practice level design by themselves too.
Currently, our focus is on finishing Book 1, Process. So this section is a little neglected.
However, we do have some almost-finished project plans to give you a sense of what we're going for:
, make (and think about) Doom / Quake level design with classic arcade-style shooter combat.
general size and complexity of a project; validated through prototyping
Scope is the general size and complexity of a project.
In , you set the initial scope and expectations.
The conventional wisdom in game development is to assume every project begins massively overscoped. Even small reasonable projects hide secret problems. Level design is no different; even a small level may require many iterations and playtests to prove out, if ever. When in doubt, scope down and cut unnecessary non-pillar game aspects.
With more work experience (or in a group, more trust) you eventually become slightly better at estimating project scope. If you're new to game dev, we suggest a 50% rule: imagine the smallest possible project you can... and then mercilessly cut -50% of the scope, for a +50% chance of actually finishing it.
In level design, a gate is anything that blocks player , usually along a .
Gating is an abstract concept, it is not necessarily a literal gate or door. It could be a magic barrier, an NPC blocking a doorway until you complete their quest, or an avalanche of rocks that falls behind the player. Anything that blocks player movement is functioning as a gate.
Gating is also a verb: "we have to gate the player inside the arena until they complete the boss fight..."
TODO: summarize some bits from Why Buildings Stand Up
Game example:
Thinking about level design more broadly, as history / community
Video games are always changing. This means that level design is also always changing. The "Culture" section of this book seeks to understand patterns and trends in level design:
What does "level design" mean to different people?
How do other disciplines and industries relate to level design?
What are other ways to think about level design, beyond a "craft" lens?
Close readings and studies of influential / interesting maps and levels
In a case study, an author conducts an analysis of a playable level or location.
A good case study identifies design strengths and weaknesses, considers typical player behavior, and compares it to other levels and games. These critical design essays demonstrate how to apply a lot of concepts from the section of this book.
For more on our recommended methodology, see .
This section is underdeveloped because right now we're focusing on finishing .
design analysis of real world architecture, physical spaces
design analysis and commentary for various multiplayer and player vs player (PvP) maps
Currently, this section is not the main focus of the project. We want to finish Book 1, Process first.
However, we do have a few pages here to give you a sense of what we're aiming for -- a mix of historical analysis, research, and cultural criticism.
When working on a large or commercial project, pre-production is a feasibility study: can this project be completed with the proposed time and resources? Is this a reasonable idea or a fanciful dream? How doable is this?
The choice of game engine and tools greatly affects which mechanics and systems will feel feasible. For example, an open world driving game in the Doom 3 engine would be very difficult to make, since that engine has no built-in support for large landscapes nor vehicles.
Feasibility is more complicated than just using your favorite game engine. Every project has different needs and goals.
Ownership: is it wise to depend on another company? Many large studios maintain their own engines rather than depending on Unity or Unreal, even though making your own game engine is obviously a lot more work.
Labor: can you recruit and retain workers? For example, a small studio might avoid Unreal if they can't resist bigger studios poaching their staff with much higher wages.
Tech-first: can you change the design to suit the tech? Imagine a job that mandated use of the Doom engine; making a shooter would be more feasible than a platformer (Doom has no jump button).
In game development, a pipeline is a sequence of steps to transform a file into a more usable format. Pre-production is when you figure out most of your pipelines.
A build pipeline makes a playable executable to distribute to players, while an art pipeline might focus on converting a 2D image or 3D model into a usable format for the game engine. Basically if you ever see these words -- convert, import, export, compile, bake -- then it is part of a pipeline.
Level design pipelines can vary a lot. Sometimes you may need separate tools or plugins to generate landscapes or construct buildings. Before 2010, it was very common for game engines to require a "map compile" optimization / error-checking step before loading the level file in-game.
Perhaps the best way to assess feasibility is to make a prototype, a small focused project that answers a question.
In 1997, Apple researchers Stephanie Houde and Charles Hill published a famous paper called "What Do Prototypes Prototype?". Houde and Hill define three general categories of prototypes:
Role: how does it meet user needs, what role does it play in their life?
Implementation: is it technically possible, how will we build it?
Look and feel: what will it look like, how does it feel?
When prototyping any of these aspects, you're make what's called a proof of concept. It might be a paper prototype, an engine tech demo, or a test level with a player controller.
When you attempt to combine multiple aspects together into a bigger integrated prototype, you're making a vertical slice -- an example "slice" of a finished game with experience design (role), some audio / visual polish (look and feel), and functional technical foundation (implementation).
Making a vertical slice forces a team to prove their pipelines. If they were able to make a good looking slice with their current tools and workflows, then maybe the tools are good enough. Or alternatively, if making the vertical slice felt impossible, then there'd need to be big changes in how the team works.
The vertical slice also helps us gauge project scope. If it took 5 months to make 10% of the project, then it could potentially take 45 months to make the other 90% of the game. (Well, obviously it's more complicated than that, but you get the idea.)
Hard gate: players must always complete the encounter with no shortcuts (e.g. wait until a timer elapses, defeat all enemies, loot a key from a defeated boss)
Soft gate: can potentially exit early, but must usually complete the encounter (e.g. exit mechanism requires staying in a vulnerable position, so most players clear the arena first)
Hidden exit: the player must explore the arena to find the exit (e.g. an exit hidden in a corner that most players won't notice until after clearing the arena)
Forward gate: player's forward progress is blocked.
Backward gate / one-way entrance: player cannot backtrack.
A lock and key gate is a hard gate that prevents the player from passing through until they find the "key" somewhere else in the level. This key is abstract -- it can be a literal key item that the player picks up, or it could be a button.
Some best practices with implementing lock and key gating:
Show the lock before the key. When the player finally finds a key, they might remember the locked door they encountered earlier. If you do it the other way around, it will feel less like the player solved a problem, and more like they accidentally stumbled on the lock with the key already.
Remind the player about the lock when they get the key. Maybe the key is on a balcony overlooking the lock, or the button is aligned with a window facing the lock. Nonrealistic projects could script a brief cutscene that shows the unlock.
If the lock requires multiple keys, the lock's visual design should hint at the key count. For example, a locked door that requires three keys should have three keyholes.
A shortcut is a hard gate that the player can unlock from the other side, allowing easier backtracking and/or better flow between areas. Exploration games often feature one way doors, climbable ladders that drop down, or elevators that turn on.
Analysis of various single player maps, usually highlighting pacing, storytelling, and encounter design.
Analysis for multiplayer maps and spaces, usually highlighting layouts, flow, and map balance.
Analyzing real world ("IRL") locations and structures from a level design perspective.
Assassins (Thief 1)
Big sprawling stealth level with dynamic pacing
Undead Burg (Dark Souls 1)
Training the player for combat and exploration

how to light night / evening scenes for dark mood while preserving readability
When lighting scenes for night or shadowy low light conditions, game developers generally follow the film industry convention ("Hollywood Darkness"): make it feel dark, but don't actually make it dark.
Early filmmakers shot their night scenes with a "day-for-night" technique: film in the early morning and artificially darken the image with a blue filter. Today, artificial lighting and better cameras mean contemporary filmmakers can shoot "night-for-night" scenes too. Some cinematographers (e.g. Steve Yedlin for Knives Out (2019)) even combine both techniques, compositing day-for-night and night-for-night shots together to create an impressionistic look.
If we light our level "accurately" with pitch-black darkness, then players can't see where to go and become frustrated.
This page builds on terms and concepts from the main Lighting page.
In real-life, moonlight is white (reflected light from the sun)... In film and games, moonlight is blue-ish. Full moon will cast stark projected shadows, cloudy evenings will cast few shadows
Fill lights = dim subtle blueish point lights with no shadows and soft falloff
Don't apply flat ambient to all shadows; you want SOME shadows to terminate into 0% black, or else you're not using the full dynamic range. Use directional ambient
Remember: don't rely on dark albedo textures to darken the scene! Let the lights create the sense of darkness. If you burn shadows into your textures, your textures will be less reusable and harder to relight, and you will force your lighting into overbright ranges to compensate.
Rim lighting to emphasize silhouettes while leaving most of the subject in shadow
With so much reliance on blue, blorange is common, but try to avoid vanilla blorange by introducing a third color or tweak hue ranges
In the image above from Overwatch 2, note the brightness, contrast, and color palette in the night time lighting scenario (bottom-right). What makes a night scene feel like a night scene?
it's actually pretty bright; what makes it feel dark is increased contrast and specular
characters are darker silhouettes vs. brighter horizon
it's not just boring blorange; there's a lot of purple and yellow mixed in
Lighting your game in a "Hollywood darkness" style results in a more polished commercial feel that matches popular mainstream visual culture.
As in film, some artists purposely want to avoid this style and its implications. If that type of mood isn't appropriate for your project's experience goals (i.e. you want to make something disconcerting, confusing, jarring, visually experimental) then you may wish to disregard much of the advice on this page.
Games with heavy use of dynamic lighting and flashlights, especially horror games, may want to selectively let high tension scenes go to pitch black darkness.
is a great 15 minute introduction to lighting and production design for night scenes by cinematographer Valentina Vee. Although she focuses on film industry techniques, much of her visual thinking is applicable to games.
"" is a 4-part 3.5 hour video series where environment artist (Crysis, Overwatch) lights a Portuguese street scene at night with extensive commentary. Much of his workflow is specific to Source 2's Hammer tool, but the general thinking is applicable to any tool or engine.
How to tell a story with level design
Many players enjoy video games for the narrative aspects. It is engaging to explore a virtual space and to meet its virtual inhabitants, and to witness how the player's actions affect the fictional game world in small or big ways. Commercial action and roleplaying games tend to emphasize the world design as a thematic "skin" to decorate levels, while walking simulators elevate these storytelling aspects above all else. Every project will emphasize environmental narratives to a different extent, based on their core pillars and design goals.
Narrative design is obviously a large complex topic that merits its own book. So here we will focus on the storytelling work that specifically level designers, environment artists, and scripters do:
is the overall plot / sequence of events in the level.
is the conceptual design of the level's setting.
Environmental storytelling
Choreography
In level design, environmental storytelling is about building a level to convey or imply a past event.
While worldbuilding is concerned with the entire fictional game world at a huge zoomed-out scope, environmental storytelling focuses on individual rooms in a more granular zoomed-in sense. What happened here, in this specific room with these specific characters?
Example: Gone Home, Everybody's Gone to the Rapture
Environmental storytelling is useful for conveying past events or static backstory in a game, but cannot portray current events in the present time. We need a different tool: choreography is a form of game narrative where in-game actors move / change in front of the camera. When a character walks and talks, a car crashes through a wall, or a monster growls from the shadows -- that's a scripted sequence, usually choreographed from a tool separate from the main level editor.
Example: Half-Life 1 scripted sequence entities, Half-Life 2 FacePoser tool, Telltale chore tool, Witcher 3 choreo tool, Unity and Unreal
In a broader sense, everything in the game should serve as narrative. Gameplay and puzzles are part of the narrative too. To tell an effective game story, narrative designer tying story tightly to a :
Your job is to make it as hard as possible for the player to finish your game without understanding your story. [...]
This means that the player must encounter, and ideally make use of, every critical piece of information in the story. “Encounter” might mean “read on screen” or “hear in dialogue” or “see in a cut scene,” but encountering information is much less valuable in an interactive context than using information. So it’s best if the player needs to act on each of those critical beats.
To design for this, start by identifying critical beats. What are the facts the reader has to know in order to understand this story?
This is a subset, probably a very small subset, of all the facts the reader could know. Many world-building details and secondary character motivations can probably be omitted without ruining the experience. But if your story’s impact depends on the player learning the protagonist’s secret motives, then that information is vital. [...]
Figure out which information is vital. Make a list. Be honest with yourself and keep the list as short as possible. [...]
Once you have your list of vital data, figure out dependencies. Which facts depend on other facts to make sense? Which facts have the greatest impact if they come after other facts? If learning the protagonist’s secret motive is more effective after we see them commit a crime, that provides a motivation for ordering. Turn your list into a dependency chart.
-- Emily Short, , 18 May 2016
Narrative design for levels ideally begins in , when conceptualizing the project's core . In , storytelling relies on a combination of , , and .
Try an environmental storytelling exercise.
Photographic / cinematic lighting theory with three light types
Three point lighting is lighting design theory used in film, theater, and photography, with three different types of lights:
(1) Key light is the main dominant light source that illuminates most of the subject or area. In most levels, this is usually a directional light (sunlight) or a bright powerful spotlight with high falloff constant (like a floodlight). Task light.
(2) Fill light brightens darker areas to avoid plunging everything into shadow. To fill a game level, we usually use ambient light and (many) invisible soft dim point lights floating in the middle of the room, but wide-angled dim spotlights are also useful when you want to direct the fill and, for example, avoid any fill splashing onto the ceiling. Ambient light, wash.
(3) Rim light highlights edges to pop the foreground from the background. Accent light.
(And in portrait photography, sometimes a fourth background light brightens up the backdrop to smooth out awkward shadows from the key and fill.)
Notice how the key light and fill light in this example are roughly perpendicular to each other, while the rim/back light is behind the subject. Pay special attention to the light positions and directions! The light source placement, relative to other lights, determines their function.
However, the big problem with using three point for games is that it assumes you have complete control over the camera. What if the player controls the camera?
Three point light types depend on the light's orientation relative to the camera -- a rim light is a rim light because it grazes the subject, but if you approach from a different angle, now there's no more rimming action -- now the rim light is a key light! If it looks like a dim shadowy silhouette from the front, it'll glow like a deer in headlights from the back. The light placement matters, but the camera placement matters too.
So in order to use three point theory effectively in games with free movement and a free camera, you need to predict how the player will utilize both.
In a first person game, that means knowing roughly where the player will be walking and looking. Fortunately, we already have a tool to constrain the player's movement and rotation: it's your level layout! If you frame a subject a certain way, or limit an approach to a certain direction, then you can place lights for that perspective. Your is a lighting tool.
The most common use of three point lighting in games is for lighting characters in cinematics / cutscenes. Because you have more camera control in a cutscene, you should draw upon more filmic lighting techniques -- because you're basically making a movie.
TODO: summarize text from these cinematic lighting cheat sheets by Derek L. Brand, senior concept artist on Psychonauts 2 at Double Fine
design exercise for a modern stealth game with cover and combat
In this project, you'll research, pitch, and prototype a combat encounter for a modern commercial stealth action game, with cover systems and combat fallbacks.
Before continuing, make sure you've read about , , and . We also recommend doing the design exercise first.
Ideally, you've played a recent stealth action game already. If you have never played any of these games, you should go play one now before continuing. At the very least, play past the tutorial level and the first mission, which will likely take at least an hour.
If you are already familiar with the genre, then take some time to review how the game plays. Search for "splinter cell blacklist gameplay" on YouTube and watch at least 10 minutes of game footage.
While you watch the video, reflect on these questions:
How do most stealth encounters in Blacklist begin? How does the player track enemy movement?
How long does the stealth encounter last? Does it feel like a small sneak or a big sneak, and why?
Are there any "beats" to the stealth encounter? What is the pacing and the fantasy?
How do the stealth encounters end? How does the player know when it's over? How does the player feel at the end and why? How does the player know what the next activity is?
Next, watch this GDC 2014 talk about Splinter Cell's stealth AI and encounter design tools. Feel free to take notes, and refer to the for reference.
Every game manages its stealth AI differently, but Splinter Cell's core approach is similar enough to other stealth action games that it represents current industry practice. An encounter designer must understand game systems as well as AI tools.
Contrast combat AI design vs. stealth AI design. What is the purpose of a "good" stealth AI? What type of experience should it push? What information does it track, and what information does it broadcast to the player?
Walsh uses "perception" and "awareness" interchangeably. Why? What is the difference, if any, between these two concepts?
Bullshit design theories that link abstract visual phenomena to universal human behavior
Shape psychology and color psychology are theories that shapes / colors convey universal ideas and influence behavior.
Supposedly, circles symbolize infinity, horizontal lines make you feel more stable, squares symbolize balance (but triangles symbolize stability!!) and apparently a drawing of a leaf makes you feel warm. Or something.
Listen, this is like astrology. It's fun to think about. If it makes you happier, go for it.
But don't take it too seriously, and don't try to elevate it to a science. Because if you try to push shape and color psychology as coherent design theory, it quickly falls apart to any scrutiny.
Abstract geometric shapes and colors, by themselves, do not make all humans feel the same thing nor communicate the same ideas.
For example, let's evaluate a common color psychology claim that "red subconsciously evokes danger," maybe because blood is red and red signals and red stop signs and video games flash red when you have low health. Sounds convincing... But is this still the case in China, quite possibly the largest consumer market for video games in the world, where red often signifies good luck, fortune, prosperity, and joy? And what exactly does red convey to the 8% of European men who have red-green color blindness? When farmers paint a barn red, are they trying to convey danger or intensity?
Shape and color are abstract phenomena that do not have universal meanings for everyone around the world. Instead, shapes and colors mean many different things in different situations, and this meaning depends heavily on personal context and audience.
"Horizontal lines convey stability"... until we see a fast flowing river strewn with wreckage.
"S-curves feel harmonious"... unless you're speeding in a car and you have to hit the brakes to avoid careening off an unexpected S-curve road.
It is easy to imagine many situations where blanket statements about shapes or colors don't work. At worst, all these blanket statements just feel blanket wrong. At best, it vastly oversimplifies how art creates meaning.
Imagine you're playing Fortnite and you see a green-colored item, indicating that it is "uncommon" tier. Does the color green scream "uncommon" to you? What about a purple-colored "Epic" item, did the designers use purple because that color inherently conveys rarity or epicness? And yet, a "Legendary" tier item is orange... does orange universally feel more valuable than purple? How do we reconcile these colors and meanings?
The answer is: we don't care about the specific colors and their connotations, because we know the specific color doesn't matter.
These color coding patterns have evolved as loot games like Destiny and Diablo implemented their own item tier systems. Colors in games mean things because of genre convention. If the color meanings feel consistent and natural, then it is more because you're immersed in a specific subset of gamer culture, not because colors have universal intrinsic meanings across all humanity.
And even if it wasn't bullshit, shape and color psychology would not necessarily transfer to a video game context.
People often behave one way in the real world, but behave differently in a video game. Player behavior depends more on game patterns, mechanics, available information, cultural framing, and roleplaying persona, rather than whether a shape is round or square.
"Pointy things are bad!"... until you need to collect pointy-shaped crystals to craft a valuable item.
"Round shapes feel safe"... until you add a dangerous enemy to your game that is round.
Game systems, and the player's knowledge of them, override whatever "natural" or "subconscious" meanings from the outside world.
For this reason, we argue that shape / color psychology doesn't address how players play games.
Maybe give humans a little bit more credit? No one sees a circle and thinks "wow I love that circle, I'm going to walk toward that circle now."
Some artists might argue that color psychology / shape psychology isn't supposed to be taken literally, or that these theories have value as simplistic guidelines to trick beginners into thinking about . To which we respond: let's make some better guidelines.
Let shape and color psychology remain as they are: convenient snake oil for fake SEO marketing blogs and consultants.
is about the science of color palettes. It is not the same thing as color psychology, because (1) it's actually real, and (2) it makes smaller claims about how colors work.
is the study of signs, and it's really complicated.
if you can afford it, register your own domain
don't use wix... a free wordpress is probably better
if your portfolio is visually oriented, just make an artstation
say what you are at the top
remove all the crap from the web template, delete everything except the home page
don't write too much
include 3-5 screenshots and a short video, and links to external websites and reviews
imagine you're a bored manager scrolling through your e-mails
show that you are following industry discourse and industry figures
helps you pretend you know people, helps you memorize names
1 page at most, less text is almost always better
include your name, portfolio URL, and desired dev role
don't put your GPA or your minor, but list any big awards, grants, scholarships
don't pad your "skills and interests" section, imagine reading 40 of these and it won't seem as cute
omit your home address or phone number, you're putting this on the internet
include a PDF in case they want to save and download it, etc
your CV has two functions: (1) list your work experience and qualifications, and (2) give your interviewer stuff to ask you about... don't bore them
after every project / before you apply
Anthony Panecasio:
Magnar Jenssen:
about this book project, its authors, and any credits
The Level Design Book is a free nonprofit project run by volunteers.
Level design is a bit of a dying art. Modern industrial workflows and the popularity of procedurally generated content mean that level design, as traditionally understood in the 1990s, feels increasingly less relevant to contemporary game genres and trends.
And yet, many games (and companies) still need level designers -- and today's beginner level designers don't have any good learning resources to use.
The past generation of level designers came of age in the 1990s / 2000s, benefiting immensely from the unique bespoke online level design communities of Web 1.5 -- easily sharing and building knowledge with peers. Today, all that knowledge is much less accessible and discoverable. The entire internet has been commodified into a handful of all-purpose social media networks, and search engines have generally become much worse / less helpful.
There are many ways out of a dark age, but here we're going to try a renaissance model and revive the old ways: write words on a page (and edit these words!!), hand-curate links, and centralize information on an independent website external to a social network.
Stage 1: write a book with solid text, links, and illustrations; good coverage on all topics
Stage 2: transform into a living book; follow inspirations like Nature of Code and Book of Shaders, which offer design tools and exercises within the text itself
build a simple web embeddable 3D level design tool with blockout, playtest, and basic game elements
interactive examples
Stage 3: ???
These people have written the bulk of the text in this book, and collectively edit contributions.
Robert Yang is the founder of this project. As an indie game developer, he is most well-known for his Radiator games about sexuality and intimacy. In the past, he also contributed levels to projects like Black Mesa Source, and conducted interviews with level designers for Rock Paper Shotgun. (https://debacle.us)
These people have contributed substantial research, writing, or assets to the book.
Andrew Yoder has worked on Paladins and Warframe, and specializes in multiplayer social spaces and combat design.
The Level Design Book logo is made of icons from The Noun Project by Maxim Kulikov and Priyanka.
And generally, much of the material from this book comes from many different authors. We strongly believe in the importance of crediting, and we attempt to cite and link back as much as possible. All this attributed content belongs to these respective creators.




What is a level, what is level design, and how to use this book
A level is a space where a game happens. Some examples:
the Fortnite island, an obstacle course ("obby") in Roblox
a basketball court, race track, or playground
a Monopoly board, crossword puzzle, coloring book
All these game spaces set boundaries for players to move and interact.
Different levels offer variation. For example all basketball courts have similar shapes, but an outdoor court and an indoor gym offer different experiences, cultures, and moods.
Level designers focus on how different game spaces can make players feel and behave.
We define level design broadly, but with a specific disclaimer:
Level design is the practice of planning and building spaces for video games...
... usually first-person or third-person action shooters.
This book is still useful for sidescrolling platformers, top-down strategy games, or non-combat games. But for better or worse, most level design theory engages with 3D shooters as the default medium, dating back to the invention of the level designer role during the shooter-heavy 1990s.
For more about the history of the level designer role, see .
Level designers focus on shaping player behavior. In large studios, they often write documentation, draft , build , observe , and maps and .
In contrast, an environment artist focuses more on graphics. They models, materials, set dressing, and to refine the level's visual appearance. While this is mostly decoration, good environment art supports experience design goals and helps players play.
So there are two ways to understand level design:
formal industrial sense of capital-L capital-D "Level Design" without environment art
broad common sense "level design" includes environment art / anything in a level
In this book we emphasize the formal industrial "Level Design" for learning purposes, but always remember that your players engage with broad common sense "level design" as a whole.
Level designers can spend days or even weeks designing a single room.
But for a huge battle royale, open world, or MMO with hundreds / thousands of rooms, agonizing over a single room is impractical. A world designer considers and for neighborhoods instead of houses, biomes instead of places, categories instead of instances. This generic approach lets players and systems breathe. But without players or systems to fill that void, the resulting world may feel empty or bland.
To build a directed or scripted experience, obsess over every room like an architect.
But for player-heavy system-heavy games with lots of space, world design offers the lighter touch of an urban planner.
This is a book, so obviously we think reading is good.
But as with any other art, a book can only introduce you to the craft. At some point you just have to close the book and go build some levels.
If you ask a Quake community mapper a lot of questions, there is a tradition to respond with the blunt answer: "go map." This curt expression might seem rude but it intends to nurture -- as if to say, "stop procrastinating, you'll figure it out; now go try to do it, you're ready."
The only way to become a level designer... is to make levels. Ideally, a lot of levels.
Don't know what to make? See our list of suggested .
This book was written with specific ideals and beliefs about level design.
Most level design books are either too academic and conceptual, or too commercial and reductive. We aim to explain and expand the same language that working level designers use, while also remaining critical enough to prune lazy thinking.
Level designers often lack language for discussing shape and volume, and benefit greatly from the architectural concept of . We cite outside concepts without realizing the deeper roots; for example, come from critical path method, a scoping and dependency-checking tool in engineering. When we're imprecise with words and theory, thinking and communication suffers.
Although level designers should focus on player behavior, sometimes we must zoom out and see the big picture.
A level is a combination of spatial design, art, psychology, programming, and culture. From the player's perspective, there is no difference between level design and environment art. Anything that affects the game world is level design.
Avoid the lure of simplistic dos-and-don'ts. Levels are more than collections of rooms and cover boxes, and more than landscapes with rocks and trees sprinkled on top. A level possesses history and culture and intent, and as responsible designers we must consider the entire play experience.
The printed format tends to doom level design books to obsolescence within a few years. Fortunately, this book lives online. For the foreseeable future, we intend to continue updating the book as new developments or trends in level design emerge. Don't die.
This online book will stay free and open access until its servers shutdown -- and even then, its content will likely be archived across the internet. The level design community collectively made level design, and so it should continue to belong freely to the community. We will never paywall this book nor sell any copies of this book.
Unattributed book text (and unattributed images / content) are under a permissive Creative Commons BY-NC-SA 4.0 license. You cannot sell this book nor sell any ports / translations. All copies, translations, and derivative works must remain free and open access.
The book consists of four sections:
details core level design concepts, and it is essential for beginners and students who need to learn level design workflows and language. Most readers should start here.
covers level design trends from various perspectives, and offers short primers on the history of architecture, lighting, and other crafts adjacent to level design.
analyze and unpack how a particular level works, accompanied by diagrams and screenshots.
are self-guided tutorials and project ideas for students and hobbyists. Teachers should check .
There's also an appendix, featuring a list with recommended software and game engines, and links to additional level design (free models and textures, recommendations for other level design books, etc.) Lastly, we strongly recommend joining a level design , because a book can't love you back.
Beginners: get a general understanding of the , especially , , and . Then pick a , join a level design , and go map.
Somewhat experienced: read about specific topics such as , , , , , and that usually go neglected in most online level design tutorials.
How to measure and design modular kits, 3D tilesets for building levels
When doing a or , you might use a modular kit -- a 3D tileset of modules, meshes designed to snap together. This comes from the real-life building practice of .
If you're new to 3D modeling or level design, then don't attempt to design your own kit yet. Many considerations go into designing a robust kit. Your first kit will probably be very hard to use, especially if you haven't learned from using other peoples' kits already. Instead, see our list of to download a free pre-made modular kit suitable for prototyping.
But if you have experience in level design and 3D tools, then you are ready. On this page we will detail the many considerations and best practices for designing your own modular kit.
vertical flow, how it feels to move upwards and downwards in a level
Verticality is vertical flow, how it feels to move upwards and downwards.
Imagine steadily climbing up a cliff or descending deep into a dark dungeon. These height changes embody the player's progression, and help orient the player towards their goals. A quest might tell the player to travel north, but that goal is impossible if they can't tell where north is. Instead, if the quest tasks the player with climbing to the top of a mountain, or descending down to the bottom of a valley -- up and down are much more obvious and unmistakable.
When discussing verticality, we assume we're designing for a typical 3D action game with two common physics constraints:
All cited material, illustrations, quotes, game screenshots, video embeds, game content, etc. belong to those original creators or studios. This book includes such content for non-commercial educational purposes under doctrine and we always attempt to credit and link back to original authors as much as possible.
Because of the complex communal authorship of this book's material, we will never paywall this book nor sell any copies of it.
And for a similar reason, we generally do not include material from other level design books, because fair use is less clear in these cases. You should purchase and read those books instead.



We also take a strong stance against "leading lines" and against shape psychology / color psychology, arguing these theories are either misleading, ineffective, or of limited use to level designers.
Very experienced: see our critical design Studies, and maybe even contribute some of your own.

do you have a lot of level designer time, and need to reuse limited art assets many times?
planning kit percentages, decide what is most important first
how granular / chunky should the kit be? depends on what level designers need / want, more customization OR faster prototyping time?
DO NOT MAKE VARIANTS YET, just build basic pieces first
decide on your units... build to a human scale
floor, ceiling, wall, doorway (single), doorway (double), window, corner
platforms (landscape)
glue
flanges and arches (caves)
shells (caves)
stay in footprint / bounding box
pay attention to naming, level designers and kit artists need to agree on a pattern
Epic's recommended naming scheme?
do NOT just stop at an ideal case
collision is one of the biggest issues, make sure you can't get stuck?
can you build multi-level environments? floors should NOT be paper thin, they have thickness and mass just like walls
do you have enough glue for interior kits with off-angle construction? essential for tunnel or cave kits
texture variations go a long way, and are "cheap" -- you don't have to test and validate the module geometry again
consider building a tool for easily swapping in module types, which will make art pass and remesh much faster
As mentioned at the top of this page, much of the info here comes from two excellent GDC talks by Joel Burgess, which are a must-read for anyone doing modular construction:
"GDC 2013: Skyrim's Modular Approach to Level Design" (slides) is the "101" introductory talk to modular kit design considerations, and how they approached building out levels for Fallout 3 and Skyrim, while avoiding the worst of Oblivion's sins.
"GDC 2016: The Modular Level Design of Fallout 4" (slides, video) is the "201" intermediate talk that elaborates on what they did for Skyrim's modular kits, and expanded when building Fallout 4.
"Modular Level and Component Design" by Lee Perry for Game Developer magazine, Nov 2002. A solid article by the lead level designer on Gears of War (2006), one of the first game dev writings to detail modular construction practices -- which only began emerging in the early 2000s when brush-based CSG construction began falling out of fashion. Included here mainly for historical interest; compare against History of the level designer.
gravity pulls the player downward
the player camera rarely "rolls", sky and horizon are always upright
If you change any of these assumptions, then "up" is no longer upward, and thus the player's sense of verticality will be different. For example, verticality in Super Mario Galaxy is very different from verticality in Dark Souls.
(TODO: image compare verticality in Super Mario Galaxy vs other game)
Many competitive multiplayer shooters and arena-based games require careful limited use of verticality.
(TODO: rollerdrome tweet)
For example, in Counter-Strike, competitive players tune their mouse sensitivity very low because precision matters more than reaction. Subsequently, constant height changes will frustrate their aim, so most CS levels are relatively flat.
That said, CS features a stacking / boosting mechanic where teammates can jump on top of each other to see over obstacles or reach otherwise inaccessible places, thus rewarding team planning and coordination. Vertical flow can be situational and strategic.
When planning the verticality in a level, try to chunk it together into floor planes and merge minor height changes into a single floor. Don't try to hold 10 different distinct overlapping layers of floorplans in your mind, because players probably won't be able to process that much complexity either.
Most maps tend to max-out at three different floor planes for any given area. Why three? Much like three lane typology, three plane format consists of a bottom, middle, and top layer. Comparatively, a fourth (p)lane doesn't add new dynamics, because it would simply yet add another middle layer or path.
(image demonstrating floor planes)
With gravity, it is easier to drop down than to climb up. Downward flow is heavier than upward flow.
The most common use of downward flow in level design is the one-way drop. When the player drops down from a ledge, they cannot backtrack and have no choice but to move forward.
Puzzle exploration games use this technique to limit how much space the player must consider at a time, it's a way of saying "everything before this drop is irrelevant to the next challenge." Shooters rely on this pattern heavily to force the player into a combat encounter, or else the player can simply backtrack to pull enemies back through a chokepoint.
(image showing one way drop)
To push against gravity and create more upward flow, you'll have to work hard to create more opportunities to go upwards. Stairs, ramps, and ladders are all common tools to facilitate verticality, but require you to reserve enough space to accommodate them. (Elevators are less common due to their scripting complexity, especially for multi-floor elevators.)
The Quake 3 Arena (1999) multiplayer space floater map Q3DM17 "The Longest Yard" famously used a dozen jump pads and teleporters to create strong upward flow. Because there is very little cover and limited floor area, players must dodge gunfire by flying through the air, while being careful not to fall to their deaths. The designer Brandon James balanced the verticality with the far platform pictured in the lower-right; here, snipers can easily dodge incoming rockets while sniping all the players taking predictable flight arcs.
Shooter games on consoles face unique level design challenges relating to input. Because console gamers use gamepads with analog sticks, the fixed turning rate from the analog stick makes it much more difficult to rapidly turn and track targets. In contrast, a mouse offers much more acceleration and precision. But we're not here to litigate a gamer spat over which input is better -- we're just here to say, if you anticipate your level will have a gamepad-using audience, then you must design accordingly.
For single player levels, that means spawning enemies behind the player ("backspawning") feels extra unfair because the player won't be able to turn around 180 degrees very quickly, and also flying enemy AI must maintain moderate distance and remain at a stable height.
For multiplayer console shooters like Halo or Call of Duty, players often park their camera's vertical rotation aimed at roughly head / chest height, and restrict their aiming movements to the horizontal axis. Levels for these games rarely incorporate very tall height changes, if ever, because it is so taxing and disadvantageous to force players to look very high or very low.
This type of shooter gamepad input only feels good if the level design supports it: lots of wide open landscapes with shallow slopes, and discrete floor planes that remain relatively flat. The left example below has high frequency height variation which will frustrate gamepad users, while the right example uses smoother slopes and flatter floor planes.
(TODO: image)
If you are one of the copyright owners impacted by our website and you want your content removed from the page, please contact an editor with (1) the URL to the page in question, and (2) short description of the content to be taken down.
All unattributed text in this online book is hereby licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license.
You can publish or distribute this book / translations of it, whether in part or in whole, under these conditions:
You cannot sell the book, nor charge for access to it (no paid subscription or license fees)
You must attribute us prominently within the body text of your copy, and link back to this website
You must also license any of your modifications under the CC BY-NC-SA 4.0 license, and prominently state this license in the body text of your copy.
Content creators and video makers: if you make a video that explains, summarizes, or paraphrases the content of this book, then please (1) audibly cite this book during the video, and (2) link back to us prominently in the video description + text chat.
Anyone else: attribute us with (1) "The Level Design Book", and (2) a link directly to the book page URL.
Students: see How to cite this book.
If you're writing a research paper, here are common citation formats for your convenience. Make sure you replace the ALL-CAPS fields with your own citation data.
“PAGE TITLE.” The Level Design Book, PAGE URL. Accessed DAY MONTH YEAR.
"PAGE TITLE", The Level Design Book, accessed MONTH DAY, YEAR. PAGE URL.
PAGE TITLE. (n.d.). Retrieved MONTH DAY, YEAR, from PAGE URL.
ACM:
The Level Design Book. PAGE TITLE. Retrieved MONTH DAY, YEAR from PAGE URL
This is a human-readable summary of (and not a substitute for) the license. Disclaimer.
You are free to:
Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:
Attribution — You must give , provide a link to the license, and . You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
NonCommercial — You may not use the material for .
ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the as the original.
Notices:
You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable .
No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as may limit how you use the material.
how areas link to other areas, the "connectivity" of a map
In architecture, circulation generally refers to the "in-between" areas that connect other areas, like hallways, aisles, and stairs.
Some level designers call this connectivity. But for this book, we think circulation is a better word and concept that more level designers should adopt.
Real world architects distinguish between several types of circulation:
Primary vs. secondary circulation (path to main elevator vs. path to storage closet)
Public vs. private circulation (ground floor lobby vs. bedroom hallway)
Horizontal vs. vertical circulation (hallway vs. stairs)
Many of these concerns often don't directly apply to level design. Unlike sad unfortunate real world architects, we can design virtual buildings without any concern for building codes, ordinances, or thermodynamics. However, these words and concepts are still useful.
In level design, there are at least two more different types of circulation:
Diegetic circulation: look and feel of the circulation, the in-game fiction of the space.
intersects with and
crucial for single player levels, especially in a realistic style
Diegetic circulation refers to how fictional in-game characters would use the space.
In film studies, diegesis is the imaginary fictional world depicted on screen. Ask yourself, how would players roleplay their movement through the level? What is the theme of this space? What is the story behind this circulation pattern?
For single player levels, conveying circulation is crucial for . If you want your level to feel like a plausible real-world space, then you must also think like a plausible real-world architect with plausible real-world circulation.
When designing their exploration game Gone Home (2013), The Fullbright Company chose to work with an old mansion theme because modern suburban houses orbit around a central room with flat dense connectivity, but mansions branch deeply into distinct wings. This mansion trope supported the hub-and-spoke they wanted, which helped them tell the story they wanted.
The first half of Gone Home's critical path starts from the "Front Porch" (bottom center) and ends in the Basement (top left) while frequently backtracking on itself, resulting in a free-form exploration feel that supports Gone Home's experience goal of investigating an empty mansion.
It wouldn't feel like an investigation (nor a mansion) if every clue led to a new area. Instead, we learn to dwell in this space and grow more familiar with it. In this way, architectural research is crucial for levels focused on story, otherwise the diegetic circulation may not support the desired critical path.
Players follow circulation based on their current objectives. If they must find the exit, then players will follow primary circulation. If they need to reach the roof, players will look for vertical circulation. If players need to sneak around or explore for resources, they use secondary circulation.
Generally, wider bigger passages feel like primary public circulation, while narrower areas will feel more like secondary circulation. But imagine walking in a level and seeing a big wide door and a smaller narrower door. Which door leads to the exit? The big door could lead to primary circulation and an exit. But if the bigger door looks like a garage door for a vehicle, then maybe it's locked and we should take the smaller door... so now the smaller door is more likely to feel like primary circulation...
For more on player navigation, see .
Formal circulation focuses on the layout's physical function (the "form") and affordance for movement.
Here we ignore the theme, setting, and culture. Think about the level in terms of abstract level geometric shapes. Ask yourself, how would a professional player or speedrunner understand this map?
Lanes are formal primary circulation in a multiplayer map.
Lanes help players predict and coordinate movement. A large map with too many lanes or no clear lane hierarchy will function like a maze; players won't know where to focus their efforts, get lost, and miss each other.
For this reason, most maps use only 1-3 lanes.
Payload maps for team-based multiplayer games like Team Fortress 2 and Overwatch focus gameplay and conflict along a single lane that snakes around the entire map. The attacking team must "push" the payload cart forward by standing near it, while the defending team must prevent the cart from reaching the end of the lane. The payload route is prominently marked so that players can easily coordinate efforts (or prepare ambushes). Occasionally, there are extra half-lanes and back alleys to help attackers break through defenses.
Lanes are also common in competitive multiplayer games about territory control such as in MOBAs like League of Legends or military shooters like Call of Duty and Counter-Strike. These games' maps often use a three lane format, three bidirectional critical paths that occasionally branch and intersect via smaller lanes. (In MOBAs, the tangle of smaller interstitial lanes / secondary circulation are collectively known as the jungle.)
If an opponent has blocked progress on one lane, then the other player(s) can attempt to flank around them by advancing on another lane. Alternatively, if a player wants to try to avoid conflict entirely, then they can avoid the main lanes and try to farm the jungle.
Lane asymmetry is important, each lane should feel different. In Summoner's Rift (League of Legends), the top and bottom lanes are longer than the middle lane, and the top lane has a powerful boss while the bottom has a weaker mid boss. In de_dust2 (CS:GO), teams must decide whether to focus on site A or B and how to approach or flank; or if the team chooses poorly, they might need to move through the mid lane to the other side of the map.
Rotating (primarily in Counter-Strike) is when players must move from one lane to another. It generally requires teamwork and coordination, and the tension between rotating vs. not-rotating is a core element of team-based competitive multiplayer games.
how to script and implement sliding / rotating wall panels (aka doors)
Functional doors are notoriously one of the most complicated objects to implement for a video game. On this page, we will outline why doors are so tricky and difficult, as well as various time-tested strategies for scripting door behaviors in levels.
A rotating door is dynamic level geometry that blocks visibility (sometimes) and blocks movement (sometimes), can be interrupted or locked or destroyed, might be obstructed by inanimate objects or characters... This wide-ranging combination of possible states results in many edge cases that are difficult to handle gracefully.
For an introduction to door dilemmas, see Liz England's blog post "The Door Problem" which touches on the door as a tricky intersection between all departments at a large game studio.
The simplest, most stable bug-free type of video game door is no door. So before you add a door to your level, ask yourself, do you really need a door there?
However, if you must have doors, we discuss two categories of door problems: movement and state.
First, decide on the type of door movement to implement.
Sliding doors are much simpler than rotating doors. They can recede into a wall / floor / ceiling, and cannot be easily blocked from opening. However, a sliding door does imply a powerful or industrialized society that can manufacture and operate sliding doors, e.g. a huge portcullis, canal lock, sensor-based glass supermarket door, or futuristic sci-fi Star Trek door might be inappropriate for your level's fiction.
Rotating doors sweep over a large area and easily trap objects, and can be easily blocked from opening or closing by standing in the way. This makes their physics more complicated than sliding doors. Yet they are much more mundane and commonplace in the real world than sliding doors, and imply non-futuristic worldbuilding.
For most door physics problems, err on the side of player convenience, even if it's unrealistic or unfair. That's our basic guiding tenet behind these general practices for handling door movement and collision:
For convenience, rotating doors should be double-hinged and open in both directions, outwards / away from the character opening the door. (via )
If NPCs can use the door, their AI should "pinch" through the doorway and avoid blocking others. If NPCs have pathfinding AI, dynamically generate or manually place AI hint nodes to force NPCs to stay away from the door unless they are using it. (via )
If the level is about exploring, let opened doors remain open so that players can track where they have been. But if the level is about high tension or combat, slowly close doors automatically behind the player to simplify the encounter space. (via )
Levels often have a variety of doors, so the core door script must support different behaviors. If there is no pre-existing door entity in your toolset, you may have to engineer your own.
The most basic type of door has two states: open or closed.
But an animated door can also be moving -- opening or closing -- and some doors could be partially-open (ajar). You might need OpenStart, Opening, OpenFinished events, as well as CloseStart, Closing, and CloseFinished events. These different events provide useful places to insert sound hooks, animation, or physics impulses.
Some common parameters and settings to expose for a door object:
moveDistance / rotateDistance, in engine units (sliding door) or degrees (rotating door)
some projects or use cases may need a configurable axis of movement (e.g. a drawbridge does not rotate around its "up" axis)
rotating doors need a hinge
Additionally, you may want to expose different ways of opening or closing the door for level designers. Implement basic Open(), Close(), and Toggle() functions, as well as a ForceOpen() or ForceClose() variant that might apply additional physics hacks or teleportation to ensure the door changes state regardless of obstacles.
The simplest locked door state is true / false. However, this binary doesn't always reflect how we use locked doors in level design. Locked doors can become surprisingly complicated:
What if some locked doors can always be closed, while other locked doors cannot be open / closed no matter what? These are two different types of locked door.
What if some locked doors are fake doors that lead nowhere and serve only as set dressing to fill wall space and imply diegetic circulation? This is another different type of locked door.
What if some doors can be lockpicked, but certain quest-related critical path locks require the specific key? (e.g. Skyrim) These are yet another two different types of locked door.
Most furniture has at least one of four functions: (1) sitting, (2) tabling (work, display), (3) storing, (4) sleeping. But function is just one way to think about furniture. Furniture and its placement also reflects social status, wealth, culture, technology, climate, and personal expression. When we craft and place virtual furniture in our levels, it reflects all these understandings.
In level design, furniture is certainly crucial for environmental storytelling narratives and set dressing in an art pass, but it also implies a formal gameplay function. If you're playing a contemporary cover shooter and you see an antique wooden chair, then you would understand it as movable soft cover. If you're playing a game with crafting and salvage systems, you might break down the chair for a small amount of wood. If you're playing a battle royale or prop hunt multiplayer game, then a misplaced chair would suggest someone has visited that location. Furniture is part of the game state!
Two brief disclaimers:
This history is biased toward a Western understanding of furniture, and as with most material histories, it's also biased toward rich people because their objects get preserved and studied.
We approach furniture from the needs of a level designer. This page is less about the specific history, and more about how to furnish your level effectively, organized by historical time period and culture.
Neolithic artifacts depict people sitting, like the .
.
It's hard to know a lot about ancient furniture because most wood pieces have decayed / disappeared. Our knowledge of ancient furniture comes from historical accounts, carvings / paintings, and rare preserved pieces from volcanic disaster sites and tombs.
The most common piece of furniture around the ancient Mediterranean was a wooden stool with low rectangular seat and 4 legs. Common Egyptian stools had woven reed seats, and a Greek diphros often had turned (rounded) legs.
Public places had built-in stone benches, or people would bring their own X-shaped folding stools.
Chairs were generally reserved for upper class or the elite. Greek thrones, klismos, and klinai had elegant sweeping lines. Egyptian chairs were more angular but still very refined and clean, more advanced than a lot of medieval European furniture.
Built-in stone counters and tables were common. Greek tables were low, rectangular tops with 3 legs, usually next to a klinai for upper class dining.
Ancient containers
Ancient Egyptian furniture: didn't change much for thousands of years, but pharoahs furniture have very fine wood working, better technicals than most medieval furniture... very clean lines and shapes, almost modernist
Common ancient Greco-Roman furniture: mostly built-in benches, stools, and counters... if you did have a table, it was low and movable to stow away when you weren't using it
Rich Greco-Roman people had couches and X-shaped folding stools (imported from Egypt?) (Roman politicians)
Greco-Roman chairs symbolized power: thrones
Chairs and stools were somewhat rare in Asia and the Americas: common to sit on the floor or on a mat
rich people were basically nomadic, would move around a lot (easier to follow food than to bring food to a centralized place) so they used lots of chests, small movable furniture, and tapestries / cloths decorate the permanent furniture they'd leave in place... then pack everything up and move on to the next residence
Since rich people signaled wealth through possessions, high emphasis on sturdy chests + tiered buffets to display fancy silks, plates, and artifacts. Dye is very fancy!
Chairs still aren't super common. Throne with foot stool, raised on dais. Height is very important. Commoner can sit on a chair by themselves, but in the presence of a monarch they must sit on benches and stools, if at all. Benches are the most common seating
Rooms are mostly empty, furniture pushed to the side when not in use... Tables were brought out and setup for events / dinner, then stowed away... again, remember the furniture is purely functional, the tablecloth is the actual decorative element
Tables are long, everyone sits on one side with their backs to the wall... powerful couples sit in the middle
The one big exception is churches, which weren't nomadic, so they could have huge elaborate carvings with big heavy furniture
This is where furniture and architecture intersect; furniture carved like a building
Tools were hung on walls, free-standing wood shelves were rare (!), usually wood planks set into a wall cavity instead
Printing press made Renaissance / study of antiquity possible... equipped with manuals, Renaissance artists make better Classical copies than Medieval artisans
Rich people are finding enough stability to settle down and permanently decorate, e.g. Venice ...
Furniture craftsmanship now becoming complex enough to form specific guilds, e.g. joiners ... 1500s sees upholstery, drawers, and matching furniture to interiors... Queen Elizabeth orders marble-topped tables
Tables are broader and less long, everyone sits on both sides, important couple sits at the ends of the table
Carved buffet
In Spain, leather is more common than wood? (Moorish influence treats wood as a rare decorative material vs. structural material)
in Europe: rise of English and French furniture export industries, English furniture was boring but high quality, French furniture was trendy and luxuriously expensive but lower craftsmanship
in England: Lots of trade, lots of interest in India (caning seats) and China (lacquering)... "the Chinese fashion" in 1700s... Lacquered chest on a stand... rise of ebony... large mirror (very expensive) with marble-topped side table and china displayed on top. "Japanning" is English imitation of Chinese lacquer
in France: Rise of upholstery, comfort, modern ideas of luxury (Versailles) ... Rich people bedrooms were social spaces where you receive guests (pg 84), but also now separation of public and private (e.g. petit-apartments in Versailles vs public courtly rooms), invention of the dining room
Renaissance humanism: understanding, classifying, collecting diverse materials and styles of the world... even more specialization of craft (pg. 99) ... Pinnacle of carved furniture and veneered cabinets ... rococo
English Regency, Greek revival, French Empire (Napoleon)
in England: neo-classical counter-reaction, Invention of the classic "timeless" chair, country joiners repeated the same chair and table over and over (e.g. American Shaker ladder back, stick-back Windsor) ... Rise of middle class, good furniture becoming more common
In the US: rocking chairs offered to guests
Sprung upholstery, Chesterfield couches, new focus on comfort and coziness... birth of furniture placement and filling a room with furniture (pg 133)
Thonet bentwood chair!!!
Lucie-Smith, Edward. Furniture: A Concise History. Thames and Hudson: 2005.
psychological / architecture theory about how people seek vantage and safety
Prospect-refuge theory is a widespread belief in architecture that humans have an "inborn desire" to seek out prospect (vantage points / lookouts) and refuge (enclosures safe from threats / view).
This book argues that prospect-refuge, as traditionally understood, has limited application to level design. Risk / safety / information in video games often differs greatly from real world architectural assumptions. (And frankly, we're also skeptical whether it's useful for real world architecture.)
At the end of this page, we suggest an alternative application of prospect-refuge theory, using already existing terms and concepts in level design.
(TODO: prospect refuge illustration with big red Xs)
In his 1975 book The Experience of Landscape, geographer Jay Appleton combined psychologist Daniel Berlyne's "arousal theory" with early evolutionary psychology to form his prospect-refuge theory. It's worth tracing how this happened.
In the 1950s and 1960s, Berlyne experimented with lab rats and curiosity. He argued that when a lab rat (or a human) sees a new space, they feel "aroused" as they process the unfamiliar environment.
Note that Berlyne does not mean sexual arousal, but instead something more like engagement -- a general state of increased energy expenditure and mental responsiveness. That is, a more complex and novel environment stimulates more arousal / engagement.
However, too much complexity and novelty is negative. In his 1960 book Conflict, Arousal and Curiosity, Berlyne cautions that too much of this environmental arousal can lead to anxiety and uncertainty. When graphed below, it is a "U-shaped" effect:
The basic premise of evolutionary psychology is that humans are just like any other animal with survival instinct. Appleton reasoned that Berlyne's environmental arousal also aided human evolutionary fitness. Increased mental responsiveness would've been useful for a caveman / early human to parse threats and find safe places from predators.
Outside of psychology, no really cared about this until 1988, when architectural historian Grant Hildebrand popularized Appleton's prospect-refuge. Hildebrand wanted to strengthen modernist architecture's claims to universal design and function, and so psychology was an effective way to argue why architect Frank Lloyd Wright's buildings supposedly had intrinsic psychological appeal -- culminating in his 1999 book Origins of Architectural Pleasure. (Maybe these men were indeed alluding to sexual arousal.)
There are several ways to critique prospect-refuge theory, including its science and philosophy:
Berlyne's behaviorism and psychology of aesthetics
does studying lab rats' aesthetics actually teach us anything about human aesthetics?
can art and aesthetics be studied in this way at all?
At first glance, prospect-refuge theory seems very applicable to games. It is about survival and safety, like many 3D action games. But for the many reasons listed above, we think it is better not to rely on it.
We argue that these same ideas are more useful if we utilize already existing terms and concepts in level design instead. These industry-specific terms have less philosophical baggage and offer more technical specificity, especially for combat games.
Instead of prospect, use sightline / vista.
Instead of refuge, use cover / enclosure / base / safe house.
A sightline is a line of empty space where one area can be seen from another area.
A vista is a vantage point with access to many distant sightlines. It is most useful in single player level design to convey progression beats, preview landmarks, and offer layout information -- especially for an arena layout before an encounter begins.
(TODO: link to specialized sightline and vista pages)
The problem with the word "refuge" is that it implies safety. But the video games, the player's sense of safety is complicated, and extends far beyond the level design.
For many action games, threat assessment is a core mechanic / skill that players must develop over time, dependent on the overall combat design.
Survival and death systems also vary greatly between games: some may reward players for death, or even penalize survival.
A dozen hours into the action RPG Elden Ring (2022), the player enters a "debate parlor" in a magical castle. When most players reach this point, it will feel very dangerous.
In Elden Ring, the most difficult boss enemies tend to inhabit highly decorated landmark areas. So the unique art assets here differentiate the room from past rooms, it stands out as a special area of high importance.
The player has reached this point after fighting through 3-5 encounters, and is probably wondering where the next save point is. Past boss arenas featured convenient save points before the fight; this one does not, and pushes players to risk their progress.
(screenshot: debate parlor entry)
Suddenly, a giant glowing wizard wolf begins growling at the player.
The wolf has a name and a large health bar, indicating it is a dangerous boss enemy.
The medium-sized room makes the large wolf feel even larger. It will be difficult to dodge the wolf's attacks.
Furniture and clutter further limit the player's mobility and options. (Until the boss destroys the furniture, opening up more floor space, making the fight a bit easier.)
(screenshot: battle begins proper)
Note all the factors that make the situation feel dangerous: the UI, consistent use of environment art, the past encounters and progression system, even the music.
After defeating the boss, only a quiet "grace" campfire-like save point remains. This landmark boss arena now functions as a safe house, territory won by the player after a difficult battle. The chaotic half-demolished parliament chamber now takes on the mood of a peaceful ruin.
This is the same room, but it undergoes three different state changes before, during, and after the encounter.
sense of safety depends less on layout / blockout / architecture, and instead more on the wider game systems / encounter design patterns
game worlds change ownership and function much more frequently than in the real world
something won't "look safe" if past levels featured traps or ambushes
Thus, "refuge" is a situation / game state, not a formal quality of architecture. No shape or layout is intrinsically safe.
So what word should we use instead of refuge?
We propose enclosure: the degree that an area is surrounded by cover.
Cover is any object that blocks a sightline and/or combat.
TODO: base / safe house
Recommended level design books... other than this one
As discussed in the introduction, remember that there's different types of level design. Thus, there's different types of level design books.
We generally don't recommend any pre-2000s level design book. A lot has changed in 20+ years. The game industry and culture is very different, not to mention the tools, workflow, and language.
As discussed on our license / copyright page, we generally avoid including content from other level design books. You should borrow / buy these books yourself.
Generalist books approach level design as one aspect of a much larger design problem. These types of books are usually written by academics who have studied this topic from multiple angles.
If you are more of a big picture type of thinker, or if you're suspicious of the game industry, then these are the books for you.
However, zooming-out also means missing out on more specific technical details. This philosophical focus can feel unhelpful for beginners wrestling with a level editor.
(2014) by Christopher Totten is a theory-heavy generalist level design textbook. Totten connects a lot of core architecture education (basic drafting, parti, prospect and refuge, etc.) to some game examples. A good roundup of conceptual design theory.
(2017) edited by Christopher Totten is a collection of case studies covering many level design topics from a variety of academics, critics, and devs. This diverse survey is useful for gauging our collective understanding of level design, but all these different contexts vary greatly in aim and approach. What does a Yakuza player's personal essay have in common with a research overview of PCG methods? An interesting question, though the answer won't readily apply to beginners.
Industry books are written by working level designers who have shipped some 3D AAA action shooter games. They tend to have a narrower focus than generalist academics, zooming-in on specific techniques and situations. For beginners, this will seem better than non-industry academic philosophers.
To become this specific, there is a price -- these books must make a lot of assumptions about genre and audience, and they rarely imagine any larger overarching theory. It often reads like a pile of random do's and don'ts. But if your creative goals match the industry's, then you'll find a lot of useful advice here.
(2008) by Sjoerd "Hourences" De Jong is among the best 3D level design books available, though some of it has aged poorly since 15+ years ago. Yet De Jong is an experienced industry developer who has built lots of 3D levels, and much of that work experience reflects his straightforward advice and examples. Given the book's age, familiarize yourself with the , or else De Jong's golden age fascination with low poly construction might not make sense.
(2020) by Max Pears is maybe the first (and only) encounter design book ever, with lots of diagrams with cute cartoon illustrations. However, note that Pears assumes you're not just making a shooter, but a fairly specific military-themed shooter with specific enemy types and weapons, etc. Still, he offers a lot of useful language and patterns for combat games.
Prestige AAA release often feature companion "art books" which show lots of process images and asset breakdowns from production, for a "behind the scenes" look and feel. These books tend to focus on environment art, with lots of concept art and asset breakdowns.
(2004) by David Hodgson is perhaps the most celebrated game art book of all time. Back in the 2000s when Valve still regularly made single player games with great craft and secrecy, this book offered a rare look into Valve's history and archives. Today it's a bit sad to read; it's a record of a golden age long past, when Valve was an inspiring design leader rather than just our benevolent landlord.
(2016) by Ian Tucker follows Valve's torchbearer Arkane Studios and their highly involved creative process. Arkane is one of the last AAA studios still making prestige single player story-shooter games with golden age level design sensibilities, and many level designers still look up to them.
Understanding the basics of real world architecture is useful for level design.
by Matthew Frederic is the classic architecture and fast design primer that most industry level designers have at least skimmed through. It's enough architecture education to talk at a party, and its brevity ensures you'll actually finish reading it. However, since it is so short, it doesn't actually study any specific buildings -- which is like studying literature without reading any books. This is good for an overview of concepts, but it won't give you any examples to practice applying those concepts.
by Francis Ching often gets assigned in first year university architecture courses, but it's still approachable enough for non-architects to engage. Ching's confident hand drawn examples urge the reader to focus on timeless fundamentals rather than flashy CAD aesthetics. There's a specificity and attention to actual buildings which is missing from Frederic's abbreviated approach. However, where Frederic will spell something out very clearly, Ching is more elusive and expects you to do more of the thinking yourself.
Grammar of Architecture
Generalist level design books try to understand it from many angles
Industry level design books focus on specific genres and styles
Architecture books offer a third perspective: what if you had to live in your levels, what if level design was thousands of years old?
Try to read everything, the future isn't just in one place


How to study, analyze, and breakdown other levels / real world reference
Your level does not exist by itself. Your level exists within a community of other people making levels, within a history of people making levels before (and after) you. Look at how others tackled design problems, and learn from their successes and failures.
Research also helps you get started with your project. Instead of staring at a blank page, you will have a collection of inspirations and influences to help you design your level.
To understand a level design problem better, do some research. Collect references of other levels and real-world structures, then breakdown a specific reference to go deeper into detail and study its construction. To pick out more general patterns, assemble a
List / archive of level design talks and presentations, with links to videos and slides
Below, we recommend level design talks that are: (1) from experienced designers, (2) aimed at other level designers, (3) free to access.
Talks are grouped by topic, more recent at the top. ⭐ = especially influential / famous
the minimum / main player path to complete a single player level
The critical path (or golden path) is the main intended player path / procedure to complete the level and progress.
usually for single player levels with scripted progressions, not multiplayer
highlights the most important ("critical") parts of the level.


No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
more about the combat design, cover patterns, and map balance
important for multiplayer maps, especially competitive combat
When using physics engines, try to physically simulate the door hardware, i.e. apply torque or velocity on the rigidbody / hinge, so that it can interact with other physics objects "for free". (via Gone Home)
Doors must clear any blocking obstacles in order to close.
Ouake-style doors inflict damage forces on blocking objects, sometimes killing players accidentally. This mechanic transforms doors into mild hazards, which fits a chunky arcade action game like Quake, but it's obviously not appropriate for other genres.
If the final state of the door does not matter, then let the door end its movement ajar, and disable the door closing force once it collides with another objects (via Gone Home).
However, if the door must be forced shut no matter what, then apply a distance-attenuated force to push away nearby objects, with an upper bound on the force. (via )
moveSpeed / rotateSpeed, in engine units per second (sliding) or degrees / second (rotating)
delayBeforeClose, in seconds. A value of -1 could mean "stay open, never close automatically."
startsOpen, true or false. If true, the door will automatically open itself at the start of the game / default to its open state. A more complicated door might implement this as an initialAjarAngle value instead. In the level editor, door objects should always be placed in their closed position.
openOnTouch, true or false. If true, the player can touch or enter an invisible trigger to open the door; if false, the player must manually activate the door or use a button.
isLocked, true or false. If true, the player cannot open the door by default, and must unlock the door by finding a key or disabling the lock somehow.
For a playable overview of different lockpicking mechanics in many games, see Johnnemann Nordhagen's "Museum of Mechanics: Lockpicking".
What if a global quest event locks all the doors in the entire game, but then after the quest, unlocks all those locked doors -- how can we distinguish between doors that were previously locked and should remain locked, and previously open doors that should now be unlocked? (In the case of The Witcher 3, a level designer had to manually re-configure every door in the entire game, see "How A Designer Accidentally Opened Every Door In The Witcher 3")
even if evo psych is real, is it relevant to video games?
The field of psychology is currently in a replication crisis, where famous experiments and theories cannot be validated or reproduced
can we replicate the U-shape curve? (2021 study: maybe not)
can we replicate prospect-refuge effect? (2016 meta-analysis of 34 other studies: prospect is real, but refuge is not)

To draw people, look at a lot of people; to paint landscapes, look at a lot of landscapes. No one has a perfect understanding of anatomy, light, or shape, without research.
Level design and architecture are no different. Study different places (both virtual and physical) and those references will lead you to build new places.
Reference helps you build contrast:
To make something new, learn what has already been done before, and then break it.
To make something feel weird, establish a sense of normalcy first, and then break it.
If realism and plausible sense-of-place are important to your project, then do research before layout or blockout.
To research a real world location:
Visit the place physically in-person (when there isn't a worldwide pandemic)
Visit the place "virtually" via Google Street View
For famous buildings and monuments, search for blueprints and plans in government / architectural archives, or even 3D scans on SketchFab
From there, perform a study: a prototype that will never appear in the game. Sketch the layout or make a blockout, with attention to accuracy rather than gameplay. Observe the place as it is, rather than what you imagine it is.
This type of recreation exercise goes beyond mere observation, and forces you to answer questions about construction and flow that you never would've asked yourself before.
You won't use this layout or blockout, but afterwards it will improve your actual layout or blockout.
Imagine building a level with a tunnel / underpass. Research could involve studying other games and levels with similar structural features. What will make it work?
So you may want to search for famous maps with prominent tunnels and underpasses, like de_dust.
Fortunately, the creator of de_dust Dave Johnston wrote about designing the underpass:
My past mapping experience was mostly creating tight interiors rather than not vast exteriors, and so I was feeling very lost. Desperate, I shoe-horned a bend in the road leading to a downward slope, and at the end of it - an underground cavern.
It didn’t work, of course. While the CT spawn area was light and airy, this giant room was gloomy, boxy and felt dead compared to the sunny exterior I’d already made. Observing it also lacked any gameplay potential, I swiftly deleted it. Dust would be an outdoor map.
[...] The shallow decline into the underpass is perhaps one of my favourite aspects, both aesthetically and as a player who spent many hours armed with a Steyr Scout at the crest popping off opponents’ heads.
Johnston's commentary offers some tips for building an underpass: avoid building something gloomy, cavernous, and dead. Compare that first attempt to a long, sunny, shallow ramp leading downward into an interior tunnel with low clearance. This balance results in a risky sniper alley with subtle verticality and long sightlines.
However, the point is not to study de_dust. Pay attention to this research process:
I wanted to know more about the de_dust underpass
I googled "de_dust underpass"
I read the designer's commentary and why he designed the underpass
As a result, I'm now paying attention to new aspects that I didn't notice before
Play the level and analyze it yourself, take notes or make sketches
Search websites, fan forums, guides, and wikis to see what others said about it
Search for gameplay video on YouTube or Twitch, watch what the player does
Ask someone else what they think or notice about its design
To study a reference further, breakdown its component parts and examine its construction. Environment artists often breakdown their work into smaller parts to demonstrate its proportions and structural patterns.
The most direct way to breakdown a level is to open it in a level editor or some sort of 3D viewer, and fly around in it and study it.
Sometimes you can decompile the map file or download ripped map geometry like at Models Resource or at noclip.website. Do this only for personal educational purposes, and do not redistribute it or reuse this work as your own.
But when you don't have access to the map source file or the map geometry, which is most of the time, then breakdown some photos or a screenshots with a paintover.
Import the screenshot(s) into Photoshop / your 2D art tool of choice (see list of 2D art tools) and highlight the main lines, shapes, and objects. Markup any repetition or patterns with the same color, with attention to tiered stacks or symmetry.
In the Brooklyn Bridge paintover below, notice how the top half has two pointed Gothic-style archways, with strong trim segmenting each vertical division along its height; the rest of the structure is some boxy beige brick forms. There's also clear left-right symmetry, which means we could save time by building one side of the tower and then copy-pasting / duplicating to the other side. If we're studying a real world reference, we can also look for schematics and plans to better understand shapes and proportions.
When a deep breakdown doesn't help or when you have a lot of different references, it's more useful to study them together as a collection. A moodboard is composed of many references and images that all convey similar subjects, experiences, or feelings. Grab photos, movie stills, game screenshots, illustrations, concept art, whatever! When you study them all together as a whole, you'll tease out common patterns or trends.
Moodboards are essential for pinpointing otherwise vague experience goals. Let's say you want to make a level that is scary. Well, what do you mean by "scary"? Did you mean an unsettling type of fear that something is just slightly "off", or maybe you meant grotesque monstrous zombies. But then what kind of zombies, the slow confident shambler or the unhinged running horror?
When you collect references and compare them, you will discover you actually have a more specific idea of your desired experience. Moodboards help you explain your intent to yourself as well as any collaborators and teammates, who might have different takes or perceptions too.
Research helps you plan and build your level.
To do research, gather a bunch of reference material.
To analyze the reference closely, make a study -- a mini recreation / copy, with attention to accuracy and observation
Study a specific reference in detail with a breakdown, a visual analysis
Paintover the reference image, add labels and notes
Look for patterns in a moodboard made of many references.
see also: How to make a level
Designing the Museum Flashback: 'The Last of Us Part II' (, )
2022
by Evan Hill; and for a walking sim level, and an overview of the level production process at Naughty Dog.
Just Me & My Pitch: The Confused Art of Showing a Layout ()
2022
by Simon-Albert Boudreault; abstract production process theory for iterating on , how to run a design meeting.
⭐ Modular Level Design of Fallout 4 (, )
2016
by Joel Burgess and Nathan Purkeypile; an authoritative primer to , essential for environment artists.
see also: Combat
Creating Conflict: Combat Design for AAA Action Games ()
2016
by Michael Barclay, Pete Ellis, Sam Howels; three talks on combat , , and open world combat.
Community Level Design for Competitive CS:GO (, , )
2015
by Shawn "FMPONE" Snelling and Sal "Volcano" Garozzo; sightlines and readability in PvP maps for Counter-Strike.
⭐ Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3 (, )
2010
by Jaime Griesemer; influential and tuning workflow talk, not directly about level design but still relevant to any combat game. See also: .
Designing Radically Non-Linear Single Player Levels (, )
2019
by Aubrey Serr; affordance theory for systemic non-linear sandbox via immersive sim examples.
'Hitman' Levels as Social Spaces: The Social Anthropology of Level Design (, )
2019
by Mette Podenphant Andersen; for non-linear sandbox maps in Hitman 2 (2018) as sociological spaces.
'Mooncrash': Resetting the Immersive Simulation (, )
2019
by Rich Wilson; and progression for Prey (2017) DLC adapting the immersive sim into a semi-proc-gen roguelike.
That last point is important. A critical path represents your ideal design goals and requirements, but it is not the reality. Most players will wander, explore, linger, or even just get confused.
In a layout drawing, the critical path markup helps other designers and collaborators understand the level's pacing. What happens and where?
For more on drawing floor plans, see Layout.
In engineering, project managers use critical path method (CPM) to figure out which tasks must happen first and why. Charting the critical path helps them understand the logic and flow for the project.
We can use critical paths for level design in a similar way, to help manage project scope.
How important is each part of the level?
If something isn't on the critical path, then only some players will see it. Is it worth making?
The critical path helps us imagine what a "minimal viable" layout looks like.
For example, in the layout drawing above, the yellow hatched area is not on the critical path. So is it still worth making? If we cut this area, then we will have less work to do.
Maybe the level is still too big and too much work. Maybe we need to delete more.
What if we deleted all the side areas? Does it still fulfill our experience design goals? Maybe we need to redesign the critical path entirely...
Designing around a critical path is potentially a reductive way for thinking about a space.
Critical paths instrumentalize the world in terms of resources, gates, and objectives, a checklist of activities imposed on the player by a level designer. Can games and levels be more than just "content" for users to consume? What if your project requires a high degree of realism, plausibility, or sense of place? Building around a critical path usually results in a "video game-y" feeling space.
Instead, some designers prefer to assemble a critical path after an already-complete layout and blockout, to flow around existing level geometry. Martin Hollis, producer of Goldeneye 007 (1997) for Nintendo 64 explains their level design process:
"The level creators, or architects were working without much level design, by which I mean often they had no player start points or exits in mind. Certainly they didn’t think about enemy positions or object positions. Their job was simply to produce an interesting space. After the levels were made, Dave or sometimes Duncan would be faced with filling them with objectives, enemies, and stuff. The benefit of this sloppy unplanned approach was that many of the levels in the game have a realistic and non-linear feel. There are rooms with no direct relevance to the level. There are multiple routes across the level. This is an anti-game design approach, frankly. It is inefficient because much of the level is unnecessary to the gameplay. But it contributes to a greater sense of freedom, and also realism. And in turn this sense of freedom and realism contributed enormously to the success of the game.” -- Martin Hollis, producer of Goldeneye 007 (N64) as quoted in "Anti-Design / Backwards Game Design in Goldeneye 007" by Chris DeLeon
In the diagram below of the "Complex" level from the first person RPG Deathloop (2021), level designer Sylvain Menguy highlights critical paths for a non linear single player map. They document an afternoon configuration and an evening configuration, along with the player's probable paths to the area boss.
The game has 4 main maps, playable on 4 time periods through the day (morning, noon, afternoon, and evening), where the player can freely explore the level, engage combats, discover puzzles, or even solve the “murder puzzle” which structures the main adventure of the game...
This approximate layout diagram omits needless details in favor of a big picture, and that's useful for communicating pacing. Notice how the white arrows shown below don't match the map terrain exactly, but still convey a lot of information about the intended routes. Even though the player begins with 3 lanes, these lanes always converge to two entrances to the boss arena on the other side of the map.
The map was made from the start to allow for multiplayer gameplay, with another player invading in the afternoon or evening. The reading of the layout is thus different between these 2 periods, and the encounters with the antagonist Julianna, who comes to chase Colt and make his life harder, are also different.
This shared layout between time periods always gives several navigation options, dead ends and long corridors from which you cannot extricate yourself are prohibited, to make a smoother experience and allow you to quickly rotate between areas..."
"Rotating" is when player(s) must change focus ("rotate") to another map area, usually in team-based multiplayer shooters like Counter-Strike: Global Offensive. It's interesting that Menguy adopts multiplayer level design thinking for a single player level.
For more on rotating in multiplayer design, see Map balance.
The critical path is the ideal player route to progress through a single player level.
It is mainly a planning and scoping tool. It helps communicate pacing within a layout drawing. And if you need to scope down the project, it can help you decide what parts of a level to cut.
However, prioritizing the critical path can result in more artificial feeling spaces. Some level designers design a space first, and then figure out a critical path later.
Circulation is helpful to think about too.


covering 3D surfaces with 2D images
A texture is a 2D image that wraps around a 3D object, like an animal skin or wallpaper. For levels, we usually apply environment textures to cover floors and walls in the game world.
Early 3D games used one texture per object. The color painted in Photoshop was often the same color seen in the game, it was very direct and straightforward. But today we often use multiple textures together, instead of just one.
A material is a group of texture maps + settings for a surface. Each texture map represents a different aspect or quality, rather than the actual color to render on screen. While there are many ways to pack textures and materials, most materials in most 3D game engines use these four main texture types:
Diffuse or albedo (pronounced /AL-bee-doe/) is the base color of the surface
For transparent materials, also pack a transparency mask into the albedo's alpha channel
Normal map or bump map encodes the micro-details, scratches, indentations in the surface
(materials diagram)
World textures are reusable tiling images that cover the underlying foundation of level geometry. These are the main ground and wall textures used for the level.
Good world texturing usually:
Reads well at multiple viewing distances
its substance is clear from short, medium, or long distances
interesting to look at, but not too interesting to be distracting
Rock textures require special planning and design. Tectonic forces form cliffs and mountains into distinctive shapes and layers; in order for a cliff texture to seem like a plausible cliff, the texture's structure should reflect this unique geology and accentuate the cliff geometry's shape.
For low polygon cliff geometry, a rock texture with strong structure / crack layout will visually break up the rock shape and make it seem much more complicated than it really is. Divide the rock texture into layers / chunks, which is, you know, how rocks exist in real-life.
Many wall textures are designed to tile horizontally, but not necessarily vertically. Edge detail at the top and bottom helps emphasize where the wall meets the ceiling and the floor, simulating ambient occlusion / the realistic accumulation of dirt.
To take the segmentation further, keep the middle of the wall texture fairly plain. For short or tall walls, you can either add or remove subdivisions based on this repeatable middle section. A segmented / modular texture is more flexible to use.
For low polygon art styles, it is very useful to paint details and structure directly into the wall texture; that way you won't have to model or bake these details manually.
When modeling modular buildings made of panels, combine all the panel segments into one texture. Painting individual edge details (dirt, grime, shadow) can help accentuate each panel and make them feel unique / less repetitive. The panel layout should accommodate various sizes and shapes, to give more flexibility.
Trim sheet... Sunset Overdrive "ultimate bevel" talk?
Multiple related subtextures grouped together, designed to be used together
But a trim sheet is not magic, in fact it makes the texture even more difficult to use. Really, anything can function as a
A new recent trend in
Half-Life Alyx hotspot UVs (DreamUV)
Texture art for games is obviously a big topic that deserves its own book. We can't really teach you how to become a texture artist, this is a skill that people spend years learning and practicing.
Here, we will only talk about the general workflow for creating textures for levels.
For links to free textures, or recommended game art books and websites, see .
Today, Substance Designer is overwhelmingly the primary environmental texturing tool across the industry. By connecting various samplers and operations together into a node graph, artists can visually program a texture synthesis pipeline to procedurally generate many texture maps and variations at a time. If you're coming to Substance from a Photoshop background, imagine Photoshop Actions and filters on steroids.
There are two main advantages to this workflow over the traditional handpainting method: (1) you can easily resample textures at higher resolutions at any time, (2) the modular workflow means you can reuse graphs.
For example: if you handpaint a stone wall texture in Photoshop at 512x512, there's no easy way to sample higher resolution textures or make similar variations on that stone wall. But if you build a Substance graph to generate that stone wall, then you can set the exporter to 2048x2048 or input a different heightmap to make countless variations very quickly.
It's not really a big deal
. An artist-focused primer to different texture map types.
by Morten Olsen (Insomniac Games) is a talk on how a relatively small environment art team created a wide variety of looks for a large open world game. Great introduction to trim sheet construction and texture variants, but today you'd probably want to model the bevels instead of normal mapping the bevel.
by Shubham Kumar covers the full process. Kumar starts by gathering material reference, then measures the trim sheet metrics / grid, then synthesizes the materials in Substance and applies the trim sheet to a model.
links to level design communities, websites, discords, podcasts, blogs, social media
There are many benefits to joining a level design community:
help with design problems / troubleshooting tools
provide critical feedback for your work
motivation and encouragement
A game specific community can offer focused help / experience, and they are much more likely to playtest your work and give good feedback.
For game-specific level design communities, see the "Community" column in .
is an annual internet tradition where level designers post screenshots on Twitter during the month of October. The most popular tweets usually come from AAA industry level designers posting blockouts of their work from famous commercial games.
is one of the longest running active message boards for level design, and focuses mainly on Source Engine games (CS:GO, Team Fortress 2) but many members also regularly mod other games and use Unity and Unreal. Mix of modders and industry users.
is a Discord community for level designers founded by Ryan Smith.
is best for 3D environment artists, lighting artists, and anyone concerned more with the visual side of level design. Projects skew heavily towards Unreal Engine 4 scenes with Maya / Max / ZBrush / Blender know-how. No one here will ever playtest your project, but they will happily critique screenshots or video. Mix of students and industry users.
features news, articles, and guides for game / film / VFX artists. It is often very technical and tool focused, usually focusing on pipeline and workflow with visual-oriented breakdowns of particular scenes or projects.
features interviews with environment artists, articles and guides, as well as a podcast. Like other CG art communities, it focuses on tools and techniques.
(formerly Level Design Workshop, Level Design In A Day) is a full day of talks from industry and indie level designers every year. After many years it has found a medium-sized audience at GDC. Unfortunately there's no convenient list of past sessions, but maybe we'll put that together someday. Open submissions every summer / autumn.
is probably the premier level design criticism publication at the moment, featuring short blog posts as well as long-form features and interviews. Commissions and pitches year-round, pays writers.
has hosted several design-focused series, such as (game design breakdowns),
is a free Harvard-branded online course about architectural theory and history that runs every year, popular among industry level designers for its conceptual focus.
makes videos about his experience as AAA level designer and gives advice for level design portfolios and resources.
writes posts about open world AAA production and encounter systems, usually with a Ubisoft-like approach.
Below are some fun Twitter accounts which exist solely to post screenshots of community levels; they're good to follow because seeing more levels will help you train your eye for level design, and it's fun to see what other people make.
posts Quake 1 map screenshots
posts GoldSrc (Half-Life 1 engine) map screenshots
posts custom Doom WAD screenshots
Where to get free art assets (models, textures, materials) for use in levels
This page lists free art assets (models, textures, materials) for use in levels.
We only list sites with robust free download plans + generic file formats that work in most engines.
"CC license" refers to free assets with permissive Creative Commons or public domain style licenses.
We also list other types of resources:
: list of other level design books, with brief summaries
: list of free texture .WADs and other Quake-specific files
When making the , we recommend using gridded placeholder textures to prototype the level geometry. This helps establish consistent scale and for the level.
by Ciathyza (Unity)
by Code Respawn (Unreal 4)
by Tom Looman (Unreal 4)
by Kenney (.png)
A skybox is a special type of 6-sided cubemap texture that gives the illusion of a distant sky background. Contemporary game engines usually use procedural sky shaders / skydomes, but sometimes the old fashioned ways are more effective.
To make 2D levels, you'll usually want a tile-based level editor. See .
design exercise for a modern commercial action shooter game
In this project, you'll research, pitch, and prototype a combat encounter for a modern commercial action shooter game, with dynamic squad formations and battle lines.
Before continuing, make sure you've read about , , and . We also recommend doing the design exercise first.
Ideally, you have played an Uncharted game or some sort of cover shooter action game. If you have never played any of these games, you should go play one now before continuing. At the very least, play past the tutorial level and get through a few gun fights, which will likely take at least an hour.
If you are familiar with the genre, then take some time to review how the game plays. Search for "Uncharted 4 combat gameplay" on YouTube and watch at least 10 minutes of game footage.
While you watch the video, reflect on these questions:
How do most combat encounters in Uncharted 4 begin? How does the player know when combat has begun? How does the player know where the enemies are?
How long does the fight last? Does it feel like a small fight or a big fight, and why?
Are there any "beats" to the combat encounter? What is the pacing and the combat story?
Next, watch this GDC 2017 talk about Uncharted 4's combat AI and encounter design tools. Feel free to take notes, and refer to the for reference.
Every game manages its combat AI differently, but Uncharted 4's core approach is similar enough to other action games and cover shooters that it represents current industry practice. An encounter designer or combat designer must understand game systems as well as AI tools.
Analyze the strengths and limitations of the "zone" approach used in Uncharted 1-3.
Gallant's team prototyped several new systems for Uncharted 4, but ultimately did not use them. Analyze the strengths and limitations of one of these failed approaches.
Gallant was inspired by Pac-Man's ghost AI while designing Uncharted 4's three (3) main combat roles. Do you remember these roles?
Now it's time to design your own dynamic combat encounter.
Sketch 10+ thumbnail diagrams within 1-2 minutes. Don't overthink it, just draw any shapes that might symbolize how the encounter would play out.
Then, sketch a of a small combat encounter for an Uncharted-like action game. But do NOT try to sketch something as big and complicated as in Uncharted 4! Clarity is more important than ambition. Keep it small. The encounter should last 2-3 minutes for the player.
Define 1 for the encounter. What kind of combat or tactics will your encounter emphasize?
Design at least 1 and at least 2 beats.
Label core elements like player and enemy spawns, items, cover, and crucial , as well as hard points / zones.
(TODO: show some encounter sketch samples)
Pitch your design to someone else, and have them use the rubric below to judge your pitch. For example. they might say your experience goal felt memorable, but doesn't really support any clear paths or strategies, and too many questions remain unanswered.
In your pitch, make sure you narrate different ways how the combat encounter would likely play out, while summarizing your intent and the player experience. Good luck!
Try to implement your design plan within an actual game.
Play a , ideally a game with a "semi-dynamic" or "dynamic" combat setup.
TODO: identify a game that can actually support this exercise... lol
Pay attention to how the game plays / how the game sets up its combat encounters.
What are the various enemy types and roles?
Open the level editor and build a level with a dynamic combat encounter.
You don't have to follow your plan from the Layout phase exactly, but use your sketch as a general guide while you blockout and prototype.
Playtest your encounter / share it with others
overview of 10,000+ years of building, construction, and civilization
The history of architecture is obviously very complicated and beyond the scope of this book. This page is just a minimal summary to help you guide your own research.
When studying historical architecture, the simplest question we can ask is: why did they build it like that back then? There's usually at least three explanations:
People: society, culture, religion, warfare
Geography: climate, water, food, resources, materials
Technology: literacy, education, engineering, physics
Some things to keep in mind when we think about old buildings:
It used to be colorful. Ancient peoples painted buildings just like we do today. A thousand years later, ruins look gray and bare today, but they didn't always look like that.
Ancient wood buildings have not survived. But that doesn't mean they never existed.
History is biased towards fancy architecture, rather than common "vernacular architecture." Yet game worlds often center on everyday homes and workplaces rather than monuments.
During the late "Stone Age" or Neolithic Period (10000 BCE - 2500 BCE), humans around the world began living in small tribal / clan settlements, usually near rivers and lakes.
They built 1-floor single room homes on shallow foundations with stones, mud, wood, and/or thatch. Sometimes a moat / ditch surrounded the village for defense and drainage (). Larger villages might've had granaries to store food (), or focused on industrial specialization like mining (). Most used some kind of pottery, but some were "aceramic" and relied on baskets (). Religion was usually small and personal, like a household shrine or a small village temple to a mother goddess.
In the few rare big cities that did exist (10,000-40,000 people), rulers and elites needed more complicated religions and bureaucracies to maintain control. They justified their authority with bigger and taller palaces, temples, and gates, made of more luxurious materials -- like kiln-fired brick and tile requires burning a lot of wood (). But still, most settlements / regions were not unified under a single power -- instead they were fragmented, diverse, and egalitarian.
During the "Bronze Age" (3000 BCE - 1200 BCE), bigger settlements became more common. Ancient cities have evidence of urban elite -- bigger compounds with rarer materials and objects.
The built big cities like with complex drainage systems built into large platforms of millions of bricks laid in an urban grid. Yet despite the complex organization and labor it would've required, the city layout is private and hierarchical, with little evidence of a central ruler or religious authority (like any other ancient city).
In Mesopotamia, the was an architectural milestone with monumental stairs and platforms assembled as abstract -- the temple evokes a unified vision and aesthetic, and it is possibly the first example of formal architecture in human history. Again, the sheer number of bricks implies a lot of resources, labor, and social organization.
There were also other similarly monumental architecture milestones around the world at this time, in Egypt (), Malta (), England (), and Peru (). All these wonders served a religious / ritual center function. However we still don't know much about these places / societies.
The Ghaggar-Hakra River dried up, and unknown invaders overran Mesopotamia; other powers began developing around the Mediterranean.
The ruler Ramses I consolidated power and religion at , a city-temple complex along the Nile River. Temples followed a linear . Festival parades / "processions" entered temples through majestic engraved and painted with the pharaoh's great deeds, expressing both power and cosmology in an iconic trapezoidal shape. After passing through more pylons, courtyards, and chambers, the path forked to an innermost sanctum with a to absorb religious offerings. The , the pinnacle of Egyptian rock temples, also features an inner sanctuary with a sacrificial altar, illuminated by the light of the rising sun at dawn.
Egyptian columns were highly symbolic and inspired Greek and Roman designs. Lotus / papyrus pattern columns mark sacred spaces, giving form to creation myths about the earth holding up the sky -- the bundled reeds and plant motifs evoke the Nile River, its stability and permanence.
As with much other ancient architecture, the stone columns would've been covered with stucco and painted with vivid colors, that have since decayed and faded with time.
(TODO: add note about windows)
A Minoan priest-king ruled at the , a large multi-tiered complex surrounding a central north-south courtyard. This miniature city also had warehouses, temples, and residences with built-in ventilation and drainage. Stone walls were covered in mud / straw / plaster and painted with frescoes, and round tapered wooden columns were painted red with blue capitals. Like the Egyptians, the Minoans built a critical path entry sequence with specific views and symbols starting from the west porch, up a great stairway, and into a throne room.
Olmec, La Venta, Chavin de Huantar, Teopantecuanitlan
Zhou Dynasty China, Ritual Complex at Fengchu / Wangcheng
Babylon, Ishtar Gate
Classical Greece, Doric order transition from wood to stone inspired by Egypt... Temple of Apollo / temenos at Delphi... Ionic order is parallel, not after... Acropolis at Athens
Great Stupa at Sanchi
Temple of Horus, Xianyang Palace
Rome... adapt greek forms, concrete, Vitruvius... Roman Urban Villa at Pompeii, Palace of Domitian at Palatine Hill, The Colosseum
Qin / Han Dynasty China
Teotihuacan
How to document and distribute a level
Once you have prototyped, playtested, and polished your level, you should probably release it publicly.
You don't have to finish a project 100% to release it. You can release an alpha / beta version, or even just a short demo. Don't wait until something is completely perfect, because chances are, nothing will ever seem perfect enough. Plenty of designers and developers release unfinished projects -- some people even sell it, and their players love it!
On this page, we'll cover general best practices and norms for publicly presenting a custom level, map pack, mod, or standalone project.
General rules and guidelines for packaging and publishing playable Quake files
This page is about how to package a Quake map / mod release.
These rules and guidelines are based on how most Quake engines work, as well as general community etiquette and consensus developed over the past few decades.
Quake was made in 1996, its core technology is over 26 years old. And like any 26 year old, it's too late to change anything bad or annoying about them. We have to figure out how to live with it.
Wayfinding and Storytelling (GDC Vault)
2015
by Brendon Chung; wayfinding and storytelling, but maybe more about flow. Lots of videos, slides not recommended.
⭐ Everything I Learned About Level Design I Learned from Disneyland (GDC Vault)
2009
by Scott Rogers; the original theme park level design talk. Despite its influence, we disagree with much of it, see: Disneyland.
2016
by Mette Podenphant Andersen and Jacob Mikkelsen; tutorial and wayfinding for Hitman 1 (2016) Paris chateau level.









Specular map, glossiness, roughness, smoothness, metallic affect shininess / reflectivity
Ambient occlusion ("AO") darkens seams, cracks, and crevices that block (occlude) light
Tiles well, without implausible seams or jarring repetition
e.g. repeated wood plank edge outlines are OK, but a clearly copy-and-pasted wood grain or dirt pattern may feel artificial and strange
Matches the massing of the underlying level geometry
e.g. don't use a brick texture for a 2 cm thick wall
Coheres with the overall worldbuilding and fiction of the level / game
JP LeBreton streams WAD Wednesdays, playing a few randomly chosen Doom levels each week.
Level Design Podcast is a podcast hosted by Mark Drew, Jonathan Wilson, Valentina Chrysostomou, and Rob McLachlan.
Level Design Lobby is a podcast hosted by Max Pears.
Game Maker's Toolkit (GMTK) is a very popular game design analysis YouTube channel by Mark Brown. He often critiques levels and makes good points, but we want to caution you, he doesn't quite have the personal experience of actually working as a level designer.
@Tf2Dot posts Team Fortress 2 community map screenshots
@TaffingAbout posts Thief and Thief 2 fan mission screenshots.
@dot_bsp the original level design screenshot account (?) posts GoldSrc screenshots (on hiatus as of 2019)
another prolific free asset creator, lots of free low poly 3D props and characters
lots of good low poly 3D modules / tilesets, special Unity integration but works for any
free community model exchange for Blender users... it's not hard to learn how to export models from .blend to .fbx / .obj
used to be the biggest stock 3D platform on the internet; still some good free stuff there
free photosource for 1990s-2000s retro vibe, spiritual successor since CGTextures / Textures.com removed its free plan
biggest selection of free low poly + realistic + 3D scan assets on internet; quality varies; make sure to filter for "Downloadable"!
lots of free models designed for games, but quality varies a lot
the most prolific free asset creator in games; many well-designed low poly 3D tilesets
many free photoscanned 8k+ PBR materials, as well as high poly model library
formerly CC0Textures; lots of solid 4k / 8k materials with PBR support
lots of free textures designed for games with handpainted styles, quality varies
10000+ free tileset packs and sprites, mostly retro / pixel art style but lots of variety, basically the first place to look
smooth chunky tilesets packs and sprites, very good but also very recognizable
Can you recall any older classic game (let's just say, from before 2000) with interesting enemy design? How could you apply that design to a contemporary action shooter like Uncharted?
Design a fourth combat role for Uncharted 4; what would this enemy type do, and what would distinguish its behavior / abilities from the other three?
What is one main takeaway that could be applied to many other combat games?
No clear path or strategy
Too many questions
Evaluation
Experience goal
Supported play styles
Clarity of plan
😄
Memorable, cohesive
Multiple robust strategies
Can visualize it all
🙂
Typical, predictable
One ideal path with side paths
Need to clarify details
😕
Confusing, incompatible
Compare two rooms. Are they close together or far apart? Why?
Does one wall seem related to another wall? If so, how and why?
Ideally, the massing supports the building's program, the overall logic and function behind the building's organization.
In the massing diagram above, an architect proposes a new addition to a public library. Each mass has a defined function and audience.
The new entrance hall (orange) is at street level on the right, and the children's area (yellow) is near this entrance so that children don't walk too far or disturb others. The central open space (teal) is a long courtyard that acts as a core community space and primary circulation with the existing library (gold), highlighting the unusual cylindrical form as people approach from the entrance.
The symmetry of the added library wings (green) matches the symmetry of the existing library. The street level retail space (dark gray) is near the entrance hall, so that people can conveniently visit both the retail and the library in the same trip. The depository (light gray) needs street level access for loading / unloading shipments, but takes advantage of wide floors with low natural light.
Now apply massing theory to levels. How will players use each area and when?
(TODO: massing diagram example for games)
(TODO: paragraph description of massing diagram example for games)
The simplest way to adjust a shape is to move, rotate, or scale it in the 3D level editor. This is best with basic shapes like cubes and other 3D primitives. If you try to stretch or squeeze detailed meshes and modular kits, it will probably look weird.
Make more complicated shapes by combining simpler smaller shapes. This is the most common massing method in level design and real world architecture.
Articulation: when shapes feel separate and distinct, we say they are articulated. Articulation can make a building feel smaller when the parts feel appropriately sized for people, built at a human scale.
Carving a simpler shape into a more complex shape. This is helpful for modernist futuristic architecture, or for carving organic-feeling natural rock forms.
Beveling / chamfering / boolean operations are key techniques in 3D modeling, but most level design tools today lack clipping tools or subtractive CSG support.
Continuity: in contrast to additive massing, subtractive massing often feels more continuous. Continuity unifies the entire form as one single monolithic shape. Big monoliths won't feel human-sized.
Some masses are more important than others. A bigger mass with a more unusual shape will feel more important than surrounding masses. If this big mass stays continuous, it can interrupt other masses and take priority over the other shapes.
In the photo below of Seinäjoki City Theater designed by Alvar Aalto and Elissa Aalto, the main body of the building feels wide and low, somewhat articulated into overlapping blocks. But what's that big brown mass erupting out behind? It is a large tall monolithic shape with unusual angles. It is a contrast with the other boxy shapes, and the color / material is different too.
In the floor plan above of the Seinäjoki City Theater, notice how the building consists of 4 main masses: three linear grids for a restaurant, backstage, and offices, orbiting around the central concert hall space (see emphasis in upper-right). For a theater, obviously the concert hall is the most important part of the program, so that's why this unusual shape defines the rest of the space.
(TODO: video game example)
Readability is how the level suggests its layout and organization using its appearance.
A map with high readability arranges relatively simple shapes into clear distinct groups that the player can easily measure and memorize.
In contrast, a map with low readability has a confusing structure and shape, with fragmented massing that feels like camouflage. But low readability isn't necessarily bad because less readability can still aid your design goals. Broken massing complicates a shape and divides it into smaller shapes, and sometimes that's what you want.
In the photo above of 580 De Haro St in San Francisco, the large residential block of townhouses has been broken into a dozen different overlapping shapes, colors, and materials, which suggests many different young unique quirky families live here.
If the architect had kept it as one big continuous monolithic shape, then it would feel much bigger and less "fun", possibly diminishing the character of the surrounding neighborhood and their property values. (Or you could argue it feels like a desperate attempt to dress up some condos and mask the true nature of gentrification sweeping the city.)
Imagine 580 De Haro as a video game level. Imagine the layout inside. How does this massing affect the player's wayfinding strategies?
Articulation: each part feels like a separate townhouse for a separate household. The townhouses probably do not connect to each other, and each interior space probably only has one front door / street level entrance each.
Continuity: yet all these townhouses were built together and form one big overall sense of place. Although they are different, they also feel related. Maybe they have similar layouts, circulation patterns, and surface finishes inside? It wouldn't be surprising.
Culture: in real-life, have you ever seen modern townhouses like this before? If your audience is familiar with this type of building and if your level uses realism, then they may expect the layout inside to feel plausible.
Sometimes you don't even need a grid to establish proportion / a center of gravity
Thickness matters. Thin floor vs thick floor, thin cover vs thick cover, narrow lip vs wide beam
in general, avoid thin floors / walls, prone to tunneling and clipping issues
thickness as gameplay: bullet penetration and wallbanging (siege, csgo, blops4)
slice the pie, sharp vs rounded (link to Balance?)... sightlines
A simple corner doesn't draw attention to itself. It exists as part of a larger shape or volume. The shape and texture doesn't vary, the only thing that makes it pop is the way the light hits it.
Line of sight blocker if 90 degrees or less
If it's a subtle bevel, don't do it in blockout
corners with obtuse angles (> 90 degrees), unified shape, make the player flow / move faster around it
Opens up line of sight, less effective as cover
Great for cars and vehicles, smooth circulation
Detailed reinforced corners emphasize the corner as a distinct edge, and transform the corner edge line into an object. The corner is less about the the overall volume, and now it feels like more of a place or a thing to use, with its deviation from the walls and its own distinct silhouette.
More complex corners are good for:
framing a certain view, perspective, or vista
making the boundary / enclosure feel more solid, permanent, and grounded
emphasizing a corner as a cover object / line of sight blocker, where the player should dwell -- but in this case, don't over-detail it with small gaps, keep it fairly chunky and solid-feeling
Break up the edge with an opening, to emphasize how the walls are planes that enclose an interior. If lit head-on with thick walls, the open corner can feel very subtle and barely-there, in case you don't want players to notice it at first glance.
Sneaky corners? a trap?
very modern, very rare in traditional masonry and carpentry
When enclosed with glass: fancy airy expensive
Shape psychology is the theory that certain shapes convey universal ideas and influence behavior.
This book argues strongly that shape psychology is 99% bullshit. Abstract geometric shapes do not make all humans feel the same thing nor communicate the same ideas. Humans form mental associations with shapes based on a complex combination of genetic predisposition, personal experience, and culture.
Even if it wasn't bullshit, shape psychology would not necessarily transfer to a video game context. People often behave one way in the real world, but behave differently in a video game. Player behavior depends more on game patterns, mechanics, available information, cultural framing, and roleplaying persona, rather than whether a shape is round or square.
To design for consistent player behavior in levels, you should playtest instead. Do the work, instead of wishing for a magic theory to brainwash players.
For more on debunking this brain poison, see Shape and color psychology.
3+ in-game screenshots of main areas (no random hallways or closets)
at least 1920x1080 resolution
high quality .JPG (~80%+ quality)
if possible, disable the HUD / UI elements and enemy AI
don't photograph a pretty wall or prop; instead your goal is to give an overall impression of the overall , , mood, and
2-10 minute gameplay video of the level in action
at least 1280x720 resolution at 30 fps
omit any splash screens, intro screens, trailer music, etc.
play "normally", show how an "average" player experiences the level
50-100 word description about the project
give it a good short memorable name
single player, multiplayer? core themes, emotions, mechanics?
what's the scope? how many levels, how big is this project?
link to download
for a gamer audience, you must include a Windows-compatible version
if it's a custom level / mod for a game with Steam Workshop etc. link to it there
otherwise, you can host the files on a free service like
TODO: Good screenshot vs bad screenshot
If you are preparing a level design portfolio in hopes of gaining employment as a level designer, then you may want to prepare some additional documentation:
top-down map overview with labels
in your editor tool's 3D view, fly up and look down, take a screenshot, and then open it in a 2D tool and add text labels / markings
to take a screenshot on Windows: press Windows Key + Shift + S, then drag a rectangle
to take a screenshot on MacOS: press Command + Shift + 4, then drag a rectangle
for single player: draw or number various points along the critical path
for combat-heavy levels, show enemy placement and strategic positions
for puzzles, show the sequence of clues / steps to solve the puzzle
for multiplayer: mark player spawns, capture points, etc.
process images
show layout drawings, blockout screenshots... "show your work"
but don't upload too many, just a few to demonstrate that you understand the process
if your layout drawing is incomprehensible / chaotic, it's better not to show it
100 word devlog / analysis
looking back, what were the main strengths and weaknesses of this project?
how did the project change over time? any interesting playtests or stories?
any levels from other games inspire your approach? why those?
In addition to the above, make sure you include screenshots, a gameplay video, and a download link.
In all likelihood, a prospective employer will probably not download and play your level unless you reach the final hiring round -- but the download link is still important, because it shows that you know how to finish and release something. It looks even better if the download page is full of user feedback and high social media metrics. Although an employer may not play your level themselves, they certainly care if other people played your level.
The more popular / commercial the project, the less documentation you will need. AAA level designers can get by with just a few screenshots because everyone already knows their work, and big studios often prevent employees from posting anything that isn't officially approved. However, if you are an unknown student / novice designer seeking their first game industry job, unfortunately no one will have such familiarity with you or your work, and you will have to work harder to convince them of your capabilities.
Do not include Minecraft builds, custom Fortnite maps, or Roblox projects in your portfolio. Even though some of the most interesting level design practice is happening in those games, unfortunately the industry generally regards these tools as unprofessional.
Every game and platform will have its own community norms and conventions for publishing projects. Some mod communities might prefer something like Steam Workshop with automatic installation, while for standalone projects, you may need to host the files yourself on a free game platform like itch.io.
The basic release process for most levels / games usually looks like this:
Gather media: take screenshots, record and upload gameplay video, prep text description and credits
Package the playable project files in a .ZIP file and upload somewhere
include any additional files the level may need, with all subfolders intact
include a readme.txt file with brief description and instructions where to unzip the file
to make a .ZIP on Windows: right-click on folder > Send To > Compressed folder
to make a .ZIP on MacOS: right-click on folder > Compress items
Publish the release
create a project page (on itch.io, your personal site, Steam Workshop, forums, etc.) with text description, credits, screenshots, gameplay video embed, and download link
publicize the project page across social media, beg people to play and share it
If you're selling your project, then public release is actually just the halfway point in the project's life. There will be a lot of feedback, bug reports, fixes, and patches to figure out. Players will expect maintenance and updates. If you manage it well, you might be able to relaunch the game again and again, and cultivate a healthy "long tail" of revenue over time... but if you're making a commercial release, hopefully you're not seeking business advice from a level design book, so we'll just stop here.
Even if you do finish your project, it is very likely no one will play it. 99% of levels have a dozen players, a hundred downloads, a thousand page views at most.
This lack of massive public response can feel very disappointing, alienating, and depressing. But this experience is very common. You are not alone. If you don't have a huge popular earth-shattering success, then that doesn't make you a failure -- it makes you human.
Remember:
it's ok to make maps, mods, and games for small communities and audiences... you can create for an audience of one; these are called gifts
it's ok to work on small projects, it's ok to work on non-commercial projects
it's ok to try something and then never finish it
you do not need to work at a big prestigious industry game studio to be a great level designer
level design is an art to hone for its intrinsic beauty
the one constant in every creative field is the need for a creative that understands the ups and downs... if it hurts, talk to someone
you are more than one project! keep going!
Go map.
Industry level designer Steve Lee has a video log with level design portfolio advice.
Valve Developer Wiki: How to Take Artistic Screenshots is a short guide written mostly by Valve level designer Adam Foster
Robert Yang has blogged about general game design / dev portfolio design considerations, with links to example portfolios.
In the real world architecture diagram above, Maja Baldea thinks about different ways to organize apartment buildings. She abstracts (simplifies, generalizes) these buildings as windowless blocks because she's not interested in little details, she's thinking about the overall shape, massing, and composition, to classify different types of residential buildings.
Typologies are useful for:
classifying different types of level design
open world / battle royale type projects, since a variety of typologies will usually lead to a variety of game content
shared design language, aids collaboration and teamwork
Beyond walls, floors, and ceilings, there's also some common gameplay elements frequently found in most levels:
Room typologies are generalized patterns for a single area / "chunk" of the level.
Straight-on linear progression through the space, like a hallway, river, or canyon. Anything with a one-way trajectory through a predictable sequence of spaces could be considered a corridor.
High degree of authorship, control, and certainty. You know where the player must go and how much time the player will likely take.
To speed it up, add downward slopes, one-way drops, and bright lighting
To slow it down, add side areas, alcoves, and spotty lighting
The first person horror game P.T. (2014) made players walk down the same hallways over and over, with a looping mechanic that teleports the player back to the start once they open the door at the end. It is a powerful use of the corridor, and would've suffered with a more open layout.
Note the strong control of sightlines, forcing the player to stare through a window at the corner, or to detour into the bathroom to notice the mirror and sink. Horror tropes and ominous alcoves discourage players from moving too quickly, while linearity and familiarity culminate in a sense of foreboding, dread, and doom. All we can do is go deeper, and there is no escape.
A dead-end corridor with a visible exit when you backtrack.
Similar to corridor, offers a lot of control and authorship
Obscuring the exit encourages the player to explore the dead-end first
Brief confusion, mild sense of exploration and navigation
Switchback example: cave in Dear Esther
Small open area with cover in the middle, usually full cover like a pillar or column, resulting in a spinning / rotating flow. Especially common in fast-paced combat games, where players can "dance" / circle-strafe around the central cover while blocking enemy attacks.
Add a one-way drop to force a specific flow, and/or introduce some verticality
An arena is an open area with several lanes of circulation and some cover in the middle.
open world and battle royale designers use points of interest (POIs), big arenas anchored by a large landmark with multiple entrances and exits
in single player, arenas usually need gating; gate players from leaving the arena early, but also gate the entrance to prevent players from pulling all the enemies into a chokepoint
(TODO: draw Dead Simple floorplan and critical path)
Level typologies are generalized layout patterns for multiple rooms / entire levels.
A larger multi-area pattern with a central area (hub) and several smaller areas / passages extending off of it (spokes). To explore different spokes, the player must return to the hub.
Gives unifying identity to different spokes, conveys logic to the structure
Needs lots of work to update the hub with each visit, or else it'll feel like backtracking
Can be a useful pacing tool, returning to a hub can feel like a relaxing reward
Gated hubs block off most spokes at the start, the player gradually unlocks shortcuts
BioShock 1 features multiple hub-and-spokes. In the beginning Medical Pavilion chapter 1
(TODO: diagram)
A linear progression that loops back on itself, most common in open world dungeons.
Similar to Corridor: lots of control and certainty with less player indecision
Helps an area feel structurally non-linear and plausible, even if progression is initially linear
Subtle loopbacks feel like closing the loop of a natural inevitable circuit
Overly convenient loopbacks can feel like contrived shortcuts that plead for the player's gratitude, and thus feel artificial or implausible
(example: skyrim layout and screenshot)
The open world fantasy RPG Skyrim features many dungeons where the player must return to the overworld after completing the dungeon. However, backtracking often feels monotonous or rote after an area has been cleared out... (TODO: finish)
Multiplayer layouts tend to be more nonlinear, circuitous, and bidirectional, emphasizing high replay value with reusable areas. Many team-based games feature bases / spawn rooms where players can safely join the game, as well as capture points for the teams to attack and defend.
most common in classic CTF maps, Blood Gulch, etc
In multiplayer team games with bases and routes toward capture points
Example: CS:GO
Example: League of Legends, DOTA, Call of Duty: Modern Warfare... also common in CS:GO (1 lane for each bomb site, and middle connector lane)
Once you classify something, you're potentially trapping yourself within the limits of those classifications. Sometimes it may be more helpful to ignore typologies and refuse categorization.
A typology is a way to classify different categories of level layouts. These words and labels help us talk and think about layout.
Room typologies are patterns for designing single areas, like corridors, switchbacks, ring-around-the-rosies / combat bowls, and arenas / POIs.
Level typologies are patterns arranging multiple rooms in sequence, like loopback, pass-through, branch and bottleneck, hub-and-spoke, and time cave.
"A Pattern Language" (1977) by architect Christopher Alexander et al. is the classic typology manual of modern architecture and urban planning today, pioneering the New Urbanism movement.
"On the ‘Three Typologies’" (2017) by architect Luke Jones is a wonderful essay about how architects still aren't quite sure how to classify architecture.
No spaces in any folder or file names.
All lowercase letters. (Some Quake engines + OS are case-sensitive, some aren't.)
Avoid using numbers or punctuation at the start.
Use common .ZIP compressed format, do not use uncommon esoteric formats like .7Z or .RAR that require special tools.
Map package (simple): put everything in the root of the ZIP, no subfolders.
Good for simple single map releases / your first map.
Mod package (complex): put everything in a mod folder, then ZIP the whole mod folder.
This way you can include custom assets and game code.
It's also common to do this for small releases too, even if they aren't full mods.
If you are only distributing map-related files (.BSP / .LIT / .MAP / .TXT) then it is OK to do the simplest packaging method:
To package a single map, place all files at the root of the ZIP file, with no folders or subfolders inside the ZIP.
A common structure where players understand they must unzip it to the correct maps folder themselves. We assume this is /Quake/id1/maps/ unless there are instructions otherwise.
If you use custom code or assets, then package your Quake release as a mod:
To package a mod, place all files in a big "mod folder" inside the ZIP file.
However, mod folders must follow specific folder names and structure...
Mod folder name must be all lowercase alphanumeric with no spaces.
Map files (.BSP, .LIT) must be in a mod subfolder /maps/
Do not use any subfolders. Maps must stay at the root of /maps/ or else engines cannot find them.
Skyboxes (.TGA) must be in mod subfolder /gfx/env/
Again, do not use any other subfolders.
Sounds (.WAV) must go in mod subfolder /sound/
Additional subfolders encouraged here. Use a unique sound subfolder name to avoid file conflicts, e.g. /sound/mymodname/
Models (.MDL) must go in subfolder /progs/
Additional subfolders encouraged, like with sounds.
Game code (progs.DAT) must be in the root of the mod folder.
Some mods package everything inside a .PAK file to simplify distribution and avoid this file folder soup. A .PAK file is like a .ZIP file, Quake engines load the files inside it with folders intact. For more info on PAKs, see QuakeWiki.org: PAK.
To package a partial mod, include several mod subfolders at the root but no main mod folder.
Include clear instructions about where to unzip.
Good for when you have only a few custom assets.
Mostly for maps intended as add-on for a big existing mod like Arcane Dimensions.
It is impractical to include the entirety of the parent mod with your release. Users likely have their own existing mod install already.
However, it is considered very bad etiquette to overwrite the parent mod's existing files, e.g. don't include a progs.dat file.
For a video intro to file structure and packaging, see David Spell's video tutorial "Quake Mapping: Release Your Map" from 4:08 onwards:
Test yourself. Is this a good or bad example? Click the arrow to reveal the answer.
We have many links to more Quake resources.
Learn more about general Release practices.





Overview of general workflow and concepts for video game level design
Most 3D level design projects involve this process:
Pre-production: plan out the big ideas and overall experience design.
Combat (optional): for combat games, define how player(s) and enemy types interact.
: sketch a visual top-down 2D plan for a level.
: build a basic in-game 3D rough draft and playtest it.
: integrate events and behaviors (missions, quests, doors, buttons, AI)
: arrange light sources for depth and readability
: "art pass" the level with props and set dressing
: document, publicize, and publish the project.
If you don't know where to start, try doing everything. With more experience, you will learn when to skip or expand a phase.
Every level / project has different needs. There is no single foolproof way to make a level.
Group projects need more and planning, like outlines and drawings. Without enough communication and documentation, collaborators can't collaborate.
games / multiplayer maps need more time to tune and with a strong focus on .
Single player levels with a
Pre-production is about planning the basic shape and scope of the project. What is the project about? What are the design goals and constraints?
Beginners often neglect project planning entirely, while experienced designers sometimes over-plan. Big commercial studios often spend months or even years in pre-production. When collaborating in a group, this phase is very important because this is when you all align your expectations. When working solo as a hobbyist, you can probably get away with less planning.
Pre-production plans are usually text documents, boards with movable cards, and spreadsheets.
For more on conceptual planning, see
If your project is about combat, then what does a typical fight look like, what is a battle made of? How do players prepare? How can you make fights feel varied and fresh?
Combat is like any other game system or mechanic. You should define these experience design goals before you make levels for them.
If you're making a combat game from scratch, the fights won't "feel good" until programmers and artists make it functional and readable. You basically have to make the whole game before you'll know what the combat feels like! Because it's so much work, we recommend modding combat games so you can practice on pre-built battle-tested systems.
For more on designing fights, weapons, and enemies, see .
For a list of recommended combat games to mod, see .
The layout is the basic structure of the level, usually a flat 2D drawing of core areas and elements.
For a small solo hobby project, a simple layout sketch, even a scribble, can be enough.
For a group / big project, detailed layout drawings are important communication tools. No one can read your mind; if you don't visualize it and talk about it, then no one will know what you want.
Layout drawings are usually top-down 2D floor plans, but isometric / perspective drawings are common too. Remember, this isn't about being a great artist; it's about communication! The drawing is a visual plan for where the player can go and what they can do.
For more on visual space planning, see
A blockout is a playable rough draft of the level, built with simple blocky 3D shapes in low detail.
We prototype the basic structure of the level so we can playtest it within the game engine. Playtesting helps us decide whether the level is too small or too big, confusing or entertaining, balanced or broken, etc.
This playtesting is important for any combat game, or anything where rearranging a room can cause big changes in player behavior. If you realize a room design isn't working, then you can modify it more easily when it is made of simple shapes.
Blockout files are playable game levels / scene files loaded into the game engine.
For more on in-game 3D prototyping, see
Scripting is about integrating behaviors, events, and game logic into a level.
is one of the most difficult problems in game development. Trains and moving platforms are even more complicated. It's better to start with buttons and collectibles.
Mission objectives, quests, cutscenes, choreography -- and any AI control / combat / -- often rely on scripting. If you're scared of coding, don't be afraid, many game engines and toolsets have special scripting languages and tools to simplify the programming process.
Level design culture tends to underappreciates scripters, yet scripting is what makes a level feel "alive" and is crucial for transforming a map into an experience.
For more about making levels do stuff, see
Lighting adds shadow and depth to a blockout, helping players understand the core shape of the level.
Without light, the 3D game world will feel more like a flat 2D image, and it will be difficult to gauge distances or understand the full layout. Light and shadow also serve as a form of cover / layer of information essential for combat gameplay.
While the game industry usually treats lighting more as a decorative facet of environment art, we argue that lighting has crucial gameplay functions and must be crafted in deep consultation with level designers.
For more on lighting design for gameplay, see .
Once you have enough certainty about the overall shape and flow of the level, you can begin adding more environment art, or visual detail.
An art pass is the process of adding these details. Most projects will require multiple art passes.
Many people think art passing is the "fun part." Beginners often rush too quickly into art passing without adequate planning, layout, or blockout work. A premature art pass locks-in early design mistakes because it becomes "expensive" to change the level and thus redo all the artwork. So, resist the urge! Don't rush into an art pass!
For more about making levels pretty, see
When the project is complete, it is time to release and make sure it reaches your audience.
For commercial projects, the game launch is just the beginning of the nightmare -- you must continue to market and publicize the project, gauge user feedback, ship bug fixes, and even build out additional post-launch content.
For personal portfolio projects, you must document the level design properly, or else no one will understand what you did. Without effective documentation, the project basically does not exist.
Beginners often do not put enough time into the release phase, and assume the project will speak for itself -- but if no one knows about it, then your work has no one to speak to.
For more on publishing a level / building a portfolio, see .
Level design usually involves multiple steps, in this general order: (1) pre-production, (2) combat design (unless it's not a combat game), (3) layout, (4) blockout, (5) scripting, (6) lighting, (7) environment art, and (8) release.
But every project is different. Sometimes you may want to skip a layout phase, or expand a scripting phase, or do environment art before scripting, etc.
If you are early in a project or early your level design career, you should probably try doing everything until you figure out what process works best for you.
Start with the beginning -- learn about for level design. Even just a little bit of planning will help a lot. It will help you figure out what the hell you're doing.
Day-to-day, most level designers tend to focus on the and .
info and resources for this modern brush-based level editor tool
TrenchBroom (or TrenchBroom 2, or TB) is a free open-source cross-platform 3D level editor with modernized Quake-style brush-based construction and ongoing updates / support. It is widely used across several modding communities as well as commercial projects.
We recommend TB as a decent general purpose 3D level editor tool that potentially works with multiple game engines on Windows, macOS, and Linux.
TB departs from previous Quake-era level editors to emphasize 3D construction in a single view pane.
Clipping planes can be 3D, and all brushes are automatically validated for convexity. TB is also great at resizing many brushes at once, with SketchUp-like handling of shared planes and contextual extrusion.
For its construction capabilities alone, we recommend TB for building , but it also allows surprisingly detailed modeling and texturing when .
gallery of various TB construction and texturing demos, from by Benoit "Bal" Stordeur
If it's not a Quake mod, there are several aspects to consider:
.MAP / .BSP support: can your engine import or compile or .BSP files?
TB's main file format is text-based Quake .MAP, Valve variant ("version 220")
If it's not a Quake engine, you'll need a plugin to import .MAPs or compiled .BSPs
If mapping for Quake, ask for help at
If using Godot, ask for help at
To build a .MAP file importer for any engine, see for info and example code
For non-Quake engines, you must create a . See the to study example configs.
(Windows) by Warren Marshall / Aleksander Marhall converts .OBJ 3D models to .MAP brushes. Be warned the tool is quite old, but it's useful for complex shapes, terrain, or reference geo.
NOTE: If you're using a modern game engine, just import the .OBJ directly, no need to use this tool. This utility is more for Quake / Half-Life mappers.
(web) by SpaceHare lets you copy and paste cylinders, arches, and staircase primitives into the editor.
file format spec + sample parser code for Quake .MAP files ("Valve" style, mapversion 220)
This is a technical file format specification article for programmers.
For mapping tutorials, see Quake resources instead.
The .MAP file format is a 3D file format devised for Quake 1 (1996).
It is gradually emerging as the standard file type for brush-based levels in any game engine, partly because it is relatively simple to parse and edit. It's similar to how .OBJ has become a simple 3D standard too, even though it lacks many advanced features.
There's a good chance someone has already written a generic .MAP parser for your game engine / programming language.
C++ ()
C# ( or )
Rust ( or )
For game engine-specific MAP importers and integrations, see .
Text based with curly braces and line breaks
Z axis is up (Quake convention), right-handed
angle values are Euler degrees from 0-359
Every object in a .MAP must be an entity, a generic actor / game object container type.
There are two types of entities:
point entities: monsters, items, lights, things with fixed size / no size
brush entities: point entities with 3D shapes embedded inside them
worldspawn: global static brush entity, the "root" of the entire game world
Entity data and templates are defined by a loaded into the level editor.
A brush is a convex 3D shape defined by 4 or more planes.
It is NOT a traditional 3D mesh format made of vertices and triangles. You need an additional map compile step to process the brush data into a usable 3D mesh. For example, Quake maps use an editor-time command line tool called QBSP that outputs a compiled .BSP map file; meanwhile many .MAP parsers for other engines instead generate this mesh at runtime.
Every brush line defines one 3D plane (a triangle) and its texture coordinates:
Building the 3D mesh based on plane intersections is a bit complicated. Most libraries implement some variant on . His paper explains the math and process in detail, PDF download mirrored below:
The Quake .MAP file format has two versions: the original Standard version, and an updated format by Valve Software.
The original Standard format had problems storing texture rotations. Given a 3D brush plane normal in XYZ, it discards the longest axis and stores the resulting Vector2. But if the plane is at a 45 degree angle, then the longest axis is now ambiguous and the map compiler must now arbitrarily favor an axis; makes this preference even less predictable, often resulting in unpleasant texture stretching.
Standard texture coordinates:
TEXTURE_NAME offsetX offsetY rotation scaleX scaleY
Meanwhile, more recent Valve format .MAPs have the "mapversion" "220" key value set in the worldspawn. Valve format 220 resolves the 45 degree ambiguity case by storing UVs in Vector3 space, which also enables some useful UV skewing operations in as well.
Valve format texture coordinates:
TEXTURE_NAME [ ux uy uz offsetX ] [ vx vy vz offsetY ] rotation scaleX scaleY
We generally recommend using Valve format, and there's no reason to use standard format other than backwards compatibility / porting old files to the updated format.
For much more complex example .MAP files, see .

How it feels to move through the level
In level design, flow is how it generally feels to move along different paths / between different parts of a level.
Is the path simple or complicated? Straight or curvy? Slow or fast? All of these factors affect the player's movement through the space. In short, designing flow is about designing movement.
You should start designing flow during initial planning, but you won't be able to verify how it actually feels until you and .
small competitive multiplayer arena
Bungie's "Halo: Combat Evolved" (2001) was the key launch title of the first Microsoft Xbox console, and is arguably the main reason why the Xbox gained market traction and an audience at all.
It was also the first FPS that "worked" on a gamepad, and both its single player format (large outdoor levels, vehicles, "smart" AI) and multiplayer design (full cooperative mode, 4 player splitscreen) proved very popular and influential. The spiritual successor to Goldeneye 007 (1997).
entity definition file / mapping aid for Quake-era level editors
FGD is a common text file format used across several Quake-era level editor tools (like ) to define entities.
An entity is basically any game object that isn't static world geometry -- NPCs, items, lights, sounds, doors, player spawns, etc. Anything that can move, change, or react.
Note that an FGD is just an editing aid that adds templates and documentation. It does not implement any in-engine game functionality by itself. It's only there to help level designers understand and configure objects. Technically you don't need an FGD to map for a game; in theory you could simply memorize and validate all the level scripting data manually.
For more about common game object types and behaviors, see .
📦 myzipfile.zip
↳ mymap.bsp
↳ mymap.lit
↳ mymap_readme.txt📦 myzipfile.zip
↳ 📁 mymodfolder
↳ 📁 gfx
↳ 📁 env
↳ skybox_up.tga
↳ (etc)
↳ 📁 maps
↳ mymap.bsp
↳ mymap.lit
↳ 📁 sound
↳ 📁 mymodname
↳ mysound.wav
↳ progs.dat
↳ readme.txt📦 myzipfile.zip
↳ 📁 gfx
↳ 📁 env
↳ skybox_up.tga
↳ (etc)
↳ 📁 maps
↳ mymap.bsp
↳ mymap.lit
↳ 📁 sound
↳ mysound.wav
↳ mymod_readme.txt

record with Open Broadcaster Studio (OBS), upload to YouTube or Vimeo
editing the footage can be nice but isn't necessarily important
optional: overlay your personal audio design commentary as an optional audio track, shows fluency and communication skills to a teacher or prospective employer
project credits, who worked on this? where do the assets come from?
use .ZIP... avoid .EXE installers or non-traditional formats like .RAR or .7Z, which are less accessible and require special software
show that you can think and communicate, but don't write too much
link to any news coverage or awards
Discord (main community platform for gamers, especially mod communities)
Instagram (popular visual platform for normal people / non-game-artists)
ArtStation (main visual platform for game artists, essential for environment artists)













-2 means "down"
some Quake mods implement rotations as a 3D vector called m_angle
{
// classname: the type of entity
"classname" "(ENTITY TYPE)"
// moreentity data goes here
{
// (optional) brush data goes here
}
}// a Point Entity is a curly brace scope
// with keyvalue pairs surrounded by quotation marks
{
// classname: the type of entity
"classname" "info_player_start"
// spawnflags: a bitmask of toggles for the entity
"spawnflags" "0"
// origin: the entity's position in 3D space
"origin" "32 32 24"
// but this is just Quake convention, you could put any arbitrary data here
}// a Brush Entity is like a Point Entity but with 3D brush definitions inside
{
"spawnflags" "0"
// remember: worldspawn is the traditional root entity of all world brushes
"classname" "worldspawn"
// note that 'classname' is often NOT the first keyvalue pair, don't assume!
// a file path to a Quake WAD (texture set)
"wad" "E:\q1maps\Q.wad"
{
// 3D brush geometry information, see next section for details
( -16 -64 -16 ) ( -16 -63 -16 ) ( -16 -64 -15 ) __TB_empty [ 0 -1 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
( -64 -16 -16 ) ( -64 -16 -15 ) ( -63 -16 -16 ) __TB_empty [ 1 0 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
( -64 -64 -16 ) ( -63 -64 -16 ) ( -64 -63 -16 ) __TB_empty [ -1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 64 64 16 ) ( 64 65 16 ) ( 65 64 16 ) __TB_empty [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 64 16 16 ) ( 65 16 16 ) ( 64 16 17 ) __TB_empty [ -1 0 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
( 16 64 16 ) ( 16 64 17 ) ( 16 65 16 ) __TB_empty [ 0 1 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
}
}(x1 y1 z1) (x2 y2 z2) (x3 y3 z3) TEXTURE_NAME [ ux uy uz offsetX ] [ vx vy vz offsetY ] rotation scaleX scaleY// in the Valve texture format, parsing the file would yield these values in order:
// texname [ ux uy uz offsetX ] [ vx vy vz offsetY ] rotation scaleX scaleY
// NOTE: Valve format doesn't actually use the "rotation" value anymore
// per vertex and per face, coordinates can be calculated like this
Vec3 axisU = Vec3(ux, uy, uz) / scaleX;
Vec3 axisV = Vec3(vx, vy, vz) / scaleY;
for (FaceVertex& v : Vertices)
{
// Dot product of (v.Point, axisU)
v.TexU = v.Point.x * axisU.x + v.Point.y * axisU.y + v.Point.z * axisU.z;
// Dot product of (v.Point, axisV)
v.TexV = v.Point.x * axisV.x + v.Point.y * axisV.y + v.Point.z * axisV.z;
v.TexU += offsetX;
v.TexV += offsetY;
v.TexU /= Texture->GetWidth();
v.TexV /= Texture->GetHeight();
}// entity 0
{
"spawnflags" "0"
"classname" "worldspawn"
"wad" "E:\q1maps\Q.wad"
// brush 0
{
( -16 -64 -16 ) ( -16 -63 -16 ) ( -16 -64 -15 ) __TB_empty [ 0 -1 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
( -64 -16 -16 ) ( -64 -16 -15 ) ( -63 -16 -16 ) __TB_empty [ 1 0 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
( -64 -64 -16 ) ( -63 -64 -16 ) ( -64 -63 -16 ) __TB_empty [ -1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 64 64 16 ) ( 64 65 16 ) ( 65 64 16 ) __TB_empty [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 64 16 16 ) ( 65 16 16 ) ( 64 16 17 ) __TB_empty [ -1 0 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
( 16 64 16 ) ( 16 64 17 ) ( 16 65 16 ) __TB_empty [ 0 1 0 -0 ] [ 0 0 -1 -0 ] -0 1 1
}
}
// entity 1
{
"spawnflags" "0"
"classname" "info_player_start"
"origin" "32 32 24"
}Asset integration: can TB hook into your game assets?
TB can read common file formats like PNG, JPG, FBX, OBJ, etc
Some plugins can sync to Quake formats, e.g. texture bundles like .WAD
Scripting: how complex are your scripting needs?
To place game objects or do scripting, TB gets entity definitions in .FGD files.
TB is OK for simple Quake-style scripting: placing objects, linking buttons to doors, or plotting simple paths... but it's a bit painful to script cutscenes or choreograph complex sequences.
Or maybe use TB only for 3D construction and markup, and do all your scripting natively in whatever game engine you're using.
compile to BSP via
built-in FGD / WAD / MDL
Quake 2
compile to BSP via
built-in FGD / WAL / MD2
Quake 3 ()
compile to BSP via
built-in MD3 / etc but no patch editing support yet (or ever?)
Half-Life ()
compile to BSP via / VHLT ()
built-in FGD / WAD3 / MDL
Doom 3 ()
via
via
Be advised, TB probably isn't the best tool for Quake 3 or Doom 3 engines. See Tools for a full list of game engines and recommended level editors.
Intro to TrenchBroom quickstart tutorial videos by David "dumptruck_ds" Spell assumes you're mapping for Quake but the general setup process is similar for mapping for any engine.
Bal's Quake Mapping Tips & Tricks (2022) by Benoit "Bal" Stordeur is a crucial must-read for intermediate / advanced Trenchbroom construction techniques. Although Stordeur is working in Quake, his advice is applicable to using Trenchbroom for any game.
Godot
common file formats, FGD / WAD via plugin
Unity
import via Tremble, Qunity, Scopa, or Unity3D-BSP-Importer
common file formats, FGD / WAD via some plugins
Unreal
common file formats, textures via TextUEr (guide)


Quake 1
Compare the two real-world race tracks pictured above.
The Circuit de Spa-Francorchamps (above, left) is a Formula One (F1) racing circuit with a wide variety of turns, sightlines, and slopes that requires flawless technical driving. In contrast, the Daytona Speedway (above, right) is a NASCAR race track, a flat wide oval that supports big crowds of cars pushing against each other.
Both "levels" serve the same core mechanic of motor racing, but emphasize very different driving styles and strategies.
Below a pro race car driver describes the flow of Eau Rouge, a famous turn at Spa:
"... as you come over the crest, you don't know where you will land. [...] you have a long uphill straight afterwards where you can lose a lot of time if you make a mistake. But it is also an important corner for the driver's feeling. It makes a special impression every lap, because you also have a compression in your body as you go through the bottom of the corner. It is very strange – but good fun as well."
-- F1 champion Fernando Alonso describing Eau Rouge (via Formula1.com)
In this way, level design is kind of like motor racing. What type of movements do we ask the player to make? Does it feel safe or dangerous, simple or complex?
On the multiplayer map de_dust2 by Dave Johnston, iconic "Dust doors" (below) funnel players into a narrow dangerous zig-zag turn. An opponent on the other side can even shoot through the thin wooden doors. Like the Eau Rouge, you never know 100% what's on the other side. This is more exciting than a straight clear open path.
"Dust doors" could be considered "bad" flow -- the doors break the line of movement and force sharp sudden careful turns. But here, the so-called bad flow is actually good, it adds drama and strategy within the context of Counter-Strike's fast paced fights.
Sometimes fast is good, sometimes slow and complex is better. It all depends on the game systems and the level's purpose.
Fast-paced arcade-style games might favor smooth flow with wide generous turns and minimal interruptions. Meanwhile a horror walking simulator might work better with sharp narrow turns, blind intersections, S-shaped curves, and maze-like dead ends.
In the end, the best flow is whatever supports the intended experience design goals.
What is this level / area / encounter / experience about? Fast exciting action, calm observation and navigation? The first glimpse of a big city? A scary chase? A hangout?
For competitive multiplayer maps, flow strongly affects overall map balance.
Verticality is vertical flow, how it feels to move upwards and downwards.
In a map, this usually means stairs, ramps, slopes, elevators, ladders, cliffs, raised platforms, jump pads, etc.
The conventional wisdom here is that more verticality is better, since it adds more visual interest to the map structure and breaks up a floor plane. But today, we advise against too much random verticality, and instead urge restraint. The suitability of verticality depends a lot on the core game design; many game mechanics require spaces that are just big flat floors, and sometimes that's ok. You don't need to put random steps and platforms everywhere.
For more info on vertical flow, see Verticality.
Flow is about designing movement. A lot of factors affect how movement feels:
Speed. Does it feel slow or fast to move along a path?
Direction. Is the path smooth / continuous, or disjointed / abrupt with sharp turns?
Wayfinding. Is the path obvious? What info helps the player plan a route?
. What are the player's movement mechanics? How are distances tuned?
To consider these factors all at once, we offer three design techniques for designing flow:
Desire lines: compare ideal paths in a single room / area
Critical path: visualize single player pacing across the whole level
Circulation: visualize multiplayer lanes across the entire map
In urban planning, desire lines (or desire paths) are user-made paths marked by foot traffic and erosion.
In the photo below, an "unofficial" dirt path deviates from the "official" concrete path. The unofficial path is the desire path. It is what player actually want / and what feels most natural and intuitive to them.
This type of thinking is useful for designing small scale flow, within a single room / area:
Imagine an efficient "desire line" from the player to their destination.
Compare the desire line against the actual path(s) the player can take.
In the example diagram below, a player must climb stairs to reach an exit...
The player's desire line (yellow) leads directly to the exit on the second floor, but the actual flow (red) forces the player onto the stairs.
The switchback stairs (left) feel less straightforward than the single turn corner stairs (right), because the switchback requires the player to make an extra turn.
While the switchback is less efficient, remember that less efficient flow is not necessarily bad. The switchback could be useful:
Slow down the player, and encourage room exploration first
Offer a parkour-style shortcut, climb directly up to the mid landing
Place a ranged enemy on the mid landing; how easily can the player attack it?
The critical path (or "golden path") is the minimum / main path to complete a single player level.
More generally, it represents an idealized player flow that highlights the most important ("critical") parts of the level and mandatory game content that you want every player to experience.
Single player layout drawings usually need some sort of labeled critical path. Sketch, highlight, or mark the critical path in the drawing -- or if the drawing is too complicated, at least mark the player start, exits, and labeled points of interest.
For more on designing main routes for single player levels, see Critical path.
Circulation (or "connectivity") refers to how areas connect to each other.
Designing with circulation can help support a level's storytelling and wayfinding. A level with plausible circulation might resemble the way that real world architecture functions, thus allowing players to read and predict patterns based on their general knowledge from outside of the game.
Circulation analysis is especially helpful for multiplayer map design, which is often more non-linear and does not follow a single critical path. Instead, we organize the level layout into a system of lanes.
For more on storytelling, wayfinding, and multiplayer lanes, see Circulation.
Flow is about how players move around a level. Verticality is vertical flow.
When designing movement, think about speed, direction, wayfinding, and metrics. Yeah, it's a lot.
Three ways to think about flow:
Desire line: compare ideal path vs. actual pathing within a room / area
Critical path: the ideal player path to complete a single player level
Circulation: connective areas / "lanes" of the level
Flow is a tool. Inefficient "bad" flow is not necessarily bad, because it can serve a purpose in the right context. Similarly, overly efficient "good" flow can feel boring. It all depends on your design goals.
Matthew "Lunaran" Breit wrote some of the earliest level design theory on flow, as well as a post on connectivity back in 1999. Today, Breit regrets his overly prescriptive tone ("... incorrectly asserts that dead ends, forced indirect routes, or other things that slow players are essentially illegal...") as a product of his Quake fanboyism, but we still love him anyway.
This is an edited version of Andrew Yoder's blog post "Halo’s Multiplayer Maps and Public Parks". All Chill Out video and screenshots by Andrew Yoder, used with permission.
If you aren’t familiar with Halo’s standard free-for-all ("Slayer") gameplay here are the basics:
Run around and attack other players with a variety of guns, items, and powerups scavenged around the map. To win, get 25 kills (or sometimes 50).
When you die, you respawn in a randomly selected position after a few seconds. However, high level Halo players understand how to game Halo's respawn selection algorithm.
Compared to other FPS games, the main identity of Halo comes from its floaty movement and its regenerating shield mechanic.
Floaty movement: players are slow at full speed, and slow to accelerate. The jump itself goes almost as high as the player character, and the jump lasts longer than it would in Earth’s gravity. This slow movement becomes predictable, which means easy to shoot, which means there are consequences for making a bad move during a fight.
Regenerating shield: players take shield damage before they take damage to a health bar.
A damaged shield will start regenerating after a second, and take up to a second to complete.
If the player takes damage during that regeneration time, the shield timers reset.
Remember: Halo was one of the first console FPS games designed for gamepad, so the slow movement speed, lack of air control, forgiving shields, and sticky aim magnetism, were crucial for easing players into the experience. It was much slower than its competitors at the time, Quake 3 Arena and Unreal Tournament. This combination of mechanics makes standard Halo multiplayer about sustained precision and deliberate movement. Tighter environments amplify these mechanics and introduce an aspect of map control and positioning that defined competitive Halo.
Chill Out is a medium-sized interior-based map where each room feels carved out like a cave, with no exterior views or visible sky. The environment textures belong to the purple Covenant alien theme, but the architecture has the harsher angles of Forerunner architecture. It is difficult to place where this map would exist within the Halo universe.
There is also a ground fog in the lowest rooms to help orient players vertically within the whole map. Combined with the cool color palette of soft grays, blues, and purples, this fog gives a cold impression, playing off the pun in the map’s name.
Chill Out is one of a dozen different multiplayer maps that shipped in the original Halo 1 retail version. It was neither the most hated nor the most popular level in the map cycle, but it still offers a useful way to understand how players use sightlines and maintain territory to establish map control in a multiplayer arena.
Structurally, “Chill Out” has three sections, and six rooms: Rocket, Mid, Pink, Gold, Shotgun, and Spiral.
Offset from the center, there is a four-sided room with two-floor, two elevated platforms on pillars where the rocket launcher spawns, and a long ramp leading from the bottom floor to the top. From this rocket room, the top door leads to a long, sharp-angled hall that exits at pink room; this hall also has a one-way teleport to shotgun room. A lower door leads to gold room, and a small curved door leads to the shotgun room. There are also two large archways and a space above them that connects rocket room to a lower room with a broken bridge.
The bridge room has two wide halls on the lower floor connecting to the shotgun room and to gold room. The bridge doors connect to pink room on one side, and a spiral down to shotgun room on the other. Across the room there are two large pillars with a head-height gap to shoot through, and a one-way teleport up to pink room. Together, the rocket room and bridge room make up the middle section of the map.
Pink room is where the active camouflage powerup and the sniper rifle spawn. One exit from pink room is part of the broken bridge across the middle. The other exit is up a ramp and into pink hall to the top of rocket room, with a window looking down on gold room. The window in pink hall is too small to easily jump through, and the angle offers little to shoot at, but it is effective for throwing grenades. Pink room is also small enough to be susceptible to grenades.
Gold room mostly functions as a connection between one of the long halls from mid to the bottom of rocket room, but it also has a one-way teleport to the broken bridge at spiral. This teleport is risky because the player exits facing toward pink room with their back exposed to anyone at the spiral from the shotgun room.
The last section is the shotgun room and spiral ramp. Shotgun is where the overshield powerup spawns. whoever grabs it receives two extra layers of shield protection and a second of invulnerability on activation. Aside from the overshield, the shotgun room is a weak position. The shotgun itself is only beneficial in close combat, and the pistol starting weapon is more consistent across all of the map’s spaces.
From the spiral, a player may look across the broken bridge to pink, but the opponent in pink may have the sniper rifle. The spiral is also vulnerable to grenades. From shotgun there is also a small bend to the bottom of rocket room, but it has blind spots to three sides, including above it where the rocket launcher spawns. The only other exit from shotgun room is the other long hall into mid, which is vulnerable from the top of the arches. There is also a teleport exit from pink hall to the middle of shotgun room, which can lead to unexpected close-combat fights.
In competitive 2v2 Team Slayer, the effect of this design is that both teams attempt to control rocket room and pink room. While players are in these rooms, the game blocks enemies from respawning nearby, which increases the likelihood they respawn in bottom mid or in shotgun room. From this setup, the team in control times pushes into the shotgun room with the overshield powerup’s respawn. For a team trapped in the shotgun room, the overshield is the best way push the enemy team and regain map positioning.
If both teams are equally skilled, it is difficult to maintain this or any other setup. In 2v2s in particular, when one player dies, the other needs to move or risk facing a 2v1. Because of these power shifts, both teams must keep rotating between strong locations on the map. Some of these positions are about information more than the damage a player could deal from them. For example, at the door to the bridge from pink room, a player can see two exits from shotgun room and a clear view across rocket room, but not all at once without stepping out onto the bridge. Two of these views are too narrow to hit a running enemy more than once, yet it is a valuable position for spotting enemies. In this way, information control is linked to map control.
With competitive play, we can also think of each action a player takes as an exchange of resources. A player may exchange shield and health for a better position when they take fire, or a player may exchange a good position to get a powerup or weapon. Strong positions are those with many options with good exchange rates. Weak positions and “traps” are those where every option becomes a risk.
All of the door and hallways are long and narrow.
Some doors are as long as they are wide, blurring the definition between a hall and a door. In the tightest of these spaces, a player can’t juke an enemy’s aim or avoid grenades.
Some of the ceilings are so low that a player will bump their head if they jump. Due to this, a player can delay an enemy push or force a retreat by throwing a grenade into these hallways and doors. These structures also force a harder commitment than doorways in tactical shooters.
The shield mechanics and their requirement for sustained precision in combat mean that a player must commit to entering an arena rather than poking ineffectually from the far side of a door.
The map’s one-way teleports also function as a kind of doorway, but they force an even harder commitment than actual doors. In casual play, where there is too much chaos to predict the game state on the other side of the map, the teleports are like a die roll: an enemy may be camping the exit, or the player may catch their enemy off guard. As a new or infrequent player, it is hard to even remember which teleport goes where, which can be a source of surprise and even humor in the gameplay.
The teleports are also a way to escape fights, since it is not possible to shoot or throw grenades through them. Whoever enters the teleport first can step back, wait for their opponent to chase, and strike them with a melee attack. Or, the player can bounce a grenade off the teleport entrance as they walk through it, discouraging enemies from continuing the chase.
One tenet of current game design is to limit the “friction” or “rough edges” that players encounter. One form of friction is to test boring skills. For example, crossing the bridge from pink room to spiral requires a careful jump, and timing it incorrectly means barely missing and falling into the open at bottom mid. There is a similar jump to the rocket platform, and another to the top of arches. These are frustrating skill checks because there is no partial failure state or room for recovery. The punishment of a slow, predictable fall from these failed jumps makes them even worse.
There are also broken chunks of the bridge on the ground of bottom mid. Although these add visual interest to an otherwise abstract map, they add literal friction to the play space. An inexperienced or distracted player trying to cross bottom mid will not realize what they are stuck on without looking down or jumping blindly, both of which cost time and may get the player killed.
We could also include the narrow hallways and low ceilings as sources of friction. These spaces feel uncomfortable. But fixing these areas, as Halo 3 did in its “Cold Storage” remaster of Chill Out, removes something from the heart of the map.
For couch multiplayer, Chill Out is less of a coherent playfield and more like a funnel for conflict and surprise.
Imagine it is 2001 and I’m playing Halo on a couch with three friends. But after a couple matches, the skill disparity is apparent and we start improvising new goals and rules: Melee only on the map Wizard, back-whacks worth 2 points, falling-whacks worth 3? Or maybe active camouflage and sniper rifles on the map Sidewinder?
If a variant grows dull, we adapt it mid match and start shooting instead of using melee, or we start driving vehicles through the fields of invisible snipers. At this point, the group’s goal with all of these variants isn’t about who won, or who is the best.
The variants are about adapting the rules, adding chaos and unpredictability so that even the weaker players have moments of success. If the variant instead aggravates the skill disparity, then a player may throw the match or break its rules; this kind of “trolling” behavior in local multiplayer is a way for a player to signal that they aren’t having fun.
This whole pattern of play is similar to how children on a playground will adapt tag into “freeze tag”, or “lava monster” (only the player who is “it” can touch the ground), or “metal monster” (the player who is “it” can only move around the structure where they are touching metal). This freeform play is not about winning or losing, and if the game locks into a solved state, where one player is stuck being “it”, the variant has failed and requires modification.
Now, if you asked me in 2001 to recommend the best map in Halo, I may have said “Wizard”. It has four sections of axial symmetry, two sets of linked teleports, a discrete first and second floor, and four powerups of two types. The teleports and symmetry create a kind of disorientation, which for casual play introduced chaos and puts a limit on tactical play. Wizard is also small enough that disorientation doesn’t matter; if the player picks a random direction and starts walking, they will find an opponent to fight. The map was also suitable to many of our game mode variants. Wizard was the go-to map for shotguns-only, or melee-only, or absurd infinite-grenade games. It also makes a great king of the hill map, due to a central pillar structure that players can only reach by jumping.
Chill Out was another key map in the rotation for our local multiplayer, but its design has more nuance to it and has stuck in my memory longer. How do we talk about multiplayer level design, is “Chill Out” good or bad? Is it a dog park to someone who wants a quiet stroll, or a playground to someone without kids?
We can list all the ways in which players play a map. We can divide a map into its components, describe their interrelations, and consider how each piece affects various players. Or we can take a narrative approach and tell stories of our times in these spaces. None of these approaches seem to fully reveal the heart of a map. But, inherently, isn’t that because a good map, like a good public park, should mean many things to many people?
You can watch a narrated tour / video version of this article on YouTube. https://www.youtube.com/watch?v=YUdUh0uE2V4
To get a better sense of how Chill Out actually plays, you can also watch this 3v3 team deathmatch ("Team Slayer") footage: https://www.youtube.com/watch?v=AwPwL3snINQ
"Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3" by Jaime Griesemer from GDC 2010 is a classic highly-recommended game design deep dive into weapon balance and Halo's multiplayer design.
"Halo and Inflexible PvP" by Andrew Yoder critiques Halo's rigid approach to multiplayer game modes, which make it painful for casual networked pub play.
FGD stands for "Forge Game Data", leftover from when the Half-Life 2 level editor Hammer used to be the Half-Life 1 editor Worldcraft, and before that when it was a Quake tool called Forge.
Because multiple studios, engines, and editor tools have used FGD, there are several different "flavors" of FGD. For example, Valve added syntax to support its unique entity input / output scripting system in Source Engine. There is no formal FGD file specification standard.
This page covers the core FGD syntax used in TrenchBroom for Quake 1 / Half-Life engines.
FGD is a text-based format. We recommend using UTF-8 encoding to support more languages. TrenchBroom requires UTF-8 without BOM.
Each entity entry follows this pattern:
Here's a simple entity example, a zombie NPC that is 32 map units wide and 64 map units tall, with one property called "Health":
Note how the in-editor help text is very important. Tell the level designer about important functionality that isn't obvious, give advice or tips / tricks.
There are three core FGD entity types: point, solid, and base.
@PointClass begins a point entity definition, like an NPC or a light
size(minX minY minZ, maxX maxY maxZ)
is the axis-aligned bounding box (AABB) size of the point entity, defined as two 3D vectors, the min extent (smallest corner) and the max extent (largest corner)
model(path, skin, frame, scale)
displays a 3D model for the entity. This can get a little complicated, see .
@SolidClass begins a brush entity definition, like worldspawn or func_wall
@BaseClass begins an entity base template; you can set entities to "inherit" a common base.
base(BaseClassName1, BaseClassName2, ... )
set an entity to include the listed base class(es)... you can also set a base to include a base, so this feature can be quite powerful / useful but beware of recursion
For example, if all monsters in your game have health, then you could create a BaseClass Monster with a health property, and then set all monster types to include that Monster base:
Entity properties are typed key-value pairs that follow this general pattern:
keyName(type) : "In-Editor Display Name" : defaultValue : "In-Editor Help"
Key name: like a variable name, usually a lower case string
sometimes with an underscore at the beginning to denote that it is a compiler-time property that won't be present in-game
Type: there are four (4) basic property types: string, integer, choices (multiple choice integer ), and flags (bitmask).
flags are a set of boolean (true / false) values, stored together as a single number through the magic of math ()
in most level editors, an entity can only have a single flags property and it must be called "spawnflags"
Value: whatever the level designer typed into the level editor
An example brush entity definition that demonstrates all four property types:
TrenchBroom can display 3D models for point entities, if the FGD file specifies it. This is useful for placing NPCs or props, where previewing model size / rotation / appearance is useful.
TB uses Asset Importer (AssImp) which has basic support for most 3D formats (.OBJ, .FBX, etc).
For certain model formats like Quake .MDL or Half-Life .MDL, you can also swap textures or preview animation frames based on the entity properties. See below for usage.
Remember: model() is TrenchBroom only, and won't necessarily work in other editors.
The most basic hardcoded usage looks like:
An example of a basic hardcoded model from Quake.FGD:
However, hardcoding the model settings in the FGD can be too limiting for swappable "prop" entities or NPCs with multiple skins or scripted animation.
To support map-defined per-entity model display settings, TrenchBroom's can parse dynamic FGD placeholders with JSON-like syntax (curly braces, named parameters in quotes):
Replace "MODEL" or "FRAME" etc. with the keyvalue property name you want, and TrenchBroom will swap in the actual value for the placeholder.
An example generic "prop" entity that uses placeholders:
An example with placeholders from HalfLife.FGD:
TrenchBroom's FGD flavor also supports conditional expressions. An example with expressions:
For more on placeholders and expressions, see Trenchbroom Manual > "Display models for entities":
Valve Developer Union: "Anatomy of an FGD (and How to Write Your Own)" is a great introduction
Valve Developer Union: "Advanced FGD Editing Made Easy" shows off tips and tricks
Valve Developer Community: "FGD" goes into detail about Source Engine 1 specific FGD extensions and quirks... not useful for TrenchBroom though
C++ FGD parser example: TrenchBroom (via GitHub)
C# FGD parser library: Sledge.Formats (via GitHub)
the overall visual arrangement and organization of shapes in a level; landmarks, vistas, approaches; also, why "leading lines" aren't real
Composition is the overall visual organization of the level. There are two types of composition:
Spatial composition: the overall big picture 3D arrangement of core masses. We cannot guarantee a specific view, and instead account for a wide variety of viewing angles and positions.
This is "composition" as practiced in 3D arts like architecture, interior design, and sculpture.
Shot composition: how the level looks in the player's 2D camera frame / screen, from a specific angle at a specific position.
This is "composition" as practiced in 2D arts like drawing, painting, photography, and film.
A lot of level design tutorials and resources out there claim that specific shot composition is really important. For many reasons, we disagree and we have a different definition of composition. Instead, we argue that spatial composition is much more important than shot composition.
(TODO: image)
Spatial organization involves building-up a spatial hierarchy, where some parts of the level should feel more important than the other parts. At the top of the hierarchy are key landmarks, focal points, and central areas that contrast meaningfully with their surroundings and anchor the rest of the composition. Some ways of building spatial contrast:
Height. Big tall towers in crowded spaces, or small short objects in open spaces.
Density / spread. A wider open space surrounded by smaller narrower structures.
Orientation. An angled object that breaks from the surrounding grid.
In the image above, notice how the central legislative chamber of the by Le Corbusier (bottom-left) uses several types of contrast in its floor plan. It's big, it's a circle in a box, and it's rotated at a skewed angle / axis that breaks from the rest of the grid. So it feels very important and vital to the function of this building! If this were a level, the main setpiece or final boss fight would probably take place in this round room.
The chamber is off-center and almost touches the eastern wall. But it doesn't feel off-center, does it? That's because focal points create new centers within the spatial organization. Imagine a zone of influence emanating from important area; it sort of "pulls" the rest of the composition around it. (See diagrams in bottom-right for how focal points influence how we perceive the "center" of a space.)
And remember, hierarchy depends on local contrast and context. A tall thing only seems special if it is surrounded by short things. A small thing will feel more special if surrounded by bigger things.
A landmark or point of interest (POI) is a unique and memorable shape, mass, or location in a level.
TODO: examples
TODO / IMPORTANT: landmarks have to feel relevant and useful !! otherwise they don't function as landmarks!
Actual landmarks (what the player notices during play) vs. fake set dressing landmarks (e.g. random skybox elements in The Last Of Us don't orient players, aren't actually useful)
A sightline is a trajectory of empty open space that offers a possible view of another space.
Sightlines are tools that players use when it seems relevant to the current game state and goals. If the player has no reason to look along a sightline, then there is a high probability that they won't use the sightline at all. A sightline is an opportunity / situational tool that the player might ignore, it cannot guarantee behavior.
Even if the player looks in a certain direction, there is no guarantee they will remember or process what they saw. (Imagine reading a boring book or watching a boring movie; your eyes may see the words / images but that doesn't mean you actually read or process it.)
In the diagram above, level designer Sal Garozzo highlights common strategic sightlines on a 2015 version of the competitive multiplayer shooter map de_cache in Counter-Strike: Global Offensive. Each sightline offers a different degree of coverage and information for attacking / defending the bombsite A area.
However, would all these sightlines be readily obvious to a first-time player, at first glance?
No. In fact, recognizing and memorizing these sightlines is part of learning the game / learning the map. Competitive players must actively study these sightlines; it is NOT a natural subconscious obvious way of looking around. The existence of a sightline does not mean the player will use it, nor even know it's there.
For more on sightlines in a multiplayer context, see .
So how do we convince the player that, on first glance, the sightline is important?
A vista is an exceptionally deep scene composition that offers an overview of the next area, giving the player an opportunity to formulate a strategy. In modern encounter design, it is very common to introduce an arena with a vista beforehand, especially if the arena layout is complicated.
(TODO: talk more about vistas with examples that also emphasize the flow / layout into the vista)
An approach is a path with a vista.
(TODO: show approach examples)
(TODO: example... Fallingwater?)
is a widespread belief / design pattern in real world architecture which argues that humans navigate spaces by seeking prospect (vantage points) vs. refuge (safe areas), evoking their innate survival instincts.
We think prospect-refuge is bad theory (and bad science / bad art) with limited applications to level design. Instead we recommend using existing concepts and terminology with less philosophical baggage, like sightline vs. cover.
For more on why we think it's bad theory, see .
(TODO: include prospect refuge image)
Shot composition is the 2D arrangement of level geometry relative to the player's camera perspective.
And ok, some of this matters, sometimes. Sightlines, approach, color and lighting, perspective -- all these aspects can matter, sometimes.
But some level designers misinterpret shot composition as level design. They argue that if you arrange everything in your level to make nicely framed views, then players will magically wordlessly know what to do and where to go.
Composition is not mind control. This is such a common misconception in level design theory that we're going to devote a whole section to debunking it. For this reason, we call this the shot composition fallacy: a belief that seems true and useful, but is actually deeply wrong, leading to a worse understanding.
First of all, a screenshot is not a level. This may seem obvious, but many level designers seem to have forgotten.
Instead, a screenshot is an image of the game at a specific position, angle, and time. Taking a screenshot is an act of photography.
Do photos capture an objective truth about a place or time? No. A photographer is an artist who chooses a place and time to create an image. Even a dev overview screenshot of a blockout emphasizes and downplays certain elements. A photo is an artistic interpretation that captures only one aspect of an actual person, place, or thing.
No photo can replace the experience of visiting a place or meeting a person, and no screenshot can replace a playtest.
More importantly, there is no guarantee the player will imagine the same framing or composition. The player never plays your screenshot.
There's currently a trend in level design to analyze screenshots by drawing "leading lines" that seem to point / guide the player's eyes toward a landmark in the distance.
However we argue that leading lines aren't actually effective, and furthermore, leading lines don't even make sense within their own logic.
Leading lines misunderstand human gaze, perception, and information processing. Retina scans and tech show how leading lines and other traditional tenets of 2D visual composition don't "lead the eye" in the ways we think they do. Even if they did, there's no guarantee the player actually processed the visual information.
Literally every hallway you build will seem to converge in the distance. This phenomenon is called foreshortening, creating an illusion of depth in an otherwise flat 2D image. Games with isometric or parallel projection make leading lines impossible. The is interesting, but it's not level design.
Ironically, leading lines mislead level designers into believing that shot composition, environment art, and set dressing are central level design problems instead of , , or . Even if leading lines worked (which they don't), you would do it near the end of the level design process. Focus on the fundamental foundation of the level first.
Leading lines routinely fail if you actually bother to playtest. You'll find that there is a 99% chance the player will look somewhere else, and a 1% chance they will look in the intended direction for 0.5 seconds. A screenshot is not a level, no one ever plays a screenshot.
Leading lines are a when you move the game camera into a specific place to frame a specific view. Of course the screenshot will follow rules of composition! That's because you composed it like that! And then you drew lines on it! This is photography, not level design. Consult the about the absurdity of self-fulfilling composition patterns.
This isn't how people navigate spaces. People use pattern recognition, prior knowledge, and cultural associations to build mental maps in their mind. is a complex active process of moving and using an environment, not just looking at one spot of a level from one angle.
Framing a view within a space is called photography, and it is a skill that humans practice and develop. It is not a natural subconscious process.
Shot composition makes more sense for photography, film, and other static flat 2D media where the author has strong control over the camera, and the audience can pay special attention to the entire image. However, it makes very little sense for interactive environments where the player can move the camera to the wrong place at the wrong time. A video game level is a place, not a painting, photo, or film.
For much better ways of influencing / "guiding" the player, see .
It may seem like sightlines and leading lines are the same. They both relate to tracing what the player sees from their camera perspective.
However, sightlines and leading lines emphasize very different things:
Sightline: a trajectory of empty open space that offers a possible view of another space
A tool that players use when it seems relevant to the current game state and goals
Again, we want to emphasize:
Spatial composition is the overall organization of 3D masses in the level.
Hierarchy is when some things seem more important than others, usually because they contrast in terms of size, shape, spread, or angle.
Landmark
Apply this theory to the .
For more on "guiding the player" with architecture, see and .
Our stance against leading lines / shot composition in level design is currently not the norm in the game industry. While we think it's 99% brain poison, other credible designers disagree:
by Miriam Bellard, Rockstar North (GDC 2019) goes over Rockstar's approach to filmic environmental composition in Grand Theft Auto 5 levels. Bellard suggests a walkthrough method with rule-of-thirds overlay, and emphasizes affordance / salience model of embodied spaces. She also "myth-busts" leading lines and weenies while simultaneously arguing they are still useful. Overall, this is probably the most "balanced" industry talk on shot composition, but maybe just don't drink too much of the evo psych / .
by Jim Brown, Epic Games (GDC 2014)
How to run a playtest, and then collect / analyze data
A playtest is when someone plays your level, and you watch whether your level works or not.
Playtesting is a foundational skill and process in game design. You should do it.
Playtests are when you witness whether your level is "fun" or boring, clear or confusing, pleasant or annoying. If players hate your level, you should deal with that problem as soon as possible. "Playtest early and often."
Level design takes a long time, and it is natural to lose motivation during a project. Playtesting with someone else can boost your energy when you see someone else enjoying your terrible broken half-broken map, despite your misgivings.
The commercial game industry takes playtesting so seriously that they perform many phases of testing like user research, QA, test markets, usability, certification, etc. The biggest game companies even run their own dedicated playtesting labs.
Each playtest has a different purpose, depending on the audience.
Self-playtest: you test your own level.
You should playtest your level yourself every day, as part of the design process
Good for catching obvious problems (does the level load? is the doorway wide enough?)
Critiques: join an online , ideally a forum or Discord with specific experience in the genre or game engine.
If possible, try to do an in-person playtest. See if there's a local and/or indie meetup.
You need people with enough game design experience to contextualize their feedback appropriately -- people who know how to look past unfinished systems, obvious bugs, or placeholder art, and get to the real problems at the heart of the design.
There are many ways to run a playtest session.
Below is a general process for an in-person public playtest:
Before you playtest, you should figure out what you're testing! Treat it like a science experiment -- form a hypothesis and design a procedure.
Here's a basic playtest prep checklist:
Briefly introduce the concept and how long the playtest session will run, set some basic expectations to respect the playtester's time and energy. If the playtest session may contain jump scares, spiders or insects, flashing or flickering lights, sexual content, or graphic/explicit violence, then give a content warning and get the player's informed consent.
You can also tell the playtester what you want feedback on, and set some basic boundaries and focus for the playtest. A more specific briefing is very helpful if your playtester is a fellow designer, so they can tailor their feedback.
Example briefings:
"use WASD and mouse... have fun"
"I'm looking for combat ideas, tell me if the encounters are any good"
"I haven't art passed the level yet so just focus on layout, these are all placeholders"
"try to use the double jump a lot, I want to see if it works well for this level"
But keep it brief. Don't over-brief and don't dwell too much on disclaimers, especially if you're having other developers playtest. As designers we often feel insecure or anxious about how our work will be received, but We understand your levels will be unfinished or work-in-progress, with placeholder assets and bugs everywhere.
Most of the time should be spent watching the screen, taking notes about player behavior, reactions, or anything that needs fixing. Make sure to watch from a short distance behind the playtester(s), don’t just breathe over their shoulder.
Feel free to ask brief clarifying questions about the playtester's behavior or thought process, but resist the urge to interrupt the playtest to apologize or explain. Whenever the playtest goes wrong, let that discomfort and anxiety stew in your mind for a little while. However, if the playtester is definitely stuck or if the level is clearly just broken, then go ahead and intervene.
If it is not an in-person playtest, then ask the tester to record their screen and send a private link to the video upload. Or better yet, the playtester can broadcast a private live stream and take questions via chat or voice. For multiplayer maps, it is best to ask an existing player group, server, or clan to play on the map and allow observers.
Track basic stats such as play time, deaths, win percentages, etc. Most of this stat collection does not require any special plugins or tools, just attentive note-taking.
Some games can automatically aggregate player data and visualize patterns, especially for multiplayer maps. Do players use the shotgun too often on a map intended for snipers, or are too many players dying outside the spawn room?
Telemetry is automatically collected data sent to a stats server that can track player behavior and display the data in a table / spreadsheet. Types of telemetry include:
Data tables with stats for most common weapon, progression, or gear
Heatmaps, top-down visualizations of where players frequently move, earn points, score kills, or die.
(TODO: heatmap example)
Ask for feedback and debrief the playtester.
Have a few survey questions ready for the playtester. You could ask comprehension questions ("Did you notice the orange light above the door? What do you think it meant?") or ask for more subjective opinions ("Did the boss fight feel easy or difficult?)
Be kind and respectful to your playtesters even if they're giving you feedback that you don't necessarily want to hear. If someone offers suggestions in good faith, smile and take it with grace no matter what. The suggestion itself might be a poor solution to a design problem, but the reason for the suggestion -- and the issue it highlights -- is almost always real and valid.
But also remember, the playtest session is not for the tester's benefit. If the playtester has a harmful attitude or gives abusive feedback, especially at an in-person playtest session, then you can totally just end the playtest and ask them to stop playing or talking.
After the playtest, you need to figure out what the heck happened and what you're going to do about it.
"We do a lot of playtesting at our studio, and we have very good telemetry tools for recording data from the playtest that we can analyze after the fact.
This telemetry [pictured below] is from a pre-release 20 player playtest. [...] The bottom numbers show different armor sets on each row, but different days from left to right. These let me see patterns in terms of popularity of gear, where in the game it's popular, how long players stay on the same gear, when they switch... and I use these charts to identify clumping that might be unhealthy.
... At the start of the game there's not many armors available, so everybody is using one of the first three [...] But what's happening here? A lot of people are sticking on this Alfheim armor. Is that something I should look into? (Spoiler, we did nerf the Alfheim armor...) So it's about looking at the data to reinforce your expectations, to have a healthy spread."
-- Rob Meyer,
The goal of a playtest is to help the designer predict whether their game works for their audience. It's not about the player's performance. Watch out for these common tendencies:
New to games / game dev: too "nice", doesn't verbalize problems or frustrations
Gamers: too nitpicky, exaggerates small problems, performs too much
If you're unfamiliar with the genre or design style, say so.
Ask "what do you want feedback on?"
Ask "is there anything I should know before I start?"
Playing
Think aloud, try to say what you're thinking constantly. No one can read your mind. At the same time, don't be offended if the dev ignores what you say.
Don't nitpick unless the dev asks you to. If you break the game, tell the dev and then move on. Unless the dev asks you to repeat the game breaker for analysis, don't continue to break the game in the same way -- don't seek to embarrass or humiliate the dev.
Be honest with expressing your emotions. If you like something, say so. If something confuses or surprises you, say so.
Debriefing
Say what was memorable to you, positive or negative.
Ask questions about intent and planned solutions, make it into a conversation.
At Valve Software, level designers playtest every Friday across a variety of different playtester types (fellow designers, non-designers, non-dev staff, sometimes "open" public testing). Playtesting is fundamental to their design process and drives many of their decisions every week. Valve level designer Phil Co discusses their process:
On a typical project at Valve, the cabal (smaller subset of the team which consists of 6-8 people) works on a weekly cycle. Every Friday, we would playtest the section of the game that we're responsible for with someone from outside the team (even outside of the company depending on how far along we are). Everything we do during the week is focused on that Friday playtest. [emphasis added]
On Mondays, we have meetings where we decide what the goals are for the playtest and who is responsible for each task. [...] You might have to prototype a new mechanic which would involve a programmer, or you might have to perform an art pass of your level which would involve an artist.
We learn everything from playtests, however, so we might have too much of one particular gameplay and the playtester suffers from fatigue. We correct this issue in multiple ways.
For example, in [Half-Life 2] Episode 2, where the player gets the car on the bridge, we decided to add a combat high moment. Most of the level up to getting the car is combat but with just a few enemies at a time. It was made to be sort of a funhouse of zombies. We added the building where you pop the roof panels off so that Alyx can help you with the sniper rifle based on our playtesting feedback.
-- Phil Co, from , circa 2013
GDC 2009: "Valve's Approach to Playtesting" (, free) by Mike Ambinder is the foundational industry text, covering playtesting fundamentals. Ambinder outlines the core bread and butter "direct observation" and iteration process at Valve, which is definitely the most helpful thing for the average level designer. There are two important historical notes: (1) data science / telemetry is now much more important in the industry, (2) biometrics like heartrate monitoring / brain wave recording / eye gaze tracking is rare in the industry, and other studios think it's "more trouble than it's worth" for level design. (Ambinder is an experimental psychologist, so of course he favors biometrics.)
GDC 2017: "Playtesting - Avoiding Evil Data" (, ) by Adriaan de Jongh covers modern playtesting practices, with practical tips for how and when to run playtests. De Jongh argues "evil data" is "playtest results that are distracting, unclear, or misleading", so it's important to focus on frequent direct observation with a variety of playtester demographics. Don't bother with forms / surveys / questionnaires, instead send a template email to remote playtesters to record their screen and voice with and then upload an unlisted video.
open world stealth single player medieval urban storytelling
Thief: The Dark Project (also known as Thief Gold, Thief 1, TDP, or simply, Thief) by Looking Glass Studios is a first person stealth game about quietly sneaking through shadows to avoid guards and steal treasure in a gritty fantasy steampunk city.
This 1998 landmark game fostered a slow methodical RPG feel that contrasted sharply with the fast arcade violence of Doom (1993) and Quake (1996). Unlike Doom or Quake, if you run through the front door and try to fight enemies in Thief, then you will quickly die. Instead, you must roleplay as a street-wise anti-hero thief who tricks the guards with distractions, or better yet, patiently observes the guards' movements and cleverly slips through the gaps between the patrol routes. Thief above all is a first person game about watching but not aiming, hiding but not running -- and sloppily improvising when all your plans go horribly wrong.
Years later, Thief prompted three sequels and inspired future generations of "immersive sims" -- games that emphasize object interaction, sprawling level design, environmental storytelling, and non-violent play styles. We study Thief because it creates a stunning sense of world and agency that is still rarely matched today.
From the very first mission of Thief (), every level begins in a safe public territory and then a restricted private territory that you must infiltrate and loot. The public is usually an open common space where you can roam the city streets with little danger or penalty. In contrast, the private is usually well-guarded with a heavily fortified front entrance.
The first step in most Thief missions is to map out the private area's boundaries and probe for any holes or vulnerabilities. "Casing the joint" is fundamental to the fantasy of thieving, and thus crucial to Thief's experience goals. It won't feel like sneaking unless there's a safe public outside and a risky private inside. When they begin the fourth mission "Assassins" (by Mike Ryan with assistance by Greg LoPiccolo), players are well accustomed to this public exterior vs private interior pacing pattern. That's when the designers flip the script and play with the player's expectations. Assassins both exemplifies and subverts the game's use of public vs private space, questioning who really owns a city.
The mission consists of four general beats:
Intro: stand inside a shop, almost get killed by assassin NPCs
Follow: secretly follow assassin NPCs through the city, back to their employer
Mansion: sneak into their employer's mansion and steal his stuff
(optional) Escape: if the alarm went off, you must backtrack through the city
The layout is two parts: the city streets and the mansion. The upper-left mansion is almost half of the map, and originally it was even bigger, but late in development it had to be scoped down for memory to run on the game's target system requirements.
You begin inside a shop, which is unusual in Thief. All the previous missions begin outside, usually right outside a main entrance. This room is also unusual because Thief features a shop mechanic before every mission, which is strictly treated like a separate mode in a menu screen, and it's never an actual shop location that you can visit.
When you take a step forward, you activate a trigger that launches an arrow through the window to murder the shopkeeper. Then you overhear two assassins outside, who walk away thinking they have murdered you instead.
Your mission objectives now change completely. Instead of breaking into a local temple, you must now follow the assassins back to their secret base without being detected. This type of bait and switch is extremely unusual, and never repeated again throughout the entire game.
So already within its first minute, Assassins subverts numerous design norms in Thief. The shop was a fake shop, the mission briefing was a fake briefing, the objectives were fake objectives. These surprises foreshadow the bigger surprise near the end of the mission.
But at this point, the player barely has any time to think (nor to loot the shop) before they must promptly leave to follow the assassins.
The game never explains how to tail the assassins back to their hideout. The lack of tutorialization for this unannounced surprise game mode is perhaps frustrating for contemporary players today. Players must guess the rules and strategy by trial and error, but you quickly learn there are three ways to fail:
Sometimes the assassins stop and turn around to see if they're being followed. If they see you then they will start chasing you and you kinda fail the mission.
If you walk or run too close to them on metal plates, it makes a loud sound. If they hear you and get too suspicious, then they will start looking for you and you basically fail.
If you trail too far behind, then you will lose their trail and quickly get lost in the mazelike streets. If you lag too far then you will eventually trigger a hard mission failure.
This mission is the first expansive sense of the City that you get, as a vast labyrinth of narrow medieval streets and alleys without a grid pattern or signage. Here, the public sphere is unknown, huge, and overwhelming, and it is very easy to get lost. It is the only time in Thief that the City truly feels like a big city.
Note that it only feels like a city. Compared to any real world city, the layout is actually not very complicated. A handful of loops is enough to confuse any player.
The assassins' route from the shop to the Ramirez mansion is randomized with different branches and stopping points, but there are basically only three possible paths. When they leave the shop and cross the metal bridge at the river, they can take:
Short path: they head west, directly to the mansion.
you basically skip half of the level
Middle path: they walk north to a statue, then west toward the mansion.
Near the end of the chase, the assassins always walk through a specific archway, up a ramp, and turn the corner.
This part is a masterpiece of stealth encounter design, condensing all of the player's sneaking know-how into a minute of tense improvisation with incomplete information.
First, you follow them through the arch. The archway's so you can easily notice a patch of darkness beneath the arch. The level designer clearly wants you to go there, as the lone island of safety surrounded by dangerous bright areas.
However, that patch of darkness under the archway is misleading. It's not really safe. Your light gem indicator will glow yellow, which means you are still somewhat visible, enough to cause AI to become suspicious.
You have three options, and none of them feel good:
Option A: If you stay under the arch at the bottom of the ramp, then the assassins might turn around, see you, and get suspicious. Fail.
Option B: If you fallback to before the arch, then you break your sightline and you won't be able to see where the assassins went after the top of the ramp. Fail.
Option C: If you continue up the ramp, the bright street lamp will give you away, and even if it didn't, then you also don't know if the floor material at the top will make your footsteps too noisy. Fail.
You can't stay still, you can't run away, and you can't move forward. The level designer is messing with you. It's a trap.
Most first-time players are paralyzed with indecision and go with Option A -- standing still and praying. The more adventurous go with Option C because they know that a narrow 90 degree corner means the assassins can't see you either, and assassins will never backtrack.
But still, how do you track the assassins from there? They could be standing right there, watching for you. You can't risk turning the corner. So instead, you have to listen.
When they turn that corner and you hear the tell-tale clang of boots on metal, you freeze and listen for how many metal steps you hear. A lot of metal steps means a long metal catwalk. That's the beauty of Thief's footstep mechanic: it translates sound into space. The designers even emphasize the metal stub by putting three different floor materials together, which is pretty rare in Thief. They want you to notice the quick contrasts between stone, metal, and wood footstep sounds.
Once you find your assassins' hideout, a castle owned by some guy named Ramirez, you're tasked with phase 2 of the mission: robbing him of everything he owns. It's unexpected. You feel like the mission should be over now, but instead it feels like two missions-in-one. (But what did you expect? How else could this have ended?) The Ramirez mansion is much easier to solve than the streets. There are only a handful of guards patrolling the top floor, which means you can control the entire area very quickly. In contrast to the really thoughtful city street design I analyzed earlier, this interior floorplan is simple and comprehensible, the main corridors are narrow and arranged somewhat symmetrically, and many of the floors are made of relatively muted stone.
In comparing the first mansion mission (Lord Bafford's) and this, the second mansion mission you play, some differences arise:
Bafford's place is much bigger and sprawling than Ramirez's place.
Bafford has a throne room and separate wings with lots of art everywhere. Ramirez has a simple, compact villa plan with central courtyard; the walls are textured plainly; he has also installed hidden wall-slits to spy on guests in their bedrooms. (Creepy.)
Bafford's basement is old. Ramirez has recently renovated his basement with an illegal animal pen and office / counting room.
The differences in level design are forms of characterization: the "B" or "R" banners make these spaces private and personal. The oversize and overdecoration implies Bafford is obsessed with just the image of power; meanwhile, the comparatively spartan Ramirez prefers the power of power. When you're infiltrating these castles, you're actually sneaking into their heads and learning their secrets and insecurities. Think of it as a proto-Psychonauts style of environmental storytelling, the home as a metaphor for its owner.
The end of Assassins is fantastic. It's probably the best part of the entire mission. Unfortunately this is also where Looking Glass really dropped the ball.
You get to play the ending only if:
you're playing on Hard or Expert difficulty
you triggered the alarm in the Ramirez Mansion
It is common for many players to never trigger the alarm. Hard or Expert players will find Assassins to be a bit easier than previous missions. And in the previous mission Down In The Bonehoard, Thief's terrible climbing code forces players to quick load / quick save a lot. Combined with the zero-warning failure of the earlier part of the mission, players will be highly primed to play as perfectionists.
And if you never trip the alarm, the game never triggers the last part of the mission: Ramirez's guards take over the streets and you have to sneak past them to get back to your neighborhood.
The "get back out" portion of each Thief level is usually trivial. You backtrack through an , past the unconscious corpses of so many guards. Even if they're still patrolling, you already know their patterns and where to hide.
But here, the game spawns overwhelming odds, about twenty new guards -- more than the number in the mansion! -- and they're all permanently alerted, randomly roaming around with zero predictability in brightly lit streets. It's an unexpected change in stakes and world state. All those corners suddenly function very differently when you're coming back from the other way. The city streets are familiar and alien at the same time. Ramirez has privatized the City: the public is now dangerous. The City starts the mission as a neutral space. Then it's a victim, bisected by Ramirez's private space, a large manor cutting through a dozen city blocks. And now the City is your enemy.
You can watch a narrated tour / video version of this article here:
Essay about acrobatic community-made levels where players perform zero input
In racing games like TrackMania and platforming games like Super Mario Maker, users have built complex “Press Forward” and “Auto-Mario” levels that propel the player’s game character to perform dazzling feats of acrobatic virtuosity, but with trivial or minimal player input.
We argue this type of “zero player level design” complicates typical ideas of gameplay and players: these zero player levels are playful design objects that play with not-playing, and emphasize the virtuosity of architectural choreography.
Many contemporary video games feature robust built-in editor tools that let players build new levels without the need for any specialized professional software or hardware. The accessibility and immediacy of these tools often attracts people who do not usually consider themselves to be game designers, and new design patterns often emerge organically out of these casual player-designer communities. These passionate amateurs use level design very differently from the industrial developer’s canonical design patterns, constituting a practice that I call "local level design.”
Local level design often happens in a very specific context and community to the original game. For example, in 2010, Valve changed how players unlocked items in its first person multiplayer shooter Team Fortress 2; to earn new upgrades, players suddenly had to grind achievement goals, such as killing a certain amount of enemies using a specific weapon. In response, the player community quickly established achievement grinding servers with specially designed achievement farming maps so that players could easily fulfill these achievement goals and acquire these upgrades more quickly than during typical unfocused play. Officially, Valve strongly disapproved of these new achievement servers and maps, arguing that it was tantamount to a cheat or an exploit.
As a rebuttal to this moral crisis, a user named The303 made “achievement_all_v4”, a novel achievement trap map where everything seems like a normal achievement farming map for a few minutes, until a giant monstrous invincible cat erupts from the ground and attacks every player with powerful laser beams and cannons. At the end, any surviving players on the entire server are wiped-out via nuclear detonation. The goal of the map was clearly to trick players into thinking they were going to play on an achievement grinding map, but then punish them in a highly visible and humorous way.
Both the achievement grinding map and the ensuing achievement trap are clear examples of local level design as a form of discourse, and in this case, these maps acted as a moral dialogue reflecting on the community’s actions. It exemplifies how users frequently invent new ways of understanding the game's core building blocks and assumptions, thus discovering entirely new ways to use the game’s design language.
I want to talk about a form of local level design that has emerged across several different games and genres: the “zero player level” that paradoxically calls for minimal or trivial player input to complete successfully.
These levels complicate typical ideas of player agency in games, and center the player-designer as an elegant choreographer rather than a wry commentator or skilled performer. This phenomenon intersects with how these communities develop (or debate) a game’s design language, how they understand the boundaries of their various design practices, and how the player community maintains its identity.
Nadeo’s TrackMania racing games feature a built-in track editor prominently featured in the game’s advertising materials and main menu. To facilitate file sharing, the game client automatically downloads new user-made custom tracks when the player connects to a multiplayer server. A community-run database called TrackMania Exchange also lets players upload and archive their track files, and serves as a social hub for players to discuss and analyze favorite tracks and building techniques.
TrackMania games usually feature a hundred or more tracks built by Nadeo that gradually increase in length, complexity, and difficulty. Early TrackMania games even forced players to race these tracks to earn currency, which they could use to unlock new blocks for the track editor. For new players, these pre-built included tracks establish a design norm of commonly accepted track design patterns, and many custom player-built tracks rely on these stock tracks to tutorialize certain skills and driving maneuvers. Later TrackMania games have since formalized track design into three game modes / genres: Race (tracks that emphasize competition with other cars), Platform (tracks that emphasize tricky jumps and drops), and Puzzle (tracks where progression and checkpoints are unclear).
Notably, Nadeo does not include the community favorite “press forward” (PF) tracks in its taxonomy.
Instead of challenging players to hone their reflexes and wits on the track, the PF beckons the player to simply hold down the "forward" button and watch what happens as a more passive spectator. Through no skill of their own, the player’s car executes amazing stunts and maneuvers based on the track’s delicate Rube Goldberg-like orchestra of serendipitous aerodynamics -- a car might spin 1080 degrees in the air before barely grazing a ramp in just-the-right-way to land perfectly on the track below. Paradoxically, if the player makes any kind of choice like letting go of the "forward" key, or (god forbid) turning left by 0.1 degrees, any miniscule deviance leads to a disastrous crash.
The only way to fail a PF track is to play it and to make an actual choice. Successfully completing a PF requires the player essentially to give up their agency in the game world. In this sense, it is clear why Nadeo has sought to suppress the press forward. This is a radical design practice that resists the intended mode of playing TrackMania. It is a surprisingly existential video game world that basically punishes players for trying to wield any agency or control, and furthermore trivializes the achievements of skilled drivers who race on “normal” tracks. When virtuosity is guaranteed, it is no longer virtuous! The PF strikes at the heart of a local level design community and asks us, what makes a strong player community -- players or designers?
The “play” and “skill” of the press forward is less about its performance, and more about its construction. The most widely-acclaimed PFs seem to focus on sheer size with complex level-over-level intersections and unanticipated improvisation of non-standard track pieces. For instance, ThunderClap’s PF “Hyperion’s Wrath” somehow directs the player’s vehicle to hit the track at a strange angle, drive across it seemingly sub-optimally, fall off, spin erratically, skid along a decorative chrome statue, and then land perfectly on a half-pipe. The design goal is to create a sort of uncanny performance that a human player could probably never achieve on a track that is otherwise invisible and illegible to humans. Instead, the track performs itself, and human players are merely its instrument.
There is a notable variant on the PF: the “press nothing” (PN) which requires players to press absolutely nothing on the keyboard. These track designs accelerate the player’s car without any player input, usually with a path of “boost pad” track blocks placed directly after the player start. However, PNs are much less popular than PFs, perhaps because cars gradually lose velocity as they proceed through the track; to maintain sufficient speed, a PN designer must dedicate substantial space to boost pads at regular intervals, which compares unfavorably to the PF’s aesthetic of surreal immediacy.
Nintendo’s Super Mario Maker series (SMM) features a user community actively managed (sometimes too much or too little, depending on who you ask) by its developers, inviting its users to build new courses using the common building blocks and platformer tropes of the popular Super Mario games.
In a big departure from typical Mario games, the SMM games de-emphasize completing a pre-made sequence of levels.
While Super Mario Maker 2 does feature a humorous story mode where Mario must rebuild an accidentally demolished castle by completing various “jobs” (pre-made example courses built by Nintendo), these one-off job courses are clearly meant to demo various game mechanics, powerups, and building patterns, and do not feature any coherent storyline or progression like other Super Mario games.
SMM 2’s main menu button layout echoes this shift away from playing Nintendo’s stock courses: the first option at the top is “Course Maker”, followed by “Story Mode”, “Course World” (to browse other users’ levels), and finally “CourseBot” (a utilitarian menu to manage your existing course files and downloads).
The demo courses are just one of Nintendo’s attempts to develop a shared design language and/or impose design norms upon the SMM community. SMM2 in particular features a new community “tag” system, where users can attach labels to describe courses.
When a course evokes the common platformer gameplay of the Mario series, users are supposed to tag it as “Standard”. Meanwhile, courses about slow methodical deduction with minimal screen scrolling garner a “Puzzle-Solving” tag, and a “Speedrun” tag implies heavy use of quick skillful continuous movement against a timer. Note the similarities to Nadeo’s TrackMania track categories (Race, Platform, Puzzle). Also note that some course tags can be merely descriptive, such as the “Short and sweet” tag.
There are two crucial constraints to SMM2’s tagging system:
(1) a course can have a maximum of two primary tags to be displayed in the main browser menu
(2) tags are predefined (and localized) by Nintendo, which means users cannot invent their own tags. Instead, grassroots community genres must be labeled directly in the course title, which limits the discoverability of these levels by the rest of the global SMM community.
The tagging limitations predictably lead to heated genre debates within the SMM2 community. What is allowed under a Standard tag, and would a Spanish-speaking player understand this tag differently when it is localized as “Tradicional”? Can a Standard course feature Puzzle-Solving and Speedrun sections as well? What does it mean when Nintendo refuses to bestow official tags upon certain community genres, such as the popular “Kaizo” courses that focus on comically unfair difficulty? Yes, SMM2’s tags are a big improvement from SMM1’s lack of filters and categorization, but certainly this new form of classification is not without its own problems.
Unlike the relative popularity of PFs / PNs in TrackMania, the SMM community heavily prefers its own variant of the PN, the “Automatic” level, or “Auto-Mario.” Auto-Mario courses depart from typical Standard, Puzzle-Solving, or Speedrun frames, and require players to press absolutely nothing on the game controller. While such automatic levels were an unofficial genre devised by the SMM1 community, the existence and use of an official “Auto-Mario” tag in SMM2 now represents an official canonization, as well as hope that Nintendo actually pays attention to community output.
“Keep” courses are the SMM equivalent of the PF track in TrackMania. Keep Walks, Keep Runs, Keep As, Keep Bs, all encourage the player to continually hold right or to jump and continually build-up speed, and the tutorial is right there in the title. These courses are less popular than the typical no-input Auto-Mario course, likely because there are already a wide variety of ways for SMM designers to maintain velocity and to redirect the player -- so requiring the player to hold down a button is not as necessary as in TrackMania.
Auto levels often rely heavily on the trampoline object, which can either push the player left / right or up / down. The most common way to begin the Auto level is to place a trampoline a few tiles above the player’s start position, so that when the trampoline falls due to gravity, it instantaneously propels the player to the right.
The trampoline’s versatility leads many users to design trampoline-themed Auto-Mario courses, like in user So yo mogi’s (そよもぎ) course “Bane-darake no zenjidōmario ritānzu” (バネだらけの全自動マリオリターンズ) (“The Return of Auto Mario: Full of Springs”) where they use dozens of trampolines to create complex emergent behaviors, like cannons that shoot trampolines that bounce on other trampolines, with a perfectly timed trampoline that pushes Mario narrowly through the split-second gap between the dozen bouncing trampolines.
This interest in complex simulations has culminated in Auto “RNG” (Random Number Generator) courses that players can complete only if a very rare randomly-generated object or interaction occurs, such as with user Phenotype’s course “Lucky Draw” which relies on a 1-in-7.5-million chance for a series of magikoopa enemies to all randomly conjure coins instead of any other object. As the course title suggests, Lucky Draw is basically a slot machine built with Mario blocks, and at this time of writing only 35 plays (of 18,000,000+ attempts around the world) have been successful. The only viable player strategy is to leave the Nintendo Switch console running the course constantly, overnight, as if it were mining for cryptocurrency or training a machine learning network. In this way, the Auto RNG completely negates the typical Mario player’s platforming skills in favor of exposing the game engine’s machinations.
Unlike most levels which center the player’s performance, the zero player level’s very shape and geometry is the performance. That performance is a dance, a movement in space to a rhythm.
Some Auto-Mario levels even double as “Music” tagged courses, which use special music note blocks that can sequentially activate to play a song. In Media Molecule’s game Little Big Planet, creators also used the in-game editor to create no-input “music levels” roller coaster rides with long walls of motion-activated music. Metanet Software’s indie platformer N also featured fan-made Don’t Do Anything (DDA) levels -- and Metanet’s advertising for the sequel N++ focused on photographs of dancers.
Players, player-designers, and developers of these games all seem to relate this activity to music and dance. Which makes sense, because so much of zero player level design involves embodied intuition. Every TrackMania PF designer must reach a minimum fluency with TrackMania’s car physics and handling, for how else can they predict how a certain ramp will cause the car to turn at a certain rate and launch at a certain speed? The only way is through trial and error, practice, and patience. Every PF represents at least days of painstaking playtesting and repeated rehearsal -- if not weeks, months, or in the case of the PF Hyperion’s Wrath, two years of work.
The Super Mario Maker course builder helpfully visualizes the player's jumps and trajectory, helping course creators fine-tune their object placement. This type of debug feature is surprisingly rare for most level editors; common first person shooter level design tools like Hammer or Radiant do not readily visualize dimensions or the player’s capabilities, and common industry level design practice places the onus on the level designer to memorize and measure the exact distances (or “metrics”) for how far the player can jump or move in the space.
The musician Martin Mull famously argued that "writing about music is like dancing about architecture." I argue that zero player level design is essentially a form of “dancing about architecture” because the game’s virtual architecture is performing and activating itself, channeled through the player-designer’s phenomenological experience of the game feel.
In level design we often argue that we must learn more from architecture as a field. When industry practitioners invoke this refrain, they usually mean the formal rigor of architectural drafting and planning processes.
However, level design already shares workflows and techniques with architectural visualization and CAD practices. The architecture we need in games is the architecture that understands itself as the intersection of social theory, economics, and art.
Level design is more than just a 3D blockout for a AAA shooter franchise. Level design is also the history of design trends in TrackMania or Super Mario Maker; level design is how casual designers wield casual creator tools and understand themselves as artists; level design is the rich study of how we experience and inhabit spaces. So yes, let’s learn more from architecture. See you on the dance floor.
critical level design primer on theme park run by the most powerful media conglomerate on Earth
Historically, industry level designers have looked to Disneyland and other theme parks as design inspirations. However, this conventional discourse rarely questions how Disneyland functions, and neglects the mountain of architectural criticism about Disneyland.
In hopes of educating the industry and elevating our discourse about theme park design, this article begins with our traditional arguments about how game developers think Disneyland works, and then transitions into contemporary real world architectural discourse about Disneyland.
linear single player castle level about teaching exploration patterns
Dark Souls is a popular third person fantasy action RPG by From Software, first released in 2011. It is the dominant template for the "soulslike" game genre, inspiring two direct sequels as well as broadly influencing all action games hereafter with its hardcore design approach and mechanics.
// comments begin with "//"
@EntityType EntitySettings() = EntityClassName : "In-Editor Help"
[
propertyKey(propertyType) : "In-Editor Name" : defaultValue : "In-Editor Help"
]@PointClass size(-16 -16 -32, 16 16 32) = monster_zombie : "A humanoid zombie with 100 health (default)."
[
health(integer) : "Health" : 100 : "Initial health points. Set to -1 to make the zombie start sleeping."
]@BaseClass = Monster
[
health(integer) : "Health" : 100 : "Initial health as a percentage."
]
@PointClass base(Monster) size(-16 -16 -32, 16 16 32) = monster_zombie : "Humanoid zombie"
[
// zombie will automatically inherit the health property from MonsterBase
]
@PointClass base(Monster) size(-32 -32 -64, 32 32 64) = monster_troll : "Big melee monster"
[
// troll will automatically inherit the health property from MonsterBase
]@SolidClass = func_door : "A simple sliding door"
[
// note that there is no defaultValue specified below; default is optional
targetname(string): "Name" : : "Named doors won't open automatically. Leave blank to open automatically."
speed(integer): "Move Speed" : 60 : "How fast the door opens / closes, in map units per second."
_shadow(choices): "Cast Shadows" : 1 : "Should the door block light? default: On" =
[
0 : "Off"
1 : "On"
2 : "Two Sided"
3 : "Shadows Only"
]
// in most level editors, flags type MUST be called "spawnflags"
spawnflags(flags) =
[
1 : "Starts Locked" : 0
2 : "Starts Open" : 0
]
// a flag follows this syntax:
// PowerOfTwoNumber : "Flag Label" : DefaultBoolValue
]// this path depends on base Game Path in Game Configuration - https://trenchbroom.github.io/manual/latest/#game_configuration
// as well as the Mod Configuration - https://trenchbroom.github.io/manual/latest/#map-setup
model("path/to/model.file")// "monster_ogre" inherits BaseClass "Monster", size 64x64x88, model path "progs/ogre.mdl"
@PointClass base(Monster) size(-32 -32 -24, 32 32 64) model("progs/ogre.mdl") = monster_ogre : "Ogre" []model({ "path" : MODEL, "skin" : SKIN, "frame": FRAME, "scale": SCALE })@PointClass size(-16 -16 -16, 16 16 16) model({ "path": model }) = prop_static : "Static Prop"
[
model(String) : "Model file path" : : "Set this to a 3D model file."
]// note: this is simplified from the actual FGD
@PointClass base(Monster) size(-16 -16 0, 16 16 72) model({ "path": "models/hgrunt.mdl", "frame": sequence }) = monster_human_grunt : "Human Grunt (camo)"
[
sequence(Choices) : "Animation Sequence (editor)" : 0 =
[
0 : "walk1"
1 : "run"
2 : "victorydance"
]
]// if entity property "big" is "true" then use a different model spec
model({{
big == "1" -> { "path": "zombie_big.mdl", "skin": 0, "frame": 13, "scale": 2 },
{ "path": "zombie.mdl" }
}})











Some weapons deal greater damage to shields than health. Other weapons deal enough damage to effectively bypass shields. In Halo 1, the default pistol is notoriously overpowered: two headshots break an opponent’s shield, a third headshot is an instant kill.


Sightlines are made of empty open space
Sightlines are situational tools that do not guarantee behavior
Leading line: fake imagined phenomenon where walls and linear set dressing seems to converge in the distance to subliminally direct the player where to go
No one navigates spaces like this
No one plays video games like this
Don't make levels for no one
Saliency
Sightlines are lines of empty space that the player can use to see into another area.
Vista
Approach
Shot composition is some kinda-bullshit theory that the player's view determines their behavior, rather than the player's actual understanding of the space.
Screenshots aren't levels; levels are spaces that players use
Leading lines are brain poison, don't use them
Don't confuse leading lines with sightlines, which are actually real

Ideally, do this after every phase: after layout, blockout, scripting, and art pass, etc.
This is where a lot of learning and collaboration happens, very common in workplace
Good for getting help on "wicked problems" -- problems that are so complex that you can't even describe the problem, much less solve it
Public playtest: someone else (ideally a "normal person" / member of the public, and not a developer) playtests the level.
Watching their behavior is more important than their feedback
Very important for catching hidden problems ("unknown unknowns")
But normies have a hard time playtesting blockouts, you'll likely have to art pass first
"Blind" playtest: a public playtest but with minimal guidance or prompting; pretend they are playing the level by themselves, alone, and see what they do
Public playtests: put your level in front of friends or family members, who are often socially / emotionally obligated to engage with your interests.
(e.g. "use WASD to move, but don't press Space, I haven't fixed the jump yet... oh and the game has spiders, are you OK with spiders?")
"the layout is final and we can't change it for budget reasons, so please only give me feedback on enemy placement and pickups"



Most importantly, you're given no feedback when you're in danger of failing by distance. So players learn to err on staying closer rather than staying back -- the exact limit is never shown.
East path: they walk east, then snake back to the statue.
Lastly, a readable cements the comparison. In it, Bafford apologizes for being late on payments to Ramirez, which means he's lower on the totem pole than Ramirez even though his place is bigger and fancier. In this way, Looking Glass uses reading text to complicate reading architecture -- whoa.
Pacing: each Disneyland attraction presents several clear thematic beats as you progress through it.
Wayfinding: Disneyland organizes each themed area around a central "weenie", a large highly visible landmark with long sightlines that draws visitors toward it. Walt Disney called them weenies because he argued these "sausages" (landmarks) attracted "dogs" (visitors).
Flow: to give the illusion of freedom and encourage movement variation, paths often branch inconsequentially and always lead the visitors back to a critical path.
: every attraction incorporates a consistent progression of architectural details, set dressing, and other environmental storytelling to immerse visitors as they wait in line for the ride.
Disneyland's Main Street is known mainly as an example of forced perspective, creating an illusion of height with less space. Buildings along Main Street are built at 3⁄4 scale on the first level, then 5⁄8 on the second story, and 1⁄2 scale on the third—reducing the scale by 1⁄8 each level up.
A more recent 2019 Full Indie Summit talk "Put A Castle In the Middle - Design Lessons from Disneyland and Zelda" by Shane Neville emphasizes similar points: weenies, environmental storytelling, wide paths for exploration. Similar to Rogers, Neville is also a big Disney fan and takes Walt Disney's words as gospel.
Now, their design points and assumptions aren't wrong. Many Disneyland visitors attend the park with the goal to glean lots of details and ride as many rides as possible, to be "guided" and explore a space.
However, as level designers, we know that our intent doesn't always translate to the reality of the player experience, and the design intent behind Disneyland should not be taken at face value either. Rogers and Neville make good points, but their passionate fan-love of Disneyland doesn't give the full picture.
What if Disneyland isn't the best place to emulate? What if, in fact, it has problems and flaws? Even if Disneyland is successful, what if it isn't applicable to video games?
And if Disney's park design team is so talented, how can we reconcile that with the embarrassing failures of California Adventure and Euro Disney -- what if Disneyland was just a fluke? If Disney can't even reliably launch new theme parks, are these theme park design principles truly useful?
The most famous piece of architectural criticism on Disneyland focuses on its larger social function within Southern California. Despite its marketing, Disneyland does not exist in a magical dimension completely detached from mundane human misery: it is located within Anaheim, California, a dense urbanized suburb in northern Orange County. We must understand Disneyland in relation to its surroundings.
In his article "You Have To Pay for the Public Life" (1966), postmodern architect Charles Moore begins with three observations:
Most European cities, as well as many US east coast cities, follow a Mediterranean model with a large public square at its center -- open land that we all agree to set aside for communal public use. We imbue this space with a public importance, a "monumentality" that compels us to flock to that space and walk around.
Californian cities don't have real urban centers. Downtown Los Angeles and San Francisco have relatively little foot traffic, least of all near their comparatively lifeless city halls. The closest thing to public monumental architecture in Los Angeles is the freeway interchange.
Californians drive cars everywhere and "float" with little attachment to an urban center, which merges with Hollywood's promise of freedom. Artifice, fantasy, and performance sit at the center of Southern Californian culture. We can become anything we want.
Moore then critiques public architecture across California, arguing that none of it actually anchors the public. But he also allows, in his own postmodern way, that maybe walking is overrated and driving everywhere is a helluva drug. He points to the Santa Barbara County Courthouse's grand arch and strangely tall walls -- a drive through film set, fake architecture that succeeds at its intent. Californian civic architecture, at its best, breaks free from the European tradition while feeling more Spanish than Spain.
However, Moore argues that Californians actually do want to walk around in an urban center, and the proof of that is Disneyland. He was the first architect to write about it seriously, just 10 years after it opened:
"Disneyland, it appears, is enormously important and successful just because it recreates all the chances to respond to a public environment, which Los Angeles particularly no longer has. It allows play-acting, both to be watched and to be participated in, in a public sphere. In as unlikely a place as could be conceived, just off the Santa Ana Freeway, a little over an hour from the Los Angeles City Hall, in an unchartable sea of suburbia, Disney has created a place, indeed a whole public world, full of sequential occurrences, of big and little drama, full of hierarchies of importance and excitement, with opportunities to respond at the speed of rocketing bobsleds (or rocketing rockets, for all that) or of horse-drawn streetcars. An American Main Street of about 1910 is the principal theme, against which play fairy-tale fantasies, frontier adventure situations, jungles, and the world of tomorrow. And all this diversity, with unerring sensitivity, is keyed to the kind of participation without embarrassment which apparently at this point in our history we crave. [...]
No raw edges spoil the picture at Disneyland; everything is as immaculate as in the musical comedy villages that Hollywood has provided for our viewing pleasure for the last three generations. Nice looking, handsomely costumed young people sweep away the gum wrappers almost before they fall to the spotless pavement. Everything works, the way it doesn’t seem to any more in the world outside.
As I write this, Berkeley, which was the proud recipient not long ago of a set of fountains in the middle of its main street, where interurbans once had run and cars since had Disneyland parked, has announced that the fountains are soon being turned off for good, since the chief public use developed for them so far has been to put detergent in them, and the city cannot afford constantly to clean the pipes. Life is not like that in Disneyland; it is much more real: fountains play, waterfalls splash, tiny bulbs light the trees at night, and everything is clean.
Moore argues that Main Street, USA is the most important part of Disneyland because it mimics what Americans want to believe about themselves, while fairy tale themed Fantasyland is the weakest part because it feels too much like make-believe. The political fantasy is more powerful than the fantastical fantasy.
Moore also reviewed various Disneyland rides in a follow-up book The City Observed: Los Angeles—A Guide to Its Architecture and Landscapes (1984). Here's what he said about The Haunted Mansion:
The Haunted Mansion is a badly flawed ride, if only for the smug and supercilious treatment it bestows on ghosts, just because they are dead. Even so, it is surely one of the most skillful, sophisticated and engrossing spatial sequences on the planet. It is useful to see the ride as a progression from outside the event, where the observer and the observed are at some distance, to the inside, where the observer, mind and body, has entered into the observed, so that it finally envelops him and even at the end makes an attempt to enter him.
More than fifty years later, Moore's central analysis still bears out.
Disneyland represents a civic promise that many Californians no longer expect from their local government. Disney can then charge middle class people for the privilege of roleplaying as if they didn't live in a failing city spiraling down in a crisis of declining public services and constant threat of drought. Clean sidewalks, functioning street fountains, and bright colors only feel remarkable when you live on a dirty sidewalk with broken fountains and peeling paint.
To escape misery, you just have to pay for a ticket. If you can afford it.
Disneyland forces us to ask, what is ethical and socially-responsible level design? Who lives in our levels and what type of "public life" do our maps make possible? If levels are Disneylands, then what's the video game equivalent of the surrounding suburb Anaheim?
Subsequent architecture critics have since largely labored in Moore's shadow, either amplifying the social critique to condemn Disneyland's craven capitalism, or emphasizing the nihilistic postmodern attitude to embrace Disneyland as a bold future alongside beacons like Las Vegas.
In 1997, the Canadian Center of Architecture ran an exhibition "The Architecture of Reassurance: Building the Disney Theme Parks" curated by Karal Ann Marling which sought a third way -- to trace the history of the park's development, and maybe even measure some of its influence on American urbanism:
Primarily, Walt was dissatisfied with Los Angeles and with other American cities of his era, the 1940s and 1950s. He was dissatisfied because the American city, it seemed to him, had become an utterly chaotic environment: cars rocketing here and there, unplanned suburbs, no sense of visual coherence, no sense of safety and reassurance. Walt Disney was also interested, however, in theming. Specifically, he was interested in what the American city had been in the past, the frontier West, the life of the small town as he remembered it at the turning of the century. He was interested finally, I think, in creating a place where people could feel safe and reassured.
We call this exhibition “The Architecture of Reassurance” because at every point in the design of Disney’s theme parks you feel safe, secure—you feel as though you know where you are in space.
Harvard Design Magazine writer Tom Vanderbilt outlined the exhibition's argument in "It’s a Mall World After All: Disney, Design, and the American Dream", again focusing on Main Street:
Although “Main Street” is just one attraction of many in the theme parks, it was closest to Disney’s heart—it was based not on a Disney product but on Disney’s personal history and memories. It is also the attraction that most embodies “the architecture of reassurance”: all those architectural and environmental touches, ranging from harmonious color schemes to the absence of garbage (a Main Street “newspaper” was discontinued early on because the discarded copies were thought to clutter to the street) to the famous 5/8 building scale (which “made the street a toy,” as Disney put it), which work together to offer an accessible landscape where Disney and visitors alike could feel instantly “at home.” More Frank Capra than Frank Lloyd Wright, Disney’s Main Street is a populist paradise designed to make vacationers feel comfortable, not awed by the achievements of would-be fountainheads. [...]
[...] “Main Street was aesthetically unthreatening,” writes Marling, “different, in that respect, from strip malls and real streets where every store battled with its neighbor in a disquieting cacophony of visual stimuli.” [...] Disney was so wedded to his Main Street memory that he first tried to populate the place with the kinds of retailers one finds in a small town, rather than with the trinket vendors and fast-food outlets typical of amusement parks. “Disneyland struggled to maintain a tenant list of shoe stores and other specialized apparel shops not because people came to the park to buy loafers and underwear but because the Main Street Walt remembered used to have them,” Marling writes. But apparently visitors’ fantasies did not include buying goods available at home (and more and more in shopping malls, not on Main Street), so eventually the stores sold just Disney merchandise. [...]
One of the lasting impressions from The Architecture of Reassurance is of how little is actually needed to create a sense of place—a realization apparently lost upon a generation of suburban builders. The comforting buildings of Disney’s Main Street disguise a ’50s strip-mall shell, Marling points out, while a structure like the Contemporary Hotel—a prefabricated hotel similar to the roadside chains—seemed progressive simply because a monorail passed through its lobby. The ingenious use of color, light, trompe l’oeil, and a bit of imagination go much further than do the much-hyped “utilidors,” monorails, and other grand infrastructural schemes in Disney’s parks. As in cities, the larger monuments of the park (Disney called them “wienies”) were located to orient and draw visitors—and most tourists, after all, behave much the same way in Disneyland as they do in cities: taking photos, buying things, seeking out attractions, orienting themselves by landmarks. Of course, in Walt’s parks, no maps were needed; the architecture was its own narrative. “We tell ourselves stories in order to live,” Joan Didion once wrote, and it comes as little surprise that the childhood stories lived out in real time and space in Disneyland should have endured in the adult minds of those who seek to recreate places whose true aspects were as dimly and fondly remembered as fairy tales.
For better or worse, Disneyland inspired a wave of small-town preservation and traditional urbanism across America with its safe nostalgic vision of early 1900s village life.
Disneyland's appeal to nostalgia at a small toy-like scale is powerful, promising safety and predictability for the player.
However, at this point we must ask ourselves -- will every player experience this wave of nostalgia? Does every Disneyland visitor fondly reminisce their idyllic suburban childhood -- or is that just for the visitors who experienced idyllic suburban childhoods?
Reassurance and nostalgia need older audiences. In this sense, Disneyland is for adults, not children.
As an eerie parallel, the US eldercare industry has also taken note of Main Street's powerful memory function.
There are now emerging "memory towns", fake villages built inside vacant warehouses, modeled after small 1950s US town squares. They seek to recreate walkable streets, a retro diner, and nostalgic music, all designed to stimulate the memories of Alzheimer's patients who grew up in small American towns like this.
But again, this type of IRL level design assumes a very specific type of player. What about the players who grew up in dense cities? What about the players who grew up outside of America?
Level designers have long been fascinated by Disneyland's overall hub structure, view composition, and open world crowd flow.
But real world architects and urban theorists focus mainly on Main Street and its powerful political symbolism.
Why don't architects care about Disneyland like level designers?
Landmarks and sightlines are not unique to Disneyland. Visit any IRL park, garden, or landscape, and you will witness similar, if not better, sightline management strategies.
50% of the function of Disneyland is to hide the long visitor queues for attractions. Is that what your level needs? Is your game about hundreds of people standing in line? If so, yes, study Disneyland.
From a cultural lens, this suggests the game industry (and its level designers) don't really understand the politics and communities we're invoking.
After all, every dead game world can be understood as a failed theme park, a Euro Disney scale disaster that misunderstood its audience. Why? Not enough weenies? Is that really what makes a theme park successful or interesting?
A capital-L capital-D Level Design analysis of Main Street would fail to locate its charm. If we were to blockout Main Street, we would capture 0% of its appeal.
The blockout would suggest that players enjoy walking along a linear strip mall of identical souvenir shops that all sell the same thing. Existing level design methodologies, centered around grayboxing mid-range combat encounters, have no explanatory power here. This explains why level designers have ignored Main Street -- we don't understand it.
Instead, perhaps we should learn more from Main Street as a model for building city hubs, NPC towns, and other safe zones that invite the player to dwell and hangout. Charles Moore and the Canadian Center for Architecture argue that, above all, this sense of public life / reassurance is a cultural and political appeal to a specific demographic. A social mood cultivated by people.
How do we make spaces feel populated and maintained? Only the janitors, retail workers, tour guides, hosts, and costumed mascots can tell you -- not the architect.
Maybe the true level design lesson of Disneyland is to recognize how hospitable game worlds depend less on level designers, and more on environment artists, level scripters, server engineers, moderators, and community managers.
Defunctland analyzes a variety of theme parks (not just Disneyland), usually from a historical perspective. Sometimes they focus on typologies across time (e.g. the history of the ferris wheel that begins with the Great Exhibition of 1851). Always feels pretty comprehensive with good coverage and presentation.
Poseidon Entertainment has more of an attraction-centric Disney / Universal fan lens, with somewhat technical deep dives into specific systems (e.g. critique of various Disneyland FastPass systems). Less of a zoomed out historical perspective, more of a zoomed in guest-facing analysis.
While most gamers focus on its punishing difficulty, they often forget the other half of the game -- Dark Souls is also an RPG where knowledge, exploration, and grinding can compensate for low combat skills or slow reflexes. Knowing where to find a helpful item, hidden checkpoint / NPC, or an easy farming route, can make boss fights much easier. Researching the game on a wiki is a valid playstyle, and maybe even the most common way to play Dark Souls today.
From a level design perspective, this is the core aspect we will focus on: how does Dark Souls manage and develop player knowledge?
After the tutorial (Undead Asylum) and hub (Firelink Shrine), an NPC tells the player to go ring a bell "up" in an church. A brief climb up into an aqueduct leads to the rooftops of Undead Burg, a dense ruined medieval castle city filled with zombie soldiers.
Undead Burg has two halves: Upper Undead Burg is the first "real" level of Dark Souls, setting expectations and core patterns for the rest of the game without anymore direct tutorial messages. Most players access Lower Undead Burg several hours afterward, so it's basically a separate level and it won't be the focus of this article.
Upper Undead Burg is a sequence of 3 areas that leads up to a boss battle (Taurus Demon). Each area has a main critical path as well as short optional side path(s) that loops back to the critical path.
Rooftop Ambushes
Fog Gate Joke
Breakable Merchant
Bonfire and Towers
(Note that these area names aren't official labels or community standard callouts.)
You begin at the top of the stairs (path 1 in diagram below) with a simple fight against two melee enemies at ground level. A short rise of stairs help highlight the critical path across the wood bridge (path 2) to the fog gate in the distance.
A third melee enemy can also walk across the bridge to help pull attention over, in case the big bright glowing fog gate wasn't enough. Although there's an alternate exit, it's hidden by some breakable barrels.
This little bridge does a lot:
The bridge is a chokepoint, forcing you to fight. If you try to run past the first two enemies, that third enemy may cut you off. Then you're trapped on the bridge, sandwiched between a mob. "Don't try to run past your problems," says the bridge, "or else your problems will only get worse. Face them head-on, one at a time! Don't cross this bridge until you get to it!"
The bridge helps hide an ambush, gently angling your approach away from a dark doorway on the left with a fourth enemy waiting in ambush. (see screenshot below, right)... It's the first of many ambushes. Never trust a bridge.
After defeating all the enemies, you stare at the fog gate and pause.
You remember the previous fog gate in the Undead Asylum tutorial level, like 15 minutes ago -- it led to the Asylum Demon boss that maybe killed you a few times. You don't feel ready for a big boss battle again so soon.
So you run away and "procrastinate" by exploring.
Looking down from the fog gate, it's possible to notice a glowing loot pickup breadcrumb below. Some breakable barrels reveal a hidden drop (path 3 in diagram below) down to the loot. From there it's also possible to see yet another glowing loot pickup on the bottom level.
There's only one way back up: drop all the way down, go through a house, and climb up a ladder to the top of the castle wall to get back to where you started (path 4).
But as soon as you begin, two zombies climb up from the ledge to ambush you.
After surviving the ambush, observant players might see four hanging zombies below -- a much bigger ambush in waiting.
(TODO: screenshots for path 4)
Here it's possible to foil the ambush by attacking these hanging enemies early. The level designer could've easily hidden these hanging ambushers on the other side, but instead they're left exposed to imply that ambushes are "fair" if you're smart enough.
When you jump down from the castle wall, you end up on path 1 again. These one-way drops / verticality enforce a one-way flow with no backtracking; each path is separate and distinct, and dropping to the stairs acts as a landmark. It's like the level designer is saying, "that was a fun little side trip, but seriously now, just go through the fucking fog gate." (Path 5)
Really, only path 1 -> 2 is the critical path. Why is most of this area "optional"?
Encourage exploration. Most of Dark Souls is "optional" - the player must learn to explore side areas. Here it's obvious that there's plenty to explore, but in later levels it's much less obvious.
Support failure / repeat runs. If you die before you reach the next bonfire checkpoint, you'll have to run this area again, but at least you can bypass optional areas you already explored.
Wayfinding via encounters. In the first fight, the third enemy begins at the back, which helps pull the player across the bridge to the next area (the fog gate). As in many combat games, enemies act as breadcrumbs.
All the other encounters act as ambush training, gradually escalating in a teach / test / twist pacing pattern:
Ambush outside fog gate - 1 enemy, semi-predictable with standing enemy in suspicious doorway
Ledge ambush at bottom - 2 enemies, not predictable, hidden enemies
Big ambush before ladder - 4 enemies, very predictable "hidden" enemies, can be foiled
So now there's nothing left to do except enter the fog gate. At this point, will a first-time player feel ready? Probably not. Which is the point.
Fog gates feel scary. You can't see what's on the other side, you can get trapped on the other side and can't run away. The fog gate for the Asylum Demon boss fight was 15-30 minutes ago.
The level has primed the player to expect ambushes everywhere. There was literally an ambush from the other doorway! If they had to endure several ambushes already, then what's awaiting them on the other side? Probably an even worse ambush.
The player has killed 10-20 enemies to reach this point, so they're holding 500-1000 souls and they've used maybe half of their healing potions. They'll feel like they have a lot to lose, with dwindling resources for a big fight ahead.
You steel your nerves and enter the fog gate... and there's no enemies. It's just an empty room with some stairs.
Was this a joke? Was the fog gate pointless? Where's the boss? Ha ha maybe this game isn't so hard after all!
As you confidently ascend the stairs to the sunlight, a giant dragon suddenly swoops down from nowhere, possibly killing you in one hit if you were rushing ahead too fast.
(TODO: screenshots for empty fog gate room + dragon attack)
It's a brilliant and cruel level design joke.
This whole beat builds up a first-time player's anxieties and expectations, seems to release anti-climactically... and then springs an unpredictable unfair instantaneous possible death from a powerful boss that can kill you in one hit, seemingly by accident. You don't even get the dignity of seeing the boss' name and health bar, instead it's just a teaser cutscene that can totally obliterate you. Unlike the silly 4-enemy failed ambush before, this is completely out of your control.
It's as if the level designer is toying with you. "I can destroy you in an instant," they say, "that is how little you matter." (It's OK if this feels erotic, because it is.)
(TODO: encounter screenshots)
This next area is also about exploration, except this time it's easy to miss the side route because the fight will pull you to the next area, and there's no fog gate to make you pause and explore.
It's also about breakables, featuring 3 different breakables beats.
After entering the fog gate, climbing up some stairs, and nearly getting killed by a dragon, you face the most challenging battle yet:
Two melee enemies rush out from behind breakable barricades. If you haven't already realized you can break jank-looking wood junk, then hopefully these two enemies teach you.
A third ranged enemy fires arrows from a tower in the back. The height is important; it elevates the archer apart from the other enemies, gives a good firing line, and leashes it to that spot. (A more difficult encounter would've let the archer maneuver and fire from different points.)
A fourth melee enemy is in the back, at the stairs, so it takes a while for them to walk over and join the fight.
This is a common encounter setup throughout the game: you have to juggle nearby enemies while getting sniped at, and if you take too long then more enemies will join.
(TODO: screenshots)
The long flat walkway serves an important combat purpose: you can backpedal to funnel the melee mob down the stairs, out of range of the archer. (A less generous approach would've been a one-way drop without any space to back away.)
But the fairly open arena floor also lets you play more aggressively. More experienced players can dance around to kettle the mob, while blocking / dodging in rhythm with the archer's (slow) fire rate.
Eventually the player will rush up the stairs to get that pesky archer (path 8), following the critical path to the bonfire up ahead.
After resting at the bonfire (which respawns all the enemies) and backtracking for a return visit, this encounter is much easier. You can kill the archer immediately and fight the one melee enemy alone at the stairs, sometimes without aggroing either of the enemies facing the barricades.
From the archer's tower you can see two spearmen on the other roof. The stairs leading down are clumsily hidden by some breakable crates
break through some crates, and go downstairs inside (path 9)
Here the merchant sells a variety of basic weapons and several consumables to make the upcoming optional midboss and/or main boss much easier. The player can also change their playstyle, resupply, or buy a key to unlock a shortcut to the boss too.
Few games would have the gall to introduce a safe hub town area (Firelink Shrine) and then hide a much more helpful NPC halfway through a dungeon, but Dark Souls does so repeatedly. And while it may seem weird, obscure, and hostile, to hide a crucial early NPC like this, it actually provides much more convenient access when respawning from the nearby bonfire.
It's an important level design lesson: you must design for the actual game you're making. Because of Dark Souls' mechanics and aesthetics, this NPC placement makes more sense than forcing players to backtrack all the way to a central town area.
path 10
get ambushed by a melee enemy hiding behind some breakables inside
fight some weak melee enemies in a line
just like the previous loop back with path 4: climb a ladder, jump down from the roof, to feed directly back into the starting stairwell
(this pattern later gets repeated for a third time in the Taurus Demon boss fight, while also evoking the Asylum Demon plunge tutorial balcony)
TODO: writeup for area 3
Upper Undead Burg introduces important level design patterns / strategies / skills for the player:
Rooftops lead the player on a sequence of gradually escalating ambushes. Each side route is one way and feeds back toward the fog gate. When the player finally does confront the scary fog gate, it feels like a joke -- there's no enemies or boss battle, but still a surprise danger.
Merchant area tests whether the player is truly exploring, hiding the first merchant of the game (!) in a side area beneath some breakables. Hopefully the player remembers how the rooftops' lower area was accessible.
Bonfire and Towers are a sequence of bigger complex fights with ranged attackers pressuring the player from towers. The player must manage mobs and deal with threats in an optimal order. It's also the main route from the bonfire to the boss, with an unlockable shortcut if the player explored (found the merchant and bought the key)
We try to use industry-specific terminology as used by working level designers, but we always try to define these concepts with simple plain straightforward language. When the game industry terminology is just really weak or undeveloped, we make a note of it, and usually emphasize a more robust concept from architecture or neighboring design fields instead.
demonstrate what conventional 3D level design practice looks like
unpack "design" in a broad conceptual sense with many contexts, avoid one-size-fits-all tips that make big assumptions, try to keep some nuance
unpack "development" as a creative problem solving process that takes time, benefits from planning, has ups and downs
emphasize a functional playtested level instead of beautiful environment art
We write for a late high school / undergraduate university reading level, and assume a "serious" long term study of design and development. There are occasional curse words and Western cultural allusions. Our target tone is "cool professor." It is probably too much for early teens / summer camp format.
Note that this book emphasizes theory and process. As the instructor, you will have to provide the technical instruction for your students. We have Opinions about the best Tools to teach:
To teach level design as an industry specialization, then use Quake or Doom.
students won't have to re-invent player controllers, combat, AI, graphics etc.
Quake and Doom force a focus on encounter design and step-back from environment art, students' most common weakness today
Quake and Doom communities maintain solid free open source MacOS-compatible tools
if you want to mod something newer, see suggestions on the page
To teach level design workflows as part of a generalist game dev education, then you can probably get by with Unity / Unreal / Godot.
modern game engines are much more user-friendly than retro shooter engines
great for students who don't aim to become AAA combat designers
Each Process page should be enough for a 60 minute lecture and discussion once a week.
Pair each lecture with a group "let's play" / play a game together as a class, to apply the lecture concepts to an actual level.
Sample breakdown for a 15 week level design course, focused on finishing one long term project:
Pre-production: 1 week. Emphasize setting experience design goals / articulating design constraints.
Layout: 2 weeks. No one can visualize flow in a floor plan without practice, visual communication is obviously a skill that needs to be developed over time. But layouts are still a key part of level design thinking and practice. So for a big final project spend at least two weeks to require at least two passes of iterations on the layout, and have students practice presenting their layouts to their peers.
/ : 5+ weeks. Learning how to use a 3D tool will take at least 2 weeks, if not much longer. Spend 1+ weeks on 3D modeling and constructing common shapes, e.g. ramps, stairs, doorways.
Every 2 weeks, do a class while also connecting back to key theory concepts.
A solid blockout with 2-3 playtested iterations is a good target for a midterm project.
Production: 5+ weeks. We usually spend the second half of the semester finishing the midterm blockouts into more finished levels. This focus will depend on your class / students' focus:
For a AAA design focus, do more playtesting and
For a technical audience, do more and
Presentations and demos: 1-2 weeks. Many students loathe presentations, but it sets expectations for how workplaces operate: meetings with peers and supervisors.
This is also a good time for -- students should document and compare each iteration, from layout to blockout to art pass.
Culture articles provide useful background and historical context. Studies are best accompanied by group live plays and/or students playing the actual level in question, before reading and debating the design analysis as presented in this book.
These two sections complement each other. The average teen has played very few games from before they were born. But you can't quite understand the history of the level designer without having played Doom, Quake, Half-Life, or Unreal Tournament..
An industrial level design theory class could challenge students to present their own critical site studies. An academic research writing class could task students with writing their own design histories. What is the history of the walking simulator, the explosive barrel, or of trees in video games? (example: Stephen Murphy's "Frogs in Videogames.")
The Projects section has ready-made project ideas and in-class lab activities for you to use. Discussion and evaluation phases are built into each assignment, along with suggested time lengths for each phase.
Show instructions on the board or provide a paper printout. If you just link students to the projects page on this website, then they will likely get distracted or lose the browser tab.
Student gives short informal presentation of their project, summarize intent and method
Instructor + fellow students give reactions and feedback
"Crits" can be constructive and enlightening, or humiliating and pointless. Instructors must model what good critique looks like -- specific and open-minded, pushing questions rather than cruel opinions. Before any crit session, discuss with students what makes for helpful feedback:
Describe specific core strengths
unhelpful feedback: "This level looks fun."
more helpful: "This level's fantasy about demolishing a student loan office really appealed to me."
Describe specific problems that weaken those core strengths
unhelpful: "The level felt broken and bad, which is less fun."
more helpful: "The level is about canceling all student loan debt, but I had trouble understanding when or how the debt cancellation happened. Which parts of the level show the debt being destroyed? Did I miss those parts?..."
Use first person "i statements", refer to your specific reaction and play session
unhelpful: "No one will know where to go in the level."
more helpful: "I didn't know where to go in the level... I thought the debt monster would be in the basement, but instead I found it in the CEO bathroom..." (why?)
Avoid second person "you statements", avoid accusing / attacking
unhelpful: "You made a confusing level, instead you should do (this) and (that)."
more helpful: "The level confused me. Maybe it could do (this) or (that)."
In architecture education, a pin-up is a critique where a student pins their architectural drawings to a wall and "critics" (instructors, guests, students) talk with the designer about their reasoning.
Example of a quick weekly pin-up design exercise:
prompt with a theme, design constraint, or genre (example: "prison break")
individually, sketch small simple map layout on paper (5-15 minutes)
shorter times discourage detailed drawings and overly complicated concepts
in groups of 4, pin-up drawings and present, with 3-5 minutes of discussion after each
at best, a pin-up leaves the student more excited about evolving their design
This book was written by practicing level designers and academics, so we have a few words of advice on "best practices" for teaching level design.
What type of level design will you teach? Most level design courses must focus on either visual space planning aspects as a generalist architecture approach, or on designing challenges and puzzles with frequent playtesting and iteration.
For a generalist survey class, structure your class into different "units" where you focus on specific methods from month to month. Then for a final project, allow students to specialize in whichever unit(s) they preferred, to explore those topics more deeply on their own or in groups.
Design can happen on a whiteboard, on paper, in conversation, or in presentations. In a large commercial studio, lead game designers often do very little hands-on work in a editor tool.
In games education and STEM-related programs, students often neglect their underdeveloped "soft" skills and fundamentals. But it's impossible to be a good designer if you can't communicate. When students neglect soft skills, their career will collapse as soon as they have to talk to someone.
Plans rarely survive intact. Ask students, do you think your level meets your design goals? Is there a better way to accomplish that? Do you want to adjust your design goals? What will you do differently on the next project? Emphasize development as an ongoing process where mistakes and problems will definitely happen.
Make every students use the same tools at first, before giving them the choice to branch out.
So much of level design requires developing a shared design language, and if you fragment your students' reference points, it will be more difficult for them to draw those connections and comparisons.
Use internal classroom social media channels for sharing work and progress. If you have a class Slack or Discord, create a channel called "#screenshots" and task students to submit a screenshot every week as part of their homework. Students need to see each others' work so they can learn from each other.
Some students seek a future career in level design. However, the game industry usually has low demand for junior level designers for prestige AAA 3D action games. Instead, encourage students to follow smaller studios and indie teams, which may not carry blockbuster prestige, but still offer mentorship and growth.
"Reorientating Level Design Education" (2020) by Alexander Muscat, RMIT. A short talk about core problems in teaching level design, and Muscat's approach to a level design curriculum for typical students in a game design university course -- generalist designer-developers who have varied experience and interest in game engines and level design.












How to plan a game level with mechanics, experience goals, and pillars
designing physical conflict between player(s) and/or NPCs
Combat design is about making game systems for physical conflict between player(s) and often AI-controlled enemies too.
In level design, we generally assume this is combat for a first person shooter or other real-time 3D action game. This book will also make that assumption.
Note that competitive player vs. player (PvP) functions very differently from single player / cooperative player vs. enemy (PvE) combat. PvP usually implies a fair chance to win for all combatants. In contrast, PvE provides delayed but guaranteed victory. These are two very different promises to make to players, and so the level design is different too.
prototyping different types of NPCs with specific behaviors, strengths, and weaknesses
Enemy design is about prototyping different types of hostile NPCs with specific behaviors, strengths, and weaknesses.
Enemy design is often a complex collaboration between AI designers, programmers, character artists, animators, sound designers, etc. Which is far outside the scope of this level design book. Nonetheless, level designers must be able to conceptualize and theorize about enemy design, even if they're not the developers tasked with implementing the enemies.
For some enemy design examples, see and
Diagnosing a level's performance problems and tuning it to run more smoothly
Is the game running very slowly when you try to play your level? Are your players or playtesters complaining about lag, low framerate, or long load times? If so, then maybe it's time to optimize your level to try to make it run more efficiently.
Optimization is the process of diagnosing problems and streamlining performance across a game or level. It is often very complicated and specific, and is far out of the scope of this level design book. Much like mapping, the only real way to get better at optimizing is to optimize a lot of games, and learn from your experience.






















but students will have to prototype their own mechanics, which may leave very little time for actual level design
After the first two weeks focus on 3D construction, gradually ease non-programmers into visual scripting. Spend three weeks teaching triggers / collectibles, interactable buttons, and then doors.
What are you making?
What will the player be able to do? (Mechanics, Experience Goals, Pacing)
Which parts are most important? (Pillars)
How are you going to make this?
How did other people solve similar problems? (Research)
How much time do you need? Is this feasible? (Scope)
Your answers to these questions will change throughout the project, and that's OK.
Planning is useful but it's not magic; you won't know what you're making until you actually make it.
Level planning can take many forms. Like for a small solo hobby project, planning is less important, you can write or sketch a simple basic plan and then enjoy the thrill of improvisation and discovery. But for a larger group project, planning helps everyone know what to do / what everyone needs from each other.
Very basic questions, enough for a quick solo jam project:
But really, you should be able to answer these other basic questions too:
For 3+ people or a 3+ months project, then more planning will help:
In the video below, industry level designer Steve Lee talks about his process -- before drawing any layouts or opening the editor tool, he first opens a text window and writes an outline for what should happen in the level. This is the core of planning: think about the main ideas and talk about it.
A game mechanic is any activity, system, or tactic repeated in your game, basically any action a player routinely performs or uses. Core mechanics are the most basic frequent and fundamental actions / systems of a game, while less frequent activities can be called secondary mechanics.
Some examples of how we talk about game mechanics:
Super Mario 64's core mechanics are running and jumping to reach the exit. Some Mario 64 levels support secondary mechanics like wall kicks for secret shortcuts.
Doom's core mechanics involve running and shooting, with little or no jumping. Sometimes players trick monsters into shooting each other, a secondary mechanic called in-fighting.
Thief: The Dark Project is a stealth game about avoiding enemies, with a core mechanic where loud fast footsteps attract guards. In contrast to Mario and Doom, Thief discourages fast movement, and running is a secondary mechanic.
Mario 64, Doom, and Thief are all similar 3D action games about reaching the exit without dying. However these games require very different approaches to level design. Mario platforming would make for an impossible Doom level, and Doom-style hordes of monsters would make for a brutally unfair Thief level.
Do not design for the genre, do not sleepwalk into familiar patterns. Instead, design for the actual game that exists! If you're modding a game, play it for at least a couple hours, including other modders' work. Watch YouTube gameplay footage, pay attention to how other players use mechanics and systems.
It's hard to build levels without knowing the mechanics. Both mechanics and levels depend on each other, one cannot exist without the other. You can't evaluate a mechanic without testing in a level, but you also can't quite evaluate a level without finalized mechanics.
If you change your mechanics, then you'll end up with a lot of wasted work and obsolete levels that relied on discarded mechanics. But if you don't build enough test levels to measure the mechanics' potential, then you might end up with a dud mechanic that isn't interesting enough beyond the first level.
You might have to throwaway or redo levels, maybe even multiple times! It's OK. Do not think of this as wasted time or work. Instead, think of each discarded version as valuable research. This is why we call it game development -- development is a process that takes time. It will take time to figure out what makes for a good level and a good game.
As part of the planning process, build playground blockout test maps: big boxy courtyard levels filled with varied floors, room shapes, and game objects.
These simple playground-style debug levels are vital for testing game mechanics and general feel for the game. It is especially essential if you are prototyping your own character controller and player physics, to make sure the player can comfortably move around in the game.
For more on building test maps for internal use, see Metrics.
Modern game developers today rarely use big "GDDs" (game design documents) nor big design bibles; no one's going to read all that, and docs quickly get outdated as you evolve the game. Instead, create a noun-verb diagram to visually track how game systems and mechanics interact.
"[Noun-verb diagrams are] useful for finding holes and questioning assumptions we were making about player motivations, and is super handy for pitching at a glance, people can understand the game so much faster with this than a bunch of bloated copy.
[...] This diagram is not supposed to chart all the things that are possible, but the things you feel are important."
-- Leena van Deventer, "Noun-verb diagrams"
An experience goal is some kind of idea, feeling, or activity for the player. To conceptualize goals, try starting with the phrase, "In this level, the player should [learn/feel/do]..."
In this level, the player should... ... learn how to use the double jump ability. (Tutorial)
In this level, the player should... ... feel vulnerable, then reach the safehouse and feel relief. (Emotion)
In this level, the player should... ... dodge deadly traps and unlock a shortcut at the end. (Activity)
In this level, the player should... ... feel like they're escaping a medieval prison. (Fantasy)
BE SPECIFIC.
Experience goals don't have to be complicated or profound, but a clear and specific experience goal helps you decide what to build and what is unnecessary.
"The player should have fun" is a vague goal that can't drive design decisions. What type of fun? How much fun? Be more specific.
Or if the goal is to "make the player feel fear," then what type of fear? There's body horror, existential horror, fear of failure, fear of rejection, mid-life crisis, etc.
THINK FROM THE PLAYER'S PERSPECTIVE.
Avoid abstract experience goals. Imagine the player's perspective.
For example, "the player should enjoy non-linearity" focuses on an abstract structure that isn't relevant to the average player, so it isn't a useful experience goal. What do you actually mean by enjoyment or non-linearity?
Imagine talking after a playtest. What do you hope a player says about your level? You would feel insulted if they said, "wow that was really... um... non-linear..."
Levels rarely have just one experience design goal. Even a tutorial level benefits from storytelling and mood. These secondary goals can help guide your design decisions.
For example, "fight multiple enemies at once" is an encounter design goal for a level. But so much is still undefined. Where is this level set? What type of enemies?
Try adding a pacing goal: "feel overwhelmed at first" ... So maybe the fight should start in a small space with enemies almost surrounding the player.
Add a fantasy / storytelling goal: "feel like defending a campsite from zombies" ... So maybe we should research types of campsites (military? hiker? winter?) to plan the arena. Campsites have campfires, maybe there's a fire weapon... etc.
The most important experience goals across your entire project are pillars -- the most vital ideas that structurally support and justify your entire design. Design pillars help teams maintain a cohesive vision for the project, and resist "feature creep" work tasks that don't actually support your main goals.
Pillars are a design planning tool to help you conceptualize short-term experience goals for each level or area. Each of your level's smaller experience goals and small gameplay beats should contribute to your pillars somehow, and that culminates in the grander arc of your entire game's experience.
To help internalize these big design goals, title each pillar with a pithy phrase or word. For example, the God of War (2018) internal design pillars at Sony Santa Monica were Combat, Father/Son and Exploration (see below).
Because this was a big budget AAA game, their experience goals also involved production value targets like "high optical [motion capture] fidelity."
You might think this character animation goal has little to do with level design, but imagine a level that makes the mocap character animation look bad -- who has to change their work now, the level designer or the animator?
Because the entire team already agreed that mocap animation should have priority as a pillar, perhaps that prior consensus means the level designer should change their level to fit the existing animation.
In this way, pillars help us define what is important about our projects, and thus make more consistent and coherent decisions during development.
Psychonauts 2 is a 3D platformer about exploring peoples' brains. In November 2016, Double Fine Studios made a pre-production with a vertical slice style "art test" prototype -- 5 years before the game's release in August 2021.
As depicted in their official dev documentary video series "PsychOdyssey" episode 8, the pre-production team focused on building out a core movement set, art style, and level design in Unreal Engine 4. While much of the core platforming mechanics carried over from the original Psychonauts 1, the team wanted to experiment with new ways the player's various psychic powers could interact with the platforming gameplay -- resulting in a telekinesis-with-movable-tightrope prototype mechanic that never appeared in the final game.
By the end of the dev cycle, there's still a lot of uncertainty and unanswered questions. Will this game be good? No one knows. The journey is just beginning.
Dishonored is a first person stealth action RPG series about exploring complex places. In Dishonored 2, there is a "Clockwork Mansion" level where the layout dynamically changes.
Arkane Studios designer Dana Nightingale built a proof of concept pre-production prototype: (Twitter thread)
"I created this proof of concept early in 2013, long before the map was greenlit to be included in the game, basically to say "yes this could be amazing" and "yes I should work on it." It did both, but it would still be over a year before the map was officially OK'd.
But sure, I could make a bunch of blocks animate however I wanted. What is possible using real level geometry? That's why I made this prototype. A bit less wild? Yes. But still clearly do-able.
That prototype introduced the idea of rooms that were moved around like cargo containers and slotted into place, making the map's layout totally dynamic, but without transforming rooms. I am glad we didn't go in that direction.
[...]
After nearly a year of working on other prototypes it was time to revisit the Clockwork Mansion and finally get it validated. I made a new version with fewer twisty rooms, and more emphasis on the "behind the scenes" areas..."
To give you a sense of time scales here: this level spent 7 months in pre-production, then entered final layout / blockout about 18 months later.
Mechanics are the repeated systems and interactions of a game.
Core mechanics are the most frequent, while secondary mechanics add occasional variety and finesse for more experienced players.
Experience goals are the player-facing design goals for your levels
Pillars are the main design goals for your entire game. What do you want the player to learn, feel, or understand?
How much planning do you need? It depends.
Small casual projects will be OK with small (or nonexistent) plans, big long-term projects may require a huge internal wiki.
Pre-production planning helps developers coordinate and trust each other.
Plans help you make things, but plans always change. Even after preproduction, while working in the middle of the project, you will almost always adjust your plans and improvise a redesign. That is OK.
Or you might move on to the phase of level design.
"A Playful Production Process" (2021) by Richard Lemarchand is an approachable textbook that introduces game production methods, ideal for late high school / university students.
is a formalized process for film and music industries.
If in fact, you do not choose violence, then skip ahead to learning about Layout.
When making a combat game, you have two options:
Mod an existing combat game.
Build your own combat gameplay from scratch.
You cannot make good combat levels without good combat systems. But developing this core combat toolkit requires a lot of code, art, animation, audio, and tuning.
This is a complex topic that is outside the scope of a level design book. Asking "how do I make good combat?" is like asking "how do I make a good game?" It's a big question.
This is why we strongly suggest modding: that way, you can reuse a game's already-proven core combat systems without having to build your own.
For a list of recommended combat games to mod and study, see Tools.
That said, even if you do mod an existing combat game, you still have to be able to theorize how it works. All single player and multiplayer combat games have some form of these core elements:
Combat mechanics
Weapon design
Economy
In a big commercial studio with specialized development roles, none of those core combat elements would be the level designer's responsibility. However, a level designer cannot make levels without understanding them.
Combat mechanics are the player's repeated actions / skills / weapons used to fight enemies. Some common combat mechanics:
Move away from danger, control territory
Aim at specific enemy types / weak points
Timing an attack for a tell / telegraph (opportunity)
Chain attacks into combos, combine actions or weapons
Block an enemy attack; parry / counter / evade at the right time
Use traps like explosive barrels, water, lava, cliffs, etc
Many games provide the player with multiple weapons to use. Weapon design is about conceptualizing, implementing, and balancing this arsenal. Some aspects to consider:
Weapon feel and fantasy (e.g. big slow gun vs. sneaky knife vs. loud chainsaw)
Stats like varied damage, range, rate of fire, ammo supply
For guns: varied spread, recoil, sights, penetration, magazine size, reload speed
Situational awareness to pick the most appropriate / effective weapon
Economy is a general game design term for the overall system of costs / benefits / rewards that the player must consider throughout the game. The player's access to resources affects which mechanics and weapons they use and when:
Weapon economy: ammo, time (DPS), arsenal / loadout
example: the player has 1 rocket left, so they save it until they fight a strong enemy that is weak to rockets
example: the player has only 15 seconds of oxygen underwater, so they need a high DPS weapon to fight an underwater enemy
Player state: short term economy like health, inventory, consumables
example: the player has 99% health, so they will avoid a health item that adds +25% health, because that would "waste" 24% of the pickup
Player progression: long term economy like experience points, perks, upgrades, gear
example: the player has 99% health, but they have an upgrade that gives +100% damage if they are at full health, so they decide to pickup a +25% health item anyway because the damage bonus is worth more than the wasted healing
"We tried to model our expectations for gear acquisition and progression in a way we felt would be healthy on paper, and then we constantly playtested and iterated on things to try to get the reality of the playtest to match our models. [Here's a spreadsheet (pictured above) with] planned power level progression, of different gear slots at different points in the game. Each row is a different level in the game chronologically. Each column is a different piece of gear, and these are the levels that we expected you to get that gear to at that point in the game. We would constantly cross reference what we thought should be happening with what was actually happening in playtests...
One trick we used is to [make upgrading existing gear more expensive than buying new gear] so you had a temporary incentive to find new gear [...] Or similarly, reward level 5 armor during exploration content when we knew the resources to upgrade from 4 to 5 weren't available yet, so we were guaranteeing that armor would be exciting and enticing for a short time."
-- Rob Meyer, "Reckoning With Gate: Combat At the Scale of Ragnarok" (2023) (YouTube)
Here we summarize three major approaches to combat:
Classic combat (Doom, Quake) focuses on movement
Soulslikes (Dark Souls, Bloodborne, Elden Ring) require dodging
Fights are usually close range and continuous.
Military realism (Counter-Strike, Call of Duty) is about aiming
Battle royale (Fortnite, PUBG, Apex Legends) adds more economy
Fights are often long range and erratic.
Modern combat (Halo, Team Fortress 2, Overwatch) emphasizes damage
Cover shooters (Gears of War, Uncharted) add positioning
Fights are usually mid range and rhythmic.
Note: no game fits neatly into a category. These are just examples / just one way to think about these games.
Combat in Doom (1993) features a strong built-in auto-aim assist. The player cannot even look up or down vertically. Doom is clearly not about aiming. Instead, Doom's high speeds enable levels with large enemy counts, encounter variation, and huge sprawling level layouts.
"[The player] runs at about 50 scale miles per hour – nonsensically fast by modern standards. Most of Doom’s enemies don’t have instant-hit projectile attacks, and most of the ones that do are quite weak – the lowly trooper and sergeant. Every other enemy projectile takes time to reach its target, and would look comical in a more realistic visual presentation.
So because the player moves so quickly in Doom, and because most enemy attacks are dodgeable, the player can avoid a significant amount of damage simply by moving. [...] This frees up Doom’s encounters to feature huge numbers of enemies, to vary scenarios by mixing in different proportions of threats, and to have huge, sprawling, often non-linear spaces that the player can traverse easily."
--JP LeBreton, Coelacanth: Lessons from Doom
Dark Souls-like action RPG games formalize dodging mechanics via "dodge rolls" with "invincibility frames" (I-frames) providing complete damage negation with good timing. Learning how to read enemy moves, and repositioning / dodging to avoid damage, is often more important than using the best weapon or having the best equipment.
The original Counter-Strike (1999) popularized competitive team-based multiplayer in a realistic military style. Weapons are highly lethal and fights end within a few seconds. Success depends on fast reaction speed and aiming in the right place at the right time, while clearing firing angles and sightlines -- but flashbangs and smoke grenades can deny visibility. Varied gun accuracy, recoil, and bullet penetration mechanics supplement this focus on looking and aiming.
The more recent battle royale genre began as a mod for a realistic military sim shooter series called ARMA, and much of its approach carried over to PUBG: Battlegrounds, the first commercially successful battle royale shooter. This persists even in less militaristic battle royales like Fortnite or Apex, where it is still very common for new players to die suddenly to an unseen sniper a hundred meters away. However, this all depends on a player's ability to accumulate supplies and guns, adding an inventory management aspect and RPG-like progression to each round.
In Halo: Combat Evolved (2001), the player moves slowly with a very floaty jump, so there's not much dodging here. But there also isn't much aiming either; the default pistol is notoriously one of the best weapons in the game, allowing cheap frequent mid-range / long range headshots with a subtle auto-aim "magnetism" well-suited for casual console play. Instead of movement or aiming, Halo is about managing damage:
"In almost every modern FPS, the player moves fairly slowly and a huge proportion of enemies are equipped with instant hit attacks – pistols, machine guns, sniper rifles. This usually puts the player in the role of “damage sponge” – they’re intended to soak up a certain amount of damage from mostly unavoidable enemy attacks, then seek cover and heal up. Halo’s recharging shield makes this mechanic quite explicit – by default, you’re exposed to damage and will die, while seeking cover halts that and completes the basic cycle of any combat."
-- JP LeBreton, Coelacanth: Lessons From Doom
Multiplayer team shooters like Team Fortress 2 strongly emphasize healing, to the extent that every team always needs a healer. Overwatch builds on Halo's regenerating shield mechanic. Cover shooters like Gears of War or Uncharted feature regenerating health, but tie this rhythm to hiding behind objects. Modern combat is about getting shot at, alternating periods of risk and rest.
blockout a test arena
open area and/or 3 lane
place some enemies
playtest and repeat
how to know when combat is "good enough"?
Once you've established the core combat systems, either by playing the game you're modding or by building your own combat from scratch, then you are ready to start designing more specific combat scenarios:
Enemy design is about defining different hostile NPC types.
Ideally, each type has distinct behaviors, strengths, and weaknesses.
Without a roster of varied enemies, fights will feel repetitive.
are structured battles against NPCs.
Open-ended combat puzzles; player must usually improvise a solution
Implementation usually involves some .
is about building spaces to fight from.
Where is safe, and where is high risk? Where can players fight or recover?
Cover varies with mechanics / weapons. You need core combat design first.
is the fairness of the player's options, usually in PvP.
Where can the player go, what territory can they control? How will the player know?
A balanced level helps players trust the and invest in the outcome.
We recommend approaching combat in the order listed above. Each aspect depends on the previous one. To build encounters, you need enemy design first. To coordinate cover, you need an idea of how the encounter should play out. To balance a map, you need to know which cover patterns make sense.
Combat design is about designing systems for physical conflict.
To make combat levels, you first need a combat game. But making an entire game is hard, and this is just a level design book. Modding a game is easier.
Common combat systems include:
Combat mechanics like aiming, dodging, timing, etc.
Weapon design, a varied set of interesting tools to use
Economy, systems of costs / benefits for weapons, inventory, and progression
Some combat examples:
Classic combat & soulslikes emphasizes speed and dodging fire
Military realism & battle royales make guns and aiming more important
To build a combat game, (TODO)
Read more about key design concepts for combat level design:
Move on to the phase.
"Reckoning With Fate: Combat At The Scale of Ragnarok" (2023) (via YouTube) is the most comprehensive talk on modern AAA combat design from Rob Meyer, lead combat designer on God of War: Ragnarok (2022). Meyer gives specific examples from his work and details the responsibilities of a combat designer at Sony Santa Monica.
Imagine we're making an action game. Here are some basic roles to fill on our enemy roster, the collection of enemy types and the combat roles they fulfill.
Grunt
Close range melee attack player straightforward, easy to pull
Squad
Attack from mid-range / long range, ideally take turns as a group
Leader
High survivability, buffs nearby allies somehow
Tank
High survivability, but slower and larger (easy to hit or avoid)
Swarm
Small fast attacker with low health but high close-range damage
A finished working enemy NPC often requires designers, artists, and programmers to collaborate. It can be a lot of work, and it's far outside the scope of this level design book.
Here we will focus on the combat designer / level designer's responsibility to advocate for gameplay features and readability:
Unique silhouette so players can discern enemy type at mid-range (~10+ meters away).
Design details and animations that telegraph enemy state, intent, and strengths / weaknesses.
example: in Skyrim, the giant feels big and slow, you must out-maneuver it and wear it down
It can be useful to organize the enemy roster with a spreadsheet / matrix:
Grunt
Squad
This can help balance the roster or point to gaps, but don't let the spreadsheet trap you into just one way of thinking. For example, in the matrix above:
Only 1 Fast enemy? Maybe Leader should be Fast too, to feel more different vs Squad?
There is no High-DPS Mid-Range enemy. Should there be? Would that be fun or useful?
Is this matrix design too simple? Do we need a Size column, a Behavior column? etc.
To analyze the enemy roster in an existing game: play many levels, and then make your own spreadsheet with your own columns.
What kind of terrain / placement works best for each enemy type?
Which enemy types work well together? Why?
Which enemy combinations are present in which levels?
Some general industry consensus / advice on designing enemy types and rosters:
Diversity. Each type should feel different to fight, avoid similar enemies.
Hierarchy. Some types are weaker, some are stronger. Make this ranking clear.
Longevity. Types should not become obsolete. A weak early-game enemy should still be interesting later on, or a mid boss should transition to become a regular type, etc.
Emergence. Different combinations of enemy types should create different situations. The same tactics, used against each type in isolation, should be less effective.
Intelligence. Give the illusion of intelligence and different emotional states (afraid, angry, etc.)
"Smart" enemies should have high survivability / health, or else they'll die before they can show off how smart they are.
Consistency. Feel predictable, with clear patterns for the player to recognize and exploit.
For most 3D action games, each enemy design needs to answer these questions, at least:
Health: how strong is this enemy, how long can it usually survive?
Speed: how fast does this enemy move? Slower or faster than the player?
Damage: how dangerous are the enemy's attacks?
Range / Behavior: does the enemy attack at close range or mid range / long range?
For an initial design, specific numbers are less important because these numbers will likely change drastically. It is enough to estimate "10% / 50% / 100%" or "low / medium / high", and tune the specific numbers later when you actually begin prototyping and playtesting.
How many resources must the player spend to disable this enemy?
Variations on health: armor / shields, stun / stagger
For the 3D action game Skylanders: Spyro's Adventure, Activision-Blizzard designer Mike Stout talks about how the design team conceptualized 4 main archetypes ("Near, Far, Swarmer, Heavy") as well as their behaviors. He argues melee enemies by themselves are usually pretty boring, and ranged enemies are important for level design:
"Far Enemies are super simple, they're just dudes that shoot at you. But they're very interesting because environment matters [here]. When you have Near Enemies, since they can't attack you from far away, your environment doesn't matter at all: you got them up on a ledge, behind cover -- it's all the same as fighting on a flat plane. So adding Far Enemies to a setup, and mixing them with other types, means all of a sudden your level design is going to start to matter."
- Mike Stout, GDC 2012: "Reaching Into the Toy-Chest: A Look into Skylanders: Spyro's Adventure's Design"
Variations on range:
Projectile design (speed, movement pattern)
Size (a small distant thing is harder to notice and attack vs. a big distant thing)
One big box room is often all you need, don't spend more than a few minutes on this
For ranged enemies, also build raised ledge / gap / cover variations
Simple basic all-purpose pattern for flanking and cover: iceworld 3 lane
Create a placeholder object
Colored shapes like blocks and capsules that slide around
Pre-made assets, reuse existing character art but with a different color
Script the behavior
if the game engine or tool has a robust scripting system or AI system, you may be able to prototype the enemy without editing game code directly
but usually, you will need to do some game programming
common AI scripting patterns: state machines, behavior trees, or a bunch of if() blocks
Playtest the enemy prototype
If possible, get console commands / debug menus for spawning even more enemies in-game at runtime
Once the enemy is functional in-game, your work has only just begun. You must now tune the enemy's stats and behaviors to fulfill your experience goals.
For early tuning passes, make only big changes. Do not make small adjustments because you won't be able to notice such small adjustments at this early stage.
The full enemy design process can take many years over the course of the entire project, as you gradually add new enemies, weapons, player progression, levels, etc.
Your project team may suddenly cut a half-finished enemy type to meet an important deadline. Or maybe you'll need to demote a boss design to a weaker reusable "midboss" type. A perfectly-tuned enemy may suddenly feel obsolete or broken. This is just the nature of creativity and game design: the project will change and develop.
TODO: example, HL2 chopper
(to do)
basically the same process as general enemy design but now it's a big setpiece
except you should also keep iterating on the arena blockout while you prototype the boss
A boss doesn't have to be a new enemy type, it can be an existing enemy type with special scripting, or even a puzzle designed around an NPC. Any climactic setpiece with conflict and danger will feel like a boss fight.
Enemy design is a lot of work and usually requires collaboration with artists and programmers to create a usable finished in-game enemy.
Enemy rosters help you balance enemy types within an ecosystem. Avoid redundant enemies which do not have a clear purpose or use case.
Diversity is important. You'll likely need a mix of weak and strong, slow and fast, small and big, close range and long range, and everything in-between.
How to design an enemy:
Define core stats like health, speed, damage, and range / behavior.
Blockout a big box test arena, but don't spend more than a few minutes making it.
Prototype the enemy and playtest, you may need scripting or programming knowledge.
Boss design is a special case, a unique setpiece encounter tied more closely to a specific level. Keep iterating on the boss arena blockout.
Consider other general combat design concepts.
Use enemies for encounter design.
When working on a team, much of these performance considerations will stretch far beyond the level designer's responsibilities.
For example, if pathfinding two NPCs brings the game down to 5 FPS, then that optimization is the engine / AI programmer's job. However, if the level designer is attempting to create a massive battle with dozens of NPCs, and the game was never supposed to support that type of encounter, then clearly the level designer might be more at fault.
Large commercial studios hire tech artists and tech level designers, whose primary responsibilities may involve optimizing art assets and levels. But on a smaller dev team, optimization is basically everyone's responsibility.
"Not too early, and not too late."
Optimizing too early is "premature optimization" and it is a waste of time because your project will change drastically. Why optimize something the player may never even see?
But how will you know if something will be in the final version? Probably only when it works well... and sometimes you can make that judgment call only after you try to optimize it.
Ideally, optimization is something you plan from the beginning. As early as pre-production, you should be able to answer these questions about your project's technical scope:
What is the target platform? For example, making an open world game for a phone is much more complicated than for desktop gaming rigs.
How big is the level? A large open world city or RPG continent will need to be built in smaller chunks that are carefully loaded / unloaded during the game and blockout accordingly.
How dense is the level? A realistic outdoor world might require a lot of expensive overlapping details, while a stylized handpainted world might be more sparse and simplified.
How open is the level? A narrow indoor level with frequent gates can make better use of occlusion culling, while a big open outdoor landscape is difficult to divide into segments.
What is the camera system? For example, a first person camera can see long sightlines, so dense levels will likely need some kind of occlusion culling. A third person fixed camera angle means you have strong control with frustum culling, and if a particular camera angle is laggy, then you can simply reposition the camera or turn the camera away.
Video games run on computers with limited resources. Laggy low framerates happen when your project is overusing its budget for one or more of these resource types:
Games are made of files are loaded into memory. When you start the game, it moves core files into a faster type of short term memory called RAM. If there's too many files to load into RAM, then load times will be very long.
If your level uses lots of different detailed models, textures, sounds, or animations, then it might be overrunning its memory budget.
The CPU is the main part of your computer that runs the file system, controls, game logic, AI, and audio. If you have too many NPCs who are navigating a big complicated city, then maybe the CPU has to work too hard to simulate all their AI. Or imagine you had thousands of insects in the virtual city, and you were constantly creating / deleting insects every second.
If your level features many different simulated objects, then it might be CPU-bound.
The GPU (Graphics Processing Unit) is responsible for rendering an image on the screen. It must gather all the visible 2D sprites and 3D models and process them with a special GPU program called a shader. When there's too many objects to draw or when the shader is very complicated, then the GPU takes longer to render the camera view.
If your level features visually dense objects, or even thousands of simple objects, then it might be GPU-bound.
When talking about budgets, game developers extend this financial metaphor:
Expensive = consumes a lot of memory or processing time
example: "Wow, that shader makes our game run at 10 FPS, it's so expensive!"
Cheap = uses very little memory or processing time
example: "When the player is 10 meters away, we swap to a cheap water shader."
A game can run slowly for any number of reasons: memory, CPU, GPU, etc. To figure out what part of a game is responsible for the slowdown, we must measure what the game engine is doing -- this is called profiling.
Never try to optimize on faith or a hunch, because you could be wrong about what's making the game run slowly. Profiling should be the first step of any optimization pass! Fortunately, modern game engines feature a robust suite of easy-to-use profiling tools.
playtest with the Stats panel in the Game tab for a basic direction for where to look
if you're CPU bound, use the Profiler and look for which code functions are running very often or seem to be time-consuming; if you're not a programmer, you should talk to one
if you're GPU bound, open the GPU Profiler or even the Frame Debugger, and try to figure out if too much is rendered at the wrong time or place, or if culling / batching / instancing is breaking somewhere
in Unreal, go to Project Settings → General Settings → Framerate and disable Smooth Framerate, which snaps framerate to certain increments and will mislead you
while playtesting, in the console type stat unitgraph to show basic CPU and GPU times
if you're CPU bound, you may need to use Unreal Insights, maybe you have too many actors or some of your Blueprint calls are expensive
if you're GPU bound, in the console type stat scenerendering and see where your draw calls and framerate are going
see
(TODO: Unreal image)
Unless there's a lot complicated gameplay systems or scripting happening, most game levels are usually GPU-bound: there's too much work for the graphics card to perform.
When profiling GPU performance, the main stat to watch is the draw call, a rendering command sent to the GPU. More draw calls is usually worse. You want this number smaller.
Device class
Approximate draw call budget
Old mobile phones, Mobile VR (Oculus Quest)
50-100
Modern mobile phones
100-400
Low spec desktop, VR desktop
500-1000
PS4 / XB1 / Switch
~1000
Mid spec desktop
~2000
To reduce draw calls, engines implement some form of (a) batching or (b) instancing.
Batching is when the CPU combines multiple draw calls into a single draw call.
Imagine a level with 10 different trees; we can combine them all into one mega tree, and send it to the GPU as one draw call. This method usually requires some pre-calculation and mindful construction, but it works across multiple different meshes and objects.
see Unity: Static Batching, Unreal: Hierarchical Level Of Detail, Godot: Batching
Instancing is when the GPU repeats the same draw call multiple times.
Imagine a level with 10 identical trees; we can tell the GPU to repeat the same rendering work for each tree. This method requires little level design work or prep, but it only works for exact copies of the same mesh. Great for a modular workflow, which uses many copies of the same modular kit tiles.
see Unity: GPU Instancing, Unreal: Hierarchical Instance Static Mesh
lights, turn off shadows... why shadows are so expensive / extra draw calls
Batching shared materials: texture atlas is a large composite texture made of many smaller textures, usually arranged in a square grid. Much like a 2D spritesheet made of many parts, "packing" many textures into a single larger texture is a useful optimization to reduce draw calls and efficiently use memory. The drawback is that the resulting assets are less flexible to use (UVs correspond to a small area, textures cannot be tiled easily) or might even degrade performance if this manual optimization
distance culling, frustum culling, LODs... but if you have lots of objects, overhead of LOD isn't worth it (Naughty Dog)
occlusion culling
vis portals, manual culling
shader optimization:
opaque shaders are almost always better than alpha transparency... modeling out a complex shape is better than alpha mask transparency, the extra polycount is negligible for the draw call or batching anyway
what is alpha test + on most hardware, alpha test is much faster than alpha blend... smooth jagged edges with alpha to coverage
on some mobile devices, alpha blend is faster than alpha test
for foliage, fit geo to the opaque alpha + merge multiple meshes + minimize overlap + use opaque core + avoid using generic object data structure (don't hand place each grass clump)
spawn less AI
TODO: particles and transparency
Forward rendering means the graphics card (GPU) processes each object in a straightforward manner, rendering and lighting every 3D object separately. Here you should usually avoid overlapping lights, and use as few light sources as possible.
Deferred renderers delay lighting calculations until after it collects all the objects together, and then lights all visible pixels at once. Here you can use many overlapping lights and sources, but transparent objects might look bad.
(image: forward vs deferred)
Optimizing games is a complex process that involves every discipline and developer. It is far outside of the scope of this book. Nevertheless, we've tried to give a basic idea of optimizing 3D levels in common engines like Unity and Unreal:
look at performance stats / profilers to see what's slow, DO NOT JUST GUESS
if it's CPU bound, maybe there's too many active objects or NPCs, or the level scripting is misbehaving, or the level is just too big
reduce the number of active objects or NPCs; redesign encounters
debug your level scripting; ask others for help
this also might be a general game code problem, and nothing to do with you
if it's GPU bound, maybe there's too many lights or env art objects, or the materials / shaders are too complicated, or the level is just too big
reduce lights, use simpler lighting modes, turn off shadow casting
combine multiple objects with the same material using batching
"Optimizing and Profiling Games with Unreal Engine 4" (2016) by Vincent Loignon is an old article but still a useful intro to the general optimization process.
"UE4 - Overview of Static Mesh Optimization Options" (2017) by Bob Cober is also a bit old but very useful for environment artists and level designers in particular.
"Unreal Art Optimization: Measuring Performance" is part of a work-in-progress tech artist book specifically for Unreal devs.
by Tech Art Aid is maybe the most useful intro video tutorial about profiling in Unreal.
by Alex Silkin seems like a VR dev talk, but actually it's more like an Unreal performance optimization talk. Silkin discusses specific workflows and bottlenecks applicable for any Unreal game.
systemic: using a repeated design language of game elements
variety: ideally, not just one specific solution or best strategy
tactics: improvised short-term play style / behavior
Many games approach challenge and conflict in a non-violent way in the form of puzzles, dialogues, or mini-games. But in level design culture, "encounter" generally means a single player or PvE (player vs enemy) fight / battle in an action game, shooter, or RPG.
(TODO) For more on non-violent challenge design, see Puzzles.
Encounters are all about pacing. What happens and when, and how does the encounter react to the player?
You can think of it like a story, but plotted through combat -- a combat story with beginning, middle, and end:
Beginning, before the fight:
Are enemies already in battle, or unaware, or en route?
Does player choose when to enter the fight?
Does player know layout and enemy composition already?
Middle, during the fight:
Short or long? How many waves or stages?
Any scripted events that affect the fight?
Any specific routes or strategies to highlight?
Ending, after the fight:
How will the player know when the battle is over?
Are there multiple possible outcomes?
Good encounter design helps player understand what's happening, enough to tell a coherent story with clear cause and effect.
In the video clip above from documentary Jackie Chan: My Stunts (1999), Jackie Chan directs a fight scene for the film Rush Hour (1998). Chan emphasizes a logic to every actor's movements; so when both he and Chris Tucker's actions play off each other, it signifies a climax in their characters' partnership. Don't be like dumb Brett Ratner and repeatedly ask dumb questions about the gun prop (Ratner: "But is this your gun?") because the gun isn't the point! (Chan: "I don't care.") The gun is just a tool to help the audience follow the fight.
Encounter design is about using movement, posture, and action to tell a story. However, the telling is more important than the specific story itself.
For more on general storytelling / rhythm in level design, see Pacing.
For single player action shooters with an emphasis on cover, give the player an opportunity to survey the arena before the fight actually begins. They need time to look around where to fight from, predict where enemies will fight from, and create an escape plan in case the fight turns against them.
If you don't help the player understand the layout, then the player will just fight unimaginatively from the doorway without committing. Your arena design will go unused, and the player will blame the game for offering so little information and incentive to use the arena.
How do we entice the player to move into the arena, understand the layout, and then engage enemies? Andrew Yoder calls this "the door problem of combat design."
There are several ways to give the player a chance to find their foothold:
Begin the encounter with enemies unaware of the player's presence, visually exposed from the arena entrance. This allows the player some time to form a plan, and attack when they are ready.
Although the player will likely eliminate the exposed unaware enemies very easily at first, you can just hide or spawn more enemies around the corner, and bring in these reinforcements when the fight begins.
This pattern is common in open world games, or any large landscape dotted with enemy outposts. It fits with the genre's aesthetic to promote freedom of movement.
Begin the encounter with no enemies, so the player will wander into the middle of the arena. Once they pass some sort of midfield threshold, trigger enemies and begin the fight. Optionally, place some items and resources in the middle as "bait."
Experienced players will likely understand this as a clear trap, and become especially suspicious if the empty room is structured like an arena, or if the bait is offered freely with no apparent cost or danger.
Note that the surprise quickly loses its luster after the player's first attempt. Avoid making enemy ambushes very difficult, because the repeated deaths and trial-and-error gameplay, combined with the player's lack of control over the ambush, may feel grating or unfair.
This pattern is common in classical shooters and horror games. Players more readily accept the contrivance when it is in service of shocking them.
Begin the encounter with unaware yet unattackable enemies, observable from a vista (high vantage point) but separated by an unbreakable window or long distance out of attack range. The player can collect information, form a plan, and begin the fight when they wish.
Optionally, force the player to enter the arena via one-way entrance, with a short vertical drop or airlock door closing behind them. This way there is minimal opportunity to surprise the enemy or cheese the fight. Once the player drops down into the arena, they are committed. The closest thing to a "fair fight."
If playtesters don't make use of the vista, try: (a) placing resources at the vista, (b) make smoother flow into the vista, (c) obstruct flow to the arena entrance and obfuscate the entrance at first (eg. with a U-turn typology), or (d) all of the above.
This pattern is common for boss fights or any big climactic set piece encounter. Forcing the player to stop at a purpose-built vista is a strong design gesture that warns the player: don't be thoughtless, be prepared.
For more on using different enemy types, see Enemy design.
The enemy palette is the specific selection of enemy types for an encounter.
Most of the time, use only a few enemy types at once. Using too many enemy types is like making a movie with too many characters, or cooking a dish with too many different flavors. It lacks focus and it won't be clear what is happening. Simpler is usually better.
Yes, big messy chaotic battles can be useful and exciting too. However, keep in mind that any experienced player will start sorting through the chaos -- solving for one enemy type in isolation, a small chunk of the battle, while ignoring the rest of the encounter.
1
Tutorial, rest
At first, focus on a specific type in isolation. Afterwards, it's simple / comfortable, a rest.
2
"Regular"
2 enemy types work together in an interesting way, a relationship.
3
Complex
It's hard to deal with 3 relationships at once. And in video games too.
For more on classifying and studying players, see Player personas.
A player persona is a player's overall long term behavior, motivations, and play style. It's like the player's personality, their "main", their "build", their favorite weapon. It generally doesn't change. Some examples:
platformers might have runners, jumpers, gliders, swimmers
shooters have snipers, shotgunners, "spray and pray", campers
open world games might have explorers, fighters, drivers, collectors
strategy games might have rushers, turtlers, expansionists
all games have completionists, speedrunners, lore hunters, streamers, newbs, etc.
(TODO: image)
However, with strong prompting, you can change player behavior for the short term, and ideally that influences their overall long term persona. Some examples:
Encourage an under-used mechanic: Players aren't using the gravity gun? Starve the player of ammo for all their other weapons, place physics props everywhere, and use numerous slow moving enemies. (Ravenholm in Half-Life 2)
Discourage an over-used mechanic: Players are climbing too much, and see every traversal encounter as a climbing problem? Add permanent rain to discourage climbing. (Zora's Domain in Breath of the Wild)
Every project needs to define its own personas. Then for each encounter, decide which personas / strategies you will support and how.
EXAMPLE: in the sci-fi RPG Cyberpunk 2077, players can specialize in hacking skills. Therefore, every encounter must support "hackers" with multiple hackable objects in every arena. Some encounters might make use of hackable robot enemies, while others may rely on hackable cameras and turrets. But there's usually always something for a hacker to use.
todo: break up sock's diagrams and talk about them individually
Throughout the third person action game God of War (2018), the player can try to defeat 9 optional bosses called "Valkyries". All the valkyries share similar character art, animations, and move sets, but use these moves in different orders under different conditions, making effective reuse of the same assets while building combat variation.
The player unlocks a boss by progressing through the game and unlocking areas, thus implying an order but not forcing the player to fight them in order. The first three were specifically intended as loose tutorials for players to recognize tells and telegraphs, though sometimes the designers exploit this suggested order by mixing up prior patterns to force the player to relearn new timings.
Former Sony combat designer Jason de Heras detailed the combat design on Twitter:
Gunnr has 2 standalone attacks whose role is to encourage parry (yellow FX); their anticipation window/attack speed are similar to allow for consistent parry timing. [It] encourages the player to parry, but doesn’t require it. All of Gunnr’s attacks can be evaded left / right / back or parried [except] 1 unparryable (red) attack [...] performed after a series of initial attacks, so the player has plenty of time to prepare. The unblockable attack has almost zero tracking so the player can evade to the right with minimal precision. Gunnr usually evades away to initiate her standalone attacks. This gives the player an obvious visual tell but also a huge amount of layered anticipation time ~2-3s to prepare and react to the subsequent attack. [...] Gunnr has virtually no downtime after evading and then attacking which arguably makes the fight easier. This removes one less variable the player has to strategize against. The designers’ kept the intensity high, but actually put the enemy in a vulnerable position.
Unlike Gunnr, Kara’s has 2 attacks that strongly forces the player to evade/block. Since these attacks have similar startup poses, the player must identify the red FX to choose evade or block. [...] Kara shares Gunnr’s Dash, but [if] the player mistimes a parry/plays defensive, they’ll be vulnerable to nearby Draugrs, [adding tension.] Kara’s Wing swipe is a standalone attack that gives her another mixup when evading away and resetting the fight. [...] The range that Kara’s Wing swipe is initiated causes it to miss on purpose. This serves to lull the player to sleep and bait them into attacking if they aren’t paying attention or become greedy. The small burst of forward translation at the end makes this attack deceptive. Geirdriful shares some moves from both Gunnr and Kara, but adds 2 unique attacks for a formidable/well-rounded moveset [...] Her lone closing attack is unparryable and gives her a high risk / high reward attack compared to Gunn/Kara’s dashing attack that can be parried. [...] Geirdriful’s wing swipe combo is the same as Gunnr’s, but used as a standalone attack (as opposed to Gunnr’s counter attack), another mixup to make the fight less predictable. Geirdriful shares the Gunnr wing thrust unblockable but as a standalone attack with increased translation/speed. If the player fought Gunnr first, then the removal of the wing swipes before the wing thrust unblockable will force them to relearn the cadence of this attack.
In the stealth first person game Dishonored, mission 7 "The Flooded District", the player faces a boss NPC. They can sneak past the boss undetected or attempt to fight the boss. Arkane Studios level designer Dana Nightingale commented on her design documents for the encounter:
Normally I hated boss fights so it was kind of excited to design one to avoid all of the stuff I didn't like about them. [...] Designing that encounter with Daud is still one of the things I'm the most proud of. I love watching people play though it. Big blocks of text is nice for a "dev commentary", but it doesn't work well if you have a hundred docs to keep up to date or you're the person who has to read them. Simpler, but conveying more, is always the goal. That's really hard.
Nightingale's original design documents (below) outline clear design goals for the encounter to justify the unusually closed-off arena layout. Additionally, because Dishonored is an "immersive sim" RPG game with many different player abilities, she uses a flowchart format to imagine different player strategies and how the encounter scripting should handle edge cases gracefully. However, as she points out, it is quite a lot to read; writing too much detail into a design brief does not necessarily improve planning or design.
Game AI Pro is the main game industry publication about game AI programming and techniques -- professionally written and edited -- and free to read. If you're not a programmer, some of it will be difficult to understand, but try to push through it anyway. If you can understand 50% of it, it'll still help you a lot. A valuable community resource for combat designers.
"Basics of Classic FPS Combat Encounter Design" (47 min video) by Andrew Yoder
"Encounter Design Topics: RNG in Encounter Design" by Nathaniel Chapman is about when and how to apply randomness to combat, especially in a multiplayer or MMO context.
workshops Quake 1 combat encounters at different difficulty tiers, while offering general design commentary and advice. Markie uses different monster behavior and weapon / ammo placement to encourage different player movement within the same room layout. A great primer even if you're not mapping for Quake.


Shapes that block sightlines, offer protection in combat and stealth games
Cover is any object or structure that blocks a sightline or shields someone from attack.
If a game has projectiles and walls, then it also has cover. It's an almost unavoidable feature in combat games, as old as the genre itself.
However, cover implementation can vary from a simple arcade-like feel to a complex cover system with animation and scripting markup. Like any combat mechanic, the rest of the core game design can all affect how players actually use cover.
Space Invaders (1978) has cover. But your time is better spent shooting, out of cover. Early first person shooters like Doom (1993), Quake (1996), and Unreal (1998) all feature this similar arcade-like focus on speedy shooting, where you sometimes take cover briefly before running and gunning again. Dodging is often a better strategy than standing still behind cover. Here, cover is a maneuver.
More "realistic" shooters like Half-Life (1998) and Counter-Strike (1999) have a faster time-to-kill and so crouching behind cover is essential, and you need less shooting time anyway. Here, cover is a tactic that slows down all combat. You shoot from cover, instead of around cover. Halo (2001) later used a regenerating shield mechanic to stabilize this duck-and-cover rhythm further, directly rewarding the player for taking cover.
In early 3D third person action games like Metal Gear Solid (1998) characters can hug walls or crouch behind crates. Here, taking cover becomes more of a distinct action / mode that characters enter into. This marks the beginnings of a cover system, though used more for stealth instead of combat.
The somewhat obscure Kill Switch (2003) is the first generally recognized cover shooter with its formalized cover system, a mechanic where characters can dynamically snap to cover, posing their body and hitboxes to the cover geometry. Gears of War (2006) later popularized the cover system to define the modern cover shooter genre as we know it today, now common in series like The Last of Us, The Division, and Uncharted.
The function of cover will depend on how players move around it / with it / through it.
Cover as maneuver, briefly stand behind an obstacle when you're not running and gunning, in fast-paced games with arcade feel. Occasional use for mob management. Moving around cover.
Cover as tactic, a general strategy where you regularly duck and cover, in realistic action games especially "gritty" 2000s shooters. Slows down otherwise rapid time-to-kill. Moving with cover.
Cover as system, an integral mechanic where being in-cover is a distinct state, in third-person cover shooters with body awareness. Cover is the default combat mode. Moving
After the core combat and cover implementation is decided, level designers usually focus on just two aspects of cover design:
cover shape: geometry of an individual cover object, usually a wall or a box-like shape.
cover placement: overall of cover shapes in an arena or encounter.
Cover can take on a variety of shapes and functions. Sometimes cover is a distinct object, sometimes it is more like a general feature of a .
Primary aspects: Height, Width, Solidity, and Facing.
Secondary aspects: Verticality, Corners, Permanence, and Authorship.
You can shoot over or jump over waist-height tables, but taking cover requires staying down and close.
Tall cover protects against elevated attackers but standing / sidestepping out can expose more.
Shallow narrow cover can leave you exposed, while deep wide cover provides reliable protection.
Exposure is useful to weaken NPC positions, make somewhere more dangerous, or encourage more movement.
NPCs ignore you in non-solid soft cover like bushes or tall grass, but PvP is less generous.
Softness varies. Energy shields / bulletproof windows block bullets but not sight; grates block movement but not bullets; Counter-Strike has bullet penetration ("wall banging").
Directional cover leaves blind spots for attackers to flank or defending teammates to cover you, good for a frontline.
Free standing cover often leads to "ring around the rosie" dances, circling in duels, better for a climactic last stand. See .
It feels good to clear a trench of NPCs, but usually feels bad yourself to get pinned down by a sniper or turret.
Elevation gives a stronger height advantage depending on angle of attack. See also .
Sharp "blind corners" (90+ degrees) protect you even up close.
Rounded corners leave you more exposed depending on the curvature. Longer curves are harder to hide behind. See also .
Most cover is permanent and static, but breakables give temporary semi-hard cover like in F.E.A.R or Dark Souls.
Moving cover (especially half cover) should move slow (a payload cart) or be huge (a long train) or else it's hard to use.
Fortnite lets you build hard cover; Counter-Strike has utility (smoke grenades) to create soft cover. These games' maps have less developer authored cover because players fill-in open space with their own cover.
For more on general level design measurements, see .
Cover metrics are specific sizes and measurements to standardize cover objects.
Consistent cover is useful for combat games that want to avoid ambiguity, or any action game with a cover system / body awareness animations that need to make assumptions about cover shapes.
For Uncharted 4, Naughty Dog designers made sure all their cover objects and wall heights conformed to three height ranges:
High cover. Standing head height object, 1.75 or more meters.
Low cover. Standing waist height object, 1.0-1.25 meters.
Not cover. Knee-height object at 0.5 meters or less
In contrast, fuzzy cover is a cover object that feels ambiguous or inconsistent.
In the brutal unfair action RPG Dark Souls, sometimes you think you're safely protected behind cover but then you suddenly get one-shot killed anyway. Or consider a military sim shooter like ARMA, where you can actively control your stance in detail, dynamically adjusting pose and leaning to conform to cover, requiring mastery in a serious mil-sim way.
So it all depends on your experience design goals. What do you want your cover to do? What are your mechanics? Are you making an Uncharted, a Dark Souls, an ARMA, or something else entirely?
(TODO: fuzzy cover examples)
The simplest cover implementations don't need special scripting. You build a wall or place a crate and the cover is ready for use.
More complex cover implementations need some scripting markup to help NPC AI use cover. Half-Life used nodes, possible fighting positions hand-placed by level designers. Half-Life 2 and Gears of War 1 implemented several types of specialized cover nodes, to signal the correct character animations to use for the cover system.
Most games today would automate some or all of this cover markup process:
workflow: reuse hand-authored cover markup by reusing tiles or prefabs.
Baking workflow: automatically detect and bake cover markup, related to a navigation mesh ("navmesh") baking pass. Allow hand-authored overrides for edge cases.
For more on NPC AI and nodes, see .
Different games needs different cover .
Genres like third person stealth have different cover needs vs. a first person shooter.
In stealth: cover is a player tool to manage enemies, information, and visibility.
In combat: all of the above, but also, cover is hard protection from enemy fire.
Mechanics strongly affect cover layout.
Consider these cover layouts for a stealth game (above left) and for a shooter (above right):
Imagine swapping these layouts. They could work OK, but players would behave differently.
If we played the stealth layout in a shooter, the player might headshot the defenseless enemies on sight and ignore the cover entirely. If we played the shooter layout in a stealth game, beginner players may fail to notice the guards hidden behind cover -- or if the guards were noticeable then the protected side paths would feel obvious and easy, like for a tutorial or the start of a mission.
This hints at the difficulty of level design for combat-stealth games. Ideally, all cover placement must support two very different play styles / game states.
Often less cover is better. Cover blocks sightlines, which prevents players from noticing what's happening. Defense feels meaningless if you don't know what to defend against.
In a single player encounter, enemy cover should usually leave NPCs somewhat exposed somehow, or else the player won't notice them.
Too many wide tall cover objects can create confusing maze-like and , which is usually bad for most action games.
For Gears of War, Epic Games designers argued "in general, low cover is better than tall cover" in a multiplayer cover shooter context:
"In general, low cover is better than tall cover. [With a wall] generally your interactions are limited to the ends of the wall [and] you’re also greatly limiting player visibility and separating the player from all the action going on over the wall.
If you lower the wall you’ve drastically increased the options for the player. They are now aware of things going on over the wall and can be on the lookout for flanks and enemy movement. They can pop up and shoot from anywhere along the wall, giving them far more choices in firing positions. They can stay crouched and feel sneaky as they maneuver for a better shot. And of course they can mantle over the wall. As soon as they start moving along a high wall they are detached and simply traversing the map, but with a low wall they’re still fully involved in the match."
-- Epic Games,
Gridlock is a team multiplayer map for the cover shooter Gears of War. It's the most influential map in the series, and the only map that has been in almost every sequel.
Epic Games attributes its success to its open spaces and usage of low cover:
"Gridlock is the clearest example of [visible flanking]. With the abundance of low cover, lines of sight are running all over the map, allowing a good player to constantly be aware of enemy positions and potential flanks.
[... You'll] often see a firefight rotate in orientation, occupying the same space, but with action happening on a different axis.
[... Maps like this] have such long view distances that they reward the observant players who can see which direction the enemies scatter to once they leave the spawn areas."
-- Epic Games,
Cover depends on angles -- the combatants' sightlines as they rotate around corners.
To visualize the angles, imagine the edge of the corner as the central axis / pivot. As you rotate around the corner, your view angle gradually gets wider -- but so does your possible exposure.
Real-life militaries and police call this "slicing the pie": sidestepping around a corner, gradually accumulating more sightline "slices" of a room until you've cleared all angles.
Directional cover limits possible angles (how much "pie" you can have) while freestanding cover supports multiple angles (360 degrees of pie!) but that also means you have to choose which angles to defend against.
For example, in Counter-Strike on Dust2's B site, both directional and freestanding cover have different vulnerability:
"... there is a cubby in the wall where a large wooden gate is shut. This recess is deep enough for a player to hide behind the post and use it as cover against an attack from the upper tunnels [highlighted in blue].
... once the attacker has cleared the cubby, they can’t use this same cover against the defenders. The cover offered by this cubby is only useful against upper tunnels [in blue]. Even worse, the cubby is exposed from the defender archway [in purple, and window in red], which means attackers can’t use this cover when they are holding the B site against a defender retake..."
"... a player can use the tall box to hide from upper tunnels [in blue], or to hide from window [in red] and defender arch [in purple].
Freestanding cover leaves options open. A player can choose to peek from either side, loop around it, or disengage. They can choose to hold close to the cover and try to peek wide and fast, throwing their opponent’s aim, or they can try to back off and play from range. So long as they are in an even fight, they have options to play that cover to their advantage. Even in a 1v2, freestanding cover can help the outnumbered player juke and stay alive, burning precious seconds off the clock.
Because of this versatility, freestanding cover tends to work best on objective sites where players may duel or attempt to run the clock down."
-- Andrew Yoder,
Even if you're not playing a military shooter, you're still probably strafing around corners in a similar way, limiting your exposure as you clear the corner.
Note how rounded corners or curved hallways would leave fewer angles to hide.
Sometimes less no cover is better.
In a tutorial or boss fight, you may prefer a very simple flat open arena design to teach the player clearly, or to keep focus on the setpiece or story moment. Cover blocks sightlines, which can be bad when you want the player to notice or track something.
Sometimes it's best to keep an area "empty" and open, to allow for more player expression or systems to fill-in. Like a Fortnite map provides plenty of empty space for players to build their own cover.
Or consider Counter-Strike's Dust2 map:
"If you aren’t familiar with the specifics of Counter-Strike, the empty stretch of road on long A may look like bad level design. In Call of Duty, this area would be a death trap, and common Call of Duty layout patterns would suggest the area needs flank routes and more cover here. However, in Counter-Strike these paths are possible in exchange for utility..."
"... Smoke grenades deny vision. Smoking a threshold or t-junction can deny a path or allow a safe crossing. Smoking a corner create pockets of hidden information and off angles for enemies to worry about. Players can also deploy a smoke in the open, like the one pictured above, to create new angles for players to fight around. Smokes behave like cover objects in how they conceal information."
-- Andrew Yoder,
Repetitive standardized cover can lead to a cover box feel -- spaces that feel strangely artificial with numerous conveniently-spaced consistently-sized rectangular objects.
If you don't mind levels feeling "videogame-y" then this often isn't a problem.
But arguably for a game like The Last Of Us which trades on immersive cinematic realism, then it can feel jarring or even patronizing when a place suddenly feels like a film set / arena waiting to swarm the player. Or maybe it's charmingly videogame-y?
Cover is anything that blocks sightlines / attacks, usually in a combat or stealth context.
Cover is movement, which differs with core game design. Most arcade games are about moving around cover, more realistic games are about moving with cover, while cover shooters require moving through cover. Emphasizing more cover = usually slows down combat.
Cover shapes vary with Height (half vs. full), Width (wide vs. narrow), Solidity (soft vs. hard), and Facing (directional vs. freestanding). You can also consider Verticality (trench vs. elevation), Corners (sharp vs. round), Permanence (dynamic vs. static), and Authorship (designer vs. player).
Use cover metrics if you need consistent cover shapes. Cover systems often need consistent shapes. But sometimes fuzzy cover is fun too.
Cover placement depends on mechanics and player experience goals. A stealth game will need a different cover layout from a cover shooter, or even two stealth games may differ a lot. Less cover is better usually. The overall strength of a cover placement depends on angled movement.
Sometimes no cover is best. Open space enables more focus on a tutorial, boss, setpiece, or player-authored cover.
For a single player level, cover factors into .
For a multiplayer map, cover is part of .
is an analysis of Counter-Strike 2's most popular map Dust2, specifically its cover patterns and sightlines. Many ideas and examples from this page come from Yoder's post.
by Epic Games is multiplayer level design theory written for modders of the original Gears of War 1 back in 2006. Much of it is still relevant for cover shooter design today.
talks about cover layouts from a Ubisoft-ian open world perspective, with an emphasis on encounter design and pacing.
How to conceptualize and design the fictional history of the game world
Worldbuilding is the high level conceptual process of designing the setting and history of the fictional game world.
We inherit this process from fiction writing, especially from science fiction and fantasy (SFF) writers who often construct "bibles" that detail backstory, lore, and characters' relationships in exhausting encyclopedic detail.
Your worldbuilding docs could describe the planet's climate, detailed political histories that predate in-game events, or even mundane details like when does everyone get up in the morning, or what the protagonist's mother enjoys for dinner.
Because this is a level design book and not a narrative design book, we take a predictable stance here: avoid premature worldbuilding. Worldbuilding is work, and if you do too much worldbuilding too early, then it is also unproductive unnecessary wasted work. At first, worldbuild only what you need.
Throughout pre-production, the shape and content of your game world might change drastically. If you start worldbuilding small details too early, then it'll likely be wasted work. What if you write 10 pages about the history of a house, only for the house level to be cut from the project? What if you write 20 pages about some monsters and their culture, only for you or your team to scope down later and replace the monsters with recycled human NPCs? Avoiding detail helps you stay flexible and less frustrated with the project.
While worldbuilding can be fun and useful, for novices it more often distracts from the basic core work of telling a compelling story with characters and actions. Remember that your favorite epic fantasy, sci-fi, and superhero worlds have been constructed over decades (or centuries) by thousands of experienced professionals with substantial funding over countless iterations. When working alone, worldbuilding yourself into a hole is a great way to avoid making a game.
to describe situations when the player's performance ("ludo") and the designer's intended story ("narrative") don't work together ("dissonance").
However, the vast majority of players tend to tolerate a great deal of dissonance in their game worlds. Fan wiki commentators will debate lore consistency, and game critics will point out embarrassing incoherence, but the average player will shrug and move on. Shooter games feature walls that are utterly impervious to nuclear explosives and world-ending magic energy. Every RPG routinely revives dead characters during the game, but arbitrarily kills off characters permanently, with no elaboration on the metaphysics of permadeath. Every action hero is a sociopath who murders thousands of people with no remorse. None of this incoherence feels particularly dissonant to its audience.
So in this book we embrace a functionalist attitude toward game narrative: fictional storyworlds in video games serve a crucial design function to smooth over the inherent incoherence of interactive systems. That is, story solves game problems.
Design problems: is the player "moving through repetitive corridors and shooting squares", or is the player "escaping an alien invasion of a vast underground military complex"?
Technical problems: is the monster "unable to navigate water due to broken pathfinding AI", or is the monster "afraid of water"?
For most level design projects, we recommend starting with a minimal psychological approach: worldbuild the bare minimum necessary to establish the level setting and support experience goals.
To plan a basic level, you only need to worldbuild enough to answer three basic questions:
(Past) Who made this place? (Why? How will the player know?)
(Present) Who lives here now? (Why? How will the player know?)
(Future) How can the player affect this place? (Why? How will the player know what happened? How will the inhabitants react?)
These answers can be simple. Here's an example for an action game level with minimal story:
Who made this place? A human family built a log cabin. (How will the player know?... It'll look like a log cabin, built at human scale, with human furniture and multiple beds inside.)
Who lives here now? Some monsters ate the humans. (How will the player know?... There are monsters and old bones inside, and no living humans.)
How can the player affect this place? The player can kill the monsters. (How will the player know?... The monsters are hostile and will attack the player on-sight.)
Even this short premise already has so much potential for future storytelling. What type of log cabin is it, how big was the family, why did they settle in this exact spot? Why did monsters attack the humans? What if there was an alternate way to resolve this encounter, without killing the monsters? How can the theme of "family vs monster" resonate throughout the rest of the level, or the rest of the game?
For large long term projects (more than a few levels / few months) then it makes sense to commit more fully to the game world and its fiction. Worldbuilding bibles are generally made of three types of worldbuilding design documents: maps, timelines, and notes.
To organize worldbuilding documentation, use a personal wiki or note database -- see .
Draw a map of the fictional game world, beyond the playable area in the game. What is the level's relation to the larger world or universe? Mapmaking is a very common worldbuilding trope in fantasy genre novels. And for level designers, a map is probably the most immediately useful worldbuilding tool.
The simplest way to engage the player is with plausibility. If you're new to worldbuilding, you should start with something familiar and Earth-like for now.
First, draw a large scale map focused on terrain and climate. To design something plausibly Earth-like, start with some basic earth science principles:
Draw continents. Simulate and make sure they fit together like puzzle pieces.
Draw wind systems and latitude. change with latitude and interact with landmass.
Draw mountains and lakes. along fault lines or volcanos. generally flow from atop mountains or lakes and downward toward the ocean.
For more on researching and designing terrain / biomes, see .
Once you have a solid base world, you can make it feel more unique or fantastical by selectively exaggerating certain aspects.
In the example map above, author N.K. Jemisin made a world with two continents slightly above the equator. Then Jemisin focused on a section of high energy equatorial ocean between the two continents, and amplified it into a "hell corridor" called the "Sea of Tears" where valuable "Furywood" trees grow along its coast. While an area plagued by constant tsunamis that temper magical trees is implausible by itself, it feels much more plausible and special when integrated within a more mundane world.
With an established natural world, you can now begin populating it with people. Where do they live and why? What is important to them?
When designing societies, author N. K. Jemisin strongly recommends some basic and doing research -- and avoid relying on thinly veiled stereotypes of existing real world cultures.
Needless to say, mapping societies and territories is extremely complicated in the real world. People go to war over borders, region names, and political identities all the time. This conflict and tension is probably what makes your world interesting, so embrace mapmaking as the messy political design process that it is.
Define the mapmaker, who are they and what are their motivations? What is their relationship to the area that they are mapping?
Sketch multiple maps of the same area, but from different perspectives. What did the area look like 100 years ago, or 500 years ago? Would different characters with different backgrounds draw the same place differently or use different names? Where is the ambiguity and conflict in your world? A "wrong map" might be more interesting than an accurate map.
Draw non-geographic maps, without borders or landmass. What would a "social map" of a city look like? What about an economic map, or an emotional map?
Plot a history of the game world, across days, months, years, or even centuries, accompanied by short annotations and labels.
What is the history of this area or place? How have the people changed? Just as with geography, history is also a deeply political craft that changes based on whoever is doing it. When writing a history you must consider the historian and their background, who their audience was, and most importantly, what they exaggerate and what they omit from their account.
Again, the goal is not an authoritative factual history that definitively answers every question. Think about the big idea or theme that each history evokes.
(example timelines from Heaven's Vault?)
Define the historian, where and when are they writing from? How would their perception, memory, or access be shaped by their time and place?
Design multiple timelines that overlap, ideally with specific similarities and contradictions.
Leave forgotten holes in each timeline, think about what the historian forgot or what they misremembered. Part of your in-game experience could involve rewriting history, filling in these gaps, or identifying new holes in history that no one knew was there.
While level designers may prefer visual documentation, narrative designers and writers tend to rely primarily on written notes, often stored on index cards, private wiki, or some other organizational system. These notes might include:
Character biographies, daily routines, family history
Location descriptions, travel guides, geological or ecological surveys
Cultural primers, religious scriptures, local histories
In-world books, pamphlets, speeches
One widely shared piece of worldbuilding advice from now-deleted tumblr user kuusamaagi:
... You can, and actually should have weird and impractical cultural things. They’re not inherently unrealistic, for as long as you address the realistic consequences as well.
Let’s say you’ve got a city where there’s tame white doves everywhere. They’re not pests, they’re regarded as sacred, holy protectors of the city, and the whole city cares for them and feeds them like they’re pets. They’re so tame because it’s a social taboo to hurt or scare one. Nice pretty doves :)
Then someone points out that even if they’re not seen as pests, doesn’t having a completely unchecked feral pigeon population - that not only isn’t being culled, but actively fed and cared for - mean that there would be bird shit absolutely all over the place?
A part of you wants to say no, because these are your nice, pretty doves. To explain that there’s a reason why they’re not shitting all over the place, maybe they’re super-intelligent and specifically bred and trained to not shit all over the place. The logistics of how, exactly, could anyone breed and train a flock of feral birds go unaddressed.
An even worse solution would be to not have those birds, editing them out of the world. No, they spark joy, you can’t just toss them out!
Now, consider: Yes, yes they would, but the city also has an extensive public sanitation service that’s occupied 90% of the time by cleaning bird shit off of everything. One of the most common last names in the area actually translates to “one who scrapes off dove shit”, and it’s a highly respected occupation. And thanks to the sheer necessity of constantly regularly cleaning everything, the city enjoys a much higher standard of cleanliness, and less public health issues caused by poor public sanitation.
If you have a lot of time and money, doing full ecological, historical, and architectural development of your game world can be rewarding. Thekla Studios spent $6 million USD across seven (7) years to build the first person puzzle exploration game The Witness, and hired landscape architecture design firm Fletcher Studio to build up the architectural history and logic for its main island.
incorporating different ecologies, climates, geologies, and architectural styles for the game world, while reconciling this worldbuilding with the already existing blockout and puzzle design.
"We first set out to reverse engineer the Island, as it might have existed before civilization. Hundreds of Islands were identified and studied, in the search for small, temperate islands that have a rich history of isolated civilizations. Known as Europe’s secret Islands, the Archipelago of the Azores offered the most material to work with. The layers of different cultures, from ancient civilizations to the Portuguese monarchy, to present day fishing villages, proved most analogous. Available aerial imagery was collected from the Azores and then collaged together to create a fictional Island in plan, now with topography, beaches, water bodies, etc..."
"We also wrote an environmental narrative for the Island, which formed the basis for design in subsequent phases. Through determination of solar orientation and dominant winds, the studio was able to establish the crucial gradients of wet and dry, windward and leeward. We then diagrammed the underlying geology, establishing assumptions regarding rock types, soils and substrates. The resultant mash-up of granite, basalt cinder cones, limestone and loose sandstones were located in specific zones and guided building materiality, soil types, and subsequent biomes. Using these fundamental climate and geological assumptions, we began to develop a set of simple ecological rules that established the make-up of the Island’s ecologies, and their bordering ecotones.
... The past was divided into three successive epochs, which we termed Civilizations (CIV’s) One, Two and Three. A simple description of each was developed, and then a larger matrix, was produced that related to each in terms of infrastructure, architecture, and landscape. Each of these three categories had their technologies, agriculture, religion, and cultures. Materially, each epoch had its own techniques of building, based on assigned resources and technologies, with each CIV methodologies and products growing more refined over time..."
"... In our narrative, the Windmill began as a CIV One sacred mound, whose rock was reused to construct the foundation for a watchtower in CIV Two. Civilization Three then adapted the tower, as a means to pump freshwater from the reservoir to the rest of the island.
Often, once a structure had been given meaning, it then inspired the addition of other landscapes and infrastructures. The existence of the Windmill necessitated the addition of a lake, a small stream, and eventually a dam and a logging flume. There was a growing reciprocity between the gameplay, architecture and landscape with the island environment and story.
For example, the use of a given building material, lead to the creation of a logged forest, a rock quarry, a glass factory. Puzzles were added to support the resource extraction and manufacturing narrative: A shipping freighter was added to justify the use of steel on the island. This ship was perhaps the source of something that not be easily made on the island, and much of it’s iron had been harvested, and can be seen in various states of reuse throughout." -- from by Fletcher Studio, 26 May 2017
Worldbuilding is about designing the history and conceptual setting of the entire game world.
Worldbuilding in games is either developer-facing (documentation) or player-facing (lore).
For level design for action games, don't do too much worldbuilding too early. It's much easier to change worldbuilding to accommodate a level, rather than the other way around.
by , for Writer's Digest Online Workshop 2015 is our recommended general introduction to worldbuilding. Much of the material on this page is paraphrased from Jemisin's excellent talk.
by Dan Pinchbeck. Useful overview of academic theories applied to action game design, with focus on Gibson's affordance, suzjet / fabula, Barthes' functions and indices, the academic basis of this book's stance on functional worldbuilding.










The history of has been barely documented because, well, encounter design itself has also been barely documented. Much of this knowledge was shared informally in hallways, around water coolers, and over internet forums -- this "field" hasn't really been formalized as "knowledge" (like in a book or a talk) until recently.
This page is our attempt at piecing together where encounter design came from, and how combat design trends have changed over the years.
design exercise for a classic retro shooter type game
In this project, you'll research, pitch, and prototype a combat arena for a fast-paced arcade-style retro first person shooter. Classic FPS games like Doom and Quake emphasized constant movement against hordes of enemies with simple AI patterns, and heavily influenced contemporary action shooter game design today. This design exercise focuses more on your design thinking and communication skills, rather than construction or production skills.
Depending on damage systems / friendly fire, larger enemies can act as moving cover.
Multiplayer maps use cover as part of map balance, but single player levels can have "unfair" cover tailored for specific encounters and player paths.
Enemies begin exposed and unaware
Enemies begin unexposed, behind cover
Enemies control middle
Middle is "no man's land"
Rushing through = no cover
Rushing through = some cover, viable
Side path is critical path
Optional side path for observant players
Side path has vulnerable gaps
Side path offers zero vulnerability as reward
















































Tune the enemy; try big changes, avoid small adjustments when prototyping.
Sniper
Slow weak long range attacker, very vulnerable without others
Leader
Tank
Swarm
Sniper




consider using some sort of occlusion culling / visibility system
simplify materials, use fewer texture samplers and rendering commands
this also might be a general game code problem, and nothing to do with you
PS5 / Xbox Series X
~3000
High spec gamer desktop
~5000
You need to optimize now
~10000+

Label climates. It's hotter toward the equator, colder toward the poles. Mountains can block or trap rainfall. Is it humid, windy, rainy, stormy?
Leave some areas blank, because not every part of the world is immediately relevant or knowable to everyone. No adventure or exploration is possible without mystery.
The doves do protect the city. By shitting fucking everywhere.
Minimal worldbuilding: who built this place, who lives here now, and what can the player do here? For most levels, simple implied answers are enough.
Comprehensive worldbuilding: design maps, timelines, and notes. Again, only do this if your project is big or if you're working in a team.
"Books on Worldbuilding" (2018) by Emily Short is a great list of worldbuilding books and resources, along with Short's insightful commentary on applying the methods to game narrative.
"Virtual Cities: An Atlas and Exploration of Video Game Cities" (2020) by urban planner Konstantinos Dimopoulos is a book that analyzes the urban worldbuilding in 45 different virtual cities, with a mostly Western / European urban focus.

This is a History article. For more on encounter design itself, see Encounters.
Early first person shooter design inherited a lot of sensibilities from Doom. In turn, Doom inherited a lot of sensibilities from an arcade design tradition of top-down 2D shooters like Robotron, Berzerk, and Tempest. In fact, it's possible to play Doom entirely from its 2D top-down "automap" view.
The key tenet of this era of combat design is "maneuverability as defense":
"... because the player moves so quickly in Doom, and because most enemy attacks are dodgeable, the player can avoid a significant amount of damage simply by moving. A skilled player can often deal with large numbers of enemies sustaining hardly a scratch. This creates a feeling that’s quite rare in modern FPS: that you are powerful because you are agile, not because you’re a tank. This frees up Doom’s encounters to feature huge numbers of enemies, to vary scenarios by mixing in different proportions of threats, and to have huge, sprawling, often non-linear spaces that the player can traverse easily."
-- from "Coelacanth: Lessons from Doom" by Vector Poem
In Doom, all the enemies were called monsters -- so the art of placing monsters was called monster placement.
high enemy counts across large maps... getting lost is relatively common and part of the game
fire and forget, arcade style... monsters have short predictable repetitive behavior loops... use several monster types, not just one
Monsters as guidance, e.g. chase monsters to find the exit
Monsters as map control, e.g. don't kill monsters right away, ration ammo, use monsters to infight vs other monsters
Doomworld Forums > Editing Tutorials: "Monster Placement" by Grymmoire and Ghastly
"Coelacanth: Lessons from Doom" by Vector Poem
Quake continued much of Doom's ethos: constant movement across large maps, with defensive maneuverability against high enemy counts.
more control over monsters: leashing with height changes
spatial awareness is different in "true 3d" vs doom
TODO: ask Soc for diagrams?
The monster placement era reached its apex in Half-Life 1 (1998), where its human soldier "grunt" AI gave a powerful illusion of squad coordination and group tactics though extensive use of animations and contextual audio barks.
Marketing materials exaggerated Half-Life's use of sensory models ("the bullsquids can smell you!!") to sell an aura of realism. Monsters were no longer arcade obstacles, but living breathing creatures with psychology and interiority. ("What if you could talk to the monsters?")
Realism means a shift from "monsters" to "AI" and "NPCs", who now need a wider range of behaviors that "outsmart" players -- a tech-fetishizing marketing point that doesn't die, and arguably, taints combat design in first person shooters forever.
Half-Life marks the end of the monster placement era. It's the last historically influential shooter to refer to its NPCs as monsters, a remnant of Half-Life's foundation in Quake engine tech and approach of game design.
Early encounter design was the game industry's attempt to begin systematizing concepts of territory and knowledge model. Hand-designed patrol routes mark a big departure from the "fire and forget" approach of monster placement.
It often involved active and laborious markup of the level, and dividing the map area into various territories and zones. We begin choreographing specific enemy movements during the battle itself, instead of simply spawning an enemy and hoping for the best.
At this point, games began devoting more engineering and processing resources to enemy AI. Developers began viewing combat AI as a separate object to design in a tool (e.g. behavior trees in a visual editor) rather than a hard-coded system embedded with the rest of the game code. Compare Half-Life 1's C++ soldier AI code from 1998, versus a visually-authored behavior tree in _____.
This period also marks the first time that industry developers begin using the term "encounter."
An introduction to thinking about guard placement and patrols for stealth games by Randy Smith, a veteran of Looking Glass / Arkane Studios immersive sim level design. Even though it's not directly about combat, this talk is still essential for encounter design theory because it codifies a lot thinking about affordances, soft cover vs hard cover, sightlines, and blind corners, etc. This is just a strong talk in general, where Smith deconstructs a lot of examples and room diagrams.
Guards maintain "territory" based on their visibility and positioning. Soft cover provides "fuzzy" situational cover within that territory, while hard cover is more reliable and static. It might seem like a lot of this talk doesn't apply to contemporary level design, since Smith's examples focus on a Thief-like game with light and shadow stealth mechanics (e.g. hide in the shadows to remain undetected by guards) and Splinter Cell and Dishonored types of AAA immersive sims have arguably died. No one uses shadow-based stealth gameplay anymore!
However, in contemporary stealth action franchises like Assassin's Creed, Uncharted, Metal Gear Solid, or Hitman 201x, soft cover still exists. They've just replaced shadow pools with tall grass clumps, which provide more readable and more discrete stealth zones than shadows ever could, while also showing-off wavy grass shaders and freeing up AAA lighting artists to do fancy stuff without worrying about the gameplay implications of their shadow patterns. The only difference is that shadows are truly systemic and intrinsic to any environment, while the omnipresence of convenient grass clumps everywhere certainly strains a game's plausibility in hilarious ways. (Suddenly every video game warehouse and military base is now set in the middle of a savannah or tallgrass prairie.)
So when Smith marks up these diagrams with shadows, just imagine he's actually talking about grass, or ponds where you hide underwater, or magical elf fog, or whatever soft cover contrivance of the week that we've embraced as an industry.
There's one crucial disclaimer at the start of Smith's talk: this is not a talk about design process. He notes that they didn't actually follow these design methods for building Thief missions. That is, they did not sketch out ideas for encounters and markup player routes, nor did they build meticulous diagrams to plan guard patrols and pools of shadow.
Instead, most of the time, they just grayboxed a space and placed some guards in an intuitive subconscious way, and playtested until it felt good. This type of thinking is most useful as a playtest analysis tool to recognize what is happening, and it should be applied loosely from the bottom-up. Don't do this in a top-down design planning way.
For an in-depth analysis of a stealth encounter case study from an actual game, see my post about the Thief 1 level Assassins.
Halo (2001) is probably the canonical example of large-scale PvE dynamic battle design, and this talk establishes a lot of crucial first principles. Broadly, it's about how good encounter design requires solid enemy design, and by solid enemy design, they mean:
enemies that broadcast their state via character animations and audio barks to the player (e.g. a Grunt will scream and flee with its arms raised)
enemies with clear predictable abilities and affordances, with differing task priorities (e.g. a Jackal will use its shield to slowly push an advance, while an Elite will seek cover)
enemies with limited perception and memory; the player should be able to trick enemies, and notice from animation / audio that they have tricked the enemy
So the player perception of good game AI (game AI designed to lose gracefully, not machine learning AI) relies on artists and designers as much as programmers. Every modern and contemporary shooter has followed these principles, and now they feel like common sense. I argue that common sense is bullshit, and this stuff didn't used to be common sense, as seen through this talk where Bungie had to articulate and invent all this supposed common sense.
Despite this talk's importance to encounter design history, this is mostly a game design and AI talk. Yes, I know it has "level design" in the title, but if you actually read through it, there's only a few slides that touch on level design. It doesn't really talk much about actual enemy scripting, placement, or architecture. There's just a couple slides about how the Halo 1 level designers had to markup territory, fortification, battle lines, retreat lines, and firing points, but no concrete case studies / examples of the level markup or hinting.
Which is a huge shame, but to me it also demonstrates why there is no solid body of theory about encounter design. Even the originators of modern encounter design didn't think it was a level design problem! Instead, Bungie seemed to regard encounter design as primarily a game designer or AI programmer problem. This is clearly more in the "combat designer" school of thought.
Many game designers remember this talk for this single design note on a single slide: to make an enemy seem smarter, just give it more health. An enemy with more health will survive longer, which helps it build more of a relationship with the player and do more stuff, which means the enemy will seem smarter.
This observation has lead to the emergence of "bullet sponge" enemies who possess large pools of health but little variation in behavior or tactics. But we can trace that back to this idea of high-health enemies to Halo 1, where survivability was meant to contribute to the player's power fantasy and prompt more diverse player tactics and situations. Perhaps when players complain about bullet sponges, they are also partly complaining about the encounter design; if bullet sponges did more, then they would cease to feel like bullet sponges.
This is another Halo encounter design talk that doesn't actually talk about level design, and caters more to AI programmers and tools developers. Still, this is one of the earliest developer talks that touches on ideas of territories, phases (front, fallback, last stand), battle lines, and behavior trees (imperative) vs objectives (declarative) AI scripting models... all of this stuff forms the basis of contemporary industrial encounter design today.
All the terminology hints at consistent design language used inside Bungie itself. But we don't really have any deeper design insight unless the Bungie level designers ever give a talk! Oh well.
popularizes the cover shooter
The apex of the first wave of Hitman games. Everything is still hand designed, but it has formalized concepts of public / private territory
Modern encounter design is marked by an attempt to manage NPCs more systemically. Instead of handmade patrol paths, NPCs wander around automatically as a result of AI routines; instead of manual enemy placement
the use of ecosystem metaphors, coordinators, directors, and conductors. All of these AI manager systems direct NPCs to fulfill different roles during a battle.
ecosystem conceit, player chooses when to engage a big daddy, encounter as a systemic player-initiated interaction
A-life system, expands bioshock ecosystem ideas
dynamic buddy system, open world battles, stalker but more polished
Here, an ex-Valve level designer does a case study of The White Forest Inn battle in Half-Life 2: Episode Two and details the Valve approach to pacing, which imagines gameplay as a graph of rising / falling intensities. This is less about the specifics of combat design and battles, and more about interspersing puzzle sections / story cutscene sections / quieter beats throughout the game to ensure richer variation.
So to use this methodology: separate your game into different gameplay beats, make sure you vary the different types of gameplay beats, and ensure smooth transitions between these various beats to achieve certain effects. For example, the White Forest battle begins with a quiet puzzle solving beat that turns into a giant loud ambush.
This "intensity graph" approach to encounter pacing is a common design strategy for planning overall encounter arcs in action level design. But again, this is less about designing the encounters themselves, and more about how to choreograph a series of encounters.
(TODO: include Left 4 Dead slides)
This is probably one of the best basic combat encounter design talks in the industry so far.
It starts with a discussion of "combat story", where the designer plots the conflict over time. Does the encounter start with an idea of impossible odds, or does it start from a position of safety that gradually escalates into danger, etc? The speakers borrow design strategies from pro wrestling choreography, likening concepts like "babyface" and "heel turn" to plotting the arc of your encounter. Think about how the balance of power shifts in martial arts movies like Police Story, and that's the model for you to plot your combat beats.
To implement those different beats, you manipulate the enemy's positioning and tactical possibilities. How much room does the enemy have to move or to flank? Does the "no man's land" help the enemies break line of sight? Is the enemy spawn protected or vulnerable? All these different affordances and factors, along with the mix of enemy types and composition, help you pace the difficulty of the battle.
Overall, this is just a strong primer to ideas of line of sight, elevation, low cover vs high cover, and general combat arena design for shooter games. But for me, the larger takeaway here is the talk's use of military terminology. Enfilade / defilade are just fancy French words for flanking, but when we connect it to a real world historical study of flanking, then maybe encounter designers can advance their craft and share more of a common language.
Here's a more recent talk about Uncharted's encounter design tools, and it's probably the best intermediate-level encounter design talk about contemporary AAA encounter design today.
Yet again, this talk is aimed more at the AI and tools programmers who would be building these behaviors, and it's less for the level designers and scripters blocking out the combat arenas. It's the same problem that encounter design has had since 2002: every game has its own set of enemies, tools, and terminology for building encounters. It's difficult to reason generically about "best practices for battles" since every game has different goals for its battles.
Still, we can try to extract some useful general concepts about encounter design workflow:
Battle lines will constantly shift as the player moves around. For large non-linear arenas it's best to let an "encounter coordinator" AI director dynamically figure out the battle lines and assign NPC roles, instead of trying to pre-place or pre-script too much about the battle.
Break your combat arenas into high-level "hard points" / "zones" to anchor different Pac-man style NPC roles ("engagers" rush towards player, "ambushers" hide in a zone near the player, "defenders" stay in high value zones)
For dynamic stealth encounters, level designers can place short patrol path loops that feel human (smooth line of motion, centralized around a location or zone) and then the encounter coordinator AI can dispatch NPCs to these pre-built patrol paths.
Generate more granular hint nodes / "posts" during navmesh generation, but don't try to procedurally generate too much. Connectivity graphs and heatmap searches seemed like good ideas early in Uncharted 4 development, but to playtesters, these systems just felt like AI blackboxes without any predictable human tendencies.
Reaction against military realism and cover shooters, nostalgia for monster placement era
Push Forward Combat in Doom 2016
Prodeus?
Educators: if you're assigning this design exercise in a class, we strongly recommend assigning the same game for everyone -- either Doom or Quake.
If you are new to first person shooters or usually dislike these games, choose Doom or Doom 2.
If you are interested in the hardcore technical details of shooter design, then study Quake.
. We recommend the QuakeSpasm source port, and no graphics mods.
Chances are, you haven't played any of these games recently, if ever. For better or worse, these are iconic key games that deeply influenced the game industry forever. You should probably learn why.
For the purposes of this exercise, you need to play at least 5-10 levels, to the extent that you will recognize most of the weapons and monsters, which will probably take at least an hour. Play enough so that you can talk about it, and it's OK to use cheats or play on easy mode -- we're here to study the design, not to prove gamer skills.
To activate invulnerability in Doom, type IDDQD.
To activate god mode in Quake, open the console with ~ (tilde), type god, and press enter.
Both Doom and Quake have been, as academics say, "well theorized." There's been lots of design analysis and criticism written about both games over the past few decades. Being a game designer means interacting with this legacy and joining the conversation.
If you played Doom or Doom 2, read the short essay "Coelacanth: Lessons from Doom" by JP LeBreton, industry level designer on BioShock and Psychonauts 2. Then reflect on these questions:
LeBreton references a 1982 arcade game called Robotron 2084. Is it really that similar to Doom? You can decide for yourself and play Robotron for free in your browser at Archive.org (click the button to start the emulator, and when you see the "Factory Settings Restored" screen press F2).
After you've played Robotron for at least 15 minutes, compare it to Doom. Are the controls similar? What about the weapons, the enemies, and of course, the level design?
LeBreton argues that Doom's "weapon design is strongly orthogonal." What do you think he means by that? Give an example of orthogonality in a different game.
Why is the essay titled "Coelacanth"? (Google it.) According to LeBreton, what do modern FPS games do, and how does he feel about them? Do you agree or disagree, why or why not?
If you played Quake, read the changelog for the Quake mod "Copper" by Matthew Breit, industry level designer on Quake 4, Titanfall, and The Beginner's Guide. Then reflect on these questions:
Explain Breit's tweak to the Ogre grenade aiming formula, and summarize why he thinks it is necessary. What are the possible arguments against this new behavior?
Google how player armor in Quake works. What is the armor damage mitigation formula, and what is Breit's critique and fix for it? Do you agree?
What were Breit's design pillars for Copper? Who is Breit's audience for the mod and this changelog post? How does this audience differ from modern FPS audiences today?
Of the levels you played for either Doom or Quake, which was your favorite, and why?
Describe one weapon and player tactic that is effective against one monster type, but ineffective against a different monster type. Why?
Identify two different monsters that are interesting to fight in the same room, and two monster types that don't seem to work well together.
Breit notes that "very few things in Quake's game code (or, for that matter, Doom's) changed with [difficulty] level." Why do you think that is?
Both Doom and Quake feature a secondary mechanic called "in-fighting", where a monster can accidentally attack another monster, causing them to fight each other. Which monster type seems to be the best suited for causing in-fighting?
OK, time to do some level design. Your task is to design a one room arena for Doom or Quake. It must include:
2-3 types of monsters
1-2 weapons
1-2 minutes of gameplay
Sketch 10+ small parti thumbnails. (1-2 min) Conceptualize the big idea behind your arena. Don't overthink it, just draw any shapes that might symbolize how the level would play out. What type of combat do you want to pursue? Which weapons and monsters will be there?
Then sketch a 3+ possible layouts for a one room arena. (5 min each) For the purposes of this exercise, do not try to build a big huge elaborate level. Instead, focus on making just one room interesting enough.
Then, pick your favorite layout, and rethink it. (5-10 min) Keep your layout loose and don't try to lock it down so fast. Make at least one big change. What if you used a different monster type? What if you replaced the boxy room with a cylindrical room?
This drawing should have a little bit more detail, and you should definitely label it and explain more of your concept. It should answer these basic questions:
Write 1 player experience goal for the encounter. What kind of combat or tactics will your encounter emphasize? What will encourage full use of the combat space?
Are there any breadcrumb trails with health or ammo pickups to help motivate the player to move around the arena?
Will you use any locked doors or keys to gate the player's progress?
Label core elements like player and enemy spawns, items, hazards, etc. and highlight a critical path.
(TODO: show some one room arena encounter sketch samples)
Pitch your design to someone else, and have them use the rubric below to judge your pitch based on the (a) experience goal, (b) supported play styles, and (c) clarity of plan. For example. they might say your experience goal felt memorable, but doesn't really support any clear paths or strategies, and too many questions remain unanswered.
In your pitch, make sure you narrate different ways how the combat encounter would likely play out, while summarizing your intent and the player experience. Good luck!
Evaluation
Experience goal
Supported play styles
Clarity of plan
😄
Memorable, cohesive
Multiple robust strategies
Can visualize it all
🙂
Typical, predictable
One ideal path with side paths
Need to clarify details
😕
Try to implement your design plan within the actual game.
Before you begin a blockout, make sure you understand the metrics for the game. For your convenience, we have gathered the basic metrics for Doom and Quake:
Now it's time to open a level editor, and blockout a simple one room arena with monsters and weapons.
If you're new to level design and construction, we recommend starting with Doom because the editor uses a simpler 2D interface.
If you want to use something more complicated to learn, you can try to build in full 3D for Quake.
See the Tools page for links to Doom and Quake resources.
You don't have to follow your plan from the Layout phase exactly, but use your sketch as a general guide while you Blockout and Iterate. When you playtest you will probably realize your plan didn't work out the way you imagined, and you'll have to change your plan -- and that's OK, that's what level design is all about.
Remember the original brief and keep it small, especially if this is your first ever level. Do not make an arena more than ~1024 units wide, and do not spend more than a few hours.
The purpose of the blockout phase is to test metrics and gameplay. Use prototyping textures, and do not waste time on decoration or lighting.
Monsters don't really have true pathfinding, so keep areas somewhat open to give them enough space to wander. Your hallways, if any, should be 128+ units wide.
To confine a monster to an area, build a height difference into the floor. It is useful to "leash" monsters with ranged attacks (Imps in Doom, Enforcers and Ogres in Quake) by placing them on a raised platform that is too tall for them to descend.
First, playtest the level yourself. Can you complete your own level? If you cannot, then it is probably way too difficult for the average player.
After the level passes your personal playtests, go on and playtest with at least 3 different people.
For info on how to find playtesters or run a playtest session, see Playtesting.
As you run the playtest, ask yourself:
Can the average complete your level without any guidance or intervention?
How many times did each player die and restart? Zero deaths might mean it is too easy, a couple deaths mean the arena is appropriately challenging, and 10+ deaths might mean it is too difficult and most players would likely give up.
Our goal was 1-2 minutes of gameplay. If the fight is always over in a minute or less, that's too quick. If the fight usually takes 5 minutes or more, that's way too much.
The whole point of playtesting is to iterate and make changes based on the feedback. If you do nothing in response to a testing session, then arguably you are not doing design. It is always possible to improve something.
Make at least one change to your level geometry. Rebuild a room, add an extra platform, extend a hallway, carve a new doorway. No level is perfect.
Make at least one change to your monster or item placement. What if you tried a different monster type? If you changed your level geometry, does this new floor / wall / room accommodate a new monster? What if you offered the player a different weapon against that monster?
Add one secret, like a hidden weapon or item. It can be tucked away in a corner, or it can sit behind a secret door that looks like a wall. What would be satisfying to discover? What kind of secret would feel fair and appropriate to the rest of the level?
Congratulations, you just built a classic first person shooter level! You have followed the tradition of countless level designers and modders before you.
Take some time to reflect on your experience. What parts of the design process did you enjoy? How will that influence your creative process in the future?
Feeling
Research
Layout + Pitch
Blockout
Playtesting
😄
Research was very useful and relevant.
I enjoyed discussing plans.
I love building a space and walking in it.
I love to see others play my work.
🙂
Research was OK I guess, I see the point.
It was helpful to communicate.
Building a space was OK, but a lot of work.
Repeat this project, make another Doom or Quake level.
Try some other projects.
Read about the History of encounter design.
4
Brawl
To keep it readable, make two factions fight each other in a 2v2.
5+
Slaughter
Chaotic free for all. Exciting at first, but player inevitably focuses on a small subset.

































Confusing, incompatible
No clear path or strategy
Too many questions
A little playtesting is useful. A little.
😕
I don't like doing research and it has no purpose.
I'd rather not share my plans with anyone.
Building was boring and time-consuming.
Playtests make me anxious and scared.



Objectives, triggers, puzzles
Level designers use scripting tools to program specific game rules and behaviors for a level. Some common examples of level scripting include:
Objectives, quests, missions -- a sequence of goals and encounters with a start and end
Triggers execute logic when entering an area, to lose health or gain points, etc.
Gates block progress until the player solves a problem in the game world somehow
Game objects / entities that move or react, like buttons, doors, elevators, trains, traps, etc.
(visual scripting example)
In past generations of game engines, there was a big technical difference between the game engine code vs. the scripting logic in a game level.
For example, Quake 1's game engine idTech2 was written in C / QuakeC, but level scripters relied on premade entities with narrow predefined behavior. A func_button entity could only function as a button, and a func_door entity could only work as a sliding object. If a designer built the door as a flat platform that "opened" upwards, then the door was basically an elevator; these resourceful hacks were necessary because level designers could not easily code new types of entities. Entities were level-specific visual scripting logic that existed as data interpreted by the game engine.
For modern game engines, scripting has become increasingly textual and code-like. Unreal Engine 4's Blueprint visual scripts match C++ functionality, Unity's Playmaker / Bolt visual scripts match the C# API, Fallout 4 / Skyrim scripters use a Papyrus language, and other engines routinely embed Lua. It's all basically code now.
So: a level script is simply a coded behavior limited to the scope of a game level. Scripts usually interact with specific objects or places in the map, binding to specific entities. They have limited functionality outside of this map or across different maps. Think of it as "softer" code unique to a given level, compared to the "harder" core game code shared by all levels across an entire game.
A scripting hack is a one-off brittle solution that uses a game system in a way that wasn't intended, and thus cannot support a wider range of behavior nor be easily reused elsewhere in the game.
For example, in Fallout 3's Broken Steel DLC, the player fixes and rides a metro train during a mission. However, the game does not have any actual vehicle or train system. Instead, . Via script, the game forces the player to secretly equip an inventory item called "DLC03MetroCarArmor" -- an armband that executes a camera script that makes the player feel as if they're on a moving train. In Fallout 3's GECK game editor tool, the armband looks like a giant train-shaped hat. (see image below)
This scripting hack may seem absurd, but it works, and it saved the developers a lot of time from needlessly engineering a complex feature. So sometimes hacks are appropriate, but you can only decide on a hack like this when you have done enough for your project scope. Here, the Bethesda designers had planned their DLC and they knew there was no point in coding a train system they would never use again, so instead they hacked a fake train and successfully shipped their project.
quests, missions... usually made of triggers and gates
Branching flags model
Fallout / Skyrim numbered quest stages (FSM?)
visualize as a flow chart, can get very complicated
triggers let us define volumes and areas, and apply behavior to those zones
triggers know when something enters, stays, and exits... a trigger is an EVENT
basic trigger is traps, deaths, lava, etc. or opens a door
for singleplayer, triggers should be invisible and seamless and magic, and sometimes just one-off triggers? ... dear esther, triggers used for ghosts and voice over...
complex triggers: dynamically resizing triggers like in Gone Home parents closet?
for multiplayer, triggers should NOT be invisible!!... bomb site areas in CS, capture points in Overwatch
see also: Gating,
A gate is something that impedes or blocks the player's movement through the level, usually along the critical path.
Despite their name, gates are not just doors. Almost anything in a level can function as a gate, because any obstacle that impedes progress or flow, either by a little or a lot, is a type of gate.
A hard gate is when progress is impossible without completing the encounter or puzzle. When we just say "gate", we usually mean a hard gate.
Kill all monsters / boss to open a door
Press all the buttons
Collect the key
Only the NPC can open the door, when they want to (e.g. out of combat)
Or chain all these together.... kill a monster to get a key, press a button to release a monster that drops a key, etc.
the player could bypass the gate without completing the encounter or puzzle, but they are heavily discouraged from doing so (e.g. too many monsters)
A bit more sophisticated and less hand-holdy, supports speed runners better... but might cause a cascade of confusion if player keeps bypassing gates without realizing, isn't sure what's happening, or the gate might be so soft that it doesn't even do anything
(very soft) blocked sightline, hairpin turn (see typology)
(soft) simple traversal / jumping puzzle, stacking boxes
(softish) Valve-style slowly opening door gate
(ranges from soft to game breaking) confusing layout, unclear how to progress (might end up feeling bad-confusing instead of good-confusing though)
monster closets
director AIs
pathfinding nodes, monsterjump, cover nodes, clip volumes, leashing
Cover hinting for NPCs and AI
"The tall red boxes are standing cover (otherwise known as “full” cover, providing the most protection) and the smaller pink boxes are low cover (half-cover in-game). The yellow targets on each cover node show which angles a soldier can shoot from when placed in that cover node. The yellow curved arrows above some of the low cover nodes show that a soldier can vault over the cover node into a node on the adjacent side. Careful placement of cover nodes and strict adherence to the metrics is essential to create a clean, bug-free cover setup that works as players expect it to. If a piece of cover is too high then you will not be able to vault over it, and if a cover node isn’t placed correctly at a corner then the soldier occupying that node will be unable to shoot around the corner. Both of these examples create frustration for the player and must be avoided!"
-- from Splash Damage blog post
many combat games also automatically generate markup and fine-tune by hand (e.g. Uncharted 4)
When we script NPCs to perform specific actions outside the scope of their normal AI, especially for in-game cutscenes and , then that type of scripting is called choreography. On large team projects, character choreography could be the responsibility of a scripter, animator, or dedicated cinematics artist.
Common choreography scripting actions include:
NPC actor body control like looking, turning, walking, talking. This choreography should hook into the same body systems as the main game AI, i.e. maintaining two different walking systems would introduce extra technical debt into your project.
Animation control. Overriding the default idle stance or the current full-body animation completely. For example, if two actors hug once in your game, you should not engineer a dedicated hugging system -- instead, you should just temporarily override their animations with hugging motions.
Props and attachments. Temporarily bind an object to a character joint, like attaching a hat to a head, or a cup to a hand.
Taylor Swope, QA lead for Obsidian RPG "The Outer Worlds" (2019), spent a long time trying to debug an NPC object interaction scripting issue
We released [...] a fix for the dreaded "the game thinks my companions are dead" bug, which I believe I spent more time investigating than I have for any other individual bug in my career.
The gist of the bug was that, for some players, a companion quest would be marked as Failed in the quest log, with the reasoning that the companion was dead -- despite the fact that the companion was very much alive and well. One reason it was so hard to pin down is that it was impossible to tell when the bug actually happened -- all of the cases we had were essentially "hey something bad happened in the last ten hours and now my quest is broken".
Investigating it involved figuring out the location of every script and line of code that could possibly make the game think that a companion was dead. The only logical culprit was a bit of scripting that runs when a companion's health reaches zero: if they're in the party, it waits for combat to end and revives them; otherwise it marks them as dead "for real". [But] the only place in the game when a companion is present but not in the active party is when the player is on their ship. The problem is, when companions are on the ship, they are undamageable. Eventually we figured out that "undamageable" does not mean "invulnerable" -- they can't take damage from attacks but can still get hurt from other things. One of those things: falling a great distance.
The problem with that is that there are no spots in the player's ship that are high enough to result in a lethal fall. So now we had to figure out how companions were mysteriously ending up way above the level. I looked into tons of theories, including "maybe their height data is preserved when fast travelling from other maps" and "maybe a physics interaction between two companions causes one to rapidly accelerate upwards". (My personal fav was "what if a companion is standing right where a cow spawns in during a random event and they're launched into space". Was genuinely bummed when that theory didn't pan out.) By this time, the game had come out, and all hopes of this being a weird fluke only a couple devs would ever see were dashed, as players all over the place started reporting their companion quests failing.
Game engines tend to have visual track-based timeline tools for choreography like (Unity) or (UE4). Scripters and animators setup different tracks and place events on each track. This way, the game can import the choreography as a game asset instead of code, which avoids any time-consuming re-compiles and simplifying the codebase.
Large projects with many conversational cutscenes (like RPGs) usually rely on semi-automated workflows for scripting their choreography. Their tools automatically generate basic cutscene scripts for every conversation, because it is not feasible to handcraft hundreds (or thousands) of short cutscenes. Then scripters and animators polish the most important scenes with additional choreography, and QA testers report any broken low priority choreography that needs specific attention. Voice over heavy projects will also need to adjust scene timing for every voiced language, and games with day-night cycles should automatically override global lighting with better setups for cutscenes and close-ups.
If your project doesn't have or need specialized choreography tools, then it is still possible to choreograph directly with gameplay scripting code. Use something like (Unity C#) or (Unity Bolt) or / nodes (UE4 BP) to call functions in sequence with your desired timing. This direct method is useful when you need full access to all scripting functions as part of your choreography. Imagine choreographing 100 NPCs walking through a door one-at-a-time; this task would be slow painful tedious work in a visual tool, but trivial in a scripting language with for() loops and arrays.
For their large open world RPG The Witcher 3 (2015), developers CD Projekt Red divided their quest workflow into four phases: (1) Writing the script and choices with a screenplay format, (2) Quest scripting the possible branches and game states in a visual scripting flowchart tool, (3) Dialogue and choreography with preliminary auto-generation pass, and (4) Post Production with fixes and visual polish for cutscenes.
The dialogue designer tool's automatic cutscene generator is especially interesting here. It takes the voice over audio and automatically generates tracks and timings for actors, with semi-randomized animation variations and standard camera shots that follow basic cinematography patterns like shot-reverse-shot and 180 degree rule. The result is a basic starting point for a cutscene that is already mostly done, allowing the choreographer to focus more on adding details and mood rather than boring rote work to setup fundamentals.
While the weaknesses of this method weren't really mentioned in , we can imagine the main drawback here is that it requires you to finalize and systematize much of your script, voice over recordings, and animation set in order to feed it into the generator. Without tagged audio assets and near-finished characters, it would be difficult for the generator to understand what to do. As with any procedural generation system, it is heavily dependent on its inputs, and without good meaningful input it will just result in the "."
Other interesting details about CDPR's choreography workflow:
The game was scripted and choreographed in English, but the length of the voice over audio would obviously vary with each language. So for every localization, the choreography and camera shot sequences are automatically sped-up or slowed-down; for example, French choreography runs 16% slower than English.
To stop NPCs and wildlife from interrupting cutscenes, choreographers blocked out an invisible collision box / clipping trigger volume / "deny area" to push non-choreographed characters away and keep the camera shot clear.
Scripting is a creative problem-solving task that is similar to any other level design task. First you want to understand the problem, and then you want to try various approaches.
Do a little planning and research.
Prototype the most basic version and playtest.
Gradually iterate and elaborate on the script until it meets your needs.
As with any creative task, a little bit of planning helps a lot. Before you open the scripting editor, take a few minutes to define what you want your script to do. Some examples of planning documents:
Scripting a mission? Draw a flowchart and markup a drawing with the mission locations.
Scripting an object or behavior? Sketch how it should look and its various states / properties.
Scripting a fight or encounter? Do some first.
Next, research various ways of implementing the feature by googling. When googling for programming or technical scripting help, make sure to:
Be technically specific. Include the game or engine name, as well as the scripting language. Surround both in quotation marks to require these terms in the search results.
Be conceptually general. Describe the desired behavior in generic terms. For more complicated features, break the problem into smaller simpler parts and google separately.
Some examples of search terms:
😢how to code a ceiling fan is vague in the worst way (which code language?) and specific in the worst way (you're hoping someone else has specifically built a virtual ceiling fan)
😎"unity" "c#" spinning object code is technically specific (we only want Unity C# code) and helpfully generalizing (a ceiling fan is a type of spinning thing) and we can extrapolate from the generic example for our specific use case
When to ask for help. Unless you're totally lost, avoid asking other people for help at this very early stage. Try to do it yourself with what you've found already, and see how far you get. Asking someone else works better when you have more specific questions or have some existing scripts to troubleshoot. To get a useful answer, you must first understand the problem.
After you've done some searches, you now have a better understanding of the problem and you are ready to prototype the feature in the scripting tool.
ask community members for advice. Join an engine-specific forum, website, or Discord, and ask your question. If possible, recap the research you've already done and include any error messages. Here's an example question you could post:
"I'm trying to make a working carnival carousel. I found this C# code to make an object spin (link) but I when I try
Usually involves a trigger to spawn / aggro enemies, and a gate to force the player to deal with enemies
Before you begin scripting:
do some encounter design on paper. Have a plan before you open the editor, even a basic plan. what weapons or abilities will the player have for this encounter?
know your combat metrics. What are the ideal enemy engagement distances? is the blockout too big or too small?
Then, place some AIs / NPCs / enemies and start playing with them
how does the NPC react to the existing space? do they do anything you want to prevent with hinting?
what tools are available to you? static vs. scripted vs. dynamic?
Scripts are level-specific behaviors designed with a lightweight programming language, often with an engine-specific visual programming tool.
Common features to script include objectives, choreography, triggers, gates, and AI.
Scripting is important for and .
After you've scripted your main beats, you may want to perform a pass on the .
Most mature game engines have visual scripting tools. Unity uses , Unreal Engine 4 uses , and Godot has . See for a full list of games and their scripting tools.
Intro to scripting for Unreal: , November 2021.
is a Tumblr archive of messy / hacky visual programming graphs authored in Unreal Engine 4's Blueprint system. It's fun but also a bit melodramatic; sometimes shipping an inefficient script makes more sense than engineering a time-consuming "better" design. If a cleaner method is 0.0001 ms faster but took twice as long to make, then it's arguably not a better script.























How to plan and sculpt 3D terrain for level design; painting, planting
Honestly there's not much existing theory or documented knowledge about level design and landscapes. Environment artists tend to work at a small scale with limited portfolio piece scenes, while level designers focus on buildings. When you look for tutorials or guides on this topic, almost everything will focus on engine-specific sculpting tools and geological simulation tools -- and nothing about the actual act of designing the terrain. Our existing design theory has basically neglected the landscape, which feels foolish when so much modern shooter, open world, and multiplayer design happens in landscapes.
Unfortunately, real world landscape architecture provides only limited insight for level designers. The landscape architect must account for surrounding ecology, climate, hydrology, soil chemistry, archeological mitigation, land rights, building codes... these are interesting factors to consider for worldbuilding, but definitely out of scope when you're just trying to blockout some basic level geometry.
player navigation, how to "guide" the player through a level
Wayfinding is when a player finds where they are in the level (orientation) and/or finds a route toward their destination (navigation).
Most level designers aim for players to wayfind their way through the game world "naturally" in an "immersive" mood with minimal disorientation or frustration, while coinciding with the designer's intended (s). This style balances naturalism and plausibility with subtlety. But more often, the goal is the performance of false subtlety -- helpful details that seem subtle (to someone, somewhere?) but are actually very obvious to most players.
(video embed?)
Planning various activities and events for the player to experience during a level
Pacing is the general order and rhythm of activities and events in a level.
Single player levels tend to require strong pacing. If players are confused about what is happening or what they can do in a level, then that may indicate a pacing problem.
An effective pacing plan should address:
















Timing delays. Waiting for X seconds, useful for dramatic pacing or pauses.
Camera control. Force a first person controller to look at something, or spawn additional third person cameras with other camera angles or cinematography.
Game state management. For systemic or combat-oriented games, it is best practice to disable the choreographed actors' combat AI and physics, as well as pause / block / delete nearby enemies and make the choreographed NPCs temporarily invincible. If you don't manage and clean the game state for the choreography, then your actors could unexpectedly collapse or die during the cutscene.
Eventually, an offhand comment in one user's review mentioned seeing a weird bug where a companion was "climbing nothing", and this comment led me to figuring the whole thing out.
On the dev side of things, the system for NPCs interacting with the environment is called "furniture". Sometimes this is literal furniture, like sitting in a chair, but it covers everything from using a terminal to leaning on a wall. Somewhere deep in the complex beast that is the furniture system, we had code that disabled all NPCs from starting new furniture interactions if the player was in a conversation.
The problem was that using a ladder is considered two different furniture interactions: one for getting on the ladder and starting to climb, and one to stop climbing and get off. So, if someone started climbing a ladder and the player entered a conversation before they stopped, they wouldn't be able to exit the ladder, and, well…. -- Taylor Swope (@_taylorswope) https://twitter.com/_taylorswope/status/1205252714680045568
game dev scripting objectives system will maybe tell you someone's opinion about how to architect an objectives system, but without any specific help. What type of game objective do you want to script, exactly? No search engine can design your gameplay for you.What if we breakdown this problem into simpler and more specific steps, and google for these smaller steps separately?
😎 "ue4" "blueprint" display text on screen helps us figure out how to notify the player about an objective
😎 "ue4" "blueprint" player enters trigger helps us learn how to detect when the objective is completed, when the player has reached a certain location in the level, etc.
When googling, include the engine name and search with generic terms.
For short term small projects (< 1 month) the simplest and fastest hack could be good enough.
For long term big projects (6+ months) a more stable systemic method is better.
Landscapes are made of rock, dirt, and sand, gradually worn down by wind or water (erosion).
When the tectonic plates along the Earth's crust interact, they often push rock upward (tectonic uplift) and form a variety of mountains. When warm air rises and pushes clouds toward the top of a mountain, the higher altitude and lower air pressure causes the clouds to rain. That rain water flows back down the mountain, forming rivers and valleys. That rain stays on the windward side of the mountain range, while the other downwind side (leeward) loses moisture to the hotter air and thus stays relatively dry and arid (rain shadow).
On taller mountain ranges, there is often a prominent tree line that marks where trees can no longer grow because it is too dry, cold, or windy. Above the tree line, the mountain rock is clearly exposed with occasional bushes / plants, or heavy snowpack in the winter.
To design a plausible naturalistic landscape, consider how various type(s) of rock, erosion, and climate will shape the terrain. Then consider how the local inhabitants responded to that terrain.
Water flows downward and curves around obstacles. That means rivers curve a lot, which also means mountains and valleys curve a lot.
... so roads and paths should curve around as well, since humans must follow terrain. Straight flat highways and roads are relatively modern, and imply a powerful industrial society that can devote (or waste?) resources to grading roads.
Vegetation holds dirt in place. Trees with deep roots are especially good at resisting erosion and blocking wind. Forests act as windbreaks, which means there can be different biomes on the windward / leeward side of a forest.
Elevation changes affect wind and water patterns. If your level features mountains, should the biome be the same on both the windward / leeward
People have been sculpting for thousands of years, so there's a lot of theory about how to sculpt, and it's a topic that deserves its own book. Here we're going to focus on the basics of sculpting as they relate to sculpting terrain in a game engine:
Layout: draw a simple diagram of the landscape with labels. What are the different biomes and microclimates? Which areas are most important?
Blockout: sculpt rough shapes for the landscape, with attention to flow and scale. How big is each valley, hill, mountain, or canyon? Is it high or low, long or short, sharp or smooth?
Metrics: measure travel times, heights, and traversable ramps / slopes. Is it clear where the player can go? Do locations feel too close or too far?
: sculpt and paint smaller details, apply set dressing. Does this space have a clear mood? Does it feel lived-in or plausible? "Finished"... or empty?
After each stage, we of course strongly recommend playtesting. When playtesting, check for:
Areas that feel too big, routes that feel too long or too annoying
Blocked areas that shoudn't be blocked, unclimbable slopes that look climbable
Game breakers where the player can get stuck or fall into a crevice
First, draw a layout to plan the landscape. Shade regions according to their theme and local climate. Label and highlight prominent areas. Your landscape layout drawing should be able to answer these questions:
What are the biggest areas, which areas need to be next to each other?
What is the theme of each area, and how does it relate to adjacent areas?
What types of art assets will each area need?
In the example layout drawings below from World of Warcraft, note how the dev team began with a simple bubble diagram to begin solving the spatial relationships. As they spent months / year iterating on the level, the final landmass retained similar organization but resulted in very different sizes and shapes. The "Highmaul" area in the top-left roughly tripled in size, the flood plains halved, and the beach expanded into a harbor. Plan to deviate from your plan.
Also note the clear regional color coding (brown = impassable mountain, yellow = arid, green = temperate, dark green = wet) and how it conveys the overall spatial hierarchy. The top-third is a wet area north of the river, the middle third is a temperate valley, and the bottom third is an arid mountain range.
Site planning
Where does the player start and what is the critical path, if any? What's the primary and secondary circulation through each zone, and between zones?
Does the massing feel small and cozy, or narrow and claustrophobic? What is the spatial identity of each area in the overall composition?
Define the palette of big recurring shapes and objects common in this area (e.g. a house; a tree) and include their placeholders in the blockout.
For big development teams like Blizzard that need to coordinate production across multiple departments, this blockout phase is also a good time to do research and planning with environment artists:
"Working with an environment artist, the level designer will help to guide and define the scope of environment assets needed. These assets include terrain textures, trees, bushes, accent plants, rocks, etc. The range of models and textures needed must address not only the main zone look, but the sub environment types needed to break up the zone, all the while bringing the concept to life while remaining within the capabilities of our game engine. It can be a challenge, and often is.
Take for example the new Nagrand. Not only do we have the environment that you know of as the Nagrand from Outland, but new areas, like a wetlands, and a higher elevation arid region. The visual clash of these disparate environmental themes could be quite jarring if not handled with care. There is a constant conversation between the level designer and the environment artist about shape language, color, diversity, scale, mood, model usage, and ultimately the visual tone of the zone as a whole that keeps the zone development moving in the right direction." -- Ely Cannon, senior level designer on World of Warcraft, from "Artcraft - Level Design part 3"
Now is a good time to think about balance... shallow slopes vs deep slopes, thin ledges vs thick ledges
Include generous space for landings at the top and bottom of ramps / stairs, or else players might overshoot and jump off a ledge
Is this walkable area readable, are the boundaries clear? Can the player survive a fall from __ height, can they walk up this __ degree slope?
Travel time, where is the nearest fast travel point
Refine shapes and overall composition and add some details (grass, plants, rocks). Is the silhouette, geology, and erosion pattern plausible or consistent? Work on lighting, mood, and color palette. Does each sub-region feel distinct and readable?
Unity extra terrain tools: https://docs.unity3d.com/Packages/[email protected]/manual/index.html
Unity Path Paint tool: https://github.com/Roland09/PathPaintTool
You should still be making big changes to the terrain btw, and each time you do, repeat step 2 and 3
Handpainting grass and flowers is time-consuming, and if you ever redo your art then you'll just have to paint everything all over again.
The most common method is to define biomes, thematic palettes of foliage and textures that automatically decorate a landscape. Then the terrain system can automatically decorate itself by procedurally generating the details.
Big AAA open world games invest a lot of in tools, scripting, and environment art to automate their landscape art passing workflows like this. It usually isn't practical to do this unless you're making a big project with a team.
Use "set height" brush to layout floor planes and terraces
Your general sculpting workflow will be: (1) add or subtract mass, (2) smooth, (3) repeat forever
To define a slope, sculpt terraced "steps" and then smooth over. For narrow ledge ramps along the side of a mountain or canyon, a dedicated ramp tool is probably easier.
Don't oversmooth, don't leave everything a blobby melted mess... sharpen and crease, define shapes
For each region, start with 3-4 basic materials and shades.
Paint with consistency. Don't reuse a cliff material as a ground material.
Do the big basic flat sculpt first, then switch to increasingly smaller brushes to smooth over slopes and add minor height variations to the floor plane.
Avoid using erosion brushes for blockout... these can't do level design for you!! These are for detailing your level later in the design process
Plateaus are raised landforms with flat tops. Terraces are flat surfaces cut from a slope.
Craters are big deep holes in the landscape. Bowls are shallow holes in the landscape, and hollows are smaller bowls. Think of them as negative plateaus which can also be terraced. Descending into these surface depressions can offer a sense of safety, or perhaps a sense of being trapped.
In real-life, terraced bowls make for fantastic naturalistic amphitheaters that focus sound and provide a big comfortable gathering place. Conversely, a small hollow can offer a sense of closeness and intimacy. In games, bowls are most often deployed as artillery craters in battlefields to offer low shallow cover -- which, we suppose, is its own form of closeness and intimacy.
Combining a plateau with a crater produces a unique volcano-like effect that could also double as a sort of shelter or hideout (above, top-left)
Axial paths are straight, angular, and efficient, associated with human power and control.
Meandering paths are curved, round, and inefficient, associated with nature and leisure. pg 91
Paths respond to constraints:
Users. Who made this path, and who is using this path today?
Topography. Paths usually follow the curve of the landscape or shoreline. Cutting into the landscape or tunneling is a lot of work.
Vegetation. Paths usually go around large trees or dense vegetation. Clearing land is a lot of work.
Sharply painted paths with hard materials imply maintenance. Disused / occasional paths with soft materials blur and dissolve.
TODO: Breath of the Wild "triangle composition"
TODO: find BotW screenshots that matches both diagrams
Ledge paths are open on one side, closed on other. Common for hiking trails on mountains and canyons. Useful for suggesting scenic views, or offering a pleasant contrast between open view vs. closed enclosure.
Cuttings are enclosed on both sides, usually "cut" through a landform or with retaining walls. It can feel safe and relaxing on a sunny day, or damp and mysterious on a cold dark night.
Ridge paths are open on both sides and raised up. Common for big open wetland areas, offers a big sweeping exhilarating view if there's enough height.
Switchbacks or zig zag paths go back and forth with periodic stopping places to control your pace. Not naturally occurring, but often used on steep hiking trails to make ascent (or descent) safer.
A landscape is more than the landmass and terrain, it's also about the overall climate, ecology, and vegetation. Landscape architects work heavily with gardening and plantings.
Every video game landscape is a garden, intentionally shaped to facilitate an aesthetic or mood. Video games expect us to suspend disbelief and pretend that diegetically, within the fiction of the game world, that these are untouched wild places. This is a fun lie we reserve for players, but as designers, we should never be taken in by our own lies.
Do research on your desired climate
An ecotone is a boundary where two different ecologies meet. It can be sharp or blurred.
Trees are basically walls that you can walk through; they enclose spaces through repetition and verticality.
thin enclosure (french garden) vs thick enclosure (a glade in the middle of a forest)
Tree planting: natural or artificial? Artificial: quincunx, formalized forest (pg, 65)
Vary plantings by height
Complex planting: understand humidity, wind, rain shadows, etc
Alba: A Wildlife Adventure is a 3D open world exploration game about environmentalism and bird watching, set on a Spanish island called Pinar del Mar.
In her post "The Environment art of Alba: a Wildlife Adventure", environment artist Jessie van Aelst wrote a breakdown of her environmental design and development process.
Pre-production: early on, the team defined four pillars for the entire game -- care for nature, sense of Spain, human impact on natural world, and freedom of childhood.
Research: they went on virtual tours through Spain via Google Maps, and even went bird watching in real-life. They collected a lot of photo reference and assembled moodboards.
Blockout: they made an early version of the island with simple geometric shapes and flat colors, allowing them to quickly iterate and test game systems / characters -- once they had a better idea of the game, they later redesigned and rebuilt the island entirely.
For building up the landscape, ustwo developed a custom non-destructive terrain tool workflow in Unity.
For sculpting the main landscape topology, they used a custom Unity editor tool to place splines that procedurally painted onto the internal terrain heightmap at editor-time. This spline-based approach allows for a non-linear non-destructive workflow with smooth flowing shapes that they could fine-tune at will. A designer could also copy-and-paste large landmasses. And because each stroke is a separate game object, that also means multiple people could merge their landscape changes together relatively easily. (note from editor: I'm actually really impressed by this.)
Terrain splines have three brush modes: ridge (for hills and terraces), valley (for rivers and ponds), and level (for flattening / smoothing). The spline's stroke falloff is a user-adjustable AnimationCurve. It also has a built-in terracing curve, as well as a customizable noise modifier.
Each spline pushes / pulls the terrain in a certain way, and the accumulation of all these splines results in a complex landscape.
For texturing, the landscape uses a basic four channel splat (RGBA). Each color (red, green, blue, alpha) corresponds to a texture type -- dirt, clay, grass, and sand. The triplanar terrain shader also applies extra masks for splat transitions, and sets different textures based on world position / world normal.
"For each splat, we had a ruleset. Sand would only appear on certain low heights of the terrain. Dirt would come in as the next layer in the height as well as appear on really flat and even surfaces. Then it would transition into Grass, almost all areas of the game are grass unless the incline was so drastic it would then turn into cliff splat material." "After this pass was done we added some more detail maps to each splat. This means the gradient transitions between splats would now have a bit more detail. These maps really helped with stretching the bandwidth of our limited amount of terrain splats." -- env artist Jessie Van Aelst, from "The Environment art of Alba: a Wildlife Adventure"
They also implemented extra "terrain stamps" overrides, editor-only game objects that could project a specific splat color onto the underlying terrain. This allowed them to add additional details and paint roads / paths, mask out foliage, etc. In the GIF below, note that the last frame consists of hand-placed details, on top of the procedurally generated base.
The team divided the island into several distinct biomes, each with their own plant and animal populations. Artists configured different biome elements for procedurally generated detail scattering / set dressing.
We defined each biome with biome elements. Ex: a pine tree forest biome would include pine trees, pine cones and bush biome elements. The biome elements all have variant slots as well as variables indicating how likely each asset would spawn and what the scale ranges would be.
These biomes would then be placed onto the terrain in a similar fashion to the terrain manipulation. The marker would project cubes onto the terrain to indicate the area where it would generate a biome. The colour of these cubes would represent:
Yellow — area where biome generation happens. Green — an asset will be generated here. Red — an asset could spawn here but won’t because of restrictions
These colours were very useful for us to understand what to expect before generating the terrain. A requirement we came up with was to be able to move around the biome markers and keep the compositions inside intact. For example, a clump of trees that was spawned in just the right composition would spawn in the same composition even if we moved this biome to the other side of the island.
Biomes would generally overlap, so how do we make them work together? In order to overlap or put a biome inside another biome we worked out a system of prioritisation. The marker’s vertical position would therefore decide what would be overwritten.
-- env artist Jessie Van Aelst, from "The Environment art of Alba: a Wildlife Adventure"
Figure out metrics early, especially for landscapes. In most terrain tools, it is difficult to shrink / expand / move different parts of the terrain after the initial sculpt. Moving a mountain is trickier than moving a wall.
Sculpt a solid blockout first. Resist the urge to sculpt details.
Landscapes usually won't feel natural until after extensive art passing.
Narrative-focused landscape projects benefit greatly from .
World of Warcraft: Level Design Panel (Blizzcon 2016) features 30 minutes of level designers Matt Sanders and Ely Cannon sculpting, painting, planting, and set dressing small mountainous island zones in Blizzard's internal map editor for World of Warcraft.
Form and Fabric in Landscape Architecture by Catherine Dee
The Fundamentals of Landscape Architecture by Tim Waterman
Theory in Landscape Architecture: A Reader edited by Simon Swaffield
The Planting Design Handbook by Nick Robinson
Decades of industry level designer orthodoxy have claimed that the goal of level design is to manipulate / trick the player into "feeling smart" while "subconsciously" following the critical path... and to this, we say: no, stop! Can we quit thinking like this?
Deception is not a productive way to relate to players, and constitutes a false theory of mind for how players actually play:
Players often avoid the perceived critical path on purpose, to explore side areas and progress through the game at their own pace. In open world and multiplayer games, players crisscross the same space repeatedly and non-linearly, without one single static unchanging goal to always guide them towards. And then sometimes players just want to ignore gameplay and relax, hangout in a virtual space, spend time with friends, or even break the game and upload silly videos of goofs.
These are all valid ways to play. Let's move away from the weird (and creepy) prescriptive designer fantasy about secretly mind-controlling players into playing the way we want.
(image)
Instead, think of it this way: we are co-creating the game experience with players, and our goal is to provide tools and information to help them use our level.
Sometimes it's fun to stay on the critical path and sometimes it's fun to ignore it. Sometimes it's good to have a lot of information and sometimes it's better to have little information. Sometimes a narrow set of solutions can feel frustrating or artificial, and sometimes limiting options might result in a better experience.
We argue that player guidance is a flawed way to understand how people use levels and virtual spaces. "Guiding the player" fails to account for how players structure their own play. Meanwhile, wayfinding is standard terminology in architecture and usability design fields, and emphasizes the player's agency (way-FINDING) and active co-authoring of flow.
There's been a lot of research across architecture, environmental psychology, behavioral geography, and design, into how people navigate spaces. While humans obviously traverse virtual spaces differently from real world spaces, we hope / imagine the mental process is similar.
People form mental maps to conceptually represent a space.
Paths - the roads used to move around
Edges - roads which define the boundaries and breaks in continuity
Districts - areas which share similar characteristics
Nodes - strong intersection points of roads like squares or junctions
Landmarks - easily identifiable entities which are used for point-referencing, usually physical objects
short term vs long term memory
Dead reckoning / path integration is a method for guessing and tracking where you are when no landmarks are available. You can estimate your current position by (1) orienting your starting position, and (2) extrapolating along your movement direction, speed, and travel time. Sailors and flight navigators heavily relied on dead reckoning calculations before radio and satellite, and even your phone regularly uses motion sensors and dead reckoning to estimate its location -- but even without math or technology, humans and animals regularly use a loose intuitive sense of dead reckoning.
Kevin Lynch's Image of the City
Track following: to rely on directional signs on the road
Route following: to follow the rules given, such as a pre-planned route before the journey started
Educated seeking: to use past experiences to draw logical conclusions on where to go
Inference: to apply norms and expectations of where things are
Screening: to systematically search the area for a helpful clue, though there may well not be any
Aiming: to find a perceptible target and move in that specific direction
Map reading: to use portable or stationary maps and help the user locate themselves
Compassing: to navigate oneself with a figurative compass, such as the location of the sun or a landmark
Social navigation: to follow the crowd and learn from other people’s actions
Informational: These provide useful information on the place where the users are, such as free wifi, opening hours, etc.
Directional: As the name indicates, these direct users with arrows saying which way to go for whichever purpose. These most often at junctions when the user must make a decision about the route.
Identification: To help users recognize where they currently are, identification signs can be placed at the entrances of buildings, parks, etc. They symbolize the arrival to a destination.
Regulatory: These let people know what they can and cannot do in a given area and are most frequently phrased negatively with the aim of creating a safe environment. Examples include “no smoking” or “restricted area”.
For example, when players exit the introductory train station in Half-Life 2, they witness a dramatic city view with deep composition that highlights The Citadel tower at the center of the city. To get the player to notice this significant landmark, Valve level designers pointed the door frame outwards into the city square, accompanied by a flock of birds suddenly flying upwards.
This example highlights three guidelines for scene composition:
Players don’t look upwards unless something draws their eye.
Players look in the direction they are moving.
Players focus on contrast (in color, shape, lighting, and movement.)
Below is a table of various methods to convey navigation information to the player, starting from very subtle methods at the top, and descending to very obvious guidance methods toward the bottom. When possible, it's considered good practice to start at the top, and gradually incorporate less subtle methods in response to playtesting.
A wayfinding aid is anything that helps the player navigate where to go and how to understand the space.
Positive reinforcement, attract the player to approach.
Negative reinforcement, know where you can't go to understand where you can go.
We organized common wayfinding aids below by "% certainty" -- a non-scientific estimate of the proportion of players will likely perceive and use the aid.
Subtle wayfinding aids are best when overlaid as extra detail / polish with another more reliable wayfinding aid. Or alternatively, use solely these methods to make an area feel more unique or special for a small proportion of players (e.g. a very secret room). A vague nudge.
Method
Example
%
allegory
recreation or homage to an existing place, game, or level (e.g. the intro to The Beginner's Guide is an homage to de_dust)
1%
, architectural patterns
e.g. castles have dungeons at the bottom, and rich powerful people live deep in the middle / toward the back / at top... modern houses often have bedrooms with nearby en-suite bathrooms
4%
following NPCs
destination implied by following humanoid NPCs or ambient wildlife (e.g. birds in Half-Life 2, mote particles in Proteus, foxes in Skyrim)
7%
unusual detail
Coarse wayfinding methods rely on the player's prior knowledge or familiarity with common level design patterns. Common in "cinematic" or "immersive" games with an exploration fantasy. Use these methods to supplement a critical path, or to mark optional resources or secondary routes. A suggestion.
Method
Example
%
, sightlines
dense clusters of details to inspect up close, sparse skybox geometry to avoid, tall landmark in distance with wide sightline, window framing a specific view
35%
, color
path implied by light placement (Left 4 Dead), visibly lit entrances and exits, color contrasts (e.g. bright blue door in a dark orange landscape)
40%
in-world signage
in-world signs and placards; easily mistaken for irrelevant set dressing
40%
gamer tropes
Situational wayfinding methods will feel like the level designer strongly urging the player to follow a certain path or direction, but not forcing the player to do so. These methods include temporary camera control, situational UI pop-ups, direct threats and direct benefits for player progress. A heavy push.
Method
Example
%
friendly NPC directly leading the player (Half-Life 2), voiceover audio with directions, sudden explosion, etc.
70%
resources, items, breadcrumb trails
lines of collectible items or powerups (Donkey Kong Country), collectibles or powerups visible in the distance ("weenies"), a treasure chest, etc.
80%
cutscene
scripted cutaway camera shot that shows a newly unlocked door (Zelda)... assuming player is actually watching, and not just checking their phone or skipping through the cutscene
90%
dynamic world UI / HUD
Again, these methods cannot guarantee a specific behavior from the player.
For example, imagine a room with two exits, Exit #1 and Exit #2. There are many enemy NPCs in front of Exit #2. Will the player run toward these enemies to engage the enemies, and thus gravitate toward Exit #2 first? Or will the danger and threat of these enemies push the player away, towards Exit #1 instead? What if Exit #1 resembles a locked door, and the player has zero keys?
The intended "message" and resulting behavior will depend a lot on the player's current health and resources, prior encounters and patterns, overall level pacing, etc.
But here's what 93% of players will likely understand: those enemy NPCs were guarding Exit #2, and Exit #2 might be part of a critical path, and at some point the player may want to inspect Exit #2 more closely.
As close as you can get to telling the player "you can't go here." Static, always-on, permanent game elements that the player can trust unambiguously as the voice of the game designer. A thick solid opaque unbreakable wall is a great way to urge the player "don't go through this wall", because they literally cannot... unless the player is a speedrunner, or if the player is wallhugging to try to find secrets, etc.
Method
Example
%
static deep wide barriers
deep pits, canyons, lava, rivers, etc. that physically block movement without blocking line of sight, cannot be destroyed or bridged
95%
always-on global UI / HUD
objective marker (Call of Duty), objective arrow (BioShock), on-screen objective text, minimap with icons... sometimes it's OK to "give up"
97%
static hard barriers
walls, fences, fortifications that physically block movement and block line of sight, cannot be destroyed
98%
Note that some of these navigation aids are impossible to avoid, and some are even a bit beyond your control. That is because everything in the game is a wayfinding aid, and everything plays a role in guiding the player around the space. A wall makes a player to go around it; stairs promise another space above or below. Everything is information that the player takes in, all to varying degrees based on their mood, and none of it is foolproof. Like any other piece of information, these navigation aids can all be misunderstood, ignored, or overlooked.
We discuss some of these wayfinding aids in more detail below:
TODO: grab a slide from David Shaver's talk
CS:GO ironic bomb site signs... some graffiti is very subtle and not very effective probably
highly dependent on flow?... maybe put this in the flow or encounter section imo
Wayfinding is the practice of providing navigation aids for understanding the level layout. We urge level designers to reject notions of "guiding the player" -- instead, we argue that players play games in a variety of ways, and thus guide themselves. Strong wayfinding design help players construct mental maps to navigate and use a level more effectively.
Wayfinding signals a lot to players:
Show the player "what they're supposed to do", let them follow an intended authorial critical path to progress
Build trust with the player, promise the game world has been designed and remains readable with consistent navigation patterns
Demonstrate conventional craftsmanship and production value
But what if the player doesn't want to follow "what they're supposed to do"? Or what if you don't want to build trust with the player, or you don't care about conventional craft and best practices?
Heavy use of landmarking, signposting, and breadcrumbing, will make a level feel like Disneyland. In many cases, this sense of controlled fantasy / "architecture of reassurance" can be desirable. The fake forest and fake wilderness of a theme park is common and appropriate for the typical commercial action-adventure themed game.
However, if a true sense of wilderness is desired, then the design may require a sort of anti-wayfinding. Ideally a natural and wild space shouldn't feel designed at all. If the idea of a totally unspoiled place is crucial to the project, then signposting and breadcrumbing will feel artificial and compromise the sense of place and authenticity.
Does your personal residence or home have landmarks and signage? Of course not -- and the privacy of personal navigation and memory is what makes that home belong to you. In contrast, Disneyland is unlivable.
"[fr0g] clan official server 24/7 zk map (for stranger)" by Marek Kapolk is a first person anti-climbing game about carefully descending downwards. The level design often feels haphazard and unreadable, with heavily fragmented circulation and very little clear flow anywhere. The result is that the player feels like they are actively creating their own route and path, and less of an authored critical path. Bennett Foddy writes about its focus on route-finding and unique anti-wayfinding level design:
You do a lot of downward climbing in zk map, but the core activity is route-finding. You look across a haphazard pile of shapes, and your eyes trace possible ways down, imagining the lines of sight and obstructions along each meandering path. Route-finding is one part forward planning and two parts 'dead reckoning': making a choice and then figuring out how to get yourself one step out of the mess you just made. There is something magical about route-finding in a videogame, since videogame worlds are untrammeled, immaculate spaces. Every unguided turn you take is yours and yours alone.
The thing about making a game involving route-finding is you can't really get there by designing great routes. No matter how good your level design skills are, if the player is following a path you laid out for them, they aren't really route-finding at all. The player becomes too aware of your intentions, and their own autonomy becomes subsumed in them. As mkapolk explains:
My process for making the levels was to scatter geometry more or less randomly and then try to traverse it. Sometimes when I was going down a map if I thought that an area shouldn't be a dead end I'd add some more stuff to it, but that's about as far as it went.
You can construct a level that players can route-find through, but you can't design it... or to put it more precisely, you can't crack out the Good Game Design if you want players to experience route-finding. To pass through a well-designed level is a hike, not an expedition.
-- Bennett Foddy, "that's not fun: zk map for stranger"
Playtesting is crucial. Like a lot of psychology and design theory, most of this is wet bullshit until you verify and validate the design in a playtest.
Mapstalgia is a collection of maps and levels from video games, drawn from memory by players. The resulting drawings are often beautiful and wildly inaccurate. It's the closest thing we have to a player's mental map, and very interesting for imagining how players parse level design.
Scope: What can the player do in each level?
Hierarchy: Which parts of the level are most important?
Causality: Why does the player do (this activity) before (that activity)?
Information: What do we tell the player and when?
Intensity: When should the player pay more attention, and when do they rest and recover?
What happens in your levels? What are the various moments and places that define the experience?
A beat is a small self-contained chunk of a level. A single area, event, activity, or element.
We can liken these beats to musical beats in a song. When performed together, these beats form a melody and rhythm. They can be understood separately, but also as part of a whole. To make beats more interesting, music composers arrange beats in different ways to create variation:
pulse: establish a regular recurring pattern of beats, like a heartbeat; establish a meter
example: end every level with a distinctive exit door
accent / stress: emphasize or intensify certain beats
sometimes the exit is difficult to find / reach
rest: incorporate periods of weaker beats or silence, sensitize audience to accents again
sometimes the exit is easy to find / reach
motif: a short recurring sequence of beats
sometimes the player fights a boss before reaching the exit
variation: repeat a sequence of beats, but with different melody, rhythm, etc.
some levels have multiple exit doors
syncopation: go off-beat; the basis of modern pop music
halfway through a boss fight, another boss appears
sometimes a false exit door hides a monster
final boss destroys the exit door; now there is no escape
A set piece is an especially elaborate beat with a unique concept or memorable activity.
The practice of set pieces comes from film production, where big budget movie projects often commission big expensive scenes that require unique sets and complex planning -- an intense spectacle that the audience will remember.
For example, Hollywood blockbuster action films are essentially a series of set pieces -- big elaborate fights, chase sequences, or death defying stunts. The rest of the film exists primarily to connect these set pieces together in a semi-coherent way, and provide some rest for the audience between these intense set pieces. Blockbuster action games work much in the same way.
But set pieces don't necessarily have to be big explosive action sequences. Comedies feature hilariously embarrassing situations, romances might emphasize a first date or wedding, dramas may feature tear-jerking confessions or betrayals, murder mysteries end with a detective recounting the true events.
Any scene in a film or game that feels important, memorable, or expensive, is probably a set piece.
In games, a set piece is usually:
Expensive, requiring many unique art and animation assets, and constant iteration. Not easily scoped down nor repurposed, so inherently risky to produce.
Unskippable, tied closely to the project's core pillars and main experience goals. Why spend so much time and money making something if the player might miss it and blame the game?
Heavily scripted and somewhat linear / on-rails, to ensure a reliable experience.
If the set piece can play out three different ways, then it is now the equivalent of three set pieces, and thus three times as expensive to make.
The level design for a set piece usually involves:
Boss fight, big puzzle, or choreography -- something with a lot of level scripting.
Arena typology, a large room to trap the player until they complete the encounter or cutscene.
Hero props, unique environment art assets to make the level feel particularly special.
In any given project, try to design and plan for at least one set piece. These sequences anchor the rest of the project. Ideally, this set piece should be something you are very excited about, something you can't wait for players to experience.
If you're dreading the work of building out a set piece, or worse, you don't want any players to actually play through it, then you probably shouldn't do it.
If you are learning a new toolset, then don't plan a huge epic set piece. If you're new to game development, then gauging the scope of a set piece may be difficult until you have more experience. Remember: the best set piece is the set piece that you actually have a chance of finishing and releasing.
Combat-based projects and puzzle games can benefit greatly from designing many beats separately, and arranging them together later. The workflow looks like this:
Conceptualize, layout, and blockout one isolated battle / puzzle.
Playtest and iterate on the blockout, until it has proven either promising or a bad idea.
Repeat steps 1-2 until you have prototyped dozens of battles / puzzles.
Arrange the best beats based on common (or contrasting) elements.
The first person puzzle game Portal (2007) was prototyped as a series of disconnected puzzle chambers, and only congealed into a coherent campaign of levels after the designers selected their favorite puzzles. The puzzle element icons displayed on each test chamber's introductory placard are left over from this "pile of beats" process.
Teach, test, twist is a common 3-beat pattern in level design:
Teach: teach the player about a game activity
example: in Portal 1 chamber 10, player learns a simple "fling"
Test: test whether the player can repeat and recognize the activity, with prompting
later in Portal 1 chamber 10, the player performs a deeper fling
Twist: twist the frame of the activity; with less prompting, can the player recall it?
in , the player flings from taller heights
in , the player "double-flings" in mid-air
Pacing design assumes that we can influence, predict, and constrain what the player can / will do in the game. The critical path is the core progression of beats that every player must experience to "complete" the game, whatever that means.
Critical paths can take a variety of forms:
For encounters, a critical path might be the ideal strategy to defeat an enemy.
For puzzles, the critical path is the solution to the puzzle, or at least the most satisfying one.
For movement, the critical path is the ideal route to complete the level.
For more, see Critical path.
There are several ways to outline and document the beats of a level:
Beat sheet, simple text list of beats
Flowchart, diagram of how beats connect to each other
Intensity plot, segmented bar graph of beats plotted against a player metric
In film and TV screenwriting, a beat sheet is a list outlining the major scenes and plot points. We can do something similar for plotting beats in level design: write a list of major events, scenes, and levels.
Write the beat sheet on paper, in an online doc / spreadsheet, or as a project board with arrangeable cards. Then write ideas for set pieces, scenes, levels, boss fights, etc. as paragraphs / rows / notecards / post-its, and then rearrange these beats to form a coherent outline.
In a group, it's important to talk and think out loud, in-person or over a call
Ideally, use an IRL board / wall, so you won't need to worry about a browser tab
The beat sheet can take many forms, based on what you're designing and what it's for.
For the action RPG God of War Ragnarok (2022), lead combat designer Rob Meyer wrote "boss flow" documents (pictured above) which outline key elements and design rationales for the big boss fight setpieces, which helped Meyer get approval for prototyping a systems-heavy combat concept.
For The Last Of Us (2013), Naughty Dog designers rearranged different levels, story moments, and themes throughout the entire arc of the game. This "beat board" (pictured below) helped them plan out the pacing for the finished game, which actually differs greatly from the early plan detailed here.
A flowchart is a visual diagram of a process / program with lines, arrows, and branches. It visualizes the logic of the beats' connections. This is good for puzzle games or non-linear levels with multiple possible strategies and event chains. Use flowcharts when cause and effect matter a lot.
Sketch the flowchart on paper or a whiteboard, or use an online whiteboard / flowchart tool. We recommend Miro.
Keep the flowchart as simple as possible. Use few words and omit minor beats. If it feels like spaghetti, then it is too complicated and you should simplify it.
Try to make the flowchart "flow" in one direction, e.g. from top to bottom, left to right.
Shade boxes different colors based on the beat type.
Instead of one big flowchart, break it up into several smaller flowcharts.
To plan pacing in more detail, sequence the level in terms of a player metric and visualize the plot as a graph.
For pacing the levels in Half-Life 2: Episode Two and Left 4 Dead, Valve designers sorted beats into four categories:
Explore, walk around and navigate the space. Often the start and end of a level.
Combat, fight enemies.
Choreo, some dialogue or choreographed scripted sequence. Used before or after combat, to help signal when combat begins or ends.
Puzzle, find an item stash, unlock a door. Used to space out combat sequences.
Because these are action-based shooters, these designers focused on intensity. On the horizontal X axis, they plotted time in minutes. On the vertical Y axis, they plotted intensity with a simple numerical scale from 0-100%, 0-5, or 0-10.
But what does "4 out of 5 intensity" mean? The intensity score is just a gut feeling that emerges from knowing the game and observing playtests. It's not a hard science.
For each project, you must devise your own categories and metrics. How do you define "intensity"?
In Journey, intensity is not necessarily the same thing as game difficulty.
For example, the death of a beloved character might be a low difficulty cutscene with no player input, but it would still have a high emotional intensity. In this sense, intensity is better understood as suspense, the player's stake, or engagement in the game experience.
Half-Life (1998) famously began with a mundane 6 minute tram ride. Begin your game or level with something low intensity, like an introductory cutscene or some low stakes exploration. It sets the mood and allows time for worldbuilding exposition. Even high action shooters like Doom or Quake begin with quiet rooms where players can test their controls and "warm up" before launching into combat.
Players adjust to prolonged periods of high intensity. Any intense boss fight will feel like a slog after 10+ minutes. To keep it fresh, use occasional downtime as a contrast and palette cleanser, otherwise the player will simply go numb. Don't try to force the player to be "on" all the time.
After high-intensity boss fights, cutscenes and low-intensity areas feel like rewards. Or your core mechanics can encourage the player to rest and return to town, e.g. to sell loot, repair equipment, turn-in quests, etc.
Thatgamecompany read about Joseph Campbell's Hero's Journey monomyth and liked it so much they called their game Journey. Other designers look to classical narrative theories like Three-Act Structure, Gustav Freytag's Five-Act Structure, and Aristotle's Poetics. These traditional narrative theories conclude with a falling action / "denouement" / defeat of the final villain that must feel like the inevitable result of the climax, or else it robs the climax of its impact. Some examples from games:
the final boss of Dark Souls has lots of health but a relatively simple combat style with obvious tells; it feels challenging, but it is far from the most difficult encounter in the game
the final puzzles in Portal 1 and 2 feature foreshadowed simplistic solutions, they are definitely not the most difficult puzzles in the game
the final level of Half-Life 2 features low stress overpowered unbalanced combat encounters while the main villain monologues about their inevitable defeat
Classical narrative theories are useful, but beware:
"Intensity" in a story might not mean the same thing for a game.
Most game progressions / learning curves rarely have "falling action."
Most games are about avoiding failure. Skillful play means the player will avoid falling actions / committing errors. However, failures and mistakes often make for better stories.
Outside of games, these are classical narrative theories that many writers seek to avoid. Using these patterns can often feel rote or formulaic.
Pacing in competitive multiplayer games emerges more from the overall gameplay loop and game mode rules. In battle royale games like Playerunknown's Battlegrounds, Fortnite, or Apex Legends, the match becomes more exciting with the last few remaining players trapped in a very small area. But where exactly will these last few players fight it out, and when? Each match is different, we cannot script or plot how the match will play out.
For team-based games like Counter-Strike, Team Fortress, or Overwatch, level designers must carefully pace the travel times between spawn areas and chokepoints. If a certain team has unfair access to a chokepoint, then the map can feel unbalanced. Here, pacing is more a direct function of the map flow, layout, and metrics.
In open world games, the player can often take multiple possible routes toward an objective. Designing a single path is not useful because we are purposely trying to allow the player some freedom in making their own path and progression. But as with multiplayer pacing, open world games minimize scripted pacing, so layout and metrics are our main tools for planning how quickly the player will traverse the level.
For the open world stealth game Assassin's Creed, level designers built blockouts and then planned missions as a series of concentric circle overlays. Each stage / segment gets gradually smaller and denser as the player approaches their objective. As the player gradually solves their way through each layer of the enemy's defenses, each segment escalates the sense of challenge and danger.
Pacing plans and documents are most useful at the early stage of a project.
docs quickly go out-of-date and require maintenance
many projects are so big that one document can't capture the complexity anyway
big studios and teams maintain internal wikis; dozens / hundreds of design documents
you can't playtest a document; design docs never survive reality
An initial plan is important because it gets everyone on the same page with shared language. But at some point, you must instead pay attention to the actual game you're making, instead of the imaginary game you planned.
Pacing is the ideal order and rhythm of activities / events in the level. A beat is an activity / event.
Single player levels usually have clear critical paths and big setpieces.
For encounter-heavy games with combat and puzzle systems, a pile of beats approach works well -- build a bunch of encounters and puzzles first, then arrange them after, maybe into a teach-test-twist pattern.
Multiplayer pacing emerges more from layout rather than authored events.
Open world / non-linear pacing needs a looser "zone" approach.
Pacing design documents may include:
Beat sheet: written outline, a list (or board) of beats
Flowchart: visual outline with arrows and logic
Graph: graph the beats based on a player metric, like "intensity"
These docs often become obsolete while you work on the game. You can either update these docs, or ignore them.
A lot of industry theory about pacing / plotting comes from film and TV screenwriting, where Robert McKee's influential book Story: Substance, Structure, Style and the Principles of Screenwriting (1997) looms large. Critics argue that McKee's methods result in stale formulaic storytelling, but for better or worse, it's hard to deny his influence.
The narrative design field has spent much more time thinking about pacing than level designers. Anytime an author talks about "plot", they're talking about pacing, and you can relate their insights to level design.










How to draw a top-down floor plan for a level, with flow and typology
Layout has two similar meanings in level design:
the level's overall structure; "the layout was so confusing I didn't know where to go"
overview drawing used for planning, sometimes called a "topdown" because it's drawn from a top-down perspective; "have you finished drawing the layout? we need to blockout soon"
Layout drawings can be simple or complex, symbolic or representational, abstract or concrete. It can be a napkin scribble or a detailed floor plan, it all depends!
A "good layout drawing" is any image that effectively communicates the core design.
But remember: plans aren't magic. A layout drawing cannot tell you if your level works, only a and can begin answering that question. A layout is NOT a level, the player never plays your drawing.
When designing a layout, utilize these design concepts:
is how it feels to move around the level.
Does the player move quickly or slowly, smoothly or abruptly?
Desired flow depends on the . Abrupt flow isn't bad.
There's no single best way to design a layout. Every person (and project) can make layouts in a different way. But if you feel lost, try doing everything:
: define design goals
Parti thumbnails: brainstorm the core shapes
Bubble diagrams: visualize size / flow between areas
Floor plan: draft specific room shapes in more detail
For small solo jam projects, do as much (or as little) layout planning as you like.
For big group projects, try doing all these steps together on a shared whiteboard.
It is difficult to design something without any purpose. In a phase, we try to define and plan out what we want to make before we try making it.
So before drawing a layout, define at least one player experience goal. What should the player learn, feel, or do, in this level?
You can write specific experience goals ("teach the player how to double-jump in a sci-fi sewer for 5 minutes") or be more abstract ("feel one with nature"). But more specific = easier to design.
Once you have some goals, you can plan , the sequence of specific events and activities that will help make the experience goal happen.
For example if your experience goal is "run away from scary monster" then you need to break down that experience into smaller specific beats -- like "(1) hear baby crying behind door, (2) reveal zombie bear making baby crying sound, (3) jump out window to escape monster." (This simple plan already helps a lot, now we know we'll need a door, a window, a bear...)
For more on planning experience goals, see .
For more on planning activities and beats, see .
In architecture, the is the basic shape / idea of the entire building.
a. sketch a small simple diagram (thumbnail) b. label it with a short phrase
What type of basic shape fits with your experience goal / pacing plan?
The parti can be symbolic ("upside-down boat") or abstract ("box subtracted") or it can focus on how people will use the building ("core segregates public-private") or a relationship with the surrounding environment ("finger poking into the woods").
Or you can just vibe with some shapes and sort it out later. The point is to start thinking visually with no pressure. If you don't like a parti, no problem, you can just scribble another one.
Draw at least 5-10 thumbnails to generate multiple approaches. If you draw 100 partis, then at least one of those will be good, because it's impossible to design 100 terrible buildings. The more you draw, the more probability is on your side.
Don't spend too long on each one. Sometimes you only need 30 seconds to scribble some lines, and that'll be enough to express the core idea.
If you can't name it then maybe it's too raw. Try drawing it again in a different way, or try rotating the paper 180 degrees to imagine it from another angle.
Expand the most promising parti into a bubble diagram: a cluster of different ovals that each symbolize different rooms.
a. draw a bubble for each part of the parti b. label each bubble c. draw arrows to emphasize certain connections or directions
The goal of the bubble diagram is to establish proportions and relationships in your level. What needs to be big? What needs to connect to each other?
Don't worry about details yet. This is about the logic of your spaces.
Look at the example bubble diagram below. Which spaces connect to the living room and why? Why is the bathroom there? Where are the bedrooms? What if someone couldn't use stairs, how would they live in this house?
Your first few bubble diagrams will have problems and pose new questions. Some bubbles will be too big or too small, or they might touch the wrong bubbles. Maybe there are some bubbles you forgot to add? Or maybe there are too many bubbles.
A bad bubble diagram is good. That means you found the design problem early, and you can draw another one to try another arrangement.
Draw at least 3 bubble diagrams to imagine multiple arrangements and sizes.
You can deviate from the parti. The purpose of the parti was to help you start drawing bubbles. If it's not helping you anymore, then don't use it.
In architecture, a top-down layout drawing is called a floor plan.
a. imagine a plan cut, an imaginary horizontal slice through a building b. draw the structural shapes below this plan cut -- wall segments, doorways, windows, and significant furniture or fixtures c. to draw relevant objects above the plan cut, use dashed or dotted lines
In the diagram below, notice how Ching uses various line types, line weights, shading, and tonal patterns to differentiate parts of the floor plan. Ching thickens and darkens walls, but uses thinner lines to mark stairs or to denote areas of the house, and fainter lines for the arc of a rotating door.
START BIG. Use the entire page. Start with big main shapes and gradually work down to smaller features like doors and windows. Don't draw at 100% detail.
BE BOXY. Rectangles are easier to build than odd angles or curved walls. ~90%+ of your corners should be 90 degrees and aligned to the grid.
USE 2+ LINE THICKNESSES. Use different line weights for different types of walls.
Markup and label important parts of the layout drawing.
. For single player levels, draw or mark the . For multiplayer maps, lightly shade or highlight team spawn areas and primary .
Areas. Label major areas and landmarks. For competitive multiplayer maps, start thinking about the possible .
Game Objects. Mark important objectives, NPCs, items, traps, etc. that are vital for understanding the player experience. But don't clutter the drawing with too much stuff.
About 2/3 of the way through the single player FPS game Half-Life 2 (2004), the player must fight through a ruined prison complex called Nova Prospekt. It is a long chapter filled with many multi-floor close quarter combat encounters against fast moving squad enemies, designed to make heavy use of the player's "bugbait" weapon that can command flying "antlion" monsters to attack hostile soldiers.
: heavily inspired by Alcatraz State Penitentiary in San Francisco, California
: ground-level arenas flanked with narrow catwalks and prison cells, frequently gated
: designed block-by-block, room-by-room, each section offers a central conceit that adds a new twist to the Antlion vs. Combine encounter space throughout the whole chapter
Notice how the Nova Prospekt plan (above, right) is a relatively simple layout drawing, marking out areas and how the player might progress through them. It omits the individual rooms and hallways inside each building. This is a layout image for a group of levels, not just one level. It is basically a bubble diagram, focusing on the footprint of each area and its connectivity.
For the individual cell blocks and encounters, Valve concept artist Eric Kirchmer incorporated level design and gameplay markup directly into the concept art sketches, which were likely the result of collaborative group whiteboard design sessions. These combat encounters have intended flows with idealized critical path "solutions", which treat each battle like a puzzle to be solved. These sketches provided valuable design documentation for level designer David Sawyer to blockout and prototype from.
In all the isometric layout drawings, note the heavy gameplay markup: player start location, critical path arrows, and heavy use of text labels to help us imagine the player experience.
For his single player Quake level, designer Andrew Yoder iterated on a setpiece encounter involving suspended cages in the middle of the room. Here, Yoder fluidly switches between layout and repeatedly, sometimes discarding entire rooms and revisiting the design with layout sketches. Here's :
"My process is about iteration, which sometimes means stepping back to planning stages. [...] Sometimes I spend an hour iterating on an area and it clicks. Other times I spend that same hour, and eh, maybe best to set it aside and try something else. [...] How do I tell? There's a gut feeling from experience building similar levels in the past. There are also a bunch of heuristics and patterns to check against. Does the player know the goal? Can they anticipate a solution and plan for it?"
Note the numbering, ample use of notes, labeling different parts of the sketch, and use of occasional perspective thumbnails to clarify the overall structure. Perspective thumbnails are especially useful when the level layout involves height changes, which are difficult to draw from a top down perspective.
The variety of sketches and copious markup helps Yoder communicate the intent of his design. The layout process helps Yoder verbalize and articulate the design problems.
For the open world hacking game Watch Dogs 2, designer Iuliu-Cosmin Oniscu built a mission with multiple objectives, entrances, and critical paths.
In his post , he includes layout drawings with heavy gameplay markup and minimal architecture:
Some of the designer's notes and intentions:
In this particular scenario the trick was that the player could go through the lasers and trigger an alarm but he could also:
Disable the lasers when the guard was patrolling away from them and then go into the red zone and silently take the AI down.
Use the Camera attached to the walls to scout the location by traveling from camera angle to camera angle. At this point in the game this is an already well established way of scouting interior locations.
Note how the level designer's drawing (pictured above) is much simpler than the actual in-game implementation (pictured below). Architectural details, furniture, and even some gameplay elements like neutral NPCs and wall-mounted cameras, aren't represented in the layout drawing. None of that is relevant to planning the core experience goal of bypassing security by knocking-out the guard NPCs.
The lesson here is: don't clutter your layout drawing with unnecessary design features.
In the class-based multiplayer shooter Team Fortress Classic (1999), "Warpath" was a control point ("CP") map designed collaboratively by Robin Walker and his team at Valve. TFC's CP game mode was similar to the modern CP modes in Team Fortress 2 or Overwatch, where two teams compete to capture all the control points along a central lane.
: one central lane with side paths, 5 control points total with dynamic spawn rooms
: symmetrical map, all 9 classes must be viable, attack / defense viable at each CP
: beaded necklace, a long coiled corridor dotted with arenas for each CP
In the Half-Life 2 artbook "Raising The Bar", Walker details their process and how drawing layouts factor into their collaborative multiplayer level design workflow:
"After the initial design discussions, maps were sketched out by the design group, and then built by the level designers. Once the initial version was complete, regular playtesting began. Many changes were made throughout the playtesting cycle, often resulting in drastic changes to original plans for the map. [...] [Warpath] was the first TF map in which teams respawned in different locations based upon which control zones their team controlled, and this led to a long test cycle where respawn points were moved many times." -- Robin Walker, from "Half-Life 2: Raising The Bar", pg. 48 (emphasis ours)
In the drawing above, note the numbered control points and labeled call outs. Each control point area is like a mini arena / parti, with specific landmark labels: sniper ledge, tunnel, stone arch, barracks, etc. Name and theme map areas from the beginning. Labels also highlight the most important parts key to the map's experience goals.
Also note the drawing only shows half of the map, where the mirrored symmetry splits at the central bridge. Because they already decided the map layout would be symmetrical, drawing the entire map was unnecessary. Thus, design constraints affect how you draw your layout.
While layouts may seem vital for level design, many level designers do not draw layouts, and often jump from pre-production to blockout. Some arguments against making layout drawings:
You can't playtest a layout drawing.
Drawings are visual documentation that quickly become obsolete and out of date.
Real world architects do layouts because they have to; we shouldn't copy them mindlessly.
3D game movement relies more on intuition rather than calculation.
For the influential 3D platformer game Super Mario 64 (1996), Miyamoto's team made only minimal concept art / layout sketches to plan major pacing beats:
... When you created the level maps, did you draw out models/blueprints beforehand?Miyamoto: Actually, no, not at all. There would only be some concept art sketches, and brief notes/memos. For example, I’d talk with course director Yoichi Yamada about an idea for a level, then he’d make some quick sketches of it. Yamada isn’t an artist, but he draws weird stuff. (laughs) Then we’d look over those and talk more (“oh, there should be a snowman here!”), and those key elements of the level would be written down. Yamada and the other level designers then would refer back to those notes while designing the levels with our software development tools.
-- interview from the Super Mario 64 Strategy Guide (via )
You could also argue Miyamoto's methods are less applicable to other genres, situations, or teams. They were a dozen veteran pro developers who knew and trusted each other, of course they could improvise small low poly single player levels with no planning.
A layout drawing (or a "layout") is an initial visual plan of the level's structure and key pacing beats. You should expect your final level to diverge significantly.
Start with a basic , define desired and .
Sketch and label , simple thumbnail sketches of core shapes.
Arrange the space with bubble diagrams, sketches that emphasize overall proportion and relation.
That said, many level designers don't make layout drawings. Try it, and keep doing it if it helps you think, or if it helps your team communicate. However, don't feel obligated.
Read more about important .
Continue to the phase.
by 3kliksphilip
How to light a game level with functional lighting strategies
Lighting design is about placing lights in the game world to create visual depth, evoke mood, and provide information to help players play. Poorly lit spaces often feel stale, flat, unfinished, or confusing.
Since lighting is so important for readability, we recommend a lighting pass during / soon after establishing core gameplay in blockout or scripting phase.
The industry usually categorizes lighting as an aspect of environment art, but here we will focus less on graphics and more on the design and function of lighting. What do lights say and do?
In the study above by Harley Wilson, lights tell us a lot about the game world and help us play:
. Recessed down-lights along a wall suggest a fancy modern gallery.
. Cooler grays wash a gallery wall, warmer lamps highlight counters, dim down-lights mark a shadowy corner. Lights divide this area into three sub-areas.
. The far wall is dark, maybe it leads to a backdoor or a closet. It's probably not a primary exit, which would be lit more prominently.
In real-life, light is visible energy that interacts with surfaces. It is an elegant system; with the core physics of energy and photons, you can derive all other complex light effects.
In contrast, video game lighting is NOT elegant. It's a fake-as-hell fucking mess, secretly made of many different subsystems in a game engine:
Light sources: base layer of direct illumination, based on light angle and position
Shadows: objects occlude (block) light and project shadow maps onto other objects
Materials: the color, texture, opacity, and reflectivity of 3D surfaces
Imagine making a rainbow with a prism. In real-life, you shine a ray of light through a prism and a rainbow "automatically" emerges because that's how photons and physics work.
But in a video game, a prism effect would be a mess of hacks:
Refracting glass material + screen space reflection for prism shape
Ray FX, white beam and rainbow painted separately in Photoshop
Glow sprites where beams intersect prism
Caustic projections / translucent AO for nearby surfaces
This is not an elegant universe of photons interacting with surfaces. In the list above, notice that we're not even using any light sources! It's all "fake"!
Lighting a video game is about picking and choosing only what you need. In most game engines you can set one light to turn off shadows, or set another light to disable reflectivity. This is essential for .
It's enough to make a real-life physicist vomit. "But light without shadows or reflectivity doesn't make any sense," cry the physicists. Haha, silly physicists! This is video game land!
The sun and the moon (reflecting light from the sun) are the most common natural light sources.
There are also artificial light sources like controlled fires, gas lamps, incandescent light bulbs... and in the 21st century, there's energy-efficient fluorescent lights and LED lighting.
However, this is not just a story of technology and progress. The light bulb did not make the sun obsolete, and the LED does not make fire obsolete. We still like sunny days and romantic candle-lit dinners.
Fire has not disappeared from the world. Instead, the meaning and use of fire has changed. Lighting design is about understanding how light conveys these ideas, moods, and emotions.
Real-life lighting design is the art / science of placing light sources to account for context and functionality, whether for an office or a moody restaurant.
Real-life professional lighting designers assess building plans and coordinate with architects. They shop in catalogs published by light fixture manufacturers, with detailed technical specifications and lab-tested light falloff charts / standardized IES profiles that they can test in 3D simulations. They must also balance local laws and building codes about minimum light levels, budget, maintenance plans, energy use, and sustainability.
Because eyes adapt to nearby light levels, it is difficult to guess how bright a room actually is, so lighting designers often approximate a quick measurement with the . For a more accurate reading on-site, they also use handheld to measure scientific units like / / .
Some game engines are increasingly adopting this technical / scientific lighting approach. However, we must be vigilant: real-life lighting design has fundamentally different goals vs. video game lighting design.
Since game lighting is so complicated, we will mostly focus on the fundamentals of lighting design for level designers: placing light sources.
Core light source types
Static vs. dynamic light sources
Fixture vs. light source
Almost every game engine uses these four core light source types:
Ambient light is the default minimum amount of light in the world. Not really realistic.
Directional light casts constant light from a direction, like sunlight downwards from the sky.
Point lights (omnidirectional / "omni" light) are like light bulbs, throws light in all directions.
(TODO: light source diagram)
Together, these light sources form a complete domain of basic lighting tools:
Other light shapes are just variations on these core types.
Area lights are wide flat rectangular spotlights
Tube lights are long point lights
Emissive materials / "texture lighting" use self-illuminated pixels like point lights
A static light does not change at all, while a dynamic light can change in color, intensity, direction, or position.
Static lighting is almost always better for framerate because the engine can "bake" lighting data like lightmaps and reflections -- but rebaking constantly gets annoying, and lighting data can consume a lot of memory.
In contrast, dynamic light means the level can change and react, enabling switchable moving lights and day-night cycles -- but if there's too many light sources, then it might overload the player's machine and the framerate will suffer.
A light fixture is a visible plausible source of light, like a light bulb or a fireplace. But a window with sunlight is also like a fixture. Within a game level, this is usually like an architectural feature or a decorative lamp prop.
This is not the same as an in-engine light source, which is actually an invisible source of light with no apparent cause. It often looks kind of weird, and simply doesn't happen in real-life.
A motivated light is a light source with a plausible fixture.
Note that a single fixture may actually motivate multiple invisible in-engine light sources. In the image pictured below by Harley Wilson, there are only two visible light fixtures: an orange fireplace and a blue-gray window. But what looks like two lights is actually 11+ light sources!
Here are two ways of approaching lighting design:
Three point lighting: common theory for 2D media like film and photography
D6 lighting: more abstract but more 3D, for architects and interior designers
Three point lighting is a lighting theory with three types of lights:
Key light: the primary light source
Fill light: softer secondary light source to brighten up shadows
Rim light: an accent to highlight objects and edges
While these core concepts are useful, it has limitations for level design. This technique comes from photography and film, so it assumes linear fixed 2D screen compositions -- not an interactive 3D space that a viewer navigates freely.
For more about this 2D lighting theory, see .
D6 lighting is a lighting theory focused on coverage and space, inspired by a six sided die. Each side represents a lighting strategy, for a total of six strategies:
Focal point ⚀
Focal frame ⚁
Path ⚂
Area ⚃
This theory has more applications for architecture and level design, however it's obscure and less known than three point theory.
For more about this 3D lighting theory, see .
Lighting can be very time-consuming, so don't attempt to do final lighting all at once. Instead, build flexibility into your workflow, and work iteratively.
We recommend lighting in four passes:
Global lights
Wayfinding / critical path lights
Gameplay / combat encounter lights
Detail and mood lighting
Begin with an initial pass at any global key lights and fill lights: skylight, ambient light, and any skybox / atmospherics.
If you are using any emissive materials as key lights, e.g. a glowing river of lava, then configure this light source as well.
If your desired look involves baked indirect light, run an initial low quality light bake immediately. Some fancy global illumination solutions (e.g. UE5 Lumen) may be able to light the entire game world with just one sunlight-like directional light.
Next, ensure any important entrances / exits along the are well-lit from the desired approach. You will likely need to use local light sources, e.g. place a light fixture next to a doorway.
Build a hierarchy. Big important exits should have more important looking lighting, while secondary spaces should have dimmer less focused lights.
Lighting to foreshadow encounters (enemy approach, battle line, possible strategies and flanks)
Lighting to highlight puzzle elements and suggest areas to explore
Fine tune and tweak everything, but don't spend too long, it probably looks good enough, and if you tweak it too much you might destroy the effect from a previous pass.
(TODO: images and examples?)
Your albedo textures might be too dark. If the textures are too dark, then any resulting light bounces will be faint, no matter how bright your lights are. Unless you have specific stylistic or technical reasons to do otherwise, your main diffuse textures should usually be in the 50-100% brightness range. See by Rogelio Olguin, and the old Epic Games UDK docs .
TODO: showcase different contexts (industrial vs residential) and moods (scary, comfy)
Lighting gives visual depth to a scene, allowing players to gauge distances and distinguish shapes. Because it serves a very important gameplay function, you should do a lighting pass early in the level design process, before a proper art pass.
Video game lighting tech is a crude illusion that approximates real-life light. Many game lighting effects do not actually use any lighting systems.
There are 4 core light source types: ambient, directional, point, and spotlight. These lights can be static or dynamic, and motivated by a visible light fixture or unmotivated without any visible source.
The most common lighting theory is three point lighting, which defines key lights, fill lights, and rim lights based on the light's orientation to the camera and subject.
To light a level, work gradually over several lighting passes. Do global lights first, then light for wayfinding, and then for gameplay, and finally any last details or moods.
Move on to .
Lighting is traditionally the most performance-heavy visual aspect of a level. After a lighting pass, you'll want to do an pass.
by Magnar Jenssen is about lighting levels to aid readability for typical shooter gameplay.
by Kinematic Soup covers an important but often neglected aspect of game graphics: color space and gamma curves.
is a great overview of how many AAA lighting artists work today, with lots of process and iteration examples.
is a video intro to lighting 3D scenes for photorealistic look. Color temperature, falloff, materials, and optics / post process.
The Architecture of Natural Light, by Henry Plummer. Monacelli Press: 2009.
, 9th edition (2000). edited by Mark S. Rea.





player gains the ability to create their own exit doors
then Portal 1 chamber 18 ends with an "infinite fling" challenge
note how these "twist" beats are spaced out, and aren't immediately after the Test

Circulation is how real world architects think about flow.
Verticality is about supporting vertical flow.
Parti is the core structure / main idea of the layout.
What is the overall concept that binds the entire layout together?
A clear parti helps you focus on the most important parts of the design.
Typology is about common layout patterns and functions.
Simplify the way you think about the layout
Shared design vocabulary helps you study other levels and communicate.
Gameplay markup: add labels and design notes
WE'RE NOT ARCHITECTS. Draw the minimum needed to imagine the player experience.
The corridor beyond also has a bunch of strategically placed junction boxes that can be hacked to incapacitate to incapacitate two guards at the same time.
Start with big simple shapes, omit details. Use multiple line weights and shade floor areas.
For rooms with multiple floors, draw an isometric view, with attention to the floor planes.
For important or complex set piece rooms, maybe sketch a perspective view and label it.
Markup the plan with player flow and gameplay notes. Help others imagine the experience, especially if you are collaborating with others.
Name and label areas. Think of each chunk of the level as its own parti.



Reflections: true reflectivity requires re-rendering the scene; most games use approximations
Baking: developers pre-render lightmaps and reflection data
Glare is literally painful to look at
Glare makes your game worth $60
Comfort, safety, usability, reliability
Drama, detail, clarity, plausibility
Area with focal point ⚄
Area with path ⚅
Runs on electricity
Also runs on electricity
Must obey laws of physics
Pick and choose laws; godless
Follow local regulations
No regulations, only gamer norms
Infinite light sources, infinite rendering
Optimize for fewest light sources
Long-term, you live in it
Short-term, you visit it
Global, affects everything
Local, affects nearby things
Shines in all directions
Ambient light
Point light
Shines in one direction
Directional light
Spotlight





subtle crack in ground or wall (Zelda), conspicuous use of game elements with unclear purpose (e.g. explosive barrel with nothing to affect)
10%
sound design
ambient sound (e.g. hearing the sound of flowing water in the distance), dynamic use of music (e.g. hearing tense music upon entering a dangerous area)
15%
e.g. shooter levels with large rooms full of cover but no enemies yet, or when a room feels structured like a boss battle arena
20%
e.g. waterfalls hide treasure, or climb a tower for a reward
45%
trail of blood on floor (Doom), trail of destruction (BioShock)... clear authored path formed by a character or event
50%
ground composition
planks that extend off the ledge (Uncharted), train tracks (Team Fortress 2), scratchy ledge markers (Tomb Raider)... clear gameplay function
55%
repetition
repeated use of prior elements in a similar situation, directly evoking the player's memory and pattern recognition
60%
glowing GPS route (Grand Theft Auto 5), dynamic road signs (Mafia 3), pings (Apex Legends), alternate vision ("detective mode" in Batman Arkham games)
92%
active threats
enemy NPCs actively attacking the player, aggro'd NPCs with audio barks that draw dangerous attention to themselves
93%
How the level designer role was invented and professionalized across the game industry, including its golden age in 1993-2002, and later its fall in prominence.
This is a history of the level designer role and the history of how we understand the work conditions and influence of level designers. Our main questions:
How did the "level designer" emerge as an identity and work role? Which came first?
What is / was the cultural understanding of a level designer, both inside and outside the industry?
What is the current state of level design, and how did we get here?
This history also intersects with the history of the game industry, the history of game modding, as well as the larger history of home computing and the internet.
In the early years of the game industry, many game programmers also did the design work for their own projects. "Level" referred to the arcade game's programmed difficulty level.
Early first person games like Maze War (1973) existed as research lab prototypes without any officially designated game designer, while popular first person arcade cabinets like Battlezone (1980) used procedurally generated / hardcoded levels embedded within the game code.
During this time, engine code and game code / content shared the same code base, or they were at least tightly coupled. There were no separate game data files to edit, so level design required extensive programming knowledge to edit the game code; there were no dedicated level editor tools for making levels, so level designers essentially did not exist. Level design was just part of the informal work performed by game designers and programmers, and thus not understood as a separate design discipline.
Computers were also just really really expensive. Only corporations and universities could afford huge computers for research, and only arcades and businesses could afford to invest in arcade cabinets by selling access to the machines. Since so few people had dedicated access to computers, of course there would be very few level designers, if any.
In the early 1980s, computer manufacturers started selling smaller and cheaper personal computers (PCs) and consoles intended for the home market. More computers meant a larger install base of users looking for new software (especially games) as well as a community of amateur "bedroom programmers" who informally developed their own games, supposedly at home in their bedroom.
Lode Runner (1983) was one of the first games to include a level editor ("edit mode"), with claims that solo developer Douglas E. Smith had neighborhood children build levels and even shipped many of their levels as part of the game. Tim Sweeney's influential game ZZT (1991) also featured a with integrated ZZT-OOP scripting language, nurturing a sizable community of modders and spurring Sweeney to run official level design contests.
One of the earliest popular first person shooters Wolfenstein 3D (1992) did not ship with a level editor, but the tile-based map format was simple enough for a fan named Bill Kirby to reverse engineer a functional editor called . By 1993, fans had made hundreds of custom maps and mods, prompting the developer id Software to build better mod support for its follow-ups Doom and Quake.
Doom (1993) is widely regarded as the most influential first person shooter of all time. Its main programmer John Carmack popularized the concept of architecting a "game engine", where core engine code like file input/output and rendering was kept separate from the rest of the game code and game data. Since Doom stored its game content in .WAD files ("Where's All the Data"), players could load their own player WADs (PWADs) to mod the game, and these PWADs could swap in custom levels, graphics, sounds, etc.
Doom blossomed into a huge cultural phenomenon with a large player base and active modding community that still continues to this day. It represents the beginning of level design as an approachable amateur hobby, stimulating the growth of a level design community and culture.
But who really built that level design community and culture? Despite shipping a technical foundation for loading custom WADs, id Software did not publicly release its internal level editor . What use is a modding system when there are no tools for modders to use? Much like MapEdit for Wolfenstein 3D, modders were forced to once again reverse engineer their own tools like .
In this sense, we argue that modders and level designers largely invented themselves as a grassroots hacker practice, with minimal support (e.g. a pledge not to sue) from the commercial game industry.
This is also where we must question the popular historical narrative of Carmack as the patron saint of modders. id Software's prior experience with Wolfenstein 3D modders had generated several less-than-purely-altruistic business incentives to support modding more officially in Doom:
mods extend the lifespan of a game and its "long tail" of retail sales
modders train themselves for free, forming a convenient pool of labor to hire from
official mod support discourages hacking / piracy (modding Wolfenstein 3D required hacking the data embedded inside the game executable, bypassing copy protection, thus mod distribution entailed piracy)
We argue that Carmack's popularization of the game engine is more effectively understood as a cultural business innovation, rather than a technical engineering achievement. Data-driven programming paradigms have existed since the 1970s, and even moddable games such as Boulder Dash Construction Kit (1986), The Bard's Tale Construction Set (1991), and of course ZZT (1991) existed well before Doom (1993). Architecturally, the WAD system is less of a groundbreaking idea, and more of a refinement of existing ideas.
What really set Doom apart was the critical mass of its mod community and fanaticism, so the keyword we'd like to emphasize is "popularize": Carmack popularized the social construction of the game engine, a marketing buzzword that reimagines the video game as a platform for user generated content... and it worked. Modders flocked to the game engine and invested their labor in it, and continue to do so today.
We argue that level design experienced a golden age from approximately 1993 to 2002. During this period, level design tools were widely available to the public, level design became a much more common pastime, and level designers enjoyed unprecedented prestige and power in game culture.
During the golden age, level designers enjoyed unprecedented prestige in game culture.
Perhaps the most prominent level designer in history was co-founder of id Software and lead designer John Romero, who possessed a rockstar-like name recognition among gamers in the mid 1990s. This reputation even prompted publisher Eidos to commission a notorious magazine ad for Daikatana (2000) threatening gamers that "John Romero's About To Make You His Bitch. Suck It Down." Thus the level designer was the chief creative voice of early first person shooters and the game industry as a whole. For better or worse.
Other Doom level designers like American McGee also garnered their own lesser amount of name recognition and power. PC Gamer commissioned official Half-Life mods by Neil Manke, plastering his name on magazine covers. The designer of the iconic Counter-Strike map de_dust Dave Johnston won a modest following and interview requests from journalists. Cliff Bleszinski, designer of dozens of Unreal 1 and Unreal Tournament maps at Epic Games, nurtured a Romero-like rockstar public persona as CliffyB. There was even a prolific Quake mapper who called himself The Levelord and people were like, ok sure. For better or worse, these were the people who would garner fawning profiles in popular gamer magazines, back when those were still a thing.
Everyone in the game industry, or at least those working on the big most-prestigious 3D action games, seemed to agree: level design was the most important part, and level designers enjoyed immense power and control over the final shape of the game.
"Level design is where rubber hits the road." "A level designer has a very responsible position, because maps are where the game takes place." - "The LD is the one who is taking everyone else’s hard work and tying it together into a cohesive package." -
This sense of responsibility stems from the technical importance of level designers in early game engine workflows and pipelines. Level editor tools really were where the code, graphics, audio, and story assets, all came together. Nothing existed in the game unless the level designer put it there. For example, if a designer didn't like a certain texture, sound, or AI behavior, then they could simply omit it from their levels -- and thus, it would never get used in the game.
Thus level designers had the "final say" and informal institutional veto power over game content. And when they claimed ownership over their levels, the centralized nature of level editor workflows meant they could essentially claim ownership over the whole game experience too.
We argue the golden age of level design culminated in 2002 with , an unofficial Quake 3 Arena community level design competition that emphasized plain texturing, sweeping abstract geometric forms, and detailed design discussion.
GeoComp2 entries emphasized auteurism with perceived elegance and functional purity, pairing the aesthetics of high level competitive FPS play with the tenets of modernist architecture. Most importantly, there was a conscious effort toward facilitating a detailed design language and critique.
For each entry, a community jury debated the merits of each map with specialized terminology and ideas unique to level design. Did the level designer have a fresh personal style, and attempt novel ideas that had never been seen before? How does the "brushwork" (level geometry) feel? These types of craft-oriented questions can only be asked by an advanced design community with a shared history, language, and understanding.
"... The map is king of the hill style map split into 2 blocks interconnected with a massive array of jump pads and teleporters. The brushwork is strangely broken but architectural complete in a sort of w[ei]rd artist way! The brushwork seems to sweep upwards offers impressive structures towering above the players. [...] The map seems to have an nosta[l]gic feel which almost needs to be dripping in fur. [...] Nothing about the architecture seems to repeat and all aspects of the brushwork seems fresh and original. even thou[gh] the map is sy[m]metrical from left to right the architecture is not. For example the floor spaces have strange cut patterns which break the sym[m]etrical theme of the map in a very striking way..."
-- Simon "sock" O'Callaghan's critique of , for GeoComp2
The aim behind GeoComp2 was not to make a popular map, or even a "fun" map -- it was to advance the craft of level design. Any fandom for Quake 3 or id Software was secondary. This was a clear example of level designers making maps primarily for other level designers, to articulate an aesthetic that transcends the game itself.
For this reason, we argue that GeoComp2 represents a historic milestone for how level designers viewed and organized their work. It represents a zenith of self-regard, when level designers consciously evoked the aesthetics of high modernist architects like Le Corbusier and Frank Lloyd Wright. It was a community-organized showcase for avant-garde design that emphasized concept, craft, and aesthetics, instead of commercial viability or building an audience.
Final Doom was published by id Software but developed by community modder group TeamTNT. Various id-adjacent studios riding the 90s FPS boom, like Ritual Entertainment and Ion Storm, hired heavily from mod communities. Valve purchased the rights and hired the modders behind Team Fortress and Counter-Strike. Going retail or "breaking in" to the industry were seen as the just rewards for the most deserving of modders, elevated to the status of professional. This cult of meritocracy still persists in a level design culture that heavily emphasizes portfolios of shipped titles.
But for many modders, the golden age was merely a gilded age where many modders labored in obscurity for little recognition or reward. Auteurism in any industry also hurts many collaborators, who see their contributions forgotten when society credits the most famous figures for the entire project. (.)
The golden age of level design was simply the time when level design enjoyed relatively high status in game culture. Today, industry level designers are much more anonymous members of huge 100+ / 1000+ person development teams. There will never be another rockstar level designer like John Romero because the game industry now works with levels as assets instead of platforms.
(todo: insert illustration)
In the golden age, level designers often served as all-in-one all-purpose developer. Doom mappers setup their own lighting, Half-Life designers choreographed their own scripted sequences, Thief: The Dark Project mission designers wrote in-game readables, and Counter-Strike mappers mixed their own ambient audio. This informal distribution of labor allowed them to claim ownership over the final product, and thus justify their auteur status.
When one person performs several different jobs or roles on a project, this is called generalism. Modders, solo devs, and small indie teams still abide by generalism out of necessity. However, generalism quickly proved incompatible with ballooning AAA game budgets and production value arms races. As early as 2000, the industry already predicted a future of specialization in level design, with a more specific and formalized distribution of labor:
"... it is no longer possible for one LD to maintain "ownership" of a level as computers and gaming machines are becoming more and more capable of rendering extremely detailed environments. The talent that is hired must be comfortable with the idea of others modifying and improving their work.
There is a direct correlation between the detail that a technology is capable of and the amount of ownership that one designer has over a particular level. With holding true (processor speed doubles every eighteen months) and 3d accelerators constantly raising the bar the detail that game engines are capable of is staggering. It is simply impossible for one driven person to build the necessary amount of detail into level locations in the allocated time, and the more detail technology can push the more people will be required to work on levels.
In addition to having dedicated world texture artists and environment concept designers the need will soon emerge for dedicated "prop" people; artists who create content that will fill up previously static and barren environments. [...] Teams may soon see the addition of "scripting" people who are responsible for storyboarding in-game events as well as assisting in the design and direction of these events. [...]
Right now there are companies that have artists lighting levels, as well as doing custom texture work on a per-surface basis. The level designer will evolve to the role of the glue of a project, the hub at which everything comes together." --
Remember how level designers were creative directors? In 2000, CliffyB wanted to "evolve" level designers into glue. Evolution indeed!
However, some level designers didn't enjoy being the glue, because it turns out when the game falls apart, you end up blaming the glue.
In his GDC 2011 talk "Unscaping the Goat", industry designer Ed Byrne alluded to a culture of blame in AAA game studios. Because artists, game designers, and programmers, had well-established tools, duties, and deliverables, they would blame level designers and their vaguely-defined informal labor for complex problems. As Bleszinski predicted, a single "level owner" could no longer claim so much responsibility and control over the experience. It was time for level designers to step down from their once-privileged position.
Many of Bleszinski's predictions came true across the entire industry. Big budget game studios today routinely hire huge teams of dedicated environment artists, prop artists, lighting artists, and level scripters. Industry level designers today rarely paint their own textures, model their own props, setup their own lighting, or choreograph their own cutscenes.
Yet Bleszinski also seems to have underestimated how much level designers would specialize. Industry level designers today also routinely do not build their own blockouts, nor setup their own NPCs and battles -- instead, we now have dedicated level architects, level builders, combat designers, encounter designers, and mission designers.
In 2001, a company called Crytek put out a job posting for a "3D-Level Designer" to work on their new game Far Cry. According to this ad (see above) a level designer was someone with experience using 3DS Max, art skills, and a degree in architecture.
In 2008, Crytek put out another job posting to work on Crysis. Now a level designer was someone versed in "systemic design", "systemic sensory based AI Systems", "simulation design"... in contrast with 2001, there was now no mention of 3D art or architecture.
Then in 2012, Crytek was looking to hire... a tech level designer, someone who would work with programmers to optimize levels, perform maintenance, and profile implementations, perhaps in the same sense as a tech artist.
At the bottom of the ad, it listed "prior level design experience" as an optional preference! Wait, so now making levels would be "nice to have" for a level design position? Level design specialized so hard that it necessitated a level design position that didn't require experience in level design!
As a major engine vendor with thousands of employees at its height, we argue that Crytek's changing attitude was somewhat representative of industry practice as a whole:
Level design started as an artistic visually-oriented discipline inherited from real world architecture, but after escalating project scopes and industry-wide shifts toward specialization, it has now fragmented into dozens of specializations increasingly divorced from the original holistic conception of level design.
Half-Life 2 (2004) was a landmark first person shooter that popularized the use of physics-based gameplay and detailed facial animation. Its level designers still had substantial control over level geometry, texturing, lighting, and scripting with an editor tool called Hammer. The underlying game engine Source 1 descended from idTech1, the core tech for Quake and Half-Life, and so it was the last major game engine to rely heavily on mid 1990s building techniques known as / .
As designer Joe Wintergreen , this type of construction might feel a bit old and primitive today, but it supports a wide range of expressive construction without forcing level designers to learn specialized 3D art tools. This workflow also promoted a tight loop between level geometry and gameplay iteration.
For this reason, we argue that Hammer was essentially "the last level editor" because it hit a sweet spot of public availability, popularity, functionality, technology, and market conditions. Since its initial release in 2004, no other tool for any other game has attained quite the same traction or influence. Just take a look at the sorry state of our page! It's sad how much is broken, and how little we can recommend.
A variety of factors have sunk any would-be successors to Hammer:
restrictive and exploitative EULA, ceiling on future utility and output
editor tools withheld to preserve developer monopoly on DLC
oversimplified editor with severe limits, not what devs actually use
game is unpopular or obscure, no sustainable community of users or players
Recall the importance of the level editor to the level designer's consolidation of power during the golden age. The level editor was literally where you binded assets and code together to implement gameplay.
Today, that binding function has become the main focus of generalized multipurpose game editors integrated into modern 3D game engines Unity, Unreal, and Godot. The game editor is where artists and coders do their work too, it's no longer reserved solely for the level designer.
In fact, these tools don't even have robust built-in 3D construction capability anymore. Industrial hyperspecialization meant level construction was now understood an art task, not a generalized design task -- prompting middleware engine providers to neglect construction tools. The continued lack of these tools perpetuates the cycle of sidelining level designers.
It's ironic that this tool design descends from level editor tools, yet level designers arguably can't really use them to do level design today.
Level design is no longer just one thing, it has split into different practices and understandings:
Postlevel design: popular game genres today rely much less on traditional level designers
Local level design: players do informal level design for each other, rather than industry or craft
Retro renaissance: return to golden age construction and design values
We argue that Hammer was essentially the last level editor tool. Maybe there are no new level editor tools because traditional level designers are no longer needed for many popular game genres today.
Consider , the rise of the multiplayer battle royale format, and -- a FPS-RPG hybrid subgenre that relied heavily on detailed level design. Perhaps popular trends and game genres have simply moved on, and the types of games that "need" traditional capital-L capital-D Level Designers are gradually losing relevance (and/or market value to investors.)
Minecraft (2011) is the most popular first person game of all time, and Fortnite (2017) is perhaps the most popular shooter game of all time. Yet for our purposes, it is debatable whether Minecraft or Fortnite have level design. Minecraft relies on to seed randomized spaces without specific experience design intended by a human designer. emerges from statistical resource distributions defined by code. is understood as a game system and amateur communal activity, not as level design. As for Fortnite, yes, players scavenge for resources in a developer-authored landscape, but gameplay quickly escalates into player-built forts and towers. Does level design meaningfully exist in a game where players routinely ignore the authored terrain and build their own level?
This reality would've been utterly unthinkable back in the golden age of level design. Imagine going back in time to 1993 and telling celebrity rockstar level designer John Romero that the most popular first person game of all time in 2011 does not rely on professional level designers building content in a level editor tool. This genre framing was inconceivable back in the 1990s, but in the 2010s it is the new normal.
The contemporary games as a service (GaaS) model emphasizes huge monolithic landscapes that go through dynamic seasons and demographic changes, instead of streams of static level content. Planning individual rooms is now safely below their concern. Is that still level design, as understood for the past 30-40 years? Obviously no.
This conception of world design, community design, season design -- it's bigger than a video game level, and demands a very different skillset. Thus the postlevel designer is less like an architect, and more like a city planner, festival organizer, TV show runner, or climate engineer.
By most professional design standards, the Counter-Strike 1.6 community map is poorly made. It is very small and symmetrical, team spawns have direct visibility to each other, the texturing and lighting are flat and bland, and there is basically zero detail or set dressing.
Yet despite all these markers of low quality and poor taste, Iceworld is one of the most popular and iconic maps of all time. Its frantic scramble and quick turnover is genuinely fresh compared to the official mapcycle. Every CS 1.6 player knows this map, and even .
As a counterweight to the heavily professionalized "serious" auteur level designer identity, we must also consider the more anonymous designers who built maps for their own gamer clans, favorite servers, local , and IRL friend groups. This type of community design practice ignores formal questions of supposed "good taste" or production value. Instead, these are spaces for fostering shared social moods, the equivalent of a childhood treehouse or clubhouse.
Iceworld is a great example of local level design, informal level design that emphasizes a social context above any larger obligation to craft or career. Other examples of local level design include marriage proposal maps like or the achievement trap joke maps like . Here, the formal level design and professional craft matter less than the cultural story surrounding it.
(TODO: include Doom history too? Doomworld, Cacowards, community memory)
In 2010, debuted as a modern "source port" engine that embraces backwards compatibility and eschews "unfaithful" graphics upgrades, unlike heretical Quake engine forks like DarkPlaces or FTEQW that use modern shader aesthetics. debuted in 2011 as a modern multiplatform open source level editor that breaks from Worldcraft / Hammer lineage. The community mega mod launched in 2015 represents some of the strongest design work in Quake's history. This critical mass of new tools, resources, and community have triggered and sustained a Quake renaissance for the past decade.
Much like historical renaissances and the larger indie games movement, the Quake renaissance represents a return / rebirth of perceived classical values retrofitted onto modern culture, economy, and technology. It is also a reaction against several contemporary trends:
rejection of modern aesthetics for "pure" low poly geometry on a fixed color palette, with carefully calibrated nostalgia (yes to colored lighting; no to 8-bit transparency)
embrace of amateurism counters industrial hyperspecialization; professional game developers miss the freedom of non-commercial generalist design
resistance to platform capitalism reconstructs Quake as a community-owned open source platform that is "worthless" to Quake's corporate IP holders
To be sure, there are still many new projects with great level design today, and there will be many more to come. However, we question whether future generations of new level designers can emerge without proper access to tools and resources. How many great potential designers are we losing? What else can level design become?
In this history, we traced factors that enabled a golden age of level design:
available tools -- free developer-grade editor that enables expressive construction
sustainable audience -- large creative communities of supportive players and designers
artistic control -- generalist self-sufficiency to build and finish projects independently
The extinction of level editors, the rise of closed platforms and games as services, the shift toward hyperspecialization, and the popularity of postlevel design genres, all threaten the future of the level designer.
We don't foresee any of these industry trends reversing. Level design will steadily become less relevant and eventually drift out of public memory as another forgotten art, like sign painters or telegraph operators. And maybe that's OK.
refining shapes and adding visual detail, while maintaining clarity and functionality
Environment art (or "env art") is the cosmetic decoration of a level or game world, while preserving its core functionality and gameplay.
This work involves building up a library of modules, props, textures, materials, and other art assets, and then art passing the level by painting / placing decor to supplement the underlying design.
Before the 2000s, level designers often made their own environment art too. But today, a level designer is usually supposed to make as little visual art as possible, and the environment artist is usually supposed to wait for a mature









depends on proprietary middleware / servers, not feasible to release publicly
level design for level designers (e.g. high modernism of GeoComp2) avoids context collapse of modern social networks, both players and designers share deep history and memory
Here we will focus on general environment art principles and high level concerns, so that level designers can better understand the art process and collaborate with environment artists. This is not an environment art book.
For links to free textures, materials, and models, see Resources.
For links to dedicated environment art communities, sites, and books, see Community.
Before you begin an art pass, you should to be able to answer these questions:
Theme. What is the time of day, climate, and location for the level?
Gameplay. Which parts need emphasis? What should be simple, what should be detailed?
Style. Realistic or stylized? What type of realism, what type of style?
Palette. What's the overall color palette, what's the mood? What kinds of shapes?
Production. Which parts need to be done first, and which should be last (or never)?
For more on planning, see Pre-production and Research.
Concept art is generally any visual art used for planning the game, but not used in the game itself.
Sometimes the goal of concept art is to convey a desired theme or overall mood, while other times it must communicate technical specifications and details for art assets. Ask yourself, is this concept art meant to inspire, or is it trying to solve a specific visual design problem?
Inspirational mood art is most useful during pre-production (especially when pitching a commercial project to a publisher) or early production, but detailed technical art is more useful later in production.
If you use someone's concept art, credit them -- or even contact the artist and ask for permission before you begin. Attribution is very important if you're looking for a job; everyone knows everyone, and failing to credit someone will look like a red flag.
A paintover is a type of concept art that starts with a 3D screenshot and then an artist literally "paints over" the underlying screenshot to visualize the next version.
It is very common to paintover a blockout screenshot to plan an art pass. This workflow saves a lot of time because the artist doesn't have to manually draft the perspective calculations for basic shapes. For this reason, even 2D artists should have at least some basic knowledge of 3D art tools, so they can potentially build their own blockouts for paintovers.
Sometimes the artist fully renders some finished-looking concept art (see image above)... but usually the paintover is about providing direct feedback between artists: suggested edits, corrections, and notes (see image below).
A model sheet is a more specific type of concept art for individual art assets that includes orthographic views for production artists to work from, as well as contextual mockups to show how that asset should be used within the game.
In the concept art / model sheet pictured below, note how we get a good sense of how this octagonal ice crystal platform model will fit into the whole environment theme. Furthermore, the orthographic top and bottom views answer the prop artist's questions about construction and color, and can be easily brought into a 3D modeling tool as reference. The orthographics emphasize the golden corner trim of each platform, while the bottom-right illustration shows how the corner trims tile together for an interlocking visual effect -- together, it helps the environment artist understand which details are important to preserve and carry over to the in-game asset.
After some planning, artists produce art assets -- visual objects to insert directly into the level. Unlike concept art, this is what the game engine must read and what the player will see in-game.
When producing art assets, keep in mind:
The Brief. What is the task? What does this asset need to do?
Approval. Who gives feedback on this asset? How will we know if it works?
Scope. How much time to make this asset? Small rare details deserve less time.
Workflow. How many steps to make this asset? In which tools?
Pipeline. How to export art into a format that the engine can read?
Longer term projects (6+ months) with larger teams (6+ people?) should formalize this art production process to avoid costly redos, wasted work, and miscommunication. Maintain a spreadsheet or kanban board to track tasks, and move each asset through different stages of testing and team review. While all this task tracking may feel slow at first, communication and clarity are faster in the long run.
For more on organizing work tasks and team communication, see Production.
Most art assets for levels are either 2D textures or 3D models, but in this section we'll also talk briefly about shaders and special FX later on.
Before making environment art, you may need to make an asset list, a list of all the art assets needed for a particular scene or level. Asset lists are usually in some sort of spreadsheet format, listing each asset's priority and estimated production time.
In the image below, the artist has made an asset list spreadsheet grouped by month / week. They estimated they had about 30 hours a week to work, and prioritized a scene blockout / the most important level geometry assets first. Materials and detail props only happen later, after the foundation has been set.
Textures are 2D images that cover the 3D surface of the map. Since the 2000s we often combine multiple textures together into materials, texture bundles with additional data like roughness, shininess, light emission, etc.
For environment art, texture design and layout is very important. Unlike character skins, we often reuse world textures heavily throughout levels. The ideal environment texture needs to be able to work well in many different situations: it should tile well across a surface, but also easily divide into reusable parts.
For more on texturing and defining materials, see Texturing.
A modular kit is a 3D tileset made of modules, environmental meshes designed to snap together in a variety of ways. Modules are most effective for buildings and structures that make regular use of repetition along a grid, but they don't work as well for organic or natural shapes.
For more on how to plan, measure, and construct kits, see Modular kit design.
There are many cases where modular meshes will not connect cleanly, especially if you build off-grid or at non-90 degree angles. Nonetheless, you may still want to preserve certain angles or odd lengths, for metrics reasons or to evoke a gritty dirty non-manufactured natural feel. In these cases, just let the modules freely intersect, and then cover the messy intersection with another object.
For example, imagine you had two rectangular floor meshes that meet at an odd angle -- arrange them to join seamlessly as best as you can, then cover the intersection with a wall, pillar, rock, crate, car, etc. Problem solved!
hero prop / hero building should ground an important place in the level
don't put hero assets in bad places... don't guitar solo a dumpster, it's a dumpster, move on with your life
For multiplayer maps, unique landmarks give identity to an area and help facilitate callouts, short memorable nicknames that players can use to quickly talk about different parts of the map.
Below is a hero asset by Lydia Zanotti for site B on the map Breeze in Valorant. The large tower looks important and in active use, with unique dark metal machinery that contrasts with the beige stone ruins. The design supports the game lore that "radianite" (the glowing teal substance) is an important resource to control, as well as a gameplay function leaving its bottom section free of distracting shapes or silhouettes. Most importantly, it is used only once throughout the entire map, making the area feel special and unique.
for tall forest trees don't put canopy on every trunk and make sure there's detail at the base https://www.gamasutra.com/blogs/DannyWeinbaum/20170216/291658/Art_Tips_for_Building_Forests.php
Readability is about whether the player can walk around your level and "read" what they are looking at. Simplify what the player must see. Make it legible.
The goal is for the player to understand the level as an whole place, not as a pile of random floors and wall segments.
Does the player have enough information to understand the current game state?
Can they easily see enemies / game objects from a distance?
Can they understand whether that enemy is idle, aggro, or hurt?
Can the player understand where they can go vs. can't go, should vs. shouldn't go?
When a level begins in abstract blockout form, it is very plain and easy to read. However, as we add additional visual details to the world, the level geometry becomes less distinct and more noisy. An art passed level that is "busy" will be "illegible" and difficult to read.
In the animated GIF above, notice how the CS map de_cache changed from a dark high-contrast level with shadowy busy details to a brighter more evenly-shaded level with les visual contrast -- that concession to readability makes sense for that game and audience.
Some games such as escape rooms, hidden object games, and prop hunts, are all about the joy of parsing busy cluttered spaces. However, fast-paced multiplayer shooters like Counter-Strike or Valorant depend heavily on split-second reflex aiming and snap judgments, and these players would likely blame an unreadable level for their defeat.
As you art pass a level and apply set dressing, the accumulation of these details can impact the player's understanding of the space.
For example, when art passing the environments in The Last Of Us Part 2, Naughty Dog artists used ivy coverage (see image above) to denote neglected closed buildings, while clearing ivy for open buildings that the player should enter. Also note how ivy flattens the structure of the facade. The player no longer has to inspect every window to wonder if it's navigable or relevant -- a building utterly consumed in ivy means it is closed, and resolves into a green blob. Thus, ivy functions as a simplifies the visual environment and serves as a navigation aid for the player. As long as all the designers and artists maintain consistency in how they use ivy, this decorative foliage effect takes on a new meaning beyond how fancy and expensive the video game looks.
But here's the secret: everything is ivy, everything in environment art has a readability function. When you art pass any part of a level, you are refining the visual patterns that help the player reason about spatial logic.
Readability also heavily depends on massing, metrics, and composition.
To help players parse and understand the game world more easily, try to compose the set dressing in clusters of related details. Proximity, similarity, and implied connectedness helps us see objects as groups and patterns. This corresponds to a gestalt theory of perception.
To make a rocky outcrop, place one rock, then duplicate, shrink, rotate, and slightly offset... and repeat. To make a forest, place one tree, then duplicate, shrink, rotate, and slightly offset... and repeat. You can repeat this workflow for any type of natural set dressing, or even your landscape compositions. Try to build these compositions in an asymmetrical fractal structure, to give a sense of repeated logic and consistency to the prop placement.
Avoid deeply saturated colors, give space for lighting... if you make a very red texture, it can't get much redder. Some games might also reserve specific color coding too (only explosive barrels are red! only doors can be blue and orange!)
Gradients are smooth (not noisy) but still avoid flatness (there is hierarchy)
In the example GIF below of the map "Castillo" from Overwatch, notice how the ground is generally darker than the surrounding walls; wall textures are plain with minimal noisy details; red and pink are generally reserved for floor and roof planes.
A material is a specific technical term for a group of textures imported into a game engine -- but more broadly, "material" also refers to materiality -- the general feel, substance, mass, and physical matter represented by the visual surface.
Ideally, an environment texture should read as a distinct real world material. Does the texture truly feel like it's made of brick or rock? Is it too shiny to feel like concrete? Does the glass or wood feel brittle or strong? Being able to read a material is often important for gameplay; for instance, footstep and bullet penetration are common mechanics in tactical shooter games, and rely on players understanding the material they're walking on / shooting at.
As a general rule, most artists strive to craft textures made of clear and distinct materials. A wood texture should still look like wood from 50 meters away, and a shiny metal texture should feel different from a shiny plastic texture.
For more on textures and materials, see Texturing.
Shape and color psychology are theories that shapes / colors convey universal ideas and influence behavior.
While artists often crave secret power over people, we argue that shape and color psychology are not effective for level design. Abstract geometric shapes and colors, by themselves, do not make all humans feel the same thing nor communicate the same ideas. These simplistic theories fail to capture the rich complexity of art and culture, misunderstand basic psychology, and overshadow much more useful design tools. You're better off without them.
For more, see Shape and color psychology.
There are many ways to approach an art pass, but here's some general advice:
WORK ITERATIVELY in stages, don't try to make the 100% final version of every asset. You need to see how the art assets will relate to each other, in context, to know if an asset is "finished" or not. When surrounded by other art in the game world, sometimes a 50% finished art asset can actually be 100% "finished enough".
ART PASS WITH FOCUS, don't just art pass random parts of random areas. Try to push progress along in specific parts of the level, in specific ways or themes, so you can get feedback on your changes. If you art pass haphazardly in incoherent ways, then it is more difficult for others to give you feedback.
START BIG, and save smaller details for later art passes. Define your basic shapes and massing, color palette, and main themes first. Then after nailing all your fundamentals, you can finally move on to sculpting pebbles or painting grunge marks.
For each animated GIF example below, try to count the number of art pass iterations.
Similar to metric playground maps and modular kit loopback tests, the best way to validate environment art is to try using it in-game. Make a scene or level with every prop / art asset, and walk around in it.
Charles Boury, art director on Caravan Sandwitch, offers this advice for showcases:
I typically create: ShowcaseCharas for every character, ShowcaseProps for an Ikea-style overview of every game props, ShowcaseMats for a grid-view of every material in different light conditions, and ShowcaseUI for a scene where I can play with every UI element.
Note the word "every." Exhaustive lists let you oversee the game content and build confidence. When you work on, say, the pickup UI, you can test it with all pickable items. When you ask yourself, "Is the color red used on a character?", or when the team asks you a specific question like, "how many props use complex collisions instead of simple and why?", you can answer confidently.
As an art director, I'm pushing for a specific style. I don't focus on a single prop or character. I'm constantly looking for the big picture, the artistic unity. So how can I make my life easier for this goal?
I want to see an organised arrangement of all the props to check their palette, silhouette and level of details. A nice warehouse would be neat, with all the game props, nicely grouped by category, arranged on a grid, so I can compare them and chose witch one to improve. What parts of the game need more consistency? How can I play with this kit to create something unique?
-- Charles Boury, from "Scene setup for art direction"
Because Valorant is a competitive multiplayer shooter that depends on precise map balance, Riot tailored their art pass process to preserve the level designer's blockout as much as possible. Before entering art production and detailing phases, Valorant maps go through extensive month-long greybox (blockout) and playtest phases as well as several initial art blockout passes to test color swatches and massing. This art blockout gives extra time for level designers to make more changes to the level geometry, and propagate those tweaks back to the artists with minimal waste. Prolonging the blockout stage improves the final art pass and allows for more collaboration between departments.
Before 3D artists can touch a map, our Art Lead and Creative Director work very high level with the concept artists to iterate on finding an iconic look for our maps using a series of blue-sky concepts. At this stage there's a lot of back and forth between the artist and project leadership to make sure the map follows the VALORANT narrative, is marked by visual variety, and most importantly, is something the team is really excited to be working on.
After a high-level direction has been locked down, concept artists begin to tackle specific locations and call-outs on the map based on the greybox layout. At this stage, the concept artists try to get as much coverage on the map before the 3D artists jump in and begin modeling the basic shapes of the architecture.
We try to model and get the basic architectural shapes into the map before starting to unwrap and texture them. When we start to add colors on the meshes, we make sure that they aren't too dark, especially in interior spaces. The objective here is to maintain gameplay integrity by making sure that the environment doesn't impede with clarity, and that the characters are always clearly visible.
As far as texturing goes, we primarily use tiling textures and trim sheets on our buildings and large structures. These are created using a variety of programs such as Zbrush, Substance Designer, Substance Painter, and Photoshop. We do use custom textures on props when needed, such as the coffee machine in the kitchen, or the forklift near A-site.
[...] To help with visual noise, we make sure that our materials are similar in value and there isn't too much contrast or darkness. We can also improve clarity by using lights to illuminate dark areas, or to spotlight spaces where you would want the most visibility possible, such as a Spike plant site or a commonly peeked corner.
-- from "The Art of Valorant Map Environments" by Lydia Zanotti
Environment art is about decorating and refining the visuals of a level.
Industrial artists tend to do a lot of planning in the form of concept art, paintovers, and model sheets. Based on those plans, they generate an asset list so they can figure out how much work they have to do.
Common environment art assets include world textures, modular kits, hero props, and general set dressing props like foliage and clutter.
When making assets, artists should consider readability: how an object's visual appearance suggests affordance (functionality and usefulness). To improve readability, cluster details together in groups, pay attention to color and value, and make sure materials read clearly.
We argue strongly against shape and color psychology.
How to art pass:
focus on swapping-in big important common core objects / shapes first
do not try to finish each asset 100% one-by-one, instead it's better to work iteratively: get multiple objects to 50%, then step back and evaluate
Continue on to Release.
Stop reading a level design book, and go find an environment art book / website instead.
Read more about a certain aspect of environment art in more detail...
Working environment artists often specialize in one aspect:
Modeling and sculpting. Hard surface architecture and props, or nature and foliage?
Lighting heavily affects how players perceive shape, depth, space, and mood.
Is that wall far away or close by? Is this room shallow or deep? Is it scary?
is important for reading shape, surfaces, and materials.
Is that wall made of wood or metal? ... Alien metal? Are there aliens nearby?
Storytelling and set dressing give a sense of place / lived-in feel.
After an art pass, levels often require optimization.
Remember, this is a level design book, not an env art book. You should definitely go somewhere else to learn more.
For links to environment art sites, see Communities: Environment Art.
Environment Art blog by Rogelio Olguin (discontinued since 2016, but still lots of good stuff)





























































The proportions and distances of the level, how big the level feels
In level design, metrics are the sense of scale, distance, and measurements across the entire level / game.
All level designers use at least two types of core metrics:
Player metrics (or physics metrics) are factual numbers measured in-engine like player size, movement speed, maximum jump height, etc.
describes game physics, derived from the game engine
example: "player size" is a specific fact that can be measured and verified
Building metrics are suggested floor / wall dimensions and guidelines that you codify for yourself based on your desired
prescribes game feel, decided by designer(s)
example: "regular hallway size" is a guideline; what does "regular" mean for each project?
Depending on the project, you might need combat metrics or puzzle metrics too.
But beware of over-reliance on metrics. Numbers and measurements may give the illusion of infallible design laws -- the illusion that following these numbers will give you the perfect level. You must reject this illusion! You cannot measure your way to a good game experience. Metrics are a helpful design tool to help you make decisions, but metrics are not magic.
Metrics help you establish scale, the general sense of how big the game world feels.
In level design we usually follow real world architecture built at a . That means making sure rooms don't feel too small or too big for people. Proper scaling is very important when working in a realistic style, because it makes the level feel more plausible -- it will feel more like a real place built by humans and inhabited by humans.
But imagine a game about being a cat, it would need some rooms that feel too big (because cats are smaller than humans.) Or imagine a car game -- it would need houses that feel too small (because cars are bigger than humans).
For games we "build at the player's scale", which may or may not be a human scale.
The human scale is helpful, but video game spaces are not human. Video games often rely on an exaggerated sense of scale that does not correspond to any consistent real world measure.
In Doom, the player ("Doomguy") is 32 pixels wide, which translates to 1 meter wide. The shotgun is 63 pixels long, which is almost 2 meters (6 ft. 5 in.) long. Oh, and Doomguy runs at 30 units per frame, which is 40-50 MPH depending on which you use. Either way, , but it feels nice to play anyway.
In The Elder Scrolls: Skyrim, the world area is about 14 square miles, the tallest mountain is 766.5 meters above sea level, and the player runs (not sprints) at 11.7 mph without tiring. That means the entire "province" of Skyrim is half the size of Manhattan, the tallest mountain is shorter than the Burj Khalifa in Dubai, and every peasant is a high performance marathon runner. By any real world measure, it is very small and weird. And yet, Skyrim somehow still feels like a large vast natural landscape with a huge alpine mountain, populated by typical people of average fitness.
So when building video game spaces, remember that it should merely "feel" realistic as part of the mood, atmosphere, or aesthetic.
But if you approach level design too much like real world architecture, then ironically, your levels will feel too big, complicated, and implausible.
Don't follow real world scale.
"Big" levels feel big, but are actually much smaller than in the real world.
Players regularly move at very fast speeds... that feel normal in the game world.
The game world feels internally consistent, even if the specific numbers seem silly to think about.
Unfortunately it's not scientific. You'll only know "it feels right" when you're walking around inside your level and playtesting.
That's why we recommend considering metrics at the phase. You can't really test metrics with a paper layout, but if you wait too late (like after an art pass) then it will be very time-consuming to make big changes. You might even have to redesign the entire level.
In theory, you can build your game or level at whatever scale you want. In practice, physics implementations assume a default scale, and asset stores supply environment art at a common humanoid scale. Following convention is... convenient.
Bounding box / collision sizes are usually much bigger than the actual character model. This bigger thicker size is for more stable movement. It's not a hitbox.
Note that in-game eye height is usually below where actual eyes would be. Many FPS games put your eyes in your neck or chest. For more detail, see .
* Quake, Half-Life, Source Engine / "Quake lineage" games use "inches" lightly (eg. ) and don't really make sense.
The minimum hallway width should be at least double the player width. Even then, it will feel a bit narrow and uncomfortable.
Modern doors should be narrower than hallways to allow space for a door frame.
Modern flights of stairs have landings / platforms every 12-16 steps. Long or tall stairs will feel industrial, monumental, or otherwise non-domestic.
Deviate meaningfully from typical metrics, proportions, and spaces.
Steep stairs will feel more harrowing and awkward than shallow stairs, and if that's the you want, then go for it. Often the best part of a level is the uncommon and unexpected. But to make something feel unusual, you must contrast it with enough usual common elements first.
Even with stylized non-realistic art styles, metrics still need to feel internally consistent to the game world / design norms. For example, the steps in Quake 1 maps are often 16 inches tall, but the rest of the game world is appropriately big and chunky to match that proportion.
Do on the type of architecture you're using. For example, traditional Japanese architecture uses the proportional system. Italian Renaissance architects used the golden ratio (1 : 1.618) in the vein of Ancient Greek and Roman architecture, etc.
For more information on planning, see and .
Some ways to bring metrics into your level design process:
Build a metrics zoo test map
Prototype core player metrics
Use world-aligned grid textures
Test modular kit
Build a "metrics zoo" / "metrics playground" developer-only test map that exhibits the different gameplay objects, modules, and prefabs across all your levels.
. Make a simple level with various rooms, hallways, and floor heights.
Playtest for usability. Walk around with gravity, jump on objects, be a general nuisance.
Playtest for feel. Pay special attention to the sizes of walls, doors, and floors. Does the height of the stair steps feel right? Do doors feel too narrow or too short?
.
Basic movement
Walk speed, run speed
Maximum step height, maximum angle slope incline
Minimum hallway width, minimum ceiling height
When blocking out, use some kind of world texture with a little surface detail.
Do not use flat solid colors, these lose visual scale and depth cues while prototyping.
Do not use detailed textures, these are visually busy, can distort scale, and are distracting.
We recommend using placeholder grid / checkerboard textures, anything with repeating lines at regular intervals that will help you eyeball distances and proportions as you build your blockout. Check our for links to various prototyping texture packs.
While building, make sure the texture scale stays constant and independent of the 3D object scale.
To ensure a constant scale in your game engine:
Quake / Half-Life / Source: make sure your level editor's "texture lock" is disabled, and set all brush faces to use world axis alignment. For , see .
Any modern game engine: configure the shader or material to use a triplanar projection with a tilting grid texture. This has the added benefit of automating UV unwraps across all objects, so you can focus more on geometry rather than texture alignment.
Unity: visual shader editor has a built-in , or to go deep on coding your own shader see
With a modular kit, you build a level with pre-made tiles and components that snap together.
What's the best size for a doorway? You don't have to worry anymore; that metric is baked into the doorway module. In modular construction, you measure once, and basically copy-and-paste that measurement across the entire level.
However, it is common to iterate on a modular kit on the fly -- adjusting tile sizes and measurements, refining and art passing modules later, etc. If you make big changes to the modular kit's design assumptions, such as tile grid size or granularity, then you will likely have to rebuild everything because the new kit won't work for levels that used the old kit.
The best way to test the metrics and scale of a modular kit is to use it! Blockout with it, try to build hallways that loop back on themselves, then playtest and walk around in it.
For about modular construction, see .
For action games with a heavy focus on player movement and platforming, it can be difficult to predict whether a wall is too high to jump, or a gap too wide, etc. An in-editor metrics measurement tool / visualization / trajectory preview can help resolve these ambiguities.
For Psychonauts 2, developers implemented a "jump preview" editor visualization so that level designers could easily predict a player's jump arc:
"The jump metrics tool is designed to be placed into the level when the game is not running to visualize Raz’s jump arc. This can be used to help place objects along an action path so they’ll be reachable by the intended jump type. The tool runs the jump simulation code at edit time, while the game is not running. Any changes to the jump tuning would be reflected by the preview arc."
-- Devin Kelly-Sneed,
Beyond player metrics like maximum movement speed or jump height, you can also set recommended building metrics for yourself as a guideline -- and these shared guidelines across a design team can help make construction and collaboration easier. Some examples:
What is "close range" or "long range"? How big is a "big fight"?
How tall is , how high should a window be?
How long should each map or chapter be altogether? How far should the exit be, how much backtracking should be allowed?
How far apart should the various map objectives be?
How many resources or rewards can be placed in each stretch of the level?
How long is this NPC dialogue, and how far can the player travel while they are talking?
How many narrative assets such as audio logs, readables, codex collectibles, etc. should be placed in a given part of the level?
metrics
If we are streaming in chunks of level data, how big should each chunk be?
How long does the level transition hallway or sequence need to be, to mask the level streaming time?
How many different meshes, materials, or shaders, can we load for each level?
Some example combat metrics for Team Fortress 2, based on :
Close range weapons: 256 units or less
Medium range weapons: 1024 or less (and projectiles become easier to dodge, etc)
Rocket spam and snipers: 2048
Maximum drop height without fall damage: 256
These metrics are reflected in the arena design of Team Fortress 2 maps like Badwater Basin below. Most drops are 256 units high, with maybe a few drops at 320 to apply a small penalty for any falling players. However there aren't many 512 unit drops because that would limit player options too harshly, and also render close range weapons much less effective.
For examples of detailed metrics, see and .
What affects the player's perception of size and speed? Basically anything on the screen.
"Some animals are lightning fast. Others are pitifully slow. But slow and fast are relative terms. Four miles per hour doesn't feel very fast to a human: it's approximately one body-length per second. But to a small insect it's approximately 100 body-lengths per second. A human traveling that fast would be going 20,000 miles per hour! This is why some animals' brains process visual stimuli much faster than ours, and why they have better reflexes (think about how hard it is to swat a fly). What does it feel like to comprehend the world at such speeds?" -- Alex Reisner, creator of
If you are prototyping a game, finalize the camera height / eye offset as soon as possible, because it will affect how big the entire game world and all its characters feel. The camera height is one of the key variables that affect the player's sense of a virtual body, because "slow" and "fast" are relative to body size.
For suggested eye heights, see the section above.
TODO: more local context, objects along the line of movement
Your sense of perceived speed depends on how much you are seeing and the rate of visual change within your vision. A high (FOV) will zoom-out to produce fisheye distortion that increases apparent speeds at the edge of the screen (periphery).
Note that there are three ways to measure field of view -- horizontal, vertical, and diagonal -- but for games we generally refer to the horizontal FOV so that it scales well with widescreen setups.
Some players prefer high FOVs because they can see more of the world around them and gain better situational awareness, and there have also been studies that suggest a high FOV helps some players mitigate motion sickness while playing first person games.
On top of the base FOV setting, many third person action games shift to a higher FOV when the player sprints or accelerates. This FOV change gives a greater sensation of speed, even if the actual speed increase is negligible. In contrast, some virtual reality games purposely occlude and mask peripheral vision to decrease this sense of acceleration and mitigate .
The default Quake (1996) field of view was 90 degrees, and competitive players often set their camera to 120 degrees so that they could see more of their surroundings. This made more sense when CRT monitors and TVs had a 4:3 aspect ratio, but feels different on a modern 16:9 widescreen display.
Today, most commercial 3D action games tend to offer accessibility settings with an FOV range slider for users to adjust the camera to their personal comfort, usually between 60 and 90 degrees, but default to a narrower FOV. A high FOV distorts the image in an unrealistic / unflattering way. Meanwhile, a lower FOV zooms-in and "flattens" the view depth, giving a greater sense of closeness and intimacy with the game world. If your game is about looking up-close at characters' faces, you would err on a narrower FOV so that the faces don't look strange or distant.
Portrait photographers often try different lens focal lengths to get the most flattering distortion and closeness with their subject. 20 mm (84° FOV) narrows the face with extreme proximity, 70-100 mm (29-20° FOV) is more naturalistic, and a long 200 mm (10° FOV) telephoto lens widens and flattens the face with a longer distance from the subject.
The brain processes all senses together. Vision isn't just a matter of seeing, it is also a matter of sound, memory, knowledge, etc.
To demonstrate, there is involving two identical circles sliding past each other to swap places. Without any sound, the circles will appear to be just exchanging positions, but if you play a collision sound when the circles intersect, then the circles will appear to collide and bounce off each other instead.
For a more direct example of how other stimuli affect our sense of speed, consider the ZX Spectrum port of Super Hang-On (1987). In this single player motorcycle racing game, the "turbo" button temporarily increases the player's max speed limit to 324 km/h, beyond the normal limit of 280 km/h. However, the game does not render faster nor does the player actually move faster; instead, the engine sound gets louder, numbers get bigger, and opponent NPCs slow down. These contextual cues combine to give a faster feel without actually adjusting the camera nor the player.
A game industry practice known as rational game design (RGD) / rational level design (RLD) focuses on measuring metrics to plot parameterized game mechanics against game difficulty in a coordinate space, with the goal of mapping out a game's possibility space in a quantified way.
Basically, give everything in the game a number, and then add up all the numbers to help guide your design decisions. If you don't like how the numbers add up, change them. This general workflow looks like:
Design game mechanics, and identify various parameters and modifiers.
Plan levels across the entire game with different combinations of mechanics and modifiers.
Quantify parameters for each mechanic (e.g. 0% difficulty jump is a 3 m wide gap between platforms, while a 100% difficulty jump is 10 m wide, etc.)
Iterate on each level's metrics to conform to desired difficulty scores and target values.
Supporters claim this design method represents a more "rational" and "scientific" approach to plotting and pacing the player experience. Unfortunately there are very few public resources on how to practice RGD, which is convenient because that means we can't actually evaluate its methodology or claims -- its evangelists can always claim that we haven't read the proper holy scriptures, and so we don't truly understand how to practice it. What little documentation here is cobbled together from the few articles and resources available online, with much of the material guarded as a trade secret by Ubisoft.
We caution against any uncritical belief in any single design method, especially something that touts supposed objectivity / ahistorical understandings of "form follows function." And we remain skeptical of any method that claims to capture conceptual depth with a number. The more technical the design formula, the more formulaic the design will be -- a common critique leveled at many Ubisoft games.
But if RGD / RLD serves as a useful design tool that yields good results for the type of game you're making, then there's no harm in using it with moderation. Collecting data, measuring spaces and distances, and playtesting are all certainly good design practices. Just don't drink too much of this rationality Kool-Aid.
Metrics are useful measurements to help blockout levels at a consistent scale. If a level feels weird or awkward to play, it may need better attention to metrics.
To recreate a real world place, don't copy the exact measurements -- video game scale is often weird and inconsistent. Instead, scale depends more on your intuition of "what feels right."
To use metrics, blockout a metrics test map / zoo / playground with simple gridded textures, and then walk around in it. If you're using a modular kit, then build a test level and walk around in it, to make sure the modules are at the right scale and dimensions you need.
The most important level design metrics to consider are usually player physics metrics like movement speed, stair step height, and jump distance. You'll also probably want common building metrics like typical doorway width, window height, wall height, etc.
Metrics reflect human perception, which is affected by anything on screen or even game audio.
Many metrics are just "good numbers" and guidelines you give yourself, they're not a scientific infallible way to perfect level design. Metrics are useful, but metrics are not magic.
Use metrics to build a .
Examples of detailed metrics breakdowns:
health and damage values, common sizes and dimensions for Doom maps
Below are some core gameplay values and numbers that are useful for level design in Doom / Doom 2.
However, keep in mind this is an action game with aiming and dodging -- so the actual damage and damage per second (DPS) will depend heavily on enemy behavior, available cover, height changes, enemy composition, etc.
For more on what metrics are and why they're useful, see Metrics.
Doom uses a grid with power-of-two numbers (e.g. 8, 16, 32, 64, 128, 256...) and textures are designed to work in increments of 8, 16, or 32.
stretched vertically by 20% with non-square pixels for a 4:3 display. Today, this results in a lot of its art assets to appear vertically "squished". It also distorts any attempt at a coherent real world scale for Doom, which we can guess at: 16 horizontal Doom units = 10 vertical Doom units = 1 foot = 0.6 meters.
Maximum map size: to calculate distances, Doom uses 16-bit signed integers which have a maximum value of +/- 32767. However, if you actually built a map that stretched from -32767 to +32767 (across 65535 units!) and somehow tricked the engine into running it, then it would still break other distance calculations like a monster's line of sight, because a value of 65535 would past +32767 to become 0. For best results, keep all map geometry within 16384 units of the (0, 0, 0) origin.
Doom randomly simulates damage values by rolling virtual dice with each hit. For the shotguns, there's an additional buckshot spread simulation where each pellet must connect with the hitbox for full damage.
The damage per second (DPS) is a rough estimate based on the fire rate multiplied by the average damage per shot.
Most maps begin with players killing low health enemies with the pistol and shotgun. Eventually the player relies more on the chaingun, super shotgun, and rocket launcher, while occasionally switching to the plasma gun for tougher enemies.
The rocket launcher, plasma gun, and BFG are usually less effective at very long range because of the lag built into their projectiles' travel time. At long distances, a monster can move out of the way before getting hit. Doom's and randomized monster movement also means it can be tricky to lead shots. You can balance long range encounters toward the player's favor by placing monsters on pillars with no cover, limiting their ability to dodge the player's projectiles.
Monsters can look in cardinal (N, E, S, W) and ordinal (NE, SE, SW, NW) directions, essentially in 45 degree increments. They have a 180 degree sight cone based on their initial facing, and can hear combat sounds based on areas bounded by set to block sound.
If set to "ambush" mode, monsters have a 360 degree sight cone and ignore sounds.
Minimum hallway size is given as (monster width + 2) x (monster height + 2) but in practice, your hallways should usually be much wider since monsters might "step" in larger increments, and monsters block other monsters. Narrow off-angle hallways will force monsters into slower zig-zag movements, because remember, they can only turn and move in 45 degree increments.
Stairs are tricky for monsters. In general, steps with long depths and shallow rises are always more dependable. Step height must always be 24 units or less (or else the monster won't cross) and minimum step depth / maximum slope is proportional to the monster width. For example, for a step that is 24u high, a trooper requires a step that is 33u deep (35 degree rise, 2:3 ratio) while a demon is wider so it requires 51u deep (25 degrees, 1:2 ratio). If you want to see the bounding box calculations yourself, see the PCheckPosition() and PTryMove() functions in of the Doom source code.
To simplify building for monsters, we generally recommend:
Minimum hallway size: 128 wide x 128 tall, mostly built orthogonally at 90 degree angles to align with the grid with occasional 45 degree angles.
Stairway step size: 16 high x 64 deep (15 degree rise, 1:4 ratio) or 8 high x 32 deep.
Monsters will use melee attacks within 64 units of their target, though the Revenant will attempt to use a melee attack within 196 units even if the target is too far. If further than 64 units, then monsters with ranged attacks are more likely to use attack the closer they are to the player, up to a maximum distance of 2048 units. But the Arch-vile has a particularly dangerous ranged attack, so it will only attack within 896 units.
When hit, monsters have a random chance to be stunned in a -- weapons with fast fire rates (chain gun, plasma gun) or multiple projectiles (shotgun, super shotgun) are particularly good at stunlocking monsters and interrupting their attacks.
For much more on monster behavior and debugging, see .
Doom 2 includes all the Doom 1 monsters, and added more mid tier monsters designed to survive longer and interact with other monsters.
An influential Doomworld poster Linguica offers these helpful design thoughts on Doom monster design:
... Doom 2 monsters are great. They nearly all enhance the gameplay along one or more of three axes:
time awareness - what is happening that I need to immediately address?
immediate spatial awareness - what is in my close vicinity right now?
general spatial awareness - what is the architectural layout, like walls, buildings, etc, in my area?
This page uses data from , under CC-BY-SA 4.0 International license.
by Scott Ampoker
Models, textures, sounds, tutorials, and other links for Quake mapping and modding
How to build a basic 3D version of the level with massing, metrics, wayfinding, and playtesting.
A blockout (also blockmesh or graybox) is a 3D rough draft level built with simple 3D shapes, but without any details or polished art assets.
The goal is to prototype, test, and adjust the foundational shapes of the level.
In the image below, notice the differences between the blockout version and the final shipped version. A shape might start as a gray block -- then after months of and , the block becomes a stack of barrels... or maybe gets deleted entirely.



Inches?*
32 x 72 in
64 in
(US, real-life)
Inches
20 x 69 in (average adult)
66 in
110 x 220 cm
15 x 25 cm
Quake / Half-Life / Source Engine
16 x 128 in
64 in
56 x 112 in
8 x 12 in
(US, real-life)
6 x 96 in
48 in
36 x 80 in
7 x 11 in ("7-11")
arctan(7/11) = 32 degreesIn Source 1 and older engines, level grids followed power-of-two numbers. Unity users often prefer 1.0's and 10's. Unreal users are split based on their age. Use whatever number roundings that you and your collaborators prefer.
When building in a realistic modern style, do some research beforehand: gather plans, blueprints, schematics, or even read through local building codes.
Metrics debug tools, editor previews
Codify shared building metrics
Jump, fall, drop, height
Maximum jump height, maximum jump distance, running jump distance
Gravity strength, fall speed
Fall damage height threshold for 1% damage vs 100% damage lethal fall
Unreal: material editor has a built-in WorldAlignedTexture Node, or to go deep into coding your own shader see Ryan DowlingSoka's post "Triplanar, Dithered Triplanar, and Biplanar Mapping in Unreal"
Unity
Meters
1.0 x 1.8 m (or 1.0 x 2.0 m)
1.5 m - 1.7 m
Unreal
Centimeters
60 x 176 cm (half-height: 88)
152 cm (88+64)
Unity
0.1 x 3.0 m
2.0 m
1.25 x 2.5 m
0.1 x 0.15m
Unreal
20 x 300 cm



Quake / Half-Life / Source Engine
150 cm
Average map size from Doom 1, Episode 1
~4000
Maximum map size (recommended, minimal glitches)
32767 (+/- 16384)
Maximum map size (technical, buggy and unstable)
65535 (+/- 32768)
0-32
2 punches
20-200
220
Chainsaw
Melee
0-33
9 revolutions
2-20
90
Pistol
Hitscan
0-512?
2.5 bullets
5-15
25
Shotgun
Near
0-192?
1 shot (7 pellets)
5-15 * 7 =
35-105
70
Super Shotgun
Close
0-128?
1 shot (20 pellets)
5-15 * 20 =
100-300
150
Chaingun
Hitscan
0-512?
9 bullets
5-15
90
Rocket Launcher
Mid / Long
128-512?
1 rocket (+ 128 range splash)
20-160 +
0-128
150
Plasma Gun
Mid
0-384?
12 cells
5-40
270
BFG 9000
Mid
0-384?
1 shot (+ 40 tracers, 1024 range)
100-800 +
49-87
~1200
33
(shotgun guy)
30
68%
42 x 58
33
(fireball demon)
60
80%
42 x 58
33
(flying skull)
100
100%
34 x 58
--
/ (fast pig)
150
71%
62 x 58
51
(big flyer)
400
50%
64 x 58
--
(hunky goat)
1000
17%
50 x 66
41
(boss)
3000
13%
258 x 102
254?
(final boss)
4000 (+50% rocket resist)
5%
82 x 112
74?
33
(big flyer, spawns Lost Souls)
400
50%
64 x 58
--
(baby spiderdemon)
500
50%
130 x 66
124?
(weaker Baron of Hell)
500
17%
50 x 66
41
(big flamethrower monster)
600
31%
98 x 66
90?
(flame zombie, resurrects monsters)
700
3%
42 x 58
33
Now let's look at the new Doom 2 monsters and what they bring to the table:
The Chaingunner is a "low-level" enemy that even a more advanced player needs to worry about, because especially en masse, they can really wreck you quickly. There is a time awareness factor because if you don't take care of them quickly, your health will be severely eroded. There is also an element of general spatial awareness in case you need to retreat behind cover.
The Mancubus's offset fireballs mean you can't just rely on mindless strafing around projectiles and actually need to pay attention to them, or else you can end up running into one. This implicates your immediate spatial awareness. (Did you end up learning the "Mancubus dance" of strafing left-right-center? Then congratulations, the game taught you a new behavior.)
The Arachnotron's rapid-fire plasma also implicates immediate spatial awareness because if you're doing any strafing back and forth, you have to watch out for "crossing the stream" and being hit in the process. Do you think it's a coincidence the Mancubus and Arachnotron are introduced in quick succession on the same level, which also includes no other enemies? I don't think so. Both enemies make you do more than the Doom 1 hallmark of simple strafing around a single fireball. The game is telling you, in case you haven't gotten the point yet, that this is not going to work anymore.
The Pain Elemental is a annoying enemy, yes, but it is there purely to implicate your time awareness - it can't even hurt you directly! Its danger to you is directly proportional to how long you let it stick around.
The Revenant's homing missiles, again, mean you can't just rely on mindless strafing around projectiles and actually need to pay attention to them, which involves your immediate spatial awareness, and you also need to keep mindful of available cover so you can get rid of the homing fireball, which involves general spatial awareness. You could even argue it involves your time awareness, since if you let a large number of homing fireballs accumulate, they could end up killing you instantly. (Or, perhaps, another enemy??)
The Archvile's fire attack strongly implicates your general spatial awareness and time awareness - you need to know where cover is, and you need to get there immediately. Furthermore, its secondary behavior of resurrecting dead enemies involves yet more time awareness - if you leave it alone too long, it's going to being back all those enemies you already went to the effort to kill.
The Hell Knight is the only new enemy that doesn't make the game tactically deeper along one of these axes. It's just a Baron of Hell without being quite so tedious to fight as a real Baron. This does give mappers a new option for when and how to use the Baron, though, which is a good thing.
-- Linguica on 28 August 2014 in thread "Doom 1 or Doom 2?" on Doomworld
Rockets
(1)
(5)
(2)
Cells
(20)
(100)
(40), (40)
Hallway (very narrow), crate, teleport pad
64
Hallway (narrow), big door, wall textures
128
Small room
256-512
Medium room
512-1024
Large room
1024-1536
Fist
Melee
0-32
2 punches
2-20
22
Berserk Fist
Player
100
--
33 x 58
1
Zombieman (trooper)
20
80%
Heavy weapon dude (chaingunner)
70
68%
42 x 58
33
Revenant (skeleton with missiles)
300
40%
Bullets
Clip (10)
Box of bullets (50)
Zombieman (5, or 10 on Hard+)
Shells
4 shotgun shells (4)

Melee
42 x 58
42 x 58
(8), (8) (in )
If you're interested in Quake mapping and modding, we strongly recommend joining a Quake community. It's the best way to learn! Experienced people can give you tech help, advice, and feedback on your work. Some have even been modding Quake for 20+ years.
Quake Mapping Discord is the biggest public social hub, beginner-friendly with frequent single player design jams and social opportunities
For Quake 2, try Map-Center discord instead.
For multiplayer Quake, try QuakeWorld.nu and Quake.World discord instead.
is a new single player mapper-modder hub with downloads, assets, and free file hosting services.
is the main single player Quake map archive, currently in the middle of an extensive rebuild (as of 2024).
is the longest running Quake level design web forum, but maybe not as newbie-friendly as QM Discord or Slipseer
is a long-running podcast series where David "dumptruck_ds" Spell interviews various Quake community members and discusses new releases
get TrenchBroom level editor (included in Level Design Starter Kit linked above)
most people start with
or start with (covers basic setup + making your first room)
after you know the basics, check out the by MarkieMusic
for useful map measurements and combat stats + design advice, see Quake metrics
for more about releasing maps and mods, see How to package a Quake map/mod.
After you know the basics of map construction and feel somewhat comfortable in the editor, learn about more complex design and building patterns:
"How to Make Rooms Look Good" (2001) on Quake architecture by Xenon
"Curve tutorial" (200x) on building "CZG curves" by Christian Grawert
"Mapping for Quake: Advanced Curves" part 1 video + part 2 by David Spell
by MarkieMusic
(2019) by Andrew Yoder is a solid introduction to tuning Quake
(2024) by Lunaran is a good primer for various item placement / traversal design patterns
(2021) series about Quake culture by Robert Yang
(id Software industry history)
(25 years of Quake mod history primer)
(2022) by Benoit "Bal" Stordeur is a crucial must-read for intermediate / advanced Trenchbroom construction techniques.
for more on Quake's influence on level design, see History of the level designer
To play Quake maps, you must compile (bake, package) the editable .MAP into a playable optimized .BSP file. You will need both tools and a graphical user interface (GUI).
Compile tools: EricW Tools (already included in Quake Level Design Starter Kit)
qbsp.exe builds 3D mesh + detects "leaks" (video tutorial: how to fix leaks)
vis.exe calculates PVS occlusion culling to optimize map performance
light.exe bakes lightmaps and shadows, makes happen
STRONGLY RECOMMEND viewing +
Compiler GUI: choose either or (both already in the kit too)
many mods package .MAP source files with the public release, just look in the mod folder
trenchbroom_quake_map_source.zip (4.5 mb download) is a collection of the original Quake 1 .MAP source files (as released by John Romero in 2006) but converted to modern file format (TrenchBroom compatible) + fixed texture references (with repackaged Quake101.wad), thanks to Atul "toolness" Varma
for more about parsing and working with .MAP files in code, see .MAP file format
To play Quake (and playtest your own maps or mods) you need a source port -- a Quake engine that "ports" the original 1996 engine code and add many new features / compatibility.
We only list free open source ports in active ongoing development. (see full list of source ports via QuakeWiki.org)
current community-standard engine for single player; bundled in Quake Level Design Starter Kit
previous community-standard engine for single player
many features + wide compatibility beyond Quake 1 file formats, good for making standalone games
common multiplayer Quake ("QuakeWorld") bundle but lacks many single player / graphics features
In Quake modding culture, it is generally considered normal and acceptable to rip models, sounds, and textures from other maps and mods, as long as you credit the original authors.
However, if you rip textures and assets from a .BSP, you'll usually have an incomplete fraction of the full kit. It'll likely be difficult to use. In these cases (e.g. the Makkon set) you're better off finding the full official public texture releases.
Quake texture collections are stored in .WAD files. To use textures in a level, download a .WAD and then add the WAD path to the .MAP file using the level editor. (Note: this is not the same as a Doom WAD. Quake WADs are only for map textures.)
When compiling a map into a playable .BSP file, all used textures are automatically embedded directly inside the .WAD file. You can rip textures from compiled maps using a tool like BSP2WAD.
Prototype WAD by Khreathor is useful for blockout and prototyping.
Quake101 WAD contains all the Quake textures in one collection, or you can just download the textures used for each map if you want to stay strictly within a traditional theme.
Knave is a medieval library themed texture set by Kell
is the current most-popular texture set used in community Quake maps today
Quaddicted WAD archive contains many .WADs but it's somewhat unorganized.
Quaketastic has a similar pile of unorganized WAD files
Slipseer has a small but growing archive of better organized WAD files
If you are going to modify WADs frequently, you can automate the WAD building process via batch processing via command line interface (CLI) with qpakman.
Use TexMex or BSP2WAD to extract textures from a compiled .BSP map file
Palletizing textures to fit Quake's fixed 256 color palette is tricky, because some of the colors are reserved as "fullbright" colors. You may also need EricW's tool to remove these fullbright pixels.
Quake has two different sky systems. The original 1996 sky system is a two panel texture parallaxed over itself. Newer Quake engines support a more standard cubemap-style skybox made of 6 static .TGA textures, each corresponding to one side of the skybox.
Mods add new functionality and features for mappers to use in their levels. Listed below are common Quake mods and toolkits used by single player Quake mappers.
Arcane Dimensions is a popular recent mod / toolkit that adds many new monsters and features.
install the latest version of Arcane Dimensions (v1.81 as of January 2022) if you want to make your own mod based on AD, get the slimmed-down dev kit instead
add the /ad/ mod folder and ad_1_8.fgd in your map editor
read the included ad_v1_80_documentation.txt for info and advice
open the in an editor to learn how to use the new systems
the
Alkaline is a recent "base" themed mod / toolkit that adds sci-fi themed monsters and weapons.
install latest version of Alkaline (minimal dev kit available)
add the /alkaline/ mod folder and alkaline.fgd in your map editor
read the included docs.html Alkaline mapping manual
Copper is a minimalist "refinement" mod that rebalances vanilla Quake gameplay and adds quality-of-life features for mappers. It is good for a "vanilla+" feel without vanilla bugs.
install latest version of Copper
add the /copper/ mod folder and copper.fgd in your map editor
read the official Copper - Mapping notes for info and advice
Progs_dump is a recent dev kit mod that adds new mapper features, but doesn't add any new monsters or weapons, it's still basically the same old vanilla Quake gameplay.
However, because it exposes so much functionality, it's possible for mappers to add some new game features without coding in QuakeC.
To map for the new "Horde" mode added in the Quake 2021 re-release:
download the special Horde mode .FGD file and load it into your map editor
in the editor, add a single horde_manager entity, this is the brain of horde mode
in the editor, add info_monster_start entities for where you want monsters to show up. You can also toggle a info_monster_start, which lets you do progression stuff.
See the example Horde mode .MAP source file for usage:
for a list of 3D art tools, see Tools
To make custom monsters, weapons, items, or props, you must export a 3D model.
The original Quake models are stored in .MDL files in a sub-folder called /progs/ . The MDL format reflects the memory limits of 1996 PCs:
Max triangles: 2048; max vertices: 1024
Textures: 8-bit palettized; max UVs: 1024
Max vertex animation frames: 256 at 10 FPS
for more info on MDL file format and parsing, see Quake MDL file format spec
The 2021 re-release, as well as more recent fan engines, have added much more modern MD5 (Doom 3 format) file support with much higher memory limits and skeletal animation support.
Model data stored in .md5mesh file
Animations stored in .md5anim file; can load multiple .md5anim files for one model
Textures are .tga, bind with .mtr material definition file
works in 2021 re-release engine ("KexQuake"), Quakespasm-Spiked, and FTE
Get the Quake MDL importer / exporter for Blender v2.8+ by Taniwha, Khreathor, and Jazzmickle.
see docs for installation, scene setup, material setup, and animation notes
Fairweather has made some great beginner video tutorials on using Blender to model for Quake, no prior Blender or 3D experience required:
Get the MD5 Importer/Exporter for Blender 2.80+ by KozGit.
read the documentation thoroughly, it's a little complicated
community is still figuring out best practices / pipeline... ask questions and shares notes in QM Discord #modeling-and-texturing
Quake game code is written in a special programming language called QuakeC. It has many historical quirks and it can be tricky to learn, but once you figure it out, it's fun.
"clean and fixed" original Quake v1.06 source code with bug fixes: https://github.com/Jason2Brownlee/CleanFixedQuakeC
useful as a base for a vanilla style mod
progs_dump mapping toolkit source code: https://github.com/dumptruckDS/progs_dump_qc/
official 2021 re-release source code:
There's a VS Code QuakeC extension by Joshua Skelton.
FTEQCC is probably the most modern compiler available, with plenty of compilation options and enhancements. You can choose between GUI version and a command line version:
Blockouts support experimentation.
It is "cheap" to delete or rebuild some rough blockout geometry, but throwing away finalized art passed work is "expensive" and wasteful.
When you are not confident about the level structure, it is best to keep it "cheap" until it is ready to become "expensive."
You can't playtest a design document or a layout sketch, but you can playtest a blockout and evaluate its flow, balance, encounter design, and metrics. This is the design phase when you finally start to discover whether the ideas will work or not. The blockout is just the beginning.
"... If we consider that [Neon White] shipped with over 100 levels, the team made “double” that amount in scrapped levels, and [the level] Smackdown alone had more than 50 changes made to it, we’re faced with thousands of tweaks and redesigns throughout the entire game. [...] Three years later, Smackdown is complete."
-- from How A Neon White Level Is Made by Blake Hester, Game Informer #350
When blocking out, consider these aspects:
Massing is the general sense of volume and weight conveyed by the shapes.
Is this structure thick / heavy, or thin / light? What kind of place is this?
Landscapes need special consideration.
is currently over-emphasized in level design culture today.
are the general scale, dimensions, and proportions of the level.
Is this area too big or small? Can the player fit in this room?
examples of useful measurements: ,
is the player's navigation process for learning the map structure.
How to help the player find the / level exit? Does the player feel too lost?
is when you run an experiment to see if the level meets its design goals.
Can most players complete the level? Do the work? Is it ?
Playtesting is really important. This is the whole point of making a blockout.
There are five common 3D level construction methods in games:
Primitives: arrange simple basic shapes like cubes and boxes.
Brushes / modeling: construct 3D shapes in the level editor.
Modular kit: connect pre-made pieces together, like Lego.
Sculpting: "paint" organic 3D shapes, useful for landscapes.
Splines: create math curves that procedurally generate geometry
Primitives are simple 3D shapes, like the default gray cubes and boxes built into a game editor.
Move / rotate / scale the shapes. Arrange them together, stack them on top of each other, make more complex groups of shapes.
This is a surprisingly powerful blockout method. You can always use this method in any 3D engine or tool, but you'll hit limitations with blocking out anything beyond simple boxy buildings.
Brushes are simple low polygon 3D shapes modeled in the level editor.
This was the main level construction method across the industry from 1990s-2000s.
We strongly recommend this method because it offers the most control and handmade feel, but unfortunately most modern game engines often have poor brush modeling tools. It can be tricky to figure out a workflow here.
Snap together pre-made pieces of architecture from a kit of modular parts.
However, if the kit is badly designed or poorly configured, it'll be hard to use. If you're a beginner, you probably shouldn't try to make your own kit -- just download one instead.
For more on planning, measuring, and constructing modular kits, see Modular kit design.
For links to download free modular prototyping kits, see Resources.
Most modern engines have a sculpting tool that lets you paint and deform a flat plane.
We use this only for making big smooth shapes like terrain and landscapes; it's bad for hard surfaces like buildings.
But if landscapes are central to a project, there's no way to avoid sculpting.
For more on sculpting and designing terrain, see Landscape.
Splines are invisible curves that generate geometry along the path.
These curves are also non-destructive; you can adjust a spline at any point and regenerate its geometry.
A spline is ideal for blocking out curvy linear forms like roads or rivers, where it can also automatically deform the surrounding landscape.
It's also possible to generate non-linear areas and buildings with splines too, but this type of workflow isn't common and usually requires custom tooling.
Why not use a 3D art tool like Blender, Maya, Max, or SketchUp to blockout?
People debate this. Here's our take: 3D art tools don't let you tune gameplay, collision, encounters, or items. Playtests become slower and less frequent.
Example: on an unnamed AAA game, moving a rock requires a multi-step hour-long process: (1) load debug build, (2) find which file has the object, (3) open Maya, (4) edit file, (5) recompile game, (6) load debug build again to confirm change.
Here's a general process. If you're a beginner, or you're at the start of a new project, try to do everything. You will gradually personalize your own process and style.
Sketch layout
Add ground plane, scale figures, walls
Playtest
Diverge, iterate, and playtest again
Repeat step 4 until done
It can be difficult to blockout without any plan, especially for beginners. Even a simple scribble can help a lot.
Look at the layout sketches below. The left sketch emphasizes the scale of each space, the middle sketch focuses on the relationships between the areas, while the right sketch is a more detailed floor plan drawing. Any of these sketches can work, any of them can help you plan a blockout.
Just draw something!
Create a ground plane (or a big flat cube) near the center of the 3D space (0, 0, 0).
Use a light-colored gridded prototyping texture so that you can visually estimate sizes and scales. This floor object will help "ground" the rest of the level geometry, providing a horizon line and context for everything else to rest upon.
Add a player-humanoid scale figure to help establish scale.
If you don't have any humanoid assets, create a roughly human-shaped block to serve as a placeholder. The scale figure helps establish consistency and clearance for the player.
For more on common hallway / wall sizes and humanoid dimensions, see Metrics.
For links to free prototyping and blockout textures, see Resources.
Build a wall segment that's approximately 150-200% as tall as the scale figure.
If you're working in a modern game engine, sizes don't have to be exact -- the sense of proportion is most important to establish here.
If you are blocking out with a modular kit, just place a standard wall module next to the figure.
Texture the wall with a different color from the ground plane. Color and brightness provide important context for understanding what the space is made of, and how these various floor and wall planes relate to each other. If you are afraid of colors affecting your blockout too much, then at least use textures with different shades of gray.
Copy & paste wall segments to build up more space until you have at least one room or hallway. Some tools feature special "duplicate" or "clone" commands: in Hammer, hold Shift and drag the brush; in UE4, hold Ctrl+Shift and drag the wall object.
Intersections are OK. Messy is OK.
To make a doorway or window, just leave a gap between wall segments, and fill it in later. Entryways and hallways should be at least twice as wide as the scale figure.
Do a simple self-playtest: walk around the space, within the game engine, with full player gravity, collision, and speed.
The purpose of the blockout is to experiment. To verify the results of the experiment, you must test the prototype. Do NOT just fly around in the editor view, that won't help you imagine the player experience.
Massing. Do the level's shapes make sense? Is it confusing to look at?
Metrics. Does the player fit through every door and passage? Do the stairs / ramps work? Can the player jump where they're supposed to jump?
Flow. Does movement feel slow or fast, smooth or complex? What type of movement is ideal for your intended design goals?
Diverge from original plans and respond to the playtest.
99% of the time, your blockout will not survive a playtest. Rooms will feel awkward, doorways too narrow, the layout too confusing. But this is exactly why we blockout!
Want to rebuild huge sections of your blockout? Go for it. Want to delete an entire room? Do it. Need to split a courtyard into two smaller areas? You have permission.
Keep an open mind about what your playtests and walkarounds are telling you.
Continue adding new scale figures, walls, and floors.
Then playtest again.
Keep an open mind and continue this cycle of modification + playtesting. Continue developing the blockout. Build, then walk around in it, then modify, then playtest again... and repeat. This design process is called iteration, because we are making new iterations that build off of the strengths of the previous version.
As you gradually build more and more of the level, it may surprise you how much it changes over time. Let the map surprise you.
(most common) My blockout feels too small / too big.
Use more scale figures during construction.
Playtest more often and catch scaling problems sooner.
Too big? Delete unnecessary rooms and compress what's left.
Too small? Expand outermost walls, then expand the center to fill up the new space.
Or delete everything and rebuild. It's just a blockout.
I have anxiety and stare at the empty level editor screen without making anything.
Sketch a layout drawing, and then try to follow that plan.
Just blockout one simple room. You can always delete it later. The point is to get rid of the blank page. In drawing, this is "activating the canvas"; in writing, this is a
Splash Damage level designer Anthony "MassE" Massey designed the map Castle for the competitive multiplayer team shooter Dirty Bomb. Massey took inspiration from twisting medieval streets and typology of the real-life Tower of London, and conceptualized the initial layout drawing (above, left). But note how the resulting blockout (above, center) differs from the layout with fewer curves, more 90 degree angles, and chunkier areas. The layout was just an initial guide. Because this is a multiplayer shooter map, the design team playtested the blockout with a focus on movement and combat metrics:
“The scale of maps is always the hardest aspect to get right. It’s important to plot your main paths and measure these distances; we’re looking for anything between 8 and 12 seconds from spawning to an objective. [...] Anything longer than that and players get frustrated when they respawn and have to run back. On the other hand, if the time is shorter it risks the map feeling too small for 8v8 matches, and can lead to chaotic gameplay. [...] This stage is crucial to map development, but our team operated by a simple rule of thumb; if it feels long, it’s too long."
"Considering [player classes] is the next step. We had to look at combat ranges to allows our entire arsenal to function, [...] while also ensuring variety in combat spaces to allow [different abilities] to be viable (like [an airstrike ability]). In real terms, this means considering the ratio between outdoor and indoor areas, ensuring [characters with outdoor-focused abilities] were viable."
Respawn level designer Rodney Reece built the blockout for "World's Edge", a large competitive multiplayer map for first person battle royale game Apex Legends. Notice how the map changed drastically from blockout (left) to art pass (right) in not only theme but also layout and composition.
"Originally the idea was the map was snowy. But art wanted to bring green into the map, and in one of the meetings, Robert Taube suggested what if the Epicenter (then called Frozen Explosion) caused the snow.
A key to being a good designer is being flexible to new ideas. For instance, the Art team came up with The Dome. In my blockmesh, it was a volcano. They pitched it and I adjusted to incorporate the idea. I had to create a new layout for it, but it made it better.
But other times, certain [points of interest] are fun from the beginning. In those situations, I am more stubborn about what can change. Sorting Factory is a good example of that. It's important to identify what's precious and what's flexible in terms of layout. Because it takes a team!"
For some projects, the traditional blockout might be less helpful. The experience may depend less on spatial design and more on the art pass. Blockouts can't validate a concept dependent on art or other assets.
For the first person narrative exploration game Firewatch (2016), developer Campo Santo wanted to focus on mechanics like walking and talking; the main appeal of the game concept was looking at art passed scenery and listening to voice acted dialogue. Following typical best practices, they first built a blockout to test the viability of these mechanics. However, the blockout did not help them answer any questions about the player experience because the game pacing was fundamentally a narrative design and environment art issue, not so much a level design issue. The traditional blockout process wasn't working.
According to environment artist Jane Ng's account, it wasn't clear whether Firewatch would "work" as an experience until they skipped the blockout process and instead completed a vertical slice prototype with an art passed environment and near-final dialogue.
For the top-down third person stealth puzzle game Untitled Goose Game, developer House House sought to create an authentic-feeling British village in 3D. Level designer Jake Strasser had never been in the UK, so blocked out the initial level with occasional use of photo reference. However, this blockout-first approach required Strasser to fill-in gaps from his imagination -- and because he didn't have a British imagination, these gaps often felt implausible or inauthentic in subtle ways, counter to their intent. The traditional blockout process wasn't working.
So instead, Strasser tried a research-first "location scouting" approach. He went on an exhaustive virtual tour of various UK villages, taking lots of photos from Google Street View. After recreating several village streets in-game, Strasser finally pin-pointed what type of structure suited the game's needs, and settled on an unusual side street layout based on Pump Street in the village of Orford. Here, blockout was less about building a space, and more about discovering a space.
A blockout is a simple but playable "rough draft" level with minimal detail. We keep it simple and blocky so that we can easily change it.
You can build a blockout with primitives, brushes, modular kit, sculpting, or splines. The best technique will depend on your engine and project, or you can combine multiple techniques.
How to blockout:
Sketch a layout, even a simple one
Add a ground plane, scale figures, and walls.
Playtest immediately; does it feel OK to walk around? You need to know now.
Diverge from your original plan, iterate and playtest again
Repeat step 4.
The most common problem is scale, especially for beginners. Playtesting the blockout in-game is the best way to know if it feels too big or too small.
Blockouts might be less helpful for some projects like single player art-dependent narrative levels.
Review key concepts for blockouts like massing, metrics, wayfinding, and playtesting.
GDC 2018: "Invisible Intuition: Blockmesh and Lighting Tips to Guide the Player and Set the Mood" by David Shaver and Robert Yang is probably the most up-to-date industry-standard blockout talk, showing blockout examples from Shaver's work on Naughty Dog games alongside distilled examples prototyped in Unity. However, it's actually more concerned with composition and wayfinding than construction.
"Quake Mapping Tips: Building Layouts" (5 min) video by Michael Markie starts with a very simple one room blockout in Quake 1, then gradually elaborates on it and makes it more compelling to play. Note the frequent playtesting and design iteration. A great example of an improvised blockout process with little pre-planning.










































The player's options throughout the level, the fairness of where the player can go
Map balance is the real and perceived fairness of player positioning throughout a level. Will the player blame themselves for not understanding how to use the level, or will they blame the level designer for putting them in an impossible situation?
A well-balanced level supports a variety of play styles and keeps players invested in the outcome, while a poorly balanced map might drive players to quit out of frustration or apathy.
Although we can generalize balance to apply to any level, balance is mostly important for combat-oriented levels and competitive multiplayer maps.
















For games about defeating an AI opponent, the idea of "balance" makes no sense. Almost all cooperative "Player vs Enemy" (PvE) and single player games are purposely unbalanced in the players' favor.
Enemy AI will purposefully take bad positions with obvious weaknesses because the game is designed to be completed promptly. Here, a "fair" level gives players ample information and opportunity to triumph. The purpose of the AI opponent is to lose in an interesting way. Essentially we must rig the game in the players' favor, and give the player compelling opportunities to rig it further.
So when we talk about map balance, we mean multiplayer map balance, not single player / PvE.
For more on single player / PvE / co-op combat, see Encounter instead.
First let's review the basics of general game balance.
In rock paper scissors (RPS) each move counters another. Competitive games frequently rely on a RPS metaphor for balance. Fighting games like Street Fighter boil down to Attack Throw Block (attack beats throw, throw beats block, block beats attack). Strategic war games like Starcraft are Infantry Artillery Cavalry (infantry beats cavalry, cavalry beats artillery, artillery beats infantry). This pattern varies across games and genres (Melee, Spellcaster, Ranged... Shotgun, Sniper, Rifle... Tank, Support, DPS... Carry, Top, Mid, Jungler, Support).
From this perspective, balance means offering counters. If the player never has any possible counters for their opponent's move or strategy, then the system is unbalanced. Any balanced counter system needs 3+ options, so that countering a counter ("yomi") is a third option distinct from their original first option as well as their opponent's second option. (e.g. "Rock Paper" doesn't work.)
The prisoner's dilemma is a 1950s thought experiment designed by a US military think tank and it is a core concept in game theory:
Two members of a criminal gang are arrested and imprisoned. Each prisoner is in solitary confinement with no means of communicating with the other. [...] Each prisoner is given the opportunity either to betray the other by testifying that the other committed the crime, or to cooperate with the other by remaining silent. The possible outcomes are:
If A and B each betray the other, each serve two years in prison
If A betrays B but B remains silent, A will be set free and B will serve three years in prison
If A remains silent but B betrays A, A will serve three years in prison and B will be set free
If A and B both remain silent, each serve only one year in prison
Here are the possible outcomes expressed as a payoff matrix, where years in prison are expressed as negative points and the goal is to maximize the highest score:
B stays silent (cooperate)
B betrays (defect)
A stays silent (cooperate)
A: -1 year, B: -1 year
A: -3 years, B: 0 years
A betrays (defect)
A: 0 years, B: -3 years
A: -2 years, B: -2 years
In this standard version of prisoner's dilemma, game theorists argue that players should always defect. Why? Imagine you are A. If B cooperates, then you should defect, because 0 years in prison is better than 1 year in prison; and even if B defects, then you should still defect, because 2 years in prison is better than 3 years in prison.
For this reason, defecting is a dominant strategy because it doesn't matter what the other player does. Always defecting will earn you a win at best, and a tie at worst. In terms of costs / points, you literally cannot lose if you always betray the other player. To understand why, watch the most famous moment from the UK game show Golden Balls, where contestant Nick Corrigan uses this dominant strategy against fellow contestant Ibrahim Hussein to sublime effect.
From this perspective, balance means avoiding dominant strategies in your system, and a dominant strategy is a play pattern that earns the highest theoretical payoff. If there is a dominant strategy, then theoretically all rational players will choose it, which makes the rest of the strategies irrelevant, and thus, unbalanced.
A heater is a simple self-balancing system. When a heater detects that it is too cold, it heats up; when the heater detects that it is too hot, it stops heating itself. In system dynamics, this negative feedback loop is a balancing loop because it stabilizes the system's state. In contrast, imagine a heater that heats up more when it gets hotter, eventually catching on fire and burning down a house -- this is a positive feedback loop, a reinforcing loop that strengthens its own effect.
In games, balancing loops help weaker players recover from mistakes. For example, racing games often "rubber band" those in last place by gifting them faster speed bonuses (e.g. an AI car in Gran Turismo) or better items (e.g. a blue shell powerup in Mario Kart), thus making a race feel more exciting and competitive. However, this can also lead to accusations of unfairness, or drawn-out matches that feel like artificial stalemates. Reinforcing loops help stronger players increase their advantage, like in any game where resources beget even more resources (e.g. in Counter-Strike, money buys better guns, which make kills easier, which earns more money, which buys better guns... etc.).
(feedback loop diagram)
Game balance may now seem like a mathematical thing you can prove -- if all the counters and feedback loops and numbers add up, then your game or level is now perfectly balanced!
Behold, the perfectly balanced payoff matrix for standard rock paper scissors:
B plays Rock
B plays Paper
B plays Scissors
A plays Rock
A: 0 , B: 0
A: 0 , B: +1
A: +1 , B: 0
A plays Paper
A: +1 , B: 0
A: 0 , B: 0
A: 0 , B: +1
A plays Scissors
In theory, rock paper scissors is perfectly balanced and all options are always equally viable. There is no reinforcing loop that causes a runaway streak of winning, past rounds do not affect future rounds. Does that perfect balance make rock paper scissors the greatest game ever made? On the contrary, some might say the perfect balance ultimately makes it a boring game to play! All the moves feel the same, there's no way to take a big risk for a big reward streak, and 33% of the possible outcomes result in nothing happening.
Unbalanced counters, dominant strategies, or out-of-control negative feedback loops aren't necessarily bad in a game. If a dominant strategy makes our experience goals happen, then go ahead and keep the dominant strategy in there. Even if it's less of a dilemma, using a dominant strategy can still feel dramatic and impactful. Victories may not feel triumphant unless they are big victories.
In the chicken game we imagine two cars driving toward each other, with a very exciting shared penalty if both cars "defect" and collide in a crash.
B swerves (cooperate)
B stays straight (defect)
A swerves (cooperate)
A: 0 , B: 0
A: -1 , B: +1
A stays straight (defect)
A: +1 , B: -1
(Crash) A: -1000 , B: -1000
What if we wanted "rock" to feel like a big dramatic decision?
Journey is a game where players can "chirp" near each other to recharge the other player's jump energy. Cooperation is a clear dominant strategy here, but that's the point.
This is all just to say: a balanced game / level is often undesirable.
(todo: image)
Fairness is the player's overall psychological perception of balance. Even in a balanced system, players may still perceive unfairness -- or players might think an unbalanced system is fair.
A balanced PvP map provides opportunities to both attackers and defenders, with trade-offs and counters to occupying any given territory. Competitive multiplayer maps should offer teams an average near-equal ~50% win rate.
In general, prioritize fairness over balance. It is less about perfect math, and more about understanding the player's experience and response. Unless you want to take a specific stance as an artist, then players are the source of truth. If all your players say 2+2=5, then consider changing the math in your game.
(image: fairness)
Map balance and fairness always happens within the larger context of the entire game. Rules and procedures affect how players use the map, especially in competitive multiplayer.
Switching sides. Map balance matters less when teams switch sides / roles during the game, because theoretically, all players have equal opportunity to exploit (or suffer) any imbalance. This approach is common in many sports, where teams switch sides at half time.
Tier lists. Very common for MOBAs and fighting games. Sort different levels, characters, or equipment into "tiers" and balance only within that tier. e.g. B-ranked options should have rough parity with each other, but no one would expect a C-rank choice to defeat an S-rank choice. Sirlin argues all S-tier or F-tier characters should be redesigned.
Tournaments. There's a whole science to bracket design for competitive multiplayer tournaments, which you could argue is basically meta level design. Open or closed, round robin, elimination? What if one team is better at a certain map than another? Can teams veto maps? What's the map pool?
For example, pictured above is the "Green Monster", an unusually tall green wall at the back of left field at Fenway Park, a Major League Baseball field in Boston, USA. In terms of level design and map balance, the Green Monster offers a huge advantage to the defensive team on the field; the Green Monster is so tall (11.3 meters) that it is very difficult for a batter to hit a home run over the wall.
But within the larger context of an entire baseball game with multiple innings where teams repeatedly switch roles, it is fair because both teams will be at a similar disadvantage. The overall game design frames how we understand balance, and sometimes map balance is even somewhat irrelevant.
(Baseball nerds debate whether the Green Monster is bad for batters. Batters can aim for the wall and bounce the ball off of it, which is more difficult for left fielders to catch. Left-handed pitchers often suffer worse stats at Fenway because right-handed batters score more of these "wall ball doubles".)
Balancing various parts of a level involves comparing the utility of the area, the cost of accessing it, and the information available to players.
Utility: Is this area useful or interesting? Why would a player go here or stay here?
Cost: Is this area easy to reach or stay in? Do players need a lot of time / resources to do so? If the player is here, does that leave another place vulnerable?
Information: Are players aware this area exists? How much info must players track or memorize to utilize this area? Are there hidden costs? Is it fun to misunderstand what happens?
Our goal in level design is not to maximize utility. A "perfect" map area that's always useful (high utility) and easy to reach (low cost) in an obvious location (visible info) isn't actually desirable in level design because all "rational" players will inevitably use it and rely upon it as a dominant strategy Why build the rest of the map if players won't use it?
Ideally, every part of the map should have a specific usefulness that depends on the game state, with situational weaknesses to discourage players from staying for too long, filtered through limited information that lets players make entertaining mistakes.
A player's territory is the area of the level that they can track, defend, and generally benefit from. Note that the player does not necessarily have to be present inside the area in order to defend or benefit from it. The concept of territory is more abstract than that, it's more about who controls access to that area, and who can comfortably move into the area.
For example, a
Every game with players and space can support a theoretical player-driven "meta" understanding of territory. When you play the board game Monopoly and accrue many adjacent properties, that area can be considered your territory. When you play basketball and have enough defenders near the basket, that area (the "paint") is now under your control.
Team-based game modes with many players tend to formalize territory with king of the hill (KOTH) styled control points (CP), payload carts, or battle royal circles.
Map control is the proportion of the player's territory against their opponent's territory. If you have much more territory and claim more key positions in the map, you have more map control.
Territories are usually bounded by chokepoints, smaller areas or passages that can be defended to deny territory to an enemy.
In multiplayer PvP maps, distribute 3-4 chokepoints across the map, one chokepoint per lane. It should be impossible to cover all chokepoints from a single point.
For example, in the Counter-Strike map de_cache, the top lane (A) has two small chokepoints, the mid lane has one big chokepoint, and the bottom lane (B) has one big chokepoint. The Counter-Terrorist (CT) team's job is to protect the orange bombsites, which both begin firmly within their territory (the left side of the battle line). CTs have a safe way to rotate from mid to A, but Ts can attack A from two chokepoints. B is closer to both CTs and Ts, but rotating from B takes longer.
Ts go A
Ts go Mid
Ts go B
CTs go A
Fight
Ts control B
CTs must rotate
CTs go Mid
CTs can cover A
Fight
CTs can flank B
CTs go B
For more on designing with NPCs and AI, see Encounter design.
For single player / PvE game modes, territory is
For competitive multiplayer (PvP) maps, maintaining map control is about defending key positions, and "denying" resources or important areas to opponents -- or, conversely, "pushing" into enemy territory to get more map control for you or your team. In this way, territory in multiplayer design is very fluid and constantly changing.
In duel, deathmatch, or free-for-all multiplayer modes, territory and map control are rarely formalized within the game system. Instead, territory is a more player-driven understanding of how players flow around the map.
(rapha video)
To help coordinate more than a handful of players, team-based multiplayer shooters feature game modes that formalize territory in the form of control points, moving payloads, or battle royale circles.
For combat games, it is also effective to conceptualize sightlines in terms of territory to defend. Which positions can be easily defended with a wide sightline, while which areas leave players vulnerable to a surprise attack? (FMPONE CS:GO talk)
Sniper alleys offer very long sightlines for long range attacks or suppression, while close quarters areas offer shallow sightlines. Most multiplayer combat games try to balance their maps with a mix of short and long sightlines, and cover is an easy way to tune the effectiveness of a particular sightline.
Some loose guidelines for measuring the effectiveness of a tactical position:
Can a hostile player sneak up on them? Are all possible enemy sightlines within a single defender's field of view?
Is cover spaced far apart, or close together?
Does the defending player have a height advantage?
A position that is easily defended with high tactical value and no obvious weaknesses is a “camping spot.” In the 1990s, multiplayer FPS gamers complained a lot about campers; today, Call of Duty: Modern Warfare free for all is basically a game about moving between camping spots. There are no firm universal rules about cover design because every game will feature different weapons and different combat styles.
That said, this book would like to suggest one firm universal rule about cover design: avoid “cover boxes”. A cover box is any repetitive object at waist-height with a boxy shape, and we encourage level designers to experiment with new cover shapes, or reconcile cover most seamlessly with the surrounding architecture. See also: Time to crate (TTC)
who controls what areas, where the player thinks they can go
single player combat, multiplayer combat
sometimes formalized with "bases" and "capture points", but territory always exists in any game with conflict
sometimes the conflict is "human vs world"... walking sims have walls, the walls are not part of the player's territory, etc.
flowchart / graph / value diagram
In multiplayer PvP level design, the most straightforward way to balance a map is to use symmetry, to copy an identical layout / base / territory for each team.
Take one half of the map, duplicate it, and then flip the copy or rotate it 180 degrees. Sew up the seams and connect the shared boundaries along the middle axis of symmetry. The most common type of symmetry used in level design.
Feels "artificial", requires extensive thoughtful art passing to differentiate the two areas
example: 2fort, iceworld, MOBA maps
Take part of the map, duplicate it, then move and rotate it. If desired, repeat more than once. This is a much more rare type of symmetry, because its strength is in how it accommodates more than two teams, yet most multiplayer games only field two opposing teams.
example: ???
More "realistic"
This is really hard to get right and it's very time consuming, and this is why CS:GO level design is really hard
Balancing a level involves a lot of back and forth between modifying your level and playtesting it, over and over again. This process is called iteration.
Playtest multiple sessions with different sets of players.
Collect feedback and combine with personal observations.
Iterate another pass on the blockout.
Playtest again.
Repeat steps 4-6.
Tuning is the process of tweaking angles, sizes, and distances until the level feels balanced.
If something isn't working, but don't know what to do with it, then err on making it more powerful. If you make it weaker, players will simply use it less, and you won't get any data or feedback on it.
On the first pass, double or halve the value. Small differences cannot be felt.
Trick jumps and unorthodox flow can offer a difficult and time-consuming route for players to flank their opponents. When designing these optional routes, balance the risk of failing the route with the reward.
For example, in the trick jump pictured below on de_cache for Counter-Strike: Global Offensive, a CT player must (1) run on the garage overhang, (2) jump with mid-air control around a corner onto an air conditioning unit, then (3) jump onto a junction box and onto a roof to sneak behind an opponent.
The co-designer Sal Garozzo notes that this trick jump is helpful but time consuming and risky. If you spend too long trying to complete the trick jump, then you leave your team at a disadvantage, and also the enemy players will constantly hear you jumping on these loud metal surfaces. Trick jumps are best when they're not obligatory -- optionally a teammate could boost you up to the roof as well.
For more on managing the player's view, see Metrics and Composition.
A sightline is an imaginary uninterrupted line that connects the player’s camera position to an important part of the level within the player's field of view.
A large busy view with many deep sightlines will overwhelm the player about what is relevant, while offering only a few shallow sightlines will leave players ignorant and unable to plan movement.
For PvE gameplay, err on too much cover. You generally want to offer more options and routes for the player to defeat enemies. If there is only one clear path with cover, then the gameplay will feel more rote and less creative.
For PvP gameplay, err on too little cover. The game mode will likely already support ways for players to create their own cover (Counter-Strike: Global Offensive features smoke grenades and flashbangs, Overwatch features tank enemies and shield mechanics) and too much cover will make it too difficult to track what's happening.
Good sightline design involves:
Balancing the rate of visual information that the player must process and track
Varying the quantity and length of sightlines; different areas should afford different visibility
Offer multiple sightlines to the same landmark from different vantage points
(corners diagram)
When balancing sightlines, pay special attention to corners. A rounded / beveled corner offers wider sightlines than a sharper corner. Imagine someone was chasing you: it's difficult to break line of sight along a curved hallway, while a sharp T-junction with blind corners lets someone easily break a sightline and escape.
When map geometry exists mainly to break sightlines and hide from projectiles, then it functions as cover. Some common types of cover:
Soft cover visually obscures the fighter, blocking sight but not projectiles examples: water, foliage, shadows, grates, thin walls / doors in games with bullet penetration mechanics
Hard cover protects the fighter from projectiles, and usually blocks sightlines as well. examples: bulletproof transparent glass window, thick opaque walls or terrain
Half cover is a waist-high object that protects the top-half of a standing figure (exposing their head, torso, and weapon) or an entire crouching figure. Half-cover depends on elevation; an attacker firing from a higher vantage point will be able to hit even a crouching figure, while an attacker from a lower vantage point might have trouble seeing even a standing figure.
Full cover is a tall object that fully protects someone standing. However, in most first person shooters, a defender behind full cover cannot easily see or fire back without stepping out of cover.
(cover diagram)
Cover boxes are easy to parse but feel artificial and unnatural
Use slopes to create cover
Again, just like anything in level design, our definitions depend on how the game implements its mechanics.
For example, Counter-Strike features a bullet penetration mechanic ("wallbanging") that lets players shoot through thin objects made of weak materials. So while a corrugated metal wall or wooden board might function as hard cover in most games, these thin objects function as soft cover in Counter-Strike.
On the CS:GO map de_crown, co-designer Sal Garozzo notes that this double-door chokepoint (pictured below) has these thin rectangular wooden cutouts specifically to offer players a trade-off: they can shoot through these walls to make sure no one is hiding there to ambush them on the other side... but if they try to wallbang and no one is there, then they have wasted some bullets and also made a loud gunfire sound that gives away their position. Wallbanging transforms cover into a betting mechanic.
Height advantage (and ceiling) and explosive radius, gravity and grenades
For the multiplayer team shooter Wolfenstein: Enemy Territory, players complained the two teams' weapons were unbalanced. Supposedly one team's Thompson submachine gun was more powerful than the other team's MP40 gun. Now within the game code, the guns literally had the same stats and damage tuning values. But when Splash Damage designers analyzed the player stats, they discovered players were indeed getting more kills with the Thompson vs the MP40 even though there was no functional gameplay difference between the two weapons. The players were right about the effect, even though it seemed like they were wrong about the reasoning.
The only differences were the 3D models and the sounds. So to balance the two guns, the developers made the Thompson sounds "less bass-y". That's it.
There are two main takeaways about playtesting and game balance here:
Players are often correct about the "effect" of a design problem, but may not be able to accurately identify the cause. Suggestions are often wrong, but the underlying problem that prompted the suggestion is real. Data can help confirm player perceptions, but does not necessarily imply the design solution.
Game design and balance is not just a technical mathematical science, but also a conceptual psychological art. What might seem one type of problem could actually be caused by something else. A holistic view of your game is crucial.
We balance maps because supposedly good balance makes for a more enjoyable game experience. But what if bad balance still makes for enjoyable levels?
In the early 2000s when multiplayer FPS culture centered around dedicated servers,
D-Day style beach landing assault maps are all about the massive unbalance of power. It wouldn't fulfill the Omaha Beach fantasy unless you died 10 times in the spawn area.
Frustration is about expectation and attitude. If players enjoy losing, then amplifying that loss will result in even more enjoyment, right?
read about Flow and Encounters
try a layout balancing exercise
"Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3" by Jaime Griesemer from GDC 2010 is a classic highly-recommended game design deep dive into weapon balance and Halo's multiplayer design.
"The Heresy of Zone Defense" (1995) by Dave Hickey is one of the greatest pieces of sportswriting of all time, exploring how rules, players, and territory work(ed) in US pro basketball. But keep in mind the NBA legalized zone defense in 2001 and adopted the three-second rule: "no offensive player, with or without the ball, could remain in the key, for three seconds or more."
"Hearthstone's Card Balance Philosophy" by Eric Dodds, lead designer of Hearthstone, lists several factors that go into balancing a popular card game. Although these design principles do not directly relate to level design, it's still a helpful lens into general game balancing philosophy.
by David Sirlin is about balancing a competitive card game called Yomi, and how Sirlin approaches tiers. He also disagrees with some of the conventional balancing advice on this page, so if you're a balance nerd, definitely check out his take.
Matthew "Lunaran" Breit wrote about map balance as it pertained to Quake multiplayer arena maps circa 1999, and was pretty influential among level designers and competitive players. Today he's slightly embarrassed about it all and disavows much of it, but we think it's funny to watch him squirm, so we're linking to it anyway. Even if he was wrong, enough people believed he was right.

























A: 0 , B: +15
A: +1 , B: 0
A: 0 , B: 0
A: 0 , B: +1
A: +1 , B: 0
A: 0 , B: 0
B plays Rock
B plays Paper
B plays Scissors
A plays Rock
A: -10 , B: -10
A: 0 , B: +5
A: +15 , B: 0
A plays Paper
A: +5 , B: 0
A: 0 , B: 0
A: 0 , B: +1
B chirps (cooperate)
B doesn't chirp (defect)
A chirps (cooperate)
A: +1 jump , B: +1 jump
A: +0 jump , B: +1 jump
A doesn't chirp (defect)
A: +1 jump , B: +0 jump
A: +0 jump , B: +0 jump
CTs must rotate
Ts control A
Fight
A plays Scissors







player size and speed, health and damage values, common sizes and building dimensions for designing single player Quake 1 maps
Below are some core gameplay values and numbers that are useful for level design in Quake 1.
Sometimes popular mods evolve new design norms in the community. After all, it's been more than 25 years since Quake's 1996 release. We note differences against default retail unmodded Quake ("Vanilla Quake").
For more on what metrics are and why they're useful, see Metrics.
For lots of Quake-specific info and links, see Quake resources.
Quake uses the Quake Engine, obviously. So any basic scaling and metrics recommendations from the main page about Quake-lineage engines (Source Engine, etc) also apply here.
1 Quake unit (u) = 1 inch, but not really. There is no consistent scale.
Z-axis up
Quake uses a "power-of-two" grid. Most mappers at a grid size of 64 or 32, then shift down to grid size 16 or 8 to start refining details. Use grid 4, 2, or 1 only for very small details.
*Falling damage is -5 health if the player hits the ground at any downward vertical speed faster than 650 units / second. In practice, this means fall damage rarely kills players. To kill the player from a tall drop, create a trigger_hurt or trigger_void (implemented in some mods).
Consider alternate ways of punishing the player for falling (monsters below, or water, slime, lava) or maybe even just let the player fall down, explore, and find their way back up again.
Keep in mind this is an action game with aiming and dodging. The actual damage depends heavily on enemy behavior, available cover, height changes, enemy composition, etc. "Damage per second" is just a rough estimate.
*Shotguns are a little complicated:
Damage is calculated via hitscan spread; for full damage, all hitscans must hit the target.
The effective range is much lower than 2048u.
In vanilla Quake, crowd control in a narrow hallway is harder than it seems -- weapons do not penetrate monsters in death animations and explosive splash damage is buggy. Recent mods like or fix these bugs.
Quake has two collision systems. QBSP bakes collision hulls for basic movement clipping (entity vs world collisions), and then there's also hitboxes for moving objects (entity vs entity collisions). Both collision types use AABB (axis-aligned bounding box) shapes that cannot rotate.
There are three (3) world collision hull sizes:
hull 0: 1x1x1 ("points" like projectiles, missiles)
but a missile's hitbox is 32x32x32 (via movetype FLYMISSILE / BOUNCEMISSILE)
and in-game, missiles don't even use this hull, and traverse the BSP instead
Meanwhile, hitbox sizes vary slightly for every monster, and are listed in the table above.
Allow more extra space beyond the monster's size or else it will have trouble moving around: at least 16 units above ground / 16 units away from walls. Placing monsters slightly in the air is common.
Generally, place monsters in spaces at least double their width and height.
For example, an Ogre (64 x 88) is better in a room that's 128+ wide and 176+ tall. For ease of construction, it's common to round up the room height to an increment of 64 (192, 256).
Fiends and Spawns jump a lot and definitely need a 128+ tall room, ideally 256.
But sometimes less monster movement is better, it all depends on the level.
Gibbing occurs when monsters get damaged a lot, all at once. If their health drops below a certain negative threshold quickly enough, then they turn into "gib" pieces instead of playing their death animation. This generally only happens when the player uses explosive weapons (grenade launcher, rocket launcher) or the quad damage powerup.
In vanilla Quake this mechanic only matters for zombies, who revive themselves unless they lose all their health (60) within a single frame and become gibbed. Again, the player will usually need explosives or a quad to kill the zombies permanently.
Infighting happens when a monster damages a different monster type, which causes the hurt monster to target the other monster instead of the player.
For example, when an ogre's grenade accidentally hurts a fiend, the fiend will turn around and attack the ogre. But if an enforcer's laser hits another enforcer, no infighting will occur.
Melee-only monsters will never cause infighting. Only ranged monsters can.
Frequent infighting can make encounters feel too easy and unbalanced. But sometimes infighting makes for a more interesting battle. It all depends.
It is possible to design your map to require infighting by placing many monsters / less ammo. However, balancing these types of combat puzzles is complicated. Make sure to set a clear player expectation that infighting is required, otherwise players will be confused why there wasn't enough ammo. We recommend designing these situations only for Hard mode.
Quake has 4 difficulty levels: skill 0 "Easy", skill 1 "Normal", skill 2 "Hard", and skill 3 "Nightmare".
In general, health and damage do not scale automatically with difficulty level; skills 0-2 depend on mappers to manually adjust monster count and items.
The exception is skill 3 Nightmare, which enforces several code-level changes:
1996 vanilla Nightmare:
faster monster attack speed / frequency
less likely to stun monsters (enter "pain frame" animations)
Shambler lightning lasts 33% longer, for a maximum of 40 damage
There are three ways to get ammo: pickup an ammo item, pickup a weapon, or pickup a drop from a dead monster.
All ammo item pickups can be flagged as "large", which doubles the ammo they provide.
monsters do not drop ammo.
Army grunts die to 2 shotgun shots, but drop 5 shells, resulting in +3 "profit". If you use a lot of these monsters in the level, then balance your item_shell quantity accordingly.
Player armor follows an overcomplicated formula, and honestly, we recommend just ignoring these details. It's not important. But for the sake of completeness:
When the player gets hurt while wearing armor, they lose armor points (instead of health) based on the armor type's damage absorption rate.
example: Red Armor will absorb 80% of the damage you receive and subtract it from your armor points instead -- in practice, that means Red Armor rarely lasts very long, even though it seems like you get more of it.
If you have too much of a better armor color, then you can't pick up a worse armor color.
Green is common in single player maps
Yellow is considered to be pretty powerful, use carefully and sparingly
Traditionally, Red is very rare, and reserved more as a reward for a secret
in vanilla Quake, the Biosuit and Ring are considered lackluster powerups with limited benefit that depend heavily on the level designer
the Quad is probably the most interesting powerup
lets the player gib zombies with just the Axe or Shotgun
Quake monsters aren't very clever, which is part of the charm. Think of their movement more like semi-chaotic pinball rather than a tactical cover shooter.
Give more ammo than the player will need. A first playthrough will waste ammo. If the player theoretically needs only 20 shotgun shells used with perfect economy and accuracy, then you should probably give at least 40.
For more general advice on designing combat, see .
Lastly, here's veteran Quake modder Matt "Lunaran" Breit with some Quake-specific advice and approaches for :
I think resisting "easier is just fewer monsters" design is the right way to go. There should be fewer monsters, just not many fewer, because too few is just plain boring. We're all Quake Experts after 20 years of this, so I think anyone playing custom maps on Easy in 2018 is doing so because they're doing it on a lunch break or a stolen evening away from the kids, and not because they can't handle more than one fiend at a time. Maybe we should think of it more as 'higher investment.' Besides, Quake gives you tons of unappreciated variables that you can tweak by skill, both obvious and subtle.
Armor makes Quake significantly easier. More reds and yellows, more often, effectively extends the player's survivability in a given fight by hundreds of HP. More Greens, or stretches without armor at all, shrink the until-death buffer to little more than the player's current health. If you do want to keep the same monster loadout on all three skills, give the Easy player several Red and Yellow armors and the Hard player only one or two Greens. They'll feel like completely different games.
Adding a vote for weapon pickups coming earlier or later. On Easy, the next big weapon might come before the next big encounter so the player can kick ass with it, on Medium it might be placed within it so the player has to engage to grab it, and on Hard it might only come as a reward after beating the fight entirely without it.
Also keep in mind, you can toggle different platforms / walkways per difficulty, to make traversal easier or harder for the player. It's not just about item and monsters.
is an epic 5000 word design essay on Quake's design and how modder Matt "Lunaran" Breit approached his influential rebalance mod Copper.
We have a dedicated page with a lot more info and links.
- see list of , list of , under
, under license
Fall damage height*
256+
Absolute maximum step height**
18
Maximum climbable slope**
45 degree incline?
Underwater height
29+ (can die via )
Max jump distance (running start)***
244
Max standing jump height***
43
***
96 high?
***
~320 long - ~128 high?
***
~320 long - ~128 high?
Best practice is for ramps and slopes to be axis-aligned.
Many maps use Doom-style stepped terrain instead of smooth sloped terrain, partly to prevent physics problems. Monsters seem to like it better too.
*** Jump distances and heights assume the absolute limits of a typical player.
Build for a shorter jump distance / height. Most players don't have perfect reflexes and timing.
Don't force players to ramp jump, grenade jump, or rocket jump on the critical path; reserve these specialty jumps for optional shortcuts or secrets.
Skilled players can use to build-up more speed and distance, change direction in mid-air, etc. But don't worry about it. Let these players break your map, it's OK.
Hallway, regular
128u+ wide
Room, small
256u wide
Room, medium
512u wide
Room, large
1024u+ wide
Ramp
1:2 slope gradient (26.57° incline)
Stairs, simple
16 rise : 32 run (1:2 slope)
Stairs, dense
8 rise : 16 run (1:2 slope)
Gravity
800 units / second²
Low gravity
100 units / second² (in E1M8 "Ziggurat Vertigo")
*
100 Shells
-2.0
24 (4x6)
48
2048u
+/-4.4°
*
100 Shells
-2.8
56 (4x14)
80
2048u
+/-8.0°
200 Nails
-10.0
9
90
6000u
--
200 Nails
-10.0
18
180
6000u
--
100 Rockets
-1.66
40-120
200
~900u
160u
100 Rockets
-1.2
40-120
150
5000u
160u
**
100 Cells
-10.0
30
300
600u
--
** Firing the Thunderbolt underwater causes an explosion that kills the player. This "discharge" consumes all Cells and inflicts cells x 35 damage. With 100 cells, that inflicts 3500 damage on anything that can see the player underwater... including the player.
but if the player has the invincibility powerup, they will survive.
64 x 64
(shotgun)
30
1-16 (Hitscan Shotgun)
32 x 56
32 x 64
60 + revives until
10 (Flesh Shot)
32 x 56
32 x 64
75
12-18 (Sword), 20-30 (Charge)
32 x 56
32 x 64
(laser)
80
15 (Laser Shot)
32 x 56
32 x 64
(flyer)
80
9 (Projectile)
32 x 56
32 x 64
(blob)
80
10-20 (Jump), 120 (Explosion)
32 x 56
32 x 64
(big dude)
200
4-12 (Chainsaw), 40 (Grenade)
64 x 88
64 x 88
250
20-36 (Sword), 9 x 6 (Bolts)
32 x 56
32 x 64
(jumper)
300
40-50 (Jump), 10-15 (Claw)
64 x 88
64 x 88
(spider legs)
400
40 ("Voreball" Homing Shot)
64 x 88
64 x 72
(big furry)
600 + 50% explosive resist
10-30 (Lightning, range: 600), 80-120 (Claw)
64 x 88
64 x 88
hull 1: 32x32x56 ("small" players, humanoids)
hull 2: 64x64x88 (large monsters)
Vore balls move 40% faster
2021 remaster / Copper Nightmare:
all 1996 Nightmare-specific changes reverted; Hard is now identical to Nightmare
except the player's maximum health is now 50 instead of 100
+5
monster_grunt
Drop
+5
item_spikes
Item
+25 (large: +50)
weapon_nailgun
Weapon
+30
weapon_supernailgun
Weapon
+30
item_rockets
Item
+5 (large: +10)
weapon_grenadelauncher
Weapon
+5
weapon_rocketlauncher
Weapon
+5
monster_ogre
Drop
+2
item_cells
Item
+6 (large: +12)
weapon_lightning
Weapon
+15
monster_enforcer
Drop
+5
For this reason, the rebalance mod Copper reduces the ogre drop to only 1 rocket.
But don't require players to use any of this "economic thinking." See Advice.
Nails / spikes are the only ammo type that do not drop from monsters.
example: if you have 114+ points of Red Armor, then you can't pickup Yellow Armor.
+200
~80%
113 or lower (to Yellow)
38 or lower (to Green)
Invulnerability, immune to telefrag and thunderbolt water discharge
30 seconds
All damage multiplied by 4; more likely to gib monsters
30 seconds
but also an opportunity to conserve ammo, e.g. use 1 rocket to clear an entire room
splash damage from grenades / rockets can easily backfire, killing the player instantly
Greater monster variety leads to more ways the player can be attacked at any one time, requiring juggling more variables to avoid damage and find the safe place to be standing at any given millisecond. A shambler and a vore together are harder to handle than a pair of either. Variety also raises the chances of infighting, however.
The angles that enemies are presented from makes a difference. In front of the player is easier, flanking is harder, behind is bordering on unfair depending on circumstances. Below the player is a turkey shoot, eye level is straightforward, and monsters up high have a distinct advantage.
Quantity of resources matters, of course. Bigger medkit pools clearly make the game easier, plentiful rockets can be splashed around while rare ones are only for emergencies, etc. Nail weapon DPS is higher than SG/SSG DPS and so on.
Frequency of resources matters too. A steady drip lets the player feel secure, but isolated bursts create situations where the player has to stretch himself to get to the next 'island'. Depending on where he makes his errors, he might have to stretch pretty hard (eg those 'quicksave with 5 health left' or 'shambler axe dance or bust' moments). Feast-or-famine item placement can induce mild stockholm syndrome, leading to more positive reviews :)
Unless you're using a lot of Enforcers, maybe provide all players an early Lightning Gun and simply vary the cells provided, as a way of dealing more or fewer 'get out of jail free' cards.
Don't forget that the difficulty spawnflags are present on every entity. If you're using monster closets, vary the locations of the ambush triggers. Have the Hard ambushes happen when the player is in the worst possible position, and give them a leg up or more warning on easier skills (or even leave the closet open on Easy so there's no surprise at all). You might even duplicate the doors so you can set different 'speed' keys per skill, so the harder ambushes are an instant pants shitting and the easier ones are more like a countdown until the monsters come out, complete with early warning aggro sounds. Doors can be temporarily barred behind the player on hard skills while he is free to retreat from a fight on easier ones. Falling into a pit can be a mild backtracking inconvenience on easy skills but death by spikes on harder ones. How much room is there between nail shooters in this hallway? With careful use of triggerable lights and skill-specific trigger_relays, you can even use light and darkness against the player differently.
Getting crafty with what you change between difficulty levels can give you ideas for entire encounters, although don't rely on that too much for interest, because any given player is probably only going to experience one such permutation and thus won't realize the need to appreciate how different it is from any others.
Here's a method I've been using. It's really rough, and time consuming without a custom progs to do it for you, but it can be a helpful way to ground your estimates.
A box of: 25 or 50 nails = 225 or 450 damage 20 or 40 shells = 440/880 dmg 6 or 12 cells = 180/360 dmg
6/12 rockets are harder to judge because of 1) splash damage and 2) zombies, but let's say every rocket is 180dmg, for 1080/2160 dmg per box.
Total all the ammo you provide in the map (add 25 shells for the starter ammo, add 2 rockets per ogre and 5 shells per grunt and so on), and that's the max amount of hit point damage you are giving the player to deal. Total the starting health of all the monsters, and compare the two numbers.
Researching id maps and popular custom maps reveals an average 'custom' of about ~3:1 on Easy, ~2.2.:1 on Medium, and ~1.7:1 on Hard. the id maps are generally above that curve (4/3/2:1), and custom maps tend to fall below it(2.5/2.0/1.5:1).
Careful cheapskate shot-counters can finish a map with a ratio of about 1.3:1 ammo DP:monster HP, but most players will have to resort to the axe at some point and will complain of shortage. RPGSP1, which was greeted by universal reviews of "good but I ran out of ammo at the end" still had a ratio on skill 2 of 1.4:1 DP:HP.
There are lots of outliers to these curves, though, because so much of it comes down to how the level design enables the player to use the weapons, as well as exploit infighting, choke points, etc. Do rockets get spent one at a time on individual zombies or can they be used to gib crowds of knights for maximum ROI? or are they useless against herds of shamblers?
It also matters when the player gets the ammo. Ammo the player doesn't pick up or can't use is effectively not present in the map at all. Does it come too late to be used when it was really needed? does it come too early and get skipped? or partially wasted when picked up by a player who's already nearly maxed and getting too much at the wrong times? How much of that ammo is in secret areas?
Collision hull size
32 x 32 x 56
Absolute minimum hallway width
33
Absolute minimum ceiling height
57
ViewPos / camera height above floor
46 (24u mins extent + 22u view offset)
Maximum run speed
320 units / second
Ceiling, low
64u high, bare minimum; bigger monsters won't fit
Ceiling, regular
128u high; recommended minimum
Ceiling, tall
256u+ high
Railing / tabletop
32u high
Ventilation duct
64u wide, 64u tall (there's no crouch button)
--
--
20
40
64u
--
25
3-6 (Bite)
32 x 56
32 x 48
Rottweiler (dog)
25
1-24 (Bite), 10-20 (Jump)
Just melee or just ranged types
Mix melee and ranged types
Fewer monsters, fewer types
More monsters, more types
Elevate / leash ranged monsters
Keep ranged monsters at ground level
Spread out monsters
Pack monsters together tightly
Wide open space
Smaller space with chokepoints
item_shells
Item
+20 (large: +40)
weapon_shotgun
Weapon
+25
weapon_supershotgun
Green Armor (item_armor1)
+100
~33%
--
Yellow Armor (item_armor2)
+150
~60%
50 or lower (to Green)
Breathe underwater, zero slime damage, lava does less damage
30 seconds
Invisibility; but once you attack a monster, it sees you
30 seconds
+100 health, ignores max health; stack up to 250
-1 Health > 100 every 5 sec.


64 x 88
Weapon
(item_armorInv)
Links to various level editors, moddable games, engines, and art tools
We list both modern and ancient level design tools:
: recommended tools for common all-purpose engines today
: short list of moddable games for "serious" level design
also: 2D level editors, 3D art tools, 2D art tools, and planning tools common in the game industry
Today's game engines rarely include level design tools by default, so expect to get custom plugins, or an external tool like TrenchBroom. Many devs also use 3D art tools to make modular kits.
For more info on 3D construction techniques and trade-offs, see Blockout.
, ,
,
, ,
When you mod a game, you get to re-use graphics, sounds, code, and most importantly, core game design and tuning. We strongly recommend learning level design by modding.
We generally recommend Quake and Doom since these games have large active communities, free stable multiplatform tools, and proven design.
Quake 1
(, ); see
static, dynamic (Horde)
visual () + code ()
, ,
Doom
, ()
static
These moddable games are NOT part of our recommended list, for one or more reasons:
player or modder community has died off
OR too old, unsupported, broken, or painful
OR seen as "illegitimate" by the industry (even if the industry is wrong)
But your enthusiasm matters most. The best tool is whatever you will actually use to finish projects.
Call of Duty: Modern Warfare (2007)
CoD Radiant
static
visual
???
Call of Duty: Black Ops 3
)
dynamic (zombies)
If your engine already has a built-in 2D level editor, probably use that. But if you're using a homemade engine or web-based framework, you'll need a standalone 2D level editor - probably Tiled or LDtk.
built-in Godot
; supports autotiles
built-in Unity
, ,
built-in Unreal
? honestly, most wouldn't use Unreal for 2D
more modern standalone editor, streamlined, lots of features with growing engine compatibility
oldest standalone editor, common with lots of features, but probably has less momentum these days
We don't recommend using 3D modeling tools to build levels. But a lot of people do it anyway.
We generally recommend Blender, free open source software that rivals commercial tools.
Older devs often prefer Maya or Max because they already know it. But if you're new to all this, Blender is basically the future.
free and open source; steadily getting more popular in industry with rich feature set
common in games and film, expensive but
common in games and architecture, expensive but
not often used in games but perfectly usable,
used by architects but no / tools, not recommended to use this beyond phase
Good 2D art tools are vital for drawing level layouts and diagrams, and essential for making your own graphics and textures. Some of these tools even run online in your browser for free.
expensive photo-editor / painter
expensive, good for vector maps
expensive, popular powerful texture generator tool
cheap Photoshop / Illustrator alternative
free ad-supported Photoshop clone, in-browser (!)
Good note-taking and writing tools can help you write design documentation, plan a project, track work tasks, and collaborate with others.
a notebook (real-life, paper)
many designers keep personal notebooks; think of it as a portable always-on browser tab
popular freemium service for collaborative whiteboarding / "mindmap" / planning
popular freemium service for notes, lists, wikis, documentation
popular freemium service for "kanban" style project planning in games
cheap ($50) writing tool popular among authors, rich outlining features
for learning 3D level design fundamentals, we recommend modding Quake or Doom
for making 2D levels, we recommend Tiled
for general 3D art, we recommend Blender
for , the world still uses Photoshop
for , we recommend keeping an IRL paper notebook for personal sketches, notes, etc.
but anyway, you should use whatever you feel good about, because making and finishing stuff is more important than social consensus
the ultimate level design tool is "giving a shit"



code (ACS)
Half-Life 2
Hammer++ (SDK 2013 SP or Mapbase)
static / scripted
visual (I/O)
Counter-Strike 2
multiplayer
code (VScript2?), visual (Pulse?)
Portal 2
Puzzle Maker (in-game)
--
visual
Team Fortress 2
multiplayer
visual (I/O)
code (GSC)
???
Crysis 2
Sandbox 2 Mod SDK v1.0
static
???
???
static (stealth)
code (DoomScript)
Divinity: Original Sin 2
Divinity Engine 2 (guides)
scripted (RPG)
Doom 3
static
code (DoomScript)
DOOM (2016)
static / dynamic (Conductor)
visual (Logic entities)
in-game (SnapHub)
DOOM Eternal
static / dynamic (Encounter Manager)
visual (Logic Designer)
Fallout 4
static
code (Papyrus)
Far Cry 5
in-game
static
visual
in-game
F.E.A.R
WorldEdit (FEAR SDK 1.08) (guide)
scripted
???
Fortnite
multiplayer
visual (Devices)
in-game, Reddit
Gears of War
UnrealEd 3
scripted
visual
???
Half-Life 1
static
visual (entities)
Halo Infinite
in-game "Forge" (guide)
multiplayer
visual (nodes)
in-game
Left 4 Dead 2
Hammer (L4D2 Tools)
dynamic / multiplayer
Metro Exodus
visual (VS)
Minecraft
static / dynamic
code (Java Eclipse+Forge)
in-game (guide)
static
???
DarkRadiant (guide)
none
code (DoomScript)
Quake 2
static
visual (entities)
Quake 3 Arena
multiplayer
visual (entities)
Quake 4
static
code (.script)
???
Roblox
all
code (Lua)
Shadowrun
Shadowrun Editor (guide)
scripted (RPG)
code (Gumbo)
Skyrim
static
code (Papyrus)
Stalker: Call of Pripyat
X-Ray Engine SDK
dynamic
???
???
Thief 1 / Thief Gold / Thief 2
static (stealth)
Thief 3
static (stealth)
visual (Actors, Triggerscript)
Unreal Tournament (1999) ("UT99")
multiplayer
visual (Actors) + code (UScript)
Unreal Tournament 4 (dead)
Unreal Engine 4 (guide)
multiplayer
visual (Blueprint)
not actively developed, but still simple and solid
free open source Photoshop alternative
free open source Photoshop alternative
free old school Photoshop alt with bad name
cheap popular pixel art painting tool
free open source Illustrator alternative
free online Illustrator alternative, runs in browser
free (PWYW) moodboard tool / reference image manager
free open source moodboard manager with PureRef-like drag and drop
free open-source lightweight personal wiki that lives in a single .HTML file on your device
Google Docs
sometimes it's best to keep it simple



how to parse Quake 1 models (.MDL) and sample C source code for rendering in 3D
This is a technical file format specification article for programmers.
For 3D artist tutorials and files, see instead.
The MDL file format is the model format used in Quake (June 1996). MDL model files' characteristics are these:
Model's geometric data (triangles);
8 bits texture data;
Frame-by-frame animations;
A MDL file can hold multiple textures.
MDL model file's extension is .mdl. A MDL file is a binary file divided in two part: the header dans the data. The header contains all information needed to use and manipulate the data.
Variable types used in this document have those sizes:
char: 1 byte
short: 2 bytes
int: 4 bytes
float: 4 bytes
They correspond to C type sizes on the x86 architecture. Ensure that type sizes correspond to these ones if you're compiling for another architecture.
Since the MDL file format is a binary format, you'll have to deal with endianess. MDL files are stored in little-endian (x86). If you're targetting a big-endian architecture (PowerPC, SPARC, ...), or simply want your program to be portable, you'll have to perform proper conversions for each word or double word read from the file.
The header is a structure which comes at the beginning of the file:
ident is the magic number of the file. It is used to identify the file type. ident must be equal to 1330660425 or to the string “IDPO”. We can obtain this number with the expression (('2'<<24) + ('P'<<16) + ('D'<<8) + 'I').
version is the version number of the file format and must be equal to 6.
scale and translate are needed to obtain the real vertex coordinates of the model. scale is a scale factor and translate a translation vector (or the origin of the model). You have to first multiply the respective value of scale with the vertex coordinate and then, add the respective value of translate to the result:
where i ranges from 0 ou 2 (x, y and z coordinates).
boundingradius is the radius of a sphere in which the whole model can fit (used for collision detection for exemple).
eyeposition is... eyes' position (if the model is for a monster or other NPC). Make what you want of it.
num_skins is the number of textures present in the file. skinwidth and skinheight are respectively the with and height of the textures. All textures must have the same size.
num_verts is the number of vertices of one frame.
num_tris is the number of triangles of the model.
num_frames is the number of frames of the model.
The vector, composed of three floating coordinates (x, y, z):
Texture data come right after the header in the file. It can be a texture composed of a single picture or a group of pictures (animated texture).
or:
time is an array of nb elements and data an array of nb arrays of skinwidth * skinheight elements (picture size).
Data pictures are contained in the data array and are in 8 bits color index mode. The colormap is generally in a separate LMP file (*.lmp). LMP files are binary files which contain only 768 bytes (256 colors in 24 bits). They are easy to use: just read the whole file in a buffer and it's done. (see )
There are num_skins objects of mdl_skin_t type or mdl_groupskin_t type.
Texture coordinates are stored in a structure as short integers.
Texture are generally divided in two pieces: one for the frontface of the model, and one for the backface. The backface piece must be translated of skinwidth/2 from the frontface piece.
onseam indicates if the vertex is on the boundary of two pieces.
To obtain real (s, t) coordinates (ranging from 0.0 to 1.0), you have to add 0.5 to the coordinates and then divide the result by skinwidth for s and skinheight for t.
There are num_verts (s, t) texture coordinates in a MDL model. Texture coordinate data come after texture data.
Each triangle has an array of vertex indices and a flag to indicate if it is a frontface or a backface triangle.
If a vertex which belong to a backface triangle is on the boundary of two pieces (onseam is true), you have to add skinwidth/2 to s in order to correct texture coordinates.
There are num_tris triangles in a MDL model. Triangle data follow texture coord. data in the file.
Vertices are composed of “compressed” 3D coordinates, which are stored in one byte for each coordinate, and of a normal vector index. The normal vector array is stored in the anorms.h file of Quake and hold 162 vectors in floating point (3 float). (see )
Each frames has its vertex list and some other specific informations.
bboxmin and bboxmax define a box in which the model can fit. name is the name of the frame. verts is the vertex list of the frame.
Frames can be simple frames or groups of frames. We can know if it's a simple frame or a group with a flag:
or:
time and frames are arrays of nb dimension. min and max correspond to the min and max positions in all simple frames of the frame group. time is the duration of each simple frame.
Pay special attention to nb, which is often missing from historical MDL file spec docs. According to Sean May, omitting it "will prevent correctly parsing .mdl files that have looping animations that have no AI control (torches / fires / some of the spiked projectiles)."
Assuming that mdl_model_t is a structure holding all your model's data and *mdl a pointer on a mdl_model_t object, this code show how to load a MDL model file:
Note: this code can't handle MDL files with group frames.
Here is an example of how to draw a frame n of a model mdl:
MDL models are frame-by-frame animated. A frame is a screenshot of an animation. To avoid jerked and ugly animations, we use linear interpolation between vertex coordinates of two consecutive frames (the current frame we are drawing and the next frame). We do the same for the normal vector:
v is the final vertex to draw. interp is the interpolation percent between the two frames. It's a float which ranges from 0.0 to 1.0. When it is equal to 1.0, current is incremented by 1 and interp is reinitialized at 0.0. It is useless to interpolate texture coordinates because they are the same for all the model frames. It is preferable that interp is related to the program's number of rendering frame per second (fps).
Here are some constant values defining maximal dimensions:
Maximum number of triangles: 2048
Maximum number of vertices: 1024
Maximum number of texture coordinates: 1024
Maximum number of frames: 256
Full example C code for loading MDL files.
The C header file that defines all possible vertex normals. (see )
The , in public domain. 256 RGB color values, 3 bytes per color = 768 bytes in total.
colors 128-223 are traditionally used just for player model shirt / pants customization
color 255 {159, 91, 83} is reserved for alpha transparency.
ubyte: 1 unsigned byte
Number of precalculated normal vectors: 162
/* MDL header */
struct mdl_header_t
{
int ident; /* magic number: "IDPO" */
int version; /* version: 6 */
vec3_t scale; /* scale factor */
vec3_t translate; /* translation vector */
float boundingradius;
vec3_t eyeposition; /* eyes' position */
int num_skins; /* number of textures */
int skinwidth; /* texture width */
int skinheight; /* texture height */
int num_verts; /* number of vertices */
int num_tris; /* number of triangles */
int num_frames; /* number of frames */
int synctype; /* 0 = synchron, 1 = random */
int flags; /* state flag */
float size;
};vreal[i] = (scale[i] * vertex[i]) + translate[i];/* Vector */
typedef float vec3_t[3];/* Skin */
struct mdl_skin_t
{
int group; /* 0 = single, 1 = group */
GLubyte *data; /* texture data */
};/* Group of pictures */
struct mdl_groupskin_t
{
int group; /* 1 = group */
int nb; /* number of pics */
float *time; /* time duration for each pic */
ubyte **data; /* texture data */
};/* Texture coords */
struct mdl_texcoord_t
{
int onseam;
int s;
int t;
};/* Triangle info */
struct mdl_triangle_t
{
int facesfront; /* 0 = backface, 1 = frontface */
int vertex[3]; /* vertex indices */
};/* Compressed vertex */
struct mdl_vertex_t
{
unsigned char v[3];
unsigned char normalIndex;
};/* Simple frame */
struct mdl_simpleframe_t
{
struct mdl_vertex_t bboxmin; /* bouding box min */
struct mdl_vertex_t bboxmax; /* bouding box max */
char name[16];
struct mdl_vertex_t *verts; /* vertex list of the frame */
};/* Model frame */
struct mdl_frame_t
{
int type; /* 0 = simple, !0 = group */
struct mdl_simpleframe_t frame; /* this program can't read models
composed of group frames! */
};/* Group of simple frames */
struct mdl_groupframe_t
{
int type; /* !0 = group */
int nb; /* "number", size of *time and *frames arrays */
struct mdl_vertex_t min; /* min pos in all simple frames */
struct mdl_vertex_t max; /* max pos in all simple frames */
float *time; /* time duration for each frame */
struct mdl_simpleframe_t *frames; /* simple frame list */
};int
ReadMDLModel (const char *filename, struct mdl_model_t *mdl)
{
FILE *fp;
int i;
fp = fopen (filename, "rb");
if (!fp)
{
fprintf (stderr, "error: couldn't open \"%s\"!\n", filename);
return 0;
}
/* Read header */
fread (&mdl->header, 1, sizeof (struct mdl_header_t), fp);
if ((mdl->header.ident != 1330660425) ||
(mdl->header.version != 6))
{
/* Error! */
fprintf (stderr, "Error: bad version or identifier\n");
fclose (fp);
return 0;
}
/* Memory allocations */
mdl->skins = (struct mdl_skin_t *)
malloc (sizeof (struct mdl_skin_t) * mdl->header.num_skins);
mdl->texcoords = (struct mdl_texcoord_t *)
malloc (sizeof (struct mdl_texcoord_t) * mdl->header.num_verts);
mdl->triangles = (struct mdl_triangle_t *)
malloc (sizeof (struct mdl_triangle_t) * mdl->header.num_tris);
mdl->frames = (struct mdl_frame_t *)
malloc (sizeof (struct mdl_frame_t) * mdl->header.num_frames);
mdl->tex_id = (GLuint *)
malloc (sizeof (GLuint) * mdl->header.num_skins);
mdl->iskin = 0;
/* Read texture data */
for (i = 0; i < mdl->header.num_skins; ++i)
{
mdl->skins[i].data = (GLubyte *)malloc (sizeof (GLubyte)
* mdl->header.skinwidth * mdl->header.skinheight);
fread (&mdl->skins[i].group, sizeof (int), 1, fp);
fread (mdl->skins[i].data, sizeof (GLubyte),
mdl->header.skinwidth * mdl->header.skinheight, fp);
mdl->tex_id[i] = MakeTextureFromSkin (i, mdl);
free (mdl->skins[i].data);
mdl->skins[i].data = NULL;
}
fread (mdl->texcoords, sizeof (struct mdl_texcoord_t),
mdl->header.num_verts, fp);
fread (mdl->triangles, sizeof (struct mdl_triangle_t),
mdl->header.num_tris, fp);
/* Read frames */
for (i = 0; i < mdl->header.num_frames; ++i)
{
/* Memory allocation for vertices of this frame */
mdl->frames[i].frame.verts = (struct mdl_vertex_t *)
malloc (sizeof (struct mdl_vertex_t) * mdl->header.num_verts);
/* Read frame data */
fread (&mdl->frames[i].type, sizeof (int), 1, fp);
fread (&mdl->frames[i].frame.bboxmin,
sizeof (struct mdl_vertex_t), 1, fp);
fread (&mdl->frames[i].frame.bboxmax,
sizeof (struct mdl_vertex_t), 1, fp);
fread (mdl->frames[i].frame.name, sizeof (char), 16, fp);
fread (mdl->frames[i].frame.verts, sizeof (struct mdl_vertex_t),
mdl->header.num_verts, fp);
}
fclose (fp);
return 1;
}void
RenderFrame (int n, const struct mdl_model_t *mdl)
{
int i, j;
GLfloat s, t;
vec3_t v;
struct mdl_vertex_t *pvert;
/* Check if n is in a valid range */
if ((n < 0) || (n > mdl->header.num_frames - 1))
return;
/* Enable model's texture */
glBindTexture (GL_TEXTURE_2D, mdl->tex_id[mdl->iskin]);
/* Draw the model */
glBegin (GL_TRIANGLES);
/* Draw each triangle */
for (i = 0; i < mdl->header.num_tris; ++i)
{
/* Draw each vertex */
for (j = 0; j < 3; ++j)
{
pvert = &mdl->frames[n].frame.verts[mdl->triangles[i].vertex[j]];
/* Compute texture coordinates */
s = (GLfloat)mdl->texcoords[mdl->triangles[i].vertex[j]].s;
t = (GLfloat)mdl->texcoords[mdl->triangles[i].vertex[j]].t;
if (!mdl->triangles[i].facesfront &&
mdl->texcoords[mdl->triangles[i].vertex[j]].onseam)
{
s += mdl->header.skinwidth * 0.5f; /* Backface */
}
/* Scale s and t to range from 0.0 to 1.0 */
s = (s + 0.5) / mdl->header.skinwidth;
t = (t + 0.5) / mdl->header.skinheight;
/* Pass texture coordinates to OpenGL */
glTexCoord2f (s, t);
/* Normal vector */
glNormal3fv (anorms_table[pvert->normalIndex]);
/* Calculate real vertex position */
v[0] = (mdl->header.scale[0] * pvert->v[0]) + mdl->header.translate[0];
v[1] = (mdl->header.scale[1] * pvert->v[1]) + mdl->header.translate[1];
v[2] = (mdl->header.scale[2] * pvert->v[2]) + mdl->header.translate[2];
glVertex3fv (v);
}
}
glEnd ();
}struct mdl_vertex_t *pvert1, *pvert2;
vec3_t v;
for (/* ... */)
{
pvert1 = &mdl->frames[current].frame.verts[mdl->triangles[i].vertex[j]];
pvert2 = &mdl->frames[current + 1].frame.verts[mdl->triangles[i].vertex[j]];
/* ... */
v[0] = mdl->header.scale[0] * (pvert1->v[0] + interp * (pvert2->v[0] - pvert1->v[0])) + mdl->header.translate[0];
v[1] = mdl->header.scale[1] * (pvert1->v[1] + interp * (pvert2->v[1] - pvert1->v[1])) + mdl->header.translate[1];
v[2] = mdl->header.scale[2] * (pvert1->v[2] + interp * (pvert2->v[2] - pvert1->v[2])) + mdl->header.translate[2];
/* ... */
}void
Animate (int start, int end, int *frame, float *interp)
{
if ((*frame < start) || (*frame > end))
*frame = start;
if (*interp >= 1.0f)
{
/* Move to next frame */
*interp = 0.0f;
(*frame)++;
if (*frame >= end)
*frame = start;
}
}/*
* mdl.c -- mdl model loader
* last modification: mar. 21, 2015
*
* Copyright (c) 2005-2015 David HENRY
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT.
* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
* ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
* CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
* WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*
* gcc -Wall -ansi -lGL -lGLU -lglut mdl.c -o mdl
*/
#include <GL/glut.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
/* Vector */
typedef float vec3_t[3];
/* MDL header */
struct mdl_header_t
{
int ident; /* magic number: "IDPO" */
int version; /* version: 6 */
vec3_t scale; /* scale factor */
vec3_t translate; /* translation vector */
float boundingradius;
vec3_t eyeposition; /* eyes' position */
int num_skins; /* number of textures */
int skinwidth; /* texture width */
int skinheight; /* texture height */
int num_verts; /* number of vertices */
int num_tris; /* number of triangles */
int num_frames; /* number of frames */
int synctype; /* 0 = synchron, 1 = random */
int flags; /* state flag */
float size;
};
/* Skin */
struct mdl_skin_t
{
int group; /* 0 = single, 1 = group */
GLubyte *data; /* texture data */
};
/* Texture coords */
struct mdl_texcoord_t
{
int onseam;
int s;
int t;
};
/* Triangle info */
struct mdl_triangle_t
{
int facesfront; /* 0 = backface, 1 = frontface */
int vertex[3]; /* vertex indices */
};
/* Compressed vertex */
struct mdl_vertex_t
{
unsigned char v[3];
unsigned char normalIndex;
};
/* Simple frame */
struct mdl_simpleframe_t
{
struct mdl_vertex_t bboxmin; /* bouding box min */
struct mdl_vertex_t bboxmax; /* bouding box max */
char name[16];
struct mdl_vertex_t *verts; /* vertex list of the frame */
};
/* Model frame */
struct mdl_frame_t
{
int type; /* 0 = simple, !0 = group */
struct mdl_simpleframe_t frame; /* this program can't read models
composed of group frames! */
};
/* MDL model structure */
struct mdl_model_t
{
struct mdl_header_t header;
struct mdl_skin_t *skins;
struct mdl_texcoord_t *texcoords;
struct mdl_triangle_t *triangles;
struct mdl_frame_t *frames;
GLuint *tex_id;
int iskin;
};
/* Table of precalculated normals */
vec3_t anorms_table[162] = {
#include "anorms.h"
};
/* Palette */
unsigned char colormap[256][3] = {
#include "colormap.h"
};
/*** An MDL model ***/
struct mdl_model_t mdlfile;
/**
* Make a texture given a skin index 'n'.
*/
GLuint
MakeTextureFromSkin (int n, const struct mdl_model_t *mdl)
{
int i;
GLuint id;
GLubyte *pixels = (GLubyte *)
malloc (mdl->header.skinwidth * mdl->header.skinheight * 3);
/* Convert indexed 8 bits texture to RGB 24 bits */
for (i = 0; i < mdl->header.skinwidth * mdl->header.skinheight; ++i)
{
pixels[(i * 3) + 0] = colormap[mdl->skins[n].data[i]][0];
pixels[(i * 3) + 1] = colormap[mdl->skins[n].data[i]][1];
pixels[(i * 3) + 2] = colormap[mdl->skins[n].data[i]][2];
}
/* Generate OpenGL texture */
glGenTextures (1, &id);
glBindTexture (GL_TEXTURE_2D, id);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
gluBuild2DMipmaps (GL_TEXTURE_2D, GL_RGB, mdl->header.skinwidth,
mdl->header.skinheight, GL_RGB, GL_UNSIGNED_BYTE,
pixels);
/* OpenGL has its own copy of image data */
free (pixels);
return id;
}
/**
* Load an MDL model from file.
*
* Note: MDL format stores model's data in little-endian ordering. On
* big-endian machines, you'll have to perform proper conversions.
*/
int
ReadMDLModel (const char *filename, struct mdl_model_t *mdl)
{
FILE *fp;
int i;
fp = fopen (filename, "rb");
if (!fp)
{
fprintf (stderr, "error: couldn't open \"%s\"!\n", filename);
return 0;
}
/* Read header */
fread (&mdl->header, 1, sizeof (struct mdl_header_t), fp);
if ((mdl->header.ident != 1330660425) ||
(mdl->header.version != 6))
{
/* Error! */
fprintf (stderr, "Error: bad version or identifier\n");
fclose (fp);
return 0;
}
/* Memory allocations */
mdl->skins = (struct mdl_skin_t *)
malloc (sizeof (struct mdl_skin_t) * mdl->header.num_skins);
mdl->texcoords = (struct mdl_texcoord_t *)
malloc (sizeof (struct mdl_texcoord_t) * mdl->header.num_verts);
mdl->triangles = (struct mdl_triangle_t *)
malloc (sizeof (struct mdl_triangle_t) * mdl->header.num_tris);
mdl->frames = (struct mdl_frame_t *)
malloc (sizeof (struct mdl_frame_t) * mdl->header.num_frames);
mdl->tex_id = (GLuint *)
malloc (sizeof (GLuint) * mdl->header.num_skins);
mdl->iskin = 0;
/* Read texture data */
for (i = 0; i < mdl->header.num_skins; ++i)
{
mdl->skins[i].data = (GLubyte *)malloc (sizeof (GLubyte)
* mdl->header.skinwidth * mdl->header.skinheight);
fread (&mdl->skins[i].group, sizeof (int), 1, fp);
fread (mdl->skins[i].data, sizeof (GLubyte),
mdl->header.skinwidth * mdl->header.skinheight, fp);
mdl->tex_id[i] = MakeTextureFromSkin (i, mdl);
free (mdl->skins[i].data);
mdl->skins[i].data = NULL;
}
fread (mdl->texcoords, sizeof (struct mdl_texcoord_t),
mdl->header.num_verts, fp);
fread (mdl->triangles, sizeof (struct mdl_triangle_t),
mdl->header.num_tris, fp);
/* Read frames */
for (i = 0; i < mdl->header.num_frames; ++i)
{
/* Memory allocation for vertices of this frame */
mdl->frames[i].frame.verts = (struct mdl_vertex_t *)
malloc (sizeof (struct mdl_vertex_t) * mdl->header.num_verts);
/* Read frame data */
fread (&mdl->frames[i].type, sizeof (int), 1, fp);
fread (&mdl->frames[i].frame.bboxmin,
sizeof (struct mdl_vertex_t), 1, fp);
fread (&mdl->frames[i].frame.bboxmax,
sizeof (struct mdl_vertex_t), 1, fp);
fread (mdl->frames[i].frame.name, sizeof (char), 16, fp);
fread (mdl->frames[i].frame.verts, sizeof (struct mdl_vertex_t),
mdl->header.num_verts, fp);
}
fclose (fp);
return 1;
}
/**
* Free resources allocated for the model.
*/
void
FreeModel (struct mdl_model_t *mdl)
{
int i;
if (mdl->skins)
{
free (mdl->skins);
mdl->skins = NULL;
}
if (mdl->texcoords)
{
free (mdl->texcoords);
mdl->texcoords = NULL;
}
if (mdl->triangles)
{
free (mdl->triangles);
mdl->triangles = NULL;
}
if (mdl->tex_id)
{
/* Delete OpenGL textures */
glDeleteTextures (mdl->header.num_skins, mdl->tex_id);
free (mdl->tex_id);
mdl->tex_id = NULL;
}
if (mdl->frames)
{
for (i = 0; i < mdl->header.num_frames; ++i)
{
free (mdl->frames[i].frame.verts);
mdl->frames[i].frame.verts = NULL;
}
free (mdl->frames);
mdl->frames = NULL;
}
}
/**
* Render the model at frame n.
*/
void
RenderFrame (int n, const struct mdl_model_t *mdl)
{
int i, j;
GLfloat s, t;
vec3_t v;
struct mdl_vertex_t *pvert;
/* Check if n is in a valid range */
if ((n < 0) || (n > mdl->header.num_frames - 1))
return;
/* Enable model's texture */
glBindTexture (GL_TEXTURE_2D, mdl->tex_id[mdl->iskin]);
/* Draw the model */
glBegin (GL_TRIANGLES);
/* Draw each triangle */
for (i = 0; i < mdl->header.num_tris; ++i)
{
/* Draw each vertex */
for (j = 0; j < 3; ++j)
{
pvert = &mdl->frames[n].frame.verts[mdl->triangles[i].vertex[j]];
/* Compute texture coordinates */
s = (GLfloat)mdl->texcoords[mdl->triangles[i].vertex[j]].s;
t = (GLfloat)mdl->texcoords[mdl->triangles[i].vertex[j]].t;
if (!mdl->triangles[i].facesfront &&
mdl->texcoords[mdl->triangles[i].vertex[j]].onseam)
{
s += mdl->header.skinwidth * 0.5f; /* Backface */
}
/* Scale s and t to range from 0.0 to 1.0 */
s = (s + 0.5) / mdl->header.skinwidth;
t = (t + 0.5) / mdl->header.skinheight;
/* Pass texture coordinates to OpenGL */
glTexCoord2f (s, t);
/* Normal vector */
glNormal3fv (anorms_table[pvert->normalIndex]);
/* Calculate real vertex position */
v[0] = (mdl->header.scale[0] * pvert->v[0]) + mdl->header.translate[0];
v[1] = (mdl->header.scale[1] * pvert->v[1]) + mdl->header.translate[1];
v[2] = (mdl->header.scale[2] * pvert->v[2]) + mdl->header.translate[2];
glVertex3fv (v);
}
}
glEnd ();
}
/**
* Render the model with interpolation between frame n and n+1.
* interp is the interpolation percent. (from 0.0 to 1.0)
*/
void
RenderFrameItp (int n, float interp, const struct mdl_model_t *mdl)
{
int i, j;
GLfloat s, t;
vec3_t norm, v;
GLfloat *n_curr, *n_next;
struct mdl_vertex_t *pvert1, *pvert2;
/* Check if n is in a valid range */
if ((n < 0) || (n > mdl->header.num_frames))
return;
/* Enable model's texture */
glBindTexture (GL_TEXTURE_2D, mdl->tex_id[mdl->iskin]);
/* Draw the model */
glBegin (GL_TRIANGLES);
/* Draw each triangle */
for (i = 0; i < mdl->header.num_tris; ++i)
{
/* Draw each vertex */
for (j = 0; j < 3; ++j)
{
pvert1 = &mdl->frames[n].frame.verts[mdl->triangles[i].vertex[j]];
pvert2 = &mdl->frames[n + 1].frame.verts[mdl->triangles[i].vertex[j]];
/* Compute texture coordinates */
s = (GLfloat)mdl->texcoords[mdl->triangles[i].vertex[j]].s;
t = (GLfloat)mdl->texcoords[mdl->triangles[i].vertex[j]].t;
if (!mdl->triangles[i].facesfront &&
mdl->texcoords[mdl->triangles[i].vertex[j]].onseam)
{
s += mdl->header.skinwidth * 0.5f; /* Backface */
}
/* Scale s and t to range from 0.0 to 1.0 */
s = (s + 0.5) / mdl->header.skinwidth;
t = (t + 0.5) / mdl->header.skinheight;
/* Pass texture coordinates to OpenGL */
glTexCoord2f (s, t);
/* Interpolate normals */
n_curr = anorms_table[pvert1->normalIndex];
n_next = anorms_table[pvert2->normalIndex];
norm[0] = n_curr[0] + interp * (n_next[0] - n_curr[0]);
norm[1] = n_curr[1] + interp * (n_next[1] - n_curr[1]);
norm[2] = n_curr[2] + interp * (n_next[2] - n_curr[2]);
glNormal3fv (norm);
/* Interpolate vertices */
v[0] = mdl->header.scale[0] * (pvert1->v[0] + interp
* (pvert2->v[0] - pvert1->v[0])) + mdl->header.translate[0];
v[1] = mdl->header.scale[1] * (pvert1->v[1] + interp
* (pvert2->v[1] - pvert1->v[1])) + mdl->header.translate[1];
v[2] = mdl->header.scale[2] * (pvert1->v[2] + interp
* (pvert2->v[2] - pvert1->v[2])) + mdl->header.translate[2];
glVertex3fv (v);
}
}
glEnd ();
}
/**
* Calculate the current frame in animation beginning at frame
* 'start' and ending at frame 'end', given interpolation percent.
* interp will be reseted to 0.0 if the next frame is reached.
*/
void
Animate (int start, int end, int *frame, float *interp)
{
if ((*frame < start) || (*frame > end))
*frame = start;
if (*interp >= 1.0f)
{
/* Move to next frame */
*interp = 0.0f;
(*frame)++;
if (*frame >= end)
*frame = start;
}
}
void
init (const char *filename)
{
GLfloat lightpos[] = { 5.0f, 10.0f, 0.0f, 1.0f };
/* Initialize OpenGL context */
glClearColor (0.5f, 0.5f, 0.5f, 1.0f);
glShadeModel (GL_SMOOTH);
glEnable (GL_DEPTH_TEST);
glEnable (GL_TEXTURE_2D);
glEnable (GL_LIGHTING);
glEnable (GL_LIGHT0);
glLightfv (GL_LIGHT0, GL_POSITION, lightpos);
/* Load MDL model file */
if (!ReadMDLModel (filename, &mdlfile))
exit (EXIT_FAILURE);
}
void
cleanup ()
{
FreeModel (&mdlfile);
}
void
reshape (int w, int h)
{
if (h == 0)
h = 1;
glViewport (0, 0, (GLsizei)w, (GLsizei)h);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
gluPerspective (45.0, w/(GLdouble)h, 0.1, 1000.0);
glMatrixMode (GL_MODELVIEW);
glLoadIdentity ();
}
void
display ()
{
static int n = 0;
static float interp = 0.0;
static double curent_time = 0;
static double last_time = 0;
glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity ();
last_time = curent_time;
curent_time = (double)glutGet (GLUT_ELAPSED_TIME) / 1000.0;
/* Animate model from frames 0 to num_frames-1 */
interp += 10 * (curent_time - last_time);
Animate (0, mdlfile.header.num_frames - 1, &n, &interp);
glTranslatef (0.0f, 0.0f, -100.0f);
glRotatef (-90.0f, 1.0, 0.0, 0.0);
glRotatef (-90.0f, 0.0, 0.0, 1.0);
/* Draw the model */
if (mdlfile.header.num_frames > 1)
RenderFrameItp (n, interp, &mdlfile);
else
RenderFrame (n, &mdlfile);
glutSwapBuffers ();
glutPostRedisplay ();
}
void
keyboard (unsigned char key, int x, int y)
{
switch (key)
{
case '+':
mdlfile.iskin++;
break;
case '-':
mdlfile.iskin--;
break;
case 27: /* escape */
exit (0);
break;
}
}
int
main (int argc, char *argv[])
{
if (argc < 2)
{
fprintf (stderr, "usage: %s <filename.mdl>\n", argv[0]);
return 0;
}
glutInit (&argc, argv);
glutInitDisplayMode (GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
glutInitWindowSize (640, 480);
glutCreateWindow ("MDL Model");
atexit (cleanup);
init (argv[1]);
glutReshapeFunc (reshape);
glutDisplayFunc (display);
glutKeyboardFunc (keyboard);
glutMainLoop ();
return 0;
}/*
* anorms.h - header file
*/
{ -0.525731f, 0.000000f, 0.850651f },
{ -0.442863f, 0.238856f, 0.864188f },
{ -0.295242f, 0.000000f, 0.955423f },
{ -0.309017f, 0.500000f, 0.809017f },
{ -0.162460f, 0.262866f, 0.951056f },
{ 0.000000f, 0.000000f, 1.000000f },
{ 0.000000f, 0.850651f, 0.525731f },
{ -0.147621f, 0.716567f, 0.681718f },
{ 0.147621f, 0.716567f, 0.681718f },
{ 0.000000f, 0.525731f, 0.850651f },
{ 0.309017f, 0.500000f, 0.809017f },
{ 0.525731f, 0.000000f, 0.850651f },
{ 0.295242f, 0.000000f, 0.955423f },
{ 0.442863f, 0.238856f, 0.864188f },
{ 0.162460f, 0.262866f, 0.951056f },
{ -0.681718f, 0.147621f, 0.716567f },
{ -0.809017f, 0.309017f, 0.500000f },
{ -0.587785f, 0.425325f, 0.688191f },
{ -0.850651f, 0.525731f, 0.000000f },
{ -0.864188f, 0.442863f, 0.238856f },
{ -0.716567f, 0.681718f, 0.147621f },
{ -0.688191f, 0.587785f, 0.425325f },
{ -0.500000f, 0.809017f, 0.309017f },
{ -0.238856f, 0.864188f, 0.442863f },
{ -0.425325f, 0.688191f, 0.587785f },
{ -0.716567f, 0.681718f, -0.147621f },
{ -0.500000f, 0.809017f, -0.309017f },
{ -0.525731f, 0.850651f, 0.000000f },
{ 0.000000f, 0.850651f, -0.525731f },
{ -0.238856f, 0.864188f, -0.442863f },
{ 0.000000f, 0.955423f, -0.295242f },
{ -0.262866f, 0.951056f, -0.162460f },
{ 0.000000f, 1.000000f, 0.000000f },
{ 0.000000f, 0.955423f, 0.295242f },
{ -0.262866f, 0.951056f, 0.162460f },
{ 0.238856f, 0.864188f, 0.442863f },
{ 0.262866f, 0.951056f, 0.162460f },
{ 0.500000f, 0.809017f, 0.309017f },
{ 0.238856f, 0.864188f, -0.442863f },
{ 0.262866f, 0.951056f, -0.162460f },
{ 0.500000f, 0.809017f, -0.309017f },
{ 0.850651f, 0.525731f, 0.000000f },
{ 0.716567f, 0.681718f, 0.147621f },
{ 0.716567f, 0.681718f, -0.147621f },
{ 0.525731f, 0.850651f, 0.000000f },
{ 0.425325f, 0.688191f, 0.587785f },
{ 0.864188f, 0.442863f, 0.238856f },
{ 0.688191f, 0.587785f, 0.425325f },
{ 0.809017f, 0.309017f, 0.500000f },
{ 0.681718f, 0.147621f, 0.716567f },
{ 0.587785f, 0.425325f, 0.688191f },
{ 0.955423f, 0.295242f, 0.000000f },
{ 1.000000f, 0.000000f, 0.000000f },
{ 0.951056f, 0.162460f, 0.262866f },
{ 0.850651f, -0.525731f, 0.000000f },
{ 0.955423f, -0.295242f, 0.000000f },
{ 0.864188f, -0.442863f, 0.238856f },
{ 0.951056f, -0.162460f, 0.262866f },
{ 0.809017f, -0.309017f, 0.500000f },
{ 0.681718f, -0.147621f, 0.716567f },
{ 0.850651f, 0.000000f, 0.525731f },
{ 0.864188f, 0.442863f, -0.238856f },
{ 0.809017f, 0.309017f, -0.500000f },
{ 0.951056f, 0.162460f, -0.262866f },
{ 0.525731f, 0.000000f, -0.850651f },
{ 0.681718f, 0.147621f, -0.716567f },
{ 0.681718f, -0.147621f, -0.716567f },
{ 0.850651f, 0.000000f, -0.525731f },
{ 0.809017f, -0.309017f, -0.500000f },
{ 0.864188f, -0.442863f, -0.238856f },
{ 0.951056f, -0.162460f, -0.262866f },
{ 0.147621f, 0.716567f, -0.681718f },
{ 0.309017f, 0.500000f, -0.809017f },
{ 0.425325f, 0.688191f, -0.587785f },
{ 0.442863f, 0.238856f, -0.864188f },
{ 0.587785f, 0.425325f, -0.688191f },
{ 0.688191f, 0.587785f, -0.425325f },
{ -0.147621f, 0.716567f, -0.681718f },
{ -0.309017f, 0.500000f, -0.809017f },
{ 0.000000f, 0.525731f, -0.850651f },
{ -0.525731f, 0.000000f, -0.850651f },
{ -0.442863f, 0.238856f, -0.864188f },
{ -0.295242f, 0.000000f, -0.955423f },
{ -0.162460f, 0.262866f, -0.951056f },
{ 0.000000f, 0.000000f, -1.000000f },
{ 0.295242f, 0.000000f, -0.955423f },
{ 0.162460f, 0.262866f, -0.951056f },
{ -0.442863f, -0.238856f, -0.864188f },
{ -0.309017f, -0.500000f, -0.809017f },
{ -0.162460f, -0.262866f, -0.951056f },
{ 0.000000f, -0.850651f, -0.525731f },
{ -0.147621f, -0.716567f, -0.681718f },
{ 0.147621f, -0.716567f, -0.681718f },
{ 0.000000f, -0.525731f, -0.850651f },
{ 0.309017f, -0.500000f, -0.809017f },
{ 0.442863f, -0.238856f, -0.864188f },
{ 0.162460f, -0.262866f, -0.951056f },
{ 0.238856f, -0.864188f, -0.442863f },
{ 0.500000f, -0.809017f, -0.309017f },
{ 0.425325f, -0.688191f, -0.587785f },
{ 0.716567f, -0.681718f, -0.147621f },
{ 0.688191f, -0.587785f, -0.425325f },
{ 0.587785f, -0.425325f, -0.688191f },
{ 0.000000f, -0.955423f, -0.295242f },
{ 0.000000f, -1.000000f, 0.000000f },
{ 0.262866f, -0.951056f, -0.162460f },
{ 0.000000f, -0.850651f, 0.525731f },
{ 0.000000f, -0.955423f, 0.295242f },
{ 0.238856f, -0.864188f, 0.442863f },
{ 0.262866f, -0.951056f, 0.162460f },
{ 0.500000f, -0.809017f, 0.309017f },
{ 0.716567f, -0.681718f, 0.147621f },
{ 0.525731f, -0.850651f, 0.000000f },
{ -0.238856f, -0.864188f, -0.442863f },
{ -0.500000f, -0.809017f, -0.309017f },
{ -0.262866f, -0.951056f, -0.162460f },
{ -0.850651f, -0.525731f, 0.000000f },
{ -0.716567f, -0.681718f, -0.147621f },
{ -0.716567f, -0.681718f, 0.147621f },
{ -0.525731f, -0.850651f, 0.000000f },
{ -0.500000f, -0.809017f, 0.309017f },
{ -0.238856f, -0.864188f, 0.442863f },
{ -0.262866f, -0.951056f, 0.162460f },
{ -0.864188f, -0.442863f, 0.238856f },
{ -0.809017f, -0.309017f, 0.500000f },
{ -0.688191f, -0.587785f, 0.425325f },
{ -0.681718f, -0.147621f, 0.716567f },
{ -0.442863f, -0.238856f, 0.864188f },
{ -0.587785f, -0.425325f, 0.688191f },
{ -0.309017f, -0.500000f, 0.809017f },
{ -0.147621f, -0.716567f, 0.681718f },
{ -0.425325f, -0.688191f, 0.587785f },
{ -0.162460f, -0.262866f, 0.951056f },
{ 0.442863f, -0.238856f, 0.864188f },
{ 0.162460f, -0.262866f, 0.951056f },
{ 0.309017f, -0.500000f, 0.809017f },
{ 0.147621f, -0.716567f, 0.681718f },
{ 0.000000f, -0.525731f, 0.850651f },
{ 0.425325f, -0.688191f, 0.587785f },
{ 0.587785f, -0.425325f, 0.688191f },
{ 0.688191f, -0.587785f, 0.425325f },
{ -0.955423f, 0.295242f, 0.000000f },
{ -0.951056f, 0.162460f, 0.262866f },
{ -1.000000f, 0.000000f, 0.000000f },
{ -0.850651f, 0.000000f, 0.525731f },
{ -0.955423f, -0.295242f, 0.000000f },
{ -0.951056f, -0.162460f, 0.262866f },
{ -0.864188f, 0.442863f, -0.238856f },
{ -0.951056f, 0.162460f, -0.262866f },
{ -0.809017f, 0.309017f, -0.500000f },
{ -0.864188f, -0.442863f, -0.238856f },
{ -0.951056f, -0.162460f, -0.262866f },
{ -0.809017f, -0.309017f, -0.500000f },
{ -0.681718f, 0.147621f, -0.716567f },
{ -0.681718f, -0.147621f, -0.716567f },
{ -0.850651f, 0.000000f, -0.525731f },
{ -0.688191f, 0.587785f, -0.425325f },
{ -0.587785f, 0.425325f, -0.688191f },
{ -0.425325f, 0.688191f, -0.587785f },
{ -0.425325f, -0.688191f, -0.587785f },
{ -0.587785f, -0.425325f, -0.688191f },
{ -0.688191f, -0.587785f, -0.425325f }{ 0, 0, 0}, { 15, 15, 15}, { 31, 31, 31}, { 47, 47, 47},
{ 63, 63, 63}, { 75, 75, 75}, { 91, 91, 91}, {107, 107, 107},
{123, 123, 123}, {139, 139, 139}, {155, 155, 155}, {171, 171, 171},
{187, 187, 187}, {203, 203, 203}, {219, 219, 219}, {235, 235, 235},
{ 15, 11, 7}, { 23, 15, 11}, { 31, 23, 11}, { 39, 27, 15},
{ 47, 35, 19}, { 55, 43, 23}, { 63, 47, 23}, { 75, 55, 27},
{ 83, 59, 27}, { 91, 67, 31}, { 99, 75, 31}, {107, 83, 31},
{115, 87, 31}, {123, 95, 35}, {131, 103, 35}, {143, 111, 35},
{ 11, 11, 15}, { 19, 19, 27}, { 27, 27, 39}, { 39, 39, 51},
{ 47, 47, 63}, { 55, 55, 75}, { 63, 63, 87}, { 71, 71, 103},
{ 79, 79, 115}, { 91, 91, 127}, { 99, 99, 139}, {107, 107, 151},
{115, 115, 163}, {123, 123, 175}, {131, 131, 187}, {139, 139, 203},
{ 0, 0, 0}, { 7, 7, 0}, { 11, 11, 0}, { 19, 19, 0},
{ 27, 27, 0}, { 35, 35, 0}, { 43, 43, 7}, { 47, 47, 7},
{ 55, 55, 7}, { 63, 63, 7}, { 71, 71, 7}, { 75, 75, 11},
{ 83, 83, 11}, { 91, 91, 11}, { 99, 99, 11}, {107, 107, 15},
{ 7, 0, 0}, { 15, 0, 0}, { 23, 0, 0}, { 31, 0, 0},
{ 39, 0, 0}, { 47, 0, 0}, { 55, 0, 0}, { 63, 0, 0},
{ 71, 0, 0}, { 79, 0, 0}, { 87, 0, 0}, { 95, 0, 0},
{103, 0, 0}, {111, 0, 0}, {119, 0, 0}, {127, 0, 0},
{ 19, 19, 0}, { 27, 27, 0}, { 35, 35, 0}, { 47, 43, 0},
{ 55, 47, 0}, { 67, 55, 0}, { 75, 59, 7}, { 87, 67, 7},
{ 95, 71, 7}, {107, 75, 11}, {119, 83, 15}, {131, 87, 19},
{139, 91, 19}, {151, 95, 27}, {163, 99, 31}, {175, 103, 35},
{ 35, 19, 7}, { 47, 23, 11}, { 59, 31, 15}, { 75, 35, 19},
{ 87, 43, 23}, { 99, 47, 31}, {115, 55, 35}, {127, 59, 43},
{143, 67, 51}, {159, 79, 51}, {175, 99, 47}, {191, 119, 47},
{207, 143, 43}, {223, 171, 39}, {239, 203, 31}, {255, 243, 27},
{ 11, 7, 0}, { 27, 19, 0}, { 43, 35, 15}, { 55, 43, 19},
{ 71, 51, 27}, { 83, 55, 35}, { 99, 63, 43}, {111, 71, 51},
{127, 83, 63}, {139, 95, 71}, {155, 107, 83}, {167, 123, 95},
{183, 135, 107}, {195, 147, 123}, {211, 163, 139}, {227, 179, 151},
{171, 139, 163}, {159, 127, 151}, {147, 115, 135}, {139, 103, 123},
{127, 91, 111}, {119, 83, 99}, {107, 75, 87}, { 95, 63, 75},
{ 87, 55, 67}, { 75, 47, 55}, { 67, 39, 47}, { 55, 31, 35},
{ 43, 23, 27}, { 35, 19, 19}, { 23, 11, 11}, { 15, 7, 7},
{187, 115, 159}, {175, 107, 143}, {163, 95, 131}, {151, 87, 119},
{139, 79, 107}, {127, 75, 95}, {115, 67, 83}, {107, 59, 75},
{ 95, 51, 63}, { 83, 43, 55}, { 71, 35, 43}, { 59, 31, 35},
{ 47, 23, 27}, { 35, 19, 19}, { 23, 11, 11}, { 15, 7, 7},
{219, 195, 187}, {203, 179, 167}, {191, 163, 155}, {175, 151, 139},
{163, 135, 123}, {151, 123, 111}, {135, 111, 95}, {123, 99, 83},
{107, 87, 71}, { 95, 75, 59}, { 83, 63, 51}, { 67, 51, 39},
{ 55, 43, 31}, { 39, 31, 23}, { 27, 19, 15}, { 15, 11, 7},
{111, 131, 123}, {103, 123, 111}, { 95, 115, 103}, { 87, 107, 95},
{ 79, 99, 87}, { 71, 91, 79}, { 63, 83, 71}, { 55, 75, 63},
{ 47, 67, 55}, { 43, 59, 47}, { 35, 51, 39}, { 31, 43, 31},
{ 23, 35, 23}, { 15, 27, 19}, { 11, 19, 11}, { 7, 11, 7},
{255, 243, 27}, {239, 223, 23}, {219, 203, 19}, {203, 183, 15},
{187, 167, 15}, {171, 151, 11}, {155, 131, 7}, {139, 115, 7},
{123, 99, 7}, {107, 83, 0}, { 91, 71, 0}, { 75, 55, 0},
{ 59, 43, 0}, { 43, 31, 0}, { 27, 15, 0}, { 11, 7, 0},
{ 0, 0, 255}, { 11, 11, 239}, { 19, 19, 223}, { 27, 27, 207},
{ 35, 35, 191}, { 43, 43, 175}, { 47, 47, 159}, { 47, 47, 143},
{ 47, 47, 127}, { 47, 47, 111}, { 47, 47, 95}, { 43, 43, 79},
{ 35, 35, 63}, { 27, 27, 47}, { 19, 19, 31}, { 11, 11, 15},
{ 43, 0, 0}, { 59, 0, 0}, { 75, 7, 0}, { 95, 7, 0},
{111, 15, 0}, {127, 23, 7}, {147, 31, 7}, {163, 39, 11},
{183, 51, 15}, {195, 75, 27}, {207, 99, 43}, {219, 127, 59},
{227, 151, 79}, {231, 171, 95}, {239, 191, 119}, {247, 211, 139},
{167, 123, 59}, {183, 155, 55}, {199, 195, 55}, {231, 227, 87},
{127, 191, 255}, {171, 231, 255}, {215, 255, 255}, {103, 0, 0},
{139, 0, 0}, {179, 0, 0}, {215, 0, 0}, {255, 0, 0},
{255, 243, 147}, {255, 247, 199}, {255, 255, 255}, {159, 91, 83}