Proper Preproduction Planning Provides Positive Performance

With Capuchin Capers essentially wrapped up, planning for our next game can commence. Through the last two projects, I have tried to formulate a plan in some way. In Odin’s Eye, I did some level planning, storyboarding, and concept art. But it wasn’t nearly enough, and the project was much harder as a result. For Capuchin Capers I decided that more planning needed to be done before the majority of work was started. But, much like Odin’s Eye, not enough preproduction planning was done and there were points when the project suffered as a result. As I may have mentioned in a previous post, the cinematic storyboarding should have been done long before any character modeling was started. Because I didn’t do that, Suzy’s bone structure didn’t support some of the movement I wanted in the final cinematic shown to the player when they win Capuchin Capers. I made it work, but it was far more difficult than it should have been. Proper preproduction planning would have prevented that.

For our next game, At the Crossroads, we are working to do much more preproduction planning before the first line of code for the game is written or the first polygon is created in Blender. We have some concept art already generated for the creatures in the game, with more to be created and added to the game design document. I can’t stress to you how much easier it will be to create this game once we have everything planned out ahead of time. We’ll know exactly what animations, assets, code, textures, and so on that we will need before we start. Code development in particular is going to be considerably more clean and tight as a result.

An added bonus to a well-made game design document is the feel of legitimacy that it conveys when you are looking at it. If laid out properly, with a nice selection of fonts for the main body of text as well as fonts and backgrounds for the title and headers, it gives a feel to the project that starts everything off on the right foot. The text styles created in the design document can also be used for the instruction manual, if you plan on including one. This is nice, because after reading the game design document for months, or even years, you will know if the text styles selected will cause problems with people’s ability to read the manual…aside from everyone’s natural reluctance to read a manual, of course.

But don’t feel as if the design document, or preproduction planning in general, will stifle your creativity. You don’t need to document every step the player can take in the game. This may lead to a game that feels too formulaic in nature if you do document every small detail. By capturing the significant details about the game, like how many maps there are and how they’re structured, what monsters are in the game and what their major attacks are, as well as other high-level details, you will have an excellent idea of the steps needed to build your game. Another example is dialog scripts. Writing scripts for dialog is very important if you are hiring voice actors/actresses to do the dialog. How much dialog will there be? How long will the recording sessions take? What inflections do the voice talent need to put on certain lines of the dialog? Making these decisions while standing in a recording booth that you are renting by the hour is a bad time to realize that you didn’t think this through as well as you should have.

When we are done writing the design document to a stage where we feel comfortable to move into production, we will have a document that is over twenty-six pages long (it’s current length at the time of this blog post). We will have several terrain studies written to document the various biomes where the game will take place. We will have a document outlining our marketing strategies and the steps needed to realize them. And, we will have proper storyboards detailing the major shots in the cinematics for the game. Will this be a complete, step-by-step guide to making At the Crossroads? No. It won’t. But it will give us a very good idea of everything that is going to go into the game.

Surprises in life can be fun; surprises in development are almost always painful. Plan accordingly.

Finding Your Own Process

Over the course of making Capuchin Capers, I have tried very hard to document as much as I can. I do this so that I can refer to these documents after the game is done and have a better picture as to what it takes to create a game design document. Now, if you go to Gamasutra, you can find articles on various developers views as to what needs to be in a game design document and how it should be formatted. But, does their design documents really fit the way that you create video games?

There is some information that needs to be in any game design document, of course. Anybody creating a design document knows that the levels themselves need to be described. Characters or creatures, including monsters, need to be detailed. There are elements that should be included, but does your design documents formatting need to adhere to the same template that I might use? Absolutely not. At least, that is how I feel about it. If you’re submitting a proposal to a publisher, things change. They have their own expectations for what needs to be in place in a proposal and/or design document. You would need to follow those guidelines to ensure your game was given the best chance to succeed and get published. But when you’re developing your own games as an indie developer, nobody outside of your small team are ever going to see these documents. They can be formatted in any manner that makes the most sense to you as a team.

When I started Capuchin Capers, I wanted to have a roadmap for the game. I wanted to know what assets I needed to create, and the overall architecture of the game. I wasn’t even close. If you view the Trello board for this game, which can be found here, you will see that I resorted to creating a ‘General’ card just to cover some of the more egregious things that I missed when first planning this game. As I discovered the many parts of the game that I had failed to plan out at the beginning, I started to write those documents post-creation. I did this, if for no other reason, to have a clearer picture of what I needed to plan for the next game. During this process, I discovered some things about the way that I create documents and what I end up putting in those documents. My documents aren’t formatted or structured the same as the documents featured in some of the aforementioned articles.

I would have worried about this when I first started creating whole games, instead of modifications to pre-existing games. But I’m not worried about this at all now that I have a little more experience. We all think differently, and that’s a good thing. So, why should my documents follow a template that another developer might use? Is my way the best way, or even a good way? It clearly isn’t the best way, since I overlooked so much; it may not be a good way for you, either. It probably isn’t, to be completely honest. But, it is a good way for me and that is what matters.

When I am done with Capuchin Capers, I will take the documents that I have generated, along with the topics that I know that I missed, and I will combine them into a single file. This will give me a good starting point for our next game. Will it be complete? No, it won’t. Will it be the right way to write a game design document? Yes, it will. Because it will be the right way to write a game design document for me.