Dungeon Master’s Toolkit: Dev Diary #2 – The Importance of Pre-Production

Allowing (and planning for) time dedicated to pre-production is crucial to planning for a successful production cycle.  I know this, and I'm probably fairly safe betting that anyone reading this does too. But here's the thing: Knowing the right way to work, and working in the right way, are two painfully different things. For starters, it requires common sense to connect the two - something I often (sadly) lack. But more than just common sense, it requires planning. As in... You have to plan to do some planning. To improve your plans. Which is probably dangerously close to being meta, or at least recursive, threatening to collapse this post into a grammatically incorrect singularity that'll eat up the Internet.

But despite the questionable scientific risks, it's worth repeating: You have to plan to allow time for planning.

This isn't a personal maxim, but a universal truth of creative endeavour. In fact, it's so universally accepted that it probably seems pointlessly trite to discuss it at all.  But the thing is, in that initial rush of enthusiasm when the ideas are all jostling around in your head, bursting your brain-meats for a creative outlet, it's far too easy to forego the boring planning stuff in favour of diving head first into production like it's an Olympic event - the kind where they fire a starting pistol and then release the zombies - and you're driven to frothing, furious abandon by an anxious need to get shit done for people to consume.

This shit is like rabies for independent game developers. I want to get my creative bits all up in your grill, and time spent doing anything but producing makes the act of production feel so imminently urgent that pre-production is like a horrible dream where your feet are lead and your muscles are rubber bands and you can only stumble forward in hopeless desperation.

But (and this goes without saying twice but I'll say it again anyway) good pre-production is critical to maximising your chances for successful completion of a project.

Fail to plan, plan to fail. Word.

With adequate pre-production, you gain (in no particular order, as all are equally relevant):

• The creative confidence afforded by research and development.
• The workflow and pipeline benefits gained from procedure validation and prototyping.
• A pragmatic measure of your capabilities versus your creative vision, and some capacity to estimate a realistic schedule.
• A healthy team psych awarded through consensus and compromise.

I'm going to blabber on a bit about each of these points because gigantic walls of text make me feel like my blog is full of helpful information, versus quasi-intellectual rambling. Bare with me, or just skip to the end where I momentarily bitch about the pains of generating good normal maps as justification for this entire diary entry.

Creative Confidence

There are immediate and immense benefits to be gained from investing time in R&D, most notably in gathering reference and cataloguing resources. This provides you with a groundwork from which your team can leverage the experience of others in your own production, saving valuable time, and avoiding the mistakes that someone else has already paid for. Working blind is counter-productive. Worse: It's just plain stupid. Unless of course the topic you're dealing with is something with which you are so intimately familiar that you are the penultimate authority on the subject.

Taking time to research your tasks and goals (indeed, every little frightening facet of your product from pushing that first pixel to shipping the 20th anniversary edition) is ultimately the best investment you can make towards releasing a successful product. Or releasing any product. Period.

So, before you start a task you should take the time to make sure that everything you're doing:

• Is the right thing to do to achieve the ends you wish to achieve.
• Is backed up with an enormously comprehensive collection of reference material from which to draw influence and information.

Workflow & Pipeline

Unless you're gifted with psychic precognition, it's only by actually putting stuff into action that you can identify the roadblocks in your way. So dedicating some time to testing out your creative processes (particularly when you're working collaboratively and relying on an intricate relationship between your work and that of your team mates) is the best way to identify and pro-actively correct the problems you'll inevitably face. Procedure validation and prototyping help ensure your workflow and pipeline are conducive to the results you're aiming for within the proposed schedule.

The average non-super-human should be prepared to be randomly (probably quite frustratingly) stalled throughout production by unanticipated challenges. But you can significantly reduce the occurance of these challenges by testing your theories, techniques, practices and best-laid-plans ahead of the crunch.

Pragmatic Expectations

One of the most common mistakes that people make in the creative industries - and we make this mistake even when we're dazzlingly aware that we're prone to making this mistake - is grossly underestimating the time required to complete a task. I learned in my professional career to estimate a realistic duration, considering all possible factors (both internal and external). And then immediately double it.

At the best of times, it was a strategy which left me with a few spare hours I could use to make up for the worst of times.

Shooting for the moon is a noble thing. More than that: It's an aspirational thing. Every soul on this Earth who aims too high should be damn well celebrated for it, for without these folk and their reckless disregard for rationality and realistic goals, the sum of humanity would be much less than it is. By all means, you should aim to raise that bar, and lift the whole world along with it. Design your FPSSHMMORPG real-time open-world procedurally generated infinite zombie space explorer, and go for it. The worst that could happen is you'll fail. Big fucking deal. Because even then you've just learned some incredibly important stuff, such as just how much work goes into making a video game, how frightfully untameable the production beast can be, and how to set realistic goals for your next project. And then of course you might not fail. Don't prematurely impose artificial limitations on your dreams.

But there is a place for pragmatism. If your goal is to produce a completed game and make some moneys, you should probably set aside some time for unit testing to ensure that your programming skills, artistic talents, technical proficiency, skills budget, creative aspirations, intended workflow and pipeline, and proposed time frame all align like some staggeringly beautiful celestial event that crazy people will see as a sign of the apocalypse.

Healthy Team Psych

This really does go without saying. If the idea of cultivating a good, happy, healthy team spirit seems alien to you, I suspect you're either a poor robotic facsimile of a human being, or you're corporate*. Group discussion time allows you to co-plan your outcomes: Individuals on your team can reach agreement on your collaborative expectations, and momentum can be created from clearly defined shared goals. This kind of stuff is priceless, and starting a project without this clarity is a sure-fire way to make it crash and burn.

In a world where geography is decreasingly important it's not unusual to find yourself working with folk in different timezones, so maintaining contact might require conscious effort, and you should enforce it throughout the duration of your project. But the initial pre-production meet-ups are where you will all clearly define your expectation from each other and your willingness to commit to them. By ensuring you're all on the same page, you minimise the chances of group implosion down the track when the honeymoon period is over.

Of course, making a game is not an entirely scientific process, and all of our best-laid-plans will invariably give way to production deadlines, unexpected interruptions from that annoying life thing that goes on around us, and our own creative tides moving our goals and targets about on that infinite ocean of possibility. A fluid production is a good thing: In my experience many of the best ideas come from spontaneity, not planning. But even that requires foresight, if just in the loose sense of being aware that feature creep, variations in scope, and changing desires will all likely interfere with your neatly bulleted schedule. And that's okay, because that's part of the joy of not being a banker or a stock broker or an accountant. Urgh.

The important point to be made here is that by being aware of all of these possibilities potentially working against you, and putting aside some time at the start of your production to prepare a cooperative plan of attack and shore up your production strategies, will much better equip you to handle the unexpected.

So if you made it this far, and your eyes are not bleeding from the text (OH MY GOD THE TEXT) then you might remember that I mentioned something about normal maps?

I don't do a lot of 3D stuff other than lighting. I think it says over in the little "About Me" bit on the side of my blog that I'm a lighting specialist. That means I spend about 15 minutes a day placing digital light sources, and 14 hours waiting for test renders. There's not a lot of modelling. So it would make perfect sense to anyone versed in production practice that some guy who has never done a particular task before should set aside some time learning the task before attempting to WTFPWN it.

Unfortunately, I fell victim to the rush of new project euphoria.

So I made the mistake of skipping the unit tests and diving right into sculpting unwieldy high resolution mesh on my uninspiring 3Gb-RAM PC and attempting to design a good normal-baking workflow with geometry that wanted to kill my computer. A process that - with better planning - would have taken me a couple of hours ended up taking me two days. It's all okay now: My workflow has improved, and I have solved a number of normal mapping issues which were unexpectedly difficult to solve via Google (and I'll bullet them below for reference), but more importantly I'll be sure to unit test every addition to my workflow and pipeline in future.

So the points I've got for normal baking, in what will surely be the shortest tutorial with the longest introduction on the Internet:

On Using XNormal

• Export to XNormal using XNormal's proprietary format plugin to ensure smoothing groups arrive intact. For some reason, XNormal doesn't give a shit what is and is not smoothed when using .OBJ or .FBX formats.
• Where you have used hard edges on your low-resolution mesh, separate the UVs along those edges to avoid filtering seams. A couple of pixels of UV space will do.

And that's it. Two days to arrive at that result. PRE-PRODUCTION, PEOPLE. OMG.

* Possibly the same thing.