Scrolling Game Development Kit UI Help  

Collision Definitions

Use this screen to define what happens when sprites touch each other. There are 16 customizable "collisions classes" for each map. The "Collision Class Names" box allows you to name these to suit your usage. Any sprite may be a member of any number of these collision classes. A sprite that is not a member of any collision class will not participate in any collisions.

You can define a number of collisions tests for each map. A test consists of two classes and a number of flags indicating the effect of the collision. There are also some inventory parameters that can control activation of the collision, a special function that can be activated when the collision occurs and a media clip that can be specified to play when the collision occurs. The two classes selected indicate which sprites should be tested for collisions. For instance, if "Player" is selected in the first box and "Platform" is selected in the second box, every time the game advances one frame, all sprites which are a member of the "Player" class will be tested for a collision with all sprites of the "Platform" class (other than itself). Whenever a collision is detected, the sprites respond as indicated. In this case the sprite that is a "Player" represents the "A" sprite and the sprite that is a "Platform" represents the "B" sprite.

When two sprites collide, all applicable collision tests for these sprites are processed, so there would be a number of collisions if there were two sprites classified as both player and platform, and two tests - one between platform and player and another between player and platform. When these two sprites come into contact:

All these collisions would be tested for each frame advance of the game, so be careful how liberally you define collisions. The number of tests would grow exponentially (in this case) as the number of player-platform-class sprites increases.

As of version 1.2, GameDev supports inventory parameters in a collision definition. Selecting "owns" indicates that the player must own a minimum number of the specified item in order for this collision test to respond. Selecting "lacks" indicates that if the player does not have a specified minimum of the specified item, then this collision test will respond. These tests go well in pairs. For instance, if the player runs into a Thief sprite and owns at least 1 dagger, the response could be to terminate the Thief sprite and play an "I gotcha" sound effect. In a separate collision test, you could specify that if the player runs into a Thief sprite and lacks 1 dagger (does not own at least 1) the response should be to bounce off the Thief and play an "ouch!" sound effect. Checking the "Remove inventory after use" box indicates that the item(s) should be removed from the inventory if the player owned a sufficient number of items that were required for the collision. Note that these parameters only take effect when the number is greater than 0. Inventory parameters for the collision are ignored when the number is 0.

There are a number of effects that a collision can bring about, and many of these can be combined:

You should keep in mind that the number of collision tests and the number of sprites that are a member of any collision class can increase the work required by the game engine exponentially, so try to limit collision detection requirements to a minimum.

Collision Definitons are saved in the MAP file of the map for which they are defined.