Rudolf
The Writing Game - "Of Pants and Outlines"
Part 1
Coyote Evolution - Neopolis Game
Writers often ask each other if they carefully outline their work, or if they fly by the seat of their pants. (Brits, stop giggling in the back)
In other words, do you pre-plan your work (outlines, treatments, characters arcs, spreadsheets etc.), or do you dive in and work it out as you go along? (Just write and the chips will fall as they may!)
The question comes up especially in relation to longform work, like novels or screenplays, which is understandable as those take a lot of time and effort to create. So, ideally, you try not to waste too much of it.
There are proponents and opponents with each style*, each offering interesting arguments why they work the way they work.
The Writer’s POV
Pantsers say things like:
“Meticulous outlines kill all the joy in the process. It stifles creativity, and hems writers in, right from the start, and produces stiff, unimaginative work. Besides, inspiration doesn’t work this way. You can’t generate your best ideas on command at the start of the process and put them in a neat and handy package - all ready to go - and then, voila: you write your book!** The writing process needs to be much more organic, allowing you to discover things in the heat of creation. Besides, the book will change in later drafts anyway.”
I think there’s a lot to that.
Outliners say things like:
“If you don’t plan things out, you will write yourself into a corner. Your plot will be illogical. Your characters will find themselves in situations that break the story. You will have to cut big parts of the work because of it, wasting lots of time. Your structure will be a mess. And you will do a bad job making sure your themes are supported by your plot. How can you know what to write, if you don’t plan it out first?”
I think there’s a lot to that too.
I’ve pitched my tent in both camps in my own work, in games as well as writing, with sometimes hilarious results.
Birds of Paradise
When I wrote my first novel Birds of Paradise (out now!), I jumped in, knowing very little about where I would end. I had a specific theme in mind as a starting point, and a few fairly general ambitions for the novel:
It was to be my ode to classical scifi; epic in scope with cyberpunk elements, featuring a strong female lead and involving themes of parenthood. Other than that, I just wanted to write. I figured, being new to novels, that my lack of experience meant I had to learn on the job anyway.
In other words; I was a pantser, and I ran into pantser problems.
- realised that I hadn’t worked out my characters enough.
- lost track of many plot threads.
- didn’t find the right ending for a long time.
- had to cut a lot of scenes.
- had no idea of the final scope, so the book became BIG.
- had to write many, many drafts before I really understood what the novel’s strengths and weaknesses were.
- constantly doubted myself, making me feel like I was wasting my time (that was the hardest part of being a pantser).
- Had to grind on and on doing tedious cleanup up jobs and little fixes.
- I discovered that my characters could decide to do amazing things, seemingly out of my control.
- When things clicked it was sheer joy to write creatively.
- I found moments of magic that were impossible to plan beforehand, and ran with them, changing the story for the better.
- I always felt I wanted to write (at least during the initial drafts), as each writing session was an adventure, full of excitement and discovery.
- Some examples:
- My characters were disobedient. Instead of nicely following my guidance on what to do and how to feel. They made it known that they had their own priorities and interests. Who was I to tell them how to behave?
- This automatically changed my plot and pacing. A middle section of the book that was meant to be fairly brief became completely central to the emotional truth of the story and kept my main character there much longer than anticipated.
- I felt constant tension and pressure, in trying to adhere to my roadmap.
- As I progressed I realised that I was secretly writing a different book than the one I had planned. Many of the original themes were there, but actually as part of a bigger, overarching theme. This was completely unexpected, and meant I had to change tack in various ways, re-planning how to support this newfound core aspect of the book.
- But, being an outliner also yielded significant benefits:
- Generally, I felt in control and focused.
- There was very little wastage.
- My planned structure worked perfectly.
- I achieved most of my original goals for the book.
- I knew what goals I was writing towards, which was enormously helpful.
- I got to know my characters early on.
- In early stages of development:
- Dungeon Crawler: Enemies don't need perfect AI, art, animations, etc., but have to perform just well enough to test representative enemy v player scenarios, which is core to the game.
- Action RPG: Level Progression System: Simple Experience Point counter will do for now, allowing characters to level up and unlock certain new abilities that fans have been clamouring for.
- First Person Shooter: Levels can use generic layout types, to create a reasonable environment for testing an innovative aiming system. A tunnel here, a t-junction there, an arena style room, and so on, all with placeholder art. Slot it in, does it work? Yes?: Keep in place FOR NOW. No? Junk it, slot in something else. Quick iterations!
- Platform game: SFX and music can be off-the -shelf, placeholder, and just perform the basic gameplay related function. Jumping sounds. Collecting pickups. Weapon impacts. Atmospheric stings… whatever is needed to get crucial information across to the player, in service of a new teleportation mechanic. There is no need yet to tune the audio to a specific style.
- * Yes, I know that most people don't fall neatly into a single camp, but… generally they visit one more than the other.
- ** Blake Snyder probably disagrees
- *** In my book on level design I devote time to “object oriented level design” which also uses a similar approach
- **** There is no point trying to be absolutist about it. Just see where it makes sense.
- ***** The big caveat here is of course that in most cases some decisions will have to be made beforehand, due to genre conventions, target audience, game device capabilities, available budget, and so on. But that is hardly surprising.
Fox and Flower
My second novel (Fox and Flower ) was very different. It is a historical novel set in 1630s Japan, featuring a teenage girl and an older female warrior, travelling together on a quest.
Faced with a project that presented some obvious inherent writing challenges (what was I thinking?!), and still hurting from the countless extra drafts and rewrites and cleanup required for the previous novel, I decided to do a LOT of prep work. I had become an outliner!
I did a lot of research, planned out my story beats carefully, wrote detailed biographies for my characters, made sure I worked sensibly towards my planned ending, and had a clear idea of plot, scope and theme.
Unsurprisingly, I ran into outliner problems.
Looking at my experiences with both approaches, I was left with a conundrum. I had to accept that outliners and pantsers both faced significant problems, and that it wasn't straightforward which approach suited me best. So what to do next?
Pondering this impasse, I wondered if some answers could be found in my game dev work. (After nearly 25 years in the games industry I must have picked up some useful tidbits of transferable knowledge, right?)
The Game Developer's POV
Like writers, game developers have similar discussions on this subject:
Do you design the game upfront, or game-jam towards the fun?
Generally - solo indie dev aside - making games is a more collaborative discipline than writing, but still, the same tensions occur; Preplanned super-detailed system and game designs, vs a loose prototyping and game-jam environment.
Upfront Designers say things like:
You should design upfront to see if the systems can even work. That way you catch problems early on, before mistakes and dead ends become too expensive. You have to provide a detailed system design, with actual specs, to communicate what the project is supposed to be. You have to plan production carefully, to keep it under control. How else will the developers know what to focus on?
Yep, all sounds very sensible.
Jammers say things like:
Making games is a creative process. The fun factor can't be predicted like that. It's all just words on paper and assumptions. Designs always change anyway. You have to find the fun by experimenting, trying out mechanics, testing ideas, and so on, to arrive at something that is genuinely worthwhile and fresh, and not a stale cookie cutter game.
There is much truth in that.
Oh dear... as with the pantsers vs outliners, both sides seem to make a lot of good arguments, which, if I left it to that rather obvious statement, would make a rather wishy-washy article.
What to do then? Is there a way to make both approaches work? Unsurprisingly, I think there is!
A Practical Approach: "Modular" Development
One of the concepts I was taught early in my games career is that of modular development.*** This is the simple-but-powerful idea that you develop your game, where possible****, using placeholder assets and systems that can be easily swapped in and out during development.
For this to work, developers must break down their game into modular components, and only give the components as much detail as is needed for the current phase of development. The exact amount of detail per component can differ wildly, ranging from very low to very high, but is always governed by the current needs of the process.
Where possible you don't settle on final, shippable detail, until key components of the game's development are settled, and there is confidence it will stay this way.
This can be done with entire systems (like enemy AI) or with specific assets (like a game's gun models). It is crucial to understand that a component's required level of detail differs from project to project, but the principle applies equally.
Other factors, like genre and business context, can dictate early detail requirements in some areas. but not others. What matters is that at the start of the project, you only add the detail that is needed at that stage, and no more.
Here are some generic genre/component examples to illustrate that point:
So the idea is to keep everything fast and loose where possible, but still provide enough meaningful progress to advance the game as a whole. I'd like to note again that this can include systems as well as assets. *****
What is so good about this approach is that it accommodates upfront designers and jammers equally!
Upfronters get to design general but important systems at the start, without getting lost in excessive system detail across the board. They formulate the plan beforehand, make sure the key parts connect and interact with logic (catching problems nice and early (especially in core components) before committing expensive resources), and provide team members (or solo devs) with a sensible roadmap. Detail gets added only when needed and appropriate. Wastage and feature creep is minimised.
Jammers get the freedom to find the fun, iterate, experiment and discover unexpected qualities. They get to execute the plan without fear, because components are easily changed and replaced. This also means that when they do find the fun, they can maximise on it by adapting the, still loose, other modular components to take advantage of it. Flexibility and spontaneity is maintained, and comes at minimal cost.
This modular development philosophy, if embraced, can make for rapid but meaningful development, agile processes that allow experimentation with minimal wastage. It respects planning and organic development equally, and is entirely scalable.
Sounds grand! For games! What about writing?
A Modular Approach to Writing
The beauty of this approach is that it also works for (longform) writing. I'm using it right now on my third novel, and have used it on other writing projects too.
I have recently developed a formalised, structured process for this, to make it easy to track my own projects, and also to illustrate how it works to others.
In Part 2 of this article, (the conclusion) I will show how to use the modular writing approach on your own projects, by applying it step by step to an informative use case. Add some basic diagrams and flowcharts, and it should be easy to adapt it to your own needs.
Hope to see you there.