An alternative, particularly for off-line viewing, is to have an empty dummy project thus:
Hello World is a room.
that you can have simultaneously open with your current project or compile quickly at a moment’s notice. This gives you easy access to a minimal Project Index within the IDE when the project you are actually writing won’t compile (and therefore might not have a Project Index).
This is exactly how I started. I copied examples, changed the descriptions, and started taking things out and changing them around to see what broke.
Early on, I relied on Jim Aiken’s book and this forum. The documentation and recipes always felt specific to things I didn’t really want to do.
That doesn’t seem true, now–I look at it all the time now (via Zed’s page, of course) --but I found them frustrating in the beginning. I learn best by looking at examples, so the discussion + code format of this forum was very helpful to me.
This kind of “spot learning” had its downsides. I didn’t realize that I ought to (at least to complement my way of thinking about things) use the whole action sequence for quite a while, and I’m not sure when I found out about the index.
It’s more about browsing this forum on mobile, or on a different device, where I can’t pull up Inform to look at the Index. An online version gets around that issue.
When you write code with Inform, you are not starting with a blank slate. Your code is not simply a set of instructions that the computer follows in order from top to bottom.
There are a bunch of built-in instructions that you do not see, telling the computer to do standard things (like what to do if the player tries to examine something, or throw something).
When you make a game, your code gets automatically combined with those standard built-in instructions. So if at any point you are telling the computer to do a specific thing, you also have to explain when the computer is supposed to do it. You can’t just say, “Do this thing.” What you write is more along the lines of, “after this thing, do that thing” or “before this thing, do that thing,” or “instead of this thing, do that thing” so the computer knows how your instructions fit in with the other instructions.
Before creating a new action, try typing ACTIONS in the IDE and try what you think the player will type to see if there are already built in synonyms or vocabulary you can take advantage of, or need to disassociate before creating the new action.
Example: if you want to KNOCK ON DOOR, inform already assumes knock is a synonym for ATTACK which is blocked by default. So you can refer to “attacking the door” to write rules like “instead of attacking the front door: say “You knock politely.”
It is hard to cut corners in Inform 7 which is actually a good thing.
(Inform 7 might feel difficult at first to newcomers as you must follow all these rules in order for the game to work. However, the rules are there to “protect” you from ruining the parser. This is in contrast to many easier IF systems, which get you started faster but you can much easier end up with a horible parser when you want to add custom verbs/sentence structures.)
There’s a better way to see what verbs are synonyms than to try typing things in:
Type (for example) ‘showverb attack’ and you’ll get this:
Verb ‘attack’ ‘break’ ‘crack’ ‘destroy’ ‘fight’ ‘hit’ ‘kill’ ‘murder’ ‘punch’ ‘smash’ ‘thump’ ‘torture’ ‘wreck’
* noun → Attack
which not only tells you all the synonyms for attack, but also that ‘knock’ isn’t usually one of them
by default, Inform doesn’t recognise ‘knock’ as a verb at all (at least in 9.3/6M62 and 10.1)
Typing ‘showverb knock’ gets the response ‘Try typing “showverb” and then the name of a verb.’
EDIT: small print This is a direct printout of the I6 definition of the verb. The line
* noun -> Attack
means that a typed command consisting of any one of the listed verb synonyms (represented by ‘*’) followed by a noun will be parsed into an Attack action
EDIT2: to add ‘knock’ as a synonym of attack:
Understand the command knock as “attack”.
I apologize for being behind or speaking confusingly; I’ve never used I6. I haven’t seriously used Inform 7 in a while and hadn’t downloaded any updates, and historical versions have put “knock” as a synonym for “attack” as in “knock out [something]”. If they’ve decoupled KNOCK in Inform 10 that’s probably good!
On further investigation, it would seem ‘knock’ disappeared as a synonym for ‘attack’ between versions 9.2/6L38 and 9.3/6M62.
In case anyone reading this thread remains confused, typing showverb <a-verb> during play in an I7 story displays the relevant Verb directive in the I6 code compiled from the original I7 source code, listing all the synonyms compiled for that verb followed by a list (somewhat cryptic to those uninitiated into I6) of the so-called ‘grammar lines’ that the parser uses to recognise and translate typed commands starting with one of those verbs into an action.
I6 grammar lines are how phrases in the more comprehensible I7 idiom like ‘Understand "throw [something preferably held] at/against [something]" as throwing it at’ end up after compilation, in this case:
* held 'at' / 'against' noun -> ThrowAtFirst, I’m glad you showed me this ‘showverb’ command, because I didn’t know it. That said, I assumed I’d easily be able to make sense of these allegedly cryptic lines, but nope. Here’s an example for ATTACK:
showverb attack
Verb ‘attack’ ‘break’ ‘crack’ ‘dent’ ‘destroy’ ‘fight’ ‘hit’ ‘injure’ ‘kick’ ‘kill’ ‘murder’ ‘punch’ ‘smack’ ‘smash’ ‘strike’ ‘thump’ ‘torture’ ‘wreck’
* noun → Attack
* ‘in’ / ‘into’ / ‘down’ / ‘through’ noun → Attack
* noun ‘in’ / ‘down’ → Attack
in into down through attack? What?! I7 says ‘Understand “attack [something]” as attacking’ and that’s it.
-Wade
In Inform 7 terms, that’s showing three grammar lines:
Understand “attack [something]” as attacking.
Understand “attack in/into/down/through [something]” as attacking.
Understand “attack [something] in/down” as attacking.
In other words, the slash means the same thing as in I7, and noun means [something].
But the I7 grammar for attacking says nothing about allowing ‘attack in/into/down/through’.
EDIT: argh it’s those Aaron Reed extensions I’m using, isn’t it?
-Wade
I would guess so, yeah. Here’s what I see.
>showverb attack
Verb ‘attack’ ‘break’ ‘crack’ ‘destroy’ ‘fight’ ‘hit’ ‘kill’ ‘murder’ ‘punch’ ‘smash’ ‘thump’ ‘torture’ ‘wreck’
* noun → Attack
In other words, only “attack [something]”.
One thing I would like to add is–
Do not give up. If you have an idea that you wish to implement, for an IF piece in Inform7, follow it through. Don’t dismiss it. There is a way to do it. Someone in this discussion mentioned ‘the many ways to skin a cat’ (or some similar metaphor) with Inform7, and I believe that this is true. You will find it if you are persistent. And you certainly won’t regret the time spent looking; you will remember the technique when you need it later, because you spent time working on it.
I believe this holds true for ‘any’ language - no way is the ‘right’ way and most of the time you will always find ways to overcome (or at least bypass) a problem that was originally blocking your game from moving on. It generally boils down to how much time and effort you are prepared to put in against the ‘what is my easiest option to overcome this problem’. My old school moto was ‘perseverance’ and am in no doubt that it has held me in good stead over the years 
- AG
Inform 7 is not just a domain-specific programming language, but one built on two specific ideas about how interactive fiction should be designed and written:
Interactive fiction writers are primarily fiction writers. Their main role is to write narratives and prose; programming is a way of fitting that text into the game, and the language should take care of as much of it as possible to let humans concentrate on the writing. As such:
Programming an interactive fiction game should be as close to prose writing as possible. Symbols like parentheses and braces should be avoided; programming should look like English prose and follow English syntax (but, crucially, an English syntax rather than any English syntax); conventional programming terms should be eschewed in favor of more conversational ones (‘say’ for ‘print’, ‘decide’ instead of ‘return’, etc.); objects should be referred to in the program by their descriptive English names instead of arbitrary identifiers; and so on. Even the documentation is mostly a set of verbose examples rather than a technical description of how the language works.
If you agree with both of those points, then you’ll probably be able to overlook the downsides of Inform 7 and enjoy its upsides. If, like me, you vehemently disagree with both of them, then you’re going to have a bad time.
Agree. I would add that Inform is primarily descriptive declarative rather than procedural. Descriptive Declarative languages are generally easier for non-programmers to learn. That is Inform’s major strength. While there are some procedural language elements included, I find them to be the weakest part of Inform and heavy use of them wrecks the prose-like quality of the source code.
I’ve often wondered if it was worthwhile to study when and why people resort to procedural coding to get certain tasks done in Inform. How could the descriptive declarative elements of inform be expanded to eliminate the need for procedural processing code in Inform? In other words, how could common tasks currently relying on procedural programming be expressed simply in plain English at a descriptive declarative level?
I may be wrong (I’m very much an Inform neophyte), but I think a lot of the procedural stuff is used to process tables. I find this ironic, because SQL, a descriptive language for working with database tables, has been around forever.
SQL is very much an imperative language (as opposed to descriptive), as indicated by its verbs (INSERT, UPDATE, DELETE). Even when describing tables, it outputs the imperative commands needed to recreate the table.
People have attempted to use declarative languages (what you refer to as descriptive) to accomplish what are inherently imperative (what you call procedural) tasks and not done so well. Ant (a Java build language expressed entirely in XML ) is an example. It’s absolutely horrid to work with. Also note HTML/CSS, which are both declarative, need Javascript to actually make a webpage do anything dynamic.
Similarly with Inform, with entirely declarative language – “Lab is a room. The ball is in the lab.” – we could make a perfectly working game, but it wouldn’t do anything interesting. It gets interesting when you put in rules – and then you’re in imperative programming. There’s no way to get around that if you want to have the Standard Rules be extensible, because to be interesting you need to change state, and changing state needs to be imperative at some level.