When your project is finished there are several things you should do. The first – take a break. And that doesn’t mean simply taking some time off which you then spend reading news about your project (you can save that for when you get back).
Take a big step back from all things gaming related. Do something that you used to enjoy doing before you started in the industry. Trust me you’ll have plenty of time to read the various accolades and criticisms your title will be receiving.
Every company functions differently but I suspect many have lulls where you have finished most of your tasks on one project and have not been scooped up yet to work on another — or you have light duties. These lulls are useful for the previously mentioned vacation but they are also a great opportunity to look at the weaknesses in either your company, team or yourself, and do something about them.
Some of the most useful improvements to the design process at BioWare in my experience occurred when someone had time to really think and tinker and solve problems that had plagued their last working experience.
Hopefully your company offers a rebate or incentive to purchase instructional books. I found it useful to buy books on video game art, animation and other specialties tangent to what I did as a designer. Reading these helped me understand the work processes that other groups went through. Read design books too, but don’t limit yourself to what you think you need to know. Look elsewhere… one of the most useful books I stumbled across was a book on drawing storyboards!
In addition to books there are numerous online places to go to read content, from Gamasutra to the thousands of small individual gaming blogs out there. Each is a voice that is worth paying some attention to, especially when you are not in the midst of a hectic crunch schedule. Certainly there will be a lot of noise but digging into the posts and pulling out the meaning behind the comments is a skill all designers should hone.
If someone complains about a particular game mechanic, try to figure out why — don’t accept their explanation or their solution. What is valid is that they had a problem, a dislike, severe enough that they were prompted to write about it. But just like a patient going in to complain to a doctor about a stomachache shouldn’t self diagnose, neither should you accept the player’s reasons for their dislike.
Review your notes
Go over the notes you took during the development process (you know all those little gripes you jotted down just for this reflective moment).
Also go through the bug tracking software and look at the bugs that were closed as “not fixed”. Not just the ones you sent either. Go through the entire list. Is there a theme to the issues that couldn’t be addressed?
Maybe there is a game system that was completed too late to be iterated on properly and hence accumulated a lot of bugs. Are there enough issues that this might be worthy of a post-ship bug fix? How do you avoid that on the next project? I find reading these bug lists very illuminating — they really provide a context for what parts of the engine are easy to tweak and which are too rigid.
Read your forums
Every company has a different policy about how engaged employees should be on their forums but I strongly advocate at the very least reading them. Take the comments with a grain of salt, many posters are competing with one another for the title of ‘drama queen’ and will exaggerate problems with the game (or to brown nose to developers, be more keen on features they actually don’t like that much, though this happens more rarely).
I’ve dug up some really nice gems — features, plot ideas to use, plot ideas to avoid, and so on — by reading forum posts.
If you are a technical oriented designer now is the time to play and develop prototype tools to try and tackle some of the problems you ran across.
Writers and story designers might use this lull to try out characters or scenarios — throwing a few hundred words away here and there — and passing them by coworkers for their opinions.
Depending on your company’s philosophy your games may be able to be customized, either through tools or hacking by end users. Take a look at what the community is doing to your game and then try hacking your project yourself.
After Neverwinter Nights shipped I went through all the 2das and just tried plugging data into random places. And sometimes I stumbled across something pretty cool.
A significant portion of the features and eye candy that shipped with the second expansion pack (Hordes of the Underdark) had been found in this way. This allowed us to only annoy the programmers when we needed something really important :)
You may have been too busy to leave your desk during crunch time for anything less important than a bathroom break. Heck you may have been one of those hardy souls who didn’t leave their desk even for that (never ask about the empty bottle some of us keep under our desk, okay).
The lull is a great time to go around and mingle and annoy coworkers who might be busily working away on other project. What’s frustrating them? What bottlenecks have they hit? Or take coworkers from other departments out for lunch. Let them vent about what you as a designer was doing to frustrate them during development. Take notes and don’t get confrontational!
Future sections in this chapter will delve into orchestrating post mortems for your last shipped title, reviewing competitors products in depth, and more.
It may be difficult for a company to do so but it is definitely worthwhile if they can ensure that their employees have some in-office downtime. Between-project experiments are great for morale (who doesn’t feel a bit better when they realize they may actually be able to fix a problem that caused them distress in the past).
What kinds of activities have you found beneficial to work on when giving a bit of time off between projects?