or, “How to Write the Way I Write, in Inform 7”

Good afternoon. Possibly you would like to learn about how I write my text adventure computer games. There are a lot of angles to this subject, and the one I’d like to focus on here is the stage right after all that horrible “coming up with an idea” and “figuring out the story” stuff—the corpus callosum between design and implementation, getting the world to a state where the player can at least walk around and look at stuff.

I’m going to assume a basic familiarity with the Inform 7 programming environment, but if you have no idea how I7 works, you may be able to glean that basic familiarity from this post. Plus you will get to see my terrible handwriting!!!

Okay, so! First I draw a map.

I always always always draw the map first. I don’t know if this applies to everyone: I think my games are obsessed moreso than others with “sense of place” and “psychogeography,” and I rely on the layout of locations for pacing purposes. But I think any writer, and especially a game writer, will benefit from knowing the basic shape of the entire world at a very early stage. It can be fun when your story surprises you, but not when that surprise means you have to go back and rewrite a bunch of stuff.

To wit: I wouldn’t be satisfied with that “burbs” node looking the way it does here: We should figure out what those suburbs are really like before we get too much further. But this is just an example, so I’ll allow it.

Next I decide what details are in each room:

I wrote this in a great big sketchbook for some reason, so I gave each room a quarter of a sheet. Typically I use a smaller notebook and give each room half a sheet.

I limit the space available to populate each room because I don’t want them to get too crowded. A room only needs two or four thingies in it! Five, max. And I’m talking about thingies the player needs to keep track of: Stuff that should be on the edges of the player’s awareness, like the floor tile or a window, doesn’t count. Neither do nested or intentionally hidden objects, like a desk containing a drawer containing an envelope containing a lock of hair. You know what I mean.

Limiting the number of details per room makes the world a lot easier for players to hold in their minds, and it makes implementation a lot easier for the author. This approach to design could be termed “efficient” or “lazy” but it has also been called the “school of Ryan Veeder” which is kind of nice.

You can see that I don’t put only game-objects in these lists: I can also note what mood I want to create in that room, what mechanics I might want to use, et cetera. If I get a lot of ideas, I might want to re-write these outlines in a little more organized form. Perhaps on lined paper? Seems like a good idea???

Now I know where everything in the game will be, unless I end up straying from this written outline. (I usually don’t.) So now I start building the world in Inform.

A lot has happened already! Dang!

Inform 7’s method for organizing code is a hierarchy of Volumes, Books, Parts, Chapters, and Sections. If you have trouble remembering the order of these ranks, I give you permission to use the mnemonic “Very Bad People Choose Sin,” which I invented, you’re welcome. (These headers are strictly organizational. They don’t do anything to the game. That doesn’t mean they’re not extremely useful though.)

I assume right away that I’ll want to dedicate volumes to “Boring Verbs” and “New Mechanics.” I may or may not know what mechanics I want to introduce, but I do know that there are a lot of “boring” built-in I7 verbs (“smell,” “jump,” etc.) for which I’ll want to replace the default responses, and several verbs that I7 doesn’t recognize by default, but which deserve responses, like “sing.” I want my responses to these boring verbs to fit the narrative voice of the rest of the story, so I’ll get around to writing those responses after I’ve written the rest of the story.

(The “scenario” gets its own Volume, and “rooms” gets its own Book therein. Each room will have its own Part. The specifics of which levels of I7 hierarchy apply to which levels of mechanical hierarchy are flexible and not super important.)

Each room has a name. I try to give the rooms very specific single-word names, because if I have rooms named “front porch” and “back porch” and “back alley”—or rooms like “dining room” and “sewing room” sharing a game with objects named “dining table” and “sewing needle” then I and the compiler will get really confused really fast. Do not use the word “room” in the internal name of a room. “Firedept” works great for me, and because I’ve declared its printed name, the player will only know it as “Fire Department.” (I would have to do extra work if I wanted the player to be able to refer to rooms in commands, but typically I find this unnecessary.)

I also put in the room connections at this stage. I am “drawing the map” again, so that I can compile the game and start strolling around, or look at the index map to make sure everything’s set up right:

(On viewing the index map, I might notice that I mis-named one of the rooms somewhere in the source, and accidentally created rooms named both “pizza” and “pizzaplace.” Here I would catch that mistake and fix it—but I don’t have a screengrab of that, because I’ve never made a mistake.)

I’ve also included the lists from my notebook of things that I want to be in those rooms, inside comment brackets. If I get all that information into the comments here, then I don’t have to refer to my notebook anymore, which is nice. I can use this as a sort of checklist, deleting items from the comments as I cause them to exist in the game. And the first thing I do is decide what kind of things they are:

I’m doing one room at a time, for my brain’s sake. First I just say what everything is: “Scenery” and “person” and “animal” are among the object types built into Inform, which serve most purposes. (Other default kinds include “container,” “supporter,” and “door;” technically “scenery” isn’t a “kind” but “who cares.”) I’m making the poster and the fire engine into scenery because I already anticipate that they will be mentioned in the room description, and I don’t want the complete >LOOK text of the room to include an extraneous “You also see a poster and a fire engine here.” (Often I will make a person also be scenery, but that’s a pretty advanced technique.) (No it’s not.)

With a view toward creating that first impression of the room, I give it a description, and I give “initial appearances” to its non-scenery inhabitants:

(Presently it occurs to me to give the dalmatian some synonyms, so I do so.) Now I can compile the game and make sure the room looks the way I want:

Which it does!* Naturally. If every room were implemented to this level, then we would satisfy what I believe to be the most fundamental component of the parser IF experience, that of walking around, or simply occupying a simulated space. The second-most-fundamental component of the parser IF experience is that of looking at stuff. We do this by writing object descriptions:

(I guess I also started making the chief a little bit interactable.) Now, at last, the rooms exist; their contents exist; the things that exist are noticeable; and the noticeable things are observable. I have implemented the most stultifyingly essential stuff, then some somewhat less stultifying stuff, and so on until: The player can walk around and look at stuff.

So I guess we’re done for today! We can add all the complicated interactions, new verbs, currency system, etc. later. I’m sure you’d find the rest of my process just as engrossing, but I don’t know if we’ll get around to discussing it.

Thank you for your interest!

*Um not quite! Have you noticed what this room description is missing? I will tell you in rot13: Vg arrqf n fragrapr fnlvat jurer gur rkvgf ner!