Idea to Implementation

I’ve been sitting on a particular interactive fiction work-in-progress for ten years. Ten years! Every so often I dust it off and add a little more, but I still haven’t finished the chore of converting it from Inform 6 to Inform 7.  And while hiding from this project, I went and released a different project that hinted at a sequel that I haven’t even started on, seven years later. Seven years!

Clearly I need a bit of help finishing some of the creative projects that I start. Even during the summer, when I kicked my Blender3D skills up a few notches, I never got the 8- or 4-hour blocks of uninterrupted time that I used to depend on in order to develop a complex project.

Anyway, IF designer and gaming maven Emily Short explains how her own creative efforts have developed. Here’s where her essay winds up:

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.