Re: John Carmack's QuakeWorld plan

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Fri, 2 Aug 1996 15:44:08 +0200 (MET DST)

Date: Fri, 2 Aug 1996 15:44:08 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <>
Subject: Re: John Carmack's QuakeWorld plan

My apologies to those who might consider this off topic for
quake-dev - I hope to get this resolved soon. Feel free to
forward this to quake-servers. I am not on that list anymore
and will not post to a list I have not subscribed to - and it
might even be off topic.

----- Begin Included Message -----

>From Fri Aug 2 14:57 MET 1996
From: John Carmack <>
Date: Fri, 2 Aug 96 07:55:44 -0500
To: Bernd Kreimeier <>
Subject: Re: q&a/QuakeWorld

> a) state updates that affect subsequent state updates (movement,
> decreasing health)
> b) state updates that only affect visual
> appearance and view (change skin texture, view tilting, MDL frames)
> Does this make sense?


> More generally, for each category of update packet, one could
> assign a priority/relevance value. Updates are sent to the clients
> based on relevance - important (a) changes ASAP, less important (b)
> ones during low traffic/idle times, later on. See below.

It has been my experience that you need to optimize for worst case behavior,
where all of the updates are important. Being clever in non-worst case
situations leads to larger swings in quality of service.

We followed this belief in the graphics engine, where we sacrificed peak
performance for level performance at every oportunity.

> Increased sampling of inputs, but updates depending on the
> amount/significance of changes? This means bandwidth requirements
> increases only during times with lots of important events.

That basically happens allready to a factor of four or so. If you turn on
cl_shownet, when you are running around by yourself you will see numbers
like 40-50 or so. When you get into a big firefight, it will top 200. The
light case could indeed be optimized further, but it wouldn't help the game.

> >The proper way to address this is by changing the server model
> >from a game style loop to a fileserver/database style loop.
> I.e. asynchronous updates on first-come first-served? And the
> server calculates the physics, too, to ensure consistency. Is
> consistency the real issue here?

Yes. I fundamentally believe in authoritative servers. I do not
go for the distributed simulation aproach. The programs are
complicated enough as it is, and going to a full distributed aproach
will lead to a massive amount of additional development work and
lots of hard to track bugs.

Sometimes even though aproaches are possible and offer theoretical
benefits, the practical aspects of using them overbalance the

> I have been surprised that you did not stick to a DOOM-style
> approach (each clients does the same calculations, occasionally
> checked). Client-side dead reckoning and override updates from the
> server seemed to be a natural choice. Is done by DIS, IIRC?

We have a far more robust architecture with dumber clients. Prog
changes just on the server, no consistancy failures, etc.

> >The server is still the final word, so the client is allways
> >repredicting it's movement based off of the last known good
> >message from the server.
> If I got it right: the QuakeWorld client runs (part of) the physics
> locally now, based on last confirmed/known good (authorized) update
> from QW server, doing a dead reckoning. User inputs are transmitted
> ASAP (or by frame?) from QW client to QW server. Waiting for the
> ACK/ authorized update, the QW client does *not* use the user
> input. The movement prediction calculated by the client is replaced
> the moment the autorized update (processed by the QW server)
> arrives at the client.

Not quite. Every frame the client gathers the user input and sends it
off to the server with a sequence number. Each message from the server
includes the sequence number of the inputs that it has simulated up to
the time of the message. The client then knows that all inputs it has
sent out past the one marked in the server message need to be simulated,
because they are still "in flight" to or from the server. This will be
a single input on a LAN game, but it could be up to eight or ten frames
worth on a fast system connected to a latent connection.

> >The client doesn't simulate other objects in the world,
> Aiming for NGT instead of QuakeWorld - how to get this scalable?
> Do Proxy Servers fit into the QuakeWorld concept? How else head for
> "huge scalable worlds" with client/server?

When we finally leave the level based game play behind, there will be a
transition to transparently distributed servers. There are still a lot
of gameplay issues there, aside from the technical ones.

> There is another problem that Quake seems to be approaching with a
> not too generic approach: attachment or locking of objects (I use
> "attachment", because it generalizes naturally to composite objects
> with kinematic chains and dynamics. Same for
> collecting/carrying/dropping items or close combat/stick-to/hugging
> attacks).

I'm not sure that that has high enough order benefits to really address
soon. I have other things with higher priorities.

> If collision detection/weapon targeting is done on the QW client's
> ...
> Same for a monster that is seen by nobody else close up.
> ...
> Every connected process is authorized "server" for one or more
> ...
> Display Proxies, Potentially Influenced Set
> Any process that has entities within the PIS it could not lock has
> ...
> This will not work w/o spatial coherency, which should come quite
> ...

Definately more work on the client than I want to take on.

Honestly, I hope that the kludging I am doing is a temporary thing.
As latencies improve over the internet, I hope that I can go back to
a totally dumb terminal at some future date when everyone has 50 ms
ping times. It is a cleaner, more robust model with a lot more flexibility.

> Another issue: what do you think about dedicated Resource Servers?
> I.e. a client that tries to log on to a server, gets a list of
> required resources (map, MDL). The client submits a request to a
> Resource Server, and downloads all resources that are not locally
> available without slowing down the Game Server machine.

Something along those lines would be a good idea, but I don't expect it for
the initial testing of QuakeWorld.

John Carmack

----- End Included Message -----