Defining Sprite Collisions

This is part of a series of pages describing the Sprites and Paths dialog. This page describes the Collisions tab.

This tab allows you to specify membership of a sprite template within up to 16 collision classes. A sprite may be a member of any number of collision classes, but as more sprites become members of more collision classes, the work done by GameDev starts to increase exponentially (depending on what kind of collision tests are defined in the Collision Definitions dialog). Ideally, the game would be concerned only with collisions between the player and various other types of sprites. This way GameDev only needs to loop through N sprites testing for collisions with the player instead of N-squared sprites, checking each sprite for collisions with all other sprites (O(n) vs O(n^2) if you're familiar with "Big O" notation).

The collision classes listed on this tab, and the collision tests performed among them, are defined and manipulated on the Collision Definitions dialog. This tab is only used to specify which templates are associated with sprites in which collision classes. For instance, assume sprite template "PlatformT" is a member of the "PlatformC" collision class, and sprite template "PlayerT" is a member of the "RiderC" collision class. Also assume you have a sprite "Platform1" based on template "PlatformT" and a sprite "Player1" based on template "PlayerT". And assume that there is a collision test defined between "RiderC" and "PlatformC" to force sprites in the "RiderC" class to ride on sprites of the "PlatformC" class. When collisions are tested, the Player1 sprite will be tested for collision with the Platform1 sprite because the template for Player1 puts it in the "RiderC" class, and the template for Platform1 puts it in the "PlatformC" class. Since these classes have a collision test defined between them, all sprites based on PlayerT will be tested for collisions with all sprites based on PlatformT.

The case for selecting multiple classes would probably usually involve the player sprite. For instance, the player sprite may act as a "Rider" on platforms, and also as a "Bouncer" of ... say, fruit. When a "fruit" sprite falls out of a tree, it could bounce off of anything in the "bouncer" class. Having multiple collision classes allows finer grained control over which collisions your interested in. This can be important if you need to refine the number of collision tests to improve efficiency.

Note: The collision class names by default are simply numbered 1 to 16. Each map can have its own set of collision class names. When you activate this tab, you may see the numbered collision class names, even if you have defined your own names. If this is the case, you need to select a path in the top left corner to indicate which map you're template applies to. There needs to be some reference to a map in order to load the appropriate collision class names from that map.

The "Select All" button makes the current template a member of all collision classes. The "Clear All" button makes the template a member of no collision class. The "Define..." button displays the Collision Definitions dialog.