Category:Hints and Tips

Optimising your Game's Performance 1: Sprites

If there’s anything that ruins a fun game, it’s it running so slowly it verges on being unplayable. Although it will sometimes be down to an underpowered computer or graphics card, much of the time it’s simply down to some some slow code and we can fix this by trying to optimise the offending code.

Remember that even if your game runs smoothly on your own computer, it may not for people with older/cheaper/worse systems. You’ll presumably be wanting to have as many people as you possibly can experiencing the game as you do, so optimisation is still very much worth doing. If you can, test your game on as lousy a system as you can get hold of. Run it in debug mode (or just draw the FPS somewhere), find the areas where it’s slowest, and see if you can figure out why.

The first area of focus will be the first thing you can edit in Game Maker: sprites

The majority of objects in a game will each contain a default sprite, which can then, through code or drag & drop, be altered in a number of ways. And while the Draw event seems like the most logical way to go for sprite manipulation, it is a lot slower than other methods, requiring every step to redraw things while the object already has its own default drawing. One thing to remember is that the majority of transformations can be handled through variables such as image_xscale, image_yscale and image_alpha. Setting these just once or whenever needed is a far quicker way of manipulating the appearance of an instance than using something like draw_sprite_ext and having it set itself 30 or more times per second.

Sprites, images with optional animation, are each drawn as two textured triangles by the hardware, and in many cases the triangle count can be reduced through simple merging. If you have a man made up of separate head, torso, arm and leg sprites, see if you can find a way to put all or some of these into one single sprite. As long as the resulting sprite isn’t huge (either in the subimage count or actual dimension department), the speed of its drawing will be greatly increased and the slight size increase will be minimal.

There are many other applications in which sprites could be merged.

Take a side-on platformer/shooter hybrid, in which your main character has the choice of four different guns. Your direction in creating this would probably be to create the player holding nothing, then the guns separately, using code to bring the player and the selected weapon together as one. However, this doubles the amount drawn. A better method would be to create four different player animations –one for each gun. Though this is a slightly longer drawing process on your part, not only does it bring the number of triangles drawn from four to two, it also reduces the amount of code processed. Another example: an overhead space shooter. Say there’s a powerup which gives your spaceship a temporary forcefield. The quickest way for Game Maker to interpret this is to make a second sprite which displays both the forcefield AND the ship, instead of a forcefield sprite drawn over it.

Though techniques like these increase the size of the game, it’s a very minimal increase (a few kilobytes), and while they increase the amount of memory required to play it, it will reduce the power required to run it allowing low-end computers (or even better ones depending on the complexity of the game) to run to more smoothly. The general idea of game development is to strike a balance between everything being done – a few extra sprites has little impact on the memory a game requires, but shortening the code can increase performance significantly, and allows for other areas to be fleshed out for a better, more polished game as a whole.