The Client as a Dumb Terminal
I am giving up on one of my cherished networking concepts — the client as a
dumb terminal.
With sub 200 msec network connections of reasonable bandwidth, pure
interpolating is a reasonable solution that is very robust and elegant.
With modem based internet connections having 300+ msec pings and patchy
delivery quality, pure interpolation just doesn’t give a good enough game
play experience.
Quake 1 had all entities in the world strictly interpolated (with a 20 hz
default clock), but had several aspects of the game hard coded on the client,
like the view bobbing, damage flashes, and status bar.
QuakeWorld was my experimentation with adding a lot of specialized logic to
improve network play. An advantage I had was that the gameplay was all done,
so I didn’t mind adding quite hardcoded things to improve nailguns and
shotguns, among other things. The largest change was adding client side
movement prediction, which basically threw out the notion of the general
purpose client.
Quake 2 was intended to be more general and flexible than Q1/QW, with almost
everything completely configurable by the server. At the time of q2test, it
was (with a fixed 10 hz clock).
Before shipping, I wound up integrated client side movement prediction like
QW. Having gone that far, I really should have moved the simulation of a lot
of the other view presentation logic (head bobs / kicks, etc) back to the
client. Because these are still run on the server, a lagged connection will
give you odd effects like falling off a cliff, running away, then having the
head kick and the landing crunch happen when you are 50 feet away from the
point of impact.
So basically I wound up losing the elegance, but I didn’t reap all the
benefits I could have.
I am still holding to my stronger networking belief, though — centralized,
authoritative servers, as opposed to peer to peer interaction. I REALLY
think distributed simulation among clients is a VERY BAD idea for networked
games. Yes, there are some theoretical advantages to being able to hand off
the simulation of some objects, but I have plenty of reasons to not want to
do it. Client side movement prediction is simulation, but it has no bearing
on the server, it is strictly to give a better presentation of the data the
server has provided.
The new paradigm is that the server controls all information necessary for
the rules of the game to function, but the client controls all presentation
of that information to the user through models, audio, and motion.
There were moves in that direction visible in Quake 2 — the temp entities
and entity events that combined sounds and model animations run entirely on
the client side. Everything will soon be like this.
This saves some degree of network bandwidth, because instead of specifying
the model, skin, frame, etc, we can just say what type of entity it is, and
the client can often determine everything else by itself. This also enables
more aggressive multi-part entities that would have been unreasonable to do
if they each had to be sent seperately over the network connection.
Almost all cycling animations can be smoother. If the client knows that the
character is going through his death animation for instance, it can advance
the frames itself, rather than having the server tell it when every single
frame changes.
Motion of projectiles can be predicted accurately on the client side.
All aspects of your own characters movement and presentation should be
completely smooth until acted upon (shot) by an outside entity.
All the clever coding in the world can’t teleport bits from other computers,
so lag doesn’t go away, but most of the other hitchy effects of network play
can be resolved. Lag reduction is really a seperate topic. QuakeWorld had
instant response packets, because it was designed for a dedicated server
only, which helped quite a bit.
During the projects development, the client side code will be in a C DLL, but
I intend to Do The Right Thing and make it java based before shipping. I
absolutely refuse to download binary code to a client.