Optimization is a special keyword in the world of video games. If you go to player-centric websites chances are you will hear it a lot.

Video games are interactive simulations and simulations are a very specific type of software. You don’t program a game like you program a business app. Games need to update themselves over time, not only when the user click on a button, and this can quickly lead to performance problems.

Here are some tips about optimizing your game based on what I experienced during the development of our game, Reckless Squad.

1.     Profile

You can’t just optimize all your code, it’s not realist. You don’t have time for that and you will needlessly obfuscate your code base and make it harder to maintain.

So how do you decide which parts of your code need to be optimized?

Enter profiler. A profiler can take many forms, but its purpose is always the same: telling you how long the different parts of your code take. All the major IDE ship with one, and if you don’t have one you can always do it manually with the good old time() function.

Start by profiling on a high level, is it your update() or your draw() function that takes this much time? Once you know you can be more specific and see if it’s updatePlayer() or updateUserInterface().

2.     Don’t run it

Now that you know what is slowing down your game, you can start optimizing it. Here is the most effective and easy way to make a function run fast: don’t call it.

If it’s not running, it won’t take time, it’s obvious!

Okay, it’s not that simple, you wrote this code for a reason, right? You still need to run it, but maybe not that often.

Reckless Squad is a RTS game, with a lot of units, all updating at once. I quickly discovered that the AI was what took the most time. I asked myself: “is it really important that the AI run at 60Hz?” The answer was obvious: no.

So instead of running the AI code every time, I do it less often. Performances increases.

There is a problem with this approach: every time the code does run, you will experiment a sudden performance drop. Spreading the execution of this function across the frames will prevent this.

In my example I only update the AI of a fragment of the unit list each frame, allowing a sort of load balancing.

3.     Know your platform

Every platform, language or SDK have its little secrets. Knowing some of them can be interesting from a performance standpoint.

For Reckless Squad we’re working with Lua. Lua is already a fast language but extra-performances can be obtained if you know how it works. There is some good information about it on the wiki.

To give other examples, using StringBuilder to concatenate strings in .NET or calling reserve() on the C++’s vector are other good practices specific to their platform/language/framework.

Similarly if your platform has 2 cores, it’s a good idea to use them effectively. And if you’re working for console or mobile devices, knowing your platforms and its pitfalls is increasingly important.

4.     Think like a computer

Object Oriented Programming is cool. It’s easy to learn and to use because it naturally maps our way of thinking as humans. My computer in front of me is an object, it’s actually in a turned on state and it execute various methods like shutting himself down. It’s seems very natural to think like this when you code too.

However it’s not how computers work. Computers are calculators, processors. They take a bunch of input data and apply to them a specific transformation to get different output data.

If you can think this way too, you can present the problem in a more computer-friendly fashion.

I won’t go into details about it, because others had already done a great job:

• The Pitfalls of Object Oriented Programming (Sony SCEE)
• Data-Oriented Programming (Or why you might be shooting yourself in the font with OOP) (Noel Llopis)
• Three Big Lies: Typical Design Failures in Game Programming (Mike Acton)

Actually, for Reckless Squad we use OOP almost everywhere. Except in a few strategic places where performance is critical.

So I’m not saying you have to toss OOP out of the window, but we have multi-paradigm languages for a good reason: don’t hesitate to change your approach depending of the problem.

5.     No magic

Despite a popular belief among some players, optimization is not magic. No amount of optimizations will ever make Crysis work on a VoodooFX.

You have to draw the line, to choose a minimal configuration and stick to it. If the game runs fine on this platform, then you’re good, you don’t need to optimize anymore.

Maybe you’ve spotted some places where some optimizations can be done, but don’t do it. If it ain’t broke, don’t fix it.

You’re making a game, not a benchmark.

This entry was posted on Friday, September 3rd, 2010 at 4:04 pm and is filed under Technical. You can leave a response, or trackback from your own site.