RE: writing scripts

2000-12-05 Thread Bullard, Claude L \(Len\)

A clockwork is possible.  Just very hard.  Again, a 
"speed is money; how fast can you afford" issue of 
resources.  If a clockwork is an ultimate goal, 
set it then by degrees work to it.  I am thinking 
of a server world that maintains a modular set of 
worlds around it.  The privilege or role of a 
user that logs in determines which worlds they 
can be in, which powers (commands and data) they 
have affect over per world, and what they can 
carry from world to world.  This is something 
classical literature and many movies achieve with 
their separate realms that can send agents to 
the middle world (think Shemp Howard as the 
angel in the dream).  Except what our medium allows 
is for all of these worlds to be simultaneously 
active.  But the prime directive is still illusion 
maintenance, and so we set up the hierarchy of 
powers and rules of interface (sounds like OOP 
to me but with XSLT and XML for messaging, 
transactions, and remediation (no rollback)).

Anyway, the lord of such a world is not disengaged 
fully.  The restriction was illusion maintenance; 
god uses the agents and sticks to self-imposed rules. 
In this thread, I am using this metaphor because it 
is reasonably clear how roles are assigned and offers 
the potential to categorize hierarchies of agents 
that inherit capability and interface.  The thread 
is to look at the properties of a script that can 
enable it to be self-transforming.  We have to out 
the properties of self-transformation but frame 
them within the constraints of illusion maintenance. 
The theology is convenient and let's me play with  
images and characters that can be created and sustained.

However, the tech side is to point out that the X3D/XML/XSLT 
combination can be extremely powerful and give us tools 
to author that are much easier to work with than 
programming in the EAI/SAI.  While the EAI can be the 
realtime interface, the universality of the XML syntax 
enables us to build all of the other languages we 
need to persist property values across episodes and 
transform them.  That I choose in this instance of a 
storyworld to call them spells, miracles, devices, 
guises, etc. is simply to make them accessible from 
the GUI in a way that naturally leads an author to 
understand their purpose.  In reality, they are 
probably UMEL resources for that world.

For a story world to be even more interesting, one 
would sustain multiple plotlines that can intersect, 
overlap, and alter each other almost the way that 
occasionally sitcom stars cameo in each others shows.

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

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


-Original Message-
From: Jed Hartman [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 04, 2000 8:42 PM
To: [EMAIL PROTECTED]
Subject: RE: writing scripts


As always, wish I had more time to participate in this discussion...

Also as always, I'm inclined to overlay my tabletop-RPG views on 
this.  (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.)  In most RPGs, the GM does not -- 
cannot -- just set a clockwork universe into motion and step back, 
because someone has to play the part of Len's devils and angels -- 
non-player characters, inanimate objects, all the incidents and 
accidents that interfere with or promote character goals.

[Um, it's come to my attention recently that many people these days 
use the term "RPG" to refer to video games in which you go through a 
sequence of adventures killing everything in your path.  I suppose 
this is a reasonable usage -- until a recent review in Strange 
Horizons I had no idea that these games had true storylines, and I'm 
still a bit mystified as to how that works -- but it's not how I use 
the term; I'm talking about traditional Dungeons  Dragons-style 
roleplaying games, where everything takes place in the players' and 
GM's imaginations, perhaps aided by pencils and paper and dice.]

But there are a lot of different GMing philosophies -- and a lot of 
different tricks.  Some GMs try to come as close to the clockwork 
universe as possible: they create a detailed world, they create vast 
hordes of NPCs, and then they do their best to play those NPCs as if 
they were real people with real goals.  Other GMs are trickier, 
manipulating things from behind the scenes to ensure that things go 
the way they want, changing motivations and even facts on the fly as 
long as they're not already known to the player characters.  (Think 
Schrodinger's Cat: if the PCs don't know something, that thing can 

RE: writing scripts

2000-12-05 Thread Bullard, Claude L \(Len\)

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