Accountability

Perhaps the most important act for people who run a developer or a publisher aside from their love and passion for the very games they play and create is accountability.

This word really is wrapped in political and business paradigms. Creatives with burning visions of a holy city of great games would, on average, rather not use it. It just sounds icky. Far too corporate. And the word "stockholder" seems to loom not far behind. But it is an important word to understand despite its murky history. Beyond the formal definition of accepting responsibility, these days accountability means being able to task for as much as possible in a process and when the process is completed, understanding what took place and why. And yes, taking responsibility.

More often than not however, as we have all seen more times than we can count, accountability usually means passing the buck and finding blame when a project runs late or gets cut off. Auditing, layoffs, high emotions and head scratching. In a creative environment we're told this is something to just accept, simply because you can't schedule creative success. But you don't have to accept it. You can learn from it and improve, whether your genre, mechanics or platforms are changing daily, you can still create better accountability.

Beyond the basics

When scheduling a project, basic tasks include things such as "texture creation", "particle system, UI hookup", "first map AI pathing / scripting", etc.. Tasks that each professional (well, in this example) knows they need to complete to see the project out the door.

Producers get estimates on how long these tasks will take, add some buffer time, and perhaps even go a step further and buffer vacation, sicktime, meetings, holidays and trade shows as well. But here's the funny part: in not one project I have seen do the executives, producers or team leads budget for how long it takes to make a decision.

In our magic schedule land, somehow, decisions are already made. We already know that a renderer will work just fine with static as opposed to dynamic lighting. We've no doubt that AI will behave perfectly with the metrics for each area that are, again somehow, already pre-defined in the context of both the game engine and Maya / Max. It's clear that Wwise will definitely, without a doubt, take roughly the same amount of time to integrate with the PS3 as the Xbox360. All these problems are already solved.

The Decision Buffer

Yes, my good friends. Decisions are a key factor to add to any schedule. The question remains how. It's surprisingly easy to conceptualize. Just not so easy to work into an entire project. Time for an example.

Overall Project Decisions

The entire project typically has milestones where it will either stop, be given more funding / resources, or continue as originally planned. The time it takes to evaluate a project and make those decisions starts in days and can take up to several months. Perhaps longer, but I'm only going from personal experience. And planning for a year of "go / no go" buffer time is definitely not something you want to slap on the table in front of a publisher with a stupid grin on your face.

But within milestones, publishers and developers do not account (to my knowledge) for build review and approval time. There is only a date, and if you're lucky a publisher will count backwards and request a build far enough in advance of that date to make an approval and God willing wire you the next milestone payment so you can keep your employees from going on strike. But account for it in advance and you're a lot less likely to bite your fingernails when you don't get a decision when you originally anticipate.

Design Decisions

Design decisions are the central hub that affect all other dependencies. A simple change of mechanics can completely swing the course of a project in an entirely new direction and take everything with it. But let's stay focused. A good specific example here is what kind of motion control a game will have. It is but a subset of design decisions that are making designers' lives exponentially complicated, given that we're no longer in a world with a few platforms and you know where you stand (literally and figuratively) with your audience and technology.

Motion control, being at this point a "platform within a platform", a connection to games that is not easy to map from one console to the other... well, okay, is extraordinarly hard to map. But regardless of details, decision to use one set of controls on however many platforms is the only decision accounted for in a schedule (typically).

This decision schedule process gets more tricky, as the ideal situation is for a publisher to have an in house r&d department able to provide adequate guidance to developers on which games will become more successful / accessible with different motion controls. But for a developer, r&d is a rare commodity to afford unless you're owned by a big parent publisher. So at this point I'll refer you to an earlier blog post of mine: "keep it simple" and unless your game is so obviously a fit for Kinect, PlayStation Move, and Wii, OR a publisher is willing to provide additional funding for it's motion controls, one motion control / one platform game development is your best bet until you've got the hang of it.

Art Decisions - Outsourcing

Art is one of the most risk-laden areas in a project, since it is where most of the production work will take place. Outsourcing has created an entirely new set of producers who specialize in this field. However, all too often the time zone delay for communications as well as delivery of assets can take the savings one thought one would get from going to Russia or India and cut it from 50% to 10%.

Specifically, making decisions about the quality of delivered assets is often not something factored into a schedule. That goes for visual quality as well as how well the assets integrate. Nearly every export, even on the same software package, will have something funky about it, particularly in the early stages of a project.

I hate to burst the bubble

Or rain on parades, but for anyone convinced they can get a project to market for pennies on the dollar is delusional, and this is just another reason why. Accounting for decision making (note that this is NOT problem solving) can easily add 20-30% of time and money to a schedule. But better to have that in your mind than discovering it the hard way when that First Playable milestone date looms. This applies to the smallest mobile or web based project to the largest AAA MMORPG (which of course is WoW, and interestingly enough, they're able to account for decision making... with cubic hectares of cash).

If you'd be interested in an ongoing blog about which decisions to watch out for with multiple contributors giving advice, comment in.