Similarly but I think less widely observed: if the text directly or indirectly suggests that the player might do something, or might not do something, or can, or can’t – implement that action, in the same words. Even if it’s just saying that you can’t.
Also, debugging extensions can be very helpful! “Object Response Tests” by Juhana Leinonen tries different combinations of verbs and objects to help you check to see if your responses make sense. “Property Checking” by Emily Short is helpful to find things you may have forgotten to write a description for.
Are all exits/directions correctly mentioned in the room descriptions (and/or in the status line, if you use an extension for that)?
Does the intended “winning walkthrough” work, i.e., can the game be played from the start to a/the winning ending? You can use the handy TEST command (see Chapter 24.2 in the I7 Manual) to let the IDE play your “walkthrough” automatically.
(Of course, ideally, the game should be thoroughly tested by beta testers in all aspects, but I thought I’d mention this test specifically because a) it really is kind of the absolute minimum that should definitely work, and b) it’s relatively easy to check in an automatic way.)
If you provide “feelies” (PDF files, accompanying map, documentation etc.), do they reflect the current state of the game correctly? (It’s easy to forget keeping everything in sync when you update the game.)
If you have a cover image, is it still reasonably legible at a small resolution (for example, when displayed as a thumbnail or preview or on a mobile device)?
Are all your beta testers mentioned in the CREDITS/ABOUT?
Do you give the players a way of contacting you for feedback, praise, bug reports?
One thing I would add to the list is to watch responses which don’t make sense if they’re repeated and to put in an alternative.
For example:
show the crucifx to the vampire
The vampire laughs. “Those things don’t work on me! Actually, I’m a Christian, I just have a different view on things.”
show the crucifx to the vampire
The vampire sighs. “Yes, yes - it’s very nice”.
show the crucifx to the vampire
The vampire ignores you.
Have you written a description of the player character in response to EXAMINE ME ?
The default in Inform 7 is “As good-looking as ever.” Experienced authors will always update this in some manner.
Can the game respond sensibly to EXAMINE ROOM ?
A “room” is a specific type of object in I7, but the parser won’t understand it from player input by default. The easiest method is to redirect it to LOOKing.
the environment is a backdrop. It is everywhere.
Understand "surroundings/room/around" as the environment.
Instead of examining the environment: try looking.
Instead of searching the environment when the location is Room 2:
say "You find nothing but dust upon careful search."
Make sure to implement that dust as scenery! Mentioning it specifically means the player will try to interact with it!
I don’t actually have a lot of “rooms” in my adventure, as it’s mainly out doors.
What I have done is implemented a thing called “enclosing”, like this:
Enclosing is a kind of backdrop.
Enclosing has text called short name. The printed name of enclosing is “[printed name] that you are in”.
The description of enclosing is “Being inside the [short name], you’ve already got as good a description as you can possibly get.”.
Instead of doing anything other than examining to enclosing, say “Concentrate on what’s inside the [short name] rather than on the [short name] itself.”.
Instead of doing anything when the second noun is enclosing, try nulling the second noun.
(nulling is an action that does nothing but just redirects from one rule to another)
Then:
The enclosing vast forest is enclosing. The enclosing vast forest has short name “vast forest”. The enclosing vast forest is in the woodlands.
Where “woodlands” is a region. Resulting in:
examine forest
Being inside the vast forest, you’ve already got as good a description as you can possibly get.
Just as a thing, I have a base template for an object, and I create one and complete it for EVERY noun in the game :
todo is a thing in todo. It is scenery. The description of it is "TODO.". Understand "todo" as the todo.
Instead of doing something other than examining with the todo:
say "todo.".
I find it’s a good habit to get into to copy this super basic template any time I create an object that isn’t useful but still needs some love and attention.
Confirm that for your final build you used Release (as opposed to Release for Testing) if you want to exclude any test verbs / commands, and that you have marked any sections (not for release) that should not be in the release.