Manager In A Strange Land: Dependencies, Part Two

In my last article, I discussed the evils of dependencies, and how you can get around some of them. But I wasn't finished. There are more kinds, and here they are.

Overbooked Resources

Fred can't work on task B because he's working on task A. Usually you just live with this, unless task B is on the critical path, in which case Fred task switches and you live with the fact that now task A is coming in late. If both task A and task B are on the critical path, you can bring in another employee to replace Fred on task B. What if Fred's the only one that can do task A and task B? Then you have a bottleneck. It's time to train another employee to do Fred's job. Even if it takes this new employee many times longer to accomplish the same thing that Fred could do, it's worth it, because it will bring your project in sooner.

This is another place where multi-class employees (http://www.gamasutra.com/features/20040130/fristrom_01.shtml) shine. A multi-classer who isn't on the critical path can switch to doing this critical path task.

Supposing George is idle, because task C is dependent on task B, but neither task C nor task B are on the critical path? I'll get to that in a bit.

Licensors and Legal

Worse than the internal sign-off approvals that come with a heavier process are external approvals. External approvals slow down a project like nobody's business. We've been having work done on our condo: all the walkways need to be replaced due to dry rot. This problem has been nagging us for two years now; they just broke ground two weeks ago. What was taking so long? The contractors needed to get approval, from us, from architects, from the city, from the fire department. Likewise, when working with a licensor, everything you do needs to go through them. There's a couple things you can do to expedite this process.

First, check your contract. The licensor should have a window of time during which they're allowed to approve; after that window, the asset is "deemed approved." This will at least cap the process.

A second thing is - do the work anyway, whether they've approved it yet or not. This is a calculated risk which you probably shouldn't take until you have an idea how friendly your licensor is. If they approve 90% of your concept art, then it may be worth going straight to modeling after the concept is sent in, because the cost of reworking that 10% they're going to deny may be less than the cost of having to wait a month for the approval.

Code and Tools

This is a big one. Some big code feature will be coming down the pipe that will let the content team actually make their content. If you've decided to create a game engine from scratch, you're waiting for that game engine to be finished and tools to be built. Or maybe you've decided to create a new visual tool that will let the game designers create gameplay without so much damn scripting. Or this boss needs to have its AI written, or a special effect requires a certain kind of renderer.

First off, don't build a game engine from scratch. If you've been reading all my articles you know you shouldn't do that anyhow.

Secondly, improving tools is a great investment. But that investment is probably not worth the cost of preventing people from working now. What you need to do is make sure your tools are backward compatible: if you're making a visual tool that lets people get away from scripting, don't take their scripting language away from them until it's finished. In fact, maybe the visual tool is just a tool that generates scripts.

If your special effect needs a special kind of renderer, maybe you should try a different special effect. For Spider-Man, we originally wanted Shocker to do a cool screen-distortion rendering effect when he blasted, but the tech wasn't ready and wouldn't be ready for the foreseeable future. We didn't just sit on our hands; we used old school particle effects instead. We intended to replace them with distortion effects eventually, but that tech never came on line. Good thing we didn't wait for it.

For AI programming I have no easy answers. We like to flip this around so that the AI is actually the last thing that goes in - the game designer places the badguys in the level and then hands it off to the AI programmer. It still can't go to playtest until the AI programmer has something. A game design that avoids a lot of unique bosses can help; face the same boss more than once, have different bosses actually use the same AI (think Galleon and how all the large bosses actually required pretty much the same gameplay to defeat them)... or have no bosses at all. Are there bosses in Splinter Cell?

When You Can't Eliminate Them

Despite all of these tricks, dependencies are going to be a fact of game developer life.

Modeling your development in Project might help you predict ahead of time where these roadblocks are going to occur. And although it's better to know about them ahead of time than to be blindsided by them - at least you'll be more honest about when you can finish your milestones - it doesn't actually help you to get past them. But it does help identify your critical path -- that chain of dependencies that stretches from the beginning of your project to the end, and determines how long your project is going to take no matter how many people you throw at it -- so you can then make those tasks your highest priority.

You don't have to use Project to do game development. I've shipped all my games so far without it. Like I said, those dependencies are still there whether you know about them ahead of time or not. On my projects, we'd be constantly blindsided with, "I'm ready to work on this now but the assets I need aren't there!" And we'd fix those roadblocks on the fly: we keep a handful of associate producers running around solving these kinds of issues, telling person A they better make task B a high priority because person C can't work without it. It's stressful but it works, more or less.

The Starfighter team at LucasArts used what they call a "blocked board" - a giant dry erase board, centrally located, listing everybody on the team, with a marker for whether they were blocked or not. Green = working; Yellow = about to be blocked; Red = blocked. If everyone on the team is conscientious about keeping the blocked board up-to-date, it's a Good Thing.

One final comment: an idle employee is often considered one of the biggest sins in game development. It is not. It is wasteful, but we do all kinds of wasteful things in game development: we crunch, we employ massive teams that require huge amounts of management overhead, we work on levels until they're half done and then cut them. We adopt these wasteful policies because it's usually more important to ship on time than to get the project done efficiently: you'd lose more money shipping late than you'd lose from all that waste. It reminds me of McDonald's - a company founded on the idea of making hamburgers ahead of time and then throwing them out if nobody wants them. Wasteful? Sure. But it makes money.

Likewise, if you're stressing about the aforementioned George, who's dependent on Joe's task B, which Joe can't get to because he's working on task A: it's okay to just live with it. You could be spending that energy making sure the critical path is running smoothly. George will get to work eventually. In the meantime, have George play-test, and go on and solve your more important problems.