The Big Picture 97

Still, this checklist can only give you an approximation. However, it can still give you a foundation to
apply the advantages of a table, even if it is just for planning and team communication.

8.1.4.3 Progression Sheet for Open Games

The word “sheet” is not descriptive enough, but in this context I mean the map of your game world (or
just a sub-section) with the boxes, which include a brief mission description and pointing at their start
locations. It gives you less pattern-recognition possibilities and likely you run out of space quickly, lead-
ing to a lighter amount of information per mission-box. However, it contextualizes the missions within
the game world, which can help to spot other issues and it is a great tool to visually communicate a mis-
sion overview to the team.
­

­
The information you put in the mission’s box surrounding the map is crucial. For readability and pat-
tern comparison I recommend to use the same formatting, content, and layout for each box. Essentially I
found two box-types to be working well.
The first variant is similar to the table, where icons and short descriptions sum up the high-level infor-
mation of a mission. However, first of all you might end up with less information than the table if space
is sparse or the boxes become unreasonably large. Secondly, focusing on iconography and very short text
(ideally just a few words) becomes even more important to keep a clean and compressed look. Thirdly,
the icons and text itself should be so self-explanatory.
The second variant for such a mission-box is more mission design or narrative oriented. Essentially
it would list the major story or gameplay blocks of the specific mission and how they are connected. I
recommend you still try your best to categorize/colorize those blocks in for example broader gameplay
types (for example, vehicle, stealth, open, exotic), cinematic or in-game events. The best foundations for
such blocks are focusing only on the major objectives or most impactful narrative beats like cinematics,
reveals, or important NPC interactions. For example: Drone flight introduction (cinematic) → Infiltrate
Mansion (gameplay)
­ → Locate Drug Lord (gameplay) → Interrogate Drug Lord (exotic) → Exfiltrate
w/ unconscious Drug Lord (gameplay) → Defend Exfiltration Location (gameplay) → Van Exfiltration
(cinematic).
­
Of course, the first variant makes it a lot easier to still detect and work with patterns. More difficult
than in an easy-to-compare table, but still possible. Using the second variant it is way more difficult to

Hostage Rescue
Village / Harbor Ocean Race
Tenseness
Intro Cinematic

Surround Snake Island

Race back to Yacht

Yacht Explodes

Chase Attackers

Destroy Fort

Outro Cinematic

­FIGURE 8.3 Showcase of two types of boxes around a map filling out an open world “progression” sheet.
98 A Practical Guide to Level Design

find patterns, even if you apply some graphical categorized iconography. It certainly has its advantages
conveying a lot more actual gameplay and narrative of the individual mission. In contrast to the first
variant which keeps things more abstract. However, if you chose the second model, then I would still
recommend additionally creating a progression table at the side. Even if the missions are only in a loosely
defined order, it still allows you to analyze patterns. If you have too much pace you can of course also
combine the two methods.

8.2 About Tutorial Levels

8.2.1 Introduction
In the context of any game’s progression, the very first level holds a very unique, exciting, yet challeng-
ing place. It has so many roles to play, like teaching the player the game’s basic controls and abilities,
hooking the player into the entire game/world, establishing a core narrative, astonishing people with
technical/artistic possibilities, and so much more. Therefore, despite the limited space of the first level,
almost every department has a high stake in the first level. However, it gets even more complicated
that a lot of the presented aspects can keep changing wildly during a development cycle. The narrative
changes can have a significant impact on the level. New core mechanics get cut or added and need to find
a new home in the already tight level or tech-specs change requiring complete reworks. It is not unusual
that more of those challenges appear simultaneously and multiple times throughout a production cycle.
However, everyone has high expectations at the first level, from developers to players, since so much
depends on its success.
I will only cover basic tutorial considerations in this book. More complex or very different forms of
tutorials are very game dependent and can easily go beyond the scope of this book.

8.2.2 Gameplay, Art, and Narrative Considerations

8.2.2.1 Introduction
This chapter covers some of the basic ways to introduce game design, art, and narrative ingredients in
the first level. Keep in mind that tutorial levels are so complex and highly game-specific that I can only
share general aspects.

8.2.2.2 Gameplay Teaching: Basics

Players typically first learn basic navigation in classic tutorials, such as look/rotate, movement, jump, climb,
or crouch. Following or still, part of the navigation portion often comes basic interactions like picking up
items, opening doors, pressing buttons, or talking to an NPC. Since none of these are the most thrilling
first impressions of any action game, players soon get to shoot something very harmless like a cardboard
cutout or a super easy enemy. Depending on the game, it typically includes more aspects like grenade/knife
throwing, aiming/sniping, introduction into some exotic moves, or special abilities. Ideally, it also includes
anything else which sets the game apart from its competition and makes the players hungry for more.
Essentially, the player learns the 3Cs, meaning character, controls, and how the camera functions.
The classic (rational design) way to teach players a feature is by the following three to four steps. It
depends on the game if that has to happen for every feature. For example, some games skip basic move-
ment tutorials by now. Another variant here is to teach players multiple things at the same time, like
attacking and dodging in one training fight.

1. Safe Introduction: Players can use the feature in a 100% safe environment to get a feel for it.
For example, they are shooting some cans or cardboard cutouts.
The Big Picture 99

3. Difficult Challenge: Players have to use the feature in a challenge with difficulty closer to the
upcoming sections, but typically the challenge stays very “clean” with no other features poten-
tially confusing the player. For example, shoot three (same as before) enemies who can shoot
back. Some games skip this step for some/all features.
4. Combination: Players have to use their recently learned feature in combination with another
feature they learned before, or the challenge is a combination of multiple features. For example,
shoot three enemies while jumping between poles or shoot three enemies, but some can throw
grenades (players have to dodge). Some games skip this step for some/all features.

Depending on your game’s audience it might be interesting to hide as much of the tutorial nature as pos-
sible, either by, for example, detecting how experienced the players are and then skipping basic steps or
by smoothly integrating into the game’s initial narrative. The whole topic can be controversial because
for some players tutorials are very boring. For some very necessary, and skipping tutorials always gives
the feeling that you might have missed something important. However, I do believe we can be a bit more
experimental with tutorialization of games and don’t have to rely too much on old-school methods for
everything.

8.2.2.3 Art and Narrative Introduction

When we talk about art and narrative, the first level is less a tutorial than an introduction. Narratively
it should give the player a combination of what to expect, introduction to the world, plus ideally makes
them hungry for more. Art-wise, it should showcase something awe-inspiring, highlight the game’s pro-
duction value, and introduce the world through artistic means while looking stunning.
There are two classical ways to introduce art or narrative in the first level. The first variation is to start
slow and build up tensions and then have a big reveal, while the second one is to start right away or very
quickly with a big bang and then calm down at the end of the level. Of course, you can combine them in
any order or at the same time.
If the story takes a backseat initially, then at least at the end of the first level or mission, players should
have an idea of what the game’s narrative is (at least what you as a developer want them to believe). It
is comparable to a very slow prologue, which has more world-establishing elements, or in the case of a
game, it can also have a very strong initial gameplay focus. It can create great narrative tension because,
of course, players are eager to know what is going on. A classic example is waking up with amnesia,
wandering around in an empty, devastated hospital/ bunker/spaceship. Then it takes the first 15 minutes
to realize that a zombie apocalypse happened, and now the actual game starts. This last narrative reveals
also acts as a cliffhanger, motivating them to hopefully keep playing.
On the flip side, if the narrative starts with a big reveal right at the start of the game, then it typically
calms down afterward, leaving some space for gameplay and art introductions. However, at the end of
the first level, you need to have a narrative cliffhanger again. It does not have to be as big as the initial
reveal but still strong enough to make the player hungry for more. A classic example is a longer initial
intense cutscene or in-game event that introduces the current situation. Then finally, the later cliffhanger
reveals what is going on or what players are actually about to do about the initial, high-tension narra-
tive introduction. For example, it starts with a barrage of TV announcements, a presidential speech, and
military briefings about an apocalyptic zombie outbreak. At the end of the level, players learn that their
job, as part of an elite undercover unit, is to investigate the plague’s origin and find the guy who caused
it all. Of course, while hinting at some conspiracies or twists.
On the art side, a calm start allows for an even more impressive artistic reveal a bit later in the first
level or mission. A classic example is the stunning vista players see when opening a door after walking
through dark tunnels, bunkers, sewers, or any other tame interiors for the first few minutes. Of course,
the vista is perfectly framed, composed, your prime example of visual player leading and long-distance
environmental storytelling. Depending on the game, you have the obligatory plane/ helicopter crashes,
big dinos stomping through the mid/ background, massive explosions, or an alien fleet mowing down
New York. However, the often underestimated part is the “boring” part before. Ideally, it is the absolute
opposite of the vista, with only a few small teasers about what to expect, like notes to read, light coming
100 A Practical Guide to Level Design

through cracks, graffiti on the walls, screen rumbles, and any other subtle audio clues. The more you
can surprise the player when opening an ordinary door, the better. However, the surprise and impact of
the vista is stronger, the more the previous section is “boring.” Of course, it can be anything other than
a door that triggers the reveal like an exploding/crashing wall, a glass surface suddenly turns transpar-
ent, a falling curtain, surprise teleportation, or whatever else sci-fi and fantasy games have to offer. You
should absolutely fight the urge to take away the player’s control when they open the door and turn it into
a mini in-game cutscene. Yes, some players might not look in the ideal direction the art director wants.
However, if you take away control of players in such a crucial moment, they know that they also likely
do not have agency about the most stunning-looking parts for the rest of the game. These breathtaking
moments are wins/rewards for players; never take it away from them.
Last version is the big, initial, impressive art reveal, which leaves players breathless and ideally forget
that the gameplay part started at some point. It sets the tone and expectations for the rest of the game, and
it better sets it high. Of course, you cannot keep up such a high fidelity for the rest of the game/ level, but
the interesting aspect is that you do not have to. If you set a high standard early on, players likely apply
the same standard for the rest of the game, even if it dropped. The same can be observed not just about
visual quality but also gameplay and overall production effort. A classic example, besides the action-
packed James Bond intros, is the classic plane crash. On the way down, the plane crashes along a few
skyscrapers/mountains, it breaks into parts, a few passengers get sucked out, the player almost flies out,
too but hangs in, and then the plane slides brutally over the ground. All of it happened in-game, and now
the player stands up and can move around in a devastated, burning hidden Tibetan temple landscape.
I will write more about combining them in conjunction with gameplay in the next when I cover the
tutorial’s level design implications.

8.2.3 Level Design Considerations

8.2.3.1 Linearity
A classic tutorial level is linear. You, as a designer, want to make sure that players experience everything
step by step, carefully orchestrated based on your teaching strategy. The artistic and narrative introduc-
tion to the world has to go hand in hand with the gameplay tutorial, but also it must leave players hungry
to keep playing. Finding this balance in a linear level is already difficult and likely to end up with many
iterations. However, applying an open structure to the tutorial is not beneficial for both developers and
players.
The players do not benefit from potential confusion of too much early freedom or unknowingly miss-
ing out on important information for the rest of the game. The irony is that many players say they want
freedom, but too much and too early is not helping anyone. Till players are familiar with the very basics,
a bit of handholding early on can be okay. Opening up the order in, for example, an open-world context
is doable but it comes with a cost which is often not reasonable. You could also think about splitting up
the tutorials. Start with a shorter linear tutorial segment, but then give players more and more freedom
till they are done with learning.
I believe giving players more space in tutorials is perfectly fine, especially if large open environments
are part of your game’s DNA. After all, a linear level does not mean a tight tunnel. The linearity is more
about the required linear steps to complete the tutorial sections. A linear structure is necessary, espe-
cially if art, narrative, and gameplay aspects build upon each other or are tightly connected. For example,
it requires a narrative event for the player to unlock a unique ability.

8.2.3.2 Combining Art, Narrative, and Gameplay

I have alluded to it previously, but one of the key aspects of tutorial levels and the important responsibil-
ity of level design is the right balance and pacing of art, narrative, and gameplay.
Introducing new, essential gameplay in narrative-heavy parts is typically bad because you want play-
ers to focus on the narrative and vice versa. A good example is that barely anyone remembers a radio
dialog in the middle of a heated firefight. However, narrative and gameplay can go after each other in
The Big Picture 101

Intensity

Level Progression/Time
In-game First gameplay tutorial in an interior with Big reveal & Outside new unique
cinematic occasional small narrative hints vista, gameplay feature is
leaving the introduced and first
interior fight

­FIGURE 8.4 Tutorial level narrative, gameplay, and art pacing graph—Example A: Narrative (Blue): ­ Strong narra-
tive start, few more hints along, and narrative cliffhanger at the end. Art (Red):
­ Strong start with narrative, lower till big
reveal/vista.
­ Gameplay (Green):
­ High during narrative lows, low during art reveal or narrative moments, unique feature
introduction at the end.

Intensity

Level Progression/Time
Stunning start, Mix of first narrative clues and new Big, unique new gameplay Final
right away gameplay reveal
gameplay, player &
has amnesia twist

­FIGURE 8.5 Tutorial level narrative, gameplay, and art pacing graph—Example B: Narrative (Blue): ­ Low narrative
start due to amnesia, just a few hints with final reveal and twist at the end. Art (Red):
­ Strong start with gameplay, stays
medium, goes back up again with big, new gameplay and even higher during narrative reveal. Gameplay (Green): ­ Right
away gameplay but safe and easy tutorials, first easy fight in between narrative hints, final big spike during big, new feature
introduction, before dropping low during narrative reveal and cliffhanger.

tight intervals, with some mild overlaps. They just should not peek at a similar time to give players time
to soak it all in.
Art, on the flip side, can go well with both at the same time. However, I would still reserve art its own
unique peeks, vistas, and reveals. At least wait a bit after a stunning moment before you bombard players
again with gameplay tutorial messages or important dialogs. Still, majestic artistic events which are part
of world-building are perfect ways to combine those two crafts—the same counts for impressive artistic
consequences or introductions to gameplay moments.
102 A Practical Guide to Level Design

8.2.3.3 Tutorial Level: Production Issues and Solutions

The creation of a tutorial level or larger tutorial section is everything but easy. The first level has many
stakeholders, for example, art, narrative, game design, and course level design. Every time one of the
departments has a bigger change, it has to get reflected in the level, and expect many changes throughout
the development cycle, often till the very end. This issue is normal in any creative, iterative process, but it
is way denser packed in the first level. Additionally, the density means that well-harmonized connectivity
between those aspects is way more complex than in any other level. In reality, it is not unusual if a tutorial
level or section sits in the hot seat for most of the production. Such levels are commonly reworked three
to four times. It puts much stress on the entire team working on the first level, especially level design. I
have met a few level designers in my career who swore to never work on one of those levels ever again.
Therefore the first, most important solution is to assign this level to calm, battle-hardened level design-
ers. The type of level designers who can stay cool if changes come, a part gets cut, then a bit later gets
added again, or the entire level gets completely reworked. Typically, that means a senior or maybe inter-
mediate with the right personality and soft skills. Working on the first level as a level designer is equally
challenging as it is rewarding. You are working on the first level, which pretty much every player will
experience. However, you need a very thick skin, need to be very flexible with your design, and ideally,
your diplomatic skills are way better than average.
One way to keep the stress down for level designers is to avoid any crazy, risky, or experimental
design. I am not saying it is impossible, but depending on the type of game, production, and team, I
cannot recommend reinventing level design in the first level. I am always an advocate of pushing the
boundaries, and of course, if your game defines new ground in the industry, then so will be the first level.
However, you will likely be busy enough while going through so many iterations and dealing with so
many stakeholders. At the same time, it will be even more challenging to develop a mind-blowing level
design concept that remains flexible enough to see the end of production. If everything else works out
fantastic, having a great and solid level design is perfectly fine for the first level.
The next crucial piece of advice I can give about tutorial levels is to keep their layout, space, and script
as modular, flexible, and dynamic as possible. It is not unusual for parts to get cut or added because, for
example, the narrative or features changed, added, or got removed. If you keep modularity in mind, it is
easy to extend a path/space to the side, above or below, to give you some more room for a new feature
without affecting the rest of the level. With modularity I do not mean a large grid-based level design, but
the mindset to easily add or remove small or large parts of the levels. It is all about resilient and flexible
design thinking, which is crucial for such highly iterative spaces. This consideration is especially crucial
for engines that do not allow quick and easy movement of large parts, especially if terrain, vegetation, or
complex architecture is involved. Removing a section is, of course, a bit simpler, and often art or narra-
tive is happy to gain some extra bit of space for their craft.
Lastly, I can only suggest working on the tutorial level the last, or at least wait to fleshing it out till the
last reasonable moment. I know it sounds strange to wait so long with the first level, but a common mis-
take is to start with the first level right from the beginning of production. Instead, I recommend waiting
some time until the game, design, narrative, tech, and art have settled a bit. If you do not wait then, you
might add a few unnecessary iteration loops, which could be better spent on later levels. Working on the
first level has much potential for waste, so reducing it and the associated frustration is critical. However,
it certainly makes sense to have a rough, very modular version early. The goal would be to get a feeling
for creating a tutorial section or sketching out key art/narrative moments. You also might need the first
level to test the overall gameplay or a tutorial level for early playtests. Just do not refine it too far, and
especially do not polish it too soon.
9
­High-Level
​­ Layouts

In this chapter, I want to start stepping away from pure theory and explain how to apply the previous
mindset from abstract level design and the concept of “points of advantage” (POA) onto something more
practical-minded. Therefore, at first, I want to start with high-level layouts. However, arguably anything
high-level, even in a practical context, will always remain partially theoretical. Still, creating an actual
high-level layout remains at the core of level design and sets the foundation for anything even more
practical building upon it.
­

9.1 Circle to Complex Arena

9.1.1 Introduction
I believe that at the heart of any good flowing layout is a circle, or rather a combination of circles.
However, let us first get a basic understanding of the circle itself before we get complex.
Level layouts should maintain a good flow, including not only movement but also options to act or
react. If players run out of visible options, it only leads to frustration, and then they blame us developers
and not themselves. Therefore, the circle is the most basic building block for well-flowing layouts.

9.1.2 The Circle
First of all, a circle, by definition, is a loop, which means players have an unlimited number of
options theoretically. They either run away forever (given they are equal or faster than the threat) or
move to the threat and eliminate it. A circle can be anything from a path, like a hallway, walkway,
or connection of floating rocks on a lava sea. However, it can also be a large enough space, where a
continuous loop defines the outer borders. The space just needs to be big enough for reasonably run-
ning in circles.
For example, imagine a big, static alien in the middle of a large circular room shooting at the player.
The space starts to be reasonably big enough when players can run along its borders and can still dodge
the alien’s attacks. If the space is too small, and they cannot dodge the attacks then it is not really a loop.
Of course, many factors play a role here, like the enemy’s attack/projectile speed and player movement,
and other abilities. Still, let us keep it simple and more general. Another interpretation of a circle in high-
level layouts is negative space, aka running around a circular object.
Secondly, when I say loop, I do not mean a perfect circle strictly. It can be anything that defines a loop.
So, for example, it can be rectangular, octagon, or a wired mix of concave or convex corners as long as
they form a loop at the end. As long as players have at least one continuous path, you are good. However,
for the sake of simplicity and consistency, I keep referring to it as the circle or loop.
Combining those two important points can already give us a large number of possibilities, and you
likely recognize their use in many levels you played. Sure, the scale will vary wildly, but it is everywhere.
Also, just running in a circle all the time is not very exciting either. After all, we need to give the players
meaningful options. Therefore, let us get a bit more complicated.

DOI: 10.1201/9781003275664-12 103

104 A Practical Guide to Level Design

(a) (b) (c)

­FIGURE 9.1 (a) Circle as positive space. (b) Circle as negative space. (c) Circle as tubular space (a variation of positive
and negative space).

(a) (b) (c)

­FIGURE 9.2 (a) A circular loop. (b) A wobbly loop. (c) A triangular loop.

(a) (b) (c)

­FIGURE 9.3 (a) A spiky loop. (b) A long loop. (c) An overlapping loop.

9.1.3 More Circles
9.1.3.1 Introduction
When I teach designer layout, I always start with one circle on the whiteboard, but then keep expanding
it quickly. It becomes clearer as soon as I add a few more circles, some overlap while others just touch
at one point. Then we apply both points from the previous subchapters about adjusting the shape and
changing the meaning of the loops between positive, negative or tubular space. However, the hard rule,
to always think in loops, must remain.
High-Level Layouts 105

(a) (b) (c)

­FIGURE 9.4 (a) Base high-level layout. (b) A simple variation translated into primarily positive (tubular) space. (c)
Another variation with a mix of negative and positive space.

(a) (b) (c)

­FIGURE 9.5 (a) Base high-level layout. (b) A variation translated into space. (c) Another variation translated into a more
realistic space.

(a) (b) (c)

­FIGURE 9.6 (a) One loop. (b) Three loops. (c) Six loops.

Another interesting observation is that each circle you add, it creates even more loops. Two touching
circles create three loops (the two original loops and then both combined). If only two circles overlap,
you create six loops (the two original loops, the inner one, the outer one, and the two loops minus the
overlap). Enjoy adding more circles and count the loops, and very quickly it gets complicated because the
number of overall loops increases rapidly.

9.1.3.2 Circle Size, Weight, and Density

When you start playing around with different sizes of added circles, you notice that they change weight.
A large circle needs to have a justifiable POA or its value/weight for the player drops. Why run all the
long way if it does not reward me for the time spent? If it is just another yet longer tunnel that allows
players to run away from the charging threat, its priority drops toward a side path while the smaller loop
stays the main, preferred loop. However, suppose the long loop includes an important powerup, weapon,
or other significant option to defeat the threat. In that case, it becomes the priority, and players do not
mind the long run.
Now, let us switch to the more likely reality that you deal with multiple threats or threats that can do more
than run after players. I have already covered the principal thinking of options in the chapter “Abstract:
106 A Practical Guide to Level Design

(a) (b) (c)

­FIGURE 9.7 (a) Base high-level layout. (b) A variation with different path weights and density distribution. (c) Another
variation with different path weights and density distribution.

Mid-Level.” It is safe to say the more threats there are, the more options you want as a player and developer.
Again players need options to make meaningful choices, while developers try to prevent their enemies from
appearing like lemmings coming down only one lane. Therefore, areas where many (overlapping) circles
create a high density of options typically indicate a battlefield of some sort. It does not have to be about
fighting but can include things like stealth or complex navigation puzzles. In larger layouts, denser areas
can create hubs. Often they are central, but hubs in the outer rims of your layout can create an interesting
tension and relationship between them, while a central one leads to a more consistent contestation.
Lastly, within your network of several loops, it might soon get messy. Therefore, think about giving
some loops more weight and purpose. Some loops become the main streets or the upper main walkways,
while others become service tunnels, air ducts, or side alleys. Not every loop should be equal. This clear
separation, weighting, and clear identity of loops are essential for player orientation, player recognition,
and environment art.

9.1.3.3 Bottlenecks
The next significant consideration is the different loop connection types. The two main types are bottle-
necks and anything else. The bottleneck is an isolated connection between two separate, significantly
large networks.
Controlling or just alone crossing bottlenecks is key in many layouts. They hold significant tacti-
cal importance, and therefore you should design them very cautiously. Bottlenecks can slow down the
player’s movement or even deny complete progress. Putting them at the wrong spot can completely slow
down or eliminate flow. However, at the right spots, they create interesting peek challenges. In a multi-
player context: Suppose alternative routes around the bottleneck exist, then a good spot for bottlenecks
is in the center of a map like in a capture-the-flag (CTF) map. However, if little or no alternative routes
exist, bottlenecks could act as a disadvantage for any spawn-camping team. In a singleplayer context,
bottlenecks controlled by AI act as difficult peeks. I suggest treating them as “action puzzles” where
the obvious approach can be very difficult. However, smart players should find alternative solutions to
overcome it.
Another variant of bottlenecks is the connection or crossroad between two long lanes. The length cre-
ates essentially something like two “soft” dead-ends ahead and behind the player. Ahead is the potentially
contested or dangerous crossroad, and behind is another long path. This case is not as severe as the previous
one but should still handle it with care, especially in central or primary locations within the layout.
Despite the difficulty of dealing correctly with bottlenecks, I like to include them in most of my high
to mid-level layouts. They are an essential tool to give a layout rhythm, provide clear, recognizable
compartmentalization for players and developers, and a great way to affect the game’s pacing. If all
connections are weighted similarly, quickly navigating the layout becomes a dull, almost meaningless
experience.
High-Level Layouts 107

(a) (b) (c)

­FIGURE 9.8 (a) Simple bottleneck (yellow). (b) Central bottleneck due to long path. (c) Bottlenecks between sandbox
bubbles.

9.1.4 ­ Dead-Ends
​­
I keep mentioning that dead-ends are generally bad. Therefore, let’s dive a bit deeper into the topic and
unravel some of its myths by initially looking where they are applicable before thinking about solutions.

• If a player reaches a dead-end and there is no threat, then there is, of course, no problem. Dead-
ends as part of exploration, navigation, or any other puzzle are perfectly fine.
• Dead-ends can work in a pinch if combat is static and does not rely too much on movement. For
example, they can work in some melee-centric fighting games.
• Suppose the dead-end provides the players with the solution or safety from a threat. For exam-
ple, you are jumping up on a tall rock when chased by wolves.
• Dead-ends might be less of an issue if its path is so wide or gives enough micro-options along
its path that it does not create a trapped feeling.
• If the risk-vs-reward is correct, for example, reaching the rocket launcher at the end of a longer
dead-end might be worth it, even if enemies can abuse my limited escape options.

This list also defines where dead-ends are bad: In combat situations where freedom of movement is
important, or risk vs. reward is highly disadvantageous.
However, when you look closer, the dead-end path is not at the core of the issue—the end spot is the
problem. When you are stuck at the end without options is the main frustrating part. Therefore, a solid
way to reduce this issue is by providing space at the end by applying the concepts of circles.

(a) (b) (c)

­FIGURE 9.9 (a) Bad use of dead-ends. (b) How to fix dead-ends purely with layout. (c) A variation of the solution trans-
lated into space.
108 A Practical Guide to Level Design

9.1.5 Closing Words
This deep dive into the circle mindset aims to set the foundation for all future flow and layout topics. The
circle mentality described above addresses most dead-end or any other bad flow options. After all, my
core understanding of flow in games is about continuously providing options for the player. Therefore,
the circle mentality provides the foundation for flow. Then applying the right mix, pacing, and rhythm of
challenges and variety to the flow makes a flow a great one.
Lastly, just because I talked a lot about layout, I have to restate that flow is not only all about continuous
movement but options. Movement is just one of many options. For example, the often-mentioned rocket
launcher at the end of a dead-end might give the player a valuable option to counter the movement limitation
either by force or by a rocket jump. Options come in many forms and shapes—it is just a matter of context.

9.2 Sandbox, Multiplayer, and Boss Arenas

9.2.1 Introduction
I decided to combine sandbox, multiplayer, and boss arenas because at a high-level the core under-
standing is similar. A sandbox in most games is a large enough space which provides players with a
wide range of options with typically at least one open objective. An open objective just states what
players have to do as a result, without providing detailed steps to achieve it, for example, “Kill general
X in the village.” Players now have the whole sandbox arena available to locate, reach, and ultimately
kill this general. A closed objective chain would give the player a detailed order of objectives to locate,
reach and kill him.
Multiplayer maps are not far off from large sandbox arenas solely in the context of high-level layouts.
Of course, context, enemies, and objectives are completely different. However, they also need to provide
enough options for all present players, and their objective is often even more open and less predictable
or defined. This chapter covers more “free” and symmetric types of multiplayer modes like deathmatch,
team deathmatch, domination, or alike. Asymmetric multiplayer modes are more a mix of this chapter
and the next one about linear levels. However, the exact mix heavily depends on the game and the details
of the mode.
Boss battle arenas are again similar but are, of course, highly contextual to the actual boss design.
If the boss works best in a big flat arena and has trouble navigating anything more complex, then this
chapter is the wrong one. However, if the boss can navigate properly or players benefit from using a more
complex space, this chapter should help. Good boss battle design is inherently very difficult, and even a
good layout can only do so much if the boss design has flaws.
Before we move on, the term “arena” must be clear. In the context of this chapter, an arena is a large space,
defined by paths, options, and negative and positive space. An arena is not just one huge room. An arena can
be anything from a village in a sprawling open world to, of course, a walled-off space-gothic cathedral. For
simplicity, I will primarily focus on the paths/lanes. How you translate those lanes into options and positive
and negative space is then up to you when you pull them in the context of your game or level.
If I look at all the arena types I worked on; I can reduce it to three types: The ones defined by a sur-
rounding circle, an inner circle, or a center axis.
Quick clarification about the drawings: First, I am overusing circles to highlight their core loop-principle
in the high-level layouts. However, in many cases, just straight lines are enough to create the intended net-
work once you establish dominating lanes (outer loop, inner loop, and center axis). Secondly, the high-level
layouts are about the main lanes. Any other mid-level lanes are secondary and not part of this chapter, but
you see them in the example drawings. Taking some liberties and “loosely translating” the high-level sketch
into a closer reality is perfectly normal as long as you keep the original layout spirit in mind.

9.2.2 Surrounding Circle Layouts

9.2.2.1 Introduction
As the title suggests this arena type is defined by a surrounding loop, which players can follow uninter-
rupted. Again, it doesn’t have to be a perfect circle, is completely safe or trivial to find/follow—it just has
High-Level Layouts 109

(a) (b) (c)

­FIGURE 9.10 (a) A version just made of circles. (b) The same but now a combination of circles and lines. (c) Still the
same, but now just using lines and took some more liberties.

(a) (b) (c)

­FIGURE 9.11 (a) Surrounding circle; base high-level layout. (b) Inner circle; base high-level layout. (c) Center axis; base
high-level
­ ​­ layout.

to be there in a fair manner. Depending on your game, occasionally climbing, swimming, some risk of
detection, jumping, or running over open ground should all be acceptable.

9.2.2.2  Open
In this context, “open” means there is much space around the actual arena, without a close, walled-up
feeling around. This case can be in an open world, large sandbox, or multiplayer map.
The surrounding circle is close enough around the location that you can see any actors inside, let it be
other players or AI. Essentially, it is close enough to see the location being “alive” or have targets/ NPCs/
players to interact with. Along this path, we have the often bespoken vantage points that give you an
overview of the location and observe what is going on ahead—more about vantage points later on when
we go more detailed.
Now from the vantage points or the surrounding loop, paths lead to the heart of the location. Those
connections are crucial and have to be inviting because that is when players commit to the inner part of
the arena. Otherwise, they stay outside, keep circling and stay at a distance. There is nothing bad about
some sniping action around such a location, but ideally, there are valid/fair counters against such tactics
for any actors inside. However, depending on engine limitations, not every surrounding circle layout
means there are vantage points and open ground all around. Negative space leading to the outer ring and
essential resources, objectives, counter-sniper spots inside are valid solutions to create some tension and
variety between the outer and inner parts.
Once inside, away from the outer ring, you keep going with circles to your liking. You can have more
circles and make it look completely like an onion, or you can get more complex with more intersecting
or connected circles. However, keep in mind that there is a dominating circle around. This loop means
at any moment players or AI can let go of the likely tighter space inside, reset the fight, go out, and re-
enter from anywhere! This layout reset option is huge. It can keep a very interesting and always fresh
balance and tension going for a long time. One example could be that it leads to a wild chain of hits and
110 A Practical Guide to Level Design

(a) (b)

­FIGURE 9.12 (a) Base high-level layout. (b) Open surrounding circle example (took a few liberties).

runs against the overwhelming strong defenders, crumbling with time. Another one could be a barrage
of enemies coming from all around, creating a 360° defense moment, but because of the circle, they can
switch up lanes at the last minute, creating a varied mix of challenges.

9.2.2.3 Enclosed
As soon as an arena is enclosed, it means the players are essentially trapped. The surrounding circles still
allow for a reset, but it does not always feel the same. Instead of being a safety net, it can feel more like
being pushed to a hard border, leaving no way to escape.
Controlling the outer circle still means that you can strike to the center part from any side, and you can
typically navigate here fast. It is a bit like a big street around a building block, just that you cannot move
further away. If players cannot dominate or navigate the majority of the surrounding loop, you might
have an inner circle layout, which I describe further below.
If controlling the surrounding loop has more advantages than being inside, you have a dominating
surrounding loop. This advantage can be a combination of resources here like powerups, ammo, or
weapons, but also tactical like seeing enemies at greater distances, easy/quick/surprise strikes to the
inside, controlling the inside or objectives, or generally any initial unpredictability. The classic besieged
mansion, in both single and multiplayer, comes to mind. Attackers can control/engage a large part of
the mansion from the outside, semi-safe circle it to find weak spots, and strike when the time is right.

(a) (b)

­FIGURE 9.13 (a) Base high-level layout. (b) Enclosed surrounding circle example with only one-way entrances from the
outside to the inside yard (excluding interior, very symmetrical).
High-Level Layouts 111

Any defenders inside have limited space and are, therefore, more predictable than anyone on the larger
outside perimeter.

9.2.3 Inner Circle Layouts

9.2.3.1 Introduction
This layout type has a loop inside the arena, which is advantageous to dominate as a player or actor. One
example could be a semi-obvious route in a deathmatch map that controls all the major pickups with
the perfect respawn time. Another one is that street inside the larger village controlled by a tough tank.
Those lanes are dominating and defining the layout. However, they do not have to have a continuous
look, width, or style. That previous tank route can be two separate asphalt streets, but the tank creates its
own dominating loop, connecting the streets by cutting through some unfortunate gardens or graveyards.
The main difference between an inner and a surrounding loop is the dominating loop and what loops
are secondary. The inner loop has “compartment-loops” toward the outside connected to the inner domi-
nating lane. These outside lanes should hold relevant POAs, but navigating the very outside lane is
disadvantageous compared to the inner one. Such disadvantages could be the ease of navigation (lots
of concave corners), exposure to inner POAs, inherent complexity, or simply its pure boring length. A
dominating surrounding loop means you dominate the inside. However, an inner loop means you can
dominate both the outer compartment loops and the potential additional inside. For example, in a mul-
tiplayer map, players can stay on it, pick up a weapon in one outer segment, and then use it to engage
anyone inside before switching to another outer extension for some armor or another good shooting
position. The inner loop connects all those outer and inner POAs and is therefore so dominant. A clas-
sic singleplayer example is a defense scenario with a bigger central object. Enemies come from multiple
angles all around. Players keep circling the central object, running from shooting position to shooting
position, scrambling to keep health and ammo high, and occasionally making a sortie. However, they
always come back to this inner circle.

9.2.3.2  Open
The open case of an inner circle layout happens if a location in an open world, large sandbox, or other
bigger space has a dominating inside loop. This inner loop can be in combination or relationship with a
surrounding one, but it does not have to be. It could also be that the surrounding circle is not continuous
or very disadvantageous to be on. If you have multiple dominating loops inside each other you have what
I call a “layout onion.”
A dominating inner loop can act as a strong player magnet to quickly draw the player from the outside
to the inside. However, this is only valid if the player very well knows about it and its strong advantage.
Vantage points, NPC, or maybe even narrative means are some better ways to message this to the player,

(a) (b) (c)

­FIGURE 9.14 (a) Simple dominating inner loop (b) More complex dominating inner loop(s). (c) Probably a too complex
dominating inner loop(s).
112 A Practical Guide to Level Design

(a) (b)

­FIGURE 9.15 (a) Base high-level layout. (b) Open inner circle example as tank path (with an outer circle, too).

but it is quite tricky to tell the player something like, “Hey, there is an advantageous loop inside that
location ahead.”
For example, a player-centric inner loop inside an open-world location could be a chain of connected
rooftops. Some connections are simple jumps, some wooden boards, and some zip-lines. The player
can stay up high, controlling the surroundings while continuously going all around. The same principle
from the example can easily be applied to other settings with teleporters, jump-pads, zero-gravity fields,
speed-boosts, double jumps, or inviting wall running opportunities.
However, it has to have an advantage to dominate this inner lane. Controlling roofs is just one case.
Others could be, for example again POAs like resources, objectives, stationary mounted weapons, stealth
ambush spots, or excellent sniper positions. The nature of the advantage defines the type of loop. So, for
example, if it is about striking from the shadow to take down opponents silently, then the loop might be
less about roofs all the time but could include sewers or dark alleys as well.
Now, when I wrote above about the outer circle going around a location, it is by definition just one
circle. However, inside, things can get a lot more complex. It can be more than just one loop, like, for
example, two intersecting loops or an eight. However, I would be careful making it too complex or it
water downs its impact and clarity.
Another advantage of inner loops is that you can have multiple ones in the same space. A surrounding
one is limited and defined by, well, being the surrounding one. However, inside, you could have your
dominating tank lane, for example, but the player has connected ambush POAs. Especially the tension
between a few paths can be exciting and provide for a good flow yet challenging player experience for
various play styles. However, as above, I would be careful if you have more than two to three such paths
in one space, or they might reduce each other’s clarity. A hard-to-recognize path is hardly a very domi-
nating one.

9.2.3.3 Enclosed
I want to believe that inner circles in an enclosed context are a lot clearer than in an open setting, where
the lines between the surrounding and inner loop are often blurred. Levels for Deathmatch, or maps
for similar game modes, often feature an inner loop. Typically, especially larger maps of this kind have
multiple, connected ones, not just one simple dominating loop. Players switch between them depending
on their situation or enemy position.
Another good example is building interiors where hallways, walkways, and stairways create such
inner loops, while the inner and outer rooms are the extensions. If you dominate the hallways, you con-
trol the movement and reduce options from anyone in the rooms. This approach works for both single-
and multiplayer.
High-Level Layouts 113

(a) (b)

­FIGURE 9.16 (a) Base high-level layout. (b) Enclosed inner circle example (two skyscrapers connected by bridges).

Extensive, complicated networks of inner loops need careful consideration because they quickly
become overwhelming and frustrating to navigate clearly. Especially interiors with limited overview
and visibility are hot spots of such issues. In such cases, I recommend clear styles for the different set-
tings, bottlenecks to funnel player attention/focus, and especially a clear separation between the main
dominating lanes and secondary ones. Additionally, any player-leading elements to establish orientation
are highly supportive here, but more about such elements later.
Let us quickly go back to building interiors, especially believable ones with a real-world reference. The
issue is that hallways and rooms define most buildings, and most of their rooms are dead-ends. Anyone
ill-advised to transform their school into a level might have quickly realized that it often is not the most
fun layout. As a result, many level designers develop creative solutions to connect the rooms somehow to
create alternative, secondary paths, and loops (insert scaffoldings or construction sites here). However,
if it happens too much, then you create a very messy and confusing network. Instead, I recommend clos-
ing off rooms and focusing on those who have interesting inter-connections and interior space setups.
However, if, after closing off many rooms, hallways become too long or boring and create problematic
bottlenecks, then simply take the liberty and shorten the hallways. If the hallways are your dominating
inner loops, then you need to ensure that they are indeed dominating and not a long, frustrating death
zone. Realistic environments rarely provide consistent fun looping spaces.

9.2.4 Incomplete Loops
Granted not every arena can provide a dominating loop of any kind. Reasons for such a case could be
an engine limitation, production limitation, a conscious gameplay consideration, or related to world-
building restrictions. Not every engine or game allows for large open space with potentially long con-
nected sightlines. You might not have the time or resources to create all the space. Gameplay reasons
are typically connected to a wish to control player movement in some sort. Lastly, for example, not every
space allows for a bigger loop surrounding a location if there are large cliffs or lava lakes involved.
Essentially an interrupted circle means a few things. First of all, they can feel more like a linear sec-
tion than an easy-flowing arena. In that case, I recommend considering aspects from this chapter and
the next about linear high-level layouts. Secondly, secondary routes can still establish loops, but due
to their nature feature a less smooth flow. Still, especially if the limitation is engine or world related it
is better than nothing. Thirdly, after some closer consideration you might end up with only a heavily
dented loop and not with an incomplete one. Often, I’ve encountered designers wanting to create a more
linear flow, but then the nature of the game added so much space and routes around that it was still one
or two separated arenas connected by a bottleneck. In reality it is difficult to create a true incomplete
circle flow in games which has a reasonable amount of free roaming. If it is a good flow is a different
question.
114 A Practical Guide to Level Design

(a) (b) (c)

­FIGURE 9.17 (a) A true dominating incomplete loop. (b) Could also be a dominating inner circle but it is a stretch since
there is a non-dominated loop below. (c) Just a very squeezed dominating inner circle.

(a) (b)

­FIGURE 9.18 (a) Base high-level layout. (b) Center axis example (semi-symmetrical variation, mission area is yellow).

9.2.5 Center Axis Layouts

Not every good flowing layout is dominated by a loop; some are dominated by a central lane. However,
this is typically more the case in multiplayer maps, given a consistent back-and-fore between two teams.
For singleplayer maps or other game modes, which are more about reaching a point and then keep on
moving, I recommend looking at the next chapter about high-level linear layouts. It is possible for single-
player, but more of a rare special case.
For center axis layouts, the flow is established by the consistent push and pull of two teams throughout
the layout. You do not have a circular flow throughout the entire layout, as long as each team is consis-
tently spawning at their side and, therefore, stays in control of each side.
A classic example is CTF, where both teams have the same objective to capture their flag from the
opposing side and bring it back to theirs. The effective route between the two flags establishes the central
lane. Of course, the central lane has other important supporting lanes, but it all starts with the main one.
Similar game modes like Payload or Escort can benefit from similar thinking.
More than one dominating lane is possible as well, of course. However, the shortest and easiest route
will always remain the most dominating ones. Other lanes might come very close in importance, and it is
not uncommon that matches are won or lost here. Still, losing control of the fastest and most direct route
between objectives is always a significant disadvantage. I am not a MOBA (multiplayer online battle
arena) developer but looking at the standard MOBA map layout is a good starting point for a multi-lane
layout approach.
As a level designer, you can look for other advantages for the longer lanes, but I would not expect a
perfect balance. Another way to see it is that the other alternative main routes serve different purposes or
High-Level Layouts 115

playstyles. Some lanes might be more stealth or long-range oriented, while the central one is more about
direct confrontation. Speed will play a factor for both the side and the center lane; you either want to keep
up the pressure in the middle or compensate for the longer path somehow.

9.3 Linear Levels
9.3.1 Introduction
The core definition of a linear level is that players have to get from A to B. This progression is either
achieved by a linear objective chain, a linear physical space, or a combination of both. However, this does
not mean just a singular lane or exclude loops in between. This chapter will focus more on the physical
layout aspect; later chapters will cover the entertaining mix/order of ingredients like objectives, pacing,
and connecting the pieces.
This chapter covers the most common type of linear high-level layout types, which are branching and
mixing in sandbox sections.

9.3.2 Compartmentalizing
Before we jump into the different types, let us first cover one of the most important considerations, or it
can quickly get messy planning out any linear level. The easiest way to design a linear experience is to
split it into explicit segments. Each segment is different from the next gameplay-wise and very often visu-
ally as well. They have a clear start and end, typically defined by an objective or progression milestone
for the player. I will cover pacing a bit later, but separating the experience into smaller pieces is essential
for a ­well-orchestrated
​­ experience.
You define each segment or beat by the player’s time spent here and less about the size of space per se.
A beat is a similar intense experience, like a single and simple objective or similar intense fight. Each
beat should not be longer than two to ten minutes for a regular playthrough, with a bit of slack and no
strict science attached. When I previously stated that they should have a clear start and end, it does not
necessarily mean a physical entrance and exit, but more a clear start of a beat and end of the experience
before the next one starts. This difference means that you can have multiple beats in the same space.
Still, looking strictly at the layout, this means that the individual segments typically only have one,
sometimes two or three connections to the next one. Those bottlenecks help you focus the layout to a
few focal points—the less, the easier. At those points, you can easily switch up the theme, pacing and
especially run all your next scripts for the segment.
In classic linear levels, those connection points between segments were points of no-return. The origi-
nal reason for this was often streaming. During the transitions, you unload anything from the previous
segments and load the next segment into memory. It was not a matter of space but time. Therefore, those
transitions often had other time-consuming elements like slow-moving doors, or they always required all
coop-partners to be present. Nowadays, games still feature points of no-return even though streaming is
becoming a smaller and smaller reason. The primary reason is to prevent players from going back to the

A B

­FIGURE 9.19 Linear level compartmentalized into five segments with increasing complexity, last two segments have
more than one connection.
116 A Practical Guide to Level Design

previous segment for baiting AI or similar gameplay reasons. However, we will cover that low-level topic
several times further down in this book.
This compartmentalization makes it easier to create and design, but it also gives players a meaningful
sense of progression. If everything feels very similar, it is hard for players to understand moving in a new
direction. However, the requirement is that, of course, each segment is noticeably different. For example,
one segment is on rooftops, the next in interiors, and then on the street level.
However, just because you compartmentalize the linear level, it does not mean that the transitions
have to be jarring or abrupt. Smooth transitions are a must, and carefully balancing the contrast between
the segments is highly recommended. However, the contrast is contextual and is a careful case-by-case
consideration. For example, an oil refinery switching from peace and quiet to suddenly a burning inferno
can make sense. However, switching from the oil refinery to a natural beauty segment is a bit of a stretch,
without some heavy magic, sci-fi, or mind-trick lifting.

9.3.3 Linear Branching
9.3.3.1 Introduction
The most common segment type within a high-level linear layout is a linear branching one. Typically, it
starts with one line connecting the start and end, but if you want to give the player more than one path,
you add additional ones, branching off the layout. However, since we are still on a high level, a branch
has way more weight. I am not talking here about the small little, close side-corridor or going left or right
of your shipping container. Each branch has to have at least one, or ideally more, significant POAs. At
best, each branch offers a different gameplay/visual experience or supports a different play style. If the
POAs or a branch is not strong enough or the difference between the branches is weak, you might simply
cut it. Each branch needs to have a strong reason to exist, or it is a production waste and not giving the
player a significant enough experience. It is better to spend production efforts on one good path than two
mediocre ones.
Therefore, I split branching into two categories: wide and tight. Each of them has its justification and
challenges.

9.3.3.2 Wide Branching
For me, wide branching means that the branches of a segment are so far apart that they are not in direct
connection or proximity. While on the one side it allows for a truly different experience worthy of a
proper branch, it also comes with challenges.
The primary general challenge is production. Creating two very different separate branches is not
necessarily right away double the amount of time and effort. However, it certainly adds up, especially if
you have three or more such branches. It is not just your time creating the additional lanes, but also, for
example, set-dressing it and testing each branch, especially for QA/QC that can very quickly add a lot
of daily workloads! It is a serious consideration, and you should not just add branches just to show some
options alone. It needs to add serious value to the game and your level, or otherwise, I recommend put-
ting the effort in fewer branches.
This issue is crucial if the different branches are not different enough. For example, you have a large
building, and the player could go around it left or right. If both paths feel and look similarly clean, have
almost the same amount of cover, and feature a comparable AI setup, then save your effort and cut one
of them. However, if one path is more open, bright, with a loose cover network while the other is dark,
dingy, and dense enough for some nice stealth routes, both branches have their justification.
The main advantage of wide branching is that it helps to create the illusion of a large world while
remaining in a linear core experience. The disadvantage is the increased production costs for paths
which many players will not even notice. If two branches are equally attractive, 50% of players will
never experience one of the paths. It obviously gets worse with more branches. Therefore, if you decide
to create wide branch high-level setups, make sure that every developer can finish them in time and that
they are worth it.
High-Level Layouts 117

A B A B

(a) (b)

­FIGURE 9.20 (­a) Base ­high-​­level layout. (­b) Wide branching example (­the lower path overlaps now the center one).

A B A B

(a) (b)

­FIGURE 9.21 (­a) Base ­high-​­level layout. (­b) Tight branching example (­rooftops, the upper navigation path overlaps the
center one, the center path is straight up action, the lower path is stealth going through interiors)

9.3.3.3 Tight Branching
When wide branching means completely separate spaces, tight branching means one or more lanes going
through the same space. The production advantage is clear because often, creating one space is easier
than multiple ones. However, squeezing in two separate ­high-​­level lanes through the same space is the
primary challenge. Like with the wide branches, each branch here has to be very different from the oth-
ers to be justified. Otherwise, they are just options within the m
­ id-​­level.
A very good application for tight branching is when a space or segment supports multiple playstyles.
For example, your rooftop section has a central path for all the ­action-​­oriented parkour ­speed-​­freaks, but
it also has a stealth path woven around, below, and above the central one.
Most spaces, which feature tight branching, struggle to create the feeling of a larger world. Their use
has its place, but be aware of the drawback. If you try to compensate for this and the space for your tight
branching grows larger, you potentially cross into wide branching or create an arena. Depending on the
game and your intentions, this transition does not have to be bad; just be aware of the consequences. I
know this whole topic can quickly turn into a subjective argument. However, I recommend sticking to
the strict differentiation between arenas, wide and tight branching, because it allows you to better plan
and manage expectations.
118 A Practical Guide to Level Design

The risk is high that different branches merge too close together or are too similar. However, if you
take it seriously, you can create a genuinely different experience for the player while also hopefully keep-
ing production efforts reasonable.

9.3.3.4 Branch Connection Angles

One key difference between arenas and linear spaces is that arenas try to keep the player freely roaming
inside, while linear spaces try to guide or attract players to a particular space or event. For linear levels,
this means that the connection angles of branches have to be correct or it can lead the player backward,
potentially keeping them in unwanted loops.
After creating your first primary path, every additional branch should connect to the primary one point-
ing in the target direction; the “pointier,” the better. Reconnecting at a 90° angle might leave players guess-
ing to either go left or right. Any angle which points back to the origin of the segment has a high potential of
sending players on a confusing and frustrating journey, especially in a wide branching scenario. Of course,
certain player-leading elements such as signs, lighting, and waypoints can help to compensate. However,
the more in-world player-leading elements you implement instead of relying on gamy waypoints, the better.
I bring up connecting angles already at high-level because the sooner you consider them, the more
likely you properly implement them. It is about getting in the right flow mindset, right from the get-go,
during ­high-level
​­ planning.

A B A B A B

(a) (b) (c)

­FIGURE 9.22 (a) Branches (pink) point toward the target B. (b) Branches (pink) reconnect with the main path in 90°. (c)
­
Branches (pink) point backward, away from B.
10
Connective Tissue

I wrote a lot about high to medium-level layouts and theory. However, before I go into more details about
the nitty-gritty and how to get started in practice, let us cover one severely underestimated aspect: How
it is all connected.
When the high and medium-level concepts are your foundation or skeleton, your action areas are
the muscles; then the connections are your tendons—if they are weak, it all falls flat. Therefore, I
will first talk about the actual connections in various design and world contexts. I’ll follow it up with
a brief dive into the verticality. Then, the progression within a level is about the right mix and order
of major ingredients within a mission flow. The last chapter is about pacing. Understanding pacing
is essential, or all ingredients won’t flow well together at the wrong speed and it all feels like a big
incoherent mess.

10.1 ­Inner-Level
​­ Connections
10.1.1 Introduction
I guess we all know a few movies with some pretty intense action scenes, but how they are stitched
together in the movie’s narrative does not make sense or is not coherent. Now there are many reasons for
bad movies, but one vital aspect is how all the main beats are all connected. How the heroes got from
A to B and especially how they used the time is crucial to create a coherent experience. In level design,
this is even more important because here, players have to move themselves and do not have the luxury
of a sudden cut jumping from, for example, Kairo’s buzzing streets to a dodgy bathroom in Hong Kong.
Each of the main world or level types has different requirements described below. However, I recom-
mend you read them all, regardless of what game you are working on because they are not as exclusive
as my categorization makes them appear. Finally, transitions in and out of cutscenes are crucial because
otherwise you end up with a jarring experience.

10.1.2 Connection within Linear Levels

10.1.2.1 The Classic Usage
In the past, and occasionally still today, levels were linear because of streaming. Due to hardware
restrictions, there was not enough memory to load all the assets, textures, animations, audio, scripts,
and much more of the entire level. Therefore, levels had to get cut into chunks that individually fit into
memory. In simple terms, the previous chunk was unloaded during the next transition, and the next
chunk was put into memory. Therefore, the transition or connection had to take a certain amount of
time (not long space per se), and often they had to be points-of-no-return. Planning in one direction
was already not easy, but continuously allowing it both ways just made it extra difficult or not always
enjoyable for players.
However, one particular problem is that when you start working on the level, you do not know how
heavy each segment’s memory load will be and how well the engine or tech might still get optimized
during development. Therefore, you do not know till sometimes between Alpha and Beta (rather the
later) how long or time-consuming your connections have to be. As a result, you need to build your
connections with flexibility in mind, and you can only start with a guesstimate. I would recommend
starting with rather too-long and curvy/corner transitions because making them shorter than longer

DOI: 10.1201/9781003275664-13 119

120 A Practical Guide to Level Design

is typically easier. However, this seriously depends on the context and available space. Another fac-
tor is if your tools allow a safe movement of large chunks of your levels to adjust the length so late in
production.
Another important consideration is how you create the unload and load time. The easiest way is sim-
ply a long path and some type of point-of-no-return, like an automatic locking door behind you, a deep
jump down, or a one-way teleport. Fancier solutions are procedurally generated hallways that adjust their
length based on the load time or often longer transition animations like a really heavy door or an NPC
providing (slow) entrance.
Depending on the engine and underlining online tech, in Coop, it is often crucial that all players are at
the ­points-of-no-return
­​­­ ­​­­ ​­ and progress simultaneously, or it can lead to technical difficulties.
With time, memory, and storage, mediums got faster and faster, reducing the severe impact of
streaming. As a result, it allowed for way faster transitions to almost instantly switching entire
worlds. Still, I believe understanding streaming as a concept remains vital for every well-rounded
level designer.

10.1.2.2 Control and Hide the Transition

Now, such transitions give you much control, yet they can appear jarring for players. This case can hap-
pen regardless if you utilize a transition for streaming or ideally compartmentalize your linear level (as
mentioned in the previous chapter).
Let us start with the control aspect. You have to set up the entire next segment during the transition, or
at least the initial part. So, we are talking here, especially about scripts that, for example, activate all the
AI, update mission objectives, play dialogs, or set anything else into motion. The timing and placement
of this script activation are crucial, and ideally, it happens a good time before players fully experience
the next segment. No player traveling at the highest possible speed should experience any assets popping
in the scene or AI just “waking up.” I recommend playing safe with the placement because those activa-
tion times tend to change during the production cycle. The transition is also a good place for any master
scripts for the entire upcoming segment.
Secondly, the jarring or boring experience often happens because the transitions are just bland tran-
sition corridors and are not utilized for something else. They are very gamey when players clearly
feel that they just play a game instead of an immersive experience. Therefore, your goal as a level
designer should be to mask or hide the transitions as much as possible or at least use them for something
meaningful.
Once players reached the end of the segment and entered the connection, they hopefully accomplished
something. Now, whatever the previous segment had to offer as a gameplay challenge is not present any-
more during the transition. Additionally, the transitions are not high-octane action sections because then
they would not be a transition but the next segment already. Therefore, we typically cannot use gameplay
to fill the void, but we still have navigation and narrative. Narratively closing the previous segments and
teasing the next one with (radio) dialogs is a good starting point, especially because they are otherwise
ill-placed in the middle of the action. Low memory environmental storytelling is another solution to give
players some alluring hints about what is going on in the world. Art that is very heavy on memory is
not a good idea for transitions because it would defeat the purpose of streaming. Finally, suppose your
game has a good amount of navigational features. In that case, you can always use them to build small
puzzle sections in between, especially in conjunction with collectibles or other achievements. Essentially
it boils down to taking away one “candy” from the player, but replacing it with another one, just with a
different “flavor.”
­

10.1.3 Connect between Sandboxes Arenas

10.1.3.1 Introduction
Transitions between sandbox arenas are typically a mix of either linear segments or comparable to
open-world connections. So in this chapter, I want to focus on what makes them unique. Additionally,
Connective Tissue 121

I believe most of the points here could also work for both open-world and linear transitions with some
slight adjustments.

10.1.3.2 Foreshadowing and Leading

If you connect sandbox areas, it is typically not through a tight tunnel, but at the same time, it does not
offer the complete freedom of an open world. It is normally something like a wide tunnel or wide-open
field. However, this mix of loose leading yet some light control allows for some interesting teasing and
leading options.
Since you know the rough direction of travel, you can foreshadow the next location with much small
environmental storytelling along the way. Signs, smoke ahead, and NPC conversations are obvious, but
they can also get more exciting. Think about the consequences of what happened at the upcoming loca-
tion and show hints of those results. For example, the next location is a village taken over by some cruel
enemies, and you could show some luggage lost in haste along the way with a teddy bear. Factories can
be hinted at by toxic waste and poisoned animals, or on a more positive note, a festival by a firework,
singing drunks stumbling home, or happy kids with cotton candy. The advantage of doing it in such wide
“tunnels” between sandbox arenas is that it does not feel forced, you can pace them out how you want,
yet you do not have to cover a massive area like in an open world.
Let your fantasies go wild, and rather place a few too many according to your guts because very likely
most players will not find all hints anyhow. The fantasy and ideas players build up in their minds are
often the crucial, powerful key to making your target location come to life. Think about the anxiety of
approaching a haunted house, planning your first date, or before performing a public speech. Without
that anxiety or foreshadowing, it is just half the “fun.”
As much as teasing is excellent in such semi-controlled/loose connections, it also allows you to give
direction without making it feel forced. Of course, likely some borders left and right provided some direc-
tion already, but ideally, they are not too apparent due to foliage, architecture, or generally believable
world-building. However, I am talking more about the little aspects like small seemingly hidden trails, a
suspicious-looking tunnel entrance, no birds singing getting closer, or a sign which clearly states some-
thing like “GET AWAY” or “TRESPASSERS WILL GET SHOT.” Essentially anything in real life would
send an unequivocal uninviting message, but in many games, they achieve the exact opposite. However,
once players overcome their fears or do it regardless, they might feel clever or rebellious. Regardless, it is
a good thing because players feel they acted and not the game told them to do something. At that moment,
it does not matter that you, as a game developer, have placed them precisely for that noble purpose.

10.1.3.3 Where and How to Connect

It can be difficult to block off connected sandbox arenas because of their usual semi-open game environ-
ment. Below are a few examples of how you can still get players to a specific point or area and control
the unlocking to the next sandbox arena. Even if they are likely not applicable for your specific game, I
hope they give you enough inspiration to find solutions that work for you.

• Players have to get close to an NPC (or interact with them) who only open up the next transition
after completing the last objective.
• Players can only interact and open up the transition to the next arena after completing the last
objective. However, make it logically connected; for example, the previous objective gave you
a key for a door, the code to call for helicopter pick-up, or the correct disguise to enter a club.
• Arriving AI opens up/allows the transition to the next sandbox arena after completing the last
objective. For example, an arriving elephant or tank crashes through a gate, or players can use
the arriving boats to cross over to the next island.
• An in-game event opens up the next transition after completing the last objective; for example,
planes blow open a gate, a huge ape places a tree as a bridge, or your allied NPC can now crack
the safe.
122 A Practical Guide to Level Design

• A cinematic event opens up the next transition after completing the last objective; for example,
the game’s nemesis lures you into his dungeon, a certain woman lets her hair down, or a trans-
port helicopter picks you up (more about cinematic transitions further below).
• The objective in the next sandbox area is not present yet. However, this can be a bit tricky if it
should not appear too gamey. For example, the enemy helicopter fleet only arrives if players
previously caused much trouble, or the big mean boss dragon only shows up if the player is
covered in the blood of the previously slain dragons. However, avoid anything contrived, like
the next, already physically present interaction is only active after completing the last objective.
• The next objective location does not exist yet before players have not completed the previous
objective. So players can visit the next arena, but not the next objective because the entire
objective location is missing. This case typically requires magic, fantasy, expensive, or sci-fi
elements like teleporting cities, giant worms coming out of the earth, or big spaceships landing.
• The current objective gives you the only/ best weapon to defeat the enemies in the next sandbox
arena. Sure, players can skip the previous arena, but they might regret it.

Below are a few points of ideas you ideally avoid:

• Coincidences like players complete an objective, and now an NPC remembers that he had a key
the whole time.
• Disconnected consequences, for example, you free some hostages, and then an earthquake
opens up a cave.
• The opening secretly appears because the developers hope that players do not snoop around
in that corner of the sandbox arena and will not notice that, for example, the ladder was not
there previously. Variants of this case are typically last resort solutions to cover up edge cases,
noticed late in production—happens to the best, but good planning can avoid them.

10.1.4 Connection between ­Open-World

​­ Locations
10.1.4.1 Introduction
First of all, in this chapter, I want to write about open-world connections covering large distances. Shorter
distances are closer to sandbox arena or even linear level connections. Secondly, player-leading is a crucial
factor for such long-distance connections, and I strongly recommend you agree on the types of player-
leading before starting to work on most of the game. Changing in too late will only create lukewarm results,
and you might end up with waypoints again—however, more about the player leading in later chapters.
Therefore, I want to solely focus on some unique aspects of such long travels through an open world.
As a quick clarification, connections between open-world locations can also cover the transition
between the questor mission giver and the quest or mission location. It does not have to be only about
transitions between two quest or mission locations. Also, this chapter is more about very loose or non-
orchestrated connections. Later chapters cover the more production-heavy case when the transition is its
own challenging mission segment.

10.1.4.2 How to Embrace No Control

One of the striking aspects of an open world is that they commonly do not provide tunnels between their
locations. Sure, there might be leading world elements like valleys, streets, tunnels, or rivers, but they
typically exist because of world-building considerations. However, they can exist for transition purposes,
or locations were picked due to their existing transitions. For example, if you want a severe high-speed
connection between two locations, you typically pick two connected by roads and not mountain wilder-
ness. Still, strict control of the player movement does not exist.
However, if players have a clear sense of direction provided by a waypoint or compass direction, most
will follow it almost blindly. I saw enough playtesters crushing down cliffs despite a bridge 50 meters
Connective Tissue 123

to the left. Therefore, an open world is more an illusion of no control because most players follow such
gamey markers often more strictly than in even linear levels.
Let us look at how you can approach this contractionary control and lack of control to our advan-
tage. As a starting point, provide a semi-straight direct connection between the two locations. This
connection does not have to be all safe, but you should give players a fair chance to spot dangers
ahead of time, especially when traveling at high speed. For example, no surprise cliffs after a few
dense bushes. Then in the areas where they can detect the danger ahead show them an alternative
route. However, keep in mind that both the areas to spot and the alternative route are not clearly
forced by the game. Therefore, they have to be quite large and stand out. Do not expect most play-
ers to study maps or spot little clues. If you as the developer think it starts to be a bit too obvious,
then it might start to be okay for most players. Depending on the distance, you can do this approach
multiple times.
Additionally, roads or trails can be player magnets, but only if they “convince” players not to go off-
track. It is almost as if they have to establish first some trust with players before they drive on them.
Therefore, initially, try letting the roads go in the perfect direction for quite some time before going a bit
off-course. When their direction goes too far off, then provide a new route, an inviting opening in the
vegetation, or a new road/trail.
All the locations along this main route and where players adjust their course are great spots to fore-
shadow the target location, the current state of the world, or anything else connected to world-building.
Their concentration is high at those spots and hopefully more open to looking around and taking the
stimuli. Other alternatives are, for example, hints for further quests, missions, achievements, collect-
ibles, cool locations to do some stunts, small or bigger world events, or impressive-looking vistas to take
pictures.
Essentially in my experience, the best way to embrace free travel through an open-world is to nudge
it a bit. Players are so attracted by straight-up traveling directly to any location that we as developers
should take advantage of this. Provide them a good time, use them for world-building, consider player
magnets, build up trust to not make it too straight, but without making it too frustrating. The challenge
factor depends on your game.

10.1.4.3 How to Embrace Long Distances

Another relevant aspect of open-world connections is that they often take a long time. So how do we
make them still exciting for the players without making it another too orchestrated and production-heavy
transition? Below are my classic go-to solutions on how to make long travels more enjoyable.

• If you have any leading elements like roads, rivers, or tunnels, try to curve and angle them to
reveal epic vistas or otherwise stunning art/environments. Especially consider this if you can
control the time of day.
• Radio/phone calls from NPCs are perfect during long rides. You have an extended period
where the player’s character and NPCs can hopefully have a long uninterrupted conversation
for world-building, character development, or background information. Narrative moments are,
of course, even better if the NPCs are sitting in the same vehicle. However, ensure that the dia-
logs can stop if accidents happen because it is usually a bit off-putting if two people chat while
drowning or burning in a car.
• As previously mentioned, travels through the open-world are good opportunities for world-
building. Placing many advertising signs, generally relevant world events, or hints of world
state can work not just for this one mission but also for any travel through the open-world.
• Investigate if you have means to increase the challenges or threats along the way for specific
missions; for example, a higher rate of police cars, more helicopters, or more wild animals
populating the roads. Essentially anything which can give the transition not just a bit more
challenge but also some unique theme. It is even better to have such adjustments only to specific
regions instead of potentially the whole monotonous track.
124 A Practical Guide to Level Design

• Plan long travels to go close to other distractions along the way. For example, quick
side missions, something to take over or collect, or NPCs with additional information
or quests. Essentially anything which enriches the player’s understanding of the game’s
world or gameplay. Of course, ideally, do not distract players with anything major because
ultimately, they should focus on the current main quest, but some occasional distraction
does not hurt either.

Last quick point if you plan your connection with a specific vehicle: Travel with it through the open-
world as early as possible. Just because the vehicle sounds fun, like flying or speed-boating, does not
mean it is fun in the world’s or game context. For example, on paper, an epic world-crossing helicopter,
wingsuit, or plane section might sound fun. However, ten minutes of just pressing a button while flying
gets quickly boring without any obstacles or real challenges.

10.1.5 Connection between ­In-Game

​­ and Cutscenes
10.1.5.1 Introduction
Cutscenes are scenes where the player loses control over their action and camera. They provide no player
agency but, depending on the game, are important narrative tools. Consider their implementation very
carefully and early on because they are in such a stark contrast to pure gameplay. If the direction for their
implementation gets defined too late, it can lead to much avoidable friction between cinematic/narrative
and level design teams.

10.1.5.2  Intro Cutscenes

If there is a good collaboration between the cinematic team and the level designers, I typically do not
foresee any complications with intro cutscenes. They are a classic staple of level design and games in
general. The main challenge is the smooth transition, but that is more of a matter of tech and resources.
The primary and most important aspects of level design are what the cutscene foreshadows and where
and how it ends. Do you want to reveal parts of the level already, or shall they remain a secret? If you
want to foreshadow, what are the important parts? Ideally, they are from an angle where players in-game
can recognize them again. The final gameplay start angle and position are also key and ideally set or
defined by the level designers, not the cinematic team.

10.1.5.3 ­Mid-Level
​­ Cutscenes
By default, I have to strongly advise against using any cutscenes in the middle of a level. The classic
issues are:

• Enemies could still be around. Of course, you usually could turn off all AI during cutscenes,
but activating them is not just a jarring experience in the middle of a firefight or can be used
as an exploit.
• The cutscenes area could be covered by, for example, vehicles, wrecks, debris, physical-
ized props, dead/alive NPCs, and VFX. Again, cleaning it up by script creates a jarring
experience.
• It breaks the immersive flow from free gameplay to losing control and back to free gameplay.
Some people tend to downplay it and refer to other games that have done it, but something bad
others have done does not make it better in your game.

It all gets even worse with the wrong transitions or triggers. I consider it a cardinal sin to start a (mid-
level) cutscene with a surprise invisible trigger, either spatial or by an event. The player has no idea what
could happen suddenly and gets ripped out of the immersive experience into losing all his agency. Those
triggers have to be avoided at all costs, especially if the result of the cutscenes means the player travels to
Connective Tissue 125

a new location or all pick-ups disappear. You never know what players still want to do here, like explor-
ing, collecting, or otherwise enjoying your game world. Robbing them from this experience or possibili-
ties is the worst cutscene transition.
If you really have no choice against a mid-level cutscene, then ideally, have the transition in a new,
safe, non-combat space. Depending on the game, the player, for example, cannot drive into the location
with their vehicle or litter it accidentally with physicalized props or dead bodies before triggering the
cutscene. Accidental is the keyword here, just to avoid any unforeseeable loss of their favorite car, crate,
or corpse.
I recommend starting the cutscene with a conscious player (inter)action like pressing a button, talking
to an NPC, or activating a radio. It should be an action they do not do all the time without triggering a
cutscene like opening a door or picking up ammo. The player should expect a cutscene to happen and
can still finish the area beforehand.
Another problem of invisible, spatial/event-based triggers is that you do not know where the players
are at that moment. If the space is relatively large, there is a noticeable jump between where they initi-
ate the cutscene and where the players are at the beginning of the cutscene. Depending on the distance,
this can be jarring, or even worse if players teleport to a completely different location out of nowhere.
Therefore, if you really have to use such triggers, make the trigger space as small as possible. Again, a
player (inter)action removes this problem completely.
Finally, the frequency of mid-level cutscenes is crucial. If one of them is terrible, more is worse, and it
was likely lousy planning if they happen back-to-back.
­ ­​­­ ​­

10.1.5.4 ­End-Level
​­ Cutscenes
Cutscenes at the end of a level face the same challenges as mid-level ones. However, they have a few
advantages.

• A bigger jump, for example, in a helicopter or back to the base, is more forgiving when it is at
the end of the mission.
• Typically, players kill all enemies at the end of a mission before the mission-complete-cutscene
triggers.
• Often you move away from the last location during the cutscene, so any devastated or littered
environment is no big problem.
• Picking up ammo or other pick-ups is not that important once the mission is over but can still
be a topic for collectibles, achievements, or similar ones.
• In general, it is not a complete surprise if defeating the last big boss/objective triggers a
cutscene. However, ideally, manage the players’ expectations.

10.2 About Verticality
10.2.1 Introduction
Verticality simply adds another (third) dimension to your level, giving you many more options, espe-
cially in layout. I am not talking here about just some softly rolling hills or mild height differences,
but about overlapping spaces or lanes and anything where players have to consciously look up or down.
However, verticality does not come without its challenges. So in this chapter, I want to cover high-level
layout and input considerations before we jump into some of the most common tools which create
verticality.
Quick disclaimer: Most of the level sketches in this book primarily display 2D landscapes with
few elements of verticality besides some houses, towers, or rocks. This simplification is not because
I am not fond of verticality, but it is clearer to bring certain aspects across on paper without its
complexity.
126 A Practical Guide to Level Design

10.2.2 Importance of Verticality

For some, it might sound trivial, but if we think about it, without this extra dimension, we would only
care about looking left and right or navigating on a 2D plane. Every time you create an ample space
without verticality, you severely limit the players’ options and waste potential.
Additionally, it offers a lot more possibilities for you as a level designer. For example, often flanking
routes can be replaced with a short underground tunnel or an overhead zip-line connection. Another
example is that adding stealth paths in an office interior would be close to impossible without the conve-
niently placed air ducts, cable shafts under the floor, or ceiling pipes.
Let us also not forget world-building. Often verticality is not a matter of pure level design but comes
with the world’s reality, for example, anything in the high mountains. If the world’s reality forces verti-
cality on level design, we, especially with art and game design, have to find creative solutions to turn it
into an advantage instead of a hindrance.
Always think of how you can add verticality, making players enjoy and comprehend the world and
game further. First of all, if players in a city never have to look up or down, then most of the potential to
showcase an exciting urban environment is wasted. Secondly, it is usually okay challenging to engage
targets at a different axis, other than left and right, and let us also consider other threats, paths, hints, or
pick-ups up or down there. Thirdly, it is simply quite dull for players never to need to look around, not
just from a challenging perspective. However, I recommend not forcing verticality where it makes little
to no sense, especially to add suiting verticality. For example, adding random towers on a frozen lake is
not always fitting.

10.2.3 Planning Vertical Levels

Typically, I start sketching out any level-sketch 2D first, but then I try to add as much verticality as
reasonable. Can I overlap any lanes? Does verticality make sense from a world-building perspective, or
does it add anything to the level?
The presence of verticality alone is not a reason for any potential design, planning, or sketching
complications. Especially not if it is, for example, just a few zip-lines, small tunnels, or hills. However,
if a level has many or large overlapping parts, sketching or planning such a level is tricky, for example,
multiple floors of a building. Therefore, plan out each floor separately and just mark the connecting
staircases. If it gets a bit more complex, I recommend providing an isometric wireframe sketch of the
high-level— the same counts for anything more detailed, but more about documentation a bit later in
this book.
However, even if it is not easy to plan the h igh-level of a complex 3D space, any connection is part
of the flow. Every staircase is a bottleneck and acts as a connection. In many ways, they are even
more important than most hallways and other basic bottlenecks because they can unlock/control
access to entire new playing fields. More about staircases and other aspects of verticality is further
below.

10.2.4 Controller, Height, and Angle Considerations

10.2.4.1 The Controller
When I switched from making exclusive PC shooters to designing console games, I had to learn the hard
way that both platforms handle verticality differently. Mouse and keyboard make it a lot easier to look
up/down while moving, while many players struggle to do the same with the same ease using a common
console controller. Many playtests I’ve observed have confirmed my own learnings.
Especially tight small turns, including an upwards or downward viewing angle, are tricky. The tight spi-
ral staircase is a classic example, but it can also affect fast engagements at ledges. Therefore, I recommend
avoiding any extreme cases where you mix dangerous movement and steep viewing angles. Try to make
your staircases a bit wider, or ledges with many fights not very deep/ high. Console players can, of course,
handle verticality, but with only a few adjustments, we can make their experience a lot more comfortable.
Connective Tissue 127

10.2.4.2 Anything Up There

Another big problem of anything very far up is that players do not see it because it is outside their field
of view. Most players, especially on consoles, are used to scanning left and right, but constantly looking
up and down is uncommon. So, for example, you added a vital hint up on a cliff, but players continuously
do not see it?
The first solution would be to frame a wider view previously, so players have a realistic chance to
see it in their field of view. For example, vistas, along paths, or previous navigational challenges guide
players looking at a specific point and direction. Secondly, you can add something at the bottom which
motivates players to look up. For example, this could be climbing ropes, a corpse/item which fell, or
simply a painted arrow pointing up. If it is a common problem in your game, I recommend adding it to
the ­game-wide
​­ player language.
Architectural or other art elements can motivate players to look up as well. Especially vertical lines in
geometry, bend-upwards features, or similar drawings on walls are way more subtle than anything gamy
or a big arrow pointing upwards. Another way is to involve game designers and develop certain features
with height in mind. For example, (high-up) snipers make themselves known with laser beams or tend
to miss the first shot.

10.2.4.3 Angles
Check how well your game’s features support navigation angles. Many features, such as building small
structures or specific animations, are not supported on slopes or stairs. Most games have restrictions on
how steep navigable angles can still be or how slopes affect cover—more about cover at slopes in a later
chapter.
It gets particularly tricky when terrain is involved. As a player, you do not clearly see when a slope
starts to be non-navigable or when certain features are not supported anymore. Therefore, it became a
norm to stay away from any angles close above the navigable limit. For example, if the game only sup-
ports navigation up to 40°, then stay away from any angles above 40° till ~70°–80°.
​­ Essentially eliminate
any frustrating assumptions and make it very clear where to navigate and where not.

10.2.5 Types of Verticality

10.2.5.1 Introduction
Below I am briefly covering common verticality types with a few important considerations, but keep-
ing it light since changing technology and your game’s context can be wildly different to my personal
experiences.

0° 35° 40° 80°

(a) (b)

­FIGURE 10.1 (a) Example: provide hints at the bottom of cliffs for players to look up for opportunities. ( b) Example: If
your game allows a max slope angle of 35° then players won’t notice the difference to the 40° one.
128 A Practical Guide to Level Design

10.2.5.2  Plain Height/Steep

­ Slopes
• AI can be kited around slopes/cliffs because players can jump down and AI cannot. Therefore,
if possible, keep the slopes/cliffs short and provide fast ways for AI to navigate up and down.
• If your game has falling damage, stay below the height lethal limit or go clearly above it.
• If the height is vast and players have to navigate or balance close to it, do not forget that vertigo
is quite powerful for some people, even if it is just a game.

10.2.5.3 Stairs, Ramps, and Slopes

• Slopes, stairs, or ramps are the default way to move up or down, and pretty much every 3D
game has them. If the world allows it, try to use them as your default over other types.
• They are critical because you can still fight and act on them, but consider which features are
affected by angles.
• Try to break up long (non-road) serpentines with other verticality types in between or switch
from going outside to a short inside section.

10.2.5.4 Interior Staircases
• If possible, avoid tight interior staircases, and if you cannot, avoid combat around and in them.
• They are death traps because they provide little to no cover, offer no space to dodge attacks, and
enemies have many attack angles. If you cannot avoid combat, try to make them as big, even if
it slightly bends realism.
• Avoid more than two to four continuous floors of tight staircases, or keep them as absolute exceptions.

10.2.5.5 Ladders, Vines, and Pipes

• Don’t be too tempted to place them everywhere where you need a quick and easy height transi-
tion. Think twice if a ladder makes sense at your location, if the length is reasonable, and the
number of ladders in a location.
• Be aware of potential game limitations on ladders, for example: Can AI use them? How many
AIs can use them at the same time, and what happens to the other waiting AI? Can players jump
on or off a ladder? Can an AI/player engage while hanging on a ladder?
• Ladders are your last resort option if you need a vertical connection. First, try everything to
avoid them since they are very limiting for players and AI. Plus, too many of them in one space
just look ridiculous.

10.2.5.6 Ledge Climbing
• Do not place more than two to three ledge climbs after each other, or it gets repetitive. Instead,
mix in some other verticality types in between if you have to cover much height.
• Make sure that the player language for climbable ledges, especially non-climbable ones, is very
obvious to players.

10.2.5.7 Free Climbing
• Ensure that the player language for climbable areas, especially non-climbable ones, is very
obvious to players.
• Developer tools to create such spaces need to be very easy and fast to use; ideally, automate
their creation as much as possible.
Connective Tissue 129

• Free climbing is a massive, expensive, and often game-defining feature. Therefore either do it
right or spend the resources for something else.

10.2.5.8 Elevators/Moving
­ Platforms
• Understand the physics engine and AI/player navigation/combat limitations of your engine’s
moving platforms. Allowing big AI fights on moving platforms is not a given by every engine.
• Otherwise, you can still keep “elevators” as “monster closets” (= AI spawn rooms) or secretly
teleport the player once the door is closed.

10.2.5.9 Rope Actions
• I am talking here about grappling hooks, repelling, or zip-lines.
• If they are not free-to-use, then all three are very contextual and often require a lot of careful
metrics considerations. Still, try to use them as much as possible because they change up the
“monotony” of just moving around.
• Grapples (free or restricted) are not only a means to get up or down, especially considering
the momentum when releasing from it. It gets even more exciting when the rope wraps around
vertical (sideways) or horizontal (upwards) objects.
• You can top it even further when combining with movement types like double jumps, gliding,
short teleports, or continuous grapple usage.

10.2.5.10 Long Falls
• Jumping down from great heights typically means two things: You navigate very fast down-
wards, and you likely die.
• Be very mindful if you seriously expect players to master long falls and survive, such as hitting small
pools of water, piles of hay, or big teddy bears because failing means likely a frustrating re-load.

10.2.5.11 Jump Pads
• Jump pads are gamy and arcadey, but they can be great fun for players and developers if it fits
your game. The explosion of speed, getting catapulted through a level, is quite exhilarating.
• I can only encourage pushing the boundaries of what is typically possible with jump pads
because they open up some quick connections on a horizontal and vertical plane, which other-
wise would be slow, long, and way duller.
• Be careful with too-long jumps because it might feel boring at one point. Test in-game what starts
feeling too long for you, and then cut another 25% of the flight time to get your maximum length.

10.2.5.12 Zero Gravity
• Handling large parts of zero gravity is not easy. It requires extremely good 3Cs and a lot of solid
features, or players quickly lose orientation and breakfast.
• The visual player leading is crucial to establish rotation and direction. Ideally, the whole room/space
visually has a clear start and end and other supporting elements, such as lines or lights, pointing
toward the exits. I recommend focusing more on player-leading than simply providing a sense of
up/down.
­
• Be careful with too large rooms because when players fly through the middle, they do not have
any close reference points to feel how fast/slow they fly.
• Be careful with too small rooms because it is more difficult to establish a clear sense of direc-
tion, especially after players perform a few quick spins.
130 A Practical Guide to Level Design

10.2.5.13 Wall Walking
• Players can comfortably walk on walls or only specific parts of the walls. A classic example is
walking on walls with magnetic boots in a zero gravity environment.
• Every new plane players walk on requires their own player-leading and player-orientation pass.
• Wall walking is a very complex and confusing experience for some players. Carefully establish
the connections between the different planes, especially when players switch planes or they
quickly lose the relationships between the completely different view-angles.
• Be especially incredibly mindful when players can freely walk on almost all walls instead of
selected paths/sections.
­

10.2.5.14 ­Wall Running
​­
• Typically, wall r unning is a great tool to commit players to a navigation section because they
can be a point of no-return.
• Experiment combining this feature with other verticality tools such as grapples, climbing
types, ladders, or any jumps/teleports your game has to offer.

10.2.5.15 Portals and Teleportation

• Pre-placed portals are a convenient and instant way to connect two parts of your level. However,
I would be careful using too many of them in your level, or it quickly becomes a messy experi-
ence because players quickly lose their orientation.
• If players have a short-distance teleportation or “blink” ability, then work closely with your QA/
QC department if you do not want players to break your level design! Players very likely will
put them to extreme use, especially in combination with potentially other navigation features.

10.3 Progression within a Mission

10.3.1 Introduction
Multiple experiences, for example, attacking, defending, or escort, are the basic building blocks of any
longer singleplayer mission or level. Some of such blocks have additional modifiers such as time limits,
limited weapons, or forced stealth. Planning the progression through the right mix of such blocks is key
to creating an entertaining mission experience. A bad mix will likely lead to a very monotonous or bor-
ing experience. Therefore, it is essential to set up the correct order based on the initial high-level pitch.
Ideally, you created the high-level pitch with a good mix of building blocks already in mind. Otherwise,
splitting up a mission into building blocks will deviate too. Mission blocks do not necessarily translate
to objectives one to one. Instead, mission blocks are core player experiences which can be split up into
multiple objectives ­in-game.
​­
This methodology only works for missions or levels with a minimum amount of complexity, length,
and often some narrative depth. Typically, such missions are at least 15 minutes long. If the entire mis-
sion only has one focus, for example, a race, quick assassination, or simple k ill-all, then you should, of
course, not apply it.

10.3.2 Basic Building Blocks and Objectives

10.3.2.1 Introduction
I’ll only cover here briefly the basic, classic building blocks of action games. Feel free to add or remove
building blocks depending on your game’s context. Each of the blocks I list here is the main one, followed
Connective Tissue 131

by a list of a few common subtypes. For example, you can split an attack-block into “kill all,” “destroy
five items,” or “kill boss NPC.”
Each block is typically between five to ten minutes long, depending on your game and mission needs.
As an exception, you could have longer ones, but after 15 minutes of average playtime, it starts to get
monotonous again, and I recommend you split and change it up again.
Another big advantage to split missions into such blocks is that the base script of each type can be
pre-created. Such template script groups can then get open or broken and become unique per individual
mission. Alternatively, they stay closed in the mission, just with unique inputs. The base script stays in a
central database, with enough modifiers to adjust for each mission’s needs, while a few crafty technical
developers (for example, technical level designers) maintain the library throughout production. It might
be a bit more limiting for some, but it allows for a way more consistent script quality and faster script
progress.

10.3.2.2 Attack
First of all, attack essentially means either “Kill” or “Destroy.” It is “Kill” if the targets are NPCs
such as humans, aliens, animals, or anything else which at least moves with some intelligence and
typically can fight back. “Destroy” covers the destruction of items, which are typically static and
non- organic. However, the items can, of course, still move around, for example, on a train or con-
veyor belt. The difference between “Kill” and “Destroy” is a narrative differentiation to give the
block more context.
Secondly, players either Kill/ Destroy “All,” or “a selected amount X.” Both of them can be limited to
a certain area and type, like “Kill All Blue AI in the Warehouse,” just “Destroy 10 evil Mushrooms” or
“Kill General Bauer.” Ideally, the area is somehow clearly marked, or if no area is required, it is clear
where to find the targets. The progression is either shown as a number or a bar if the numbers get too
high. Bars can, of course, also be used, for example, like a boss enemy’s health bar to motivate players
through progression.
One of the biggest problems of this block is to give AI a clear objective or goal. It is tricky to make AI
look smart with the primary goal just to stay alive. Defensive strategies like retreating, deploying turrets/
shields, or asking for reinforcements only work so far and are not always suitable.

10.3.2.3 Defend
The defend block is more passive and reactive compared to Attack. You either defend an area, keep
items/ NPCs alive, or essentially just survive as a player. The area-defend block can be one or multiple
ones, with or without the option to re-take them again and different types of timers involved to switch
the area’s ownership. Sometimes an interaction like a button press or putting up a flag is involved as well.
Domination or King of the Hill is classic multiplayer example of this objective, but they can fit well into
a singleplayer context.
Defending one or multiple items/ NPCs is another typical application of this block. Typically, the fewer
items/ NPCs you have, the higher the chance the design asks for a health bar instead of a frustrating one-
hit-fail criteria. A special variant of this subtype is the infamous escort objective, where one or multiple
NPCs have to reach a location alive. The basic escort types are either the one where the NPCs move by
themselves, the one where they move based on player actions (for example, players have to kill X enemies
ahead), and finally, where they follow players directly.
The one where players just have to defend themselves is essentially just basic survival. Typically, there
is a specific condition attached like a timer. The primary problem is that you need a sound AI system to
make searching AI work well because players just hiding in a corner for extended times is often not very
fun. Therefore, I would not necessarily recommend this version.
I like the defense block quite a lot because it gives AI a clear objective and makes them look smart.
Any time AI has to do something other than killing the players is typically a good thing, especially when
there is some type of tug-of-war associated with it.
132 A Practical Guide to Level Design

10.3.2.4 Interact
In its simplest form, the interact block is where players just have to interact with one or multiple
items/ NPCs and are done, for example, talking to NPCs, press a few buttons, or stand on a few plat-
forms. They might sound simple but can quickly become more challenging if threats exist, the NPCs run
away, or a puzzle is associated with it. Essentially the action itself is simple, but the HOW or WHERE to
interact is the key here. Interacting does not have to be always a simple press of a button, but can also be
connected to a skill challenge, for example, if players have to hit a small item to activate, like a rope for
the piano to drop. It could also be a Destroy block, but the more “puzzly” it is, the more I prefer to keep
it in the interact category.
Collecting is another variation, even if it is just walking over the items. Again, the lines get blurred if
players first have to kill enemies for the items to drop, but I recommend looking at the dominating player-
facing aspect. Collect objectives are often associated with a search component if the item’s location is
unclear, comparable to a puzzle.
Any interact blocks are typically very player-centric because it primarily focuses on player actions.
Any AI or other threats are simply said to be just a hindrance. It is rare that there is a competition with
AI without turning it into a defense block.
The interact block has the most exhaustive options due to its sheer huge amount of variations. You can
distill so many game objectives into the interact block, yet none of the objectives are incredibly similar
in execution.

10.3.2.5 Navigation
At its core, the Navigation block requires players to reach one or multiple target locations or areas or reach a
certain distance away from an entity. The locations, entities, or areas can dynamically change or even move
in case of, for example, a chase. However, the player challenge factor here typically comes from threats or
a puzzle. The puzzle variant can be to find the target spot or figure out the way to the location because the
path might be blocked or otherwise unreachable. Again, the HOW to reach the target or WHERE the target
is are the key aspects. The primary difference between a navigation and an interactive puzzle is the last
action players are required to do in order to complete it, and that gives them a different vibe. The navigation
vibe is often associated with the notion of “get out,” “get to,” “get away,” or “get through.”
Another huge factor for this block is distance and, with this comes potential vehicle usage. The ques-
tion is can players pick their vehicles freely, or are they tied to a specific one? Is one vehicle better than
the other, or maybe just one can do the job? Also, do they drive the vehicle themselves, or do they, for
example, just handle the mounted weapon? The more limited the choices, the more essential it is to
prevent the vehicle from blowing up, which often becomes one of the primary core design challenges.
Again, in such cases, it blurs the lines with defense blocks.
Typically, I recommend not using any “Go-To” objectives, except it is required for technical reasons
or by the mission system. Ideally, you give players the next objective at the target location right away and
let them figure out how to get there. Especially chaining up “Go-To” objectives can feel very demeaning
and redundant. However, they do have their place if the navigation is a challenge or a bigger experience
in itself, like a chase, running away from a horde of lemmings with rabies, or sitting behind the mounted
grenade launcher of a stolen get-away vehicle breaking out of a military base.

10.3.2.6 Narrative Blocks
Narrative blocks are an exception because they are often shorter than five minutes. However, I highlighted
them here separately because they are unique, require special attention, are crucial for pacing, and typically
include other departments. Classic examples are cutscenes, bigger in-game events, or NPC walk-and-talks.
I would not add every smaller narrative event here, just the big and major ones for the story; the same counts
for any narrative events that happen during gameplay. For example, a long drive with a lengthy radio call or
an NCP on the driver seat talking is still rather a navigation block instead of a narrative one. The walk-and-
talks are a bit special because they primarily exist for the player to listen to the NPC.
Connective Tissue 133

10.3.2.7 No Blocks
Quick reminder, I would not make a block out of everything just to create a seamless coverage of the
mission in your level design document. Minor transitions do not require a particular navigation block. I
recommend adding any smaller pieces to either the previous or next block and be good with it.

10.3.3 Modifiers
10.3.3.1 Introduction
Modifiers are an additional layer of complexity you can add to a mission building block to create more
variety between them, affect their difficulty, or make them narrative or world-building-wise more fit-
ting. In theory, you can stack as many modifiers as you want, but there is a reasonable limit case by case
before it gets silly. Also, some objectives require a mission block to have a modifier, or, for example, a
checkpoint race without a timer is not a checkpoint race.
Modifiers are especially great if you have to use the same building blocks with only minor variations
between them. In order to still create some exciting differences between them, you can investigate using
modifiers.

10.3.3.2 Time
Applying a time limit is one of the most classic modifiers. Essentially it puts time pressure on completing
an objective. The time pressure can come from a failure at the end of a timer, it has to happen at a specific
time, or the timer needs to finish for success. Classic examples are any checkpoint-races, disarming a
bomb before it explodes, completing a download, hitting the hostage taker when he raises the gun, or
reaching the antidote before the poison kills you. I recommend connecting the time pressure with a tan-
gible reason to cause death or absolute failure. For example, the arrival of reinforcement in five minutes
is not time pressure which should trigger an objective failure because players still have a chance to fight
and escape. Alternatively, you can apply “fake narrative time pressure,” where you stress out players by
giving them hints and messages about the impending threat or danger without instant failure when the
time runs out.

10.3.3.3 Forced Stealth and Stealth

Another classic modifier is forced stealth, which triggers an objective failure upon detection by the
player. However, I would be careful linking a complete failure to this objective in general, even if you
have a very stealth-centric game. Detection is often a very black&white experience, and you need very
well-tuned game mechanics to be exciting and fair for players. Instead, I generally suggest letting the
players deal with the consequences of their detection, even if it is a very harsh one.
However, if a mission block is instant failing on detection consider a slim chance of redemption. For
example, if a hostage taker still needs to run to the hostages to kill them, or someone has to run to an
alarm box to activate. In such cases, you still have a chance to take out whoever would then trigger the
actual mission failure.

10.3.3.4 Limited Tools
This modifier limits the tools players are allowed to complete an objective. It either reduced the action
to one specific item or group. Alternatively, it states which items or item types/categories you are not
allowed to use. Player-facing this can also force a certain playstyle if, for example, the objective requires
using a sniper rifle or bow and arrow. Common examples are killing an evil man with his own gun, not
being allowed to use explosives because the body should stay unharmed, or only using non-lethal force. It
is a good modifier to spice up otherwise simple action blocks. However, I would be careful not to overuse
it because players typically prefer to use their full earned arsenal.
134 A Practical Guide to Level Design

10.3.3.5 Specific Order
This modifier specifies the order in which to complete certain aspects of an objective. Some examples
are buttons that have to be pressed in a specific order, kill the family of evil gnomes starting with the
youngest, defend the shield pylons from the outer to the inner ones, or cut the wires in the correct order
to prevent the bomb from exploding. I recommend only using this modifier if the context is clearly justifi-
able and does not come across as arbitrary.

10.3.3.6 Other Modifiers
Below is a brief list of other, less often used modifiers.

• Distance: Adding a minimum or maximum distance required to complete an objective is an

occasional good way to spice up mission blocks. A few examples are sniping targets above a
certain distance, staying within a minimum distance to a fleeing target, or shadowing a VIP
without getting too close or far away.
• Speed: An objective has to be completed above, at, or below a certain movement speed. A few
examples are driving slow for the unstable chemicals not to explode, not getting caught by the
police for exceeding the speed limit or keeping a bus above a minimum speed to prevent a
bomb from exploding.
• Light: Sunlight or darkness has to take into consideration failing or succeeding an objective.
Some examples are defending a vampire, staying in the light because flesh-hungry demons lurk
in the shadows, handling some light-sensitive chemicals, or staying in the sunlight to prevent
instant depression.

10.3.4 How to Mix Them

10.3.4.1 Basics of a Good Mix
I believe that it is more complex than simply stating a good mission should be all about variety, like
always mixing attack, defend and interact blocks. First of all, it starts with the narrative premise of the
mission, which sets the initial mood or theme of the mission, but it does not have to stay like it for the
entire duration. Instead, I recommend breaking the initial player expectation of a mission to create drama
and excitement. It is a bit like starting to watch a movie, and you soon predict the rest of it. Some simple
twists and turns are always a good starting point.
For example, the mission asks for a hostage rescue, which makes the initial theme more sneaky and
calm. So, in this case, it would start with a forced-stealth-interact mission block to free the hostage ide-
ally undetected, or they would shoot him. Then you can add a defense block to protect the hostage till
the get-away vehicle arrives. Finally, the initial pick-up location is compromised and we have a wild ride
vehicle-block while you are behind the mounted gun while the hostage drives. It started stealthily and
gradually went more action with a nice progression.
Now, depending on the mission’s briefing, the example might not surprise players or break their expecta-
tions because it might have been the plan all along. So an alternative example could be that the freed hos-
tage turns against the player as the twist, and then we could follow up chasing the hostage through a hornet’s
nest ending with him giving up. Finally, we have a big shootout till your get-away car arrives gun blazing.
At the same time, the example could have stayed stealth-oriented by changing the defense block to a
stealth escort one and maybe even a driving sequence where the player drives but has to stay undetected
in traffic till they are far away.
A good piece of advice is to see your mission as a movie and how it could play out in an ideal scenario.
Think about turning it into an exciting movie to watch, with some interesting plots, twists, and memo-
rable moments. Of course, for example, turning an action movie about fast cars into mainly a soap opera
is not the kind of surprise most would enjoy. However, a few love scenes and relationship trouble will not
hurt just to break up the monotony. Also, the more freedom players have, the less likely they will follow
your ideal scenario, but it sets the foundation and potential.
Connective Tissue 135

Initial Example:
Interact Defend Navigation
Forced Stealth NPC Vehicle - Gunner Position

Example Variation #1: Bigger Surprise

Interact Navigation Defend
Forced Stealth Chase NPC NPC

Example Variation #2: More Stealth

Interact Defend Navigation
Forced Stealth Escort - Forced Stealth Vehicle - Forced Stealth

Example Variation #3: Reverse Order

Navigation Defend Defend
Vehicle - Gunner Position NPC Escort - Forced Stealth

­FIGURE 10.2 A three-mission-block

­ ­​­­ ​­ level and three alternative variants.

I will cover pacing in the next bigger chapter, but it is already important to note that not every mission
has to end loud and action-oriented. Sure, it leans toward a high intense ending, but there are many other
options to establish an increasing intensity and end with a highlight. Let us take the previous example
and see how we can start with an explosive vehicle entry, then a defense, and end with a stealth-interact
block. We could start with initially freeing a VIP from a heavily guarded prison truck with an NPC
buddy driving and you controlling the mounted gun. Then we must defend our NPC buddy till he man-
aged to weld open the prison truck’s door. Of course, something goes wrong, and we then have to escape
on foot while the buddy carries the unconscious VIP. The only escape route is through a dense forest at
night, swarming with cops and corrections officers. If we do not sneak or take out enemies undetected,
they quickly kill your slow/unarmed buddy and VIP. This intense cat & mouse game, breaking through
the enemy lines chased by dogs, finally ends by reaching the door to a safe-house. Of course, the initial
car chase/attack is likely quite intense, but I hope the example showed that you could end up with an
intense sneaky ending by pulling the right levers. Also, that now the last block is rather defense than
interact is more semantics, but you still “interact” by reaching the safe-house.

10.3.4.2 Monotonous Block Usage

It is not always possible to add up a nice variety of blocks and add some twists to break up player expec-
tations or even to surprise them. For various reasons, it can be that a mission, for example, is dominated
by attack or interact blocks. First of all, the good news is that the blocks allow for much variety in them-
selves already. Secondly, applying one or multiple modifiers is the next obvious option. Otherwise, the
same goals to break expectations and add surprises remain.
For example, we have a mission where the players have to take over a village. Instead of apply-
ing some interesting blocks with variety, I make it purposely monotonous and then see how we can
improve it. We start with a kill-all-block of all enemies in the village, followed by three more kill-
all-blocks to take out three troop reinforcement waves. Without changing the attack blocks to another
type, I could start with first a k ill-VIP-block to take out the commanding officer, who would flee upon
detection, adding a bit of a stealth incentive or even a systemic chase. Up next, we do not change much
and still keep the kill-all-block of the enemies in the village; we have to clean it somehow. However,
I could add the modifier only to take them out non-lethally because the regular troops do not deserve
to die for later diplomatic talks. An alarm mechanic or time modifier could also work here in a stretch
to potentially affect future reinforcements. The first reinforcement wave is a fanatic special forces
recon platoon consisting of primary snipers and sneaky and fast guys. This very long-range and fast
136 A Practical Guide to Level Design

Initial (Bad) Example:

Attack Attack Attack Attack
Kill All Kill All Kill All Kill All

Improved Example (still staying with only Attack blocks):

Attack Attack Attack Destroy
Kill 1 VIP Kill All - Non-Lethal Kill All - Special 4 Tanks
Forces

­FIGURE 10.3 First, a very repetitive four-mission-block level, with then an improved alternative.

focus certainly switches it up for the player, especially if he initially feels like the hunted. Finally,
we send in some tanks as reinforcement, switching to a destroy-tank block which requires players to
change playstyle drastically compared to just killing regular troops. A big tank battle also acts as a
nice explosive ending.
Sure, I played a lot with changing enemy archetype composition to give them a clear/clean focus, and
the VIP-kill block could also be an optional one. However, it succeeded in breaking up the monotony
without changing any attack-block to another type. In reality, I would try to change one or two to a
defense block or another type, but that was not the point of this example.
However, missions with primarily monotonous blocks have their place. One reason could be the
game’s dominating theme or the lack of production resources to create enough variety. There is only so
much pure level design can do in such cases, except maybe some custom scripting. Another reason is to
add monotonous blocks to the overall mission mix purposely. The irony is that always having well-mixed
missions with surprises and twists can be monotonous as well. Sometimes some predictability can be
refreshing and give the true twists more weight. Therefore having a few missions in between with a very
dominating block type can break that pattern.

10.4 About Pacing and Timing

10.4.1 Introduction
The pacing defines the intensity of the player’s experience at any time during the mission or level.
Planning out a good pace is essential for level designers to avoid, for example, classic mistakes like a
long boring middle part, players getting tired of too much, non-stop high intensity, or the highlight of
a level is more at the beginning than the end. It can also help balance out gameplay with narrative or
singleplayer with coop experiences.
The origin for pacing comes from story writing, where pacing determines how fast or slow the viewer
gains narrative information or how fast/intense the plot is moving forward. The classic example is from
the three-act structure. Act one exposes the viewer to the overall situation, sparks the protagonist’s
adventure, and ends lower in intensity when the protagonist makes their first bigger decision moving
forward. In act two, we have the bulk of the story with the rising action, leading to a big confrontation
that goes wrong. Then again, pacing drops again, reflecting on or dealing with what went wrong. Finally,
in act three, we start with some doubt to ensure that the final climax is even more impressive. We close
with the aftermath, which is usually also a lot slower-paced again.
This book is not about narrative, but I highly recommend reading up on the three-act narrative
structure or similar models if you are interested in such topics. There is certainly an advantage for
level designers to have basic narrative knowledge. You will find other different-looking graphs, but
that is the variant I prefer to bridge to pacing within level design. I hope you will see the similarities,
but in an interactive medium driven primarily by gameplay, I am replacing “ the speed of narrative”
with “gameplay intensity.” Essentially a non-scientific measure of the player’s heart rate or sweaty
hands.
Connective Tissue 137

Intensity
Act 1 Act 2 Act 3
Climax

Midpoint

Inciting Incident

Time

­FIGURE 10.4 It shows a classical pacing graph, which is often used in narrative forms.

I recommend working with a pacing graph for any bigger mission, which requires some more detailed
planning. As I said, it is not something highly scientific, it is very subjective, and not every player will
have the same experience. However, it gives safety and sets expectations for the level designer about
the journey through the level. For example, early on, they might spot issues of not enough “breathing”
points, clearly set the pacing expectations for any major moments before the finale, or spot that the high-
light might not be as impressive as initially intended. Also, a good-looking pacing graph always looks
good in level design presentations and shows your confidence in the design.

10.4.2 The Beat and Intensity

10.4.2.1 Introduction
The beat is the smallest element I would compartmentalize a player experience in a level or mission.
A new beat starts whenever the intensity changes, by either going up or down. Each beat has a certain
length. I recommend seconds because it gives you more flexibility. You can still easily calculate minutes
out of seconds but working with, for example, “6.75 minutes” can be odd.
Therefore, a beat is defined by its intensity and length of time. The time is another guesstimate but
should be close to the time you want an average player to spend here, close to the golden path or maybe a
tick slower. Then the pacing graph shows the rising and lowering intensity curve over the different beats.

10.4.2.2 Intensity Estimation
The recommended maximum intensity is ten, which should be your absolute highlight of the mission. I
do not recommend comparing the intensity between missions. Keep it simple and look at each mission
individually. The lowest intensity is zero, and that is when the mission loads and ends. Otherwise, even
the most boring walking beat has an intensity of one. Now since we know the maximums and mini-
mums, the remaining intensity levels are about gut feeling. However, remember we are still in the plan-
ning phase. Therefore, your intensity levels are about your intentions to make sure you have enough low
points as a breather and that none of the previous beats are putting the highlight to shame.
Another important consideration is that difficulty does not directly link to intensity. I know that might
be confusing because, of course, a difficult section is more intense. However, other aspects raise inten-
sity, for example:

• Speed (even without extreme difficulty)

• Narrative closure (finally catch that bad guy)
• A lot of not so dangerous and near-miss explosions
138 A Practical Guide to Level Design

­TABLE 10.1
Various Situations and Their Associated, Suggested Intensity Ranging from 0 to 10
Situation Intensity
Loading screen 0

Very simple navigation without anything interesting happening or to look at 1

Simple navigation with something interesting (art or narrative, etc.) to look at 2

Mild navigational challenge or something very interesting to look at (small vista reveal, small in-game even, etc.) 3

Very small or very easy firefight / skirmish 4

Easy firefight, difficult navigational challenge, or something stunning to look at (bigger vista, medium in-game 5
event, etc.)

Medium firefight, very difficult navigational challenge, or something incredibly stunning to look at (massive 6
vista, big in-game event, etc.)

Challenging firefight or very difficult navigational challenge with an extra component (explosions, time 7
pressure, etc.)

Very challenging firefight, it starts to get intense but remains conservative (= no severe extra components) 8

High intense firefight with an extra intense extra component (extra navigational factor, limited cover, time 9
pressure, lots of explosions, difficult AI archetypes, or mix, etc.)

High intense firefight with an extra intense extra component (extra navigational factor, limited cover, time 10
pressure, lots of explosions, difficult AI archetypes, or mix, etc.)

• Running through a burning house (without extreme difficulty)

• For some people, lots of spiders
• Really cool loud heart-pumping music.

10.4.3 The Pacing Graph

10.4.3.1 Introduction
The pacing graph is the visual representation of your mission’s intensity. Typically, it is an initial inten-
tion and not something clearly measurable. The height (x) of the graph represents intensity, while the
length (y) represents time. The graph is split into all the individual beats of the mission with their heights
and length of time. Drawing a curve between the top-middle points of each beat is the pacing graph.

10.4.3.2 Basic Rules
The ideal way to work with a pacing graph is to work with Microsoft Excel or a similar program where
changing table entries right away affects the curve. Below I list the basic rules, what you want the pacing
graph to look like and what to avoid.

• Each level typically should only have one highlight with one beat at intensity ten. Ideally, the
last high-beat is the highlight and the memorable moment. If it is different, then expect the level
to feel anticlimactic.
Connective Tissue 139

Intensity

Time
Intensity

Time

­FIGURE 10.5 Top Graph (good): Occasional breaks, beats, and higher blocks raise gradually, clear highlight at the end.
Bottom Graph (bad): No clear breaks, highlight is in the middle of the mission, way too steep raise at the beginning of the
mission, and the last two beats have equal intensity.

• You can combine more than one higher beat, for example, three beats with an intensity of six,
seven, and nine. However, I do not recommend such blocks to be longer than ten minutes, fif-
teen at most, before you have a lower intensity beat as a break. Otherwise, you likely tire out
many players, and they might not feel an intensity increase anymore that drastic.
• Any intense beats or blocks should ideally go up gradually toward the final highlight. It does
not have to be crazy strict, but I recommend overall growth of the higher points.
• The intensity breaks are crucial every five to fifteen minutes. They allow players to have a
breather, and without them, the next intensity spike will not feel as powerful. For example, if
you would have a continuous increase, then the rise from six to eight is barely noticeable, but
if you have a drop-down to a two in between then, there is a noticeable spike. Without breaks,
players not only get exhausted, but they also become callous and indifferent for any highlights.
• The height of the breaks does not have to increase gradually, but in order to be a break, it cer-
tainly should be around one to three and at least 30 seconds long.
• Two following beats should never have the same intensity because by the core definition a new
beat is a change in intensity.

Arguably you could have two connected beats with the same intensity because you change the mis-
sion block. However, I would recommend seriously considering changing the intensity between the two
blocks because otherwise, it might be dull. It is just a lazy design if you cannot find anything that changes
the player’s experience.
The background coloration of the beats according to their mission block color is optional, but it can
help show good or bad patterns. However, remember that you can cut a mission block into multiple beats
like multiple defense waves, and the small little break-beats in between are not mission blocks either.
So, I am just using the colors without a strict mission-block analogy. Also, keep in mind that there is no
direct correlation between objectives and beats. An objective can have multiple beats if, for example, a
defense has increasingly difficult waves.
After all, the pacing is not a very strict science since it largely shows just an intention and cannot be
precisely measured. I bet there are great levels with a very bad-looking pacing graph. Therefore, I recom-
mend using it, especially for more linear experiences, to set expectations and not be too stifling. It might
140 A Practical Guide to Level Design

A B C D E F G H I
1 Beat 0 Beat 1 Beat 2 Beat 3 Beat 4 Beat 5 Beat 6 Beat 7
2 Mid Time 0 5 160 325 445 610 835 1010
3 Pacing A 0 2 5 1 6 7 8 2
4 Pacing B 0 6 1 6 2 2 1 7
5 Time (sec) 0 10 300 30 210 120 330 20
6 Total Time 0 10 310 340 550 670 1000 1020

­FIGURE 10.6 Yellow Fields: Level Designer fills out those cells. Blue Fields: Those cells get calculated.

Intensity

Time

FIGURE 10.7 If everything worked out fine your graph should look similar to the one above.

even be helpful for some level designers or directors to create them for very open missions planning the
golden path— even if it is just a whiteboard sketch.

10.4.3.3 How to Create a Pacing Graph Using Excel

The easiest way to work with a pacing graph is to use Microsoft Excel or similar programs. Below I
describe a quick way how to create such a graph for two pacing graphs using Excel.

1. Create a table where the columns are the individual beats, starting with an empty beat zero (all
numbers zero here for a nicer looking graph), then your first beat of the mission, till your final beat.
2. The first-row call “Mid time,” second row “Pacing A” (your first pacing graph, like “Gameplay
pacing”), third-row “Pacing B” (whatever your second pacing graph should be, see further
below), fourth-row
­ ​­ “Time,”
­ and last ­sixth-row
​­ “Total
­ time.”
3. Start filling in the two pacing rows and the one “Time” row. We will calculate the other ones.
4. Calculate the “Total time,” which takes the previous total time and adds the current time, for
example, D6 = C6 + D5.
5. Calculate the “Mid time,” which is the middle time of the current beat within the context of
total time. Otherwise, the graph will show the intensity at the end of the time and not in the
middle. The total time context is important to show a continuous graph. It is the previous beat’s
total time plus half the current beat’s time, for example, D2 = C6 + D5/2. ­

Ideally, if you change the timing and intensity, the pacing graph should change accordingly. You see that
longer beats take more space while, for example, a short break is just a quick dip.
Connective Tissue 141

If you add or remove beats, you might have to adjust the graph’s data or make a new one quickly. If you
are fancy, you could add a new graph (“Stacked Column” rotated by 90°) behind the current one showing
just the individual time to highlight the beats. However, that can quickly get finicky.

10.4.4 Alternative Pacing
10.4.4.1 Introduction
The beautiful aspect of pacing graphs is that you can display more than one graph in the same graphic
showcasing even more information and to showcase their relationship. It is also a great tool to communi-
cate different intentions or spot issues in more than just gameplay intensity.
The two types of additional graphs I’m most used to are for narrative and coop. Based on your game,
you might come up with your own pacing graph types, but I recommend not having too many graphs in
one graphic and not going too granular; otherwise, it is less helpful and just an exercise for the sake of
an exercise.
Usually, I do not see a reason for any additional graphs to follow similar strict rules like the gameplay
intensity graph. For example, a narrative graph will always start pretty high if the level starts with a cool
cinematic.

10.4.4.2 Narrative Graph
The narrative graph shows where you transmit more or fewer amounts of narrative to the players.
That can include anything ranging from cinematics over radio dialogs to environmental storytelling.
It is ideal because it communicates clearly when the narrative has more space and opportunity and
where less. Typically, it would be best not to trigger relevant radio messages in very heated gameplay
beats but instead use the break in between. However, you could sprinkle some lower narrative-dense
environmental storytelling in some more intense scenes. Looking at your graph narrative design might
claim early on that they need more or less time to bring their narrative across. It might also tell them
that they only have two or three bigger moments for radio dialogs or cinematics, and otherwise, it
is just environmental storytelling. Expectations can go both ways. Sure, we are still in the realm of
guesstimates, but it is better to sort it out now and set base expectations than make adjustments later
in production.

10.4.4.3 Coop Graph
The coop graph shows where the players have to work more together and where they usually act more
individually. For example, they commonly act more as one unit in a smaller space than in a wide space
with many flanking opportunities. Other examples are strict purpose-built coop-sections or where play-
ers work individually without relying much on each other. Especially for coop-centric games, it can
highlight if you have long segments without any coop-centric gameplay or too much after each other.

Intensity

Time

­FIGURE 10.8 Blue Graph: Gameplay intensity. Red Graph: Narrative density.
142 A Practical Guide to Level Design

Intensity

Time

­FIGURE 10.9 Blue Graph: Gameplay intensity. Red Graph: Coop density.