Organizing Inform 7 code

“How to organize I7 code” is somewhat of a FAQ here, so I wrote briefly about how I do it: … rm-7-code/

Cool! Thank you. I was looking for a general structure outline like the one in this article, and the game links help too.

It seems like there would have been other craft articles focusing on I7 codebase organization by now, right? I feel like I just haven’t figured out where to look for them.

Aha! Just the guide I need. Thanks for putting that together.

Are there any bits that MUST occur before other bits? I think I started grouping my new types of values at the top for this reason, but can’t remember.

I have learned to right from the beginning to group stuff. For the last couple years my Mac Inform version did not have the jump-arrows that normally occur in the compile errors to hyperlink to the code line in the source where the error is. I had to know what everything was called to search for it, or know where it originated to find it in the outline view.

Here’s some outlines for my games, collapsed for spoilery.

[rant=Transparent]“Transparent” by Hanon Ondricek
Include Basic Screen Effects by Emily Short.
Include Glulx Entry Points by Emily Short.
Include Music by Daniel Stelzer.
Include Easy Doors by Hanon Ondricek.
Include Postures by Emily Short.
Include Epistemology by Eric Eve.
Use MAX_SYMBOLS of 25000.
Use MAX_PROP_TABLE_SIZE of 275000.
Use MAX_OBJECTS of 700.
Volume 1 - Release and Setup
Volume 2 - Help and About
Volume 3 - Figures
Volume 4 - Sound
Volume - Startup
Volume 5 - Global Backdrops and some adjectives
Volume 6 - Knocking
Volume 7 - Electricity
Volume 8 - Lighting
Volume 9 - Doors
Volume 10 - Photography
Volume 11 - Darkness/Flashing
Chapter 1 - Images
Volume 12 - XYZZY
Volume 13 - Mansion
Volume 14 - Sunset
Volume 15 - Front Entrance (start)
Volume 16 - Phantasms
Volume 17 - Camera Equipment
Volume 18 - Peristyle
Volume 19 - Bottom of Ramp
Volume 20 - Entryway
Volume 21 - Foyer Gallery
Chapter 1 - Door Sounds
Volume 22 - Bottom of Stairs
Volume 23 - Top of Stairs
Volume 24 - Corridor
Volume 25 - Hidden Statue Garden
Volume 26 - Elevated Window Passage
Volume 27 - Visitor Entrance
Volume 28 - Ticket Counter
Volume 29 - Stable
Volume 30 - Stone Steps
Volume 31 - Portico West
Volume 32 - The Kitchen
Volume 33 - Cellar
Volume 34 - North Upper Hall
Volume 35 - West Upper Hall
Chapter 1 - Door and Chair Madness
Volume 36 - Library
Volume 37 - Study
Part 1 - Guest Code by PaulS
Volume 38 - Sitting Room
Volume 39 - Parlour
Volume 40 - Dining Room
Volume 41 - Ballroom
Volume 42 - Conservatory
Volume 43 - Nursery
Volume 44 - ButlersQuarters
Volume 45 - Boudoir
Volume 46 - Attic
Volume 47 - Master Bedroom
Volume 48 - Playroom
Volume 49 - Drawing Room
Volume 50 - Vault
Volume 51 - Studio
Volume 52 - Master Bath
Volume 53 - Servant Quarters
Volume 54 - Garage
Volume 55 - The player
Volume 56 - Ghostcalls
Volume 57 - Butler
Volume 58 - Earnings
Volume 59 - Standard Ending
Volume 60 - Alternate Ending
Volume 61 - Not for release
Volume 62 - Library Messages and Stupid Commands
Volume 63 - Okay, fine FEEL AROUND
Volume 64 - Exit Helper[/rant]

[rant=Baker of Shireton]Screenshot 2016-04-29 21.38.03.png[/rant]

Yeah, try to place code where you lay down the basic mechanic at the top.

This code works:[code]Desolate planet is a room.

A turtle is a kind of animal.
1 turtle is in Desolate planet.[/code]

The following code however, will give an error, since it first creates a single turtle, which causes Inform to deduct that the game only will contain a single turtle. So inform can’t handle it when we later defines turtles as ‘a kind of’, meaning that more than one can exist:

[code]Desolate planet is a room.

1 turtle is in Desolate planet.
A turtle is a kind of animal.[/code]

Also: the first time you mention something, you also defines how it should be refered to by inform:[code]Desolate planet is a room.

Some crocOdile is an animal.
The crocodile is in Desolate planet.
The crocodile is edible.
The crocodile can be hungry. The crocodile is hungry.[/code]The code works. However, the absolutely silly way we mentioned the crocodile at first will be taken by inform as some basic law on how the crocodile is to be refered to:

The hierachy is not all entirely flexible. Sure, it’s possible to let a Chapter follow a Volume, without any Books or Part inbetween. But this is limited. Let’s say you have two chapters:

Chapter - People Chapter - Dog

if you then decides that you want to rename ‘Chapter - People’ to ‘Part - People’, then ‘Chapter - Dog’ will automatically become a sub-chapter to that.

So I try to stick to a fairy rigid structure, creating sub-heading that are one step below the one above.

Volume is is the highest abstraction layer. I use them to slice the rest of my code into a few basic concepts:


Sometimes it makes sense to further seperate those into sub-categories with books:


I always let Volume titles be in UPPERCASE - it really helps making them stand out in the content panel. (Book may be uppercase too)

Then I create Parts, which I might further seperate into Chapters.

Section is something I solely use for making my code easier to understand when skimming it. (I adjust the content panels ‘Heading depth’ to hide the Sections.)

Something like this:

Volume - NOTES Book - changelog Book - to-do list Book - basic vision Book - research Book - brainstorm Volume - PREPERATION Book - memory boost Book - extensions Volume - STUFF Book - Things Book - People Book - Rooms Volume - WORLD Book - Homeworld Book - Kingdom of Matoriax Book - Underground Queendom Volume - FRONT MATTER Book - title Book - author Book - story headline Book - story description Book - banner text Book - help Volume - MECHANICS Book - Activites Book - Actions Book - Hacked standard rules Book - New rules Book - Scenes Volume - PUBLICATION section - release section - addendum

I’m still not entirely sure what code to place first, or how to group it. Should the Annoy Rabbit Rule be placed below the code with the rabbits, or in a dedicated Rules section?

I try to [comment] as much as possible. Having to describe what you do and why you do it helps getting a better overview. And sometime the comments come in handy later, too.

I don’t numbers the headings. Never saw the point of this.

I try to keep the sets of headings or subheadings at manageable numbers. If I had 24 volumes, I would loose the feel for them - they would become a list. But I can mange 7 volumes.

I use numbering extensively to help me remember where something is. The button to jump to where an error occurred works inconsistently in the Gnome IDE, so finding “Volume II … Book 1 … Chapter 4 … Section C” makes searching easier.

In general, I always try to place rules and special code before where it’s used in the source. Often this will work okay the other way around but I don’t like to chance it.

I number volumes/sections etc because I can turn on automatic numbering in preferences and it will update them automatically and numerically as I add stuff. You can also just use names “Volume - Let there be light” “Chapter - And then there were random giraffes”.

This is neat–there’s no right or wrong way to do things, but a detailed and relatively intuitive way does help a person say “hey, I think I’ll borrow that idea,” which is a big help.

Makes me want to write my own blog post.

volume rooms

book region

chapter room

section object

volume verbs

part nonstandard

part standard

part meta-verbs

volume tables / data

volume beta testing

(ease of testing commands)

volume testing - not for release

(test command, debug command, jump-ahead commands)

I also have two extra volumes, one for programmer testing, and one for beta testing.