What is predictable collision detection and why does it matter?

One of the things I really want to emphasize during this Kickstarter is that Eyes Open is a very mechanically driven game. This is different than a lot of horror games for a number of reasons, not the least being that most horror games like Amnesia or Slender play out in the first person. These are games that focus on atmosphere and visuals to push their experience, even in the case of Slender where those visuals originally weren’t the most polished. A game like Slender can get away with never actually animating Slenderman and teleporting him around, because his appearance is so shocking that you’re going to be looking away most of the time. The environment is dirty and imprecise – you click on notes whenever you’re kind of close to pick them up, your flashlight never displays its battery state so you’re always guessing as to what position you’re actually in. It’s much less Super Meat Boy, and more Dear Esther.

And all of that is OK. Great even. Our game is different though: we’ve been upfront that we push horror in different ways than other games in the genre. In our initial prototype, we used solid colors to represent everything – you were a square, the monsters chasing you were a square, the walls were squares, and so on. Because of that, we had literally pixel perfect collision detection with walls and entities. That’s something we’ve tried to preserve as we moved through the various new demos.

Not sure what I mean? I’ll go over some really quick examples.


Monster Hunter demands high-level positioning and timing – not minute dodges or perfect aim.

In Monster Hunter Tri, the weapons have predetermined animations that aren’t really controllable but can be swung together into fluid combos for really deep and satisfying combat. Because this is built around the dance of positioning yourself and executing a long attack with the hope it won’t get interrupted, the collision detection needs to be fudged a little. Collision with monsters is very approximated – if you aim at a monster and you’re close enough, and you’ll hit them. If you’re aiming for the head, you’re not going to get caught on a horn and deflected down the back. You’re not going to swing at a monster and get your sword caught in a tree. The game relies on timing and strategy, not on precision aiming or controlling where exactly your sword is at any point.


Need For Speed allows for fine tuning of movement and forces the player to have good reflexes and aim.

Contrast that with a game like Need For Speed, where collision detection is, for all intents and purposes, pixel perfect. Because Need For Speed is about, among other things, very precise actions. Having simplified invisible walls is considered a detriment to the experience because the player needs to be able to fit tight gaps and make curves and to know exactly when they’re about to hit something and when they’re not. Collision in Need For Speed needs to be predictable.

What does that mean for a 2D game like Eyes Open?

There’s a reason why I’m obsessed with collision boxes – what we’re doing is maximizing the disparity between when your eyes are open and when your eyes are closed. If you’ve ever shut your eyes and tried to wander around a building blindly, you’ll know that one of the creepiest moments is when you think there’s a wall in front of you and you’re inching your way forward waiting to hit something. It’s a scary position to be in, because it turns a concrete (no pun intended) and predictable action into an uncertain one.

In order to create that disparity, the environment needs to be understandable on a conscious level. So we use tile-based graphics that enable you to have consistent rules for the environment. You know exactly when you’ll hit a wall or a monster, all the time. When you close your eyes, all of that goes away.

Increasing that disparity and sense of loss drives almost all of our design decisions. When your eyes are open, you can do things that you can’t with your eyes closed – thread your way through monsters, cut corners going around walls, inch through a doorway, and so on.

You need to be able very quickly and accurately determine which parts of your character are touching what at any given moment, how close they are to touching, and so on.  It’s not just about having accurate collisions with different objects – it’s about the player being able to easily predict those collisions.


Binding of Isaac has great collision detection, but it’s sometimes unpredictable.

A good example of the two choices we have is in how The Binding of Isaac simulates things like perspective and height when it’s doing collision.  Shots can arc over rocks, and the player’s head doesn’t collide with enemies, only his/her body.  It’s accurate and surprisingly intuitive, but still sometimes unpredictable..  Learning to navigate around Isaac‘s collision takes some effort, not the least because of bugs, but more because, even with the intuitiveness of it’s isometric view and accuracy, there’s a small separation between what’s realistically happening on screen and what the player is able to mentally work out in real time.  And although I don’t have any way of knowing for sure, I would guess that was a purposeful design decision on Edmund’s part.  It suites Isaac really well.

But it wouldn’t serve Eyes Open.

When we say we’re preserving as much pixel-perfect collision detection as possible, what we mean is not only do we want to have our collision be accurate rather than just approximated, but also we want you as a player to have no guesswork as to when you’re going to collide with something.

So we pull a number of tricks – we make all collision detection act as if everything is flat, ignoring any perspective between the player and the things around them.  That means that the top of your head collides with a wall just as if it was in the same place as the bottom of your feet – you don’t have an overlap with the things around you.  The same is true of monsters.

Check out the above peek at gameplay, especially around the 25 second mark and watch how the player’s head collides with the walls.  Once you get past the graphics and animations, you can still see those solid blocks moving around – they might be different sizes or modified in one or two minor ways, but they’re still there.

I don’t want to pretend that it’s a formula we’ve gotten down perfectly yet or that I won’t be coming up with different ideas in the future, but it’s something we’re working on and thinking about – a lot.  Collision detection is really important for a game like this, so we’re going to be testing it and experimenting with it and refining it like crazy at every stage of development.  I’m sure I’ll have more to talk about, correct, and expand upon as we do.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">