It’s All There in Black and White

Ok, so “documentation” is perhaps not the world’s most exciting word. In fact, just seeing that word at the top of this blog post might cause you to…. zzz…. uh, did you just fall asleep? Apologies.

But seriously, at No Crusts, we actually spend a lot of time thinking and talking about documentation. Believe it or not, it’s a subject that we can get pretty passionate about, and with good reason. Having the proper documentation for your game may be the difference between the game experience turning out just the way that you envisioned and having an unusable, incoherent mess on your hands.

The point in the process when documentation gets locked down can vary widely – it really depends on the project. Ideally, when we’re designing a game we can be in close contact with everyone involved throughout the design phase. This means that the design process can be very iterative, with a lot of different folks giving their input and the game developing over time. We can try things out, tweak them, do some testing, make some more tweaks, and do it all over again until we’re satisfied. So, although we may start writing game documents early on, those documents are likely to go through many, many drafts on their way to the finished product, each reflecting the current state of the game, until the last elements are refined and complete.

That being said, as anyone who’s ever worked in production of any kind knows, there are some situations that are less than ideal. Whether it’s a tight schedule, a developer that’s far away, or a large team with a lot of stakeholders, there are certain projects that demand really explicit documentation from the get go. In these cases, for the sake of our clients, the developers we work with, and our own sanity, we work on creating design documents early and with a ton of detail (even though we’ll end up going through lots of drafts of those ones, too!).

Whatever the design process, by the end, everything needs to be planned, every contingency accounted for, every “i” dotted and every “t” crossed, or the game won’t work (sometimes literally). This means being extremely deliberate about accounting for all of the different elements that a game will include, from logic to voiceover, from visual highlights to sound effects, from art assets to hint structure, and so on and so on. As designers, we’re building a system that’s going to be used, and we need to account for the user and all of their potential choices. We’re responsible for looking at the big picture and thinking about the whole experience, including things like:

-What will happen when the game loads?

-What will happen when the player exits and loads the game again? Will they pick up where they left off? Will they start over?

-What are the possible decisions the player will make and what inputs will they use to communicate those decisions to the game?

-What usability issues might impact their ability to do that?

-What rewards to we want to offer when the player achieves something?

-What support do we need to give them if they’re struggling?

Our design documentation won’t be complete until all of these questions – and many others – are answered in detail. That final document will include every element that will need to be produced and put together to make the game a finished product, as well as a map of how those elements are stitched together into one seamless whole.

Yes, writing documents like this can be painstaking, but ultimately, it’s worth it to account for all of these elements, even if we know the design may change later, someone on the team may come up with a better solution, or we may discover something in kid testing that requires us to tear it all up and start over. Games will always change during development, just as a television script will always take on a hugely different life once it’s in the hands of the director and performers. But having good documentation that accounts for all of the pieces ensures that we’re not going to forget something important along the way, and that everyone working on the project will be on the same page (or page of the Google doc, as the case may be).

So, if you’re still awake, that’s why I spend so much time thinking about game design documentation. It may not be the most exciting stuff in the world, but ultimately, if it becomes the blueprint for a game that works and is a blast to play, that’s exciting it its own way, eh?

And as always you can email us at [email protected] or catch us on Twitter at @noCrusts.

Read more: http://kidscreen.com/2012/08/27/its-all-there-in-black-and-white/#ixzz2AROZ2qCs