What are some of the classic Inform 7 mistakes to look out for?

+1 vote
207 views
asked Mar 25 in Authoring by Joseph Geipel (207 points)
recategorized Mar 27 by Alex
In my work in Inform 7 and in my testing of works made in Inform 7, I've noticed a few problems that are easy to forget about while coding. It would be nice if there was just a solid checklist of well-known and common subtle issues to go over. I'm looking less for problems in Inform 7 code that prevent compiling but more for problems in Inform 7 that lead to bugs in a successfully compiled work.

2 Answers

+1 vote
answered Mar 25 by Joseph Geipel (207 points)

The relationship between exiting, getting off, and going outside: When the player types OUT, EXIT, etc. by itself, it will start off as the exiting command. If the player is not on or in anything, it will be converted into the going command with a noun of outside, which can be accessed directly via GO OUT instead. If the player is on a supporter, the exiting command will be converted into the getting off command with a noun of the supporter you are on, which can also be accessed directly via GET OFF NOUN. If the player is in a container, it will fully perform the exiting command that is used to make the player leave a container, which cannot take a noun. EXIT NOUN will result in "I only understood you as far as wanting to exit.". Be careful when doing "Instead of exiting" rules: it's all too easy to wind up in an infinite loop.

In vs. on: Make sure that your if statements use the proper preposition. If you make a supporter called a chair it is still quite easy to accidentally have an if statement of "if the player is in the chair" that will always be false since the chair is a supporter and not a container.

Getting rid of vital objects via putting on and inserting into as opposed to dropping: If you have an object that the player isn't allowed to get rid of, make sure that you not only prevent dropping it but also putting it on a supporter and inserting it into a container.

0 votes
answered Mar 25 by AndrewS (250 points)
edited Mar 25 by AndrewS
Namespace collisions e.g. red writing is scenery. blue writing is scenery.

check examining the writing:

 

Blank spaces in tables can be a problem. Tables can be tough to fill every entry in. You should always initialize them when play begins.

 

Forgetting an instead in check rules is a big one.

 

Also, forgetting "continue the action" in after rules can cause the rules to end early, e.g.

 

after eating: increase fullness by 1;

after eating the pizza: increase happiness by 1; [above rule will not fire without continue the action]
This site is now closed.
As of 1st November 2015, this site is a read-only archive. For more information see the intfiction forum post

Welcome to IF Answers, a site for questions and answers about Interactive Fiction.

Technical questions about interactive fiction development tools such as Inform, Twine, Quest, QuestKit, Squiffy, Adrift, TADS etc. are all on-topic here.

Non-technical questions about interactive fiction are also on-topic. These questions could be about general IF design, specific games, entering the IF Comp etc.
...