Hints
<P>
 For any game with at least one puzzle in it (and some with none!), at least one 
player will need hints to get through it.  Even the perfect game, communicating directly 
and clearly with its players will find one player who, for whatever reason,  doesn't get it.  
Maybe they are stuck thinking along a different logical track.  Maybe they misread a line, 
or missed an exit.  Maybe they don't know English well enough to correctly phrase their 
input.  If the player is to continue and see the complete work, they will need a hint.  And 
that's where you, the hint-writer, come in.
<p>
 You have not set yourself up for a simple task.  If you are the author, two forces 
work against you.  For one, you are often so close to the work that it can be hard to adopt 
the outside perspective needed to see where your prospective player is coming from.  
You know the streets, alleys, and footpaths of your neighborhood, but haven't a clue 
what freeway they should take.  For another, the hint-writing process must, by necessity, 
come at the end stages of game development, but require the same amount of energy and 
creativity as the initial design.  It can be hard to maintain that level of output for so long--
fixing bugs is about as creative a task as one can manage.
<p>
 The outside hint writer also faces a challenge opposite of the author's:  you don't 
have an intimate knowledge of the game's ins and outs.  In fact, you often start with no 
map at all, but merely the directions you followed to get to where you ended up.  In some 
cases, you might not even be sure if where you ended up was where the author intended 
you to finish.  To someone who did things differently or wants a different ending, your 
hints might not be able to steer them in the right direction.
<p>
 The solution to this initial hurdle, whichever side you started on, is the same:  
seek outside advice.  A single set of hints must apply to a wide variety of people; it must 
have a wide variety of inputs if it is to serve.  The author has a natural group in their beta-
testers--pay close attention to their reports to find out where they were stuck, and what 
path they found to get them moving again.  Painstakingly go over their transcripts to find 
even moments of temporary confusion--all could be places where another could get 
stuck.
<p>
 Once you have completed your research and know the potential trouble spots, you 
must work to make your hints complete, adaptable, and inspiring.  Complete in that they 
must both provide answers to each potential trouble spot as well as fully answer that 
problem.  Adaptable in that they must meet the player at the level at which they are stuck-
-on the one hand they must not simply rehash what is already known, but on the other, 
they must not jump straight to the solution and 'spoil' the puzzle.  Inspiring in that they 
must prompt the player to return to playing the game and attempt the new solution you 
did not tell them, but which you made them think of.  This last is by far your hardest task, 
and we shall explore artificial ways to accomplish it to supplement the inspiration you 
can muster on your own.
<p>
 The most common (and, to my mind, most effective) method of accomplishing 
these goals is to follow the 'invisiclue' format.  Invisiclues were hint booklets published 
by Infocom containing readable lists of hint topics, each followed by a list of 
progressively more explicit hints, all printed in an invisible ink that would appear only 
when you drew on it with the enclosed orangeish pen.  Players would look up the 
problem on which they were stuck, then reveal the hints one at a time until they solved 
the puzzle, ran out of clues, or lost the pen.  Though the invisible ink technology is sadly 
not used much today, the invisiclue format of readable topics followed by hidden clues is 
widely used in a variety of implementations, from web pages to encoded files to a hint 
menu within the game itself.  A survey of the available options and variations on this 
format is included at the end of this article, following an in-depth study of how to go 
about actually writing the hints themselves.
<P>
Complete<br>
 Being complete in your hints is probably the most crucial task you face.  Nothing 
can be more frustrating to a game player reading hints and still being unable to progress 
in the game.  As the author, this might be harder than you imagine--bits you put in that 
you did not intend as a puzzle may be unclear or simply missed.  Whether you are the 
author or not, a good method might be to compile a walkthrough of the game first, and 
note any commands that are not directions, 'examine' or 'get' as potential places where 
people might need a hint.  Even these are not always safe--in many games it seems I get 
stuck at least once when I have failed to notice an exit.  Depending on the format of your 
hints, you might consider including maps of each section, noting the 'obvious' places one 
can get.
<p>
 Based on your walkthrough and list of puzzles and trouble spots, compile the list 
of hint topics you want the player to see.  Make this list as tangible as possible, and try to 
formulate it as a question the player might pose having seen the puzzle, but not know 
anything about the solution.  That means that if a diamond is hidden in a locked box, 
"Opening the locked box" or even just "The locked box" would be a suitable topic, while 
"Finding the diamond" would not.  Even if the player knows they need a diamond for 
some other puzzle, they don't know (unless the box is transparent) that it rests inside.  
Likewise, you don't want to give away anything in the topic.  "Finding the key for the 
locked box" tells the player more than they know when they encounter the box for the 
first time.
<p>
 Sometimes, there's just no way to word a topic without that itself being some kind 
of a spoiler.  ("Aha! One of the questions is 'How do I get into the house?, so there must 
be some way of doing that!") The accepted method of dealing with this is to put bogus 
questions on the list as well as real ones. (How do I get on top of the house?, How do I 
revive the skeleton?) Infocom did this a lot, in their Invisiclues.  Don't go overboard, 
though--too many false hints will leave the player wading through them, not realizing 
when  they've hit a real one.
<p>
 Once compiled, you will often find that the topics can naturally be grouped 
together somewhere, often by geography ('The Forest'), sometimes by progress within 
the game ('The Prologue').  Grouping clues this way provides both a logical framework 
for looking up where one is stuck, and a way to avoid 'looking ahead' to see what sorts of 
challenges await.  Ideally, a player reading hints will only see the topics for the particular 
section of the game for which they need help.  This can be accomplished fairly easily for 
electronic hints, but if providing hints in some hard-copy format, be sure to include 
enough white space or page break between sections so that a player can if they choose 
look only at the hint topics for their particular section.
<p>
 The other side of being complete is to be sure to provide explicit instructions for 
how to get past each puzzle.  The simplest way to do this is to simply relate the 
commands the player is to type as the last hint in each topic.  So, after skating around the 
fact that the key is in the mouse hole, and after finally saying explicitly, "The key is in 
the mouse hole," say, ">REACH IN MOUSE HOLE.  You will get a silver key.  Then, 
>UNLOCK BOX WITH SILVER KEY."  The reason for being explicit is that invariably 
some player will have the right idea, but not be able to phrase it in a way that the game 
understands.  Maybe they tried, ">PUT HAND IN MOUSE HOLE" or ">FEEL MOUSE 
HOLE" or even, ">GROPE ABOUT INSIDE THE MOUSE HOLE", none of which 
worked.  They can send a bug report to the author later--for now, they need to know what 
to do to solve the puzzle.
<P>
Adaptable<br>
 Before the player needs explicit instructions, however, they need gentle nudges in 
the right direction.  And to do that, the hints need to be adaptable.  The very format of 
invisiclue-style hints caters to this need by gradually revealing more and more 
information as the player reveals each new hint.  The following checklist should help you 
give exactly the right amount of information to the player.
<P>
1.  Is the puzzle currently solvable? The player may feel that they are stuck, say, on 'How 
do I unlock the grate?', but they will actually be stuck on 'How do I enter the house?', 
inside which will be a skeleton key. The first clue given to a player should convey to the 
player whether or not the puzzle is solvable yet. As an example, let's say that there's a 
grate in the game that must be unlocked with a skeleton key.  The first hint might be:
<p>
 How Do I Open the Grate? <br>
  You'll have to get in the house first. (see How Do I Enter the House?) 
<P>
Sometimes it might be impossible to reveal this information without giving away too 
much.  If a credit card can be obtained from a broken ATM and subsequently used to 
jimmy open a shed door, then telling the player looking for a shed door clue "You must 
first solve the ATM puzzle" reveals too much.  Try to be circumspect in this situation, 
perhaps telling the player they must solve some puzzles in the bank area first.  If there's 
no way to tell the player this information without some spoilage, you can bump this 
information down the list and give the player other clues first.
<p>
 If the hints are included in the game itself, they can bypass this step by only 
providing hints for those puzzles that are currently solvable, or by stating "This puzzle 
cannot yet be solved."  Excruciating care must be taken to make sure this is actually the 
case!  In my own game 'The Edifice', the hint system acknowledged only one way to 
solve a particular puzzle, and got stuck there if the player used a slightly different 
method.  Carefully check this code to not make the same mistake I did, and provide 'outs' 
for the hints to continue in case it happens anyway (checking to see if a door is open, for 
example, rather than noting when the player types 'open door').
<P>
2.  What are the clues within the game? A good puzzle should have indicators to its 
solution within the game itself. The next few clues should point the player in that 
direction. In our example, say the author has put a skeleton inside the grate as a clue. The 
next clue might therefore be: <br>
 How Do I Open the Grate? <br>
  You'll have to get in the house first. (see How Do I Enter the House?) <br>
  Have you looked inside the grate? <br>
<P>
Another type of in-game hint, often overlooked, is the non-working solution to the 
puzzle.  This is anything the player might do to solve the puzzle that doesn't resolve the 
situation, but that the game acknowledges and responds to with some kind of pointer to 
the real solution.  'So Far' is an excellent example of a game with many puzzles like this, 
the animal puzzle in particular.  In my hints for that game, I attempted to steer the player 
towards as many dead-ends as I could find, since each dead-end provided information 
one could use towards understanding the situation and eventually hitting upon the right 
solution.  Indeed, I myself solved the animal puzzle by first failing to solve it in several 
different ways.
<P>
3.  What is the logic involved? A good puzzle should be logical.  The next clue or clues 
should try to get the player thinking along the lines of logic needed to solve the puzzle.  
This might be a good place to say explicitly what you hoped would be inferred from your 
pointers to the in-game clues.  So, for example: <br>
 How Do I Open the Grate? <br>
  You'll have to get in the house first. (see How Do I Enter the House?) <br>
  Have you looked inside the grate? <br>
  The original key is probably lost. <br>
  But another key might be useful,... <br>
  What kind of key is known to open many different locks? <br>
  Didn't the skeleton remind you of anything? <br>
<P>
4.  What must be done to solve the puzzle? If the hint writer has conceded that the author's 
thinking might be alien to the player, they should probably also concede that the hint 
writer's thinking might be alien to the player as well (especially if the hint writer is the 
author!)  As mentioned before, explicit instructions should be included after the hints 
have otherwise been exhausted.
 How Do I Open the Grate? <br>
  You'll have to get in the house first. (see How Do I Enter the House?) <br>
  Have you looked inside the grate? <br>
  The original key is probably lost. <br>
  But another key might be useful,... <br>
  What kind of key is known to open many different locks? <br>
  Didn't the skeleton remind you of anything? <br>
  A skeleton key! <br>
  UNLOCK GRATE WITH SKELETON KEY, then OPEN GRATE <br>
<P>
It is traditional to give commands that should be entered directly as ALL CAPS, as 
above.
<P>
Inspiring<br>
 Hints are not an end in and of themselves.  They are there to provide inspiration to 
the player to go back to the game and try something new.  Sadly, there are no easy tricks 
to accomplishing this in your writing, except to say take your time and try to think about 
the problem from a variety of angles. [Readers, any suggestions here?]  Even the most 
inspiring clue may hit the reader at the wrong time and make them want to hurry on to the 
next clue.  So, we cheat.
<p>
 To cheat, we provide some artificial or external means of preventing the player 
from reading one hint right after another.  Different techniques may be used, depending 
on the format of the hints (paper, electronic, or in-game), and on how many hoops you 
want the player to jump through before getting the next one.  The motivation behind all 
of these techniques is the same:  to slow down the player so they have time to think about 
the first hint before going on to the next, and to prevent the player from accidentally 
viewing hints they did not want.
<P>
-Encryption<br>
 This option can take a wide variety of forms, and be used in all three formats 
(paper, electronic, or in-game).  Put simply, the hints are provided in a format that is not 
easily readable, and effort must be expended by the player to decipher each line.  The 
amount of effort can vary greatly, and should be kept in mind when writing the hints 
themselves.  For a great amount of effort, players expect a greater degree of hintage, 
while for less effort, you can get away with including 'filler' hints.  A few examples:
<p>
 -Letter Substitution.  Each letter in the clue is replaced by a different, unique 
letter.  The simplest method for this is to use 'rot-13', or substituting each letter by the 
letter 13 away from it in the alphabet.  Rot-13 has the advantage of being reversible--A is 
substituted by M, and M by A.
<p>
 -Word Substitution.  Each word in the clue is replaced by a number, and a booklet 
or file is provided with a list of words and numbers.  Some games may provide in-game 
hints with just the numbers, with the booklet available along with registration, or for a 
price.
<p>
 -Sentence Substitution.  Each sentence is replaced by a number, and a booklet is 
or file is provided with a list of sentences and numbers.  This method has the 
disadvantage of allowing a wandering eye to see answers to puzzles the player didn't 
want to see; this can be allayed by mixing up the clues and including fake ones, too.
<p>
 -Writing Backwards.  Each sentence is written backwards, perhaps with the 
spacing changed or removed.  This allows all hints and topics to be printed on the same 
page, but minimizes the effect of wandering eyes.  I would break with tradition here and 
*not* use all-caps for explicit instructions, since for some reason, ".PMUJ  .ELBAT NO 
DNATS" is easier to read than ".pmuj  .elbat no dnats"
<p>
 -Inserting Characters.  Some letter, like X, is inserted every other letter 
lxixkxextxhxixs.  Simple to use, and again minimizes the wandering eye problem.
<P>
 Whichever method of encryption used, it is probably best to write the clues in 
plain English first, then use or write a simple computer program to encrypt them, to 
ensure consistency and accuracy.
<P>
-Physical impediments<br>
 Game companies are most likely to use this method, since they usually involve a 
significant increase in cost than the simpler encryption methods above.  Infocom 
famously utilized invisible ink with a special pen that would reveal the clue in their 
Invisiclue booklets, but this technique may be too expensive to be practical today.  A 
simpler method, popular with Sierra among others, is to print the clues in light blue 
against a red pixellated background, which could be read if covered with a piece of red 
cellophane.  One problem here is that once you have the booklet and the cellophane, it 
can be too easy to slide down to the next hint, even by accident.  One of the advantages 
of the Invisiclue system was the finality--once you exposed a hint, it was forever exposed 
on the pages of the book, perhaps giving the player enough pause to contemplate that last 
clue again and discover the answer for themselves.
<P>
-Electronic 'encryption'<br>
 Once you move the hints to the computer, a wide variety of new options become 
available for use, in addition to those above (well, maybe not literal invisible ink).  A 
typical implementation will allow the player to read the hint topics, then click on one to 
go to the first hint, and continue clicking to go to successive hints.  One advantage of this 
format is that it provides a way to easily hide from view graphical or even auditory clues.  
While it is possible to create your own format, here are two that will probably suffice:
 HTML.  This is most often used for plain text clues with individual links to each 
clue, as Peter Scheyen's HTMLized Invisiclues  at 
http://www.csd.uwo.ca/Infocom/Invisiclues/.  My own hints for 'So Far' used this same 
basic format, with the slight modification that links were only provided to the first hint 
for any topic, with subsequent hints available only through manually editing the location 
bar.  The idea was to require more effort from the player, giving them more time to think 
about the previous hint.  Another option is to simply print all the clues in white text on a 
white background, which the player can view by highlighting the appropriate section.  
The wandering eye problem becomes a wandering mouse problem for players with jerky 
wrists or sticky mouse pads, but it's a simple method that can be created with minimal 
effort.
<p>
 UHS, or 'Universal Hint System'.  Currently online at http://www.uhs-hints.com/, 
this is a fairly popular multi-platform system that provides these types of hints in a simple 
electronic format, either from a standalone reader or online.  The reader is not free, which 
is a mixed blessing--on one hand, not everyone will be able to access your hints, on the 
other, if you write hints for a popular game, you can actually get paid.  Sending in your 
hints nets you a free version of the reader, at least, so if nothing else it's good for that.
<P>
-In-game options<br>
 Providing hints within the game itself allows a new level of options, probably the 
greatest of which is the ability to provide context-sensitive hints.  This means a lot more 
work for the hint writer, but a better experience for the player.  While the most popular 
in-game hint systems simply provide a way to get to a menu of hint topics, there are other 
systems that might be appropriate for your game.
<p>
 -One Hint Per Room.  In each room, the player can ask for a hint and get a clue 
about something to do in that room, or about something related to that room.  Probably 
not the best option for complex games, but has the advantage of being automatically 
context-sensitive
<p>
 -One Hint Per Object.  The player can ask for a hint about an object they possess 
or have encountered.  Again perhaps not appropriate for some games, but might work 
well for others
<p>
 Hintus Ex Machina.  Some object, character, or device within the game itself can 
give clues to the PC.  'Curses' and 'The Magic Toyshop' both had characters the PC 
could show objects to and get clues from, my own 'The Edifice' had special rooms where 
hints would appear etched into the wall, and Infocom's 'Arthur' had a toque you could 
peer into to get hints.  This method can have the advantage of furthering the atmosphere 
of the game, and players tend to be more forgiving of hint restrictions placed on the PC 
than restrictions placed upon themselves.
<p>
 Time-Delay.  Theoretically available for external electronic formats too, users of 
this option simply force the player to wait to receive the next hint, either by waiting a 
certain number of turns or by tying into the system clock and forcing a delay of an actual 
period of time (though I personally have never seen the latter, and imagine it might get 
annoying rather quickly).  This option is most often used with the 'Hintus Ex Machina' 
(as in 'Arthur' and 'The Edifice'), but would theoretically also be an option for menu-
based hints.
<p>
 The Penalty.  The player is penalized in some way (usually a decrease in score) 
for getting hints.  This technique has been around since an early version of 'Adventure', 
which allowed the player to get a hint at the cost of a point, and has been used as recently 
as 'Not Just An Ordinary Ballerina'.  The problems with this method are that it is easy to 
get around through saving and restoring, and perhaps more importantly that it furthers the 
breakdown of trust between the player and the author.  The author has already betrayed 
the player by creating a puzzle too hard for the player, and deducting points cements this 
division, rather than gently cajoling the player back to the game.  I include the option 
here for completeness, but strongly recommend against it.
<p>
 No Explicit Hints.  The one sure-fire method of keeping the next hint from the 
player is to never include it in the first place.  'Theatre', for example, while providing a 
number of hints for each topic, never explicitly told you the command to type, instead 
ending on indirect clues like "You need to have a girlfriend called Jane" when Tarzan-
like activity was required.  The NPCs in 'Curses' and 'The Magic Toyshop' likewise 
never told the PC explicitly what to do.  Be aware that by using this option, you will 
probably force some players to use some external resource (probably a walkthrough) to 
solve their problem, and once there, they may never return.
<p>
 Letting The Player Decide.  Rather than having to choose among the above 
options, in-game hints (and, theoretically, electronic hints), can leave the format up to the 
player.  At the most basic level, many Infocom games that came with hints allowed you 
to type 'hints off', which would disable the hints for the rest of that game session.  This 
method is somewhat ham-fisted, however, and easily gotten around by simply restarting 
the game for the express purpose of reading the hints.  A middle-of-the-road solution was 
utilized in 'The Legend Lives', where the user could request encrypted hints, which 
would pass all the hints (and, perhaps unfortunately, hint topics) through a rot-13 filter.  
Any number of above options could be used in this way, and might be a good way to 
include the 'No Explicit Hints' option without alienating the player.
<P>
 When written and utilized well, the result of a good hint system is that the player 
finds out how to get past were they were stuck with exactly the right amount of a 'push', 
and is able to go on and enjoy the game. They still feel challenged, and can complete the 
game without the sense of loss consumate with either giving up on the game altogether or 
from being 'spoiled' for that puzzle. (See "Cheat, Beg, Wheedle, Cajole" from 
XYZZYNews #12, at http://www.xyzzynews.com/xyzzy.12f.html ) I received the 
greatest validation of my own hint writing efforts when I read a post from someone who 
said they had just finished 'So Far' "without cheating", and only a "gentle nudge" from 
my clues.  Hint writing can take a lot of effort, but the players will thank you for it.
<P>