Game Development Reference
In-Depth Information
to the video hardware, and this preparation can be quite CPU intensive. As long as
you protect any shared data with the game logic, such as the location and orientation
of objects, you should achieve a good performance boost by doing this.
AI is a great choice to put in a background process. Whether you are programming a
chess game or calculating an A* solution in a particularly dense path network, doing
this in its own thread might buy you some great results. The magic length of time a
human can easily perceive is 1/10th of one second, or 100 milliseconds. A game run-
ning at 60 frames per second has exactly 16 milliseconds to do all the work needed to
present the next frame, and believe me, rendering and physics are going to take most
of that. This leaves AI with a paltry 2
-
3 milliseconds to work. Usually, this isn
'
t
nearly enough time to do anything interesting.
So, running a thread in the background, you can still take those 2
-
3 milliseconds per
frame, spread them across 10 or so frames, and all the player will perceive is just a
noticeable delay between the AI changing a tactic or responding to something new.
This gives your AI system much more time to work, and the player just notices a
better game.
Running physics in a separate thread is a truly interesting problem. On one hand, it
seems like a fantastic idea, but the moment you dig into it, you realize there are sig-
nificant process synchronization issues to solve. Remember that physics is a member
of the game logic, which runs the rules of your game universe. Physics is tied very
closely with the game logic, and having to synchronize the game logic and the phys-
ics systems in two separate threads seems like an enormous process synchronization
problem, and it is.
Currently, the physics system sends movement events when actors move under phys-
ics control. Under a multithreaded system, more concurrent queues would have to
buffer these movement events, and since they would happen quite a bit, it might
drop the system
s efficiency greatly.
One solution to this would be to tightly couple the physics system to the game logic
and have the game logic send movement messages to other game subsystems, like AI
views or human views. Then it might be possible to detach the entire game logic into
its own thread, running separately from the
HumanView
. With a little effort, it may
even be possible to efficiently separate each view into its own thread. I
'
ll leave that
exercise to a sufficiently motivated reader with a high tolerance for frustrating bugs.
'
