Collision Example

Displays various collision methods and explains how they function (Check the game info with F1).
Source + Executable

How Collision Boxes Work
There are two main types of collision activations in GM, precise and non-precise collisions. Non-precise collisions use something called a bounding box, which is a rectangle that is the maximum dimensions of your sprite. Precise collisions also use a bounding box, but will only trigger the collision event if a non-transparent area of the sprite is collided with. Here is a visual of this (the pink is the bounding box):



A collision mask will retain the same collision area across frames, and even sprites. This is very useful because you may want to increase or decrease the size of your character's collision box while developing the game, and you also may want to ensure there is a consistent box across all sprites for any given object to ensure you do not get faulty collisions. In something like a platforming game, you will certainly want to use a mask so that you character does not get "stuck" in the ground while performing actions because of an ever changing collision area across the various sprites / frames for that character.

How Game Maker Handles Collisions
There are collision events, which are the most basic way to define collisions, and collision functions, which give you much more control. Specifying a collision event is easy, just click Add Event for the object in question and choose the object. You can use the word "other" to refer to the object you collided with in collisions. This is very useful, for instance, if you have a bullet object that when colliding with an enemy will decrease their life. Functions give you much more control, and generally speaking you will be using these mostly if you are making a more advanced game. Refer to the GM help file for more information on all of these commands.



Every object you create has a checkbox to enable it to be "solid". This is essentially an object variable. However GM will treat collisions differently depending if this is enabled or not. To put it simply, if a collision of two objects happen, if either is solid it will not be possible for the objects to "pass through" or overlap each other. This is because the objects are reset to the position before the collision occurred. If both are non-solid, the collision event will execute and the objects will continue their paths. This ONLY applies to the GM collision event, if you use functions in something like the Step event, solid is simply a way to separate objects into groups (ie. place_free() checks to see if there are no collisions with solid objects only, while place_free() checks for collisions with all objects). So if you had two solid objects, and you wanted to see if they collided using place_free, they would not reset to the position before the collision. This may be a bit confusing when you think about it technically, but it's primarily done to make it easy for beginner users to understand that solid objects will not be passed through by objects.

General Collision Tips
- Disable precise collision checking for sprites that do not need it. By default it is on, and more likely than not you will actually want this off. Having it on will only increase the time to process your collisions, and will increase memory usage. So if you have a sprite that is a rectangle or square, it will not need this because the bounding box is a rectangle. Additionally, many of the graphics in your game will likely use masks or will be purely graphical (overlays, user interface graphics, etc) so you will not need this option.

- Collisions can easily use up a lot of processing power. While it is fast for what it does, many people make the mistake of making thousands of objects that have collisions and then wonder why their game runs slow. The important thing to realise is this all works in factors. Let me give an example:

You have 500 "wall" objects. You make a player object who simply cannot pass through these wall objects. That is 500 collision checks a step (most GM games are 30fps, which means 30 steps a second). This is very easy for the game to do and has no problems.

You then add 10 enemies to the game who also cannot pass through walls. Now you are at 5000 checks a step. A lot of power is going to be used just for collisions alone now.

All characters (10 enemies plus the player, 11 characters) can shoot bullets. Bullets can hit enemies and walls. For every time you shoot, it has to do 511 extra checks while the bullet is present. Slowing the game even further.

As you can see, this all easily adds up. However, there are many tactics to combat this which I won't go into great detail, but mainly involve processing things on screen or near the screen only, cutting up your areas into smaller chunks, using the instance activate and deactivation functions, and more.

- Much like above, in addition to having too many instances, make sure you use collision check functions only when needed.

- Collision boxes rotate with the sprite, and scale with the sprite if you use the image_angle, and image_xscale / image_yscale variables.

SCRIPT OF THE WEEK:

Script:sFont(font,colour (optional),horz alignment (optional),vert alignment (optional));
Code:
Example: sFont(Times10,c_white,fa_center);
Description: Changing fonts is something you may do a lot in your game, but even if this isn't the case, you are very likely to change the font alignment and colour. The above example code is the equivalent of typing:


As you can see, this will save you a lot of time and give you more control. Specifying -1 on any argument will keep it the same, and leaving it blank will set it to the default values (read the script to see what they are). To add this as a script, simply create a new script called sFont, then copy and paste the code into it.