Contest 99 idea--NPCs in IF

19 views
Skip to first unread message

Avrom Faderman

unread,
Dec 20, 1998, 3:00:00 AM12/20/98
to
With all the talk about whether IF is *capable* of creating reasonable NPCs
(without such techniques as parody, extensive use of cut scenes, or strictly
limiting player interaction), I thought of the following idea for a comp
entry. There's no *way* my Inform skill will be up to it for comp '99, so
I'm throwing it into the "public domain" [figuratively; I know an idea as
general as this can't be copyrighted] in case anyone wants it.

This would be, in some sense, more an existence proof than a game; it would
probably be best done by someone not angling for a high score but rather
interested in pushing the boundaries for the sake of pushing the boundaries.

The problem with the current NPC model, I think many people agree, is that
NPCs just don't *know* about most of the stuff in the game; and they
*certainly* don't respond interestingly to most commands. Very few games
that allow you to

> PUT THE RED SPHERE ON THE BLUE DISK

will respond to

>FLOYD, PUT THE RED SPHERE ON THE BLUE DISK

with anything but a stock response. Even worse, most games that know about
the red sphere will respond to

>ASK GURTHARK ABOUT RED SPHERE

with
"I don't know anything about that."

Why is this? Well, of course, since every action needs to be coded
separately, every action FOR THE NPC has to be coded separately, so giving
the NPC the same vocabulary and range of action as the player doubles the
length of the game. Add three NPCs, and the game has bloated to four times
as long.

The standard solution? Make most of the objects and actions out of the
NPC's range.

My idea? Just make the "base game" (the thing being doubled) much smaller.

Here's the comp idea [originally, this was going to be a takeoff on Eliza,
but I think this works better]: The PC is a psychologist, sitting in a
sparsely furnished (remember, the idea is to keep the main game small)
office. A few moves in, an NPC named Parry, a new patient suffering from
severe paranoia, comes into the office, and begins to tell the PC about his
troubles.

With the exception of the few objects in the office, the PC him/herself, and
Parry, the only "objects" in the game are the ones Parry mentions himself,
plus maybe a few stock psychologist's objects (Parry's mother, Parry's
father, etc). The only way for the player to interact with these objects at
all is by talking to Parry.

Of course, commands aren't the ideal forum for a psychologist. The parser
would need to be hacked [maybe this would make it too big a project for a
comp game?] to handle a wide range of interrogatives; the range of ordinary
commands could be slashed.

Any thoughts? Not so much about whether this would make a good game [it
wouldn't], but whether it might a) be feasible and b) be something that
might have a positive influence on what good games looked like in the
future?

Best,
Avrom
(PS. Oh, maybe it's not *quite* in the moral PD. If someone tries this, my
ego's big enough that I'd at least like a friendly mention somewhere in the
credits. But that's it.)


Adam Cadre

unread,
Dec 20, 1998, 3:00:00 AM12/20/98
to
Avrom Faderman wrote:
> The problem with the current NPC model, I think many people agree, is that
> NPCs just don't *know* about most of the stuff in the game; and they
> *certainly* don't respond interestingly to most commands.
> [...]

> Why is this? Well, of course, since every action needs to be coded
> separately, every action FOR THE NPC has to be coded separately, so giving
> the NPC the same vocabulary and range of action as the player doubles the
> length of the game.
> [...]

> My idea? Just make the "base game" (the thing being doubled) much smaller.

That was my thinking as well. My current project is in large part an
attempt to code up some NPCs much less reliant on stock responses than
most NPCs today seem to be. Ideally, I'd want each of them to have a
unique response to inquiries or statements about every noun that occurs
in the text of the game.

Even though the map is quite small, this would entail a huge amount of
coding. A huge enough amount that I worry about Inform's 512K barrier.
I downloaded Hugo today.

-----
Adam Cadre, Anaheim, CA
http://www.retina.net/~grignr

Lelah Conrad

unread,
Dec 21, 1998, 3:00:00 AM12/21/98
to
On Sun, 20 Dec 1998 17:15:30 -0500, Adam Cadre <ad...@acpub.duke.edu>
wrote:


>I downloaded Hugo today.

Throwing us off the track again, eh?

I predict that the comp 99 game written in Adventure Builder by an 86
year old gentleman from Puyallup, WA, containing only complex
interactions with inanimate objects, will have been written by
.......

;)

Lelah

Michael Gaul

unread,
Dec 21, 1998, 3:00:00 AM12/21/98
to
Avrom Faderman wrote:
>
> My idea? Just make the "base game" (the thing being doubled) much smaller.

Yes - there are striking examples for this technique in literature as
well
as in movies. Spontaneously, "Duet" comes to my mind - an episode of
Star Trek DS9, which had to be designed when the budget was overdrawn
already. It mainly consisted of two characters acting in one room. And
it was great.

But unfortunately game size is only one factor that makes NPC coding so
difficult. Others are non-linearity of plot and NPC intelligence.
Consider
the following conversation:


> ASK PARIS ABOUT ATHENA

Paris answers: "Oh, she's really cute."

> ASK PARIS ABOUT ATHENA

Paris answers: "As I said, she's really cute."

> ASK PARIS ABOUT APHRODITE

Paris answers: "Oh, she's cute too. Not the way Athena is, though.
More on a ... well ... more emotional level."
A shy smile escapes his lips.

> ASK PARIS ABOUT ATHENA

Paris answers: "As I said, she's really cute. But somehow she
doesn't ... touch me the way Aphrodite does."


I always wanted NPCs to be able to converse in that way, but this
is awfully difficult to code. The NPC has to have a memory of which
topics have already been mentioned, and he should be able to act
sensibly if the player chooses a different sequence of questions.
In the example above, if the player had first asked about Aphrodite,
he would have heard the same answers as for Athena above, unless he
also asked about Athena. The first mentioning of the second goddess
then yields the "cute, too" response, and so on.
But the programming effort is disencouragingly large compared to the
small effects.

And I don't even talk about NPC intelligence, which is about twenty
levels more difficult to model.


> Here's the comp idea [originally, this was going to be a takeoff on Eliza,
> but I think this works better]: The PC is a psychologist, sitting in a
> sparsely furnished (remember, the idea is to keep the main game small)
> office. A few moves in, an NPC named Parry, a new patient suffering from
> severe paranoia, comes into the office, and begins to tell the PC about his
> troubles.
>
> With the exception of the few objects in the office, the PC him/herself, and
> Parry, the only "objects" in the game are the ones Parry mentions himself,
> plus maybe a few stock psychologist's objects (Parry's mother, Parry's
> father, etc). The only way for the player to interact with these objects at
> all is by talking to Parry.
>
> Of course, commands aren't the ideal forum for a psychologist. The parser
> would need to be hacked [maybe this would make it too big a project for a
> comp game?] to handle a wide range of interrogatives; the range of ordinary
> commands could be slashed.

I think the chances that this will work are not too high. First, as you
already mentioned, the parser would have to be hacked - and before you
do
that, you should have a working model of how conversation between player
and NPC would function. I think hacking the parser will be the *easy*
part.

Secondly, I fear that the psychologist setting won't make a good game.
At
least not the psychoanalyst paradigm you mentioned. As in real life,
behaviour
therapy might prove much more fruitful. This means, for example, to
confront
a phobic patient with his fears instead of asking whether he ever wanted
to
sleep with his mother. This in turn means that much more sensible
actions
could be objectivized, e.g. in "GIVE SPIDER TO ARACHNOPHOBIC PATIENT" or
in "CLAUS, ENTER ELEVATOR". (Paranoia seems to be not very well suited
for
the task.)

But of course anyone is free to prove that I'm wrong. :-)

Michael Gaul

unread,
Dec 21, 1998, 3:00:00 AM12/21/98
to
... and what I forgot to mention is:

If there are as many prizes in next year's competition as
there were in this year's, it might make sense to issue
category prizes for "best NPC", "best plot", "best writing"
etc. Or do you think this would put the competition in
conflict to the XYZZY awards?

J. Robinson Wheeler

unread,
Dec 21, 1998, 3:00:00 AM12/21/98
to
Adam Cadre wrote:
>
> Avrom Faderman wrote:
> > The problem with the current NPC model, I think many people agree, is
> > that NPCs just don't *know* about most of the stuff in the game;
>
> > My idea? Just make the "base game" (the thing being doubled) much
> > smaller.

> That was my thinking as well. My current project is in large part an


> attempt to code up some NPCs much less reliant on stock responses than
> most NPCs today seem to be. Ideally, I'd want each of them to have a
> unique response to inquiries or statements about every noun that occurs
> in the text of the game.

Gee... what a neat idea. A comp game with a small base map, and NPCs
who are able to uniquely respond to every noun in the game, even nouns
that, say, appear in other NPC answers only.

Say, that sounds swell! If only I'd thought of it first, and done it
for Comp98. Then I'd know I was really ahead of the curve on this
one.

--
J. Robinson Wheeler
whe...@jump.net http://www.jump.net/~wheeler/jrw/home.html

green_g...@my-dejanews.com

unread,
Dec 21, 1998, 3:00:00 AM12/21/98
to
In article <O4VKd2FL#GA....@upnetnews02.moswest.msn.net>,

"Avrom Faderman" <Avrom_F...@email.msn.com> wrote:
> The problem with the current NPC model, I think many people agree, is that
> NPCs just don't *know* about most of the stuff in the game; and they
> *certainly* don't respond interestingly to most commands. Very few games
> that allow you to

<snip>

> >ASK GURTHARK ABOUT RED SPHERE
>
> with
> "I don't know anything about that."

FWIW, I handle the above question in my game in progress (PastPerfect) for
all objects in the game (and there are lots) and it wasn't really that hard.
I'm using Inform, and will happily chat on about it if you would like... just
email me.

Kathleen

--
-- Excuse me while I dance a little jig of despair.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Jonadab the Unsightly One

unread,
Dec 22, 1998, 3:00:00 AM12/22/98
to
Adam Cadre <ad...@acpub.duke.edu> wrote:


> > My idea? Just make the "base game" (the thing being doubled) much smaller.
>
> That was my thinking as well. My current project is in large part an
> attempt to code up some NPCs much less reliant on stock responses than
> most NPCs today seem to be. Ideally, I'd want each of them to have a
> unique response to inquiries or statements about every noun that occurs
> in the text of the game.
>

> Even though the map is quite small, this would entail a huge amount of
> coding. A huge enough amount that I worry about Inform's 512K barrier.
> I downloaded Hugo today.

I don't know how *much* this will help, but it's an idea:

Assuming you have a limited number of NPCs, use a separate
description property for each (and one for the PC as well)
and then what each character has to say about any given
object is in that object. The library could be hacked to
perform actions with any actor (not just the player), and
although it would take some work, it might work very well.
Most before rules will need to check the value of actor...


- jonadab

Jonadab the Unsightly One

unread,
Dec 22, 1998, 3:00:00 AM12/22/98
to
Michael Gaul <ga...@rz.uni-potsdam.de> wrote:


> could be objectivized, e.g. in "GIVE SPIDER TO ARACHNOPHOBIC PATIENT" or
> in "CLAUS, ENTER ELEVATOR". (Paranoia seems to be not very well suited
> for the task.)

> Attack patient.

- jonadab

Phil Goetz

unread,
Dec 22, 1998, 3:00:00 AM12/22/98
to
In article <O4VKd2FL#GA....@upnetnews02.moswest.msn.net>,
Avrom Faderman <Avrom_F...@email.msn.com> wrote:
>The problem with the current NPC model, I think many people agree, is that
>NPCs just don't *know* about most of the stuff in the game; and they
>*certainly* don't respond interestingly to most commands. Very few games
>that allow you to
>
>> PUT THE RED SPHERE ON THE BLUE DISK
>
>will respond to
>
>>FLOYD, PUT THE RED SPHERE ON THE BLUE DISK
>
>with anything but a stock response. Even worse, most games that know about
>the red sphere will respond to
>
>>ASK GURTHARK ABOUT RED SPHERE
>
>with
>"I don't know anything about that."
>
>Why is this? Well, of course, since every action needs to be coded
>separately, every action FOR THE NPC has to be coded separately, so giving
>the NPC the same vocabulary and range of action as the player doubles the
>length of the game. Add three NPCs, and the game has bloated to four times
>as long.
>
>The standard solution? Make most of the objects and actions out of the
>NPC's range.
>
>My idea? Just make the "base game" (the thing being doubled) much smaller.

You old-timers knew I was going to respond to this... I suppose I am being
tiresome, since it seems I write this post every four years.

My approach is that the game should treat the player like the NPCs.
In <collective groan here> my 1986 game _Inmate_, NPCs and the player performed
actions exactly the same way. The only difference was that the verb handler
got PLAYER in the Agent slot instead of, say, MARK, and the routines to
print descriptions of events would change the grammar to say "You pick up
a red square" instead of "The player picks up a red square".
Descriptions were printed only for actions that occurred in the player's room.

So if you typed

Tell Ed "Go north."

the parser would take everything in quotes, run that through the parser,
and hand the result to Ed as a request from the player. Ed could either
refuse or execute the action. Each verb had a bit that said whether an NPC
would by default perform the action if requested to. Mostly they would
not. I can't remember if there was a separate bit for each NPC.

Planning under this system was limited to pathfinding and specially-coded
NPC knowledge about how to unlock and open containers.

In my 1996 Prolog adventure engine, NPCs had access to the entire database that
described how the world worked. So, specifying how things would react to
player actions also told the NPCs how they would react. So the program
could give an NPC the goal of killing the player, and the NPC would
construct a plan via Prolog backchaining and try to execute it, using
only knowledge about how to move from room to room, how locks work,
what knives do, etc., that are used for player actions. (I never wrote a
game with this engine, sorry. It's not of professional quality, and
runs only under Sun's Prolog. It in particular does not run under bprolog,
the Linux public domain Prolog.)

The funniest result of this system was when I implemented "undo" -
characters began solving their goals by using "undo" to undo whatever
the player had done to thwart them.

In my next game engine I'm going to take a step "backwards" and have
separate belief spaces for each character, so they can have false beliefs,
degrees of uncertainty, conflicting belief, unshared knowledge.
But this still won't require duplication of most knowledge, just pointers
to propositions with notations about who believes them and how strongly.

Phil go...@zoesis.com

Gareth Rees

unread,
Dec 22, 1998, 3:00:00 AM12/22/98
to
Phil Goetz <go...@cse.buffalo.edu> wrote:
> My approach is that the game should treat the player like the NPCs.
> In <collective groan here> my 1986 game _Inmate_, NPCs and the player
> performed actions exactly the same way. The only difference was that
> the verb handler got PLAYER in the Agent slot instead of, say, MARK,
> and the routines to print descriptions of events would change the
> grammar to say "You pick up a red square" instead of "The player picks
> up a red square". Descriptions were printed only for actions that
> occurred in the player's room.

I'm working on an actor-independent version of the Inform library.
Instead of <<action noun>> you call DO(actor,action,noun) and all the
same rules are applied to actor as would be to the player, as Phil
describes above.

A few things have to be changed. I have to ignore player-centric
variables like "location" and "lightflag" (although I take care to set
them up for the benefit of the parser). The "found_in" feature can't be
used for anything that NPCs ever need to know about or interact with, so
a door has to be represented by a pair of objects (one for each side).

Action routines have to be tidied up so their return value reliably
indicates whether the action was successful/expected or unsucessful/
unexpected.

And of course someone writing a game using the actor-independent library
has to make sure that their code is actor-indpendent too: no more

after [; Take: "It's a wrench, but you take it."; ];

but rather

after [; Take: if (actor==player) "It's a wrench, but you take it."; ];

Doing the above doesn't make writing NPCs very much easier (for example,
you can't write a general planning engine in Inform because Inform can't
easily represent the hypothetical world of the plan). But it's a start.

--
Gareth Rees

Rene van 't Veen

unread,
Dec 22, 1998, 3:00:00 AM12/22/98
to
Hmmm, very interesting ...

Phil Goetz wrote in message
<75osbg$f22$1...@prometheus.acsu.buffalo.edu>...


>In article <O4VKd2FL#GA....@upnetnews02.moswest.msn.net>,
>Avrom Faderman <Avrom_F...@email.msn.com> wrote:
>>The problem with the current NPC model, I think many people agree,
is that
>>NPCs just don't *know* about most of the stuff in the game; and
they
>>*certainly* don't respond interestingly to most commands. Very few
games
>>that allow you to
>>
>>> PUT THE RED SPHERE ON THE BLUE DISK
>>
>>will respond to
>>
>>>FLOYD, PUT THE RED SPHERE ON THE BLUE DISK
>>
>>with anything but a stock response. Even worse, most games that
know about
>>the red sphere will respond to
>>

[ .. major snippage ... ]


Phil Goetz continued in message
<75osbg$f22$1...@prometheus.acsu.buffalo.edu>...


>
>You old-timers knew I was going to respond to this... I suppose I am
being
>tiresome, since it seems I write this post every four years.
>

Oh goodie, I am not an oldtimer ... so ...

>
>My approach is that the game should treat the player like the NPCs.

>In <collective groan here> my 1986 game _Inmate_, NPCs and the player
performed
>actions exactly the same way. The only difference was that the verb
handler

[ .. major snippage ... ]

Ah. Yes *and* no.

Yes: the compiler, runtime and stock libraries should, IMHO,
be designed and implemented such that "you" are treated
as any other NPC as much as possible. Which would entail
that NPC's can 'issue' commands and have the usual
effects happen to them. This would make it a least a lot
easier to endow NPC's with some 'intelligence'.

Obviously, suitable messages should be displayed if (and
only if) an NPC performs an action and you are in a position
to observe that action, eg. "John takes the apple", "You take
the apple".

For the author there is some benefit in implementing at
least some objects similarly as it would allow the author to
reuse such objects in other games with relative ease.

The current state of affairs is such that this is
*difficult* with the standard platforms, but well one can
hope and until that happens, be happy with whatever is
available.

No: "You" and "Me" is rather special in the context of the
story you are telling.

In fact, it isn't quite clear who "you" refers to, anyway.

Are "you" the character in the world and is the player a
sort of puppet-master controlling and observing that puppet
named "you"?

Are "you" the person that is fulfilling the role of the
character in the world?

Are "you" the player that is sitting at the console typing
in commands in response to things that are displayed on the
screen?

Are "you" the individual with his own background, history,
emotional make-up , etc. that is enchanted, engrossed and/or
disgusted with the story that the author is telling "you"?

(Add your own set of "you"'s here ...)

Depending on which "you" you, the author, wishes to address,
you, the author, might want to phrase the messages differently
to get whatever point across you, the author, want to make.

To summarize: with a view to designing, modelling an implementing
a credible world model, yes. With a view to storytelling,
authorship and communicating with the audience, no.

[ .. snipped bits about the Prolog Engine which .. ]
[ .. sounds really cool :-) .. ]

Phil Goetz continued in message
<75osbg$f22$1...@prometheus.acsu.buffalo.edu>...


>
>In my next game engine I'm going to take a step "backwards" and have
>separate belief spaces for each character, so they can have false
beliefs,
>degrees of uncertainty, conflicting belief, unshared knowledge.
>But this still won't require duplication of most knowledge, just
pointers
>to propositions with notations about who believes them and how
strongly.
>

Mmmm, if you can pull this off and be able to do some automated
reasoning with all of that stuff above, I bow humbly for your
great talents. Really, I do. No pun intended.

----
"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat
---
(remove nospam to email me)

Rene van 't Veen - r.n_o_s_p_...@wxs.nospam.nl

Chris Nebel

unread,
Dec 22, 1998, 3:00:00 AM12/22/98
to
In article <si90fzh...@cre.canon.co.uk>, Gareth Rees
<gar...@cre.canon.co.uk> wrote:

>Phil Goetz <go...@cse.buffalo.edu> wrote:
>> My approach is that the game should treat the player like the NPCs.
>> In <collective groan here> my 1986 game _Inmate_, NPCs and the player
>> performed actions exactly the same way. The only difference was that

>> the verb handler got PLAYER in the Agent slot instead of, say, MARK,
>> and the routines to print descriptions of events would change the
>> grammar to say "You pick up a red square" instead of "The player picks
>> up a red square". Descriptions were printed only for actions that
>> occurred in the player's room.
>
>I'm working on an actor-independent version of the Inform library.
>Instead of <<action noun>> you call DO(actor,action,noun) and all the
>same rules are applied to actor as would be to the player, as Phil
>describes above.

<Cough!> TADS has worked this way for some time. Under WorldClass, the
"Me" actor is even less unique (vs. NPCs, that is) than the standard
adv.t.


-Christopher Nebel

David Glasser

unread,
Dec 23, 1998, 3:00:00 AM12/23/98
to
Phil Goetz <go...@cse.buffalo.edu> wrote:

> My approach is that the game should treat the player like the NPCs. In
> <collective groan here> my 1986 game _Inmate_, NPCs and the player
> performed actions exactly the same way. The only difference was that the
> verb handler got PLAYER in the Agent slot instead of, say, MARK, and the
> routines to print descriptions of events would change the grammar to say
> "You pick up a red square" instead of "The player picks up a red square".
> Descriptions were printed only for actions that occurred in the player's
> room.
>

> So if you typed
>
> Tell Ed "Go north."
>
> the parser would take everything in quotes, run that through the parser,
> and hand the result to Ed as a request from the player. Ed could either
> refuse or execute the action. Each verb had a bit that said whether an NPC
> would by default perform the action if requested to. Mostly they would
> not. I can't remember if there was a separate bit for each NPC.

In fact, this is basically how TADS works: each doVerb method's first
argument is the actor. I think it only takes one line of code to make
"JOE, DO SOMETHING" work the exact same as "DO SOMETHING".

In practice, one rarely actually puts a "if (a = Me)" everywhere. But
you could, if you wanted.

--
David Glasser gla...@NOSPAMuscom.com http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4001 | r.a.i-f FAQ: come.to/raiffaq
Sadie Hawkins, official band of David Glasser: http://www.port4000.com/

Jonadab the Unsightly One

unread,
Dec 23, 1998, 3:00:00 AM12/23/98
to
"Rene van 't Veen" <r.nospa...@wxs.nospam.nl> wrote:


> >My approach is that the game should treat the player like the NPCs.

> [ .. major snippage ... ]

> Yes: the compiler, runtime and stock libraries should, IMHO,
> be designed and implemented such that "you" are treated
> as any other NPC as much as possible. Which would entail
> that NPC's can 'issue' commands and have the usual
> effects happen to them. This would make it a least a lot
> easier to endow NPC's with some 'intelligence'.
>
> Obviously, suitable messages should be displayed if (and
> only if) an NPC performs an action and you are in a position
> to observe that action, eg. "John takes the apple", "You take
> the apple".

> The current state of affairs is such that this is


> *difficult* with the standard platforms,

Actually, not *too* bad.
For example, under Inform, I think you'd need to do the
following:

Whenever an NPC executes an action:
Store the value of actor
set the value of actor to the NPC
<<Foo>>
restore the value of actor

That could all be done like so:

[ NPCAction V A N S temp;
if (V==0) CantHappen(); "NPCAction called with no verb!";
if (A==0) A = player;
temp = actor; actor = A;
if (N==0)
{
<V>; ! This is the only thing I'm not sure about;
! The action is allowed to be a variable, right?
}
else
{
if (S==0)
{ <V N>; }
else { <V N S>; }
}
actor = temp;
];

Then you have to replace a bunch of library
messages so that they check the value of Actor
and also whether that actor is in scope to the
player (which could be checked by a single
function call, and the function is near-trivial
to write). There are also some verb Subs that
incorrectly (for our purposes here) use the
value of player when they should use actor,
and you'd have to fix them. I think that
should just about do it.

Oh, your game has to be aware enough that
things like before and after rules check the
actor variable and scope to print their
messages, too.

Oh, one other thing: the player read the
text of room descriptions &c to notice
stuff, and then the library automatically
checks scope when the player types something
in. NPCs will need their own routine to
decide what actions to issue when.

A theif is easy: pick at random one of
the objects in the room the actor is in
and try to take it. Pick a compass object
at random and try to go that way.

An NPC with more complex goals will be
more difficult, but that's really a
separate issue and should be a distinct
thread if we care to discuss it.

- jonadab

graham...@hotmail.com

unread,
Dec 24, 1998, 3:00:00 AM12/24/98
to
In article <c.nebel-2212...@nebelch.apple.com>,

c.n...@apple.com (Chris Nebel) wrote:
> In article <si90fzh...@cre.canon.co.uk>, Gareth Rees
> <gar...@cre.canon.co.uk> wrote:
>
> >Phil Goetz <go...@cse.buffalo.edu> wrote:
> >> My approach is that the game should treat the player like the NPCs.
> >> In <collective groan here> my 1986 game _Inmate_, NPCs and the player
> >> performed actions exactly the same way. The only difference was that
> >> the verb handler got PLAYER in the Agent slot instead of, say, MARK,
> >> and the routines to print descriptions of events would change the
> >> grammar to say "You pick up a red square" instead of "The player picks
> >> up a red square". Descriptions were printed only for actions that
> >> occurred in the player's room.
> >
> >I'm working on an actor-independent version of the Inform library.
> >Instead of <<action noun>> you call DO(actor,action,noun) and all the
> >same rules are applied to actor as would be to the player, as Phil
> >describes above.

Hey, neat. I did that in my hack to support NPCs. I also changed most of
the references of Player to Actor, recalculated Location for the Actor, and
changed the way Actor was set so that it was always the correct actor. There
are a few other changest that have to be made to make sure that the correct
messages are displayed in the correct locations, too. You can look at it
here:

http://www.geocities.com/CollegePark/9315/gfinfo3d.zip

The changes are commented with !GLYPH, but there's not much as far as
explanations. Maybe next time.

- GLYPH

David Glasser

unread,
Dec 24, 1998, 3:00:00 AM12/24/98
to
Jonadab the Unsightly One <jon...@zerospam.com> wrote:

> <V>; ! This is the only thing I'm not sure about;
> ! The action is allowed to be a variable, right?

<(V)> should work.

Rene van 't Veen

unread,
Dec 24, 1998, 3:00:00 AM12/24/98
to

Jonadab the Unsightly One wrote in message
<36813b02...@news.bright.net>...

>"Rene van 't Veen" <r.nospa...@wxs.nospam.nl> wrote:
>
>
>> >My approach is that the game should treat the player like the
NPCs.
>
>> [ .. major snippage ... ]
>

[ .. major snippage ... ]

>> The current state of affairs is such that this is
>> *difficult* with the standard platforms,
>
>Actually, not *too* bad.
>For example, under Inform, I think you'd need to do the
>following:
>
>Whenever an NPC executes an action:
> Store the value of actor
> set the value of actor to the NPC
> <<Foo>>
> restore the value of actor
>

I am not that versed in Inform (more of a TADS-man),
but it goes along similar lines in Tads. In fact
*most* action responses (those that are not
hardcoded in the verb) already receive the actor
as a freebee, eg.:

raincoat : clothingitem
doWear(actor) =
{ inherited.doWear(actor) ;
"<<actor.thedesc>> <<actor.isdesc>>
wearing <<self.itdesc>>. " ; }

would do very nicely indeed.

I have also coded some routines for actors in TADS
that allows NPCs to perform commands in a fashion
similar to the execution of command(phrase) by the
parser. That bit wasn't all that hard, actually.

>
>Then you have to replace a bunch of library
>messages so that they check the value of Actor

And that is where the trouble begins ...

>and also whether that actor is in scope to the
>player (which could be checked by a single
>function call, and the function is near-trivial
>to write). There are also some verb Subs that
>incorrectly (for our purposes here) use the
>value of player when they should use actor,
>and you'd have to fix them. I think that
>should just about do it.
>
>Oh, your game has to be aware enough that
>things like before and after rules check the
>actor variable and scope to print their
>messages, too.
>
>Oh, one other thing: the player read the
>text of room descriptions &c to notice
>stuff, and then the library automatically
>checks scope when the player types something
>in. NPCs will need their own routine to
>decide what actions to issue when.
>

To summarize: it isn't really all that
hard, at least in principle. Most of it
is really trivial in TADS anyway. Some of
it isn't though.

I knew that already because I did it already
(in TADS). The *difficulty* is not in the principle,
it is in the *effort* of rewriting almost the
entire library + making sure that none of
your library routines and most objects you write
for the game make the implicit assumption that
the actor is *you*.

When I was just about to embark on this venture, which
in the end would have resulted in an almost complete
replacement of the entire adv.t and std.t library, I
stopped right there and then and thought:

hey, does the story I am telling actually use
this?

It didn't, so I stopped.

Maybe, just maybe, if I want to tell a story that does
use this, I will pick it up again.

>
>An NPC with more complex goals will be
>more difficult, but that's really a
>separate issue and should be a distinct
>thread if we care to discuss it.


Just my cup of tea ;-). Unfortunately, on my
part, it will have to wait for a couple of days,
as I am visiting relatives for Xmas.

Oh, before I forget:

----
A Merry Christmas and a Happy New Year to you all!

Sean T Barrett

unread,
Dec 29, 1998, 3:00:00 AM12/29/98
to
Rene van 't Veen <r.nospa...@wxs.nospam.nl> wrote:
>The *difficulty* is not in the principle,
>it is in the *effort* of rewriting almost the
>entire library + making sure that none of
>your library routines and most objects you write
>for the game make the implicit assumption that
>the actor is *you*.
>
>When I was just about to embark on this venture, which
>in the end would have resulted in an almost complete
>replacement of the entire adv.t and std.t library, I
>stopped right there and then and thought:
>
>hey, does the story I am telling actually use
>this?
>
>It didn't, so I stopped.

Agreed. I'm a hardcore technologist, and the biggest
battle I fight in working on IF is not going off on
a wild goose chase after some cool bit of technology
that really won't help me tell a story/create a fun
game.

<wild-goose-chase>

People who *are* thinking about doing this, though,
might want to look at MUDs to see if there's anything
to learn from there. *All* muds are coded so that
multiple objects can be the actor, and so that messages
are correctly displayed to the actor herself and to
other players who are observing the actor.

In fact, most MUDs therefore also allow NPCs to use
commands as well.

Take LPmuds, which I know the most about. NPCs can
issue commands just like other characters. Moreover,
there is a generic 'say' command for saying things out
loud, which you use to communicate with other players.
Anytime something happens in a room with a player, code
generates an appropriate string to indicate what that
player sees, e.g. you might see 'Satoria picks up a scimitar'.
NPCs are on a level playing field--they 'receive' a string
'message': "Satoria picks up a scimitar." Unfortunately,
this makes coding NPCs that react to their environment
somewhat cumbersome, as they have to do string parsing.
(But, it's nice that rather than giving 'orders', you can
communicate with them by simply talking out loud the same
way you do with players--something that simply can't be
duplicated in single-player IF.)

Dikumuds added a cute twist--one player who can
'see magic' might see "Satoria picks up a glowing scimitar",
while another sees "Satoria picks up a scimitar". And
if I am invisible, someone who cannot 'see invisible'
will see nothing.

Based on some ideas from a group called TEAM CTHULHU (sp),
some friends and I were working on a much more sophisticated
version of this (dikumuds are scripted, not programmable,
so it wasn't as flexible as one might like--which lead to
a lot of branches of the dikumud source tree).

Using a custom mud development system, we used a scheme
which TC had called 'descriptons'. Each time an event
occurs which needs to display info, rather than printing
message 1 to the actor, and printing message 2 to everyone
else in the room, the event generates a little object,
called a descripton, which "knows how to generate the message".
A distributing system 'propogates' the object around the
container hierarchy allowing everyone in the room who
'sees' the descripton to allow each one to query the descripton
to 'display' the message. At this point, the object can
query properties on the viewer to decide how to format the
output--testing if they can 'see magic' or 'see invisible',
testing if they know Elvish to decide how to display the
Elvish writing on the object, etc. Descriptons can represent
visual events, auditory events, or both. (Odors are left
as an exercise for the reader.) While propogating in and
out of containers, the descripton could be "filtered"--e.g.
if it propogates out of a soundproof but transparent box,
audio aspects are removed; if it propogates out of an opaque
box, visual aspects are removed.

All of this requires even *more* coding in the library and
on the part of the author; for example, if the author determines
that a given event description involves both sight & sound,
then the author must write a good textual description of the
event for each of the three cases (normal, blind, deaf), for
both the actor and for onlookers.

There's actually more payoff than the above; descriptons actually
propogate across rooms (a la the corridor in Deadline and a few
other Infocom games), turning corners if they're sound events and
not if sight, etc. etc. This required further authorship work,
determining how clearly a player should see an event at a distance,
etc.

All of this leads to a cool and fun experience for a game-y mud
full of interacting players, but is probably not that useful for
single-player storytelling IF.

However, this description was mainly here to setup what we did
for NPCs. A player-object queried the descripton: "give me a
string describing the event". Unlike LPmud, an NPC did not.
Instead, it send a different message to the descripton: "give
me an action-description-template". Such templates were simply
a standardized collection of structures representing common
sorts of events. This is derivative of some AI research,
although we weren't even thinking about that sort of AI, merely
trying to expediently solve the problem: how can we make NPCs
understand what goes on around them without having to do lots
of string parsing.

For example, the example given above would be represented by
the abstract template:

action = move object
actor = Satoria
object = scimitar
source = some room
destination = Satoria

This template can represent almost all object movements--pick up,
drop, throw into another room, player movement, putting in containers,
etc. Often, this is a useful simplification; a character may want
to react to an object being manipulated at all, for example. On the
other hand, if the NPC wants to distinguish one of these cases
specially, it has to do extra work; e.g. if it wants to react to
'get', it has to check actor == destination; if it wants to react
to 'drop', it has to check destination == parent(actor). On the
other hand, sometimes this is more flexible; for example, a character
may not really care about 'drop' so much as, say
(source isin actor && !(destination isin actor))
where ! is 'not' and 'isin' means 'anywhere inside'.

Anyway, in code, this was represented with just a five element list:

($move_object, Satoria-object, scimitar-object, some-room, Satoria-object)

The mapping is implicit, and in fact maps trivially to yet another
message send, which is how the stock NPC internally processed it--
by sending the first item in the list as a message to itself with
the rest of the list as the parameters of the message. This is
just an incredibly indirect way of implementing: send everyone
who can see this event one of several kinds of 'stock messages'
that describes the event.

The trick, of course, is coming up with stock templates that cover
all the possibilities; making as few as possible (to reduce work)
while not making them so few that important distinctions are lost.
The movement example above is no doubt the most powerful action
template, and also the least representative; but it's one of the
more important actions for NPCs to notice anyway.

We probably had about eight standard action types before the
project was canned (for reasons having more to do with time
availability and shifting interests than difficulty making
this stuff work). I remember in a philosophy class hearing
that somebody had claimed to have reduced all meaningful human
actions down to 13 core ones as above, and while I'm suspicious
of the claim (try perusing a thesaurus--nicely sorted distinct
meanings), I think it's fair to believe that we could create
a useful virtual world in which there are only 10 or 20 distinctive
actions--even if the player-viewed prose shows a lot more. (We're
trying to entertain the player, but we're not trying to entertain
the NPCs.)

What is this good for? I coded a simple test NPC which
noticed objects being dropped in nearby rooms, went in that
direction (no pathfinding, just relying on the fact that the
descripton for non-local events indicate through-which-exit
the event is being seen) and tried to pick the object up
and then come back. Another "pet" NPC watched for events like
'X hugs Y' and 'X slaps Y' (which all showed up in templates
as 'friendly-action' and 'unfriendly-action'--players were
not allowed to use 'emote's, only pre-canned 'atmosphere' actions,
so as to facilitate NPC interaction), and used a scoring
system to determine whether it "liked" people
depending on how friendly its 'owner' was towards other
people, and vice versa. I think these were fairly
good indicators of the power of this sort of system.

To see the source to the creatures described above,
without many comments and without any explanation of the
language or syntax, look at:

http://world.std.com/~buzzard/harry.txt
http://world.std.com/~buzzard/petbrain.txt

(It doesn't work exactly as I remembered, but hey, my memory
of 1993 is imperfect, big surprise.)

</wild-goose-chase>

Sean
I *did* say I was a hardcore technologist

TenthStone

unread,
Dec 30, 1998, 3:00:00 AM12/30/98
to
Jonadab the Unsightly One thus inscribed this day of Tue, 22 Dec 1998
08:56:18 GMT:

>Look at newsgroup.
They're all standing there. Watching you. You opened your mouth...
and now they're waiting. You'd better say something.

>Newsgroup, put a space before the angle bracket.
(Please.)
"Hey, umm, you guys? Could you, um, like, put spaces before
those, uh, you know, bent thingies? You know, those greater-than
symbols that you, uh, use when you're, uh, pretending that the newsgroup
is, like, a text adventure? Because I, like, use Free Agent? You know,
as a newsreader? And I, uh, like, kindof have it, like, display quoted
text in a different color? And if there's a space there, it, like, looks
better. Yeah. Uh, thanks."
A few of the people in the audience nod, agreeing with you. One --
you can't tell which -- leans toward another and says, "That wouldn't look
right in Linux."

The newsgroup turns toward you again, and awaits your answering of the
question.
You have nothing to say.

-----------

The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us

Reply all
Reply to author
Forward
0 new messages