I enlisted the help of my good friend Brad Hines of Eidos Montreal for the research on this video. I felt terrible cutting a lot of the great information he had from the video, so here’s his full, uncut message to me.

Most AAA titles these days have at least a few issues with collision. As we move forward in quality in games, and with games getting more immersive, collision issues are more and more noticeable to the player. With new gen consoles having more realistic graphics, we’re more easily immersed in what we’re playing. Anything that reminds us that we’re playing a video game will break that immersion, and causes us to have an uncomfortable experience. This is why you see a lot more minimalist UI in newer games - because in theory, more UI means less immersion. Immersion is the key reason why collision issues are so disturbing to a player - if it looks like the character should be able to go somewhere, walk over something, or climb up something, they should. Collision is, however, a complicated system and tends to be different in most game engines, so there are a lot of things that can have an effect on how it interacts with the player character. I’ll get into the details below, which will hopefully provide a useful perspective on collision. As a caveat, this is written from a level designer’s perspective. There may be programming related details that I’m fuzzy on.

Collision, typically, is how the player character physically interacts with an object or terrain in the world. It can be built in many different ways, but most commonly it is a separate part of a mesh, built specifically to collide with the player. If you have a wall, for example, with a bunch of tiny details such as bricks, piping, windows, and so forth, usually the player collision will be built as a flat plane in front of all the details. This is two-fold: to provide a smooth experience for the player’s navigation, and to lessen the burden on the processing of the player’s collision. If the engine has to calculate how the player collides with every tiny detail on an object, you’ll typically see a pretty drastic effect on the framerate of the game.

You may also have cases such as in third-person games where there is even a separate mesh for camera collision. If you’ve ever seen the camera suddenly get pushed inside your player character and see their eyeballs and mouth sack, you’ve likely seen a problem with camera collision. Usually this collision should be closer to the shape of the actual mesh, so that its slightly further away from where the player is colliding with the mesh. This allows the camera to fit between the player and whatever object they’re colliding with. This isn’t always possible, but it certainly smooths things out when it happens.

Typically, collision is the responsibility of an environment artist or level artist to create. In most cases, a game designer or level designer will also create or modify the collision to better suit the player’s experience. If you were to enable the visibility of collision in most linear levels of AAA games, you might see something that looks like a very simple tunnel, whereas the environment appears to be complex. This shows a good example of synergy between art and design - art has provided an immersive environment, while design has provided a smooth experience. This starts to break down when, lets say, you run into an invisible wall in a location where it looks like the player should absolutely be able to go.

This brings me to my next point about problems with collision. There are many times when an artist has crafted a beautiful, immersive environment, but it ends up being a nightmare for player collision. The artist achieved their main responsibility - job done! However, a designer, technical artist, or the original artist needed to have done a cleanup pass of collision on that environment. Why did this happen? Deadlines, money, and workload, are a few factors at play here. The higher priority here was for the artist to make something that looks awesome. Maybe the designer that worked on the level has been moved on to another map to work on, and wasn’t able to have eyes on that level. Maybe QA logged a bunch of bugs regarding said collision, but the artist or designer had higher priority bugs to fix and these issues ended up being waived. It’s unfortunate, but small collision bugs end up being prioritized lower if they don’t individually have a massive impact on the overall experience. You start to see a big problem when all those little issues add up, though.

Speaking of schedule - you have to figure that in general, quite a lot of games start out with the best intentions for their development schedule, but often get pushed back and need to rush or crunch at some point to get things done. This causes a lot of these little issues to fall by the wayside, as there are bigger priorities such as literally getting the game done.

Another element that has a big effect on the collision in a game is the engine that’s chosen to develop the game in. If a third party engine such as Unreal is chosen, that comes with its own collision system, and therefore its own set of collision problems. If you’ve ever played a game made in Unreal (Gears, Bioshock, etc) and noticed your character suddenly stops at a tiny 2 pixel high obstacle, you’ve seen one of several of these issues. This is due to how the engine decides what an obstacle height should actually be, combined with collision that has not been crafted in a smooth way. This, however, can be worked around by building collision intelligently. This effectively adds “knowing what the engine is going to do” to the list of an artist or designer’s responsibilities. This speaks of an ideal case, of course, but it’s still something for devs to keep in mind. It should be stated that this is not a dig against Unreal, since it’s a very powerful engine - it’s just an example that will be common ground for a lot of gamers since Unreal is a frequently used engine.

So far, this big wall of text has tried to outline a bunch of sources of these issues, as well as a brief bit of information about collision itself. Below is the most general statement I can make on the topic:

Collision in video games is one part of a big, complicated set of systems. It’s created by human beings, which are capable of making mistakes, or rushing work, or having higher priorities. Game development is usually based on a tight schedule, and unfortunately smaller issues can get pushed to the side.

As a parting thought, my opinion on the matter (which has probably been loosely threaded through this whole thing anyway):

As we move forward in game development, collision and “3C” (character, collision, camera) can no longer take a back seat to the other features of a game. Immersion in games is the highest it’s ever been, and bad collision in games can be the most extreme cause of immersion breaking. We as developers need to remember that, even as environments become more and more complex, the way that the player interacts with that environment can still be considered relatively simple in a lot of ways. Collision needs to be carefully crafted to provide the smoothest experience for the player possible, so that they can feel grounded in the world and trust the game’s systems. Each time you miss a jump, get stuck on a small object, fall out of the world, or see inside your own character, a little bit of that trust gets worn away. The less you trust a game’s systems, the less immersed you’ll be, and the less fun you’ll have.

Twitter: http://twitter.com/wangbacca