[Inform] Stop prompt & Delay parse
FReDRiK RaMSBeRG (WILdcARD)
Hi all,
I'm writing a little routine to allow the player to type things like:
>GO TO THE KITCHEN
I've got it to work fine for other actors. When the player does it to move
himself around though, there is a problem. I need to end his turn after
every move, as if he had typed a movement command himself. Does anyone know
of an even remotely nice way to do this. I'd hate to put the directions
into the parser, it feels so crude.
Problem 2:
I want to delay parsing of all commands but the first, so that it's possible
to type:
>JOSH, GO TO THE APPLE TREE. PICK AN APPLE THEN RETURN TO ME
...without getting the reply that there is no apple here. Any ideas on how to
do this?
Thanks,
/Fredrik
--
Fredrik Ramsberg, d91f...@und.ida.liu.se, http://www-und.ida.liu.se/~d91frera
------------------------------------------------------------------------------
I want to make it perfectly clear that I can't say I don't think people who
aren't avoiding using too many negations aren't putting things clearly enough.
Florian Beck
d91f...@ida.liu.se (FReDRiK RaMSBeRG (WILdcARD)) writes:
> Hi all,
>
> I'm writing a little routine to allow the player to type things like:
>
> >GO TO THE KITCHEN
Sorry, can't help. But sounds interesting. Could you elaborate a bit
on how you do this. I've tried something like this myself. But soon I
drowned in tons of shortest-way-algorithms for every NPC, handling
obstacles that weren't there the last time the character passed a
location (and avoiding the game going around that obstacle: if the
player doesn't know about it he should walk right into it), handling
exit routines in the shortest-way-algorithm (esp those killing the
player and stuff), has_visited room attributes for every character,
keeping track what places and objects the characters know about, and
so on. Nothing impossible, but lots of things to keeps track of.
Eventually, I gave up.
--
Flo
FReDRiK RaMSBeRG (WILdcARD)
Florian Beck <f...@ue801di.lrz-muenchen.de> writes:
I think the secret is to start out with something less complicated, get it
to work, and learn while doing it. That knowledge will make it easier to
see how to solve future problems, when extending the algorithm.
I have now, as far as I can tell, solved my first prolem, getting the player
to walk around with time passing as usual, so both GO TO THE KITCHEN and
JOHN, GO TO THE KITCHEN work fine.
I ended up modifying a piece of code from timewait.h by Andrew Clover (thanks
Andrew!) to let time pass while the player walks around.
Here's what my routines do:
First, a routine called FindPath, that takes three arguments; startlocation,
destination and actor. It uses breadth-first searching, utilizes knowledge
about the state of doors on the way that the the actors maybe shouldn't
possess. For this particular game, it doesn't matter. If you think it does, you
can store an array of knowledge in every actor, that the routine will look
for when making decisions about what paths are possible. Furthermore, the
routine will only try to pass through doors of a certain class, and will only
try to pass through rooms of a certain second class. That way, I can
restrict the search to the meaningful areas, and no one will go to
sudden-death-locations, if they are coded as a routine in an exit.
All actors are of the class Walker. That way, they are guaranteed to have all
the properties that the various routines are trying to read and write. That
class sets up a daemon, calling self.walk(), which does the actual walking.
If the actor needs a daemon that does more, he can set up his own, just
making sure he calls self.walk() from it. self.walk() calls self.move(), which
is the same for all actors except the player, as he needs to call PlayerTo();
If a movement proves impossible, due to a door that has been locked _after_
the path was established, the walk-routine calls FindPath to find another
way to get to the target.
The player is not moved using a daemon, because I want to make sure his
walking is done before everybody else's, just as if he typed every command
himself. He still uses the same walk-routine, though.
These routines are a bit more complicated than this, to speed up search and
handle other things than just walking around for instance, but more detail
would make it less comprehensible. They are still under development, but
I'm pretty close to what I need for this game, so I won't refine them much
more at the moment.
Something I think a lot of people (including myself) tend to forget, is that
we're trying to create an illusion for the player. If the player never
realizes that your actors are purposefully avoiding the use of information
they should not have aquired, why spend effort building it that way?
I would find it interesting to hear peoples opinions on how NPC:s can be
made more realistic. Anyone in for a discussion? (I know the topic has been
dealt with before, but still very few games display credible NPC:s)
Regards,
Dan Shiovitz
In article <5ei4g6$6...@curofix.ida.liu.se>,
FReDRiK RaMSBeRG (WILdcARD) <d91f...@ida.liu.se> wrote:
[..]
>Something I think a lot of people (including myself) tend to forget, is that
>we're trying to create an illusion for the player. If the player never
>realizes that your actors are purposefully avoiding the use of information
>they should not have aquired, why spend effort building it that way?
>
>I would find it interesting to hear peoples opinions on how NPC:s can be
>made more realistic. Anyone in for a discussion? (I know the topic has been
>dealt with before, but still very few games display credible NPC:s)
AFAIK, the reason few games display credible NPCs is because, for one
thing, a credible NPC should have a number of different conversation
responses on the order of the number of items in the game times the
number of plot changes you can talk to her during. Which is an awful
lot. And that's just conversation. Personally, I'd like to see more
work being done on giving NPCs goals outside their encounters with the
players. Windhall was pretty good about this, in the sense that the
people all had activity cycles, but still, I don't remember that the
blacksmith guy did anything other than hit the anvil and sleep. Now,
if he made horseshoes, shoed horses that came in occasionally, went to
the bakers' to buy some bread for lunch, came back, went outside to
take a nap, played a little solitaire, made some nails, argued with a
customer about those horseshoes he'd sold last week, and then went up
to bed, *that* would be impressive. I'm just not sure how to do this
sort of thing ;P
>Regards,
>Fredrik Ramsberg, d91f...@und.ida.liu.se, http://www-und.ida.liu.se/~d91frera
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more
sensible people ... remember to speak up for freedom because no one else
will do it for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
FReDRiK RaMSBeRG (WILdcARD)
an...@ici.net (Anson Turner) writes:
>: I'm writing a little routine to allow the player to type things like:
>:
>: >GO TO THE KITCHEN
>:
>: I've got it to work fine for other actors. When the player does it to move
>: himself around though, there is a problem. I need to end his turn after
>: every move, as if he had typed a movement command himself. Does anyone know
>: of an even remotely nice way to do this. I'd hate to put the directions
>: into the parser, it feels so crude.
>Call InformLibrary.end_turn_sequence() (assuming you're using the newer
>libraries; I don't remember the name of the routine in the older ones)
>after every movement except the last one (or else set meta=1 after the last
>move, so that the library won't cause another turn to pass when you finally
>return control of the game).
We're still using Inform 6.05 with library 6/2. For the game we're making, we
don't have much need for Inform 6.10+, and it still seems to be more buggy
than 6.05, so I think we'll finish it in 6.05.
The name of the routine is End_turn_sequence(), as I found out from the
code I ended up "borrowing" from timewait.h. It uses 'meta=1' as well, and
the whole routine works correct now, including the turn counter. Thanks for
the help anyway!
I still don't know how to give an actor a line of commands like:
>JOHN, GO TO KITCHEN THEN GET THE KNIFE THEN RETURN HERE
It seems that it starts by letting John stroll off, and then tries to parse
the rest of the sentence, which generates the reply:
"You seem to want to talk to someone, but I can't see whom."
Is this something the parser was definitely _not_ made to handle, or is
there a way?
/Fredrik
--
Fredrik Ramsberg, d91f...@und.ida.liu.se, http://www-und.ida.liu.se/~d91frera
FReDRiK RaMSBeRG (WILdcARD)
scy...@u.washington.edu (Dan Shiovitz) writes:
>AFAIK, the reason few games display credible NPCs is because, for one
>thing, a credible NPC should have a number of different conversation
>responses on the order of the number of items in the game times the
>number of plot changes you can talk to her during. Which is an awful
>lot. And that's just conversation. Personally, I'd like to see more
Then again, developing the characters, including writing their conversation,
can be a lot of fun. If just a bunch of strings would do, it wouldn't be
so much work. The problem is that you need to figure out just what situation
it is, have several ways of saying the same thing, and be able to insert
parameters anywhere. I sure wish someone could come up with a neat way of
organizing that so that you can spend less time coding for the conversation
and more time on the actual lines.
>work being done on giving NPCs goals outside their encounters with the
>players. Windhall was pretty good about this, in the sense that the
>people all had activity cycles, but still, I don't remember that the
>blacksmith guy did anything other than hit the anvil and sleep. Now,
>if he made horseshoes, shoed horses that came in occasionally, went to
>the bakers' to buy some bread for lunch, came back, went outside to
>take a nap, played a little solitaire, made some nails, argued with a
>customer about those horseshoes he'd sold last week, and then went up
>to bed, *that* would be impressive. I'm just not sure how to do this
>sort of thing ;P
Sounds pretty much like what we're trying to achieve in Stranded, the game
we're making. We try to keep the action code general and small, but still
end up with a lot of rather specialized code, like one routine for locking
doors, one for unlocking them, one for opening them etc. It's really beginning
to look good when playing it, but it takes some code.
Perhaps we should make a library extension that contains all the nasty details?
The problem is that you probably want to add your own little code and texts
for those special, personal things (for instance, I think the secretary in
Gumshoe is great, getting up and closing the door, looking generally
discontent, if you leave it open for a while). I can't see a good, general way
of doing it at the moment. Does anyone have any ideas?
Kenneth Albanowski
In article <5ei4g6$6...@curofix.ida.liu.se>,
FReDRiK RaMSBeRG (WILdcARD) <d91f...@ida.liu.se> wrote:
>
>Something I think a lot of people (including myself) tend to forget, is that
>we're trying to create an illusion for the player. If the player never
>realizes that your actors are purposefully avoiding the use of information
>they should not have aquired, why spend effort building it that way?
I think because it's generalized, and lets you build NPC by knowledge rules
instead of action scripts.
Also think of it from the perspective of a player trying unusual commands.
With proper knowledge limitations, you might need no special-purpose code
whatsoever to do something like this:
> LOOK
This is a room, and not much more.
You see Judy here.
> JUDY, GO TO GEORGE AND TELL HIM TO COME HERE
"I'm sorry, but I don't have the foggiest idea where George got to."
> XYZZY
With a wonderous noise, splendid lights, and a rather insipid odour of
reconstituted coconut, a large and well-constructed wooden door appears
in the east wall.
> OPEN DOOR
Opened.
> JUDY, EAST
Judy walks away to the east.
> EAST
You are in what appears to be a surprisingly roomy closet.
You see Judy and George here.
> JUDY, WEST
Judy walks away to the west.
> WEST
This is a room, and not much more. There is a door to the east.
You see Judy here.
> JUDY, GO TO GEORGE AND TELL HIM TO COME HERE
Judy says "Sure thing".
Judy walks away to the east.
> WAIT
George appears from the east.
I think that anything that can anticipate these sorts of problems is better
then something that cannot.
--
Kenneth Albanowski (kja...@kjahds.com)
FReDRiK RaMSBeRG (WILdcARD)
kja...@kjahds.com (Kenneth Albanowski) writes:
>>Something I think a lot of people (including myself) tend to forget, is that
>>we're trying to create an illusion for the player. If the player never
>>realizes that your actors are purposefully avoiding the use of information
>>they should not have aquired, why spend effort building it that way?
>I think because it's generalized, and lets you build NPC by knowledge rules
>instead of action scripts.
>Also think of it from the perspective of a player trying unusual commands.
>With proper knowledge limitations, you might need no special-purpose code
>whatsoever to do something like this:
> > LOOK
>
> This is a room, and not much more.
>
> You see Judy here.
> > JUDY, GO TO GEORGE AND TELL HIM TO COME HERE
>
> "I'm sorry, but I don't have the foggiest idea where George got to."
[snip]
>I think that anything that can anticipate these sorts of problems is better
>then something that cannot.
It's a good point. What I am saying though, is that under many circumstances
you can just let the actors know everything they need to know. As, for
instance, if you are in a crowded house, maybe you don't know where George is,
but you can ask people and you will find him. The action of asking people can
be made implicit.
From the start, my algorithm for finding paths to places used the actual
states of the doors on the way; if they were locked, the actor would not
attempt to plan a path through it. Then, however, came several things that
made it necessary to change that. For instance, a bathroom door. If it is
locked, there is a fair chance that it will be unlocked again before the
actor arrives. Also, I added the "GO TO"-command. Then, suddenly, I got the
problem that actors could respond that they don't know how to get there, based
on the state of doors they haven't seen. That wouldn't do. So, at the moment,
they are assuming all doors are unlocked, unless they are standing right at
the door and can verify that it is locked. This has the disadvantage that if
there are 3 doors into an area, two of which are locked, the actor may never
even try the third door, as she forgets about the states of all doors except
for those within reach all the time. In this game, this disadvantage probably
won't matter, and if it does I'll just have to add knowledge to the actors.
As you say, it's more complicated to build knowledge based actors, but once
it's done, you need less special code. Has anyone made successful attempts at
storing general knowledge about the state of objects into actors in Inform or
some other similar language? I know it would be easier in Lisp, but that's not
the issue right now...
Magnus Olsson
In article <5erfa4$8...@kjahds.com>,
Kenneth Albanowski <kja...@kjahds.com> wrote:
>In article <5ei4g6$6...@curofix.ida.liu.se>,
>FReDRiK RaMSBeRG (WILdcARD) <d91f...@ida.liu.se> wrote:
>>
>>we're trying to create an illusion for the player. If the player never
>>realizes that your actors are purposefully avoiding the use of information
>>they should not have aquired, why spend effort building it that way?
>
>I think because it's generalized, and lets you build NPC by knowledge rules
>instead of action scripts.
>
>Also think of it from the perspective of a player trying unusual commands.
I think Fredrik's advice is excellent, and something that should be
kept in mind at all times. To draw the argument to its extreme, when
people argue that NPC's need AI to be convinving, I like to remind
them that writers of static fiction have been creating convincing
characters for millenia, and a character in a book doesn't have a
shred of intelligence, being entirely non-interactive.
So interactivity obviously has something to do with it. It seems as if
the more the player is going to interact with some entity in our game,
the more detailed must the way it's modelled be. But the model doesn't
have to exhibit more detail than is needed to maintain the illusion.
An example with NPC's:
Suppose we have a game where you (the player) and your rival Nevada
Smith (an NPC) are searching the labyrinthine tomb of king
Quezcoatleclatl for treasure. All the treasure is hidden in the
innermost chamber.
Now, if all the author wants is a final confrontation with Smith, then
it's perfectly OK to "cheat" and just move him to the innermost
chamber; no need to have the NPC walk through the maze if the player
will never see any difference (in terms borrowed from quantum
physics, Smith's trek through the maze, while implied by the logic of
the story, is unobservable).
The same applies if you want the player to meet Smith halfway through
the maze - just move him there, and then when the encounter is
over, move him to the final chamber in time for the final
confrontation.
But what if the player's encounter with Smith can have consequences
for the final encounter? For example, if the player tells Smith
something that deludes him about the shortest way through the maze, or
if the player gets into a fight with him and hurts him so he moves
more slowly? Or what if the player removes clues on the way, hoping
that Smith will be delayed (if he isn't ahead of the player and has
already seen them)?
Up to a point, we can "cheat" by modelling this in an ad-hoc way: if
the player leaves all the clues in place, Smith will appear in the
final chamber one move after the player; for each clue tampered with,
Smith arrives one move later.
But we'll reach a point of complexity where it's actually simpler to
make a "realistic" model: an NPC that really *does* find its own way
through the maze, dealing with clues, doors and traps as it encounters
them. For example, suppose the maze has movable walls, and the player
moves them around to confuse Smith? That would be a nightmare to model
in any other way than actually giving Smith a maze-solving algorithm
and let him traverse the (dynamically changing) maze together with the
player.
But before attempting such a feat, the author must consider exactly
what he's trying to achieve. Let's not swat flies with sledgehammers!
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
Charles Gerlach
Magnus Olsson wrote:
>But the model doesn't
> have to exhibit more detail than is needed to maintain the illusion.
>
(Maze example snipped)
It was precisely in the maze of Hollywood Hijinx that my illusions
were shattered. If I remember right, I was in a spot like this:
|---| |
| |
| |
| | |
| | |_____
| |
| | ME
----------------
South side of maze
when I got the message about hearing a noise on the other side
of the hedge. Since I could see to the north and east, the noise
had to be either to the south or west (if you take them literally
that the noise was on the other side of the hedge). Since south
was outside the maze entirely, I figured the noise-maker was
in the dead-end with no escape.
Of course, he's not there at all; HH just puts in random messages
like that to freak you out and make you think there is someone
else lurking around. I know that this has been pointed out
before. Other people have heard the noise coming from a dead-end
in the house and been similarly disappointed at their inability
to catch the jerk.
I probably would have been much more frustrated if the NPC had
been written like the thief, and moved my stuff around from where
I had left it, and used the elevator in the house so that I
couldn't-- but you need to be careful with things that are
just meant to give the "feel" of something happening without
the relevant framework underneath, especially when that framework
can be tested from within the game.
--
**********************************************************************
Charles Gerlach does not speak for Northwestern, and can be mailed at:
cagerlac a t merle d o t acns d o t nwu d o t edu
He hopes that placing his e-mail in this format did not seriously
inconvenience anyone attempting to contact him (except for spam-bots).
Magnus Olsson
In article <fake-mail-ya024080...@news.direct.ca>,
Neil K. <fake...@anti-spam.address> wrote:
>In article <5fhmsv$8...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
>Olsson) wrote:
>
>> I think Fredrik's advice is excellent, and something that should be
>> kept in mind at all times. To draw the argument to its extreme, when
>> people argue that NPC's need AI to be convinving, I like to remind
>> them that writers of static fiction have been creating convincing
>> characters for millenia, and a character in a book doesn't have a
>> shred of intelligence, being entirely non-interactive.
>
>believable NPCs derives in large part *because* of the total lack of
>interactivity.
That's true, of course. And it's just that point that I made (albeit
less forcefully) in the next sentence (which you snipped).
> Same with fiction. The author writes down the words; you can't change
>them. So you can't go poking around, asking the character questions,
>because everything's there and presented before you. IF, with its carefully
>constructed illusion of choice, allows you to step behind the sets. And
>therein lies a problem.
My point is that IF has an *illusion* of choice. Unless you want to
solve an AI complete simulation problem, at some point or another you
have to stop the player from peeking behind the sets.
A tendency I've seen in some posts from beginning IF authors is that
they assume that (to continue your metaphor) if they want the town in
the movie to look real, they'll have to build real houses with
backsides, rooms inside them, gardens, and so on. That can of course
be required: if the camera will follow the hero into the saloon,
you'll have to build the inside of it. But if your script only calls
for exterior shots, a simple, two-dimensional set would be just as
effective and much cheaper.
For it's all a matter of economy. Don't get me wrong: I love detail, I
love interactivity, I love to be able to go behind the sets and see
that everything really *works*, even though it's not needed for the
story. But if the extra realism means that the game will never be
finished, because it will need five man-years of programming rather
than five man-months, then I'd prefer the cardbord illusion.
(An example in point is "Undertow" from the 1995 competition, where
the author had obviously spent a lot of time ensuring that the taps
and sinks in the bathroom worked; time that IMHO had been better spent
correcting bugs).
Neil deMause
Magnus Olsson (m...@bartlet.df.lth.se) wrote:
: A tendency I've seen in some posts from beginning IF authors is that
: they assume that (to continue your metaphor) if they want the town in
: the movie to look real, they'll have to build real houses with
: backsides, rooms inside them, gardens, and so on. That can of course
: be required: if the camera will follow the hero into the saloon,
: you'll have to build the inside of it. But if your script only calls
: for exterior shots, a simple, two-dimensional set would be just as
: effective and much cheaper.
: For it's all a matter of economy. Don't get me wrong: I love detail, I
: love interactivity, I love to be able to go behind the sets and see
: that everything really *works*, even though it's not needed for the
: story. But if the extra realism means that the game will never be
: finished, because it will need five man-years of programming rather
: than five man-months, then I'd prefer the cardbord illusion.
To carry the point still further: Trying to create a more "complete"
reality can work against creating a fuller-seeming reality. Which seems
more real, a hotel with 500 rooms, all identical, or one with a
lushly-detailed lobby and a counterperson who won't let you in the
elevator? Which seems more real, an NPC who has detailed responses to 20
items you can ask him/her about but "looks confused" the rest of the
time, or one who nods vacantly and stares off into space no matter you ask?
I was terrified of writing NPCs for almost two years because I thought it
would require massive amounts of tricky coding. Now I'm convinced that
all it takes is somewhat-massive amounts of good writing -- characters in
I-F, as in static fiction, come to life because of what they say and do,
not (necessarily) how they respond to your every whim.
The trick to interactive fiction, really, is making the lack of
interaction feel natural.
Neil
Adam West
Neil deMause, in a fit of unadulterated brilliance, wrote:
>
> The trick to interactive fiction, really, is making the lack of
> interaction feel natural.
Neil, these are perhaps the best words I've read concerning NPCs. I agree
completely. There is alot of this "make a real world" going around --- akin
to some sort of drug addiction. Everyone complains about the results (how many
times I've heard the lament "games today are all glitz and no depth"!), but
ironically everybody still thinks its the best method.
Adam
Thomas Nilsson
Neil deMause wrote:
>
> The trick to interactive fiction, really, is making the lack of
> interaction feel natural.
>
> Neil
One of the most elegant and compact 'says it all's that I have ever
seen! It will be copied into my quote book.
Thomas
--
"Little languages go a long way..."
(ThoNi of ThoNi&GorFo Adventure Factories in 1985)
-------------------------------------------------------------------------------
Thomas Nilsson Phone Int.: (+46) 13 651 12
Junovägen 12 Phone Nat.: 013 - 651 12
S-590 74 LJUNGSBRO Email: th...@softlab.se
SWEDEN alan-r...@softlab.se for info
-------------------------------------------------------------------------------
Bill Hoggett
Thomas Nilsson <th...@softlab.se> wrote:
>Neil deMause wrote:
>>
>> The trick to interactive fiction, really, is making the lack of
>> interaction feel natural.
>>
>> Neil
>One of the most elegant and compact 'says it all's that I have ever
>seen! It will be copied into my quote book.
If there's any justice on this flea-bitten world, Neil will make it
onto Cardinal's sig with this one!
---
Bill Hoggett (aka BeeJay) <hog...@airtime.co.uk>
IF GOD IS LIFE'S SERVICE PROVIDER WHY HAVEN'T I GOT HIS I.P. NUMBER ?
Trevor Barrie
Charles Gerlach <gerl...@nospam.address> wrote:
>|---| |
>| |
>| |
>| | |
>| | |_____
>| |
>| | ME
>----------------
>South side of maze
>
>when I got the message about hearing a noise on the other side
>of the hedge. Since I could see to the north and east, the noise
>had to be either to the south or west (if you take them literally
>that the noise was on the other side of the hedge).
Or northeast, no?