I agree with your assessment.  Thanks for this 
reference.  Excellent reading.

I looked at the Skotos site and 
inevitably we come back to the issues 
of text MUD vs 3D real time stories. 
Protocol and how to parse a protocol 
as always becomes the design challenge. 
We have discussed this before in terms 
of commands, gestures and even emotional 
language files and when you look at sites 
like Cybertown, you see the bare beginnings 
of commands for simple behaviors, plus they 
regularly host real time events with some 
aspects of role playing.

A text interface and a 3D interface may 
overlap.  It certainly solves the problems 
of command and control in text; OTOH, it is typing 
intensive, relies on learning a vocabulary, 
and seems to rely on guides for escapes.  This isn't ideal but 
there are lots of ideas that do transfer 
the real time 3D world well.  Interaction 
means controls and it is tough to hide them 
without real time speech and that of course, 
makes the automation of devils and angels 
extremely expensive (won't pass a turing test). 
Yet without a richer medium, the skotos experience 
seems to be a kind of interactive radioplay.

I like Kimberly's story writing articles. 
As I said before, one may want to abandon the 
inherent linearity of stories, or learn how 
to hide plot driving devices.  Much of what she 
talks about is directly text related and one 
has to figure out how to translate that into 
3D stuff.

The crux is still the illusion 
of free will and managing that by context.  She 
notes a vital point and that is the ability to 
affect globals.  Globals are key to producing 
sideeffects and uncertainty (what XSLT assiduously 
avoids for the same reason).  

Very good site.  I note they are already using 
XML.  It will be interesting to see if they 
mine the markup gold mine of the Hytime 
work and look at some of the emerging work in 
topic maps.  Being able to create and change 
these is one way to manage relationships 
among objects.  Graham Moore did a good paper 
on using groves for linking to application state.

See http://www.empolis.co.uk/products/prod_x2x.asp

>From the skotos site:

"Though we're using the basic ideas of XML, we haven't poured over the XML
specs in ultimate detail. We don't actually need to comply to the XML specs.
Thus there may well be other things we do in our system that's off-spec."
 
Looking at their file example it wouldn't be hard to do the 
right thing and make it possible take their file, using XSLT and 
spit out a 3D object that conforms.   If they persist game state 
for players, and enable modification between episodes (another 
kimberly bit was that she covers plot types; nice), then 
the XSLT can use these to initialize a 3D world, SOAP for RPC services, 
and so on.
  
An important issue for UMEL will be being able to do this kind 
of thing in a provably standard way, so the light way Skotos 
treats this issue won't work in the long run.  (yes, that's a challenge to 
the lurkers).  It does us not much good other than experience 
and bangles to create for proprietary languages and implementations. 

Thanks for the pointer, Jed.  Most enjoyable reading.

Len 
http://www.mp3.com/LenBullard

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


-----Original Message-----
From: Jed Hartman [mailto:[EMAIL PROTECTED]]

Perhaps Lurker Par has some thoughts about how all this plays 
out in existing MUDs, such as the groundbreaking work he and his 
company are doing now at http://www.skotos.net -- I envision this 
kind of thing eventually being a back-end to interactive stories of 
the type we're talking about, with a 3D graphics display system in 
place of text descriptions -- there are a lot of ways in which the 
problems being solved are different in these two cases, but also, I 
think, a lot of similarities.)

Reply via email to