Simon Donkers
Game Maker
Home > GameMaker > Articles > Coding efficiency

Coding efficiency

German translation A german translation of this article is made by Windapple and is available at the German GMC.

by Simon Donkers

Many people complain about the fact that Game Maker is very slow. However speed can differ greatly from your programming technique. Many things can be performed much more efficiently. This varies from using local instead of global variables but also things like which objects has a collision event. Within this article I hope to share some insight on how to write your code faster and shorter.



Game Maker has a very advanced collision system which is capable of some advanced collision checking. However in 99% of the cases you do not need this. Also as this system is complex it isn't very fast. Lets give some basic things to speed up collision events. If you have one object player and you have 100 objects bullet heading towards the player. In that case you can give all 100 objects a collision event with the player. However you can also give the player one collision event. The last option will save Game Maker on quite of calculations and thus save speed. When having collision events start them from the object which there are the fewest of. You can even make your coding more efficient by having one parent object of all those 100 bullets so you only need one collision event. This makes coding a lot more efficient because A: you only need to write your code once and B: if your code works for one bullet it will also work for other bullets. While at the same time you keep the possibility of giving your bullets special actions. You can for instance give each bullet within it's create event a variable damage. The higher that variable is the more damage is done to the player and in the collision event you simply deduct the value damage from the health variable. But what if you want a few bullets to have a special collision effect. In that case you can for instance define a user defined event within the parent object with the default behaviour when there is an inpact. While every object that needs a different behaviour gets there own user defined event and in the collision event you simple execute this user defined event This way 90% of the bullets can be the same with only writing your code once while you still allow for certain bullets to act differently.

An other very important element in optimizing collision event is precise collision checking. While precise collision checking is a nice thing it is very often not needed. If you just set a bounding box around the sprite you are quite often already done and you save a lot of calculations from Game Maker with this. The amount of time you need precise collision checking within a game is very rare. Also hardly any other game development platform makes use of precise collision checking because precise collision checking will make collision checking much slower.

A final thing for collision checking is the use of solid objects. The use of solid objects can help make collision checking a lot easier but hardly anyone uses it right. Solid objects are easy so you can make objects such as floors solid within a platform game so you can easely use collision checking routines. If everything you can't move through is solid you can easely use place_free to detect whether you can stand somewhere without having to check for every single object. What people do not know is that collision events with solid objects are handled completely differently as collision events with non-solid objects. I won't go into details here about the technique however if you have a collision with a moving solid objec there is a big change that the collision checking routines of Game Maker fail and your objects get stuck. So remember this rule: "Never use moving solid objects!!!". Mark Overmars told me that this is the most common made error within games. So never ever use solid moving objects.

1 2 3 4