Weekly Update - Closing BackerKit and an in depth post on Metrics!


This week we have another in depth piece written by one of our team members! But before we get into this we would like to announce that we will be closing our slacker backer campaign on BackerKit this Monday, December 6th. As mentioned in our end of October update, it’s important to us that pre-alpha players have plenty of time to play and give us feedback before then, as we don’t want anyone to be short changed and not get a chance to contribute before a bigger community joins in. So what does this mean for you? Make sure that all of your information is up to date (address, tiers, payment info etc..), as we will lock down backer information soon. And, this is also the last chance to get in on the pre-alpha feedback. Don’t hesitate to send us an email ( if you have any concerns.

This week, Marc is going to talk about game metrics. It might not sound bubbly, but it is a crucial part of game development.


Hello happy few!

Marc, gameplay and AI programmer here. I have done a lot of small updates and added a few features to gameplay, sound and AI in the past few weeks, but I have been thinking that it’s not that interesting to just deliver a series of bullet points. Instead, this week I wanted to talk about an important subject of game development that is becoming critical at our stage: Metrics.

We have been recruiting a few people in level design and art to help push all the content the game needs and it’s becoming really necessary to make sure we’re all on the same page when it comes to the game space.

Metrics are what we call the series of “regulations” we try to follow when building areas: e.g. width of doors and corridors, height of windows, etc. Defining metrics allows for better tuning of the gameplay by controlling the space, it reduces player confusion, and, very importantly for game development, reduces the amount of bugs.

For instance in We Happy Few the player can vault over fences, enter windows, and climb walls. The level designers need to know the physical dimensions that are taken into account by the gameplay code to know where to place their objects.

Some games use really strict metrics (think about the square/hexagonal grids on turn based strategy games, or the block heights in most platformers), which has a lot of advantages: it’s clear to the player what he can do, it’s much easier to build, and to test; and there are no edge cases that could be the source of unexpected behaviours. But when you do a (relatively) realistic open world game, you don’t want to limit yourself to prefabs of a given dimension when building the world; it needs to be more organic than that, and as such, there will be problems.

So it’s even more important to have a clear idea of the capability of the player and the AI characters to try to avoid using geometry that does not clearly correspond to one ability or another. It will still happen, no software as complicated as a game is bug-free, but trying to respect the metrics as much as possible helps a lot to relieve the pain.

Coming back to the vaulting & climbing example, the code needs to detect whether an object is “climbable”. It uses at least two tunable values: minimum height and maximum height. As we have two different types of climbing - a “low” climbing and a “high” climbing - there is also a cutoff (middle) height. We want to avoid obstacles with a height that is about the cutoff point, as we want to be clear which kind of climbing it is: the “low” objects should be between the minimum and middle height, and the “high” between middle and maximum. Obstacles that can be “vaulted” over need to have a maximum depth, and ideally be well below it to avoid physics collision issues. But in this case we also need a minimum depth otherwise the animation will not match nicely.

As a gameplay programmer it is my job to tell the designers the ideal dimensions they should use, so I created a technical document with all this information, and created a test map containing grey blocks representing these dimensions:

The other advantage of having test maps like that is to check the gameplay code is working as intended, i.e. it is useful for regression testing (making sure stuff that was working is still working).

Another very important aspect is metrics for AI. We all know how stupid characters can look in video games: getting stuck in walls, not knowing how to walk over a pebble on the floor, etc. One wonders why it’s still happening, and in big AAA games too, now that we have a lot of experience and very sophisticated game engines. Well, the answer is that AI navigation and behaviour is a hard problem, really hard. The number of factors to take into account is crazy. When you see these bugs in games, don’t believe it is because the developers are lazy (they’re not) it’s because they have tons of issues to fix and some just slip under the radar. You should see what it’s like before they release it into the wild.

What if the AI can walk above a 30cm step but a random object ended up on its path and it’s a 32cm obstacle? What if the AI capsule (its collision volume) is 70cm diameter but there is a flower pot that reduces a corridor width to 69? You end up with stuck characters, because game engines need to simplify things, and so when the AI looks like it should have the space to go somewhere its game engine physical representation may not.

To minimize all these issues the game spaces need to respect the AI constraints, which are stricter than for the player. For instance:

The other problem for AI is the generation of the navigation mesh: For a character to know how to get somewhere, she needs to have a mesh that indicates the connections between different spaces. Aka, where can you walk. This is generated with some extra tolerance/margins, relative to the geometry, to avoid AI getting into places they shouldn’t (for instance stuck through walls). So, you need to add space on top of the “size” of the characters:

The green areas are where the AI would consider walking, and the green arrows on doors represent the “navigation links” that AI can use to go from one patch of the nav mesh to another.

In this example the dimensions are minimum: a corridor needs to be wide enough for two characters to go through relatively comfortably (so they don’t get stuck walking in the opposite direction to each other), and a door can accommodate only one character. The wider the space, the fewer issues there will be. It’s one of the main reason there are few open world games that do a lot of interiors, and when there are some they are usually very controlled environments.

You can already see how the corridors dimensions are not “realistic” (for a corridor inside a house at least):

But there is a difference between “realistic” and “believable”. Video games rarely use realistic dimensions; in my experience, when they do they shoot themselves in the foot and it leads to buggy games. Instead, we use “believable” dimensions, where everything is slightly oversized and room layouts are much more open that they would be in real life. After all, what’s important is not the reality, it’s the illusion of reality. If you double check the games you’re playing you will soon notice how everybody's doing it.

So that’s why we need to define metrics: to simplify our life, and allow everybody on the team to be on the same page building consistent environments. I’d like to deliver a game that is bug-free, but I know that won’t happen, so we aim to deliver a game with few problems, that are of little consequence when they arise.

Hope you enjoyed this update, have a great weekend!


Discuss this post here