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.)