Writing IF: mechanics first, writing second or both at the same time?

This may have been visited before, but if there’s one thing that this forum seems to love it’s reigniting an old discussion, so:

When writing IF, do you prefer to deal with the bare mechanics first and then go back and fill in the descriptive parts later, or do the implementation and writing at the same time? I’ve tried both: the former let me get a working game up and running pretty quickly but left me with a load of writing to do at the end, which felt like a bit of a chore; the latter felt more thorough and left me with little more than tidying up to do at the end but it was slower and made it more difficult to maintain momentum (it felt like I’d never finish it). Just interested in other authors’ typical working methods.


Usually the pendulum swings back and forth. I tend to start with a cool title or mechanic or concept for a puzzle and then figure out a plot and story that implements it. I try to have the entire game planned out because that helps then with filling in with all the details, but during coding and experimentation with the game, often a new mechanic or solution will present itself that I never thought of (or testers keep wanting to try) and usually that’s a sign it needs to be added in.


I always do mechanics first, except for my Choicescript game (which was more or less contract-dictated).

I like the mechanic-skeleton because you get the whole gestalt experience each playthrough and it’s easy to replace things that don’t work. If you do writing first, you might have a pretty terrible section that you don’t want to delete because you spent so much time on it.

I 100% love writing by playing through over and over again (and testers doing that too) and tweaking things one at a time.


Yeah I mean the project at hand is really going to dictate this more or less. @mathbrush’s Magpie Takes the Train is clearly the kind of thing you’d want to nail down the exact mechanics off first, for the exact reasons they just outlined. Writing is the polish atop the experience and its just bad project management to do polish over potentially changing content.

Also depends what you mean by mechanics. My game has an augmented sense mechanic which I had before I started writing, but that’s very different than having all the puzzles. Implementing all your games puzzles basically leaves you with a skeleton upon which all your writing can rest. My sense system, if implemented first, still leaves you with a blank page. In the Magpie example, it’s more akin to starting with an outline.

I am trying to move toward a reliable process of themes and mechanics, outline, mechanic iteration, writing. The mechanics are usually suggested by the theme or they have a clear relationship, so I need them first, but then a comprehensive outline will suggest what I actually need from the mechanics to tell the story, which means I can iterate on both without having to wrestle with existing writing. Then it’s just filling it all in and, what iterations are suggested or required by the process are usually much smaller and easier to add.


Couple of questions here really.

When I’m designing, I start with the mechanics and then come up with events and story elements that fit the mechanics. Then I go back and forth until I have a full design.

When I’m implementing, if there’s a major mechanic that runs through the whole game, I implement that first. (E.g. in my Cragne Manor room, I started by implementing the rulebooks for the magic words and the moon.) But once that’s in hand, I start with the first room and implement that completely, text and code. Then I move forward through the story. I try to always have a game which is fully playable up to the current point.


What about graphics, if any?

I came up with an interesting idea for a mechanic that drew on real-life before having the story fleshed out, but that didn’t work out so well. Now I think I’ll go back to a story-driven puzzlefest.

1 Like

Thanks. There is some reassuring variation. I couldn’t base a game around a mechanic and work out the story later - I’d need to have the story first. But I expect that’s because I’m used to writing linear fiction and not at all used to writing (or really, playing) games. I am, however, a massive procrastinator - like pretty much all writers I know - and find it quite agreeable to spend an entire evening coding a drawer opening and closing properly, or something, as an alternative to getting any writing done.


Only if I have to and then, last of all.

My approach is pretty similar to this one, but minus the trying to have a fully playable game to point X.

Apart from planned vital ingredients for a whole game or level, I don’t know what will be in a room 'til I pretend to stand in it. So I write a description that’s erring on generous. Then I know I’ll have to implement all the stuff I described. Now I try and decide how much of that work will pay off in various dimensions, and I’m editing the description to match what I’m prepared to implement.

I like to implement A Lot, but I still acknowledge that I want to get my next game finished before I die, so this is kind of the battleground for me… Getting away with what writing I can without being trapped forever in implementation.

So I don’t have this problem:

because for me writing and implementation are joined at the hip. The only time I have this problem is in cut-scenes, where I’m always trying to cut, cut, cut more out.

On the other hand, I definitely do this:

because in the playing is the only time I can judge the flow of all the little bits and pieces against each other. A fine room desc., the reponse to some action and then some bit of dialogue may all have been written perfectly in isolation, but when they come one after the other, then I can edit them to get the dynamic of how they run together to be its most effective.



Yep. Definitely.

Thanks, all - these are helpful insights.


The visual novel I’ve excerpted for Spring Thing started out as a short story (I considered myself a writer long before I considered myself a creator of any sort of software). That, in my head, is the “canon path” through (though not necessarily the only, best or worst).

Next (well, after a diversion where I tried and failed to get it illustrated, and concluded this might work better as interactive fiction), I looked at it and decided on the most important themes and ideas I wanted to focus upon.

At this point, I split the IF into sections, because as a novice IF creator, I know I can’t expect to succeed if I try to do the whole thing in one lump. Making a minimally-viable game, and then iterating based on feedback, makes far more sense in my situation. I initially split it into five sections (two of which run in parallel), but later discovered I needed to split the first “arc” into two to get a minimally-viable game that was actually “minimally-viable” (the minimum unit of narrative fiction is the arc, and I spotted that my first section had two small arcs).

Since I’m a new IF creator, authoring-system “shopping”, and learning the basics of the system, followed.

Once I had a section, I looked at it and decided where the challenge points were, and how I’d express that. (This was also where I decided to go for a puzzleless, choice-led mechanic for the section. I could as easily have puzzles in a different section, if there was a situation there that made sense for them).

Next, I wrote the writing and logic. I preferred to do these at the same time, and I mostly did them sequentially. Sections where I did not necessarily intend to fill sequentially were commented with a special tag, so I remembered to fill them all in later. Only once that was done and tested did I start the next pass.

Each type of multimedia got its own pass. Playtesting started before I did the music one, though (and continues, even though the excerpt currently in playtest has been submitted to Spring Thing’s Back Garden).


Thanks for this detailed insight into your working process. I’ll be sure to check out your game.

1 Like