Metrics

The proportions and distances of the level, how big the level feels

What are metrics?

In level design, metrics are the sense of scale, distance, and measurements across the entire level / game.

All level designers use at least two types of core metrics:

  • Player metrics (or physics metrics) are factual numbers measured in-engine like player size, movement speed, maximum jump height, etc.

    • describes game physics, derived from the game engine

    • example: "player size" is a specific fact that can be measured and verified

  • Building metrics are suggested floor / wall dimensions and guidelines that you codify for yourself based on your desired experience goals

    • prescribes game feel, decided by designer(s)

    • example: "regular hallway size" is a guideline; what does "regular" mean for each project?

Depending on the project, you might need combat metrics or puzzle metrics too.

But beware of over-reliance on metrics. Numbers and measurements may give the illusion of infallible design laws -- the illusion that following these numbers will give you the perfect level. You must reject this illusion! You cannot measure your way to a good game experience. Metrics are a helpful design tool to help you make decisions, but metrics are not magic.

Note that "metric" is also a generic word for "measurement." In games, we also have mobile game metrics ("KPI"), audience metrics, marketing metrics, monetization metrics... anything that can be measured.

Scale

Metrics help you establish scale, the general sense of how big the game world feels.

In level design we usually follow real world architecture, which argues that most buildings are best when you "build at a human scale." That means making sure rooms don't feel too small or too big. Proper scaling is very important when working in a realistic style, because it makes the level feel more plausible -- it will feel more like a real place built by humans and inhabited by humans.

Of course sometimes you should NOT build at a human scale:

  • non-human player perspective (playing as a cat or a car?)

  • non-realistic, surreal, strange (a dream sequence, an alien world?)

  • iconographic style (level set in a theme park or Las Vegas)

(TODO: photo of different scales)

But even in those examples above, the human scale is still important in an indirect way.

Cats and cars exist in relation to humans; a cat game would need some rooms that feel too big (because cats are smaller than humans) while a car game would need houses that feel too small (because cars are bigger than humans).

Dreams and aliens only feel dreamy or alien when compared to a mundane world. And theme parks and Vegas feel special only because you have to go home to a normal place. Living in Disneyland would feel like hell.

To break rules meaningfully, you must understand what you are breaking, so you can better craft its opposite.

For level design, perhaps it's better to say, "build at the player's scale."

Video game scale is weird

The human scale is helpful, but video game spaces are not human. Video games often rely on an exaggerated sense of scale that does not correspond to any real world measure.

In Doom, the player ("Doomguy") is 32 pixels wide, which translates to 1 meter wide. The shotgun is 63 pixels long, which is almost 2 meters (6 ft. 5 in.) long. Oh, and Doomguy runs at 30 units per frame, which is 40-50 MPH depending on which hotly debated scaling system you use. Either way, Doom scale doesn't make any sense, but it feels nice to play anyway.

In The Elder Scrolls: Skyrim, the world area is about 14 square miles, the tallest mountain is 766.5 meters above sea level, and the player runs (not sprints) at 11.7 mph without tiring. That means the entire "province" of Skyrim is half the size of Manhattan, the tallest mountain is shorter than the Burj Khalifa in Dubai, and every peasant is a high performance marathon runner. By any real world measure, it is very small and weird. And yet, Skyrim somehow still feels like a large vast natural landscape with a huge alpine mountain, populated by typical people of average fitness.

So when building video game spaces, remember that it should merely "feel" realistic as part of the mood, atmosphere, or aesthetic.

But if you approach level design too much like real world architecture, then ironically, your levels will feel way too big and complicated and thus implausible.

Don't follow real world scale.

Scale advice

  • "Big" levels feel big, but are actually much smaller than in the real world.

  • Players regularly move at very fast speeds... that feel normal in the game world.

  • The game world feels internally consistent, even if the specific numbers seem silly to think about.

  • Again, most games do not follow a coherent scale, and break scale all the time.

Nonetheless, poor attention to scale and metrics will make the level feel awkward to inhabit. Unfortunately it's not really a scientific thing. It has to feel right, and you'll only know it when you're walking around inside your level and testing your game mechanics.

That's why we recommend considering metrics during the blockout phase. Don't worry too much about metrics when drawing an initial layout, because you can't really test for game feel on paper. And definitely don't wait until production and art passing before testing metrics, otherwise it will be very time-consuming to make any big changes, and you might even have to rebuild the entire level.

Basic metrics

In theory, you can build your game or level at whatever scale you want. In practice, physics implementations assume a default scale, and asset stores supply environment art at a common humanoid scale. Following convention is... convenient.

For your convenience we provide common metrics for popular game engines below, but we encourage you to check out our full list of Tools.

Common player sizes

Game / Engine

Default units

Bounding box (width, height)

Eye height from ground

Unity

Meters

1.0 x 1.8 m (or 1.0 x 2.0 m)

1.5 m - 1.7 m

Unreal 4

Centimeters

60 x 176 cm (half-height: 88)

152 cm (88+64)

Source 1

Inches?*

32 x 72 in

64 in

(US, real-life)

Inches

20 x 69 in (average adult)

66 in

  • Bounding box / collision sizes are usually much bigger than the actual character model. This bigger thicker size is for more stable movement. It's not a hitbox.

  • Note that in-game eye height is usually below where the eyes would be. Most FPS games lower the camera to neck / chest level because it feels better to them. When prototyping a game, play around with eye height, but finalize it quickly.

  • * Source 1 games often use "inches" lightly (eg. in Team Fortress 2, everyone is 7 feet tall) and inherit much of their proportional system from Quake 1.

Common modern architecture dimensions

Game / Engine

Interior walls (depth, height)

Minimum hall width

Doors (width, height)

Steps (height, depth)

Unity

0.1 x 3.0 m

2.0 m

1.25 x 2.5 m

0.1 x 0.15m

Unreal 4

20 x 300 cm

150 cm

110 x 220 cm

15 x 25 cm

Source 1

16 x 128 in

64 in

56 x 112 in

8 x 12 in

(US, real-life)

6 x 96 in

48 in

36 x 80 in

7 x 11 in ("7-11")

  • The minimum hallway width should be at least double the player width. Even then, it will feel a bit narrow and uncomfortable.

  • Modern doors should be narrower than hallways to allow space for a door frame.

  • Modern flights of stairs have landings / platforms every 12-16 steps.

  • Modern stairs should follow a 30-35 degree slope. arctan(7/11) = 32 degrees

  • In Source 1 and older engines, level grids followed power-of-two numbers. Unity users often prefer 1.0's and 10's. Unreal 4 users are split based on their age. Use whatever number roundings that you and your collaborators prefer.

  • When building in a realistic modern style, do some research beforehand: gather plans, blueprints, schematics, or even read through local building codes.

Deviating from common metrics

You should, of course, deviate meaningfully from metrics. Steep stairs will feel more harrowing and awkward than shallow stairs, and if that's the experience goal you want, then go for it. Often the best part of a level is the uncommon and unexpected. But in order for something to feel uncommon, you need to situate it next to enough common elements first.

What if the level isn't modern?

Do research and derive your own measurements from the type of architecture you are working with. Medieval European doors and stairs are traditionally smaller and narrower than modern doors and stairs, traditional Japanese architecture uses the ken (ι–“) proportional system, Italian Renaissance architects used the golden ratio (1 : 1.618) in the vein of Ancient Greek and Roman architecture, etc.

What if the level is stylized / isn't realistic?

Even if you're building a level with non-realistic proportions, the metrics still need to feel internally consistent to the game world / design norms. The steps in Quake 1 maps are often 16 inches tall, but the rest of the game world is appropriately big and chunky to match that proportion. Creating a coherent and consistent stylized proportion is definitely more difficult than an appeal to realism.

To try to codify consistent metrics across the entire game, many teams build test maps and formalize specific measurements in internal design documentation.

For more information on planning, see Pre-production and Research.

How to build with metrics

Start with physics metrics. Player size and camera height are the most important numbers, these will help you blockout at a human / player scale.

To make a level (or set of levels) feel more consistent, reuse room sizes and codify your own building metrics. Similar sizes help players use pattern recognition for smoother flow and wayfinding.

Consistent metrics can help a level feel "correct" alongside other levels, with well-tuned proportions and dimensions contributing to smooth player flow. When the distance between movements or jumps feels satisfying in a level, that's metrics at work.

Ignoring metrics means the level's constructed scale will feel awkward to inhabit; ceilings will feel too low, hallways too narrow, doorways too wide... and sometimes these levels feel interesting and wonderful to explore too. Just make sure it was intentional.

Modular construction

Does the prospect of measuring everything make you nervous? Some designers use a modular construction method to build their entire blockout: build one perfectly-measured sample wall segment, floor tile, stairway segment, etc. and then copy-and-paste these modular prefabs as needed to fill out the entire map.

In modular construction, you measure once, and then duplicate that measurement across the entire level. But that's also a big weakness of modules: you can only measure once, and if you ever have to change that measurement, then it might break the rest of the level that relied on that specific grid.

To learn more about modular construction, see Modular kit design.

Deriving metrics

When modding an existing game, there are already existing maps to derive some metrics. If possible, open the original map files in the level editor and measure widths, heights, and inclines. Ideally there is also some documentation to help explain the metrics, but in the likely absence of design docs, you'll have to become somewhat skilled at the game and figure it out yourself.

For example, here are some combat metrics for Team Fortress 2, based on observation and analysis from the TF2maps community:

  • Close range weapons: 256 units or less

  • Medium range weapons: 1024 or less (and projectiles become easier to dodge, etc)

  • Rocket spam and snipers: 2048

  • Maximum drop height without fall damage: 256

These metrics are reflected in the arena design of Team Fortress 2 maps like Badwater Basin below. Most drops are 256 units high, with maybe a few drops at 320 to apply a small penalty for any falling players. However there aren't many 512 unit drops because that would limit player options too harshly, and also render close range weapons much less effective.

If someone else doesn't calculate and explain all these measurements for you, then that means you'll have to figure it out yourself, especially if you're making your own game from scratch. The most direct way to obtain these metrics is to inspect the actual game code.

But without code or scripting access, you can also build a metrics zoo test map to conduct experiments. Imagine building a short length of a race track, then running along the track and timing yourself.

For examples of detailed metrics, see Doom metrics and Quake metrics.

Build a metrics zoo test map

To get even more specific and concrete with metrics, it's best to build a sort of "metrics zoo" test map that exhibits the different modules, prefabs, and level geometries you intend to use across all your levels.

  1. Blockout. Build enough of a blockout map with various rooms, hallways, and floor heights.

  2. Playtest for usability. Walk around with gravity enabled, ensure there is ample clearance and passage through doors, hallways, between furniture, and up/down stairs. If there is awkwardness or discomfort, make sure it is intentional and serves your design goals, otherwise fix it.

  3. Playtest for feel. Pay special attention to the sizes of walls, doors, chairs, tables, and stairs. Does the height feel right? Do doors feel too small? Make notes, and measure the problem areas in-editor and adjust the dimensions. If prototyping a game, finalize the camera height and player speed.

  4. Iterate. After each metrics revision, playtest the map again. Repeat.

The average real world human adult walking speed is about 3 mph (5 km/h). But this speed will feel painfully slow for most first person and third person games, and even walking simulators. For this reason, most games default to the average human adult running (jogging) speed of 7 mph (11 km/h).

Some common movement metrics you should know for your game:

  • Basic movement. Walk speed, run speed, falling speed, maximum step height, maximum incline. Minimum hallway width, minimum height clearance.

  • Jump metrics. Maximum jump height, maximum jump distance, running jump distance. This is obviously very important for designing any type of platformer.

  • Fall / drop metrics. In games with health and fall damage, what is the maximum drop height without incurring any fall damage? At what height will falling kill a player completely?

  • Combat metrics. What do you mean by close range, medium range, or long range combat? How tall is half-cover, how high should the window be placed? How big is each team's base or territory?

... and also some less common but useful metrics for collaborating with others:

  • Pacing metrics. How long should each map or chapter be altogether? How far should the exit be, how much backtracking should be allowed? How far apart should the various map objectives be? How many resources or rewards can be placed in each stretch of the level?

  • Narrative metrics. How long is this NPC dialogue, and how far can the player travel while they are talking? How many narrative assets such as audio logs, readables, codex collectibles, etc. should be placed in a given part of the level?

  • Optimization metrics. If we are streaming in chunks of level data, how big should each chunk be? How long does the level transition hallway or sequence need to be, to mask the level streaming time? How many different meshes, materials, or shaders, can we load for each level?

Texturing for metrics

When blocking out, use some kind of world texture with surface detail.

Do not use flat solid colors, or you will lose visual scale and depth cues while prototyping.

We recommend using placeholder grid / checkerboard textures, anything with repeating lines at regular intervals that will help you eyeball distances and proportions as you build your blockout. Check our Resources for links to various prototyping texture packs.

While building, make sure the texture scale stays constant and independent of the 3D object scale. To ensure a constant scale, set the level editor to use a "world aligned" texturing mode, or use some sort of triplanar grid material.

Metrics of perception

What affects the player's perception of size and speed? Basically anything on the screen.

Camera height

"Some animals are lightning fast. Others are pitifully slow. But slow and fast are relative terms. Four miles per hour doesn't feel very fast to a human: it's approximately one body-length per second. But to a small insect it's approximately 100 body-lengths per second. A human traveling that fast would be going 20,000 miles per hour! This is why some animals' brains process visual stimuli much faster than ours, and why they have better reflexes (think about how hard it is to swat a fly). What does it feel like to comprehend the world at such speeds?" -- Alex Reisner, creator of SpeedOfAnimals.com

If you are prototyping a game, finalize the camera height / eye offset as soon as possible, because it will affect how big the entire game world and all its characters feel. The camera height is one of the key variables that affect the player's sense of a virtual body, because "slow" and "fast" are relative to body size.

For suggested eye heights, see the Basic metrics section above.

Local reference points, composition, texturing, fog

TODO: more local context, objects along the line of movement

Camera field of view (FOV)

Your sense of perceived speed depends on how much you are seeing and the rate of visual change within your vision. A high field of view (FOV) will zoom-out to produce fisheye distortion that increases apparent speeds at the edge of the screen (periphery).

Note that there are three ways to measure field of view -- horizontal, vertical, and diagonal -- but for games we generally refer to the horizontal FOV so that it scales well with widescreen setups.

Some players prefer high FOVs because they can see more of the world around them and gain better situational awareness, and there have also been studies that suggest a high FOV helps some players mitigate motion sickness while playing first person games.

On top of the base FOV setting, many third person action games shift to a higher FOV when the player sprints or accelerates. This FOV change gives a greater sensation of speed, even if the actual speed increase is negligible. In contrast, some virtual reality games purposely occlude and mask peripheral vision to decrease this sense of acceleration and mitigate VR sickness.

The default Quake (1996) field of view was 90 degrees, and competitive players often set their camera to 120 degrees so that they could see more of their surroundings. This made more sense when CRT monitors and TVs had a 4:3 aspect ratio, but feels different on a modern 16:9 widescreen display.

Today, most commercial 3D action games tend to offer accessibility settings with an FOV range slider for users to adjust the camera to their personal comfort, usually between 60 and 90 degrees, but default to a narrower FOV. A high FOV distorts the image in an unrealistic / unflattering way. Meanwhile, a lower FOV zooms-in and "flattens" the view depth, giving a greater sense of closeness and intimacy with the game world. If your game is about looking up-close at characters' faces, you would err on a narrower FOV so that the faces don't look strange or distant.

Portrait photographers often try different lens focal lengths to get the most flattering distortion and closeness with their subject. 20 mm (84Β° FOV) narrows the face with extreme proximity, 70-100 mm (29-20Β° FOV) is more naturalistic, and a long 200 mm (10Β° FOV) telephoto lens widens and flattens the face with a longer distance from the subject.

Sound design, HUD / UI, and NPC AI as speed metrics

The brain processes all senses together. Vision isn't just a matter of seeing, it is also a matter of sound, memory, knowledge, etc.

To demonstrate, there is a well-known experiment in game feel involving two identical circles sliding past each other to swap places. Without any sound, the circles will appear to be just exchanging positions, but if you play a collision sound when the circles intersect, then the circles will appear to collide and bounce off each other instead.

For a more direct example of how other stimuli affect our sense of speed, consider the ZX Spectrum port of Super Hang-On (1987). In this single player motorcycle racing game, the "turbo" button temporarily increases the player's max speed limit to 324 km/h, beyond the normal limit of 280 km/h. However, the game does not render faster nor does the player actually move faster; instead, the engine sound gets louder, numbers get bigger, and opponent NPCs slow down. These contextual cues combine to give a faster feel without actually adjusting the camera nor the player.

The church of metrics: "rational game design"

A game industry practice known as rational game design (RGD) / rational level design (RLD) focuses on measuring metrics to plot parameterized game mechanics against game difficulty in a coordinate space, with the goal of mapping out a game's possibility space in a quantified way.

Basically, give everything in the game a number, and then add up all the numbers to help guide your design decisions. If you don't like how the numbers add up, change them. This general workflow looks like:

  1. Design game mechanics, and identify various parameters and modifiers.

  2. Plan levels across the entire game with different combinations of mechanics and modifiers.

  3. Quantify parameters for each mechanic (e.g. 0% difficulty jump is a 3 m wide gap between platforms, while a 100% difficulty jump is 10 m wide, etc.)

  4. Iterate on each level's metrics to conform to desired difficulty scores and target values.

Criticism of rational game design

Supporters claim this design method represents a more "rational" and "scientific" approach to plotting and pacing the player experience. Unfortunately there are very few public resources on how to practice RGD, which is convenient because that means we can't actually evaluate its methodology or claims -- its evangelists can always claim that we haven't read the proper holy scriptures, and so we don't truly understand how to practice it. What little documentation here is cobbled together from the few articles and resources available online, with much of the material guarded as a trade secret by Ubisoft.

We caution against any uncritical belief in any single design method, especially something that touts supposed objectivity / ahistorical understandings of "form follows function." And we remain skeptical of any method that claims to capture conceptual depth with a number. The more technical the design formula, the more formulaic the design will be -- a common critique leveled at many Ubisoft games.

But if RGD / RLD serves as a useful design tool that yields good results for the type of game you're making, then there's no harm in using it with moderation. Collecting data, measuring spaces and distances, and playtesting are all certainly good design practices. Just don't drink too much of this rationality Kool-Aid.

To review...

Consistent metrics can help establish a basic layer of usability, functionality, and scale to a game world.

But when there is too much consistency, the level can feel predictable, rote, and uninspired. Metrics are a crucial tool, but also just one of many tools that can be misused or misunderstood. Do not try to measure too much of a game system; measurements alone cannot guarantee good level design.

Now what?

Further reading on metrics

Last updated