How do I make stuff?
the haphazard, circuitous process of Drew Cook.
Writing interactive fiction involves computer stuff. It also involves plain, old writing. I have some experience with writing. My graduate degree is in creative writing: poetry. I am a trained poet, if you can believe that!
It’s important to note that people experience creativity in different ways, and that this is a good thing! We get to experience all sorts of ideas and art because of difference. That being so, understand that I’m discussing my creative process here. I don’t intend to direct anyone or argue for my way as the best way. If something seems useful here, take it! If not, well, maybe you’ve learned more about me or Repeat the Ending.
Speaking of which: there will be mild spoilers for RTE, since that is the only game I’ve published so far.
As for Repeat the Ending: it began with three things.
1. an idea.
“Sure,” you might be thinking, “everything starts with an idea.” I think idea is an important signifier. I don’t mean “plot synopsis” or “comprehensive design.” I mean an idea. For me, an idea has enough play or wriggle room for me to remain flexible and make things up as I go. Some people like to have an entire storyline mapped out, but I find that limiting. Since my MFA is in poetry, I tend to write in small pieces that fit together. For me, a collection of poetry is modular. While there’s a relationship between the poems (I write a collection as a single project), I can focus on writing one thing at a time. Because of the way my IF works technically, there are a lot of ways to build a story via modules. For instance, a parser game has rooms. Rooms connect and relate to each other, while each remains its own, individual thing.
My goal in starting a project is to have enough of an idea to start writing. It doesn’t take much to start: a room description, a new action: anything more than nothing might be enough! My goal in writing from there is to cultivate a new idea for writing what’s next. I’ll get more specific later, but for now: my process requires a simple concept that is enough to start. I worry about later, well, later.
2. a way to tell the story.
Ok, so I have an idea. I need some sort of medium for telling it. It’s important to bear in mind that medium influences what we can write. If I’m writing in Inform 7, it has all kinds of stuff built into it for making rooms, putting things in rooms, and what not. But you may not care about any of that! Other languages (Twine, Dendry, Ren’Py, Dialog, and more) have their own strengths and challenges. I’m not here to recommend a language, but you will need one if you’re going to make IF. I recommend starting by looking at games that you might want to emulate, and then checking out the tools involved. I looked into Inform 7 because Inform came from an effort to reverse-engineer Infocom’s toolchain. That’s what I wanted initially: to make my own Infocom games.
As I’ve suggested, choosing Inform 7 meant that I would probably be telling a story in room-sized chunks. The player would inhabit a world of nouns, because that’s what Inform 7 is built to simulate. That basic framework needed to be able to accommodate my basic idea. Could I tell my story in terms of locations and objects? Platform is a decision that affects everything. With most systems, it will be very hard to separate the story from the technical framework that contains it. If all is working well, you probably won’t want to try. How should you choose a system? Start by finding games you love.
Sometimes somebody will say that this or that system is more sophisticated or that it’s for “real” programmers (and, by extension, others aren’t). Don’t be fooled by that gatekeeping bullshit. Every system out there has a high skill ceiling. Nobody’s smarter than anybody else just because they like one system more than another. Instead, consider the kind of game you wish to make. I love Inform 7, but it’s probably suboptimal if I don’t care about simulating a map filled with objects. Play games and research authors. See if there’s a community out there talking about platforms that interest you. I don’t know about you, but I need code advice, code samples, and supportive testers to be successful. Look for people making the kind of content that interests you. What tools are they using, and where are people discussing them?
A huge part of doing IF is having somewhere to hang out and share work.
3. be curious.
This is just as important as the other two. An advantage of starting with just a small idea is this: I can be curious about how the story will turn out. I haven’t written it yet, after all. This is very motivating to me: I like building a story as I build a game world. After all, Inform 7 relies heavily on environmental storytelling. Since I build the map one room at a time, I use that pace to build out the story. The essential ingredient is curiosity. How can geography and narrative fall into place? I approach creation as a series of challenging and rewarding problems to solve. More must follow, of course: the simulation of events, general rules governing the world, but all must serve the fiction they inhabit.
Technical problems can be just as motivating. This is why it’s important to find a system that interests you! I try to treat design as a kind of gameplay loop: solve narrative problems through technical development, and vice versa. I have to leave myself enough room to invent, or, barring that, to wing it.
if you have a core loop, you have a lot.
My initial idea for Repeat the Ending came from a traditional fiction project that I had abandoned. I had two basic, narrative ideas: a system of magic based on entropy and the orange-eyed woman. There was nothing else! No endings, no footnotes. There was not even the scene set in 1980.
However, in a fiddly-type video game gamey game, a core gameplay loop can drive narrative and mechanical design. In the case of Repeat the Ending, the entropic system of magic was fairly simple–there were three verbs involved–but the mere fact of having a system of play provided a framework for interaction in the game world. Players could look for magic, and they could experiment with it for laughs. The system might provide insight into character, or else be a mechanism for advancing the plot.
Graham Nelson calls this fabric of player world, perspective, and abilities as the “magic” of the game. If I’m designing an experience rooted in mechanical satisfaction, what is the magic of that experience? Entropy in Repeat the Ending is more than a gimmick; it’s part of the way the protagonists see the world.
The magic of your game can illuminate a path forward when you are stuck. In Repeat the Ending, a question was always, “Where can the player find and/or use entropic power?” This creates a loop, as the world must be built to answer such questions, and the story must be shaped around our constructions. With a solid design at hand, you have ways to not only shape problems but also to know the focus of the player. You know what they will be examining, experimenting with, and so forth. This gives you a strong sense of what details or hints to provide in descriptive text.
To be clear: games don’t have to have mechanical loops. A lot of my favorites don’t, but for games that require them, finding a new point in the loop can often lead you out of a rut.
test as soon as possible, and test often.
If you are building a loop, have players look at it as soon as possible. You don’t want to waste time building a game around a flawed concept. Seek feedback and refine your approach! Playtesting is another way to keep your project moving, as testers will comment on what is and is not working for them. While I was making Repeat the Ending, testing pushed me to try new things and improve the experience. Does the loop require too many steps? Refine it! Are there enough synonyms? Make more.
This has everything to do with writing. Loops are what trigger output, and output is the narrative. If the narrative is stuck, work on the loop. If the loop is stuck, work on the narrative. Testers will keep you moving in the right direction. I have many blind spots and assumptions about what puzzles are “easy,” for instance. I may take for granted that everyone will examine a bit of scenery with important environmental story telling. Find out!
Then go back and do it again. Don’t work in a vacuum if you don’t have to.
what do I do when I’m stuck?
If work is stalled, I try to think small. Usually, the focus is on some technical task. Since programming and narrative must work together, perhaps there is some little bit of code I could work on. There might be some ambient text that prints from time to time. How do I set that up? What would the text be? If I write a few sentences, that serves to develop the mood of the game. Developing the mood is writing, and important writing at that.
I might revisit some printed text, be it from a description, an event, or something else. Does it fit with what I’m trying to do? Revising it might open doors for me. Does the map make sense? Or, if I’m using story nodes, do they make sense? Is there something I could add? I get out of stuck states by finding something small to fiddle with, in hopes than an idea gets knocked loose. It usually does.
In Repeat the Ending, I changed the narrative perspective at least three times. I think I made the right choice in the end (mix of first person singular, first person plural, and second person singular), but I got there by revising and improving passages to see what was working. This wasn’t just a mechanical exercise! It was a way to evaluate my work for consistency, improve the text, and find new avenues for writing the text of the game.
When stuck: I playtest and revise. I think small. I’m no good at figuring everything out all at once, so I very rarely try.
bringing it together.
Still, sooner or later, things need to come together. I knew Repeat the Ending would end in the hospital fairly early, but I didn’t know what would happen there until I was writing that final area (parking lot, roof, room). By then, D’s character was thoroughly developed. I’d built that character, thing by thing and room by room, over a period of months. Everything was so well-defined at that point that the ending was inevitable. I didn’t choose it. It was only what it could have been. This is why I don’t like to commit too soon: I see all of my little choices as leading somewhere, even if I don’t initially know where.
Still, I did have the hospital. I did know where D was heading. I figured out the route there and wrote that in steps. D is like a weird superhero. What heroic things could he do in the trailer park? What could stop him from leaving? These are small but interesting things to work out. What could be happening at Lakeshore Drive? And so on. I knew that this was a trip, that the medication was needed, and I solved small problems with code and narrative. D, who is narrating the game, said a ton of stuff about mental illness, about childhood. If I did things right, The players and I know who he is by the time he reaches the hospital parking lot.
Because of all that came before, I knew what kind of person he was and how he would experience the end of his journey. When it was time to write it, I was ready.
In short: I had a goal, but the shape of that goal was molded by what I had already written. I left myself room to improvise, to wing it. I approach writing as discovery and play. Even with difficult subject matter, I think there is a joy in creating. I feel this, and it drives me.
what else?
This is just a start. Next time, I’ll write about my specific process for building rooms and objects in Inform 7 (though I’m sure some of it will apply broadly). See you then!

Leave a comment