336 7. The Game Loop and Real-Time Simulation
ject, over which the local machine has authority and a “proxy ” version that
contains a minimal subset of the state of the remote object.
Peer-to-peer architectures are made even more complex because author-
ity over an object sometimes needs to migrate from machine to machine. For
example, if one computer drops out of the game, all of the objects over which
it had authority must be picked up by the other machines in the game. Like-
wise, when a new machine joins the game, it should ideally take over author-
ity of some game objects from other machines, in order to balance the load.
The details are beyond the scope of this book. The key point here is that multi-
player architectures can have profound eff ects on the structure of a game’s
main loop.7.7.3. Case Study: Quake II
The following is an excerpt from the Quake II game loop. The source code for
Quake, Quake II, and Quake 3 Arena is available on Id Soft ware’s website, htt p://
http://www.idsoft ware.com. As you can see, all of the elements we’ve discussed are
present, including the Windows message pump (in the Win32 version of the
game), calculation of the real frame delta time , fi xed-time and time-scaled
modes of operation, and servicing of both server-side and client-side engine
systems.int WINAPI WinMain (HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
MSG msg;
int time, oldtime, newtime;
char *cddir;ParseCommandLine (lpCmdLine);Qcommon_Init (argc, argv);
oldtime = Sys_Milliseconds ();/* main window message loop */
while (1)
{
// Windows message pump.
while (PeekMessage (&msg, NULL, 0, 0,
PM_NOREMOVE))
{
if (!GetMessage (&msg, NULL, 0, 0))
Com_Quit ();
sys_msg_time = msg.time;