In case anyone’s interested in a long read, there’s interesting thread about designing a tutorial mode here: Can we make a better parser tutorial?
I came away feeling like the two most promising options were:
- Use a very restrictive approach, like Amanda’s exploring… require the user to type in precise commands in the correct order.
- Use a more complex rules-based approach, like the one implemented in Emily Short’s Tutorial Mode extension.
The first approach has a lot of advantages: simpler to implement, harder to get into bad or untested states, avoids the early paralysis of choice. I have a theory that reading a transcript of gameplay, like Inform used to include in their manuals, was an effective way to learn… since people can often learn to imitate much faster than internalizing rules. A railroaded tutorial is a bit like a transcript you’re forced to type in yourself.
Of course, there are many advantages to the more flexible approach too… among other things, it allows learners to experiment with the rules. Also presumably Short has actually tried it out while I have only speculation and anecdotes.
Also, on the formatting question… I pulled some formatting details from the Z-machine spec. The TL;DR is that nothing useful for formatting help text is actually required by the spec. Glulx might be different of course.
Z-machine digression
Text may be printed in any font of the interpreter’s choice, variable- or fixed-pitch: except that when […] the text style has been set to Fixed Pitch, then a fixed-pitch font must be used.
So interpreters are required to support fixed pitch, but are allowed to print everything else in fixed pitch too, so it’s not always visually distinguishable.
Text can be printed in five different styles […] Roman (the default), Bold, Italic, Reverse Video (usually printed with foreground and background colours reversed) and Fixed Pitch. The specification does not require the interpreter to be able to display more than one of these at once (e.g. to combine italic and bold), and most interpreters can’t. […] An interpreter need not provide Bold or Italic […] and is free to interpret them broadly. (For example, rendering bold-face by changing the colour, or rendering italic with underlining.)
So Reverse Video (as used in the status bar) appears to be required, but nothing else.
If the interpreter cannot produce colours, it should […]
So colours are entirely optional.