collides Property

The final part of collision detection we need to learn about is the .collides property. This property determines how the entity collides with other entities. It’s important to note that this is independent of the collision map. This is strictly an entity-to-entity collision event. There are several types of collision property values:

ig.Entity.COLLIDES.NEVER
ig.Entity.COLLIDES.LITE
ig.Entity.COLLIDES.PASSIVE
ig.Entity.COLLIDES.ACTIVE
ig.Entity.COLLIDES.FIXED

By default, the collides property is set to NEVER, which ignores all collisions. FIXED is used for objects such as walls and platforms that won’t move as a result of a collision. It’s important to note that entities with a FIXED collides property may still move, just not when colliding with another entity. Elevators and moving platforms are good examples of this situation.

The remaining three collides values determine which entities move after a collision. If two ACTIVE entities collide, they will both move apart. The same is true when ACTIVE and PASSIVE entities collide, but the PASSIVE collides value exists so that entities of similar types can overlap without causing a resulting movement. So, when a PASSIVE entity collides with another PASSIVE entity, neither is moved by the collision.

Finally, where FIXED describes a “strong” entity that never moves away from a collision, LITE is used to specify a “weak” entity—one which always moves away from a collision.

Now that we have covered the collision properties entities have, let’s start setting up our own player and monster to have collision detection. Open up the player.js class and add the following properties:

type: ig.Entity.TYPE.A,
checkAgainst: ig.Entity.TYPE.NONE,
collides: ig.Entity.COLLIDES.PASSIVE,

Here, we are setting up all three collision properties for the player. We assign the player to TYPE.A, which will represent our friendly group. Next, we’ll set .checkAgainst to NONE. In our example, we’ll let the monster handle the collisions and, as shown in the previous section, apply damage to the player. Finally, we’ll set .collides to PASSIVE. This will prevent overlaps with another PASSIVE entity moving either entity as a result of the collision.

Now it’s time to set up our monster. Open up the zombie.js class and add the following:

type: ig.Entity.TYPE.B,
checkAgainst: ig.Entity.TYPE.A,
collides: ig.Entity.COLLIDES.PASSIVE,

We are setting our monster to the enemy group, which is TYPE.B. Since the player belongs to group TYPE.A, we will check against that group for collisions. And finally, we also set the enemy .collides property to PASSIVE. This will allow us to react when a collision is detected with the player, but because both entity .collides properties are set to PASSIVE, Impact won’t automatically move either of the players due to the collision.

If you tested your game now, it would appear that no collisions occur. This is because we set the collides property for all entities to PASSIVE, and Impact won’t adjust the position of either entity after a collision. We need to add some more code in the monster class to handle the collision when it is detected. Add the following method to the zombie.js class:

check: function( other ) {
    other.receiveDamage( 10, this );
}

You may recall during the discussion of the .checkAgainst property that this code applies damage to the entity the monster collides with. Remember that the colliding entity is passed to the function as an argument (other). This code executes Impact’s built-in receiveDamage() method in the player entity, and passes a value of 10, as well as a reference to the monster, to the player. The end result is that the player will lose all his health (10 points, by default).

Now, if you test the game, when the player hits a monster, he should be immediately killed. Visually, the player just disappears, since we haven’t created a death animation (see Figure 4-19.

Figure 4-19. The player is removed from the screen once the zombie kills him.

Next, we will discuss health.