A german translation of this article is made by Windapple and is available at the German GMC.
by Simon Donkers
gmmentor@simondonkers.com
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.
Collisions
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.
Very nice article, Simon. I learned a couple of new things, and thanks for writing this. You use "and" too many times inside your written piece, but I read through it.
Can't wait to see more articles,
Timmins
Scotley posted at 2005-03-22 09:45:38
Absolutely ripper. Have used c# a bit so I realise most of this, but good to get a refresher! Awesome work Simon.
Vishal posted at 2005-04-05 16:07:53
Great tips and a great game(Bacteria 2), probably one of the best games made in GM.
Red man can posted at 2005-06-24 09:12:23
my sirname is coidling! =)
Marlow posted at 2005-07-16 19:59:25
wonderful...just the type of information I needed to read to make my programming less sloppy and actually easier to write... I especially enjoyed your material about using the alarm event rather than the step event, view usage, and parent relationships... these will help me out the most. I look forward to more of your articles... Thank you.
Looking for advise on Ai development for a simple game of checkers. All the movements work properly but I want Ai to play against the computer. Any suggestions? alberley@yahoo.com
Very nice! I really like it. It's a great articles. This will really help a lot of people (me included). Your a help to the GM world.
eleet posted at 2005-12-08 00:38:22
For you question about the game checkers, it is not a simple thing to make a AI for checkers, in fact no one in the world yet found a way to make a perfect AI for checkers there are just to many ways to move and play. Also, if you want the AI to play the AI then all you have to do is make a simple script that says whois turn it is to play and make the AI the player 1 and player 2. You can also have a loop set so they will play the game over and over for millions of times. But trust me AI for that type of game is in no way ez to make.
A german translation of this article is made by Windapple and is available at the German GMC.