I had the privilege of participating in the AI Summit at GDC 2010, which also bought me an All Access pass to the rest of the conference. I went to some of the other AI sessions — all very interesting, though many of them focused on aspects of game design that have little to do with interactive fiction — but I also hit a number of other tracks, taking in panels on independent and serious games, on art and design and writing. Especially writing.
I went to a writers’ round table session run by Richard Dansky, and lectures/panels given by Dansky, Susan O’Connor, and Marianne Krawcyzk; and I chatted informally with several people going that route professionally.
Several things in the writing track resonated with me as being potentially useful to revisit here for IF authors. In all the talk about work practices, there was a certain brutal pragmatism: the perfect is the enemy of the finished; projects have to end sometime; it’s better to write down something mediocre than to write down nothing. You can revise later.
One of my most popular posts (judging by my site stats, anyway) is the one where I talk about ways to get from idea to implementation on a project. But there is more to that process than planning. I find that even in my hobby work, I’ve moved toward treating my game writing like a job — and that sometimes means taking on both the role of writer and the role of the lead designer, creative director, or other project lead, and consciously managing myself.
Here’s what that tends to mean, for me:
1. Have a deadline in mind. Moreover, have a schedule for how each piece of the project is going to fit into that time allotment, so you have a reality check to come back to when you realize you just spent a week on font coloring in the status bar and you were supposed to be done with the midgame puzzles by now. A timeline makes you pick your battles, which is not such a bad thing.
City of Secrets is the game that made me realize the importance of this — I was determined to do justice to everything about that game, with the result that the project ran hugely over its planned duration and is sprawling and underdirected in conception.
There’s a certain weird glory about devoting yourself to a project to the point of stupidity, losing sight of the rest of your life. This plays into the mythos of the solitary artist. But that’s not a sustainable approach, and it doesn’t guarantee great art (as CoS, alas, also demonstrates). There is no such thing as uncompromised art. The blurry-but-glorious Vision of what one’s game will be is not something that can exist in the real world. Creation is a process of compromising with reality. A schedule helps you do that more systematically and thoughtfully. You can always change it if you must.
If you’re not sufficiently experienced to plan differently with some confidence, put your “first beta” deadline around half-way to the release deadline. There will be more bugs and changes than you expect. Then write the game you’re going to be able to afford to implement.
2. Brainstorm freely, when working on a concept. Sounds obvious, yeah, but some novices I’ve worked with are too self-critical at the concept stage and aren’t willing to write down ideas they think are sub-par. Stuck on a puzzle or a plot concept? Have you actually made yourself sit down and fill a few pages with harebrained ideas?
Yes, it’s possible to get stuck and stay there for a while even if you’re doing the work to get un-stuck, but often the mundane exercise is more effective than you’d expect.
Related to which:
3. Don’t be afraid to type a mediocre sentence. This gets back to the advice I heard so much at GDC. If you can’t think of something brilliant for a particular spot, write something non-brilliant and come back to it later.
This isn’t just a matter of compromise, for all that I’ve just been arguing for compromise. I often can’t write the better version of something until I’ve written the worse one. Maybe not everyone works the same way, but for me writing is an iterative process.
Besides, often by the time I come back to a piece of sub-par dialogue, I’ve written enough of the rest of the game that I have a much better sense of the characterization or tone that dialogue needs to convey.
4. Give yourself specific feedback. One of my most successful project experiences was with writing Bronze. I knew from the outset that I was going to release the game’s code and some “making of” material, so I kept design notes as I went along about what I was changing and why. What I didn’t anticipate was that the act of making the design notes vastly sped up the process of improvement. Having to write down what I thought was wrong with the game at each step made it much easier to develop solutions.
(If you’re not good at giving game writing/design feedback in general, reviewing other people’s games can actually be a big help. It’s often easier to figure out why someone else’s game doesn’t work than why yours doesn’t, but the practice does carry over to your own stuff.)
To boil all that down to something pithier: work as though you’re getting paid to work. Don’t let yourself be inactive, even if you’re stuck — getting unstuck is more often about effort than it is about a visit from the Muse of Interaction. Don’t get side-tracked from the core set of things your project requires. Do be self-critical, but apply that self-criticism as part of an iterative process of improvement.