IF Style guides?

I’m trying my hand at my first IF of non-trivial length and I was wondering if some generalized style guides or style hints exist. I’ve played several IFs that seem to have some things in common making it easy to pick up and play but I haven’t quite figured out what these commonalities are.
I’m using Inform 7 and I’m particularly wondering about the use of ‘scenery’ vs’ things’, what verbs should I support, is there a standardized fashion in which conversation/hint systems are expected to work nowadays?

Could someone point me to some style guides or examples of ‘perfectly styled’ games?

I’m attempting to write a story/puzzle IF. Thanks for any help!

Well, mostly you can go ahead and do the game you want to.

Scenery vs things: you declare something as scenery if you want it to be something immovable and not worth having its own automatic description separate from the room description. You want to declare something as objects if they’re portable, mostly. This is hardly a hard-and-fast rule.

There seems to be a trend of preferring that EVERYTHING that you can meaningfully interact with should have a line break between it and the room description, so that the room description becomes “This is a room with this and that and those, which you don’t have to worry about. [line break]Also, you can see eenie, meenie and moe, which are definitely worth your attention”. I personally dislike this; it’s perfectly valid to have important items as scenery mentioned in the room description.

I7 already comes with all the standard verbs supported. Any verbs you want to add will be specific to your game; make sure that if the game suggests an action, it’s something the player can try. The extension “object responses” (I think that’s what it’s called, it’s by Juhanna) will help you in making sure you get appropriate replies.

Conversation can be a lot of things, but mostly it’s of the ASK/TELL variety, like in Anchorhead or Galatea. You can make it CYOA-style, if you like, like in Earth And Sky. You can mix both, like in City of Secrets. You can forego it entirely and just have a “TALK TO” command that directs the whole conversation on rails. Everything is fair game. ASK/TELL remains the basic standard, I guess.

Hints usually use a separate menu, like the HELP menu. But again, it’ll have to do mostly with the style that you chose, and what you want to do. Aaron Reed’s “Adaptive Hints” extension shows a pretty different approach.

There’s no such thing as a “perfectly styled” game, because there isn’t a “perfect style”. But highly rated games at IFDB are very polished and are definitely worth looking at as examples. See most everything by Emily Short, Andrew Plotkin and Adam Cadre. See also Anchorhead and Lost Pig.

This is not exactly what you asked for, but you can learn a lot by browsing IF Gems, a collection of reviewer opinions from IFComp reviews, organized by theme. Chapters 3.8 and 3.9 are about hints, chapters 13.6 and 13.7 are about conversation systems and chapter 14 is about commands.

Here’s a summary of what I’ve seen described as best practices, along with some other observations, in no particular order:

New verbs: Some common verbs you may want to add are help, hint, about, info, credits, and walkthrough (some of these may overlap). Some people also add xyzzy and such, but this is not required. Go to and exits are nice conveniences, but not necessarily expected.

Exits: It’s also a nice convenience, when a player tries to go a direction that’s not supported, to list which directions are actually available.

It seems to be generally expected, if you are, say, outside a building, to allow both in and enter building to work, along with the relevant compass direction. You can make a scenery object to represent the outside of the building, and redirect enter from there to the appropriate compass direction. Likewise, from the inside of a building or location, it’s good to allow for both out and the compass direction. For stairs, if a stairway to the north leads upward, both north and up should work.

Implementing nouns: People tend to get annoyed when nouns in the room description are not recognized by the game, especially if those nouns seem interesting or important. They don’t all necessarily need a unique description–for instance, you can have multiple related things point to one common description, by making them synonyms–but people like to have SOME sort of response to x noun.

Synonyms: Include synonyms so players are not forced to guess the verb or the noun.

Extensions: Object Response Tests and Property Checking are very useful extensions to avoid overlooking things.

Puzzle Feedback: Give feedback to players to let them know if they’re on the right track with a puzzle. If they try something that makes sense but isn’t the right solution, give them a nudge in the right direction.

Hints: One of the common hint systems relies on a style of menu that requires you to key up and down, and that type of menu is not very screenreader friendly. In-line Topical Hints is a good alternative. github.com/i7/extensions/blob/m … 0Hints.i7x.

Conversation: Conversation systems vary, but if you include one it’s a nice touch to give some sort of response if players try the wrong wording. E.g. if you are using ask and tell, it’s nice to have some sort of response to talk to to redirect people.

Player: Including a non-default description of the player is sometimes used as sort of a litmus test of polish.

Testing: The number one rule, though, is beta testing. And crediting testers under about/info/credits.

I totally agree!

One of the guys behind the game Amnesia has written a really good piece called The Self, Presence and Storytelling. One of the things discussed is how it weakens immension when the raw game mechanics are laid bare: