Making Your First Map in Quake (Part 2)

For the rest of this series, see Preface and Part 1.

Our Progress So Far

In Part 1 of this tutorial, I covered the tools needed to make and play a map for Quake. Specifically, I explained:

  • The sourceport, Quakespasm, which allows us to play Quake on modern computers.
  • The editor, Trenchbroom, which allows us to make and modify “.map” files.
  • The compiler, EricW Tools , which allow us to turn our “.map” files into playable “.bsp” files.
  • And the compiler graphical user interface, ne_q1sp_compilingGui, which makes it easy for us to use the compiler.

In Part 1, I also explained the folder structure and settings for these tools so that they work together. If you have all of the tools set up, let’s compile our first map!

Exploring a Map

To keep things simple, I have prepared a map for you to use, named “”, which you can download Here. Once you have downloaded the map, move it to your “C:\QuakeDev\working” directory and open the map with Trenchbroom.

When you open the map, you should see something like the image below. If you don’t see any textures, or your editor has a different arrangement, I explain more below.


The Editor Layout

There are four main components to the Trenchbroom level editor.


  1. The Viewport is the biggest part of the screen with a view into the map. By default, this view shows the map in perspective with textures and a grid.
  2. The Toolbar is at the top of the screen, with various tools for editing our map.
  3. The Inspector is on the right side of the screen with information about our selection in the level. At the top of the Inspector, there are tabs for “Map”, “Entity”, and “Face”. The Inspector is where we modify properties of our entities, or apply textures.
  4. Lastly, we have the Info Panel at the bottom of the screen, which informs us of errors and warnings in the level.

If your editor does not look like the picture above, then you can hide or show the Inspector and the Info Panel by selecting “View” in the toolbar, and selecting the relevant option. For now, we don’t need the Info Panel, but we will need the Inspector set to the “Face” tab for the next part of this tutorial.


Adding the Texture Collection

If your view into the level shows a simple grey texture across the floors and walls, like this…


… this means that the texture package, known as a “.wad” file, is not loaded. If you compile the map without textures, the result in game will be an unpleasant red-and-white checkerboard error texture on every surface. Instead, let’s load in a “.wad” file so our map has textures.

For this map, I used the “prototype.wad” by Khreathor. If you did not download the file in part 1 of this tutorial, you can download “prototype.wad” Here. Once downloaded, move the file to your “C:\QuakeDev\Wads” directory.

Now, with the Trenchbroom editor open, go to the Face tab of the Inspector. At the bottom, there is a section labeled “Texture Collections”, where we link our “.wad” files. Select the “+” button to add the “prototype.wad” in your “C:\QuakeDev\Wads” directory. Trenchbroom will then ask for the “Path Type” for your texture collection. Select “Absolute”, and you’re good to go!


Viewport Camera

Now that we have the level loaded with textures, let’s fly around!

With the Viewport in focus (left click within the viewport), the W, A, S, and D keys control the camera movement Forward, Left, Right, and Back, just like playing the game. These directions are relative to where the camera is facing, which you can change by moving the mouse while holding the right mouse button.


The Q and X keys move the camera up and down. Unlike WASD, the Up and Down movement are not based on where the camera is facing; Up and Down are always the same. (If you prefer a different arrangement of keys, you can go to “View” → “Preferences” and then select the Keyboard icon.)

What’s in the Map

Now that we can fly around our level, let’s examine what’s here so far:

  • “Brushes” make up the floor, ceiling, and walls. The pillar with the orange texture is also a “brush”. These are solid blocks that define the level geometry we will see in game.
  • There is an “info_player_start”, which looks like a soldier running with an axe. This is where we will start in the map once we compile and play.
  • There is a “trigger_changelevel” with the “trigger” texture on the far side of the room. This works as our level exit.
  • There is a “monster_army” in front of the exit, to provide a simple obstacle for the player to overcome.
  • Last, there is a “weapon_nailgun” in the middle of the room, so the player has a tool to defeat the monster.

We’ll dig into these more in the next part of the tutorial. What matters for now is that we have the “info_player_start” and our “trigger_changelevel” so that we can play through the level from start to finish.


At this point, we have our map, “”, and we have the textures applied. We also have an idea of the pieces inside the map. Now let’s compile the map so we can play it!

First, let’s open the compiler GUI executable in “C:\QuakeDev\Tools\ne_q1spCompilingGui103”. Here we want to set our “Source Map”, which is on the right side of the program half way down, to “C:\QuakeDev\Working\”. We should also check the “Pause After Compiling” box, which will keep the compiler window open and inform us of errors. With the “Source Map” set, we can now compile by selecting “File” → “Compile”.


With our map compiled, look in your “C:\QuakeDev\id1\maps” folder for “tutorial1.bsp”. This is the compiled map.


If you check your “C:\QuakeDev\Working” folder, you’ll now see some additional files. The original “” file is still there for us to modify, and we also have a copy of the compiled “.bsp” and some “.log” files with information about the compiling process. What matters here is that we still have our “.map” file to modify.


Our Working folder after compiling

Playing The Map

Now that we have a compiled version of our map, we can play it. One easy way to do this is directly from the compiling GUI by selecting “File” → “Run”.


We can also run our map from within game. To do this, first open the Sourceport. Then start a new singleplayer game. Once in game, you can open the console with the tilde key, which lets you enter console commands and cheats. Here if you enter “maps”, you will see a list of all maps available to play, including “tutorial1”. To play this map, enter “map tutorial1”.


Next Time

In Part 3 of this tutorial, I’ll cover the basics of modifying the map so that you can make it your own. Then from there, we’ll take a leap from the basics of the tools to the more conceptual skills and design patterns of making a map for Quake.

In the meanwhile, here are some resources for you to continue learning:

  • Dumptruck_DS’s Trenchbroom Video Tutorials
  • The mapping tutorial on
  • The Quake Mapping Discord for help and questions. (You can ping me @ mclogenog)
  • The Quake level repository Quaddicted
  • The Quake forum func_msgboard. This is where people post new releases and organize mapping events. (This branch of the community can be a little rigid in Quake orthodoxy, and also a bit of a boys club, so visit the forum with caution.)



Making Your First Map in Quake (Part 1)

For the rest of this series, see Preface and Part 2.

In this tutorial, I’ll walk through the basic setup for the tools to make your first Quake map. First, we’ll set up Quake to run with a modern sourceport. Then we’ll set up our level editor, Trenchbroom. Last, we’ll get our compiler running.

If you want to skip this tutorial and jump straight into the tools, you can download Jonathan Linat’s setup All you need to do is add an “id1” folder with your “pak0.pak” and “pak1.pak” files, which I explain below. Also note that Jonathan’s setup includes some tools we won’t be using in this tutorial, and there are some small differences in the file structure.

If you prefer a video explanation for setting up your tools, here is Dumptruck_DS’s quickstart tutorial covering the basics:

The Folder Structure

To start, we need to create some folders. Go to a root directory of your computer, this could be your “C:” drive, or an “E:” or “F:” drive if you use external storage. In this root directory, create a folder named “QuakeDev”. This is where we will keep all of our tools and content.

Inside of “C:\QuakeDev”, create the following folders:

  •  “id1″—where we store the original Quake content and our completed maps.
  • “tools”—where we store our editor and compiler
  • “working”—where we store our rough drafts “.map” files.
  • “wads”—where we store our texture packages, called “.wad” files.

Your folder structure should now look like this:


Quake Game Assets

Now that we have our folder structure, we need to fill it. And the first thing we need is the Quake content so we can play the game.

If you don’t have a copy of Quake already, you can purchase it for a few dollars on steam or gog (where it also includes the expansion packs).

Once you have downloaded a copy of the game, you will need to find the files “pak0.pak” and “pak1.pak” within the “id1” folder. These “pak” files contain all of the game’s content, including the models, textures, sounds, maps, and even the compiled gameplay code! Copy these files, and paste them in your “C:\QuakeDev\id1” folder.


How to find your id1 pak files from a steam download

While in your “C:\QuakeDev\id1” folder, you should also add a  “maps” folder. This is where our final levels will go so we can play them.

The Sourceport

If you have played your copy of Quake through steam or gog, you may have run into problems with the graphics on your modern computer. This is where sourceports come in. A sourceport is a modern version of the engine (a port of the source code) to run the gameplay code with more features and better compatibility.

For a simple sourceport, I recommend Quakespasm, which you can download here: For additional information about Quakespasm, you can visit their website.

I will be using Quakespasm throughout this tutorial, but you may also be interested in trying the Mark V sourceport

Once you have downloaded your sourceport, you should extract the files into your “C:\QuakeDev” directory.

With the sourceport extracted, your “C:\QuakeDev” directory should now look like this:


It’s important that your sourceport executable (“Quakespasm.exe” in this case) is in this folder above the id1 folder, because quakespasm needs the id1 “.pak” files to run.

If you extracted your sourceport into a subfolder, like “C:\QuakeDev\Quakespasm-0.93.1_Win64”, then the sourceport won’t work without additional configuration. You should cut and paste those files to the “C:\QuakeDev” directory.

Testing So Far

Now that you have the game and your sourceport, you should test that everything works. Run “Quakespasm.exe” and attempt to start a new singleplayer game. If everything is correct, you should see something like this:


If instead you see a warning like this…sourceport_error.PNG

… double check that “Quakespasm.exe” and the id1 folder are in the QuakeDev folder, and that “pak0.pak” and “pak1.pak” are directly within the id1 folder.

At this point, you can now play all of the base game for Quake. As you go through this tutorial series, I recommend taking the time to play the first episode of Quake. This will help you develop your tastes as a designer and gain a sense of what works and what doesn’t, especially from a perspective of 2019 looking back at a 23 year old game.

The Level Editor

Now that we can play Quake, let’s set up the tools to make maps.  First, we need a level editor, which let’s us create and modify our “.map” files; this means everything from shaping level geometry to adding monsters and applying textures.

For our level editor, we will be using Trenchbroom, which you can download here: You can also read more about the tools on the main Trenchbroom website.

Once you have downloaded trenchbroom, extract it into your “C:\QuakeDev\Tools” directory. You may also need 7-zip to extract the Trenchbroom files. (7-zip is a tool that allows for better zipped file compression than standard “.zip” files.)

For Trenchbroom and our other tools, the exact directory location does not matter. We could have our Trenchbroom folder in “My Documents” and still be able to work. But it’s good to keep organized with all of your tools in one spot, especially if you have multiple versions of the tools.

Once you have your Trenchbroom files extracted, I recommend creating a shortcut to the “Trenchbroom.exe” in your main “C:\QuakeDev” directory. This will save you time digging through folders, and make life easier for enabling mods later on.


The Trenchbroom file structure and shortcut

Configuring Trenchbroom

Now let’s run Trenchbroom for the first time and make sure it works. First, let’s set our preferences for making Quake maps in Trenchbroom. When you create a new map, there is an option to Open Preferences. Here, you should go to the Quake tab and set the Game Path to “C:\QuakeDev” where your sourceport is.


These preferences are also where you can modify your keyboard, mouse, and display settings for Trenchbroom. For this tutorial series, we will be using the defaults.

Now that the preferences are set, let’s create a new map and select Quake for the game. If everything is working, you should see a screen like this:


I will go into detail on the features of the Trenchbroom editor in a future tutorial. For now, what matters is that it works!

If you saw an error message, or your editor did not launch successfully, you may need these Visual C++ Redistributables.

The Compiler

Quake level design involves two main types of file. There are the “.map” files, which are what we use in our level editor. Then there are the “.bsp” files, which are the compiled maps that we can play. In order to turn the raw “.map” file into a “.bsp”, we have to compile it. This compilation process optimizes the map, creating “view portals” that determine what is visible to the player in the final map. The compilation process also calculates the lighting in our level by “baking” the light data as “lightmaps”, sort of like texture.

You can think of compiling like baking a cake. The “.map” file is the cake batter and the “.bsp” is the cake. While we’re working with the batter, we can still make changes. Once the batter goes into the oven and “compiles”, those changes are locked in. Our compiler tools make our lives a little easier than with baking because we get to keep a copy of the “.map” when it creates the “.bsp” result, instead of having to start a new cake.

For our compiler, we will use EricW’s Tools, which you can download here: You can also read more about EricW’s tools on his website. As a modern compiler, we get many more options than were possible with Quake back in 1996, like sunlight and bounce lighting!

Once you download EricW’s compiler, extract it to “C:\QuakeDev\Tools”. Your folder should now look like this:


Inside of the ericw-tools folder, you should then have a “bin” folder and a “doc” folder. The “bin” folder contains the “binaries” which are the executables that run the various stages of “.map” compilation.

You now have everything you need to make and compile a map! But, let’s make our lives a little easier with a graphical user interface for our compiler. For this, we will be using the Necros Compiler GUI, which you can download here: You can also read more about the compiling GUI on the tool’s website, The Shores of Nis.

Once you download the compiler GUI, extract it to “C:\QuakeDev\Tools”. Your folder should now look like this:


Now we need to set up our compiler GUI to know about the actual compiler tools. Go to “C:\QuakeDev\Tools\ne_q1spCompilingGui103” and run “ne_q1spCompilingGui103.exe”. From here, let’s go to “settings” and then “folder setup”. On this screen, we need to make three changes:

  1. Set the “Tools Folder” (in the top left) to the “bin” folder containing the EricW compiler tools.
  2. Set the “Working Folder” (in the middle right) to the “C:\QuakeDev\Working” folder we created earlier. This is where the compiler will save a copy of our “.map” and output warning logs for errors.
  3. Set the “Output Folder” to “C:\QuakeDev\id1\maps”. If you did not create this “maps” folder earlier, do so now. This is where our compiled “.bsp” will go so we can play them.

Once you have completed these steps, your compiler settings should look like this:


Now select “Done”, which returns you to the main screen of the compiler GUI. Here, we need to set the “Quake Engine” to our sourceport. Once we have a map to compile, we will also want to change the “Source Map”.


As with Trenchbroom, I recommend creating a shortcut to the “C:\QuakeDev\Tools\ne_q1spCompilingGUI\ne_q1spCompilingGUI.exe” that you can access from the main “C:\QuakeDev” directory.

One Last Thing

All you are missing now to make your own first Quake map are some textures. To keep things simple to start, I recommend downloading id1_wads_per_map, which includes a “.wad” texture package for each level in the original game. I also recommend Khreathor’s prototype.wad, which has simple grid textures and a variety of colors.

Extract your “.wad” texture packages into the “C:\QuakeDev\Wads” directory to keep things organized.

Next Time

For Part 2 of this tutorial series, I explain how to use these tools that we’ve set up. I also explain how to take a basic map through the compilation process. In Part 3, we’ll start modifying our first map and learning some features of the tools. From there, we’ll explore the design patterns of Quake.

In the meanwhile, here are some resources for you to continue learning:

So You Want to Learn 3D Level Design

Maybe you are a student of game development and want to specialize in level design. Maybe you are a game developer already, but want to learn some new skills. Or maybe you’re a hobbyist and want to build strange new worlds. Whatever drew you to 3D level design, you may not know where to start.

If your goal is to make an entire game, or if your focus is learning the tools used by professional level designers, you should look into learning the Unreal Engine or Unity.

However, if your goal is to learn the conceptual skills of level design, to go beyond learning the tools and practice design, then you are in the right place! Practicing design requires a context, and with level design that means building levels for a game. If you build 3D environments without that context, you will learn the tools, but you won’t learn design.

With this goal in mind, this tutorial series covers the basics of designing a level for Quake.


E1M5 loaded in the Trenchbroom level editor

Why not Half-Life 2, which has stronger thematic variety and more assets to draw from? Or why not Counter-Strike: Global Offensive, which has an active mapping community? Why Quake?

  1. Quake has modern tools that are easy to learn and use. This lets us minimize our time learning the tools so we can focus on design fundamentals instead.
  2. Quake has a tight focus to its gameplay. There is a small range of weapons, enemies, and environments, and these constraints keep the design context simple. These constraints also let us avoid the distracting features of modern game engines.
  3. Quake has an active mapping community that will playtest, offer feedback, and help you check your design ideas against reality.

But, learning 3D level design through Quake comes with some downsides: the beneficial constraints can be an expressive limitation; we don’t have preview lighting in the editor, which makes lighting a little tricky; and also, some of the construction paradigms are specific to Quake’s tools.

Once again, if your goal is to make an entire game, or to learn the tools of professional level design, you should look into tutorials for the Unreal Engine or Unity. My goal with the tutorial series here is to help you practice design skills with minimal technical obstacles.  And whatever your goals are, I hope these tutorials will offer some new insights!

In Part 1, I walk through the setup for the game and the tools. In Part 2, I cover the map compiler and the basics of level editing. From there, we’ll explore the design patterns for Quake, and how to create memorable levels.

Making Your First Map in Quake (Part 1)

Release Notes for Toybox

Last weekend I released my Quake mod “Toybox”, which offers two new maps of open-ended exploration with an emphasis on joyful movement. You can download the mod from dropbox or quaketastic.

If you don’t have Quake but are still curious about Toybox, here’s my video playthrough:

Or keep reading for my design notes below!


Map Pack or Mod?

When I released Toybox, I wasn’t sure whether to call it a map pack or a mod. The enemies and items are all still Quake in their function and presentation. The code changes—all part of progs_dump by dumptruck_ds—are there to simplify level creation, but most of the gameplay in Toybox is possible without modified code.

The most striking modification in Toybox is how the levels look. Quake has never been so bright and colorful before. However, I did not change the color palette. These colors were always available to modders, but seldom used. Even before we add colored fog and lighting, which are features of modern sourceports, Quake has what it needs to be bright and colorful instead of dark and brown.


Quake’s color palette

My level design for Toybox is the other modification. In Quake, most levels offer a sequence of obstacles to overcome. Some of these obstacles, like locked doors and keys, serve as goals to guide the player and structure their progression through the level. Other obstacles, like traps and combat encounters, are the heart of the experience; these obstacles ask players to react with skill or die.

Instead of this structure, I built my Toybox levels for a nonlinear progression. Both levels have two keys, which together open the exit, but players can choose the order they seek them. There are multiple methods to acquire most of the keys, and there are other objectives in the form of runes and secrets for the players to pursue. My hope with the open layout and objectives is for players to explore at their own pace.

Importantly, I didn’t use secret tags. In normal Quake maps, players can track how many secrets there are to find. But with my Toybox levels, some secrets aren’t possible on the first playthrough. Specifically, both levels have secrets that require runes from the other level. If I tagged these areas as secrets, and players saw they had some number of secrets left to find, I worried that my players would spend hours looking everywhere in the map instead of moving on. By not tagging any secrets, I hope my players exit the level when they are satisfied with their exploration.

I also included a tourist mode instead of the traditional easy mode. This option lets players explore the world without any monsters to fight, and lets players focus on exploration, level interactivity, and the joy of Quake’s movement. Because the keys in each level aren’t tied to monsters or combat encounters, it is possible to complete both levels in this mode.

Playgrounds and Living Worlds

Some of my design goals for Toybox started with “Recursion”, a map I released in August 2018. With that map, there were four goals for the player to complete in any order. Completing each goal would reset the level to the start, and reset the enemies and items with it. One of my inspirations for this was Super Mario 64, which sends the player back to the hub after completing each goal; this reset may have been for technical reasons at the time, but it was also a way of keeping the world alive and changing across multiple objectives. For Recursion, this reset meant that players lose the territory they claimed after each reset. The player’s role was no longer to conquer the dungeon, but to pass through a world that would persist without them.

With Toybox, I tried this a different way. When the player enters the level, there are monsters roaming, and the player can kill them all before proceeding with any of the goals. However, many of the monsters aren’t a threat until the player wanders nearby, so there is no urgency to clear the level. With this as the baseline, each key the player finds adds a new horde of monsters to the level. Some of these reinforcements pose immediate threats to the player, but others are there to reclaim territory and offer new challenges as the player continues to explore.

Both Toybox and “Recursion” are imperfect attempts to create a world that players can’t consume. Ideally, the monsters would respawn on their own. Or instead of dying, the monsters would freeze or stun for several seconds

For “Recursion” and Toybox, I drew inspiration from the design of playgrounds. In my work, I want to create persistent spaces for non-prescriptive play. But to achieve this goal, I’ll need to mod Quake in ways that change its identity.

Toybox as Subversion

Most of the Quake community focuses on the craft. There are over two decades of work refining techniques specific to Quake and its tools. Most of this work exists within Quake’s language of dungeons, monsters, and gore. A few works, like czg’s Honey, push to the fringe of traditional aesthetics and expand the language of what a Quake map can be. But, compared to the Doom mod scene, Quake remains conservative. Even in the Quake-inspired and Quake-derived retro-shooter renaissance of Dusk, Prodeus, and Wrath, it’s still monsters, dungeons, and gore. (So much focus on gore, you’d think that’s all Quake is missing…)

My hope with Toybox is to nudge this conservatism. Within the Quake modding community, I want to encourage others to explore outside the established techniques and craft. I also want to signal to a wider community of developers that there is room here to make strange and beautiful worlds. I want people to know that Quake can be more than its dungeons and monsters and gore. Of course, Quake is excellent at those things too; this isn’t a one-or-the-other situation.

Through the simplicity of Quake’s modding tools, I see the potential for a new generation of developers to learn the skills of 3D level design. But for this to be possible, we have to create space where different forms of expression are welcome. We have to show outsiders a reason to join. One of my hopes with Toybox is to start making that space so more experimental and personal work can follow.

There is more I want to explore in the ideas around Toybox. I want to do more with the design language of playgrounds and welcoming environments. To do this within Quake, I have to modify the code more deeply and push my work away from this ambiguity between mod and map pack. With its own identity, my project will lose its power as a subversion of Quake.

So, while there is more I want to do, I felt it was important to release Toybox in its current form. In this release, version 1, Toybox occupies a happy space as both mod and map pack, as both Quake and something all its own.

Special Thanks

To close out this post, there are some folks I want to thank:

First, thanks to dumptruck_ds for his progs_dump mod framework, and for all of his support in the Quake community. Without his work, the Toybox levels would have been a pain to create, and a few of their features would have been impossible. It is also thanks to his tutorials that I started making maps for Quake around this time last year.

Second, I want to thank Benoit Stordeur (aka Bal). He was the first playtester for the mod, and his feedback and enthusiasm motivated me to continue with these ideas. Without his encouragement, I might not have finished Toybox at all.

I also want to thank the level design community beyond the mod scene, especially those of you who see what I’m doing here and say “huh!” with legitimate curiosity. Even if you don’t get a chance to play this mod, I hope you’ve found this post useful for your own work.

Lastly, thank you for reading!

Notes on Welcoming Spaces in Games

Last week I posed a question to my friends in level design and environment art: how do we create welcoming spaces in our games?

I received many great answers on shape theory and lighting, answers on specific objects for the feelings they evoke, and answers on mechanics to create a welcoming space. However, the variety of answers exposed a flaw in my question. What does “welcoming” mean?

When I posed the question, I framed “welcoming” as the opposite of feeling apprehensive or wary. Level design and environment art have many techniques to make the player afraid to move forward. We also have shorthand and tricks that have become clichés over the decades: the blood trails and graffiti warnings, the flickering lights and tilted halls. Within this context, I asked what techniques we have to achieve the opposite effect of apprehension.


System Shock 2 (1999)

I received two types of answers to my question. The first type considered “welcoming” as a feeling about a space. That is, if we imagine a room with no door or world outside, what makes the player feel welcome in that room? The second type considered “welcoming” as a feeling of contrast while moving from one state toward another, better state. That is, if we imagine a building in a world, what makes the building more welcoming than the world around it?

My hope, in turning this conversation into a post, is to clarify the question and highlight some ideas for us to explore further. Eventually, I hope we will techniques as robust—and even clichéd—as our toolkit for creating apprehension and dread in our games.

Welcoming as Contrast and Movement

To start, imagine again that abstract building in an abstract world.

But let’s be specific. Imagine a spooky forest on a cold night. Imagine a cozy cabin on a hill in a clearing. Wandering the forest, we hear wolves howling. Right as we think we’ve lost our way, we see a path leading up to the cabin. We see the warm light of a fireplace illuminating the windows. We see smoke curling gently from the chimney. We approach, still unsure if we should ask for shelter or continue on our way, but we hear music and laughter within. This is a welcoming feeling, to be drawn or attracted toward an appealing space.

Now instead of a forest, let’s imagine a nuclear wasteland. We hear the flesh-hungry mutants howling. Our gas mask filter is worn out, and we could use some clean water and food. Instead of a cozy cabin, there’s a rusty metal shack. It shows no signs of life, or death, which is a good thing when there are bandits around. A dusty window will let us peek inside to be sure it’s safe before we enter. Maybe there will be supplies to salvage? At the very least, the shack means a moment of shelter on our journey.

Is this still welcoming? We should be cautious approaching the shack because this is a hostile environment, but the shack itself is neutral or better than the world around it. We are not repelled, and the possibility of supplies is attractive.

For both of these examples, the buildings offer the possibility of satisfying our needs for survival. There is the possibility of food, water, and rest. But even if we can’t satisfy these needs, the building itself offers shelter from a hostile environment. Both buildings are more positive than the world around them, which makes them attractive. But are both welcoming in the same way?


Near Death (2016)

Before we go too far, let’s look at a specific example from games. In Near Death (2016), the player is trapped at an Antarctica research station in a blizzard and has to find a way to survive. There are no monsters or enemies, only the cold and the wind. The buildings also aren’t enough on their own to warm the player. For that, the player uses a portable heater and a limited supply of kerosene. In some buildings, the windows are blown out and need patching before the player can use the space to recover and warm up.

Because of these mechanics in Near Death, venturing out to each new building is a gamble. There may be supplies, like more kerosene. Or there may be blown-out windows that demand supplies to repair, adding an element of attrition. But, as the player moves through the research station, the known and safe territory expands. Backtracking into a room the player knows to be safe produces that welcoming feeling.


To turn these examples into a more abstract case, we have something like the diagram above. The player is in a hostile world, sees a safe building, and moves toward it. Arising from the environment’s context and from the movement toward a positive space, the player feels welcome.

The exact cause and effect is not clear here. Does the player experience the welcoming feeling before deciding to move toward the building, or after? Are the feeling and action simultaneous, or is one in response to the other? These are difficult questions. My hunch, borrowing from appraisal theory, is that the emotion follows initial stimuli and cognitive appraisal of the environment context.

If we change the environment context, or change the direction the player is moving, the player experiences different emotions.


This diagram is a fuzzy way for me to condense several of my subjective experiences, so treat it with caution! The emotional labels here are imprecise. The importance of this diagram is to isolate the welcoming feeling from related experiences, which deserve their own investigation.

Specifically, moving toward a positive state may not be enough on its own to make the player feel welcome. There is some aspect of entering a building or an enclosure that contributes to the welcoming feeling. This may be an association with safety and refuge, but I’m not sure if this real-world association is strong enough to override when a game’s mechanics make interiors more dangerous than exteriors.

Valence Theory

What about more complex examples? What if we remove the threshold between building and world? For example, what if instead of a building we have an opening in the forest? There is no door to open, but standing in the clearing will feel different from standing among the trees. Or what if there are two different cabins to choose from, or a whole village?

To handle these more complex cases, we can borrow from what Robert Yang dubbed “valence theory”, which was itself adapted from Randy Smith’s GDC 2006 model of “Level Building for Stealth Gameplay”. An important feature of this model is that the states within the environment are fuzzy and imprecise. The states have gradients of intensity and overlapping boundaries.


A node layout from Aubrey Serr’s GDC 2019 talk

Aubrey Serr’s GDC 2019 talk “Designing Radically Nonlinear Singleplayer Levels” also adapted Randy Smith’s model, but with a strong emphasis on the cloudy quality of each state within the level. Serr’s diagrams add objectives (indicated by stars) to explain why players move through negative states instead of staying where they are safe.

With these more complex networks and fields of polarized space, what does the player feel? Is the nuance of a welcoming feeling lost to the less specific feeling of tension and release? There is more for us to investigate here.

What Makes the Player Move?

So far I’ve described the welcoming feeling as a product of moving from a negative state toward a positive one where there is some element of enclosure and safety. But what attracts the players in the first place and motivates them to move?

With my example of the cabin in the forest and the shack in the wasteland, I assumed human needs and interactions. We need food, shelter, and water. If there are people in the cabin, we could talk to them. If there are supplies in the shack, we could salvage them. With video games, we can’t count on any of these real-world assumptions.

For example, the Doom games invert our expectations. For us humans, hell is bad, and Earth is (comparatively) good. But for doomguy, who only wants to rip and tear, Earth is boring. Doomguy runs toward hell.


Beyond Doom’s simple inversion, we can make our valence model a proper mess by looking at states that simultaneously attract and repel the player.

Let’s imagine the forest scenario again, but now as a horror game. Instead of a cabin, we have a haunted house. Instead of the warm light of a fireplace, we see some eerie glow of mysterious origin. Instead of laughter and music, we hear chains and electric crackling from somewhere below.


The forest in this imagined horror game is not pleasant, but also not hostile. Looking around, we see a fence some distance into the trees, and if we checked, we’d find that we are unable to cross it. We also have no way to interact with the forest, and there is nothing to do but walk in circles or approach the house. Let’s say this imaginary game also has no mechanics for hunger or thirst, and we don’t need to worry about hypothermia outdoors. Within this context, why does the player leave the safety of the forest to face the danger of the haunted house? Something attracts the player at the same time the threat of danger repels.

In Miriam Bellard’s GDC 2019 talk on “Environmental Design as Spatial Cinematography”, she described several ways that environments attract players and influence their movement. First, there are mysteries that draw the player to seek information. A towering landmark in the distance may not be enough to draw the player, but if there is a mystery around the landmark, then the player has a reason to investigate. Second, Bellard describes multiple ways that object affordances motivate the player to move through a space. To oversimplify a complex topic: people tend to move toward areas with greater affordance opportunities. Or, in game terms, players tend to move toward interactivity. (Watch Bellard’s talk for the more nuanced explanation.)

To return to our horror game example, mystery and affordance draw the player at the same time that the aesthetics, and the dangers they suggest, repel us. This tension of both wanting and not wanting to proceed is at the heart of horror games. The player feels a dissonance of wanting to know the mystery but not wanting to face the danger on the way.


The start of Gone Home (2013), which hooks the player with mystery.

But the welcoming feeling is in opposition to mystery. In my example of the cozy cabin in the woods, we may hesitate because of the unknown, and we need reassurances to overcome that uncertainty and feel welcome. Or in my example of the shack in the nuclear wasteland, we would be far more apprehensive if there was no window to peek through before we step inside.

Without mystery as a tool, what remains from Bellard’s toolbox is the attraction of affordances. Inside the cozy cabin, or inside the shack, we know there are things to do. But if the game offers no ways to interact in these spaces, then there is no attraction; the cabin and shack are no longer positive spaces for us to be drawn toward and feel welcome.

However, there are forms of play not represented within game systems and mechanics that can still attract the player. Non-interactive spaces can still serve role playing, imaginative play, and social interaction.


“Lon Lon Ranch” from Ocarina of Time as depicted on

For example, in Legend of Zelda: Ocarina of Time (1998), there is “Lon Lon Ranch” where the player has several optional activities to earn valuable items throughout the game. Once the player completes these activities, the game no longer offers incentives to spend time there. The space becomes minimally interactive. There are still things to do, like chasing the chickens, but the game offers no reason to interact beyond intrinsic enjoyment. Yet, when I played Ocarina of Time, I would return to “Lon Lon Ranch” between the game’s dark and scary dungeons. This was a welcoming space.

Beyond the ideas of affordances and mysteries, there is more we can explore:

  • Are players drawn toward aesthetic beauty, and in what contexts?
  • What about safety and comfort?
  • Or community and a sense of belonging?

Before moving on to the idea of welcoming as a state, here’s a summary of what we have so far:

  • The welcoming feeling arises while moving toward a positive state, often enclosed, where there is the promise of safety and interactivity.
  • The player moves toward affordances, mysteries, and rewards. The player’s movement may not align with the welcoming feeling at all!
  • If we want welcoming spaces, we need to create the reasons and opportunities for our players to enjoy them.

Welcome as a State

Back at the start I said how the responses to my question fit two types. Now that we’ve explored the welcoming feeling as contrast and motion, let’s explore the welcoming feeling as a state.

Thankfully, a 2017 Project Horseshoe report about “Coziness in Games” did most of the work already! As part of the section on cozy aesthetics, the authors suggest literally welcoming the player into a space:

When the player is explicitly positioned as a welcomed entity, this gives them the freedom and safety to express themselves. This welcome does not imply responsibility or pressure on them as a hero … but rather welcomes them as a person, to join whatever activities are available, or to be alone, as they wish. Bartenders often greet newcomers with a welcome, whether the tavern is digital or physical, to encourage a longer and more leisurely visit.

The other patterns for cozy aesthetics are about safety, protection, and abundance. A welcome environment is one where players are supported and feel like they belong.

Welcoming as Dominant Mode

Most of these cozy spaces described in the Project Horseshoe report are small rooms that fit within one screen. If we expand these spaces, we may lose the cozy aesthetic, but how far can we push them while the player still feels welcome?

In some levels, the welcoming feeling of safety is the dominant mood. There may be pockets of risk or danger, but they are isolated with clear boundaries.


“Bob-omb Battlefield” as depicted on

For example, the first main level of Super Mario 64 (1996) is sunny and verdant. There are friendly NPCs to greet the player at the start, and the first real obstacle the player encounters is the Chain Chomp. This enemy is literally leashed to a pole and can’t escape. A red coin on top of the pole encourages the player to toy with this boundary. Within this safe context, danger is made a tool of play. The other enemies in the level also have leash-like behavior where, if the player runs far enough away, the enemies will give up the chase. But the boundaries here are more subtle than the Chain Chomp’s.


The Chain Chomp enemy in “Bob-omb Battlefield”,  taken from the Mario Wiki

If we return to our valence theory from earlier, this first level of Super Mario 64 looks a bit like the diagram below. For each of the level’s risks, the players can retreat to safety and try again when they are ready.


“Bob-omb Battlefield” as depicted on, with our valence diagrams on top.

Mette Pødenphant Andersen’s GDC 2019 talk “Hitman Levels as Social Spaces” also highlights the idea of spaces where the player is welcome. In the level “Sapienza” from Hitman (2016), a welcoming public space surrounds a walled villa. Between these public and private spaces, there are clear boundaries so players know when they are trespassing and toying with the level’s risks, much like the player’s experience with the Chain Chomp in Super Mario 64. Other spaces have softer boundaries, but if the player can’t manage the risks, then the large public space allows the player to retreat and find another way.


The social spaces in “Sapienza” from Mette Pødenphant Andersen’s GDC 2019 talk.

How far can we expand these welcoming levels? Can we make the whole game welcoming?

For Super Mario 64 and many of the 3D platformers like it, the welcoming levels are only there at the start. As players progress, the levels ask more of the players’ abilities, and the level aesthetics turn dangerous to match theses mechanical demands. As a consequence of these dangers, the early levels like “Bob-omb Battlefield” become even more welcoming when the player returns. Or for Hitman, “Sapienza” becomes a vacation from harder levels like “Colorado” where there are no public spaces. In both games, these welcoming levels become a genuine reprieve because of the harder levels ahead.

Ideas to Explore Further

Phew! I hope these early notes have highlighted some techniques and ideas to explore. There are also more specific ideas that I didn’t cover. In particular, I am left with a few questions that I hope to investigate in the future:

  • We feel welcome when visiting a friend’s house, but we don’t use “welcome” to describe the feeling we have in our own house. Why?
  • At what point does welcome becomes mundane and boring?
  • Is the welcoming feeling holistic, where one element out of place disrupt it? Does this make shorthand techniques impossible?
  • Bonfires! How much of the attraction to bonfires is a real-world association that we bring to games, and how much is an in-game association with mechanics?
  • “Welcoming” as an act, or ritual that we perform for our guests. What games explore this?

Thanks for taking the time to read! If you explore these ideas in your own work, or are aware of more games I should study, I hope you’ll let me know :)