Tales of a Game Engine: The Game Loop

I’m writing a game engine in Java for a university game design course.  The scope of the course is rather limited, and I could easily hack together a satisfactory game without a good engine.  However, since I’m interested in game design, I’m attempting to make a versatile, efficient engine that I can use for my future game design experiments.  I like learning new things, and I thought I’d post a log of the things I find interesting as I build this game engine so that others can learn from my experiences, successes, and mistakes.

This is my first game engine, and though I’m not new to programming, I am new to game development in Java.  By no means do I consider myself an expert.  This is all new and exciting to me, as I get to experience first-hand the kinds of decisions programmers have to make when designing an application.  One of these experiences I’m currently working on is the game loop.

Hypothetical Scenario:

Say you have a state-of-the-art computer, and you want to write a game for this computer.  If you have a basic update-then-render loop (what Game Maker does by default), no matter how fast of a computer you use, the number of updates will only equal your frames per second setting at best.  Increasing the number of frames per second under this system is the only way to increase the number of updates per second, but we have to keep in mind that monitors have a limit on how many frames they can render in a given second: after you set the FPS over that limit, you’re just wasting your time.  In a simple update-render game loop, using an FPS setting of 60 will give you 60 frames per second and 60 updates per second.  Any leftover time is spent sleeping, which is nice and friendly to other applications, but typically most of this time is wasted, as most users don’t play games and run CPU-intensive applications at the same time.

So, since I hate seeing time wasted, I decided I’d try a system I’d read about but never worked with before: Separating the update and the render steps.

The general idea:

Run at the goal fps, and use the remaining time to perform as many updates as you can.  If the previous system was update-render, this system could be described as update-render-update-update-update… you get the idea.

Why this is a good thing to do:

This is great for things like physics -specifically raster collision-checking- which increase in accuracy when run more often. It means that your game isn’t “wasting” large amounts of time, and depending on your engine’s structure, it is probably more efficient than using separate render and update threads.

The algorithm:

Each period of time (1/FPS, so about 30 or 60 or 75 times a second)
If there is any time left over,
     While there is enough time left,

Simple, isn’t it?  Using some logic and tuning (i.e. what “enough time” is), I’ve been able to get my (mostly-empty) game to run at 60 FPS while performing almost 200 updates per second. Worst case it performs the same as a system that links updates and rendering, best case you get a huge number of extra updates every second.

There you have it.  A simple algorithm for separating the frame rate and the update rate.  If all the “real” games are doing it, why can’t mine?

Further reading:

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: