Collision Systems/

From ENIGMA
Jump to navigation Jump to search

One of the most fundamental features of a game development engine is the way that it handles collisions. A collision occurs when two instances attempt to occupy - or occupy - the same space. Determining the specifics of how this occurs is up to the collision system. There are several approaches to this, many of which are already implemented in the ENIGMA engine. Generally, a collision system will provide a standard set of functions for testing various collision conditions, and then the Event system will provide a collision event which will fire when certain conditions are met (by checking one of the provided functions, such as place_meeting). The collision area for an instance or graphical object is often referred to as a Mask. There is also an article on Instance and Motion Functions that covers collision functions.

Existing APIs

  • None - Provides no collision functionality. Originally this option was provided as the default API when ENIGMA had no collision functionality yet. The option was kept as an option for programs which do not require in-built collision functionality.[developer confirmations: 1]
  • Bounding Box or BBox - The concept of the bounding box is essentially a rectangular area encompassing the expected area of collision relative to an instance's coordinates. A collision is very easy and efficient to check for by performing a simple rectangle overlapping check. This was the first functional collision system to appear for the API system.
  • Pixel Perfect or Precise - A bit mapping of every pixel in an image (1 bit per pixel) to indicate whether the pixel is part of the collision mask or not. such a mapping could either be computer generated by transparency threshold, or provided by a 1-bit-per-pixel bitmap mask. This is the most powerful masking method, capable of covering any image, but it is also the most inefficient (read: slowest) due to many individual pixel checks throughout the mask. Various things can be done to speed up efficiency a little, such as performing a BBox check prior to actually checking individual pixels, but in the end it's usually better to use one of the other, more efficient masking methods. This method can also be disadvantageous for images that have pixels that jut out or hooks, like the arms on a person, which can cause him to either collide weird or hook on to something by accident. In those cases, it is desirable to either use a separate image mask or one of the other masking methods.
  • Box2D

Other possible systems

  • Circle - Performs a very simple and very efficient distance check between two instance coordinates. This can be visualized as a circle encompassing each instance. This is more efficient than a rectangle check, and provides great collision checking for encompassing an instance that can graphically rotate (such as a top-down car). However, a circle would not be a good mask for a wall.
  • Polygon - Since not everything can be represented in a single nice rectangle or circle, the next fairly efficient masking method is that of the polygon. Given an image, a polygon mask may be computer generated as either a convex hull or an approximated outline of the pixels in the image which meet a given transparency threshold (that is, transparent pixels or mostly transparent pixels around the image are ignored), or may be user-defined. Usually, the polygon will then get converted into triangles to test for collisions.
  • Polygon Extensions - A single polygon may not be sufficient to represent the mask, for instance, if the mask has a hole in the middle which would not cause a collision (e.g.: stay inside a ring), or the mask may be segmented into multiple parts. Some extensions to polygons have been suggested, such as polygon subtraction and multiple polygons. Polygons can also be used to represent bounding boxes (although perhaps inefficiently), but more importantly, rotated bounding boxes.
  • Per-Sprite or Per-Image - Object boundaries aren't always static; they can change from one frame to the next. Consider an explosion. It starts out small, and grows, sometimes in disproportionate directions. It may not need to cause damage to distant objects until it gets big enough to reach it, which is where a per-image mask might be useful. On the other hand, for something which animates, but maintains a generally static area, such as the player, or a rotating coin, a per-image mask would be excessive, inefficient, unnecessary, or even harmful (if at one of those frames, the coin is invisible, you may time it just right so that you go through the coin without ever collecting it!), and a per-sprite mask would be more appropriate.
  • 3D - The masking methods discussed here have all been 2d systems. Once you expand into 3 dimensions, 2d collisions become less and less useful. The 3d world has many collision approaches, and as ENIGMA develops and expands into 3D, we may see some of those approaches become integrated.