xml-dev - RE: XML for Online Games

[Joshua Allen <joshuaa@microsoft.com>]

The interesting thing about shared illusions, as you touch upon here, is
that you often only care about "sharing" the illusion with a finite
population of your universe.  This is much like the real world -- if a tree
falls in London, I probably don't care.  This also means that loose
collections of nodes working together (napster on steroids) can scale fairly
naturally in illusion-sharing situations.  If you have a central server
holding all of the objects of the universe and dispatching information, that
machine gets overheated.  Let the software be the laws of the universe, and
let people get reality from whoever they're standing near.  ("standing near"
in a virtual sense, of course).  "Proximity" and "location" can be fluid
things, but usually exist in some form in wired contexts as well.

Another thing slightly related to latency in shared illusion systems is the
issue of trust.  Even when you get to the point where your system has
tolerable latency, can you trust that the illusions you are looking at have
not been tampered with?  In long-running transactions (xlang, edi, etc.)
much attention is paid to the idea of trust, under the implicit assumption
that trust is harder to ensure when you have lots and lots of equal peers.
But the trust issue is just as much a problem when the illusion dispenser is
a central server.  While a distributed state system needs to watch out for
localized tomfoolery, a centralized sytstem is more vulnerable to
"byzantine" threats.  Byzantine could be used to describe a gang of vandals
slicing cables in your data center, a hacker deliberately polluting the
blood supply of illusion flowing to all clients, or it could describe
corporeal legal entities attempting to enforce law by going for your
system's jugular (cat illusions|tr "democracy" "the glorious and wonderful
peoples republic").  It's possible to imagine the latter byzantine threat
becoming an important consideration in corporate system design as
multinational corporations do business that spans multiple corporeal legal
authorities who may all have different laws and enforcemnt policies.  The
question becomes "who do ya trust?".  Not all of us would trust every
individual, but neither would all of trust every organization with the power
to go byzantine on our data.

To me, the trust issue is the one with which we have the least experience as
an industry.  This is also going to be the most important cahllenge for us
to solve long-term.  One interesting project is at
http://research.microsoft.com/sn/Farsite/.

P.S. We tolerate inconsistencies in the real world all the time.  To quote
from a favorite play by Pirandello, "Oh sir, you know well that life is full
of infinite absurdities, which, strangely enough, do not even need to appear
plausible, since they are true."



> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Tuesday, October 31, 2000 9:31 AM
> To: Sam Hunting; Linda van den Brink; xml-dev@lists.xml.org
> Subject: RE: XML for Online Games
> 
> 
> 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....
> 
>