xml-dev - RE: XML for Online Games

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

And similar to the pre and post condition notions 
used in the old IETM databases.  A process 
executes somewhat serially, completes, 
and stores the results (post-conditions) as the 
pre-conditions for the next process node. 
Diagnostic models based on a simulation 
of operational modes works like that.  
The trick for the author is to ferret out 
the hidden couplers that create unknown 
unknowns in processes with parallel 
schedules: eg, kill the guy on the other side 
of the aircraft by moving a wing surface 
while they are beneath it.  Again, when 
doing this for real work, don't fly the 
first one.

Very much the kind of thing we are discussing 
in standard business processes or what MS 
calls long term transactions.  Neat.  We 
see the same design pattern in so many 
different applications: persist a process 
by "dehydrating" and "rehydrating".  So we 
get back to layering, heterarchies of 
processes, etc.  This is good because 
we can use this understanding to look 
at the meta-models being advanced for 
designing these (eg, XLang, ebXML) and inquire 
if they are robust enough to solve the 
problem.

We discussed this thoroughly on the 
vrml-lit list as well as a way of 
creating interactive fiction.  While 
it is not realistic to talk about 
non-linearity (without predictability, 
plot has little meaning), it is realistic 
to talk about a system of locally linear 
but evolvable plots.  In effect, any 
control-driven system with a means to 
change paths based on abstracting discoverable 
patterns into signals works this way. 

Most simulations of real-time systems have 
the same issues.

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: Leigh Dodds [mailto:ldodds@ingenta.com]

I was involved with a Java port of the Quake2 game server for 
a while (the project [1] has dried up now). 

We ended up using a DOM tree to store the level information, 
allowing game modules to manipulate the data prior to 
the start of a new level. XML was also used as a means of 
persisting game data, and loading game state at start of level.

I also tinkered with an XML structure for capturing the model 
animation data.

It was a neat way to add extensibility to the game data. Nothing 
flashy but an interesting application to work with never the less.

[1]. http://www.planetquake.com/q2java/