Author Astray

Preface
I recently finished my Masters degree in ‘Digital Games Theory and Practice’. While I found the Theory part far more enjoyable (the Practice section was far too similar to my day job working at Lionhead) I am still happy with most of the work I put into the Practice sections. One of these assignments was writing a ‘review’ or a ‘post-mortem’ of a previous assignment – a short design doc. While I think I may still use the design doc for a future project, the post-mortem itself has likely seen the totality of its use. However, after reading it my mother told me that she found it relevant for her own creative process independent of the design document itself. Now, I’m not sure a mother’s praise can be taken at face value, but I still thought the least I should do was to self-publish the post-mortem online. So, here it is.

Introduction
Creating the ‘Auto de Fé’ design document has been an interesting journey. It was meant to take only a couple of months to write, but the process was interrupted several times. On the one hand, these interruptions have broken my concentration and constricted my schedule. On the other hand, they have given me more time to reflect. Because these reflections came mid-project they had a direct effect on the results of the ‘Auto de Fé’ project. For this I am grateful. I do not think the game design would have been as good without this mid-project chance for reflection. This document is a brief sketch of the key thoughts I’ve had, how they changed what I was creating and what (I hope) I’ve learned.

Missing the Forest Fire for the Falling Tree
When I started work on ‘Auto de Fé’ I started with a blank slate. My intention was to use experimental prototyping to explore a unique set of game mechanics in order to invent a new genre. However, I quickly hit a snag; I found it difficult to work experimentally within the provided prototyping environment. My initial reaction was to fight against the constraint placed upon me; a fight which I would ultimately lose. While I don’t consider picking that particular fight to be a bad call on my part, my reaction to losing it was. I continued harassing the issue long after I knew that I was stuck with the tools provided. Worse, I didn’t adapt my work practice to the designated tool set. I kept trying to work in the way I would have given my tools of choice. Needless to say, I didn’t make much progress with either strategy. If it wasn’t for the sudden interruption of serious crunch on Fable III, I don’t know where I would have ended up.

The long break away from working on ‘Auto de Fé’ gave me perspective. When I returned, I saw my mistake. Continuing to attempt a programmer’s approach of experimental prototyping in a context in which I was unfamiliar was madness. With perspective, I was able to revaluate what I needed to be working on. This is the first important lesson I learned working on this project; when things stop working the way I ‘need’ them to, step back and reconsider where my ‘needs’ are coming from. If a change in the way I work enables me to continue forward progress, even if it means changing my vision, then such a change is a good idea.

Starting Out of Time
Unfortunately, crunch on Fable III took a lot longer than I expected it to. Just when I thought I had finished, I was given a new set of responsibilities. When I finally came back to ‘Auto de Fé’, while I had a fresh perspective on how not to proceed, I was also out of time. I knew that an experimental prototype wouldn’t be easy given my tools and my now tight schedule, but I still needed some form of prototype. I just didn’t know how to proceed. So I went back to the project requirements and realised that the prototype portion of the work was not necessarily the ‘core’ task.

Over the years I’ve worked on a variety of projects in my spare time. One thing I’ve found over and over again is that projects will often have hard problem and easy problems. When I focus on only the hard problems, I sometimes get stuck and unable to make further progress. On the other hand, if I focus on the easy problems, I can end up going in a direction that makes the hard problems harder. While I don’t think I know yet where the best middle ground lies, I came to a new realisation from reflecting on what I needed to do next. When pressed for time, solve the biggest problems first. In the case of ‘Auto de Fé’, the design document was the big problem – the prototypes were meant to support the document, not the other way around. So I put my prototyping problems to the side and focused on the design and writing.

An Imperfect Match
At its core, ‘Auto de Fé’ is the combination of two ideas; creating a serious world where standard platform mechanics make sense and telling a story about Columbus as a privateer before he became famous. Both are ideas I’ve had for a long time, but I’d never really considered them together. The ‘serious platform game’ was an idea looking for a story while ‘Columbus as a Privateer’ was a story with no mechanics. I decided to try to fit the two together.

At first, everything went well. I found interesting ways to make jumping around an environment approachable and 15th Century Spain proved to be an interesting source for conflicts far beyond Columbus and privateers. However, as I got into the writing, I found that I continuously had to justify the two ideas to each other. These two ideas, having grown in wonderful ways as I worked with them, weren’t working well together. I either needed to make them mesh together or to drop one of the ideas.

So I started playing with my two ideas from a number of different perspectives, seeing what was important about them. What I found was that from the perspective of the world, it wasn’t particularly important why I’d crafted it the way I had. It didn’t matter that the world was made up of winged amphibians in order to justify the platform mechanics. It didn’t matter that the world had strong influences taken from the true history of Spain. What mattered was the end result; a world of medieval anthropomorphic swamp creatures. I didn’t need to explain that amphibians were Jewish and reptiles Christian. The conflict remained without the explanation and the explanation got in the way of the end result. Taking the time to explain why the world was the way it was did not further the end goal – writing a quality game design document. The lesson here is simple. It doesn’t matter where an idea comes from. It only matters where it is going.

The Perfect Curse
I now had a clear idea of where I was going, and only several thousand more words to write in order to get there. But these words – they weren’t coming. I knew what I wanted to say, I just couldn’t find the right way to say it. And every start I made just seemed to make the final product worse. This led to low motivation, and low motivation led to low productivity. Not a good thing when I was already running short on time.

But this is a lesson I’ve been taught before. Maybe one day it will stick. Perfection is impossible. As soon as I begin judging my work while I work on it, I will find myriad flaws. Trying to fix these flaws on the go is always a mistake; I have no scope to see which problems are the big ones. It is better to finish first, flaws included, and then make incremental changes that approach my ideals. The lesson; done is better than perfect.

A Different Type of Prototype
At the same time as I was solving the problems involved with getting the document finished, I began to look back in the other direction. I needed to figure out what I wanted to do for the prototypes. A discussion I’d had several months before suddenly clicked for me. What the prototypes showed was more important than how exhaustively they showed it. They were not being created for me, but for another audience.

When I think of prototyping, I think of experimental prototypes. When creating a set of mechanics I am unfamiliar with, I like to ‘feel out’ the possibility space of those mechanics. I do this by writing a prototype in a programming language I am comfortable with and then playing with the results. I push the resulting game mechanics both in directions towards my initial set of inspirations, but also in whichever direction maximises fun.

But experimental prototypes are not the only type of prototype that can be made. Specifically, for the purposes of presenting a work to others, it is more important that a prototype communicates an idea than that it explores a set of mechanics. In both cases, the prototype is exploring unfamiliar territory. In both cases, the prototype is meant as a proof of concept. But changing the audience of the prototype fundamentally changes the nature of the prototype. With an experimental prototype, I am exploring territory unfamiliar to myself in order to discover which set of mechanics are the most fun; a disproof is as important as a proof. With a prototype meant for an external audience, I need to elucidate territory that is familiar to me, but unfamiliar to them. The purpose of this type of prototype is to prove to my audience that I know what I am talking about. A disproof will just make me look bad.

In the end, the prototypes I made for ‘Auto de Fé’ are somewhere between these two... but the realisation of this difference is perhaps one of the most important discoveries I made during this process. It shines new light on previous conversations I’ve had throughout my career in the games industry.

Conclusion
It is surprisingly difficult to make things, whether full games or just designs for games. But with each making, whether success or failure, I learn something new. While a failure is a definite lesson, it is those projects that I finish that I learn the most from. I need to finish more projects in order to learn, not only those projects that have a framework of external expectation. A finished project doesn’t need to be perfect, but it needs to be done. It doesn’t need to solve all the problems before me; finishing something is more important than being truly innovative. When I get stuck, I need to find ways to push through, whether by forgiving my imperfections, concentrating on the most important tasks first or by focusing on the end product rather than all my cool ideas. And lastly, I need to learn to communicate my ideas to others if I’m ever going to get their help.

This last one scares me the most; while I am very precise in what I say, precision isn’t always the best path to understanding. And the discipline of design is, far more than I would like, about getting other people to understand ideas. I suspect learning these communication skills will be my major focus for the next several years.