My work on The Counsel in The Cave has been about understanding what the story is meant to be, and how to bring that story to life, just as much as it has been about writing and programming the story itself. When I started writing this summer, I thought I had an accurate idea of what the final piece would look like, and felt confident moving towards it. But since then, I’ve gone back to the drawing board multiple times. This would be discouraging, if I didn’t keep in mind that those explorations were valuable, even necessary steps towards my current understanding of the project, so much so that I hesitate even to call them mistakes.
A technique that’s been instrumental to my work on my most recent revision is one widely used in the games industry, and the field of software development in general. That’s prototyping. And I feel that this technique can be just as valuable in creative fields. Instead of approaching my project as a one defined product, massive and entirely known, that I could complete simply by chipping away at it little by little, it’s far more helpful to see my project as a process defined by problems.
For example, readers of my story felt they didn’t understand the characters well enough to play them in the opening scene. My job is to find solutions to such problems. However, in most instances, I can’t be certain the solutions I design will actually succeed in solving problems. Identifying those uncertainties as questions– for example, “Will providing a synopsis of the characters before the first scene begins help the reader play them, or will it read as awkwardly frontloaded exposition?”– allows solutions to be effectively evaluated with a prototype, the smallest possible piece of work that answers that question.
In this example, I wrote such a synopsis alongside my next scene. When I was finished, I could see that the synopsis was a necessary part of the player’s background information, and so I added it to my design.
Furthermore, since this was a critical part of the design, I designed other elements of the story to mitigate that sense of “awkwardly front loaded exposition,” the risk to my solution. I designed my story to appear as a script to a play, in which character synopses are often written to aid actors, and placed in the beginning of the script. You can see how problems, solutions, risks, and prototypes build on one another towards one work. In this way, game design is a series of decisions that reduce the ambiguity of a project until it is complete. I suspect that this philosophy may apply itself well to other creative fields as well.
In hindsight, approaching my creative work with this prototype-first process from the start might have saved me a lot of time and energy. Maybe I would have reached my current understanding of my story much sooner, and have had more time to improve it. But at the same time, I’m grateful that it took me the majority of my time to reach this point. First, because it forced me to better understand both this particular project, and my creative process as a whole. Secondly, it’s only left me four weeks to rebuild my story from the ground up, which has forced me to utilize the prototype approach I described. My final piece will be relatively small, but it will be focused and its design will be intentional. It will be a prototype of what I might imagine a larger work to be! Thinking of my final piece as a series of prototypes puts me in a great position to think about the future of my project beyond this summer.
You can see more of my design and prototyping process on my website here.