fbpx

Tag Archive for design document

Serendipitous Mistakes

 

In art there is something called the serendipitous mistake.

One of the reasons traditional artists hesitate about working in a digital format is that you have the ability to undo anything you don’t like.  You’re not forced to work around it.  You don’t have to think outside of the box to come up with something clever.  In a traditional piece of artwork, you have to work with what you got, warts and all.  That constraint can push a piece of art or illustration or animation to new levels.  When I first started in the industry, I worked with artists who deliberately introduced serendipitous mistakes.  They restricted the undo stack to 1 action, they did all of their under-painting on top of an upside down photograph or a text created from paint splotches on the floor.

That serendipitous mistake effect carries over into game design as well.  Whenever you work with a team there are going to be design issues.  Sometimes they stem from mis-communications between team members, sometimes they are constraints with the hardware or the software.  Design inherently forces the serendipitous mistake, so keep your eyes peeled and be ready to embrace it when it happens.

I ran across this interesting paper tearing down this type of effect here:

Maximising_Serendipity_The_art_of_recognising_and_fostering_potential

 

Killing your babies…

In videogames there are different types of design documents. There can be one for the Ui, there can be a purely technical document that deals just with the solutions that the programmers need to work with, but before all these other, more specialized forms come into play, there is your master document. When you pitch a game concept to your
producer, whether you be already embedded in the industry or not, you’re going to be asked “do you have a design doc for that?” It’s the death question. If your answer is no, you’re dead on the water. Even if you put one together and come back in a week, that
moment of interest, that spark is GONE.  If you do have one, likely it is full of your hopes and dreams for this game. It has every cool trick, puzzle and visual dynamic you
want to see in your game. It’s probably so big that the game, as written will take years to develop and a team of hundreds to produce.

That’s okay. In fact, that’s GOOD, and I’ll tell you why.

It’s easier to kill than create. Every creative type has been exposed to this at some point or another. It’s easier to put in too much, then edit out the unnecesary fluff than it is to try and add more content, to fill in the gaps and extend a product. Realizing you’re
three levels short and having to figure out how to slot them in when you hit Alpha is a frakkin’ nightmare on SO many levels.

So this is where I am right now with our game. To borrow a term from the literary, I am killing my babies. Going through each and every level and figuring out what is essential, what is almost necesary and what is just going to bloat the thing like a week old corpse in the sea.

I have a whole a gameplay mechanic I had outlined in here that is, well, it’s useless. It gets used in one place to solve one puzzle and will suck up a ton of coding that could be better put to use elsewhere. It would be cool, but it will cripple something else that is far more important to the overall game. So I’m killing it, searching through the document and cutting it free like a wart gone bad. Finding any reference, any place it pops up and changing the pieces to more solidly support the “core” game mechanic.

It hurts, believe it or not. Taking that cool thing out feels like cutting off a toe. But I can already see how the rest of the game is going to be stronger for it, how this pruning and butchery will make the center stronger, tighter. The blossom that will result is going
to be a solid, robust thing, rather than the weedy puffs of “cool” factor that they were headed to grow into before.

Now I just need to find the Bactine… and perhaps a roll of gauze.