The tedious parts of game development: optimisation

I’ve put it off for months, but it’s time to finally acknowledge the fact that Arcus runs like a pig in quicksand and needs some serious optimisation.


I have no formal training or education in programming. I’m entirely self-taught, and have only learned most of what I know in the past year. As a result, my code is often a bloated, inefficient mess. I have only the vaguest idea of what a memory leak is. Load order? Texture caches? Not a clue.


(Please forgive me for the meme usage. I promise it won’t happen again).

My problem solving tends to be reactive rather than proactive. Something breaks, I turn to Google. This is usually fine for the obvious bugs and other issues, but not so great for those more subtle issues; the ones that creep up on you slowly. As I work on Arcus, the game and its levels are getting progressively more complex. More math is necessary, levels have more objects and particle effects, and the code gets more and more inflated. Redundant code is left in, broken things are patched, then broken again, then patched again. As a result, some of the larger, later levels are starting to show signs of slowdown. My PC is pretty powerful, so if it’s a problem on my machine, then it’s definitely a pretty major problem.

I’m not going to provide optimisation tips here – I’ve approached the problem in the same way I approach most problems – Google it – and am far, far, FAR from an expert in this. But here are some things I’ve been doing with Arcus to improve performance. I’m no longer seeing any slowdown, and I haven’t managed to break anything, so I seem to be doing something right.

The wall/floor/ceiling lasers, a relatively new addition, were a huge cause of slowdown. You can see the lasers in this video, and the framerate is noticeably awful.


I wrote a script to calculate the distance between an object and a wall in a specified direction. The original script used quite a bit of trigonometry to calculate the distance in any direction between 0 and 360 degrees, but as a result, was quite intensive when there were several lasers in a level at once. Admittedly, it was probably horribly written, and could have been vastly optimised by a better coder than I. Instead of that, though, I just rewrote it to only be able to calculate in exactly horizontal or vertical directions (i.e. 0, 90, 180, 270 or 360 degrees), thereby vastly simplifying the maths.

The second issue with the lasers was the effect it makes when in contact with a wall (that little particle effect you can see in the video). I thought my code was only creating a few particles a frame, but thanks to a broken ‘while’ loop, it was actually creating thousands. While it took me quite some time to spot this, the actual fix only took a matter of seconds.

Another huge cause of slowdown was thanks to the script I describe in this post.

While it didn’t cause consistent slowdown, it did make each level take quite a bit longer to load, and there was about a 1-2 second period when the framerate chugged every time you restarted. The initial script consisted of 301 lines of code; after sitting down with a pencil and paper and thinking it through, I managed to condense it to about 50 lines. I’m sure there are lots of other chunks of code I’ve written that I could do something similar to as well.

Which is basically what the third main part of optimising Arcus was about – going through all of my existing code to move redundant bits and condense older, inefficiently written sections.

Overall, it wasn’t the most exciting of weekends spent coding, but it was a learning experience, and it has massively improved the performance of Arcus.

Leave a Reply

Your email address will not be published. Required fields are marked *