Game Development Reference
In-Depth Information
void UpdateProcesses(unsigned long deltaMs)
{
ProcessList::iterator i = m_processList.begin();
ProcessList::iterator end = m_processList.end();
while (i != end)
{
Process* pProcess = *i;
pProcess->VOnUpdate(deltaMs);
++i;
}
}
The contents of the
VOnUpdate()
overload could be anything. It could move the
object on a spline, it could monitor the contents of a buffer stream and update it
accordingly, and it could run some AI code. It could monitor user interface objects
like screens and buttons. If everything in your game were run by a process, you could
actually get away with a main function that looked like this:
void main()
{
if (CreateProcesses())
{
RunProcesses();
}
ShutdownProcesses();
}
It may sound crazy, but Ultima VIII
'
s main loop looked almost exactly like that, give
or take a few lines.
Think Like a Sim
On The Sims Medieval, every Sim had two processes that were constantly
running. One process handled the AI and ran any interactions on the Sim
(like eating, sword fighting, and so on). The other thread was the
SimUpdate, which mostly dealt with the simulation of the Sim itself. This
process took care of things like decaying commodities, moods, and any
other noninteraction updates the Sim needed to make. This system worked
remarkably well. You could actually Ctrl-Alt-Shift-click on a Sim and break
the execution of its specific interaction process! This made debugging the
internals of a particular Sim a lot easier.
There are a few wrinkles to this wonderful design that you should know. If creating a
system to handle your main loop were as easy as all that, I wouldn
'
t bother devoting
so much time to it. The first big problem comes when one process
'
s
VOnUpdate()
