What belongs in the ABOUT command response?

Of all the common meta-commands related to game information—HELP, VERSION, CREDITS, HINTS, etc.—the only one I find myself pondering is ABOUT.

I’m wrapping up my first game, and one of my last tasks remaining is to write an ABOUT. I sampled a few games to see how other authors tackled this:

  • Mike Carletta’s The Song of Mockingbird mentions the game was written for IF Comp 2021, it’s Zarfian rating, a few general hints, some thanks, and the game’s license. It’s the same as its CREDITS response.
  • Ian Finley’s Babel also lists its CREDITS.
  • Eric Eve’s Nightfall opens a menu with instructions, hints, credits, and a README.
  • mathbrush’s Absence of Law ABOUT is written using an in-game voice, with a dedication, tester thanks, and music credits. It too is the same as its CREDIT response.
  • Emily Short’s Counterfeit Monkey uses a menu system with some custom entries, including an introduction, game-specific commands, credits, and how to contact her. (This game is also the only one I found that doesn’t have a CREDITS command, or at least one available at the start of the game.)

From this variety, I assume there’s no pat template for ABOUT. Most simply display their CREDITS or use what appears to be a stock menu with some customized entries. (A standard Inform library, perhaps?)

My current thinking is to write a personal message thanking people and offering general tips specific to the game. My CREDITS command is more like a copyright page, in that it’s a bit dry, listing credits, version numbers, and license information. For ABOUT, I’m currently leaning toward Mike Carletta’s style.

Does anyone have any sage advice on their approach to writing an ABOUT for a parser-based game that’s not merely printing CREDITS or opening an instruction menu? Or know of a game with a unique approach to it?

2 Likes

If you want to say something to the player that’s optional for them to read, stick it in ABOUT. If it’s mandatory for them to read, either just print it at the start of the game, or tell them when the game begins they should type ‘ABOUT’ (which is sort of like putting it behind what Livejournal called a cut. Used to call? Whatever!)

There’s probably a degree of expectation that ABOUT is implemented, which I reckon is why, if the author has no particular need for it, they redirect it to the entirely optional CREDITS page. Which is fine. And I don’t think anybody will care deeply if it isn’t. Because if it isn’t, that in itself is a communication that the player doesn’t need anything extra from the author, or the author doesn’t want to give any… unless the player does (need something), in which case the absence will amount to poor implementation.

Mostly I would say, don’t divide up your ABOUT / HELP into more than one page unless you have good cause. Pick your fave verb, put the info there in response to it, redirect the other verbs to it. E.g. Make ABOUT and HELP go to your about/help/info page, and CREDITS go to your credits page. If you DO have good cause to create more than one info page, make it clear, in the text of each command, that the player can type ABOUT or HELP or VERBS or whatever to see that particular other page that has a specific purpose.

Alternately, if you have many help pages, it could be time to go to a menu extension… like Menus by Wade Clarke! I recommend my extension over alternatives or the famous old one, but I don’t really recommend menus in general. They seem to have gone out of fashion, perhaps as part of a view of accessibility that people shouldn’t have to read too many instructions anymore in advance of playing. I’m not 100% of this view but it’s the blow of the wind at the moment.

My parting shot is if you don’t need or want to say anything to the player in advance, then don’t.

-Wade

3 Likes

I always expected a message from the authors in ABOUT. Whatever it may be :slight_smile:

My take is ABOUT is “about this game”; CREDITS is “credits of this game” (a different thing than VERSION; copyleft/wrongs IMVHO has their proper place in the banner, by the way)

so, ABOUT ought to be about the game (blurb, readme, zarfian ratings, dedication, author’s rants/pride/braggadocio &c.) CREDITS should show the credits (ßtesters, helpful denizens of this forum, &c.) and VERSION should show the version of the story file, compiler and library/ies.

Influenced by Unix/Linux philosophy ? perhaps yes :wink:

Best regards from Italy,
dott. Piergiorgio.

2 Likes

That’s a fine approach, I think.

ABOUT is one of the first things I type in any newly started game (ABOUT, X ME, I), and I think a lot of others do so, too.

In my experience and expectation, it’s the default command for getting meta-information.

Reasons for that:

  • force of convention: it’s the standard (and also, as I remember it, there are more games that have an ABOUT but no extra CREDITS command than vice versa)

  • ABOUT is flexible and can be a one-stop (or maybe better first-stop) meta command as it can play multiple roles at once

  • the advantage over CREDITS is that ABOUT can contain more than just the credits: for example, advice on how to get HINTs and HELP, or a reminder that the game has some unusual special COMMANDS, or links to more background info about the game’s lore, or advice about the ideal interpreter setup or screen resolution, or a tip about turning on the sound because the game has music/SFX.

  • the advantage over HELP as a one-stop meta command is a) that ABOUT can contain credits, and b) from the player’s perspective, ABOUT is practically guaranteed to be non-spoilery, in contrast to HELP, which has a slight possibility of being the same as HINT

What I would put into the ABOUT:

(of course, some points only “if applicable”)

  • "<Title> was written by <Authorname> in <Year> [for <Competition/Jam name>, <link to the jam>]."

  • the contact information for the author: “Comments and bug reports are very welcome, please send them to email@example.com. If you’d like to, you can include a transcript of your playing session, which you can record by typing TRANSCRIPT.”

  • mention the development system which you’re using and thank its authors

  • Big thanks to the beta testers

  • mention that any remaining errors are, of course, the author’s fault

  • it might not be required, but I think it’s nice to explicitly credit extension/plugin authors (but ideally without making it seem as if they co-wrote or endorsed this particular game)

  • I wouldn’t list all the extensions’ titles here, that’s not of interest to the normal reader. But you can add: “(For a complete list of extensions with version information, type VERSION.)”

  • “For general information on how to play, enter HELP.”

  • “For a list of special/unusual commands which [work / are required] in this game, type COMMANDS.”

  • “If you’re stuck at any time, type HINT to get [a gentle nudge / a hint menu with further advice / …].”

And I’d make CREDITS (and INFO) an alias for ABOUT.

Or, if ABOUT is getting too long because you’ve got a lot of credits or a lot of non-credits, split off the credits into a separate output and mention the CREDITS command in the ABOUT (and vice versa).

Since new players might not know the ABOUT convention, I’d also include a piece of advice on start-up after the banner:
“(For more information on who contributed to this game and how to play it, enter ABOUT at the upcoming command prompt.)”
or something like that.
(Although it would probably be best to have a tutorial etc., but that’s a different question.)

As you and Wade mentioned, another typical thing which games do is to make a menu with all meta-options and just redirect every such command to the starting page of that menu. That can convey an air of tidiness and professionalism, but might also seem overwhelming at the start of a game.

3 Likes

For ABOUT, I’ve been writing a little bit of background to describe how the game came about (but trying to keep it concise) and which game jam or comp it was entered in (if appropriate), followed by credits. For CREDITS, I just provide the credits.

The former calls the latter, so the credits are in one place in the source code.

At what point are there too many meta commands? I have ABOUT and HELP, but I also have a number of commands intended to be useful, like TASK to help you remember what you’re supposed to be doing, HINT, and one other specific to my game. None of these are necessary, and if you don’t want to use them you don’t have to, but I worry that 5-6 meta commands in HELP is just overwhelming. Thoughts?

2 Likes

You can have as many as you need, but make sure the player is aware of them. Notify the player of all the meta-commands in HELP, and perhaps when play begins.

You can type ABOUT and CREDITS for information about this game. Type HELP to see all unique and helpful commands.

3 Likes

For my own part, what I like to see in an ABOUT response is:

  • Basic information about the game (game name, author name, year, and human-readable description of any other pertinent information that helps to situate the game in whatever situation it fits, like whether it’s for a competition or responds to another game or was inspired by a novel or poem, or whatever helps me to understand what would be a productive way to start thinking about it).
  • A pointer to an answer to “What on earth is this parser thing?” for truly new players. (“Included in the game’s introduction is Andrew Plotkin’s quick-start guide” or such, if nothing else.)
  • A set of quick things that experienced players might not think to try, but which they should (“Experienced players should note that this game makes use of several unusual commands, including PONDER, which increases your Philosopher ranking when used appropriately, and …”).
  • Either the information that’s might be included in other metacommands like HELP and CREDITS, or else an explicit suggestion to use those commands.

If a game does all of these things, I think the ABOUT text meets all basic expectations. But since it’s also one of the first things I see, so it’s a real plus if its writing is of above-average quality in some meaningful way that helps to set up the game: if it’s funny, or in-character, or piques my interest in some other meaningful way. “I will be your eyes and hands” in the original Adventure is a great example of doing this in a concise manner, I think.

3 Likes

This is a fantastic set of responses. Thank you everyone.

After I posted this, I realized there’s a related side question: What goes in the About box? That is, the pop-up dialog some (but not all) interpreters offer for the game. For TADS, this is coded as a separate method the writer needs to fill in (and therefore can print anything they want).

So far, I’ve simply had the About box display CREDITS. Last night it occurred to me that my CREDITS was getting a bit lengthy with it listing libraries, CC notices, versions, and so on.

I want to give everyone credit where it’s due, of course. But unlike an IF command, in modern UI practices the About dialog box is usually fairly compact. Apple still uses its ultra-minimal About boxes that take me back to 1984:

Screen Shot 2022-01-01 at 10.15.11

Other apps offer buttons or links to bring up more detailed information, but again, the trend is to pare down than go maximal.

So now I’m thinking of a “mini-CREDITS” mode for the About box.

(What makes all this confusing is that the About box shouldn’t print ABOUT but rather CREDITS, unless the author’s CREDITS merely prints ABOUT, in which case About should print something more like CREDITS. Now it’s starting to sound like an Abbott & Costello routine.)

That’s one of the reasons I took this seriously enough to ask for other’s opinions. I wondered if I was making too much of this, but if ABOUT is one of the first things players type, then yes, it’s worth thinking through. (It’s also why I spent my New Year’s Eve pondering About boxes.)

That’s an interesting point. I was going to have my one-liner be “(Type HELP for more information about this game)” or thereabouts, and have HELP list ABOUT, CREDITS, and other meta-commands. More like this:

But I’ll rethink it. I know that if, after installing a regular program like a browser or a word processor, the first thing it told me was “You should click Help” I’d think I made a mistake installing something more complicated than I needed. Starting off with “Type HELP” is not putting my best foot forward (although I’ll stick with listing the major meta-commands there).

Whatever I go with, for this game (rather simple and short), I want to keep the initial player “nudge” to a single terse sentence.

I agree, and it’s why I’m leaning toward something more than a bog-standard author’s acknowledgements page you might find in a book.

You probably expected this response, but I’d say it depends on the game itself. If yours offers additional assistance to the player, I’d say it’s important for them to know it’s there.

You might inform them of its existence as they progress, e.g., when they trigger a new goal print “(Type TASK at any time to see your current objective.)” so they don’t have to use HELP to know about it. You could also only display TASK, etc. in HELP when they’ve been informed of its availability (to avoid spoiling the game—again, depends on how they’re used).

But I don’t think five or six meta-commands are too much. We live in a time where real-time first-person shooters will utilize practically every key on the keyboard, and gamers buy mice with six or eight programmable buttons as well. I say we IF authors have some wiggle room here.

3 Likes

Thanks. I don’t play games outside of IF or iPad P&C games, so it’s easy for me to overlook how complex controllers are. My mind is eased.

1 Like

If there’s a lot to be said, I like the option of redirecting all the commands to a menu with all the various meta info laid out nicely. Then players won’t need to guess which verbs will get them the info they are after.

1 Like

Patrick involuntarily has given an interesting idea on metacommands.

PONDER is what every IF player does when tackling puzzles, so why not use said command for augmenting the immersion in the story ?
In other word, PONDER as synonym, if not a replacement of HINT (esp. adaptive hints) seems a idea worth of investigating…

Best regards from Italy,
dott. Piergiorgio.

3 Likes

I think mini-credits are absolutely okay, you could also just go with your name only. After all, the game is “(c) you”, and as long as you offer the full credits in a clearly visible place in-game (ABOUT, CREDITS), everything’s fine.

For further context (I think you know this already, but can’t hurt for reference, if people stumble across this thread later):

On some z-machine and Glulx interpreters, like Frotz and Windows Glulxe, there is a menu option “About this game”, which will display the cover image and the main bibliographic data which are stored in the game’s “blorb” file, as defined in the Treaty of Babel.

The text there is what the treaty calls the “description”, which is more like the back cover or comp blurb, rather than being equivalent to the ABOUT text within the game.

In TADS implementation terms, that’s the “desc” from the GameInfo/versionInfo object.

TADS doesn’t auto-fill its About Box with that “desc”, but the example given in “Some Common Input/Output Issues” in the T3 Technical Manual is:

setAboutBox()
    {
      "<ABOUTBOX>
       <CENTER>
       <<versionInfo.name.toUpper()>>\b
       <<versionInfo.byline>>\b
       Version <<versionInfo.version>>\b       
       </CENTER>
       </ABOUTBOX>";
    }

… which pulls its data from the versionInfo object, so that might point in the direction of also pulling the blurb-like “desc” data from there, if you want to expand the box. But there doesn’t seem to be a strict norm governing that, so you’re free to put something else there.

I like that!
(If the player is advised about it beforehand, of course.)

Some of Eric Eve’s games actually do it, for example Nightfall:

“The individual puzzles in Nightfall aren’t meant to be particularly difficult, but if you do get stuck, try using the THINK command, which will offer some suggestions based on the player character’s knowledge. If that doesn’t give you enough help, you can try the command THINK HARDER which may give you rather more explicit hints. THINK HARDER is in effect a hints command; using it more than once may give you increasingly explicit hints. You can safely use the THINK command without getting spoilers; use THINK HARDER if you want hints.”

4 Likes

You could always change it to “Type INFO for instructions unique to this game.” I think the assumption in most IF is that if a player is completely flummoxed they will type HELP, which should direct them to all non-standard commands. I’ve done a help text that’s like:

Type HELP to see this text, type COMMANDS for unique commands, INFO for the status of the game state, QUESTS if you’re not sure what you are doing, HINT if you are stuck, CREDITS for names of people who contributed to this game, ABOUT for information about the author and this game. If you are having trouble playing the game, visit [website] for an introduction to Interactive Fiction with more explicit assistance.

but it can be any verb you want COMMANDS, VERBS, INSTRUCTIONS - whatever feels best to you! You just need to let the player know what to type, ideally when play begins and when they struggle, which is why “help” is often used.

5 Likes

I have in fact been using PONDER as the hint command in a game I’m writing that’s grown out of control, to let the player know what needs to be achieved to move the story forward if they get stuck. So the basic response looks basically like this:

PONDER

Currently, you’re trying to:

Find your employee ID badge so you can go to work in the morning
Pick up the new reed set for your melodion
Figure out where your roommate is, because the party guests are looking for him
2 Likes

For an example of how I chose to approach it, I’ll share my output for these commands from my only complete parser game ever, The Land of Breakfast and Lunch. I took some care to give a unique answer for each of these commands. You’ll notice in addition to a general description about the game for about, I also use it to mention the license.

> about

You’re playing The Land of Breakfast and Lunch, a kind of game or a fictional miniverse where you can walk around and waste your time. There is not a lot of point to it, so just look around and poke around and enjoy yourself, if you like that kind of thing.

There’s only one puzzle and you won’t miss much if you don’t solve it.

All versions of The Land of Breakfast and Lunch are released under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 license. In summary, you may freely distribute, perform, or create derivative works, but not for commercial purposes without permission from the author. More information is available at http://creativecommons.org/licenses/by-nc-sa/3.0/us/.

> help / hints

The Land of Breakfast and Lunch is a little place for you to walk around in and look at every little detail. There are a couple of little tricky things you can accomplish, but there’s really no point other than to look at everything and smell everything and laugh at my dumb little jokes. Sometimes people don’t notice the toy box in The Land of Unrealized Possiblities. Sometimes people don’t realize you can “open hatch” and “enter rocket” when you’re near the 1950’s rocket. Yes, there’s one little puzzle and it involves the jack-in-the-box, but don’t get too concerned about it. If you need any other help you can just email me at danieltalsky@gmail.com. I’m happy to help.

> credits

The Land of Breakfast and Lunch was written by Daniel Talsky and is a [[Rabbit,Rabbit]] production.
http://rabbitrabbit.city

Inspiration and 3-D modeled cover art by Hypothesis Archer
http://reptilemind.com

The game’s generous and thorough beta testers include:

  • Jason “Always Be Testing” Dockins
  • Mike “The Pious” Tarbert
  • Caleb “No Stone Unturned” Wilson
  • Josh Grams
  • Matthew George
  • Michael “Space Swimmer” Baltes
  • Daniël Worm
  • Nick Gauthier

Special thanks to Mike “The Lord is His Shepherd” Tarbert for extensive testing PLUS actual code help.

Last, but not least, I’d like to thank you, the player, personally. You could be watching Better Call Saul or reading Fyodor Dostoevsky or playing pinball. Instead, you’re taking the time to explore something I made and I really appreciate it. I had fun making this, but most of the fun was imagining you doing what you’re doing right now. Reading the credits. No, I mean playing the game.

If you’re curious at all about my other thought-processes for the game, I did a pretty thorough postmortem for it.

4 Likes

These are nice examples to draw from. Thanks for sharing.

1 Like

Since this took a bit of a turn towards meta-commands in general, I think parser errors can function as a sort of meta-command that say “Hey! You seem stuck! Type VERBS to see what verbs to use.”

While I think/imagine that you have enough data to have made your own ABOUT just the way you want it, I’ll add what I think.

Yes, I like using ABOUT as a branch-off point for other meta-commands which hopefully give the player quick value. It may include the parser error responses I alluded to above e.g. “I didn’t understand the verb. Game X uses a simplified parser, which you can see with VERBS. You can see options with OPTIONS.” (Options might be ASCII maps vs text descriptions, for instance.)

CREDITS is separate for me, as my ABOUT can get rather long, especially if I have post-comp releases.

One other thing about ABOUT: most other people who want to do this probably do, but I like to have bracketed and italicized text before the player’s first move pointing the player directly to ABOUT or VERBS or whatever. Make extra sure new players see it!

THINK works well for me to say “OK, you are stuck at (puzzles a, b and c).” Also thanks @StJohnLimbo for the specific example especially since I’d wanted to play Eric Eve’s games for a while.

Oh … one other thing … you may wish to use the [one of][or] construction for “ABOUT” … it’s something I’ve tried, where the first time shows bare-bones information (noting a second ABOUT will give much more) and the second goes into a lot more detail. I know I have trouble striking a balance between not overwhelming the player and getting everything across, and this helps.

3 Likes

That’s an interesting thought and one I’d not considered. That approach might be useful in my next game.