About writing "ABOUT"

Authoring General Design Discussions
1

The instructional messages in my meta menu in “Tree and Star” are too long and awkward. I realize that I don’t really know how to write a good informational message for the traditional “ABOUT” command/menu option. I know it should be short, but it’s hard to say anything at all without rambling.

How about credits? Should there be a separate “CREDITS” menu option/command, or should everything be grouped together in one meta message? Should a “HOW TO PLAY” or “UNIQUE COMMANDS” section go along with the generic “ABOUT,” instead of having its own section?

2

When I’m feeling lazy, I tend to combine everything into one go-to repository for metagame info, with a few short paragraphs explaining what the game is, unique commands, a few conditional hints and then the credits. Sometimes if there’s too much to say (in Calm we decided to list almost every command that would work in the game) it helps to refer to other help commands within the about or help text. “Type Commands for a list of commands and Credits for the credits” sort of thing.

A lot of people use menus and maybe that’s a better approach.

3

Hm, this is a tricky one for me too–the copout is “It varies by the game” but I think ABOUT vs CREDITS can be different and can overlap a bit & it shouldn’t be limited to these verbs.

There’s really no wrong way to do it & maybe thirty minutes’ thought will make it ok–I don’t see a need for complex menus, although a list of verbs may be nice if you want to address that (with VERBS) – my tendency is to avoid discussing parser commands and such in ABOUT/CREDITS, although I think ABOUT or maybe INFO can give a bunch of meta-commands to try to describe what the game is about. Obviously there’s a potential for sprawl here but if you have a list of verbs you like and make sure they’re signposted, people can figure what they want, where.

I’m not a big fan of menus, especially nested ones, so I like the approach of having these basic commands that are directly hinted. It also gives people a way to get used to the parser.

I think it’s ok to have these meta commands pointing back to each other & here’s my rough template.

ABOUT:

This game was thought up on (date) as a result of seeing (book/game X). It requires

This game is freely available but do not sell it for profit.

The author can be reached at @@@. If you find a bug you think needs fixing, I’d be grateful enough to put you in the CREDITS.

For general information about text adventures, type INFO. For specific people and websites that helped with the game, type CREDITS. For verbs specific to this game, type VERBS.

CREDITS:

Beta testers include …

People with post-release transcripts include …

Websites that helped include Jolt Country Forums, etc.

(For your game you may want to mention the Andromeda comp in both About and Credits. I also tend to mention transcripts in about/credits just because I like knowing about stuff I need to fix.)

So, yeah, there’s no wrong way to do it, and your testers will let you know about anything that looks grossly wrong or that can be reorganized–especially if you let them know you want their opinion on this, or how to make a good first impression. Most testers probably wrote a game, too, so they understand the importance.

These out-of-game commands should make the player feel comfortable and warm them up, and it’s kind of hard to figure what works in a vacuum.

4

The benefit of that being that the player only has to see the meta messages that he or she needs. This might be the downside of menus as opposed to simply printing the messages in response to commands.

In that case “ABOUT” doesn’t seem to be a very practical message. It’s probably background information that the player probably doesn’t need. I understand the logic of separating the parser from background information, though. Maybe “ABOUT” could be the equivalent of the text on the back of a paperback or inside the jacket sleeve of a hardcover book – like a summary, but (hopefully) completely non-spoiling. Except, I don’t think I’ve ever seen any IF games use “ABOUT” that way before.

Anyways, thank you both. I just found out that there’s a standard informational menu template that goes with the Hugo NewMenu extension I’m using, which can be activated by setting a compilation condition. I’m going to try that template to see if it works for my game, and I’ll keep thinking about it and experimenting.

5

That’s probably not the best way to go about it. I tend to type both “about” and “credits” in the games I play, expecting something different each time. I guess at the very least, separating them shows that you’ve gone that extra mile.

6

I think seasoned IF players have different expectations from beginners - but surely “help” is and should be the first stop for any of this information? So if you break out other info to “verbs”, “credits” and “about” it’s a good idea to mention that those commands (and whatever other stuff you implement) exist, in response to a “help” command. Right?

7

It’s probably not safe to assume that any player will try one of these first. So if you really want your players to see something, I think you should cross-reference.

For what it’s worth, here are my expectations:

If I type “CREDITS” I expect to see the names of beta-testers and that sort of thing. I don’t expect to see any help text, though if I get the whole about text I won’t be too upset.

If I type “ABOUT” I expect to see general information about the game, probably including the credits, and also including information about other things that work. This seems to me like it should contain the most general information – I don’t necessarily expect to be able to access hints from the “ABOUT” menu (and if it’s not a menu I certainly wouldn’t expect a hint from it), but I would expect it to tell me how to access hints. So if there’s a simple ABOUT text rather than a menu, I’d want it to say something like, “For a simple contextual hint, type HINT. For more detailed hints, type HELP. For a complete walkthrough, type WALKTHROUGH. For a list of unusual prepositions that you had no idea were even going to be implemented, type PREPOSITIONS.” Note that if you don’t put that last one in there, no one’s going to find it!

If I type “HELP/HINT/HINTS” then I want hints. It’s OK if these yield different kind of hints, but then one should tell me about the other. (IIRC Beet the Devil did a good job of this.) It’s not so terrible if this sends me to a complete ABOUT menu, except that if I have to dive to the bottom of a lot of different menus just to get to the hints that can annoy me. (This can happen sometimes if you’re using Emily Short’s Basic Help Menu in Inform 7, which of course you aren’t.)

I won’t type “WALKTHROUGH” or “INFO” unless I get an external prompt to do so.

But other people probably have completely different habits! What you really want is to make sure that people don’t miss something they want to find – like if you have different responses to “HINT” and “HELP,” a player might easily type “HINT” and assume that “HELP” yields the same result if you don’t tell them.

8

Good point about different expectations for beginners than for expert IFers. I never imagined that my game was remotely newbie friendly or intended it for anyone outside the IF community. I still think I should take a hypothetical new player, or relative new player, into account in my about menu, though.

If a special command to list unusual verbs does nothing other than list the verbs (that is, it’s not context-sensitive or anything), I don’t think having a separate command for it would help. Maybe a separate menu option, if menus are being used, since a menu option seems less segregated and calls less attention to its own importance than a command, I think.

Thank you. Those are helpful observations.

I think it might make sense to have different content for “HELP” and “HINT.” However, it’s probably not good to get too theoretical with this. Whatever is most efficient for players is best.

9

Aye. I’m a big fan of cross-referencing … and lumping them all together … and not lumping them all together … and using menus … and assorted hybrid approaches … and approaches which discard them all. There are no “best practices,” only what’s awesome here and now.

My only universal is that something should happen when a player types something like ABOUT, INFO, AUTHOR, CREDITS, HELP, HINT or HINTS. What should happen depends, always, on context. There is no best practice.

10

I agree that there’s no universal best way to do this. Start out by working out what information needs to be delivered, then decide how you organise that information.

11

I think a single menu system is best. But, certain commands can be shortcuts to submenus, so if you type credits or help/hints, it can take you directly there.

12

All I like out of an >about command is the version number, how to talk to people, and if there’s any special commands.

13

I’ll call your post and raise a quick overview of the game’s Zarfian cruelty.

14

I think the cruelty system is outdated and problemy. I agree with maga’s list of its limitations out yonder at ifwiki:

ifwiki.org/index.php/Cruelty_scale

I also find I have trouble even rating my own games or games I’ve helped test with it, in spite of possessing intimate knowledge of them.

  • Wade
15

I grant most of those objections, although the first one is misdirected, I think: the scale was never about difficulty, at all.

But I don’t think the notion is outdated. It’s still entirely meaningful. The fact that it’s tricky to think about doesn’t mean you shouldn’t.

16

The first one’s intended (whether the intention succeeds or not is another matter) to redirect a common misdirection.

Basically, the biggest rhetorical problem that the cruelty scale has is that it looks like a difficulty scale. A difficulty scale is something that there is a pretty clear need and desire for, but we don’t have one (or any good standard to produce one, or very much expectation that such a standard would be possible). If there was a difficulty rating to list alongside the cruelty rating, or if cruelty ratings weren’t positioned on IFWiki and ifdb as part of the basic information that a game should have, it wouldn’t be a concern.

The fact that zarf has had to repeat “it’s not the same thing as difficulty at all” for sixteen years means that, if nothing else, we’re not very good at broadcasting that “cruelty” is not just the community’s idiosyncratic way of saying “difficulty”.

17

It strikes me as one of the basic things I should know about a game going in - can I get permanently stuck? Dead ends? Will a single UNDO suffice to keep me out of a very frustrating walking dead? Will I, or will I not, need 300 savegames with 10 alternate realities based on things I did differently, wondering whether any of them is impossible to finish?

I think it’s only fair that I know some of this before going in, so I can adjust my gameplay style. It’s not new… twenty years ago you went in expecting games to be cruel. Nowadays you mostly expect games to be merciful or polite.

Zarf’s scale, despite whatever problems it might have, seems to be the only - and best - answer to this issue so far.

18

My decision for A Killer Headache was to split it up into several parts:

HELP - How to play IF, plus special commands in A Killer Headache
ABOUT - Story background and cruelty scale
CREDITS - Same as I7’s VERSION command
CHANGES - added as overflow to CREDITS
HINT - hint menus

But all of these commands contained cross-references to the command you might be looking for, and many error messages point to relevant commands, while keeping track of whether you have tried those commands yet.