Hint topics

7 views
Skip to first unread message

David Fisher

unread,
Jan 9, 2006, 5:23:40 PM1/9/06
to
One problem with providing a list of hint topics is that sometimes the
topics themselves give away information; for example, "How do I get the key
from the Vermicious Knudle?" lets that player know the Knudle* has a key.

I was wondering if anyone has tried allowing hint topics to be entered
directly by the player instead of being displayed on the screen - in a
similar way to using "ask X about Y" instead of displaying a conversation
menu?

It might look something like this:


Lair of the Knudle

The Vermicious Knudle lies sleeping on a mound of
gold and jewels, its single claw grasping a small
shiny object.

> x shiny
It appears to be a key.

> get shiny
That would wake up the Knudle!

> hint
Entering Hint mode.

hint topic> get key from Knudle
You can't take the key by force.

hint topic> again
You need to make the Knudle let go of the key without waking it up.

hint topic> { player presses enter }

>


There are lots of potential problems (phrasing complicated questions,
disambiguating questions without giving things away, etc). But I was just
wondering if anything like this has been done before.

David Fisher

---

* Vermicious Knudle: Distant relative of the Vermicious Knid.


Risujin

unread,
Jan 9, 2006, 5:55:56 PM1/9/06
to
David Fisher wrote:
> I was wondering if anyone has tried allowing hint topics to be entered
> directly by the player instead of being displayed on the screen - in a
> similar way to using "ask X about Y" instead of displaying a conversation
> menu?

I think there are games where you can use NPCs this way. If you ask
about something enough times they give you progressive hints. I think
its a pretty good idea.

-- Risujin

David Fisher

unread,
Jan 9, 2006, 8:13:31 PM1/9/06
to
"Risujin" <ris...@fastmail.fm> wrote in message
news:0SBwf.26607$Dk....@tornado.rdc-kc.rr.com...

Talking to NPCs is a great start, but you are generally limited to single
word topics ("ask Fred about Jabberwocky") ...

I am mainly thinking about something that approaches entering a question
like "How do you tune the piano?" or "Can you get past the dogs without
feeding them your lunch?" - only not quite as ambitious as that (natural
language parsing).

Just wondering,

David Fisher


BrettW

unread,
Jan 10, 2006, 2:48:51 AM1/10/06
to
I think this hint approach is interesting but problematic. It's
problematic because it turns getting hints into a "guess the verb/noun"
problem. You'd require an extensive vocabulary for simple problems; to get
past a guard you'd have to catch "get past guard", "avoid guard", "get
through door", "solve guard puzzle", "circumvent Charlie the Guard", "get
into vault", "sneak past guard"... And if you have disambiguation, you may
run into the problems you were trying to avoid.

I've found the TADS 3 way to be pretty good: the hints are presented as a
menu, but each menu item only appears if it satisfies some condition.
There are in-built methods for opening/closing menu items for conditions
like "Player has seen [blah]", "Player knows [blah]", "[blah] has been
described to Player"... You can also add in custom conditions easily.

These combine in a nice way so that you can have a hint menu that unfolds
as hints are produced. The topics can be made ambiguous and only specific
when the player has the required information or the game world is in an
appropriate state. For example, assume the player doesn't know about the
key in the example you gave:

Hint menu:
* What is the go with the Knudle?

[selects this hint]

- The Knudle might have something on it. [1/2]
- The Knudle has a shiny object. [2/2]

Then you could have a new hint appear:

* What is the shiny thing the Knudle has?

Then if you read that hint, or actually examine the key, that hides the
previous hint and produces a new one:

* How do I get the key from the Knudle?

Examples of this sort of stuff can be found in "Return to Ditch Day", any
of Eric Eve's TADS 3 games, and (to a lesser extent) my own "Mix Tape".

I prefer this method, although it requires some elaborate work from the
author. It does break the flow of the game a little (but then again,
shouldn't all hints?) Any gentler hints can be given via NPCs.

BrettW

Mike Arnaud

unread,
Jan 10, 2006, 7:46:06 AM1/10/06
to
Or the hints could be conditioned on what the player has or knows.

[generic]

"hint"
if key is seen then "how do i get the key"
else "no hints for you right now"

-- Mike Arnaud

Risujin

unread,
Jan 10, 2006, 8:46:54 AM1/10/06
to
David Fisher wrote:
> "Risujin" <ris...@fastmail.fm> wrote in message
> news:0SBwf.26607$Dk....@tornado.rdc-kc.rr.com...
>
>>David Fisher wrote:
>>
>>>I was wondering if anyone has tried allowing hint topics to be entered
>>>directly by the player instead of being displayed on the screen - in a
>>>similar way to using "ask X about Y" instead of displaying a conversation
>>>menu?
>>
>>I think there are games where you can use NPCs this way. If you ask about
>>something enough times they give you progressive hints. I think its a
>>pretty good idea.
>
> Talking to NPCs is a great start, but you are generally limited to single
> word topics ("ask Fred about Jabberwocky") ...

"ask Fred about tuning the piano"?

I've seen this done, I guess you define "tuning the piano" as one token.
You would have to do this for every variation though ... "piano tuning",
"tuning piano", "how to tune piano" etc ...

-- Risujin

Dan Shiovitz

unread,
Jan 10, 2006, 4:49:17 PM1/10/06
to
In article <43c2e262$1...@duster.adelaide.on.net>,

David Fisher <da...@hsa.com.au> wrote:
>One problem with providing a list of hint topics is that sometimes the
>topics themselves give away information; for example, "How do I get the key
>from the Vermicious Knudle?" lets that player know the Knudle* has a key.

This reminds me of something somewhat related I've been thinking about
lately. It seems to me that most hint systems that have been done in
games so far are based around the wrong question. Specifically,
they're attempts to answer "How does the player solve the puzzle?",
which is admittedly important, but it doesn't get to the heart of the
matter.

I think the *real* question ought to be "Why hasn't the player solved
the puzzle?". "Because they didn't put the ruby on the pedestal" is
one answer, sure, but it's equally possible that they haven't solved
it because they aren't carrying the ruby, haven't seen the pedestal,
or don't know why they should be putting the ruby on the pedestal in
the first place (which in turn might be because they don't know what
their larger objective is, or because they don't realize that putting
the ruby on the pedestal will help with it).

So I think a useful help system would be one that says "ok, what are
you trying to accomplish in the big picture?" and then directs the
player towards getting the tools and the knowledge to accomplish it.

Having typed that, I then spent ten minutes or so trying to come up
with a decent example with the Knudle and not doing too well. I guess
the deal is that the player tends to get goals in a top-down way, but
encounters things to do in a bottom-up way. Still, I think the overall
point is valid: in most games, the player shouldn't be messing with
the Knudle until they know it has a key and want to get it, and the
hint system should be directing them appropriately.

For some games, where the puzzles are the entire goal, it makes more
sense for the player to want to wander around and poke at
stuff. There, I guess the hint system ought to be directing them to
ways of interacting with the Knudle ("Have you tried wearing different
outfits around the Knudle?" "Have you noticed how the Knudle reacts to
unusual smells?" "Have you tried looking up books on Knudlology at the
library?") to start, rather than jumping straight in and exposing the
key goal.

>David Fisher
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW

David Fisher

unread,
Jan 11, 2006, 1:23:20 AM1/11/06
to
"Dan Shiovitz" <d...@cs.wisc.edu> wrote in message
news:dq1a4t$4dn$1...@cascadia.drizzle.com...

> It seems to me that most hint systems that have been done in
> games so far are based around the wrong question. Specifically,
> they're attempts to answer "How does the player solve the puzzle?",
> which is admittedly important, but it doesn't get to the heart of the
> matter.
>
> I think the *real* question ought to be "Why hasn't the player solved
> the puzzle?". "Because they didn't put the ruby on the pedestal" is
> one answer, sure, but it's equally possible that they haven't solved
> it because they aren't carrying the ruby, haven't seen the pedestal,
> or don't know why they should be putting the ruby on the pedestal in
> the first place (which in turn might be because they don't know what
> their larger objective is, or because they don't realize that putting
> the ruby on the pedestal will help with it).
>
> So I think a useful help system would be one that says "ok, what are
> you trying to accomplish in the big picture?" and then directs the
> player towards getting the tools and the knowledge to accomplish it.

Hmm ... this reminds me of the idea in (non-IF) programming where you design
and write unit tests at the same time as writing the rest of the code -
which has the interesting side effect of forcing you to think about what
exactly you want the program to be doing (in much more detail than the high
level requirements). More potential bugs are excluded because of the fact
that you were forced to look at the details than because of the tests
themselves.

Writing hints for an IF game at the same time as the rest of the code would
have a similar side effect - to make you ask questions like, "How does this
puzzle fit in with the player's overall goal at this point ?" and "Why
should the player do that action ?" If there isn't a reasonable answer, then
the something needs fixing.

Disclaimer: Not that I've actually tried out this idea ...

David Fisher


David Fisher

unread,
Jan 11, 2006, 1:32:12 AM1/11/06
to
"BrettW" <shor...@hotmail.com> wrote in message
news:op.s25jzphny51jdq@ninja...

> I've found the TADS 3 way to be pretty good: the hints are presented as a
> menu, but each menu item only appears if it satisfies some condition.
> There are in-built methods for opening/closing menu items for conditions
> like "Player has seen [blah]", "Player knows [blah]", "[blah] has been
> described to Player"... You can also add in custom conditions easily.
>
> These combine in a nice way so that you can have a hint menu that unfolds
> as hints are produced. The topics can be made ambiguous and only specific
> when the player has the required information or the game world is in an
> appropriate state.

Sounds very good ...

> I prefer this method, although it requires some elaborate work from the
> author. It does break the flow of the game a little (but then again,
> shouldn't all hints?) Any gentler hints can be given via NPCs.

Any thoughts on unrequested hints (given by the game when the player seems
to be floundering) ?

Thanks for the info,

David Fisher


BrettW

unread,
Jan 11, 2006, 6:34:51 AM1/11/06
to
> Any thoughts on unrequested hints (given by the game when the player
> seems
> to be floundering) ?

I'm figuring it'd be specific from game to game. Some people class
suggestive object/room descriptions as hints, or random mutterings by
NPCs. But if your IF is, say, the PC wandering around a deserted, sterile
space ship, it might be a bit harder.

As for things along the lines of:
====================================
[in the midst of play]
You seem to be stuck. Would you like a hint on how to open the door?
====================================
I dunno. Some players might be annoyed, others delighted. It'd be hard to
do and incorporate all the playing styles. For example, an overly cautious
player might explore all the rooms before they manipulate anything. The
game could easily be fooled into thinking that you've seen a locked door
and given up straight away.

Also, a player may prioritize puzzles differently to the game and might be
annoyed that the game is smart enough to suggest hints for Puzzle A, when
they're really looking for hints for Puzzle B. What might be at the
forefront of a player's mind might not be obvious from a transcript of a
game (which, after all, is all the game can use, in a sense). Requested
hints follow the player's mind because they direct it.

> Thanks for the info,
>
> David Fisher

My pleasure,

BrettW

Quintin Stone

unread,
Jan 11, 2006, 9:13:34 AM1/11/06
to
On Wed, 11 Jan 2006, David Fisher wrote:

> Writing hints for an IF game at the same time as the rest of the code
> would have a similar side effect - to make you ask questions like, "How
> does this puzzle fit in with the player's overall goal at this point ?"
> and "Why should the player do that action ?" If there isn't a reasonable
> answer, then the something needs fixing.
>
> Disclaimer: Not that I've actually tried out this idea ...

It seems to me that those two questions should really be a fundamental
part of the design process of the game before you even start coding it.
If you're only asking them when you get around to writing hints, that's
how you'd know something needs fixing.

==--- --=--=-- ---==
Quintin Stone "You speak of necessary evil? One of those necessities
st...@rps.net is that if innocents must suffer, the guilty must suffer
www.rps.net more." - Mackenzie Calhoun, "Once Burned" by Peter David

Reply all
Reply to author
Forward
0 new messages