Level Design In Pursuit of Better LevelsTable of Contents Planning Concept process # © Metrics & Prototyping & Blockout ¢ 2 Structural geometry 2 Form follows function 2 The Backdrop % #8 Check the scale 2 Empty space % 28 Testing the level #8 Documentation & important questions ‘2 lleration & playtesting * ‘@Navigation & distinction ® Perception @ Readability # Orientation © Landmarks 2 Signposting *# Vantage point # Guidance ‘# Overestimating guidance & # Attention & saliency *# Visual language ‘#8 Nope zone 8 Guiding with Al # Alas visual & audio language & ‘2 Breadcrumbs ® ‘2 Teasing 2 Prospect & refuge ® # Contrasting paths Pacing 4 Pacing tools & tricks @ #8 Flow in Singleplayer ‘2 Gates & Valves & ‘Loops * 2 Recycling levels Planning & structure @ 2 Intensity, variety & time 38 2 Beats, charts & timelines one 1" " 2 2 8 4 4 5 15 15 19 26 26 30 34 32 32 37 40 a 42 43 46 47 49 50 50 50 51 52 aee2g#8 Non-linear pacing ‘@Enhancing the experience Choices & Enhancing with audio & visuals % Color, lighting & mood © Narratives & Emotions Spicing it up 28 Wow moments * ‘2 Reactivity 28 #8 Exploration ‘Designing for combat © Vantage point & ‘@ Combat Spaces # #8 Combat fronts # Flanking Cover ¢ ‘® Cover placement ® @ Enemies & encounters @ ‘Enemies & cover ‘® Spawning & tracking enemies % + Encounter design # Allied NPCs 4 Line of Sight for SP & MP & ©Muttiplayer map design © @ Overview + Readability Level structure 2 The Circle ‘2 Figure 8 # Clash points & Double Clash & 2 Tug of War & Defence ® Balance ‘28 Symmetry & Asymmetry & RTime ® ‘2 Spawn points & # Potential Player Positions (PPP) # + Flow ‘@ Briefly on accessibility 57 59 59 62 66 68 69 69 70 n 72 72 73 76 78 79 83 85 85 86 90 92 93 7 97 99 101 101 102 103 106 107 109 112 14 14 115 "7 124Foreword > The goal of this write-up was to collect less commonly found knowledge from veteran game developers as well as other relevant information, Occasionally | will also provide my own ‘suggestions and observations where its relevant.But I don't want to take any credit for the knowledge contained in this document, | merely collected it. While | stand behind everything in this document as good guidelines to follow, its up to you to decide if and when to apply it or not. If you feel anything contained in this document is wrong or you have any questions, feel free to contact me on twitter @TychoBolt Alex KPlanning > Good planning at the beginning (and during) a project can save both you and your team a lot of headache. In this section | will go over some tips that can help make the level creation process go more smoothly, > Concept process <> The first thing you should do is to nail down the Restrictions, Goals and Context of your level. ‘* Restrictions: Things you have to do, Often not decided by the level designer. > For example: Introduce and teach a new mechanic (item). Can't take place on Earth. Needs to introduce and use a new enemy type throughout the level. Needs to meet up with friendly NPC at the end of the level. * Goals: Things you want to do. This could be a levels Theme, Challenges or the like. > For example: Lots of verticality and should create a sense of acrophobia (fear of heights. Alternative routes. Platforming. © Context: Things you need to consider. > For example: 7th level in the game that roughly takes place during the midpoint. There are already X and ¥ type of levels planned, how will your level be unique. The reasons for this are: + It creates a starting point so you avoid the “blank canvas” problem. You'll reduce the risk of having to rework your level part-way to make your level work. + Ithelps you create structure and focus from the beginning, + It helps the rest of your team plan their work around your level more effectively. ‘Then it usually helps to create a flowchart or timeline so you can nail down when certain things should take place. ‘Some things will probably logically or have to take place in a certain order, while some things are more fluid. For example, if an NPC is supposed to give you a mission briefing it doesn't, make sense for the player to meet them at the end of the mission.After you've nailed this down, some good questions to ask yourself ars * Where does the level take place? >A forest? A ghost town? In France? When does the level take place? > Noon? At night? After a big battle? What are the mechanics of the game? > The level should facilitate the gameplay the game has, so make sure you understand and stay up to date on them. Making a level in a vacuum and then trying to shoehorn in the game’s mechanics is generally not a good approach. Why will players remember your level? > What sets your level apart? What are the highlights that will leave an impact on the player? Does the location fit the gameplay? > Ifthe level is focused on long-ranged sniper combat then having it take place indoors with tight corridors is probably not ideal. What is the “story” of the location? > What kind of place is it? What happened there? Who or what lives there? The things that makes your level fee! more believable and alive. What will I need to communicate to my team? > Is there anything you would need to communicate with your programmers, artists or sound department, etc, about? What do you need to know so your artists can ‘make the level pretty and what do they need to understand so the gameplay experience remains intact? Is your level possible? > Can the lovel be made in terms of the engine, timo, asset creation, etc? Can you and your team actually make the level? Critical & Golden paths Critical path = The quickest and most direct route to beating the level. Golden path = The designers ‘prefered’ route. It's the one you expect most players to take and the one which will offer the optimal experience, Don't forget to predict and plan for these early so your level flows well and makes sense. But also don't forget to test out your level by following neither of these paths.> Metrics < Nailing down all the relevant measurements and documenting them (and later updating them when necessary) is a very important step. ‘* Itallows you to test and figure out the proper values in a quick and dirty setup. ‘¢ Ithelps you (and your fellow level designers) ensure that things like cover, platforming jumps and the like are always correct from the beginning. Meaning you won't for example accidentally create impossible jumps forcing you (and potentially artists) to re-do parts of the level. ‘¢ If for example an environment artist comes in to replace your placeholder assets it allows them to be better aware of what metrics are important for gameplay. Usually i's a good idea to collect all of these metrics inside of a ‘playground’ level often called a “Gym” (see image below for example). ‘The Gym is where you place boxes and measure out these metrics so they can be tested and serve as reference during development. While not necessary, it's a good idea to create either meshes with these fixed metrics or dynamic tools that can act as ‘rulers’ (way more flexible). Said tools should be dynamically updated with their measurements and data to make the process of using them quick and easy for everyone on the team. Below are example tools made in Unreal Engine 4. Ruler Useful for dynamically measuring distance.BoxiFrame Useful for measuring windows, door frames, cover boxes, otc. Sphere Useful to quickly measure nearest distances, AoE, etc. Can be very handy to ensure your cover is spaced properly, ideal weapon ranges and so on. Notes Notes to help you remember or to communicate important things to the rest of your team, “Don't move these boxes", “Add explosion VFX here once it's created by artist’, etc. Spline/Path Useful to measure total distance along less linear paths. Can be especially handy in Teel Multiplayer level design to ensure that each teams side of eee) ad the level are balanced, ‘So what kind of metries should you have? Obviously it heavily depends on what kind of ‘game you're making, but below are some examples: World ‘¢Hallway/Room width & height (roughly 2.7 meters to 3.6 meters can be good) © Stair scale ¢ Window & Door sizes ‘© Various Cover sizes (low, high, etc.) ‘* Minimum distance between Cover (roughly 2-3 meters) ‘¢ Main (roughly 5 meters in width) and Side paths (roughly 3 meters in width) Player, movement & other characters ‘* Character dimensions (in different positions like standing, prone, crouching, etc.) ‘* Jump height and distance (when standing, running, etc.) «Maximum step height (what characters can just walk across)* Max slope degree (before the characters start to slide or can't walk on the surface) ‘* Max fall distance (before taking damage or dying) tems & abilities ‘* Weapon & ability (effective) ranges ‘© Combat engagement distance © Grenade throw distance ET) eee eee Example of how you can check combat engagement, weapon range, etc. using metric tools. This can allow you to get a feel for where combat should take place and the lke. iso don't forget to document more unique cases that can stil be relevant, like how far a player can throw a grenade if they use a jump pad and double jump, ifit could for example affect the balance of one of your levels. Likewise, don't forget that you might need to document various metrics for your Al characters (cover distances, navmesh, jump height, etc) so they can properly function in your level ‘Additionally, something that is important to keep in mind is that you often can't apply real world proportions to common things like doors, windows or even ceilings. It can very easily look and feel cramped. You also have to consider how the camera will function (3rd person games tend to require greater ceiling height) in the environment. cight.240 Door on the right uses close to real world scale, while the door on the left is scaled up.> Prototyping & Blockout <> ‘So now that you've got a general idea of what you want to do with the level, you've got (at least some) of the metrics down and you're a bit more familiar with the basic mechanics of the game its time to start making our level The eagerness to just jump into the engine and start blocking out a level can often be felt at this stage. While tempting, its typically a good idea to plan the level out a bit more and map it out beforehand, Everyone's process is different, but the one I'm going to describe is one I feel should work for most people. 4.Create a bubble diagram or flowchart Basically, think of all the rooms/areas in your level, place them into ‘bubbles’ and connect them in the way they'll be connected in the level The goal here is to get a sense for what areas your level will have, how they connect ‘and how the player will flow through the ei level r) Here you could also loosely plan events like when the player meets an NPC, fights ‘enemies or where they can find a key. 2.Draw up a map (not final) that roughly covers your entire level The idea is to create a more detailed version of the bubble diagram that gives a more accurate image of how the entire level will ook and connect. Planned combat encounters, platforming sections, etc. should be fleshed out a bit and you should indicate roughly how many enemies and the like each room will have. Here you can also write down some notes like “The player will ight 1 wave of enemies and a turret, then 1 wave when the player has the turret’3.Jump into the engine and place big blocks and meshes to get a sense of space The keywords here are “quick" and “dirty” This is not supposed to be pretty, final or even something you will re-use. While it doesn't have to be exact, try and stick to the rough scale you had in your map ‘as well as any metrics you already have. This is to get a quick sense for how your level would roughly look in-engine so you can more easily visualize it, spot potential issues and get a sense for the scale of the level. 4.Go back to your map, make adjustments and make it more accurate Make adjustments to the map based of the observations made in step 3. Try and make it more accurate and to scale. Its important to not that this is not the “final” version of your map, just a solid starting point. This is also the point where you can more easily communicate and get feedback ‘from your team with said map (and rough level from step 3) 5.Start blocking out the level using your map you drew up as a starting point This is the point where the cycle of blocking out your, level, testing it and iterating on it starts. ‘A'so try and get feedback early and often on your, level Don't wait until you feel you've gotten it really ‘polished’ before receiving feedback, otherwise you ight end up having to rework large portions of your level which could've been avoided with early feedback. 10° Structural geometry % ‘So now that you've started blocking out your level, the first step would be to just place out any of the larger more rigid surfaces and structural geometry your level has. This means any buildings, caves, mountains, pits, etc. and not things lke cars, benches or other non-rigid objects (often called “props'). This is because at first you just want to get the backbone of your level created, the thing that is less likely to change or move around than something like a car or a “decal” = —— = 'Non-rigid “Props” on the left, rigid structural geometry on the right. * Form follows function ** While we'll go into this in more detail in a later chapter, i's important to also consider how “form follows function” at this stage. That things in your level contextually makes sense. ‘A diner obviously has a bathroom, pipe systems shouldn't connect to nowhere and most buildings don't consist of a bunch of hallways. How did these giant boxes get into this room with such a tiny door? "o The Backdrop *° ‘As you're blocking out your level, also consider what the backdrop (non-playable area) will look like, While an intricate and beautiful backdrop can have great impact on the players experience, it will also be more ‘expensive’ in terms of performance and workload for your team. So while indoor environments will generally be ‘cheaper’, things like windows or ifthe player travels outside of the building it would most likely demand extra work and performance. ° Cheek the scale % ‘As you're blocking things out, remember to also keep an eye on the scale of your level Just looking at it or walking around in first person can be deceiving without objects to help us give a sense of the scale of the world, ‘You don't want to end up spending a lot of time creating an area that is either too small or too big for the requirements of your level. Improper scaling can look very weird (feeling like “something is off") and hamper the believabilty of your level. ‘Notice how in the image on the left we don’t get a good understanding of the scale of the environment? ‘Meanwhile on the right when we place a character reference in the scene we notice i's quite large! 12You might end up creating a space that might not work once you start placing tables, cover, etc. in them, resulting in you having to rework your level needlessly. This also applies to re-using assets, but scaling them differently. Especially in close proximity and if said assets are more distinct The player will get used to assets being a certain scale and when their perceived scale of an object is off, their mind will notice it. ‘Some examples of how scale can make things look a bit strange. (On the other hand, scale can intentionally be used to give a more surreal feeling, In the game Dusk the player enters a door an ‘emerges from a hole finding themselves having been shrunk to the size of a mouse! “¢ Dusk (2078) “® Empty space * Even if you don't have any particular design intention for a specific space, i's worthwhile to stil place out some props just to check how it looks once it’s “furnished’ For example, imagine you designed a cafeteria space that the player is just supposed to move through. Then imagine if the space isn't big enough for the environment artist on your team to create a properly looking cafeteria once you're done with your level. ‘Try and minimize the risk of either you or someone on your team having to re-do their work or having a tough time when it can be prevented. Just placing out some simple props can help you see if the space will work once i's “Turnished”. 13,°: Testing the level * ‘Once you get further along in your level there will eventually come a point where you need to test it with the new systems, Al, etc. that's created by your team, For Al this could be how your Al partner moves in the environment and if they can performs actions like boosting the player over a ledge and the like, For enemies this can involve checking so they use cover properly, if during a stealth ‘segment they can detect the player properly (not hear or see them when they shouldn't), being able to open doors, ete. Basically anything the Al would need to do in your level should be tested. Testing so the camera behaves properly in your level Is also a good idea, especially ifit's a non-first-person camera. Don't assume anything works 100%. This is not you ‘expecting’ your team to screw up or anything. I's to help them and the rest of your team's minds be put at ease, as well as, avoiding someone having to fix tons of stuf later when they might be busy with other stuff, Finally, try and set up a system so you can more easily test your level. If you have to replay 20 minute section every time you want to check a 1 minute long segment or there isn't a way to easily test your level in a later build (with a level select or the like) you will lose a lot of time. ° Documentation & important questions *° Remember to document everything that's important about your level. This is so both you and your team is aware of and can read up on everything that's important about your level. This could be goals, interactable objects, events, a summary of a playthrough of the level, puzzles, secrets, where narrative will happen, etc. Creating asset lists for materials, VFX, sounds, meshes, etc. as well as potential performance related information is also a good idea to document. ‘The documentation step is important since it allows you to scope your level properly and to reduce the risk of potential problems arising during development. So spend a little extra time on it to make sure it has the information that's required. But also don't forget to ask your team important questions that can affect your level. Things like how will the checkpoint & save system work? How and when will control (if ever) be removed from the player? How will achievements be implemented? How will modular assets work? Ete 14% Iteration & playtesting * Playtest early and offen. It's easy for you to become blind to the problems in your level. Playlests should drive the iteration, not the other way around. It's easy to get into the mindset of "Just wanting to polish it a little bit more before a playtest”, Playtesting is to lear what you need to change. The later and less frequently you playtest, the more expensive the needed changes could become. Playtesting is a science in and of itself, but what is important to remember is that the negative feedback is by far the most important Several playtesters might comment on the nice composition, but then two (or even just one) playtester comments on difficult jumps. Do not embrace the praise of the composition and the idea that "Well these other playtesters didn't complain about the jumps so it's not a problem’ From the psychology (cognitive biases) of the playtesters (and yourself) to just the small sample size, there are tons of factors that can muddy your feedback. So any potential problems that arise needs to be examined and potentially addressed. Navigation & distinction This section focuses on ways we can guide the player and to make levels more readable. Since a lot of these topics are connected, some of it can end up overlapping. So while they should all be used together, they're broken up to make it more organized. “Distinction” is basically how you make something noticeable to players. How to increase readability, player awareness and how to make players see what you want them to see. > Perception < While humans have good depth perception and sense of scale, it doesn't directly translate 1:1 when it comes to games. There are a number of reasons for this, but for the sake of brevity I'll try and condense it (but recommend reading up on it if this interests you). ‘The reason why this is important to know is because if the player doesn't get a good sense for scale and depth it can result in missed jumps, confusion, etc. 15‘A gag from “Top Secret!” (1984) that showcases how perception and scale can play tricks on us. The easiest way I can think of to explain why this is harder to gauge in a movie or a game is with an image (see below). In the real world you're looking directly at an object with both eyes using your own position in the world as reference, Ina. game you're looking at a screen that shows you its view of an object with the camera having its own position in the game world. This is in addition to the game possibly lacking cues otherwise present in the real world (because it's artificial). lf the game uses a camera detached from the player avatar (i.e. 3rd person) then that can make it even more difficult to gauge if for example your avatar can make a jump or not. This is for example why its easier to visually measure distance in a 2D platformer than in 3D. You're gauging horizontal distance, not depth, in a 2D platformer. Pa ee Identical distances, but different perspectives. Notice how i's easier fo gauge the distance in the 2D view because you're not measuring depth. 16‘Another issue players can encounter is when it comes to hallways/paths that turn. ‘Notice how in the image on the left it's difficult to tel thatthe hallway turns to the right at the end. ‘So how can we minimize these issues? Giving the player depth cues and reference so they can more easily calculate the distance and notice openings is a good approach. Placing objects the player knows the size of (like the football in the image) and then having it placed further away can help give them a rough idea of the distance. But placing something that stretches out more linearly (doesn't have to be in a straight line), preferably with consistent repeating elements, is a pretty effective way of helping the player gauge depth Just be careful when it comes to using objects that don't have fixed sizes in the player's mind. Even though they might've seen it before, it can be hard to tell how large a tree is in the distance. Is it a smal/young tree or is it a big tree just very far away? This is especially true if you or your team also scale the trees differently {or visual variation. A football on the other hand has a known size for the player, so there's, less risk of confusion for the player. 7Another way is to make use of the parallax effect. This is when things close to you appear to be moving faster and things further away from you appear to move slower. You basically break down your environment in foreground, midground and background ‘elements for the player when depth perception is more important (or you just want to ‘communicate depth). [Background od [esaroume | atmost si) Foregroun * slow) — This can also be done by simply using things like pillars, railings, boxes, vehicles, etc. in a room. Try and space things out so there are identifiable foreground, midground and background elements. Here we can see the railing in the foreground, the wagon in the midground and the truck in the ‘background. As the player would move these things would ‘move' at different speeds. Here we can also see how we use the pillars on the left and the railing to also help with depth perception. 18But what about the hallway? What it boils down to is basically just giving hints of that the hallway continues (or any other path that initially doesn't indicate that it continues). ‘Some examples ‘An object the player knows isn't visually complete (like the upper half of a corpse). ‘An element the player can visually see or assume continues (like a rug or a pipe). Revealing a small part of the area the turn in the path leads to (like the next room). A lightsource from around the comer, possibly even projecting a silhouette of something (Ike a person). a In addition, being aware of your established metrics can help as well. Ifthe player can jump a 3 meter distance, then placing a platform 3,15 meters away from them over a fatal pitfall probably isn't a good idea. In cases like these it's generally better to exaggerate the distances so it really looks like the player can’t make that jump, > Readability Readability is about making it easy for the player to discem (or “read') their environment. To not be visually overloading and providing sufficient contrast so the player can see what you want them to see. The best way to demonstrate how low readability can harm the ‘experience is through some examples, Notice how everything blends together? The walls, the door (center) and even the character ‘on the right? 19In addition to most ofthe surroundings being green and brown, all the vegetation and their shadows ‘end up creating a very visually ‘noisy’ and overwhelming environment. In many games it has even gotten to the point where in-game guiding elements (see image below for example) and Ul elements (arrows and special vision modes) are almost mandatory since reading the environment can be difficult, SEPSIS co oR rains Other examples of visual language can be in the form of white paint, the yellow markings in God of War (2018) and white scratches surrounding ledges you can grab in the Uncharted series. Without guiding elements tumed on, can you guess where gatherable resources are, the path forward is and where you can climb? 20With the guiding elements tumed on and the special vision mode activated we can now clearly see that which was very difficult (i at all) to see bofore. In addition to this, guiding elements like these can easily break the 4th wall since you're more directly talking to the player. But despite all this, using these kind of guiding elements might not be a problem for your game. But if you want to move away from using them, what can be done? Well the first step is to consider how visually ‘complex your scene is, Visual complexity can for example come from how detailedinoisy it is (see foliage image), a large number of objects to take in, a large number of saturated colors, a large number of possible points you can be attacked from, et The more visually complex something is, the more extreme something has to be for us to notice it (like in the jungle image above with the guiding elements tured on). 24