Game Loop? No thanks!

There are so many tasks involved in the creation of computer software. To me, identifying the necessary architecture is one of the most important and one that if done wrong can mess up your project from day one.

I am not going to start a debate about the merits of “iterative” approaches over “waterfall” here. The bottom line is that one way or the other you need to come up with a structure for your code that does not obstruct you from achieving whatever is that you are trying to achieve.

Here I am trying to make a game. The obvious approach is, of course, to look around first and see how other people that are making games recommend to structure the code of a game project. What are the best practices to follow and why? Needless to say there are a lot of books out there and the web is full of examples. This subject is huge but in this post I am going to focus on a very common programming model that is used in almost every game.

The game loop

Traditionally games are structured around a very tight infinite loop, know as the “game loop”. Within that loop the game checks for user input, updates the state of the game and draws the screen. An over-simplified version of that loop would look like this:

bool exit = false;

The loop will process everything as fast as possible and then repeat until the game is finished or the user opts to quit, whichever sets the “exit” flag to true.

There are a few reasons why a game has to be structured like this. Most games are required to update the screen and the game world in real time, in this case meaning a frequency that is around 60 herz. Within that tiny 1/60th of a second the game needs to process the input from the player, the network and the other systems that it interacts with, it needs to run a physics simulation, calculate the AI behaviour, play the music and all the sounds, render a 3D world and display everything on the screen before it starts all over again.

The game developers need to squeeze as much as possible within that time-frame which means they have to bypass all the unnecessary abstractions of the operating system, like the message queue and cut to the chase. With the game loop the program aggresively utilizes all the cycles it can get from the CPU and video adaptor and uses low level libraries (like DirectX or OpenGL) to communicate with the hardware directly.

A game loop is not always necessary any more

Recently I came across this post by Shawn Hargreaves about game loops in winforms. It starts by explaining what is the different approaches between an XNA application and a WinForms one:

WinForms and XNA have quite different ideas about how a program should run.

XNA assumes that games are always in motion, moving and animating. It constantly cycles around the game loop, calling your Update and Draw methods. This is convenient for most games, but wasteful if the program reaches a static state, because XNA will keep calling Draw even though the image has not actually changed.

WinForms assumes that programs tend to just sit there doing nothing, and only wake up when the user interacts with them by pressing a key, clicking the mouse, etc. It uses an event based programming model, where input and paint requests are delivered to the program via the Win32 message queue. If no messages arrive, the program runs no code at all and thus consumes no CPU.

Both WPF and Silverlight follow an approach similar to WinForms, as described above, in the way they treat a program’s execution. The assumption is that the program generally waits for events from the user or the OS in order to do something, and sits idle the rest of the time. However, these two frameworks introduce a very important element for the creation of more “dynamic” interfaces and, well, games: The concept of “animations

Storyboards and animations replace the need of having a game loop just so that you can change the game screen, or parts of it, smoothly for a short period of time. And for some games that’s all that you need.

Take for example Hexpand, the turn-base strategy game I am working on. Most of the time it behaves like a WinForm application, sitting there waiting for the players to finish their turn. The AI can run in a different thread passing orders to the game session the same way a player does. In this scenario the event driven model fits perfectly and using storyboards to animate the various UI components and unit movements is more than enough. A game loop would be such an inefficient way to structure this game.

Most games still need some form of a game loop

Most real time games that is, or games that have heavy animation requirements. Silverlight and WPF animations don’t come cheap. Each instance of them comes with a timer attached, effectively introducing a mini-game loop on the spot. They are quite flexible and customisable but they need to be carefully used, otherwise they can have a substantial impact in performance. It might make more sense to have a central timer serving as a game loop to update the visual state of the game instead of multiple animations competing each other for system resources.

In my case, animations provide a handy alternative to the game loop approach that allows me to keep the event driven model for my game without compromising its visual appearance.

This entry was posted in Uncategorized and tagged . Bookmark the permalink.