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:

• Sprite 1 as the player hits sprite 2 as the platform
• Sprite 2 as the player hits sprite 1 as the platform
• Sprite 1 as the platform hits sprite 2 as the player
• Sprite 2 as the platform hits sprite 1 at the player

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:

• A rides on B: The sprite of the first class starts riding on the sprite of the second class like a platform. Some of its inertia is maintained so it can be difficult for a sprite to get onto a quick, horizontally moving platform.
• A and B swap velocities: This attempts to make the sprites move apart from each other by swapping components of the sprites' velocities. This often, but not always, looks like a "bounce". Sometimes one sprite ends up pushing the other until it passes through it. If you want sprites that act more solid and repel each other better, take a look below for the new "repel" functionality in version 1.3.
• A stops; B stops: The sprite definition and template of the sprite are cloned (so changes don't affect other sprites based on the same template or definition). Then the sprite's template is altered such that it becomes inert and its velocity is set to 0. Effectively, the indicated sprite stops moving (and may fall to the ground). Note the repel functionality below will result in a completely different effect if you have also checked the boxes for Terminate and Add New on the other class involved in the collision, and checked the swap velocities box.
• Terminate A; Terminate B: The sprite is removed from the layer and no longer drawn.
• Add new A; Add new B: A new instance based on the sprite's definition is created. If "A and B swap velocities" is also selected, the new sprite is moved to the location of this sprite instead of assuming its default start position. If "Terminate" is also selected, the current sprite starts over at the beginning of its path.
  Note: The "Add new" effects should be used with caution. If the effect does not include some action that stops the collision from happening again, you can quickly end up with too many sprites for the game to continue functioning at a reasonable speed. It may be preferable to activate a special function that creates a sprite, thereby exposing the ability to place a limit on the number that can be created.
• New with version 1.3 you will see a number of buttons below the checkboxes. The last 4 of these buttons simply expose old functionality in a new way. All the buttons are used to simply check a certain special combination of checkboxes to accomplish a particular effect. It is recommended that you clear all the checks before clicking one of these buttons if you want to be sure to achieve the expected effect. Since there are certain combinations of effects that don't make sense together (and since I wanted to continue to store the effect information in the same 8 bits) I decided to use these "nonsense" possibilities to represent alternative effects. So, for instance, when "A Stops", "Terminate B", "Add New B" and "A and B swap velocities" are all checked, rather than performing all those effects (which don't make much sense together) the repel effect is activated instead. Here is a complete list of what the buttons do.
• A Repels B: This causes "B Stops", "Terminate A", "Add New A", and "A and B swap velocities" to be checked, which is a special combination that causes the sprite of class B to avoid the sprite of class A. That is, when sprite B attempts to run through sprite A, it is stopped and repelled. Also, if sprite A attempts to pass through sprite B, it pushes sprite B away. In no case is the path of sprite A impeded. Only sprite B is affected.
• B Repels A: This causes "A Stops", "Terminate B", "Add New B", and "A and B swap velocities" to be checked, which is a special combination that causes the sprite of class A to avoid the sprite of class B. That is, when sprite A attempts to run through sprite B, it is stopped and repelled. Also, if sprite B attempts to pass through sprite A, it pushes sprite A away. In no case is the path of sprite B impeded. Only sprite A is affected. Note: if the boxes for both "A repels B" and "B repels A" are checked, A will repel B first, and if B is unable to move due to solid tiles on the map, it will then push back on A. This is new with version 1.4. In older versions, only B will repel A.
• Restart A; Restart B: By checking both Terminate and New for a particular sprite class, the sprite will restart from the beginning of its path, somewhat as one would expect by checking these two boxes.
• New A here; New B here: By checking New and "A and B swap velocities" a special combination is activated that causes the new sprite to be positioned at the location of the collision rather than its normal starting point.
• Activate special function: When the two sprites collide, activate the specified special function. The special function is activated regardless of the activation parameters of the function -- no inventory is required or affected for the activation of the function in this way. Only inventory parameters of the collision are taken into account. As of version 1.3.1 you can also activate a number of functions at once and pick functions based on the correlation between the function name and the name of the colliding sprites' definition or template names. For instance, the pattern "COL_<ATemplate><BDef>*" will activate all functions whose name contains "COL_" followed by the name of the A sprite's Template, then the name of the B sprite's definition and then anything else. The available patterns are:
  • COL_<ADef><BDef>* (Sprite A Definition Name + Sprite B Definition Name + anything)
  • COL_<ADef><BTemplate>* (Sprite A Definition Name + Sprite B Template Name + anything)
  • COL_<ATemplate><BDef>* (Sprite A Template Name + Sprite B Definition Name + anything)
  • COL_<ATemplate><BTemplate>* (Sprite A Template Name + Sprite B Template Name + anything)
  • COL_<ADef>* (Sprite A Definition Name + anything)
  • COL_<ATemplate>* (Sprite A Template Name + anything)
  • COL_<BDef>* (Sprite B Definition Name + anything)
  • COL_<BTemplate>* (Sprite B Template Name + anything)
  Definition names are those seen in "Sprite Definitions" list on the Sprites and Paths dialog. Template names are seen in the "Template" dropdown box below it.
• Play media clip: A media clip can play when the collision occurs.
• Script: When a collision occurs the Player object raises the "OnSpritesCollide" event that can be trapped by script code, which in turn can respond by doing anything supported by scripting. The name of the layer where the collision occurred, the indexes of two sprites involved in the collision as well as the index of the collision definition are passed as parameters.

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.