"Bringing Characters To Life"
Neil Brown
Has anyone actually tried implementing the ideas in the article
"Bringing Characters To Life"? (Can't remember for the moment who wrote
it - Doug Atkinson, something like that?)
For those who haven't read it, it basically suggests that NPCs should
have lives of their own and shouldn't just react to the player's actions
with occassional random actions of its own thrown it. Emotions, personal
goals and behaviours should be simulated. (Presumably it would be better
to do this in real-time, but hey, one step at a time.)
______________
Neil James Brown
ne...@highmount.demon.co.uk
http://www.highmount.demon.co.uk
-
Neil Brown wrote:
>
> Has anyone actually tried implementing the ideas in the article
> "Bringing Characters To Life"? (Can't remember for the moment who wrote
> it - Doug Atkinson, something like that?)
>
> For those who haven't read it, it basically suggests that NPCs should
> have lives of their own and shouldn't just react to the player's actions
> with occassional random actions of its own thrown it. Emotions, personal
> goals and behaviours should be simulated. (Presumably it would be better
> to do this in real-time, but hey, one step at a time.)
At the moment I'm working (on and off) on what will end up as a largish
game, and I'm going to have all of the characters move around...
leaving home in the morning, going to work, possibly even taking time of
year into account (eg going out for dinner on their birthday instead of
eating at home).
--
Nicholas Daley
<dal...@ihug.co.nz>
Neil Brown
In article <qLYOnAAw...@highmount.demon.co.uk>, Neil Brown
<ne...@highmount.demon.co.uk> wrote:
>Has anyone actually tried implementing the ideas in the article
>"Bringing Characters To Life"? (Can't remember for the moment who wrote
>it - Doug Atkinson, something like that?)
>
>For those who haven't read it, it basically suggests that NPCs should
>have lives of their own and shouldn't just react to the player's actions
>with occassional random actions of its own thrown it. Emotions, personal
>goals and behaviours should be simulated. (Presumably it would be better
>to do this in real-time, but hey, one step at a time.)
I ask all this because I've built the foundations of a game that is
intended to be heavily NPC-oriented, and now I have to decide whether to
build in and pre-program all the behaviour (eg move character to room x
by turn 3, say q and then move to room y) or provide a large number of
possible behaviours based on certain motivation factors and let the NPCs
get on with it themselves. The pre-program method seems too much like
forcing a story to happen rather than letting it progress naturally, but
it would be the easier of the two to code.
Can anyone offer any advice?
Mary K. Kuhner
>I ask all this because I've built the foundations of a game that is
>intended to be heavily NPC-oriented, and now I have to decide whether to
>build in and pre-program all the behaviour (eg move character to room x
>by turn 3, say q and then move to room y) or provide a large number of
>possible behaviours based on certain motivation factors and let the NPCs
>get on with it themselves. The pre-program method seems too much like
>forcing a story to happen rather than letting it progress naturally, but
>it would be the easier of the two to code.
To what extent will the player be able to tell the difference?
NPC behavioral complexity that is opaque to the player is a waste of
coding effort (unless you enjoy coding it for its own sake), so you
need to take a player's-eye look at the game and see where the extra
coding might actually make a difference. For example, someone earlier
mentioned an NPC who did something different on his birthday. Unless
the player can find out why the NPC did something different (birthday
card, conversation, seeing him at the party) it's just going to seem
like random behavior, and might as well have been.
You will be in for a horrid testing effort trying to find out if
the game is winnable, if you let NPC motivations bouncing off each
other have much role in the plotline. You could easily make the
mistake seen in the vidgame "XCOM II" where the game is sometimes
winnable and sometimes not, depending on a random roll early on.
If your plotline is at all linear, you probably want to pre-program;
behavior models will lend themselves better to a very loose, non-
directional plotline. You might look at "Trust and Betrayal" if
you can find it; it goes much further in this direction than any
IF I know, and shows strengths and weaknesses of the attempt.
You can spend a *long* time in T&B trying to out-sweettalk the NPCs,
and having your efforts undercut by what's going on among them.
Progress is often frustratingly slow. And, though the designer tried
to put in specific plot events, they jar with the rest of the game
since it's hard for the player to talk to the NPC about "that alarming
thing that happened last night."
You may have trouble getting decent NPC dialog if it has to link to
NPC mental states you can't predict in advance, since you can't write
a natural-language conversation generator for the game....
In other words, I'm pessimistic that heavy attention to behavioral
models will help. I'd keep it simple, but try to make your
pre-programming *look* like a behavioral model by catching some of
the appropriate branches and allowing for them explicitly.
Then again, I'm seriously thinking about killing off some NPCs in
my current game; too bloody much code! So maybe I'm just a wimp.
Mary Kuhner mkku...@genetics.washington.edu
Neil Brown
In article <5oefjo$p...@nntp5.u.washington.edu>, "Mary K. Kuhner"
<mkku...@phylo.genetics.washington.edu> wrote:
>To what extent will the player be able to tell the difference?
To the extent that something that happened on one go may not happen on
another. The main influencing factor would be what the player does. If
the player slaps a character early on, that character might run off to
the boss to complain. The boss may then mark the player down as a rogue
and may not trust him/her as much.
Ny first idea was to have a very linear plot - first this happens, then
that, then all the NPCs run off to the conference room to have a
meeting, and x says this, and y says that... I then realised that this
method would exclude the player from a lot of the NPC interaction. How
on earth would I allow for the player saying things at this meeting, for
example? I thought about getting an NPC to invite the player to speak at
certain points, ignoring what the player said at other occasions, but
this just wouldn't happen. The player is an important person; everyone
would listen carefully to what s/he had to say.
The problem isn't just with conversations, but with many other aspects
of NPC interaction. Perhaps with simulating behaviour, I wouldn't be
able to have as much detail, but I believe that it would feel more
natural.
>NPC behavioral complexity that is opaque to the player is a waste of
>coding effort (unless you enjoy coding it for its own sake), so you
>need to take a player's-eye look at the game and see where the extra
>coding might actually make a difference. For example, someone earlier
>mentioned an NPC who did something different on his birthday. Unless
>the player can find out why the NPC did something different (birthday
>card, conversation, seeing him at the party) it's just going to seem
>like random behavior, and might as well have been.
>
>You will be in for a horrid testing effort trying to find out if
>the game is winnable, if you let NPC motivations bouncing off each
>other have much role in the plotline. You could easily make the
>mistake seen in the vidgame "XCOM II" where the game is sometimes
>winnable and sometimes not, depending on a random roll early on.
Testing is going to be a problem with what I'm proposing, but for what
I'm writing, NPCs acting wildly against character are likely to be more
of a problem. How do you model a human being accurately?
>You may have trouble getting decent NPC dialog if it has to link to
>NPC mental states you can't predict in advance, since you can't write
>a natural-language conversation generator for the game....
By a happy co-incidence, all of my NPCs have suddenly developed
laryngitis... No, I'm sure it's possible. I'm sure it's possible...
(famous last words).
>In other words, I'm pessimistic that heavy attention to behavioral
>models will help. I'd keep it simple, but try to make your
>pre-programming *look* like a behavioral model by catching some of
>the appropriate branches and allowing for them explicitly.
>
>Then again, I'm seriously thinking about killing off some NPCs in
>my current game; too bloody much code! So maybe I'm just a wimp.
Just do what everyone else does - make your NPCs deaf, or stupid, or
just plain rude. That way, they don't have to respond to much. :-)
Stephen Robert Norris
This discussion brings up an interesting (well, to me) question. How
much code do NPCs take? I mean someone like the chap with the parrot in
Christminster. I've just started playing with inform, and I can well
imagine having literally thousands of lines of code for an NPC...
Stephen
Miron Schmidt
Stephen Robert Norris <s...@psrg.cs.usyd.edu.au> wrote:
> This discussion brings up an interesting (well, to me) question. How
> much code do NPCs take? I mean someone like the chap with the parrot in
> Christminster.
The chap with the parrot takes up around 600 lines, plus a couple of special
routines all NPCs in _Christminster_ use. His name is Edward, by the way.
Also keep in mind that Edward is a very well-develeoped character in a very
large game. A good deal of his code go into situation-dependent actions, such
as being in the same room when one tries to read the bible, etc.
As for well-developed characters in moderate-sized games:
Christopher Robin from _Ralph_ has ~250 lines in the current release (6).
One of the prominent characters in my upcoming competition game has ~100
lines at the moment, with about half his conversational skills, a third of
his general reactions, and none of his puzzle-specific code finished.
--
Miron Schmidt <mi...@comports.com> PGP key on request
WATCH TV... MARRY AND REPRODUCE... OBEY... PLAY INTERACTIVE FICTION...
Joe Mason
"Re: "Bringing Characters", declared Neil Brown from the Vogon ship:
NB>I ask all this because I've built the foundations of a game that is
NB>intended to be heavily NPC-oriented, and now I have to decide whether
NB>to build in and pre-program all the behaviour (eg move character to
NB>room x by turn 3, say q and then move to room y) or provide a large
NB>number of possible behaviours based on certain motivation factors and
NB>let the NPCs get on with it themselves. The pre-program method seems
NB>too much like forcing a story to happen rather than letting it
NB>progress naturally, but it would be the easier of the two to code.
NB>Can anyone offer any advice?
It depends on how exactly your story is set up. The one I'm writing
(extremely slowly) uses the first method you mentioned - and don't
automatically assume its easier to code! You still have to either write
general routines to handle what happens when the player interrupts your
pre-planned movement path (meaning you have to do a lot of the work from
the second method too) or carefully pre-plan what the NPC does for every
possible player action (a recipe for disaster!) Of course, the easy way
out of this is to artificially limit the ways the player can interact,
but I strongly recommend against it except for specific scenes.
(Of course, the specific scenes where the character is restrained are
the only ones I've got written so far, so I don't have a solution to the
above problem yet...)
Joe
ş CMPQwk 1.42 9550 şMy toughest fight was with my first wife. - Ali
Mary K. Kuhner
In article <5ohn7j$a...@staff.cs.su.oz.au> s...@fn.com.au writes:
>This discussion brings up an interesting (well, to me) question. How
>much code do NPCs take? I mean someone like the chap with the parrot in
>imagine having literally thousands of lines of code for an NPC...
> Stephen
Thousands of lines of code. More than anything else. Especially if
they are not limited to just one scene--for example, in the game I'm
currently working with, early on an NPC won't talk about X or Y (she
is keeping them secret from the PC) but will talk about the current
puzzle. Later, when X and Y have been revealed, she will talk about
them but no longer cares about the first puzzle. Still later, after
X has been dealt with, she is mainly interested in Y. It is easy to
end up with five to ten different states for even a simple NPC, each
of which has mostly its own set of responses to actions and questions.
I tried coding a bargaining scene--whoof.
I'm curious myself--in games like Christminster or Jigsaw where an
NPC appears in several distinct scenes, is it usual to code the NPC
as one object or several? I've tried both and I'm still not sure
which works best. The single-object approach makes for huge
confusing player-objects. The multiple-object approach leads to
weird little bugs like "Which Grandmother do you mean?" as
a response to "Who is Grandmother?" (done with scope=All in
Inform) and makes inventory and so forth tricky.
Mary Kuhner mkku...@genetics.washington.edu
Katy Mulvey
On 21 Jun 1997 23:13:55 GMT, Stephen Robert Norris <s...@psrg.cs.usyd.edu.au> wrote:
>This discussion brings up an interesting (well, to me) question. How
>much code do NPCs take? I mean someone like the chap with the parrot in
>Christminster. I've just started playing with inform, and I can well
>imagine having literally thousands of lines of code for an NPC...
For this particular question, you can check the source for Christminster.
It's online at:
ftp://ftp.gmd.de/if-archive/games/source/inform/minster.tar.gz
The entire game takes about 15000 lines of inform code.
--
Katy Mulvey
Home: mul...@frontiernet.net http://www.frontiernet.net/~mulveyr/Katy
Neil Brown
In article <66.982...@tabb.com>, Joe Mason <joe....@tabb.com>
wrote:
>It depends on how exactly your story is set up. The one I'm writing
>(extremely slowly) uses the first method you mentioned - and don't
>automatically assume its easier to code! You still have to either write
>general routines to handle what happens when the player interrupts your
>pre-planned movement path (meaning you have to do a lot of the work from
>the second method too) or carefully pre-plan what the NPC does for every
>possible player action (a recipe for disaster!) Of course, the easy way
>out of this is to artificially limit the ways the player can interact,
>but I strongly recommend against it except for specific scenes.
I'm assuming that pre-programmed behaviour in NPCs is easier to program
because it's been done before many times - I've done it myself (to an
extent). Letting the NPCs run around doing what they want is bound to be
harder because it's been done very few times, and never using the
popular IF languages (TADS, Inform, Hugo etc) to my knowledge. There's
nothing to compare the results with, and no code to examine. And really
accurate testing would require the services of a psychologist...
Joe Mason
-> This discussion brings up an interesting (well, to me) question. How
-> much code do NPCs take? I mean someone like the chap with the parrot
-> in Christminster. I've just started playing with inform, and I can
-> well imagine having literally thousands of lines of code for an
-> NPC...
You can get the Christminster source code somewhere at GMD - I can't
remember the exact address. It's either near compilers/inform5.5 and
the rest of the example code or its near games/infocom, I think.
Anyway, checking my copy, the actual Edward object is 585 lines long.
But a lot of the actions he takes are scattered through the rest of the
code.
Joe
Joe Mason
"Re: "Bringing Characters", declared Mary K. from the Vogon ship:
MK>I'm curious myself--in games like Christminster or Jigsaw where an
MK>NPC appears in several distinct scenes, is it usual to code the NPC
MK>as one object or several? I've tried both and I'm still not sure
MK>which works best. The single-object approach makes for huge
MK>confusing player-objects. The multiple-object approach leads to
MK>weird little bugs like "Which Grandmother do you mean?" as
MK>a response to "Who is Grandmother?" (done with scope=All in
MK>Inform) and makes inventory and so forth tricky.
In Christminster, Edward is a single object.
I prefer to make many objects. For example, in _In The End_, there are
three objects for Annie - one when she's standing in the parking lot,
one when she's sitting in the car, and one when she's mad at you.
They're all members of the class Annie which contains the stuff that is
common to all of them.
Here's the code I use - it might help you:
Class NPC
class MyObj,
with
register_self 1,
has animate;
[ NewPersona old new;
if (new.register_self()) {
move new to parent(old);
remove old;
while (child(old)~=0)
move child(old) to new;
StopDaemon(old);
StartDaemon(new);
if (old has female && herobj == old) herobj = new;
else { if (himobj == old) himobj = new; };
};
];
The "register_self" returns 1 for a default NPC, so that by default this
will work. If you want any other conditions for changing from one of
the objects to another, you can put them in the register_self routine
and return false if it shouldn't work.
So Annie would start out like this:
Global Annie_Obj = Annie_In_Parking_Lot;
Class AnnieClass
class NPC,
with
name "Annie",
register_self [;
Annie_Obj = self;
rtrue;
],
< other code for all Annie's >
has female proper;
Object Annie_In_Parking_Lot
class AnnieClass,
with
< code for this Annie >
Object Annie_In_Car
class AnnieClass,
with
< code for this Annie >
The first version of Annie is in the parking lot. When she gets in the
car, you just call
NewPersona(Annie_Obj, Annie_In_Car);
move Annie_Obj to car;
Because you use a variable to point to the "current" Annie, there's
never any confusion about which one you mean.
Joe
ş CMPQwk 1.42 9550 şAnd God said: E = «mvı - Zeı/r, and there was light!
FemaleDeer
I've thought about it, but have no interest in programming such a
difficult thing at this time.
The rough way to do it, is give the characters "attitudes". Depending on
the what the protagonist does, they would reply or react differently based
on their current attitude toward the protagonist. However, I just
short-cut this intensively coding method and give each of my characters an
"attitude" toward the protagonist to begin with. They are not all
friendly, for instance.
But this is one way to start:
if (action==##Kiss)
give character attitude_amorous
if (gun in player)
give character attitude_scared
if (character has busy)
give character attitude_distracted
I think Chris Crawford writes about this somewhere in some article or
book.
Femal...@aol.com
"If builders built buildings the way most programmers program, civilization would fall apart with the first peck of a woodpecker."
Neil Brown
In article <19970630052...@ladder02.news.aol.com>, FemaleDeer
<femal...@aol.com> wrote:
>The rough way to do it, is give the characters "attitudes". Depending on
>the what the protagonist does, they would reply or react differently based
>on their current attitude toward the protagonist. However, I just
>short-cut this intensively coding method and give each of my characters an
>"attitude" toward the protagonist to begin with. They are not all
>friendly, for instance.
>
>But this is one way to start:
>
>if (action==##Kiss)
> give character attitude_amorous
>if (gun in player)
> give character attitude_scared
>if (character has busy)
> give character attitude_distracted
But then, what if the player kisses a very busy character while holding
a gun? The player would also be startled, confused etc. I don't think
representing emotions with attributes would be a good idea - for a
start, there are only a limited number of attributes available, and many
types and ranges of emotions. And looking back at this example, there
are different types of kiss - kissing your grandmother, kissing a
friend, kissing a lover. It's all so complicated.
Al Sullivan
FemaleDeer <femal...@aol.com> wrote:
> I've thought about it, but have no interest in programming such a
> difficult thing at this time.
> The rough way to do it, is give the characters "attitudes". Depending on
> the what the protagonist does, they would reply or react differently based
> on their current attitude toward the protagonist. However, I just
> short-cut this intensively coding method and give each of my characters an
> "attitude" toward the protagonist to begin with. They are not all
> friendly, for instance.
> But this is one way to start:
> if (action==##Kiss)
> give character attitude_amorous
> if (gun in player)
> give character attitude_scared
> if (character has busy)
> give character attitude_distracted
> I think Chris Crawford writes about this somewhere in some article or
> book.
> Femal...@aol.com
> "If builders built buildings the way most programmers program, civilization would fall apart with the first peck of a woodpecker."
you wind up with very shallow characters that have no internal conflict.
They called flat and uninspired. The best characters are designed around
some internal turmoil, otherwise you wind up with sit com people who
nobody would care about.
FemaleDeer
Hey, I was just suggesting, for the guy who asked, a way to begin. It
would have to be much more complex than what I showed.
I personally agree that it is more interesting to have some consistent
internal conflict the character may have and how that conflicts affects
their reactions to the protagonist. This is why I give my characters one
"attitude" to begin with. That is more like a novel, a story telling
approach to game writing.
But within that frame work other emotions could then come to the fore. A
slightly friendly character could then become amorous, a brave character
could become somewhat fearful. The friendly character could respond
differently when just friendly vs. amorous, the brave character could
respond differently than when brave or slightly scared. It would be a
massive programming task to set up different responses based on their
current emotional states (and based on the player's previous actions
toward them which caused some of those states), but some might (for some
reason) think it was worth it. It is more similar to the "strengths" idea
of role playing characters in graphic games than anything else.
I heard Chris Crawford talk about this once in San Jose. It was a virtual
reality concept, modeling the game world to be more like the real world.
I, myself, can see no real use for it at this time. But maybe someone
could.
If you want characters to be living their lives as the player approaches
them, carrying on as normal and until the player interrupts, that can be
done with "traditional" IF writing now. They can act interrupted and a
daemon that starts them on their course can be started when the player
enters the area, turned off when the player leaves, with self.number set
to something, restarted with the same self.number or a new one depending
on time passage. I see no need for the characters to live lives outside of
the player's scope (unless they are wandering through a game for a
purpose). The game, after all, is FOR the player, it is from THEIR
viewpoint.
Maybe I should keep my mouth shut, I only started posting to this group a
few days ago. Before I lurked.
FemaleDeer
-------------------------------------------------------------------------------------------
Neil Brown
In article <19970701012...@ladder02.news.aol.com>, FemaleDeer
<femal...@aol.com> wrote:
>Hey, I was just suggesting, for the guy who asked, a way to begin. It
>would have to be much more complex than what I showed.
I hope you didn't take offence at my posting - that wasn't the
intention. I was just pointing out the difficulties. Anyway, I've
abandoned the idea for the time being, as it is all too complicated for
what I'm working on at the moment.
However, I do think that Al Sullivan's post could have been written a
little more diplomatically.
>I personally agree that it is more interesting to have some consistent
>internal conflict the character may have and how that conflicts affects
>their reactions to the protagonist. This is why I give my characters one
>"attitude" to begin with. That is more like a novel, a story telling
>approach to game writing.
Internal conflicts are perhaps more suited to novels where the subject
can be explored extensively and with subtlety. I think the reason why IF
characters are so hard to do convincingly is that you can't have that
subtlety. Novels can switch points of view fairly regularly in order to
enable the reader to see the full story, but IF is restricted (or should
I say 'restricts itself') to one point of view. There are other
disadvantages of IF when compared to the novel: good IF can have several
different pathways, so the player may not come across a crucial moment
in a character's development at all (unless the author forces this to
happen), and while an IF author can present the signs of an internal
conflict within a character, there is no guarantee that the player will
read it or understand it. The reader of a novel *has* to go through B to
get to C from A.
Comic characters are popular in IF in my opinion because they usually
conform to a stereotype, so they automatically have something the player
can latch on to. "Oh, this is the bullying guard, this is the
overbearing mother, the bad-tempered woman..."
>But within that frame work other emotions could then come to the fore. A
>slightly friendly character could then become amorous, a brave character
>could become somewhat fearful. The friendly character could respond
>differently when just friendly vs. amorous, the brave character could
>respond differently than when brave or slightly scared. It would be a
>massive programming task to set up different responses based on their
>current emotional states (and based on the player's previous actions
>toward them which caused some of those states), but some might (for some
>reason) think it was worth it. It is more similar to the "strengths" idea
>of role playing characters in graphic games than anything else.
>
>I heard Chris Crawford talk about this once in San Jose. It was a virtual
>reality concept, modeling the game world to be more like the real world.
>I, myself, can see no real use for it at this time. But maybe someone
>could.
>
>If you want characters to be living their lives as the player approaches
>them, carrying on as normal and until the player interrupts, that can be
>done with "traditional" IF writing now. They can act interrupted and a
>daemon that starts them on their course can be started when the player
>enters the area, turned off when the player leaves, with self.number set
>to something, restarted with the same self.number or a new one depending
>on time passage. I see no need for the characters to live lives outside of
>the player's scope (unless they are wandering through a game for a
>purpose).
By area do you mean room, surrounding rooms or different 'zones' within
the game? For instance, it is useful for Austin the cat to move around
while the player is in the attic, but there's no point moving him around
if the player is currently in the surreal city (which is what I mean by
a different zone). In that respect I agree with you.
>The game, after all, is FOR the player, it is from THEIR
>viewpoint.
>Maybe I should keep my mouth shut, I only started posting to this group a
>few days ago. Before I lurked.
No, keep those posts coming thick and fast. Some replies may sound a bit
off but usually the author didn't intend it to be so.
FemaleDeer
>By area do you mean room, surrounding rooms or different 'zones' within
>the game? For instance, it is useful for Austin the cat to move around
>while the player is in the attic, but there's no point moving him around
>if the player is currently in the surreal city (which is what I mean by
>a different zone). In that respect I agree with you.
Yes, exactly. Some characters (daemons) have to keep running all the time,
but most don't. Usually the player goes to an "area" they are not in.
>No, keep those posts coming thick and fast. Some replies may sound a bit
>off but usually the author didn't intend it to be so.
Okay. Thanks.
Phil Goetz
>>By area do you mean room, surrounding rooms or different 'zones' within
>>the game? For instance, it is useful for Austin the cat to move around
>>while the player is in the attic, but there's no point moving him around
>>if the player is currently in the surreal city (which is what I mean by
>>a different zone). In that respect I agree with you.
I think this is only acceptable at present because of the simplicity
of our NPCs.
I would like to have some metric of distance from the player,
and give each agent processing time that is a decreasing function
of distance from the player. Of course, this won't work either...
If "processing time" is converted to something like "depth of search
allowed", then characters get faster and dumber as the player moves farther
away from them.
Phil Go...@cs.buffalo.edu
FemaleDeer
>I would like to have some metric of distance from the player,
>and give each agent processing time that is a decreasing function
>of distance from the player. Of course, this won't work either...
>If "processing time" is converted to something like "depth of search
>allowed", then characters get faster and dumber as the player moves
farther
>away from them.
>Phil Go...@cs.buffalo.edu
??? You are limited by the turns. Only so much action can take place
during one turn. A daemon cannot run faster than a turn, but it could run
slower. It could run only every other turn, or every third turn. Good
luck.
------------------------------------------------------------------------------
Femal...@aol.com The Tame Computer
"Loyalty to petrified opinion never yet broke a chain or
freed a human soul." Mark Twain (or won a game)
Dan Shiovitz
In article <19970713114...@ladder02.news.aol.com>,
FemaleDeer <femal...@aol.com> wrote:
>>I would like to have some metric of distance from the player,
>>and give each agent processing time that is a decreasing function
>>of distance from the player. Of course, this won't work either...
>>If "processing time" is converted to something like "depth of search
>>allowed", then characters get faster and dumber as the player moves
>farther
>>away from them.
>
>>Phil Go...@cs.buffalo.edu
>
>??? You are limited by the turns. Only so much action can take place
>during one turn. A daemon cannot run faster than a turn, but it could run
>slower. It could run only every other turn, or every third turn. Good
>luck.
I believe what he was referring to was actual processing time by the
computer, ie, CPU cycles. This doesn't really come up much in IF
because we don't do very much compute-intensive stuff; the most
intensive thing I can think of is probably the TADS WorldClass
library's habit of testing the locations of every objects in the
game for scope reasons.
But if we do every get around to doing better NPCs, they'll take up
more processing time deciding what to do. And there is some limit on
how much processing the computer can do every turn; if there's a time
lag of a full minute every time you hit return, people just won't want
to play the game. So probably, you'll divide the time you do have up
so that the computer spends more time making the nearby NPCs realistic
and less time on the faraway NPCs that the player won't see.
>Femal...@aol.com The Tame Computer
--
Dan Shiovitz :: scy...@u.washington.edu :: sh...@cs.washington.edu
..................................................................
"Alas, I do not rule the world and that, I am afraid, is the story
of my life: always a godmother, never a God." -- Fran Lebowitz
...http://weber.u.washington.edu/~scythe/home.html................