One of the most tricky aspects of amateur game development is just working out what workflow you’re going to use to get from point A, your germ of a premise, to point B, the finished game you can release. (This is not always as much of a solved problem in commercial game development as one might expect, either, but a commercial project tends to have some people with prior experience shaping a game who have a plan — whether or not it’s a good plan — about what needs to happen in what order.)
Lately I’ve adopted a new approach to this, and it’s made me look back on how I’ve done such things in the past, and the whole gory evolution (which is probably not over yet) of my implementation strategy.
Implement first! Design later!: You open up your IF tool of choice and you just go. Implement a room or two, some stuff to go in it, maybe a character. Write whatever comes into your head, then seek out the connections that come out of it.
In my experience, it’s really hard to finish this kind of game. I’ve started lots this way, especially when I was new to IF writing, and that was all useful experience because it familiarized me with my tools and was a kind of play. But sooner or later you hit a wall where you realize that your doodlings aren’t going anywhere and you have no particular end in mind; or you do, but there’s not a coherent plot, the backstory doesn’t work consistently, the pacing is off. No design intentionality has gone into the project, and sooner or later that becomes obviously a problem. At that point you can either ditch the project and start a new one, or step back and do some intentional design work on the project, then come back to implementing.
There’s a real risk, though, that if you’re alternating implementation with incremental design you’ll let yourself consistently avoid the really difficult pieces. “Ending goes here.” “Something interesting happens, I’m not sure what, and the player winds up at Alpha Centauri.” “A coding miracle occurs because I have no idea how to do this.” You may not even realize that you’re doing it… until sooner or later you realize that thing is just not getting done. And isn’t ever going to.
Prototype the hard part (usually a game mechanic) first: you figure out the most important/difficult simulation elements in your intended game and code those, working on them until they succeed; then work out the puzzles that go with it and build up a game from those.
I fell into this approach accidentally when Implementing First ran out of steam. I was working on a huge sandbox game, my first real IF project of any scope, that involved a detailed implementation of cutting and burning; a polaroid camera that recorded object states accurately including that of things that had been cut and burnt; smoke that smudged things; mixable liquids and varying light levels; goal-seeking conversational NPCs who responded not only to discussion but also to a large number of gestures and to observing when (e.g.) the player destroyed important objects in their presence. (Ten years later I think I might finally know enough to be able to code that game. Alas, I no longer want to. The gameplay concept was a total mess.)
It was too hard to prototype the conversation system and the materials modeling system in the big game, so I went away and wrote little lab-test game versions of them, where I developed the system first and then implemented some stuff with it. The first of those lab-test games became Galatea, the second Metamorphoses. For a while I told myself that I was going to go back to the big game later, but I couldn’t help observing that, unlike my original approach, this one was actually producing things I could release. I decided to keep that “Implement First!” approach as a form of brainstorming — I do still sometimes mock up a few rooms as a way of getting rolling envisioning a new setting or establishing a mood or PC voice — but not rely on it as my main methodology.
The thing was, though, that prototype-hard-stuff-first was still producing a lot of time-wasting. Metamorphoses was originally a much, much bigger game and then had to be ruthlessly cut down to reach its final size — entailing a lot of discarded code and design. I decided I needed a more top-down approach.
Fully design on paper, then implement: You sit down in a coffee shop with a notebook and you write down everything you need to know for your game. Maps and puzzle diagrams, if it’s that kind of game; plot plan and lists of scenes, if it’s that kind of game. Character bibles, historical timelines, setting research, if it’s that kind of game. (It may be all of these at once.) Then you code, checking things off on your plan as you go until they’re all done.
This is pretty much how I did Savoir-Faire. The setting came out of some freeform brainstorming sessions with Inform, and I did prototype the magic system first; but then I sat down and made a list of puzzles, arranged them into a big chart, and implemented the chart. This was hugely satisfying as a process because it produced a sense of forward movement. I knew I was making progress and I had a pretty good idea of when I was going to be done. I tweaked the design as I worked, a little — there were a few puzzles I decided were too arbitrary and threw out, and in response to tester feedback I extended the early game to contain some easier puzzles because it was generally thought to be too hard to get into.
I’ve never had that approach work quite as well again since, though. Generally the failure is down to one of three things:
Lack of self-discipline in the planning phase. I let myself get away with making a chart that still had some fuzzy bits in it, some magic I meant to tackle “later”, and of course later those things proved intractable, just as much as when I tried to implement with no written plan at all. A particularly seductive thing is to do a classic three-act structure and only design the opening and the midgame, leaving the endgame for “later”. Reasons this is terrible: it sucks to have 2/3 of a game completely implemented and be staring at the prospect of not being able to finish it after all; and then sometimes you can finish it, but your solution for the endgame is bodged together and lame compared with the opening and midgame, which is sad when you (and your players) were hoping for a strong finish.
Disproportion of effort, skill, or other resources. It’s very likely that you’ll wind up working really hard on the first stages of the game and getting them into good shape, maybe having them alpha tested before you’ve started the endgame. Even if you have the end fully plotted, you may find that you’re running out of energy, time before a competition deadline, and/or beta-tester attention by the time you get to it. Or, on the other hand, your skills may have changed substantially by the time you get to writing the endgame with the result that the end is actually much better than the opening — but not that many people actually get to it because they were put off by the ineffective start. I’ve played games of both kinds, and written several of the first type. (I’m not sure any of my games finish stronger than they start.)
Slightly different problem, but along the same lines: Savoir-Faire was running out of storage space in the game file by the time I wrote the last puzzles, which is a reason why they may feel oddly spare compared with the rest of the thing.
Overambition. You write a big chart, and it looks cool, but as you code you realize that it’s much, much too big and your energy and interest aren’t going to hold out that long. You can perhaps salvage by attacking the design and cutting it down to something manageable — I’ve done that many times — but there’s still a bunch of lost effort in the process, things you coded and can’t use, puzzles you worked on and have to ditch. This hurts most if you’re ripping out bits that you really liked. Earlier drafts of Floatpoint were both more puzzly and more comic, because I wanted to emphasize how much the protagonist was out of his element by having him struggle farcically with native customs and machinery. I had several bits on this that amused me a lot. But they had to go in the end because they made the game too slow to write and too long for the competition, and because they distracted from the real thematic points of the piece. I was pretty sad about taking them out. If you can’t bring yourself to make those cuts, though, the project may stall out entirely.
So now I’ve gone to:
Write the through-line first: come up with your setting and any prototype coding you need to do, and maybe make a list of puzzles/elements that you’d like to see in the finished game. Then create a simple outline design of the game and implement it so that you have something you can play (even if very quickly) from a beginning to the end, and which contains the most critical turning points of the plot. With that skeleton in place, consider what you like and dislike about the structure; you complicate the game incrementally, fleshing pieces out with new puzzles or improving on the simple puzzles/conversations that you used to start with. You may be drawing on the list of puzzles or situations you’d had in mind to start with, but you don’t have to commit to a whole structure at the outset.
What’s great about this: by the end of the first week or so you have a complete playable game. It is always in some sense “finished” — oh, not in a state you’d want to release, certainly, but it has a clear enough shape that there’s not a horrible anxiety-producing mystery about what will go in any part of it. The ending gets as much attention as the introduction, and isn’t likely to be fundamentally different in style, theme, or implementation quality.
At the same time, you’ve got a process with a lot of flexibility, because you can add new elements to address design flaws you see. Too steep a learning curve? Fine; add a few more intermediate puzzles to the opening of the game. Not enough motivation for a major NPC? Add another conversation scene that sheds some unexpected light on her background. (A weird thing about IF: it’s generally easier to add stuff than to take it out. If you’ve implemented a major feature or a complex puzzle it may have implications here and there throughout the whole code. Editing it back out is like kudzu eradication and may leave you with bugs.)
Finally, this process offers the best odds for return on investment. At any given phase of development you’ll have something that you could stop, beta-test, polish, and release. Doing that early might produce a bite-sized mini-game with little story complexity; doing it late might produce a 15-hour masterwork; but the process of getting from what you have to a game you can release is always clear.
This is the method I stumbled into with Bronze, largely because that was a Speed-IF I decided to flesh out into a full game. I’ve come back to it for another WIP I was having trouble with, and I’m finding it very liberating.
I’ll probably find things wrong with that, too. But it’s working for me better than any of my previous approaches to date, so right now, that’s where I am. Writing the through-line first.
There’s another possibility I should mention:
Transcript fully, then implement: You sit down with a text editor and you write the transcript of your player’s perfect experience. Then you implement that.
I’m throwing this in here as an alternative because though I’ve never done this with a full game, it sounds like a viable process. J. Robinson Wheeler has used it; he talks about the process in some detail in his Make IF Fast article (now missing from its original location but available via Internet Archive here), and Stephen Bond writes about applying this approach to The Cabal. A real strength of this approach is that it encourages the author to think like a player: to write in the hints and subtle cues in the output that provoke exploration, to create a strong sense of pace. I don’t think it’s coincidental (a) that Wheeler is a sometime independent filmmaker familiar with writing screenplays and turning them into a finished form; and (b) that the games he describes writing this way are among the most cinematic and smoothly forward-moving I’ve encountered.