xml-dev - RE: XML for Online Games

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

It's all about shared illusions.

Latency:  in this context, timing issues of maintaining 
shared state among distributed systems that 
use stateless protocols.   The classic case 
is maintaining a coherent image for all of 
the users when each platform has different 
performance properties both locally (eg, 
processor speed, polygon update support) and 
globally (network performance, UDP vs TCP).  

Consider the problem of a game or simulation 
in which a character or agent drops a glass.  
If the physical properties of time are invariant, 
all of the users should be able to see if the glass is 
caught or hits the floor.  Given the time 
to react, one might see it differently 
as long as updates depend on the timing illusion 
(how long to hit the floor).
 
It is possible to create inconsistent 
conditions.  Inconsistencies that create 
false or superstitious assumptions can 
make for funny problems in a game.  These 
same inconsistencies can kill if the 
simulation is a real time control.  B2B 
systems use rollback for business objects 
that do not close correctly.  Parallel 
processing in operating systems can do 
similar tricks.  Fine, but in a 
simulation, it isn't too cool if the glass 
jumps back onto the table.  That's an 
update oopsie.

Stuff like this occupied a significant 
amount of the VRML 2.0 design discussions. 
If you go into 3D chat rooms, you can 
see funny behaviors as avatars move around. 
These inconsistencies are acceptable.  For 
the next level of gaming, they are not.

There are standards like Distributed Interactive 
Simulations (DIS) which take up the problems 
of designing messages for updating parts of a 
view to all participating users.  Attention is 
paid to ensuring that simulation events are 
prioritized effectively.  Simply being able 
to suspend and rehydrate isn't enough.  Games 
are written with a lot of attention to getting 
rid of superfluous compute cycles.  For example, a game 
played in an open space has significantly more 
problems than one forced into a world of cube 
space (walls, ceiling, etc) where occlusion 
can be used effectively (eb, a BSP tree) to 
eliminate objects from a current context.  

The author creates the world with these problems 
in mind.  For example, Level of Detail (LOD) 
switch nodes can be used to enable lower levels 
of fidelity of representation to speed up the 
display.  At the longest distance from an object, 
a bitmap can be used.  At an intermediate distance,  
a low-res polygon representation is used.  Up 
close, the full-monty is available.  Different 
texturing techniques can also be used to reduce 
load time in RAM-impoverished environments, and 
pre-lighting a texture (using shading) can be 
used to reduce the compute-intensive problems 
of calculating lighting.  

Remember, regardless of the name, all displays are really 2D 
and framerate is the critical metric.  Optimization 
for maintaining a high enough framerate to pull 
off the illusion of 3D animation is a problem 
shared both in the authoring and in the implementation 
of software and hardware.  3D is an illusion 
convenient for authoring and navigation, but  
framerates are 2D update problems.

Toss a network into that and a need to preserve 
that illusion regardless of network or platform 
performance, and you have a challenge.  This is 
why the 3DOnTheWeb projects are significantly 
more complicated than just saying, "We'll use 
XML for interoperability."  Performance is the 
sine qua non for illusions.  XML solves some 
problems but not the hard ones where we have 
to share illusions.  Ask yourself if you get 
faster performance from a meta-API (the DOM) 
or a bound API (toss the XML and use the object 
property names directly).  This issue has 
strained the X3D effort severely and lead 
to systems that will interoperate with 
X3D (eg, Sony Blendo) and those that 
will use the DOM (eg, Xj3D).   X3D has 
been a very good test case for the feasibility 
of XML ubiquity and the DOM API.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Sam Hunting [mailto:sam_hunting@yahoo.com]
Sent: Tuesday, October 31, 2000 9:52 AM
To: Bullard, Claude L (Len); Linda van den Brink; xml-dev@lists.xml.org
Subject: RE: XML for Online Games


 > BTW:  using XML in games is not that novel.  The 
> X3D effort has an XML encoding and can be applied 
> to games, there is a talkingHead application that 
> uses XML, and extending the persistence of games 
> via XML serialization is a straightforward application. 
> The latency issues are a much harder problem 
> than picking XML for message formats.

Can you expand a little on these "latency issues", Len? Thanks....