We covered the bare basics of creating parser-based Interactive Fiction in TADS 3 Lite and Inform 7 in the prior post. This time we’re going to dig a little deeper into planning and structure, and ways to keep your IF projects organized.

I’m a planner. The following is my personal process. It’s going to be a shorter than usual blog entry, focused more on design and logistics than technical elements.

Planning

Coming up with an entire game on the fly can backfire on you pretty hard. Game development is a series of design decisions, and you’ll be making them whether you realize it or not. It is better to make them intentionally before you spend time implementing code that you might have to delete later.

There are a lot of tools you can use to help you plan; I find Obsidian useful, but there are other solutions like Hacknplan or even just a long google dock. Use whatever you’re comfortable with.

At minimum you’ll need an idea. You might have an idea for a protagonist, or a cool location, neat puzzles, or a plot. Whatever you start with, you can work around to using it to develop the other elements.

A few days ago I came across a social media thread of historically interesting artifacts for use in tabletop roleplaying games. This reminded me of the earliest Adventure games, which were all treasure hunts… including Colossal Cave Adventure itself. I could make an elevated sort of treasure hunt game hearkening back to those originals. Developing this into the core of an idea, I come up with a general premise of a protagonist breaking into a rich weirdo’s survival bunker to liberate all the art and relics they’d hoarded over the years. This gives me the vital elements of a protagonist, goal, setting, and even hints at opposition, puzzles, and an antagonistic force.

Development

My next step is a bit of free brainstorm. I write down ideas that might be neat to include, or general directions the game might take. I try not to restrict myself here, but at the end I’ll want to trim the list of any items that are unfeasible based on the scope I’m working with.

My goal is to refine the concept I’ve had so that I have a clear path to implement it – any questions are answered so I don’t have to stop and come up with anything to fill in the blanks. It’s also important to make sure my enthusiasm levels remain high for the duration of the project.

The rich weirdo is a real weirdo. The survival bunker should be liminal and unsettling, and progressing through it should tell the tale of his descent into madness. I also decide this is a post-apocalyptic game – society has collapsed, the outside world is in environmental ruin. The puzzles don’t have to be the standard security systems we might escape, because the rich weirdo is – as we’ve said – a weirdo.

While the core gameplay is the treasure hunt, at the midpoint there will be a shift into survival horror. We discover something unsettling about the rich weirdo, find ourselves in terrible peril, and must try to escape what has become our tomb.

We can also at this point make a list of ideas for traps, props, locations, and characters we might need to develop.

Characters

Characters are not, generally, where Parser interactive fiction shines. Developing them to any degree of fidelity can be a lot of work. They can add a lot to a game, but each one we include increases development time by quite a bit.

One mandatory character is the player, and there’s a big choice to be made here. Do we want to give the player a blank slate as a window into the world we’re creating? Do we want to bake in an identity and attitude revealed through play? The former is definitely easier, but the latter allows us to color descriptions from the perspective of an actual person’s attitudes, and that can make *good writing *flow more naturally.

Our secondary characters can include recurring antagonists, characters-as-puzzles, NPC companions, sources of information, and incidental background color. Remember, all but the simplest characters will expand your scope, so try and limit yourself to the stark needs of your game.

We’re going with a largely blank-slate protagonist in the spirit of the early treasure-hunt games, but not one that speaks from a comfortable middle-class perspective – this is a survivor, hard-bitten, blaming rich weirdos for taking the world from humanity. Plenty of opportunity for colorful subtext and commentary on a fallen world.

As far as other characters go, we’re going to stick to two. First, the Rich Weirdo who will serve as an antagonist. Dangerous, amoral, and deranged even before the isolation of the bunker twisted them further. The dragon of this hoard.

Second, we can include another survivor living in the bunker – maybe a security guard, servant, or family member of the rich weirdo. They might be either a temporary ally or a secondary antagonist, depending on how the game goes. Or first one, then the other. They should be useful, but not someone the player should trust.

Plotting

Next we’re going to come up with some plot beats. In a parser-based game the player is going to have a good deal of control over the game’s pacing, but we can come up with “things that can happen” in response to the player’s actions. What triggers these events might be random chance, player interactions with game objects, or just the passage of time.

Think of these as your cool set-pieces and powerful dramatic moments. Identify what triggers them, what choices the player might have in terms of reacting to what’s happened, and what the state of the game is afterwards.

If you’re feeling literary you can even try to work in a three-act structure:

• Establish the protagonist’s goal in the intro
• Change things up at the first plot point, where something happens to change their understanding of the situation
• Give them a midpoint twist where the context changes in an even more stark manner
• A third plot point sets them up for the climax
• Said climax and the resolution that follows.

For our theoretical treasure hunt adventure, our intro will establish the post-apocalyptic setting and our protagonist’s identity as a survivor scavenging the wasteland. If we can make it interesting we’ll play out the discovery of the bunker and the puzzle of gaining access; if not we’ll cold-open inside the bunker.

Once inside we establish the goal of making away with as much treasure as possible, and the second act is our exploration of this space. We get some creepy foreshadowing, a lot of atmosphere, and points for finding treasure.

This leads up to the midpoint discovery: The bunker is not abandoned. We are being hunted. We see the antagonistic force directly, and have to hide, evade, and avoid the NPC hunting us. Meeting the other character – the untrustworthy survivor – can happen just before or after this.

The third plot point is a discovery of information or resources that allow us to go from evading the rich weirdo to setting up something that lets us defeat them and escape. We go from the defensive to offensive, set up our climax, and then ride out the resolution.

Mapping

The last stage in our planning is mapping. It’s going to start with a list of all the stuff you’ve come up and decided to keep so far. Necessary locations, puzzles, objects, etc. Objects need a place to be. Sometimes puzzle sequences require a few locations.

With that list in mind, break out the paper and start drawing. Map the game out. Indicate where objects and characters are. Graph paper can help, and remember – connections between rooms don’t have to be symmetrical, but if they don’t quite match up you should be doing that intentionally.

Once that’s done, you can start implementing the game, writing the code, refining your prose.

Project Organization

In TADS

TADS games are made up of multiple discrete text files from the get-go. If you look at the Project tab in the Workbench, you’ll see that in addition to the .t file you build the game in, it includes the system files and adv3Lite library files. You can, mostly, ignore these when you’re not digging into them to figure out how things work. You don’t need to add to them or modify them on an individual project level.

Keeping all your game data – your rooms, verbs, items, and NPCs – in one long text file gets unwieldy, however, and can make debugging a nightmare. Thankfully, splitting your source up isn’t difficult.

You can use whatever schema you like, but what I’ve found useful is creating individual source files for:

• Each major discrete location’s map. Forest.t, Castle.t, City.t.
• Verbs.t for any new actions I’ve added, and any that I’ve modified.
• Topics.t for abstracts and knowledge-based objects
• Individual source files for any NPCs of significant complexity… including the player, along with any agendas and conversation nodes.

Each will be added as a file under the Project>Add File to Project menu option in the workbench – or you can right click the project pane, or you can drag and drop from Windows Explorer.

You will want to open each source file with the #include macros for the system and library files to keep everything working

…but aside from that you can structure them how you like. Personally, I prefer to make heavy use of comments to keep things organized. These are lines following double-slashes // or multiple lines between /* and */.

For my map source files, I create headers for each location, followed by the Room itself and any items found in that location. From Keys - Wallet - Phone - Check:

My approach for NPCs is similar. I create a large heading for the NPC game object itself, sub headings for each actor state, headers for conversation topics, and finally for any objects the NPC possesses. It’ll make more sense once we’ve gone over NPCs.

One major benefit to this is that if you have a major bug, it’ll tell you which file the error is occurring in. That makes it a lot easier to figure out what the problem is.

In Inform 7

In Inform, you only have the one file. Its built-in method to keep things orderly borrows from printed media, giving you headings and subheadings. There are five levels of header: volume, book, part, chapter, and section. You don’t need to use all five, but they are hierarchical. Books fit inside of volumes, parts fit inside of books.

The major benefit, again, is that you are alerted to what heading an error occurs in. They are also used in the Index pane, allowing you to jump around your code with a click.

As with TADS, how exactly you use headings is up to you. You could use one section for setup (extension includes), one for new commands, one per map, and then a sub-section for each room in the map, one per NPC, and so forth.

Did this help? Do you have a different process that works for you? Let me know in the comments. If you feel moved to help support my work and this series, you can do so by donating to my patreon. I’ll be providing the source code of the games I’m making for my supporters.

Next time: Implementing Rooms.