For countless years I have attempted to write an interactive fiction game, and while I can usually create a few rooms, I always end up getting stuck and abandoning my projects. I feel like I’m trying to do too much at once, like creating rooms and putting items/puzzles/etc. in them at the same time. I’m wondering if I should approach one thing at a time (e.g. rooms first, then items, etc.?)
What are some of your thoughts? I’d love to hear them.
Speaking as a person who uses Inform, though this probably applies broadly.
A key for me is being aware of what I like doing most, and getting back to that periodically. I tend to enjoy figuring out technical problems, coming up with mechanics, and that sort of thing, so I always have a list of open issues that I can work on when I need to switch gears. For instance, if making rooms begins to drag, I’ll tinker with the scoring system for a bit, hopefully coming back refreshed.
I try to balance doing the “fun” parts with the rest of it, which hopefully keeps my momentum going.
As for my approach, I usually do things one room at a time, making the room, putting all of the things in it, and then writing custom action responses for the room. That way, I can set a clear goal or stopping point for the day, or a time for taking a break. I wouldn’t be surprised if there’s a lot of variety among different authors on this point. Having something contained like a room suits the way I organize my thoughts, so I usually measure progress that way.
I’m curious to see what others have to say!
Everyone’s process is going to be different, but I do a certain amount of pre-planning before I start—outlining plot, outlining puzzles, drawing maps—and if you’re getting overwhelmed by trying to create stuff all at once, it sounds like you might benefit from trying that.
I do also (in projects where this is relevant) tend to build out the whole map first and flesh it out later. Sometimes I don’t even fill in the room descriptions initially, I’m just getting the layout in place.
I can highly recommend a high-pressure situation where you have to write a whole game in five days with everyone watching, and you don’t have time to faff around or get discouraged 
Here’s some things that have helped for me:
This, I’ve found, is the key for my process. If I don’t have a plan in mind before I start, the scope will get bigger and bigger and I’ll never get around to the less-fun parts because I can always add to the more-fun parts instead.
It usually goes something like:
For me this is usually my planning document and TODO comments in my source code. I’ve tried to use issue trackers before, but for a single project, I find I accumulate so many little things to work on that filing them all officially becomes a hassle.
And going along with that…
My games usually have at least two files, one for the world and one for the mechanics, so that I can switch back and forth between them and avoid getting tired of any one thing.
And this is crucial! This is why I seldom release anything outside a comp. The deadline works wonders, and you get a bunch of feedback!
I’m currently working on an article that goes through my entire process for building a small game, and hopefully that will be out by the end of this month. Ryan Veeder has done something similar before.
How to guarantee that you’ll get stuck: get sucked down the rabbit hole of tool development. One of my WIPs is my entry for the 1995 IFComp…
I don’t know if this is a suggestion or more of a cautionary tale, but I don’t plan much of anything beforehand. In each of my three released games, I had an idea about systems/mechanics and another idea about themes. From there, I came up with the main character and what they “wanted” (a main dramatic question). A very loose idea about an ending came after.
This ties into two strategies, which may or may not be useful depending on personal style.
The first is that I test my games a lot and I test them often. What might seem like essential elements of my games often emerge from tester feedback. I think a lot of people would be surprised by how late features and content are added to my stuff. I spend a lot of time throughout the process talking to testers about their reactions and adapting along the way.
So one idea is to show things to people often, get new ideas, and push forward.
The second idea: there is a strategy in writing studies known as “discovery writing” or “writing for discovery.” The idea is that authors discover the text as they write it, and a primary satisfaction of discovery writing is the sense of improvisation and invention an author feels as they “find out” where the text is going. This is the way I write. I enjoy finding out what happens in my stories. I think it’s a bit like rock climbing.
This doesn’t work for everyone, but it suits my process of getting feedback, iterating, and getting more feedback.
I would like to push back a bit on the advice about deadlines. I can see how a certain amount of pressure would be motivating, if your problem is making excuses to yourself, so if it works for you, that’s great… but what you’re really doing is raising the psychological cost of failure. And sometimes you might end up having to pay that cost.
I wasn’t able to finish my entry for Spring Thing in time for Spring Thing. I tried really hard, I pushed myself harder than I should have, failed anyway, and the end result of the psychological fallout from that is I haven’t even opened it since I realized I wasn’t going to finish in time. As a productivity tool the deadline was a substantial net minus.
I agree with keeping a regular schedule, though. Making continued progress is more important than finishing by a certain date.
The only times I’ve ever succeeded in making complete games is when I have made game transcripts in pure text from start to finish before any coding took place. The transcripts only involved the main game thread, not any side stories or anything.
I wrote how I liked the game to play out and didn’t worry about implementation details until that transcript was finished. I only aimed for really short games for amusement and not that hard puzzles. That kept my focus for the actual story in one pass, and the implementation details in another pass. (You can always expand it afterwards if it doesn’t feel sufficient.)
There’s also a sense of “just freaking do it”. Just write and don’t worry too much about it because you can edit later. I’m currently in the middle of struggling with this, and it’s hard.
I liken it to going to the gym. I like having gone to the gym more than going to the gym. The gym is smelly and sweaty and we’re explicitly working on all the things I’m not good at. It’s tough. Depending on the week, my shoulders might be wrecked or my legs. But once I go, I feel proud of my efforts and energised to do better next week. I just gotta go and do the work.
Sometimes you sit down to work on your IF project and it’s daunting. The code is smelly and leaky, and IF is equal parts code and writing, and it’s tough to be good at both. Even a small scope game is a bunch of items, rooms, NPCs and getting them all working in concert is hard. But once you get something written, you can feel proud of your efforts turning mere ideas into something real people are playing. Maybe it doesn’t come out perfectly or even well, despite your best efforts, but you have an idea of how to improve in the next one. You just gotta sit down and write.
I’m currently struggling with this because it’s hard. I have ideas but I also have doubts. So I’m working on side things, or helping out with the IF archive. I’m doing things near IF but not quite managing to write IF. That’s okay for now because I’m keeping my interest and trying to roll my ideas around my head to hopefully smooth them out. And then one day, maybe even today, I’ll sit down with a cup of coffee and say, “Brett, you just gotta start.” And it’ll be hard and I’ll feel discouraged, but the more you do it, the better it gets.
There’s a push and pull between designing the parts of the game that truly interest and motivate you, versus arranging all the uninteresting infrastructure and connective tissue of the game. If you concentrate too much on the former, you’ll wind up facing a weeks-long slog of churning out room descriptions; if you concentrate too much on the latter, you’ll lose interest quickly.
Instead, I’ve found it’s useful to built up a core of the game and expand it from there. If you have a great puzzle, implement it with a few rooms and simple descriptions. Play around with it for a while, then move onto the next compelling piece. Link up the separate parts when you have the time to motivation, and start adding in descriptions and dialogue when you come up with something clever. Keep going, and eventually you’ll get something that you think can be released. (It can’t. It needs more testing.) If you’re stuck on designing something, murder your darling and remove it from the game; you can always put it in a future one. If you’re stuck on implementing something, ask here. There’s no trick to it beyond just making sure that you’re working at a pace that sustains your interest in the project.
I’ve written only one game, but I did it in a way that let me finish it, so maybe this is helpful:
Make the plot first. Some IF games are very plot-heavy; some are simpler “you found this cool treasure map and now are exploring …” kind of things. But make notes on the world, what happened before the game, and what should happen in it.
Make a map very early! And not just a rough pencil drawing, make something that looks nice and feels exciting to you. I found it super helpful to look at this and it was motivating to see as I completed rooms, expanding the coverage of the space.
Make at least one NPC (assuming you have any) early on. Getting to “write in their voice” helped me think through the setting more clearly and the tone.
Good luck!
Looking forward to reading your take, @Draconis !
For the projects that I’ve actually finished and published (which is only about five) the common thread was story first. When I’ve gone in the other direction (designing puzzles for a game that’s missing the story) I usually lose interest fairly quickly. For one of my games (Paintball Wizard) I had a map and aspects of the story written two years before I actually started serious coding. For my current WIP, I had an outline written two years before I started coding. I usually start by programming whatever I perceive will be the most difficult part of the game engine. Once I’m over that hurdle, the rest is just a lot of work. But if you have a story and characters you feel attached to, it’s really very motivating to watch the game grow and evolve around that.
I started a short story a year ago and got really far with a single plot thread to almost completion. Then I realized that I needed another motivation, so I decided to implement the story with a new engine called Rez. Then my game looked boring so I focused on a nice visual presentation. Then I felt the motivation waning again because I just had a lot of grunt work ahead of me, but I found out that IFComp is starting soon. Now I’m muscling through for that submission.
It’s amazing how hard it is to complete a story that you’re proud of. I feel like I’m over half way done mine, but I also say overly optimistic things to myself to avoid the soul crushing idea that there’s too much left to do and this hobby is like a second job. I’m preparing for…
Good luck on completing a game (any game). I feel your pain. I joined this forums 3 years ago and I still haven’t finished a proper game. I might not make the competition deadline, but I’ve come too far to stop now… and maybe that’s just how shit gets done in the IF world.
I would add in some advice, but I know I wouldn’t be able to follow it myself… I’ve been working for 3 years on one IF piece. Good luck though!
One possible option is to focus smaller projects. If you “can usually create a few rooms” before getting stuck, try creating something that only requires a couple rooms, bringing it to a relatively finished state, and releasing it. Then hopefully you’ll get the confidence boost from releasing something, some helpful feedback from others, and a finished project that you can reflect on and learn from, instead of just another abandoned project.
EDIT: I feel like I just produced a very AI-sounding paragraph, but I promise that I organically wrote two successive lists of three items, combined with a “not x but y” construction, for coincidental non-robot reasons.
My take on that is to use an iterative process, starting by doing it on paper:
At this point I tend to make “cards”, like small bits of paper representing items, locations, and I “play” the game on the table, taking notes of what makes sense or not, like rooms that don’t seem to fit logically, or items that maybe should be somewhere else, then “solve” the game on paper until victory.
At the very least that gives a “red thread” you can follow to solve the story.
From that point, I fluff things out, make the path a little bit less direct, add non relevant places but that makes sense in term of geography or feeling that you are in a credible place.
Then only I convert that to a program, starting by the core stuff so the game is playable from start to finish with only the important actions.
The only projects I’ve finished were ones that were completely or maybe 80% fully-scoped before starting. I know people hate making notes and outlines, and I’m one of them.
If you know the ending and the way there, your creation progress has more momentum than when you’re figuring it out as you go.
Also knowing where you want to end and how to get there means you probably have all your mechanics in mind from the start, and you’re not inventing something mid-code that throws the entire project for a loop.
It’s easier to create a working structural version of the game without the prose - write “TODO, TBD” with prose filler and then detail it later. Again, it’s easier to paint and furnish a house that has already been fully built than while it’s under construction.
A word of advice: setting deadlines/timetables don’t help much if english isn’t the coder’s mothertongue.
Best regards from Italy,
dott. Piergiorgio.