The process of writing IF

Every writer, and probably every programmer as well, has his or her own way of doing things, I’m sure. There are many aspects of actually going about the task of writing IF. Maybe some of them can only be learned by experience, but I think a discussion of the IF writing process could be useful for wannabe authors, such as myself.

One of the important practical decisions we have to make is whether to take notes about our vision for a game before beginning to write and code, and if so, how extensively. When I used to play at making text adventures with Inform and ADRIFT as a young teen, I rarely took any notes. If I did, the notes amounted to a scribbled, incomplete map that I never finished implementing. My 2005 Comp entry came out nearly spontaneously in a little under two months. At least partially on the advice of Mike Roberts in an article about the practical aspects of IF design that’s included in the TADS documentation, I decided to make extensive notes for what I intended to be my next project, after having failed to get very far in a few hopeful projects after throwing “Dreary Lands” together. Since June 2009, I’ve been occasionally jotting down notes, keeping them organized in a binder. I’m glad that I didn’t start coding when the initial concept came to me, because my plans have taken off in different directions. My basic basic idea and ultimate goal have remained the same, but my current vision is much more complicated and ambitious than my original thoughts.

I’m wondering if any authors who have had success in completing their WIPs have any tips about the execution of our ideas and notes. Several times, I felt like I was nearly ready to begin coding, but I don’t know where to start. This past December, I laid aside this WIP, on the top of my tremendous heap of forsaken ideas and wasted effort. A new story idea had come to me, and I thought it could make a good IF game. Frustrated with taking notes, I jumped right into coding.

In my experience, one of the difficulties of writing IF is introducing the plot. In both this latest project that I’m working on and the previous one for which I made all the notes, I now realize that I don’t know how to get the game into motion. This realization is what recently made me decide that I need to mostly rewrite my start to this new game (I’ll keep the two rooms), which isn’t going anywhere. Now I have an idea that would give another dimension to a game that I had abandoned at least a year ago, which was going to be built on the same premise as “Dreary Lands”, but completely redone. I know that I’ll never get anywhere if I keep jumping from idea to idea, but it’s really hard to stay focused on a project that seems to have a flat tire. :frowning:

Has anyone had success with the technique of writing a mock transcript before coding? I’m thinking of trying this approach for my current WIP.

Well, I’m sorry that this post was so self-serving. Most of my personal frustration is likely due to my laziness and indecisiveness, but I’m sure that some of it is common to the experience of trying to write interactive fiction. I’d be interested in any discussion. :slight_smile:

I can’t really comment on finishing IF, as I haven’t ;D. Emily Short has a good article at her site about various ways to go about implementing a game, from mock transcript to design document, etcetera, here: emshort.wordpress.com/2009/08/23 … mentation/.

One piece of advice that I think is good is to ‘start in the middle’. That is, don’t start a game by writing the beginning (a pitfall your game fell in it seems). By the time you get to the end it’s likely your beginning will be the weakest part of your game, both in terms of coding/technical skill, and in relation to what comes after as the game naturally develops. Since a strong beginning is critical, you could try putting this off until the game is well established.

Until people filter in and 'fess up, Emily Short had an excellent blog post on this in August:

emshort.wordpress.com/2009/08/23 … mentation/

I’ve gone about this a number of different ways, most recently with the design-stuff-on paper followed by a transcript.

For every game I’ve finished, I had ten ideas for games that never went anywhere.

An important part of it is settling on the right idea, something you care about, but also something with properly defined limits to it. If you start without knowing where you’re going to finish, you’ll probably struggle to ever get there, whereas if you at least know what your goal is, it doesn’t matter so much if the path there is fuzzy.

My usual process, after I’ve settled on an idea (which usually involves notes and prototypes) is to create the bare bones of the game - the locations and main interactions, and then flesh it out. With my last game I completed each scene in the order the player would encounter them, but I found that a bit arduous.

Obviously, once you’re a fair way into any creative project it becomes more difficult to keep working on it, but as long as you care about the idea, you’ll want to finish it to prevent all your work so far going to waste.

Well, the game that won the last IFComp was written in this fashion.

Thanks for the replies. :slight_smile: There’s some genuinely helpful and interesting information here. I haven’t finished reading Emily Short’s article yet, but it’s just the kind of analysis that I was looking for. Thanks for the pointer, Ron and George.

That’s a very interesting design philosophy that I had never even imagined. It may be very worthwhile. I’m always excited about the really interesting bits that I’m planning on implementing, but I never know how to advance to those parts. It may be a very good idea to code my favorite or most important parts first, and work backwards toward the less-important parts.

I think I understand what you’re saying, and I agree. If you keep changing you’re mind about what you want to accomplish, or about what you fundamentally want your game to be, then it’s highly unlikely that you’ll ever finish. Strangely, the only game that I ever “finished” – at least released – was done without much of a final goal besides creating a real text adventure that could be won. I don’t think I would have cared that much how it turned out, as long as I had something to enter the Competition with. Of course, that little game hardly disproves that you need to have a specific, unchanging goal in order to successfully complete most serious IF projects. I have very definite goals for my two most recent attempts, so I’m hopeful that I may be able to finish them one day.

I think this process may be very workable for those who can stick to it. With my latest (perhaps my current) WIP, I was trying to do this, more or less, except that I was working chronologically from the beginning to the end. However, when I don’t know what to do to make progress, I start working on the details that I had intended to save for later. That can be dangerous if anything needs to be changed, and it can cause burnout.

Good thoughts, everyone. :smiley: I can’t wait to finish reading Emily Short’s excellent exposition on the subject.

Of the different design philosophies listed in Emily Short’s blog article, the most effective ones appear to be those labelled “write the through-line first” and “transcript fully, then implement.” I’ve tried implementing right away several times, barely making progress, and I’ve also tried designing the game fully in written notes. This time, I’m going to try writing a full transcript to serve both as an outline of the entire game structure and as a rough-draft for my writing.