One thing GSB does that I’m quite proud of, is run an ‘idle manager’ to smooth out the frame rate. In concept, it’s pretty simple. There are some jobs that need doing in the near future, but not *NOW*, and some that are optional. The idle manager works out that we have some spare time, and does them accordingly. In code terms it’s a lot more involved.
GSB has a target frame rate, and checks the time since last frame in the main game loop. If there is some ‘spare’ time before the next frame, it tells the idlemanager, and checks again once the idlemanager has finished. The idle manager has a list of tasks, and it cycles through them in turn. Two of the common tasks are these:
1) Check that we aren’t running low on any pre-cached particle effects, and if we are, pre-cache some new ones ready for future use
2) Check if any laser blasts which are missing their target happen to intersect with some debris. If they do, make the debris explode.
task 1) is vital for performance, task 2) is optional graphical fluff.
The implementation of an idle manager is cool because it allows you to use the fluctuating rendering-demands per frame to your advantage. It also means you eek as much usage as possible out of a single processor core. In multi-core, multi-threaded systems, this is all done much better by having a separate thread, which can spin off and do this stuff at your leisure. There can be synchronisation issues in that case though (I don’t want to change the list of cached particles while another thread is altering them too etc).
If you can’t be bothered with the hassle of multithreading, I recommend implementing something like this idle manager at the very least, assuming performance is vaguely an issue for you. I’m writing the idle code for my new game right now, and it will be a bit cleverer, and more involevd and possibly multithread stuff too. I hate to think the game would drop a frame when it could be avoided by doing this sort of stuff.