More About Level Design and Constraints

In my previous blog post, I described level design as constraint management. Level designers take the needs of art, design, and tech, and we try to resolve their conflicts through the process of creating our levels.

In that post I also hinted that the way we negotiate these constraints is by building level geometry; we negotiate through the process. The complexity of all these constraints is too great to solve in our heads or solve on paper; we have to build and iterate on our proposed solutions, which are our levels.

On team projects, this also means the purpose of a level blockout is to communicate with teammates across disciplines. The blockout should communicate our solution so others can evaluate if it works for their need.

But, shame on me, my previous post didn’t give examples from an actual level and blockout process! Thus, the need for this followup post.

To keep the example simple, let’s say I’m once again making a Quake 1 singleplayer map.

Imagine I already have a beginning to the map, which slowly sets a mysterious tone and sense of place in overgrown ruins. Imagine I have also introduced the basic weapons and monsters for the level, gradually raising the tension. As the player delves deeper into the ruins, the floor falls out from under them and drops them into an encounter room!

I have a few ideas for how to build this encounter:

  • At first, no enemies. The space should start as a puzzle-exploration room, then turn into a combat room.
  • There should be a clear goal for the player. I want them to see the exit in their first scan of the room but not know how to reach it. Maybe an exit to an ascending staircase that the player can see across a chasm too wide to jump.
  • As the player explores the room, looking for a way to reach the exit, they should discover a few buttons. When the player activates one of these buttons, some level geometry in the middle of the room rises, forming a platform for a few seconds, and then reverts. Individually, it isn’t clear how these buttons and platforms help. But once the player has discovered them all and tested some combinations, they grant the player access up onto a ledge, where an intermediary goal waits!
  • Because the buttons are on timers, the player should have smooth paths around the space, no awkward turns or frustrating collision. The buttons should also ideally have a view on the platforms they trigger.
  • At the intermediary goal on the ledge, there is a use-once switch. When the player activates this switch, a new platform ascends at the chasm. This new platform still isn’t enough for the player to jump all the way across to the exit, but it hints that one more platform should be enough.
  • The ledge with the intermediary goal should also show the position of the other intermediary goal so the player knows where to go next.
  • The player should now *get* what they need to do to escape. The player has solved the puzzle and now just need to complete it. This is good for player-intentionality, but it’s also boring. So now let’s add monsters!
  • I want to gradually shift the tone from puzzle-exploration to combat, so I will open monster closets in waves. This means the same puzzle space from before should also serve for combat: no awkward dead-ends or bad collision for the player or monsters to get stuck on.
  • The ambush should surprise the player. This means the monsters can’t be waiting behind locked doors from the moment the player first falls into the room; that would be obvious! I also want the player to think “ah if only I had paid closer attention, I could have anticipated!” This means no teleporting monsters into the arena. A tricky problem!
  • The monster variety during this combat encounter should escalate over time. Depending on how I’ve built the space, some monsters may not work.
  • Once the player defeats all the waves of monsters, the player should now be able to reach the other ledge and complete the second intermediary goal.
  • When the player presses the use-once switch for the second intermediary goal, a second platform ascends, completing a jumping path across the chasm to the exit.
  • As the player prepares to cross to the exit, one final wave of monsters! A “boss” wave! This may also be a great opportunity to drop in a quad damage powerup to increase the intensity. For this phase of combat, teleporting the monsters in is OK. (The player’s expectations should have shifted after the first combat waves, and they should be expecting more combat at any moment, so teleport spawning no longer feels as cheap.)
  • At last, the player kills all the monsters, reaches the exit, and returns to the rest of the level above! The encounter room is complete!

Those are my initial goals for the encounter room (revised a little for clarity). Already, I noted a few challenges in making this encounter work, but I need to build the space to see. Sketches can help me identify more of these problems before I move into the level editor. Likely, I will change my plan for the space as I build it and struggle with all of the moving parts. Then, once I’ve built the level, my pan will definitely change with playtesting.

FullSizeRender(4)

A quick sketch of the encounter, and just enough info to block out the space in the editor.

So far, the biggest conflicts in this encounter room are between gameplay types. What works well for a puzzle-exploration phase at the start might get in the way during the combat later on. For example, I want the buttons to be hidden enough that the player needs to explore the space, while for combat I don’t want the space to sprawl or become too fragmented.

The other conflict is handling the surprise. When the player first falls into the room, I need to reassure them that this is a puzzle room, that there aren’t any monsters around, nor any combat-cover, nor suspicious monster-closet locked doors. But the room still needs all of those things for the combat phase!

 

Untitled document(7)

Turning the encounter into a constraint diagram, there are a lot of conflicts! And this is before we consider art…

I need to solve these conflicts as I built my level. Already, this encounter room is a challenge to build well! But my constraints so far are mostly about the abstract gameplay…

Time for Nightmare mode. “Architectural Realism” adds a whole new set of constraints:

  • What was the purpose of the room originally? Who built it, when, and why?
  • How has the room fallen into this state of ruin? Is it water damage? Erosion undercutting the foundations? Was there a singular event that led to this state, like a flood, earthquake, or explosion?
  • How do the buttons operate? Are there moving chains and counter-weights that connect the buttons to the level geometry they affect? Can the player see these moving parts?
  • What purpose did these buttons and moving geometry have within the original space? Or did someone graft these features onto the ruins later on? Either way, why are they there?
  • Are these moving components used often? Or is this the first time anyone has used the space in years? Decades? Centuries?
  • Why were there monsters waiting in closets? How did they get there? Have they been there a long time? How did they survive without food and water?
  • (Etc.)

Thankfully, when mapping for Quake 1, I don’t care! (Or at least, I don’t care too much.) Quake’s chunky graphics mean that realism is off limits. I have to embrace some degree of abstraction.

Up to a point, Quake 1’s players also don’t care. Players want the level to convey a fantasy, which requires a consistent theme and governing logic. This is very flexible! If the level is a ruined temple, floating platforms are probably bad. But if the level is a floating castle in the sky, then floating platforms are probably better than grounded ones. My rule-of-thumb: if I would believe the space in a dream, then it’s good enough for Quake. (And if the space is the kind of dreamscape that would stick with me once I woke, then it’s great for Quake!)

But outside this specific example of making an encounter room for a Quake 1 map, these “architectural realism” questions often matter a lot! For western AAA games in 2020, players want spaces they can recognize from the real world, things like hospitals, cities, parking garages, offices, airports, suburbs… Even in sci-fi games, players don’t want generic sci-fi corridors; they want sci-fi hospitals, sci-fi cities, sci-fi parking garages… (This is a big generalization, of course. Some games within the Western AAA space care about “architectural realism” more than others.)

If I take my room encounter’s design from earlier and I apply the constraints of architectural realism, this is a hellish challenge. Likely, I need to change my design and loosen the constraints for art. This means stepping back from the specifics and considering my big goals with the encounter—the series of feelings I want the player to experience—rather than the implementation details such as the arrangement of buttons and platforms. From these big goals, it is easier to find a solution for these conflicts.

In practice, most levels don’t solve all of their constraints. Production imposes its own set of constraints: time, budget, team size, and scope. As a level designer / constraint manager, I need to find working solutions. I need to build foundations that solve the most important conflicts and leave room to iterate on the details and smaller conflicts from there as the team has time. Making games is messy.

In the end, the “design” in level design isn’t some magic or some lofty science exclusive to those of us with the job title. Level design as constraint management means building, testing, communicating, and iterating. This is the reality for anyone tasked with implementation, building tangible solutions to abstract goals and needs. Level design is craftwork, and that means building.

Thanks for reading,

-Andrew

What Do We Even Mean by ‘Level Design’?

I think of Design as Constraint Management. With Level Design, there is a common set of constraints each time I build a new level. Even when I’m designing for older games with a clear set of rules and expectations, there is a lot to consider.

To keep this example simple, let’s say I need to design one encounter room for a classic FPS like Doom or Quake.

Untitled document(1)

Even with a basic encounter, there are probably enemies to create combat, and there may be moving pieces, like a door opened by a switch so that players can’t skip around the enemies and escape. This gives us our Encounter Requirements, as well as demands for Combat Spacing and Functional AI! I also have to consider the Readable Layout constraint, so players can see and react to the encounter and enemies.

Untitled document(2)

Some of these constraints, like Functional AI and Readable Layout, support each other. With the example of classic FPS games, the AI use line-of-sight checks instead of path-nodes or nav meshes. This means some layout patterns can “break” the AI and trick them into getting stuck. But this also means that building clear and simple gameplay spaces for our AI to walk around also supports a Readable Layout (clear sightlines, distinct hierarchy of spaces).

In the same way, good Combat Spacing (sizes of enemies on screen, travel times of player and projectiles, distances for audio cues, room for monster closets or teleport spawns) tends to support Functional AI. Together, these constraints inform what distances in a layout feel good, and what distances to avoid because they feel bad (because AI or combat systems badly support them).

Untitled document(3)

Some of these constraints conflict. For classic FPS gameplay, the combat systems are often about pushing the player into close range against the enemies. The layouts encourage this by breaking sightlines on longer positions. Good Combat Spacing for classic FPS games also means preventing players from sitting back and chipping away at enemy health with a shotgun.

But these same layout features that help combat spacing can also hurt the layout’s readability and visual composition. A bunch of sightline-blocking pillars may be great for gameplay, but terrible for art.

Where constraints conflict, there aren’t reliable solutions for me to reuse. In one encounter room, the correct balance between these constraints may be different from the balance in the next encounter room.

The way I determine this balance for a space is by identifying the needs. What takes priority here? This means looking at the larger context, where the encounter sits in the pacing- and teaching-arcs of the level and episode:

  • Pacing-Arcs: Was there a tense combat encounter just moments before? Maybe this one can chill, focus on the art, let players use easier tactics and “cheese” enemies.
  • Teaching-Arcs: Is the encounter teaching a critical new mechanic? Maybe Thematic Consistency can step back, give the player the more abstract teaching environment that gameplay needs.

Untitled document(4)

Most of the constraints fit within a few categories: game design and game system constraints;  tech and tool constraints; and art constraints. These categories tend to be internally consistent; all of their constraints resolve. Conflicts instead tend to be between these categories.  What’s good for game design may be bad for art. What’s good for tech may be bad for game design. What’s good for art may be bad for tech and game design. And so on. There are conflicts that need resolution!

Where is Level Design in all of this?

Untitled document(5)

We’re here, at the junction of all these constraints. Our job is to resolve them. Once we have a have a workable solution, we’re on to the next problem, iterating across a whole level.

In classic FPS level design, this isn’t too bad! When it’s just me working on a level, I get to decide my priorities! Maybe I’ll ignore some of those art constraints in favor of gameplay. Or maybe I’ll ignore some of those game design constraints in favor of art? No hurt feelings if I’m the only one making the call.

However, in team environments, there may be a Game Designer who owns those systems and goals that determine these constraints. There may also be an Environment Artist who has their own interests and goals, which mean more constraints. Same with Tech Designers, Scripters, and Programmers. On large projects, each of these categories may be departments instead of individual people, and there may even be Directors for each of these categories, with varied visions and hopes for the project, expanding our network of constraints further.

Level design sits in the middle. The levels that we build are our way of negotiating between the teams and their constraints. Our levels are the field through which we iterate as a team to find the best balance possible.

So, what do we even mean by ‘Level Design’?

Sometimes Level Design means working with art, even building art ourselves. Sometimes it means working with game systems, even designing them ourselves. Other time it meas working with tools and tech and scripting. Usually it’s some mix of all three, and it varies project to project.

Building a level is the easy part. Iterating on that level and communicating with the team to satisfy all the constraints and needs—that’s what I mean by Level Design.

Thanks for reading,
-Andrew

Notes:

  1.  I stole the constraint diagram structures from Christopher Alexander’s “Notes on the Synthesis of Forms” where he proposed a mathematical approach to solving design problems. The math part is bunk, and Alexander himself came to reject it, but the diagrams are still a nice shorthand. For more on that history, check out “On Design Thinking” by Maggie Gram.
  2. For another example of Design as Constraint Management, check out Liz England’s “The Door Problem”

The Door Problem of Combat Design

Let’s say I’m making a level for a classic first person shooter. To start, I build an arena and add some monsters. I don’t want the player to be attacked as soon as they start the game, so I add a hallway to one side of the arena and start the player there.

doorProblem_arena.png

Here the “E”s mark enemy monsters in the arena and the “P” is the player start in the hall.

My level is simple, but I’m happy with what I’ve built, so I invite a friend to playtest. My friend walks along the hallway, enters the arena, and alerts the monsters, all according to plan. Then things go wrong. Instead of fighting in the arena, my friend steps back into the hall and fights from the doorway as the enemies funnel in. Instead of a dynamic gun ballet of dodged projectiles and swirling destruction, my friend has turned my level into a shooting gallery: dull, safe, and slow. Continue reading “The Door Problem of Combat Design”

Announcement: Quake Sewer Map Jam!

Everyone hates sewer levels.

Too often they are cramped, repetitive, and disorienting. They limit the range of gameplay systems and require one right way to play. They are the antithesis of playgrounds and sandboxes. At their worst, a sewer level drags with no end in sight and stretches a game thin.

Yet, there is an appeal to sewer levels that is so hard to achieve:

  • A good sewer level is a moment to breathe. In its tunnels, there is quiet and refuge which invites introspection.
  • A good sewer level is raw design. This isn’t the place for the one-off scripted sequence or the expensive art setpiece. Instead, a good sewer level is subtle in its mastery of the craft: geometry, lighting, and textures working in unison.
  • A good sewer level is also environmental storytelling at the scale of systems. As we navigate the space, we glimpse something larger than us. We see the flows in, the flows out, and the processes they undergo. There is history and logic at play in the sewers.
  • And sewer levels, both good and bad, are a space for dreams. Unlike the tombs and dungeons of tabletop RPGs, sewers exist alongside our daily urban life but unseen, like the city’s subconscious. They are an id to the ego of the streets. They are also a home for nightmares.
20190721184901_1

Wolfenstein: The New Order, Chapter 7

How do we solve these conflicts of design? How do we take a sewer level—which everyone hates—and make it good? This is the goal of the Quake Sewer Map Jam. This design problem is the theme.

If you are up for this challenge, here’s what you need to know:

When does the event start? When is the deadline?

The jam begins July 28th and ends August 31st at 1 PM Eastern Standard Time.

My hope with the longer deadline is that more people can participate as they have time. I don’t expect anyone to use the whole month+ on a sewer map. Please pace yourself and reduce scope if you run short on time!

Also, if your map only took you a few hours, you are still welcome to submit it! There is no barrier for quality so long as your map is playable start to finish.

Are new mappers welcome?

Yes! Newcomers are encouraged to participate! Sewers have a lot in common with traditional tabletop dungeon design, so this should be a great opportunity to pick up the tools.

If you aren’t sure where to get started, most of the talk about Sewer Jam is taking place in the Quake Mapping Discord, so stop by and we’ll be happy to get you started. Or, if this is your first time mapping for Quake, here is a Quickstart Tutorial.

Are there any special modifications?

We will be using a new version of the underwater jam’s mod.  This allows for dynamic water! You can read more about these features Here. I will update these links once the new version is available.

If you want to stick to vanilla id1 features, that works too! The progs add features, which you can ignore, but they don’t alter any of the standard features.

Are there any special textures?

We’ve gathered some textures from id1, Daikatana, and a few community packages into the sewerjam_wad.zip. I hope these textures provide a starting point for some ideas, but you are welcome to use different textures.

What is the naming convention?

Please name your map “swjam_[username]”. For example, my map would be “swjam_yoder”. If you build the map collaboratively, please include both names.

Where do I send my map?

Once you have completed your map, you can send it to me at AndrewYoder@live.com or on the Quake Mapping Discord. If I don’t reply within a day, feel free to nudge me again.

Please also include a readme file, and consider including the “.map” file so other people can open your level in the editor and learn from your design.

How strict is the theme?

Your map should draw on the ideas of sewer levels, but there is flexibility. You can make a canal, a cistern, or water treatment plant. It may also help to think of a secondary theme. What does a blood sewer look like? Or a sewer in space? What kind of sewer would you find under a dark mage’s tower? All of these ideas are welcome!

Anything else I need to know?

Your level exit should go to the “start” map.


20190721152204_1

Dishonored, Dunwall Sewers

Despite a mess of design problems, sewer levels are rich with theme. They are also a place to practice the subtleties of our craft. Over the next few weeks, I will be writing about some of my favorite sewer levels, like the two pictured above, and why they work.  I may also write about the sewer levels that failed and why.

I know sewers make for a bizarre theme for an event, but I hope you all will join me in showing what a good level a sewer can be!

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!

toybox1toybox2toybox3toybox4

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.

quake1palette

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!
-Andrew

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.

systemshock2.jpg

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?

NearDeath.gif

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.

WelcomingAbstract.PNG

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.

ValenceVariants.PNG

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.

AubreySerr_ValenceTheory2.PNG

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.

DoomGuy.PNG

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.

HorrorGame.PNG

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.

GoneHome_Welcome.gif

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.

LonLonRanch.PNG

“Lon Lon Ranch” from Ocarina of Time as depicted on noclip.website

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-ombBattlefield.PNG

“Bob-omb Battlefield” as depicted on noclip.website

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.

Behind_Chain_Chomp's_Gate.png

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-ombBattlefield3.PNG

“Bob-omb Battlefield” as depicted on noclip.website, 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.

MettePodenphantAndersen_Sapienza.png

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 :)

-Andrew