Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!news-reader.ntrnet.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: AI in IF
Message-ID: <GJ6EDw.GCv@world.std.com>
Date: Wed, 5 Sep 2001 06:08:19 GMT
References: <7d26d66b.0109030448.59339a1a@posting.google.com> <a69830de.0109031040.6c335374@posting.google.com> <7d26d66b.0109040941.176ce65f@posting.google.com> <a69830de.0109041820.378f2b66@posting.google.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 118
Xref: news.duke.edu rec.arts.int-fiction:92171

emshort@mindspring.com <emshort@mindspring.com> wrote:
>martinbays@hotmail.com (Martin Bays) wrote:
>>> Reaction to Player Action
>>> -- Notice what the player does and react to it appropriately if it
>is
>>> peculiar.  (There being two possible stages here, interfering with
>>> player action to prevent it and reacting to it after it is done.)
>>>
>>This is of course the one thing that Inform (and TADS(?)) is good at
>>already (through .before and .after), though it would be nice to tie
>>it in to a more general architecture.
>
>Yes; and I suppose I should add, here, that what I have in mind (and
>have partly implemented) is contextually-based reaction, rather than a
>constant one.
>
>The disciplined application of this idea, as opposed to a hackish
>application in a couple of restricted cases, requires that all actions
>the player does that are visible to the NPC must be passed to him for
>reaction, and that that code must be written to provide for reactions
>that interrupt the action or respond to it according to the current
>state of events.

Setting aside the "contextually-based reaction" for the nonce,
I'll sum up some of the things that led to The Weapon's
reaction-oriented character.

I've posted several times through the years about the MUD system
I co-developed.  On a MUD, multiple people can see the same event,
and need at least slightly different views of it ("You hit Bob"
versus "Satoria hits Bob").  On LPMud, for instance, there is a
function call that takes two strings, one of which is sent to
the current player for the current command, and one which is sent
to everyone else.

In the system we developed, all events which caused something to
display generated an *object* instead of a string. When a player
observed the event, it queried the object to print an
appropriate-to-that-player message. (Players might perceive
different objects differently based on PC knowledge, magic
senses, distance from event, etc.) At the same time, *NPCs*
could query the objct to give it a little "event packet" which
described the event in more world-model-ish terms, for example
"GIVE MOUSE TO BOB" might print "Satoria gives Bob a mouse" but produces
"Event: Mouse MovedTo: Bob CausedBy: Satoria" for the NPC--while
"GET MOUSE" produces "Event: Mouse MovedTo: Satoria CausedBy: Satoria"
(where these are all actually object identifiers, not strings).
This made NPC reactions more tractable and consistent, since the
number of event types was smaller, and because the NPCs would
react to visible things happening in the world, rather than what
the player typed. (But we needed an entirely separate system for
NPCs to prevent player actions.)

Putting the event description in the object also allowed us to
propogate it around the container hierarchy and through exits.
The object could be "filtered"--passing through a soundproof window,
going around a corner (propogating sound but not vision), reflecting
through a mirror (causing writing to be reversed). Each message to
be displayed became a little program for displaying text appropriately
in context, accounting for filtering, for the distance travelled
by the event, and for the PC's status (doesn't know language X,
can currently see invisible, etc.)

For The Weapon, I simply hacked all the character reactions
directly into the room and objects--it is a one-room game for
this reason (well, sort of, actually it was a one-room game
first). I hacked in a bunch of sensory puzzles that would
have been much easier with a true propogating sense system
(there's a bunch of sensing in the EM spectrum outside the
visible range).

I also think the commercial PC game "Thief", which had a
relatively detailed sensing system, and which for gameplay
reasons the player had to be aware of how the NPCs might
be sensing the PC and work with that, probably influenced
the direction The Weapon's sense-stuff developed.

>This is not sufficient, of course, in itself, since as you point out,
>reactive NPCs, however richly described, retain the status of lifeless
>machines to some extent.

This was pretty much the sole reason for the NPC-driven
one-sided "conversation" in The Weapon.

And now that I've explained that history of it, I should point
out that I do not plan on being out in the front leading the
charge on "reactive NPCs"--that will probably have been my
only shot at it.

>It's mine, now in betatesting and mostly complete, to be released in
>Glulx format towards the end of this year.  It was also (perhaps
>uniquely in the history of IF) written on commission, so it will not
>be available for free,

which unfortunately means it's ALSO not going to be available as
source. Maybe libraries?

>>Remembering object location actually isn't actually that difficult - a
>>system I tried out a while ago just gave each object a .bel_parent
>>property (or array for multiple NPCs) which just gave what the NPC(s)
>>currently thought the object's parent was, which was updated for
>>objects in sight each turn.
>
>Ah, good point.  I was contemplating something much uglier, involving,
>perhaps, a humungous array attached to each NPC.  [Spitting
>apotropaically.]

This is really an implementation detail. One ought to be able to abstract
away such concerns and say "I need a mapping from <AI,object> to
<last-seen-location, last-seen-time>", and not really fret the
details. Most languages allow easy data abstractions, especially
object-oriented ones (where objects are not primarily "simulation
objects", but rather structured data). This is the sort of thing
I mean when I say that Inform is really not an ideal language to
be doing complex programming in. (Mind you, all of my games to date
and in-progress are Inform games.)

SeanB
