RE: [Nel] Game Object Models

[John Hayes]

I was starting to wonder if this group was on :-)

> -----Original Message-----

> From: address@hidden [mailto:address@hidden Behalf Of

> Vincent Caron

> Sent: January 25, 2002 10:56 PM

> To: address@hidden

> Subject: Re: [Nel] Game Object Models

> 

> 

> On Tue, 2002-01-22 at 00:47, John Hayes wrote:

> At least you didn't say the famous 'TCP is slow' statement :)

Well that's just plain vague - does slow refer to latency or bandwidth?
In TCP's case, the latency is low until you lose data.

> TCP will bring sequentiality, reliability, inernet-wide

> cooperation, but certainly not delay guarantees, we all know that.

And neither will UDP, or any internet protocol ... but I'll get to that
below.

> - find the network properties you can live with. This is the most

> disregarded path. I'm always wondering why people always 

> blindly try to

> implement more or less ackward reliability hacks over UDP, before even

> asking if they need reliability. Yes, you often can live with dropped

> packets : this is what interpolation and extrapolation is about.

> Detecting them is easy, if you numbered your packets for 

> sequentiality.

> You might even find yourself dropping a late packet, because 

> you already

> have fresher info (depends on the info carried by the packet, of

> course).

This is what I was attempting to describe (although it wasn't really my
point for the whole email - just an example). Thing is, there isn't a
single protocol that'll meet all of your needs, there's several
scenarios:

1. You need "stream" or "large packet" transmission. These must be
received in the exact order that they are transmitted and none can be
dropped. An example is character connection where you immediately get a
large amount of data - in this case it's more efficient to repair the
data than retransmit the entire large packet and hope it makes it
through correctly. This is the most "TCP-like" - with the only
difference being a more aggressive retransmit - or it *could* be a
separate TCP channel, the implementation options are .

2. Reliable Datagram, transmission that must be successful but is order
independent. An example of this kind of chat text. You do care about
every message making it but the order is largely irrelevant. Another
example might be significant animations[1]

3. Unreliable Datagrams, the most UDP like - stuff where you don't care
if the packet gets lost, insignificant sound effects and animations.

4. Latest Data, you only need to know the newest data. Out of order
packets don't bother you as long as you can tell which one is newer and
the server retransmits. A special case of this data is velocity data -
covered later.

Now some interesting tidbits, and I should be able to bring this back to
my original point. You have parameters you can tune for such a system.

Frequency: how long after a change a the protocol waits to transmit -
frequently changing data should have it's transmission capped to a fixed
frequency. Slower updating data may have a frequency of 0[2].

Aggressiveness: how long after sending a data update should the server
before for retransmitting. This directly affects the latency increase as
the connection reliability drops. Tuning this parameter is related to
the frequency - if the data is expected to change again pretty soon,
it's probably faster to wait until that happens rather than retransmit.

Now - if getting the optimal communication requires all of these
protocols and then further tuning down to the attribute level, I think
this is the missing link to your plaint that contemporary games
implement too much reliability instead of customizing it.[3] Because
it's *easier* to implement reliability for everything.

If it were built into the framework that you could downgrade the
reliability selectively down to the field level - into a data model
(with a fancy editor no less), then it would become practical lengthen
the frequency until people complain, then turn it down a bit. Maybe not
too scientific, but the goal is the *appearance* of responsiveness not
actual responsiveness :-)

Now - then you swapped topic:

> > So - what kind of rules can we make up for this? Network 

> messages from

> > the server to the client have two functions - updating state and

> > "one-shot" actions (which is really a special case of 

> updating state).

> 

> Your description is interesting. I won't comment directly on 

> it, instead

> I would stress the importance of a dimension that is so commonly

> neglected : time.

I was thinking that I'd just hand wave this one away as an application
domain problem :-) But you dragged me into it - I leave it to the reader
to consult the summary.

> When you realized that every node (clients and servers) have 

> their own,

> timely view of the objects, my guess is that you end with two model of

> distribution :

> 

> - centralized : one (server/master) node is considered to be the only

> one to have a full coherent view of all objects at any time. All other

> nodes (clients, or let's say more generaly 'slaves') have a 

> slightly and

> globally delayed view of the referential view. You'll only get into

> trouble when the master must

> integrate client responses, since they 1) are a reaction to an info

> which is 1 RTT late and 2) a client info which is ~RTT/2 late.

> - fully distributed : the 'holy grail' :). In theory, each node is

> connected to all the other participating nodes. Of course, it's a

> bandwidth killer and it doesn't scale. But there are some points that

> make it somewhat conceivable :

It'll use about twice as much bandwidth as client/server model. But you
have all the same problems magnified, since every client (and the
server) still work on a different time base. Which client's
interpretation is correct, or is the server's correct (P2P broken)?

The biggest practical barrier is more users are behind NAT/firewalls and
have difficulty receiving incoming connections without configuration
(mapping ports) or a 3rd party forwarding.

> * a node is often only affected by a few other nodes : the players in

> sight of your gun, etc. If every node can maintain a 'neighbourhood

> dependency', you'll end with a finite number of links per 

> node (depends

> on your game design, might prove wrong in a virtual stadium :))

Server has to do the same work anyways determining who can see who. You
could make a P2P system do the same thing, but there's a couple bits of
trickery: one node has to be able to discover other nodes (moving closer
to another node can cause that node to transmit nodes it knows to be in
it's own view) and bootstrapping (how does a node initially discover
who's nearby). 

---

For the timing problem the answer is similar to the packet reliability
problem. Do you care? I can think of two applications where you do -
timing enforcement such as making sure animations take as long as
they're supposed to, velocity checking, and server-side physics. Only
one of the commercial MMOG's has server-side physics - so maybe it's not
a big issue, or maybe everyone else is scared to touch it.

For cheating, using something like NTP, you can spot over a few minutes
whether someone's clock is sliding.

John

- Lets burn that bridge when we come to it

[1] Something with a very obvious tactical or dramatic influence.

[2] I'm aware that by 0, I mean infinity, and I'm not really talking
about frequency but time.

[3] Low latency "LAN" games will do things like transmit every packet
2-5 times and assume it's gets through.

<<winmail.dat>>