LD - In pursuit of better levels

Game level design document with useful senior dev knowledge

engineering
software
games
guide
dev
  1. Home
  2. Google Doc
  3. LD - In pursuit of better levels

LD - In pursuit of better levels

Game level design document with useful senior dev knowledge

engineering, software, games, guide, dev

Level Design

In Pursuit of Better Levels








































Table of Contents

?Planning? 4

❖ Concept process ❖ 4

❖ Metrics ❖ 6

❖ Prototyping & Blockout ❖ 9

⚒ Structural geometry ⚒ 11

⚒ Form follows function ⚒ 11

⚒ The Backdrop ⚒ 12

⚒ Check the scale ⚒ 12

⚒ Empty space ⚒ 13

⚒ Testing the level ⚒ 14

⚒ Documentation & important questions ⚒ 14

⚒ Iteration & playtesting ⚒ 15

?Navigation & distinction? 15

❖ Perception ❖ 15

❖ Readability ❖ 19

❖ Orientation ❖ 26

⚒ Landmarks ⚒ 26

⚒ Signposting ⚒ 30

⚒ Vantage point ⚒ 31

❖ Guidance ❖ 32

⚒ Overestimating guidance ⚒ 32

⚒ Attention & saliency ⚒ 34

⚒ Visual language ⚒ 37

⚒ Nope zone ⚒ 40

⚒ Guiding with AI ⚒ 41

⚒ AI as visual & audio language ⚒ 42

⚒ Breadcrumbs ⚒ 43

⚒ Teasing ⚒ 46

⚒ Prospect & refuge ⚒ 47

⚒ Contrasting paths ⚒ 49

?Pacing? 50

❖ Pacing tools & tricks ❖ 50

⚒ Flow in Singleplayer ⚒ 50

⚒ Gates & Valves ⚒ 51

⚒ Loops ⚒ 52

⚒ Recycling levels ⚒ 53

❖ Planning & structure ❖ 54

��� Intensity, variety & time ⚒ 54

⚒ Beats, charts & timelines ⚒ 55

⚒ Non-linear pacing ⚒ 57

?Enhancing the experience? 59

❖ Choices ❖ 59

❖ Enhancing with audio & visuals ❖ 62

⚒ Color, lighting & mood ⚒ 64

❖ Narrative❖ 66

❖ Emotions ❖ 68

❖ Spicing it up ❖ 69

⚒ Wow moments ⚒ 69

⚒ Reactivity ⚒ 70

⚒ Exploration ⚒ 71

?Designing for combat? 72

❖ Vantage point ❖ 72

❖ Combat Spaces ❖ 73

⚒ Combat fronts ⚒ 76

⚒ Flanking ⚒ 78

❖ Cover ❖ 79

⚒ Cover placement ⚒ 83

❖ Enemies & encounters ❖ 85

⚒ Enemies & cover ⚒ 85

⚒ Spawning & tracking enemies ⚒ 86

⚒ Encounter design ⚒ 90

⚒ Allied NPCs ⚒ 92

❖ Line of Sight for SP & MP ❖ 93

?Multiplayer map design? 97

❖ Overview ❖ 97

⚒ Readability ⚒ 99

❖ Level structure ❖ 101

⚒ The Circle ⚒ 101

⚒ Figure 8 ⚒ 102

⚒ Clash points & Double Clash ⚒ 103

⚒ Tug of War ⚒ 106

⚒ Defence ⚒ 107

❖ Balance ❖ 109

⚒ Symmetry & Asymmetry ⚒ 112

⚒ Time ⚒ 114

⚒ Spawn points ⚒ 114

⚒ Potential Player Positions (PPP) ⚒ 115

❖ Flow ❖ 117

?Briefly on accessibility? 121



?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 I will also provide my own suggestions and observations where it’s relevant.But I don’t want to take any credit for the knowledge contained in this document, I merely collected it.



While I stand behind everything in this document as good guidelines to follow, it’s 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 I 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 Y 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.

* It helps 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 are:



* 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?

➤ If the 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 feel 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 level be made in terms of the engine, time, 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.



* It allows you to test and figure out the proper values in a quick and dirty setup.



* It helps 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 it’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.


Box/Frame

Useful for measuring windows, door frames, cover boxes, etc.


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 Multiplayer level design to ensure that each teams side of the level are balanced.


So what kind of metrics 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)

LD - In pursuit of better levels
Info
Tags Engineering, Software, Games, Guide, Dev
Type Google Doc
Published 18/06/2020, 22:42:29

Resources

Specification gaming examples in AI - master list