Automatic walkthroughs
David Fisher
game ...
Usually walkthroughs are included as a separate file, or as a "text dump"
you can access via a special command in the game. An alternative would be a
way to step through the walkthrough in-game (by pressing Enter repeatedly or
something) - for example:
> walkthrough
(entering walkthrough mode)
>> [player presses Enter]
(get on table)
You get up on the table.
>> [player presses Enter]
(get lamp with stick)
Using the stick, you just manage to reach the lamp, and delicately lift it
off the hook.
>> look
(exiting walkthrough mode)
You are in a small round room with exits in all directions. There is a
table in the
middle of the room. You are currently standing on the table.
>
The idea is that when you are in "walkthrough" mode, there is a double
prompt (>>), and entering a blank line prints the next command in brackets
and executes it. Entering something other than a blank line returns to
normal (non-walkthrough) mode.
Ignoring the difficulties of working out the next command for the
walkthrough (which may require working out which goals the player hasn't met
yet), how does this sound as a user interface ?
David Fisher
Mike Snyder
news:43fb918c$1...@duster.adelaide.on.net...
> Just wanted to ask for feedback on something I am planning to include in a
> game ...
>
> prompt (>>), and entering a blank line prints the next command in brackets
> and executes it. Entering something other than a blank line returns to
> normal (non-walkthrough) mode.
>
> Ignoring the difficulties of working out the next command for the
> walkthrough (which may require working out which goals the player hasn't
> met yet), how does this sound as a user interface ?
It sounds interesting, but I wonder if it would be worth the work involved?
It seems possible for a very linear game (especially a short one), but my
mind boggles at how you'd accomplish this with a more non-linear path or in
a longer game.
Think about this:
The player has gone to the "big blue room" to look around. Player feels
stuck. Player needs the walkthrough. The game believes the player should
next tackle a problem in the "small red room". At this point, the game has
to realize what combination of N/S/E/W is necessary just to return the
player to the point where the walkthrough can resume solving the puzzle.
This is difficult enough in a terse walkthrough, where it's up to the player
to skim along and figure out how to put the game in a state that makes a
walkthrough meaninful in mid-game. To convince the game itself to do
this.... yeah, it boggles my mind. :) It was hard enough just getting the
built-in hints in my last game to make a good guess at what the player
needed to know about next.
I suppose you'd need pathfinding, for the situation above (including any
related actions along the way, such as opening doors or pushing obstacles
out of the way). Or, you'd need to have the game enter walkthrough-sensitive
areas, where the player is attempting certain linear tasks that wouldn't
need to carry through the entire game. I dunno. It's an interesting topic,
but one I personally wouldn't tackle.
---- Mike.
Mike Snyder
news:QAMKf.167865$WH.12089@dukeread01...
> "David Fisher" <da...@hsa.com.au> wrote in message
> news:43fb918c$1...@duster.adelaide.on.net...
>> Just wanted to ask for feedback on something I am planning to include in
>> a game ...
Oh -- and to me it sounds fine as a user interface -- in theory. It's simply
the logistics of making it work that I get stuck on.
--- Mike.
David Fisher
> news:43fb918c$1...@duster.adelaide.on.net...
>>
>> prompt (>>), and entering a blank line prints the next command in
>> brackets and executes it. Entering something other than a blank line
>> returns to normal (non-walkthrough) mode.
>>
>> Ignoring the difficulties of working out the next command for the
>> walkthrough (which may require working out which goals the player hasn't
>> met yet), how does this sound as a user interface ?
>
> It sounds interesting, but I wonder if it would be worth the work
> involved? It seems possible for a very linear game (especially a short
> one), but my mind boggles at how you'd accomplish this with a more
> non-linear path or in a longer game.
>
> I suppose you'd need pathfinding, for the situation above (including any
> related actions along the way, such as opening doors or pushing obstacles
> out of the way). Or, you'd need to have the game enter
> walkthrough-sensitive areas, where the player is attempting certain linear
> tasks that wouldn't need to carry through the entire game. I dunno. It's
> an interesting topic, but one I personally wouldn't tackle.
I agree it's *really* hard in the general case, but it's not such a problem
for the situation I am planning to use it for ... mainly I was wondering
about the interface (and if there are any interesting alternative
interfaces).
BTW, there was a post in July 2006 about a system called (P)NFG that could
analyse preconditions, find the shortest path to a goal, check for
unwinnable states, etc:
http://groups.google.com/group/rec.arts.int-fiction/browse_frm/thread/86fb97f43b4abccb
I don't know how it's going now, but it sounds like an ideal system for this
kind of thing (if it became a fully functional, general IF language) ...
David Fisher
Andrew Plotkin
I had to do much of this work already to make the dynamic help in
_Dreamhold_. That had fairly simple goals, but I did have to track
them all, worry about what the player had or had not seen, etc. So
it's a lot of work, but not out of the range of other detailed help
mechanisms.
The only piece missing (from what I did in _Dreamhold_) is a way for
the game to route the player from one room to another. This is a
well-understood task -- there are libraries in Inform, I think it's
built into TADS-3 :), etc.
I agree that it would be a workable interface. I'm somewhat worried
that it's too easy -- the player might start pounding Enter, and
accidentally go past the point where he unsticks himself and is
capable of playing the game himself.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
It used to be that "conservatives" were in favor of smaller government,
fiscal responsibility, and tighter constraints on the Man's ability to
monitor you, arrest you, and control your life.
rpresser
David Fisher wrote:
> BTW, there was a post in July 2006 about a system called (P)NFG that could
> analyse preconditions, find the shortest path to a goal, check for
> unwinnable states, etc:
Now, I realize this was just a typo and you meant July 2005 ... but
there's something oddly appropriate about an all-knowing IF system
being talked about in the future. :-)
David Fisher
"rpresser" <rpre...@gmail.com> wrote in message
news:1140564627.7...@f14g2000cwb.googlegroups.com...
Aaargh ! My cover is blown !
Maybe people will pay more attention now when I talk about "the future of
IF" ...
:-)
David Fisher
David Fisher
news:dtg66j$cct$1...@reader2.panix.com...
>>> "David Fisher" <da...@hsa.com.au> wrote in message
>>> news:43fb918c$1...@duster.adelaide.on.net...
>>>> Just wanted to ask for feedback on something I am planning to include
>>>> in
>>>> a game ...
>>>> The idea is that when you are in "walkthrough" mode, there is a double
>>>> prompt (>>), and entering a blank line prints the next command in
>>>> brackets
>>>> and executes it. Entering something other than a blank line returns to
>>>> normal (non-walkthrough) mode.
> I agree that it would be a workable interface. I'm somewhat worried
> that it's too easy -- the player might start pounding Enter, and
> accidentally go past the point where he unsticks himself and is
> capable of playing the game himself.
Hmmm ...
Maybe it could stop after each goal is reached and automatically revert to
non-walkthrough mode, so you need to say "walkthrough" (or "g") again to
proceed to the next goal.
Or, to be more like a traditional walkthrough, it could just tell you the
next command - but you still have to type it. But I don't like that idea
very much (too similar to parser messages telling you what to type instead
of just doing what it knows you want to do, eg. "To climb the rope, just say
'up'").
David Fisher
steve....@gmail.com
> I had to do much of this work already to make the dynamic help in
> _Dreamhold_. That had fairly simple goals, but I did have to track
> them all, worry about what the player had or had not seen, etc. So
> it's a lot of work, but not out of the range of other detailed help
> mechanisms.
Could you describe the technique for me please? For instance, did you
set up a tree of goals over which a search is performed to find the
next goal (and which was updated when a goal was achieved)? Or did you
do a sort-of pencil-and-paper search yourself, and set up a (more
"static") tree of hints, branches of which turn on or off as goals are
fulfilled?
doc...@chaiyo.com
> and entering a blank line prints the next command in brackets
>and executes it. Entering something other than a blank line returns to
>normal (non-walkthrough) mode.
The idea is certainly interesting. Walkthroughs are helpful for
beginning IF players. And such a mechanism would help them stick
around for the end game.
I like the double prompt indicating walkthrough mode.
But I think pressing ENTER is too easy. The player should at least try
something. Lazy people will just press ENTER forever and ever. I
think it would be better to default to a hint system before defaulting
to a walkthrough. Or you should have to type something like
"walkthrough" (although I have always shortened it phonetically to
"walkthru" personally).
One of the things I like about IF is that it's perfectly suited for an
old CPU that is running MS-DOS - or linux without the X server. If you
add the code necessary to figure out walkthrough steps, then I think
your file size is going to increase dramatically. I like having more
than 600 Z5 files on a 200 MB hard drive. So I guess my question is
this: How much overhead are we adding to the original file size? That
would be a factor for me.
Another thing: I was playing Zork 3 last night and got all the way to
the end where I knock on the dungeon master's door. The walkthru says
he should invite me in, then I'm only a few steps from winning the
game, but my experience last night was that he wags his finger and I'm
teleported back to the Beam Room. I racked my brain over this. And in
re-reading the whole walkthru, I think my error was in not getting the
hood and cloak from the shadowy figure at the very beginning of my
game. While I haven't tested my theory by restarting the game, lets
just assume this is true.
How would your walkthru system handle the necessary items missing
from my inventory? It knows that I'm missing something it requires at
this point. But I don't know that yet, because I have gotten this far
without it.
Andrew Plotkin
> So I guess my question is
> this: How much overhead are we adding to the original file size? That
> would be a factor for me.
Some. I don't think it would double in size. You're adding a lot of
code, but little text.
At worst, you have to upgrade to a *seven*-year-old computer with a
*four* hundred megabyte hard drive. :)
> Another thing: I was playing Zork 3 last night and got all the way to
> the end where I knock on the dungeon master's door. The walkthru says
> he should invite me in, then I'm only a few steps from winning the
> game, but my experience last night was that he wags his finger and I'm
> teleported back to the Beam Room. I racked my brain over this. And in
> re-reading the whole walkthru, I think my error was in not getting the
> hood and cloak from the shadowy figure at the very beginning of my
> game.
If the game can be put into an unwinnable state, the walkthrough
interface will be able to detect this (since it's checking goal
requirements all the time anyway). You'd have to decide how it should
react. Presumably it would just print "You lose, chump". Since
that's not very satisfying, I'd say it's better to use this mechanism
on games that can't be made unwinnable.
> How would your walkthru system handle the necessary items missing
> from my inventory? It knows that I'm missing something it requires at
> this point. But I don't know that yet, because I have gotten this far
> without it.
Easy: walk the player to the place where he missed something, and then
walk him through discovering it.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're an American.
Andrew Plotkin
tree of "if" statements. No technique to speak of.
_Shade_ has a more modular system for defining trees of goals. You can
look at the code for that. The "search" is still all precomputed -- I
think it tracks a list of things that are available to do, updating
the list whenever the player completes a goal.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Neil Cerutti
>>when you are in "walkthrough" mode, there is a double prompt (>>),
>> and entering a blank line prints the next command in brackets
>>and executes it. Entering something other than a blank line returns to
>>normal (non-walkthrough) mode.
>>...... how does this sound as a user interface ?
>
> The idea is certainly interesting. Walkthroughs are helpful for
> beginning IF players. And such a mechanism would help them stick
> around for the end game.
> I like the double prompt indicating walkthrough mode.
> But I think pressing ENTER is too easy. The player should at least try
> something. Lazy people will just press ENTER forever and ever. I
> think it would be better to default to a hint system before defaulting
> to a walkthrough. Or you should have to type something like
> "walkthrough" (although I have always shortened it phonetically to
> "walkthru" personally).
>
> One of the things I like about IF is that it's perfectly suited for an
> old CPU that is running MS-DOS - or linux without the X server. If you
> add the code necessary to figure out walkthrough steps, then I think
> your file size is going to increase dramatically. I like having more
> than 600 Z5 files on a 200 MB hard drive. So I guess my question is
> this: How much overhead are we adding to the original file size? That
> would be a factor for me.
A general, reusable system for computing and executing dynamic
walkthroughs might be big and slow. But a game-specific system could
be small and fast.
I did a puzzle-analysis some years ago of _John's Fire Witch_, and
that sort of directed graph is easy to represent without much bloat.
Computing it is hard, but I'm imagining that the author will be forced
to do that.
> Another thing: I was playing Zork 3 last night and got all the way to
> the end where I knock on the dungeon master's door. The walkthru says
> he should invite me in, then I'm only a few steps from winning the
> game, but my experience last night was that he wags his finger and I'm
> teleported back to the Beam Room. I racked my brain over this. And in
> re-reading the whole walkthru, I think my error was in not getting the
> hood and cloak from the shadowy figure at the very beginning of my
> game. While I haven't tested my theory by restarting the game, lets
> just assume this is true.
>
> How would your walkthru system handle the necessary items missing
> from my inventory? It knows that I'm missing something it requires at
> this point. But I don't know that yet, because I have gotten this far
> without it.
There would be a data-structure reflecting every puzzle that must be
solved, and how those puzzles depend on each other, i.e., how they
relate. The data structure would be tree-like. In Inform, you could
use the object tree, with children representing dependencies.
Searching the data-structure for unsolved puzzles, the system would
select one (the first unsolved puzzle it hits might be an OK choice,
depending on how user-friendly you want to be). If it selects the
Dungeon Master's door, it would look up that puzzle, and see that it
depended on the "get the cloak" puzzle. It would continue checking
dependencies until it finds an unsolved puzzle that has no missing
dependencies, and finally launch that command.
At least in theory.
--
Neil Cerutti
The church will host an evening of fine dining, superb
entertainment, and gracious hostility. --Church Bulletin
Blooper
doc...@chaiyo.com
>>How would your walkthru system handle the necessary items missing
>Easy: walk the player to the place where he missed something, and then
>walk him through discovering it.
That actually makes sense. And I like it.
But in the case of my Zork 3 game, I already killed the shadowy figure
who had the hood and cloak. He vanished forever. I don't think the
game presents another shadowy figure if you go back to the Shadow
Lands. So this makes the game unwinnable I suppose.
I agree that it's better to use this walkthru mechanism on games
that can't be made unwinnable. Probably one of the biggest IF
turn-offs for newbies is when they get frustrated with the text parser.
So a walkthru mode could help alleviate some of that frustration, thus
giving the game more staying power.
Oooh it just occurred to me. On text adventures that keep a
score (like the Zork and Enchanter trilogies), you could lose points
for doing certain actions. Perhaps using the walkthru mode should
decrement your score some.
Chris Pickett
> BTW, there was a post in July 2006 about a system called (P)NFG that could
> analyse preconditions, find the shortest path to a goal, check for
> unwinnable states, etc:
>
> http://groups.google.com/group/rec.arts.int-fiction/browse_frm/thread/86fb97f43b4abccb
>
> I don't know how it's going now, but it sounds like an ideal system for this
> kind of thing (if it became a fully functional, general IF language) ...
That was me. There have been small fixes, but there's nothing major
improved. Basically I need to find better ways to generate the input
model of the Petri net for the NuSMV model checker. I do have some
ideas about this, I'm just sort of preoccupied at the moment with other
things. The changes that have gone in since I made that post have
affected the higher level language and optimisations to the code
generation methods used by the compiler. I didn't do them, and I
haven't really looked at them.
So, for small things, our PNFG stuff works well. If you have a fairly
complicated puzzle and you want to check reachability, it could be
useful. If you want somewhere to start that lets you add LTL/CTL
specifications to (small) IF games, it could also be useful.
However, I think for a larger game, it is better to use a tool like
ifm-5.1 and a hand-done walkthrough approach. I bet IFM could be
adapted pretty well to suit your needs.
http://www.sentex.net/~dchapes/ifm/
http://www.ifarchive.org/indexes/if-archiveXmapping-tools.html
Cheers,
Chris
Kevin Venzke
<doc...@chaiyo.com> wrote in message
news:1140627899....@z14g2000cwz.googlegroups.com...
> But in the case of my Zork 3 game, I already killed the shadowy figure
> who had the hood and cloak. He vanished forever. I don't think the
> game presents another shadowy figure if you go back to the Shadow
> Lands. So this makes the game unwinnable I suppose.
I love Zork 3. What a cool game. I don't understand the endgame
contraption, though...
Samwyse
>>How would your walkthru system handle the necessary items missing
>>from my inventory? It knows that I'm missing something it requires at
>>this point. But I don't know that yet, because I have gotten this far
>>without it.
> Searching the data-structure for unsolved puzzles, the system would
> select one (the first unsolved puzzle it hits might be an OK choice,
> depending on how user-friendly you want to be). If it selects the
> Dungeon Master's door, it would look up that puzzle, and see that it
> depended on the "get the cloak" puzzle. It would continue checking
> dependencies until it finds an unsolved puzzle that has no missing
> dependencies, and finally launch that command.
Oh, boy, twice in one day I get to mention Glenn Hutchings' IFM
(Interactive Fiction Mapper)(available in the archive). Below is a bit
of a description of the DM4 sample game, "Ruins". The 'finish' flag
indicates the final goal, to accomplish it requires four prerequisite
goals, and they each require a single object. Some of the information
isn't needed in this example, but if you need, say, the ruby to solve a
different puzzle, the fact that you lose it in task 3 would help
determine an ordering to the solutions.
I'm ever-so-slowly working on a way to translate IFM descriptions into
Inform code for a game; adding a walk-through piece could be an
interesting add-on. Of course, at my present rate don't expect to see
anything before 2010.
# The game is won by putting all the treasures in the case
task "Put statuette in case"
tag pack_statue
need statue
lose it
score 10;
task "Put bangle in case"
tag pack_bangle
need bangle
lose it
score 20;
task "Put ruby in case"
tag pack_ruby
need ruby
lose it
score 30;
task "Put wax in case"
tag pack_wax
need wax
lose it
score 40;
# After all the treasures are stashed, the game is over.
task "Wait for helicopter"
after pack_statue pack_bangle pack_ruby pack_wax
cmd "wait" 2
finish;
Blank
problems would give the player "hint points" that they could spend
later? Almost the same mechanics but presented as a positive rather than
a negative.