Things to Know Before Scheduling Begins

There are a number of miscellaneous subjects that are useful to anyone tasked with organizing the project schedule for a computer game. Let's explore them now.

Tip/Tricks Using Microsoft Project

I should call this section, "Death of a Programmer," because I remember a time when I was better at C++ than Microsoft Project. I'm pretty sure that's behind me now and I might as well suck it up and start becoming an Excel macro guru as clearly, that is my destiny. I've been using Microsoft Project since 1995 on Ultima VIII, and I'm sad to say there's nothing else on the market that performs the task of scheduling as well. Certainly nothing within the price range of a small computer game developer, anyway. The problem with Microsoft Project is that is was never designed to schedule software projects in general, and certainly not computer game projects. I heard some rumor that Microsoft Project hasn't changed significantly from an original software package that was used for building buildings, not software.

This heritage seems likely once you begin to dig into the project. The fluidity of computer game production isn't handled well in Microsoft Project, especially if you begin to set constraints such as begin/end dates or task predecessors. At first blush this seems like a good idea, but you'll quickly find that you won't be able to easily reassign tasks from one person to another or change which milestone a certain task should end. This is hard enough with little or no constraints, but it becomes nearly impossible when you assign dependencies.

Here are some things I generally do when working with Microsoft Project when building a schedule for a game:

Predecessors: I never assign them, rather I generally attempt to make sure the tasks are set in the schedule in roughly the order in which they will be completed. If you want to assign predecessors, be frugal with them and delay as long as possible.
Resource Assignments: I always assign resources to individual tasks, not summary tasks. Try to assign one person for each task, unless you can assign a task to a resource that represents a group of people, such as "Artists."
Custom Fields: I use additional custom fields to help me store additional data about the tasks, specifically I use the Text1 and Text2 fields for describing which feature and subfeature to which the task is related. This helps me tally up all tasks that might have to do with, Sound—Foreign Language Speech for example. Don't make the mistake of thinking that the summary task descriptions are useful for this. They aren't.
Cost Field: I always use the cost field, and put a special section in the schedule for things that need to be purchased specifically for the project such as technology licenses or the ship party.
Partial Time Assignments: Sometimes a person on your team will have to spend some time managing, and the rest of their time performing task work. Put a line for them up in the management section and assign the resource like this: Name [25%]. On every other task assigned to them in the schedule, put 75% in the brackets.
Linking Tasks: I never link tasks, because it keeps me from being able to move tasks up and down in the schedule easily. I think of Microsoft Project as a tool to plan my project instead of one that helps me keep track of it after work begins.
Use Resource Pools: If I'm planning multiple projects I use the resource pool to make sure that I'm not double scheduling someone.
Don't Bother with Email Task Updates: This is another feature that simply doesn't work as well as you'd hope. The technology is fine and it's pretty easy to set up, but you simply don't get the information you want. To be honest, nothing beats walking around to see, hear, and play with things as they get done.

There's one point I should make clear: The features of Microsoft Project that I choose to ignore are not useless. In some large projects it might be impossible to understand the effect of moving or changing tasks that are on the critical path. If you choose to enter all the information to link tasks and set predecessors that's perfectly fine. My advice is do this as a last step since you'll find changes very difficult to make without seeing that "Can't level resource" message ten thousand times.

Key Programming Tasks in Computer Games

One of the best ways to transform a design specification, even a rough one, is to look at each component and figure out what key programming tasks are necessary to bring the feature online.

Graphics: Every game has to paint pixels, whether you use an old sprite engine or the latest hardware accelerated 3D renderer. Your game will need a way to draw and manage the art assets for sprites, textures, models, in-game animations, and cinematics.
User Interface: This task extends the graphics system and creates buttons, menus, fonts, dialogs, screen overlays, and so on. It also deals with translating user input from devices like joysticks, a mouse, game controllers, and even microphones into actions the game understands. Sometimes this translation is non-trivial, such as recognizing that the speed of a vehicle should affect the sensitivity of the steering input.
Sound: This includes sound effects, speech, and music. Your game must find a way to blend these as smartly as a sound engineer would and somehow leave enough CPU speed to keep the graphics system happy. Sound systems are almost always running in a separate thread, so they tend to break easily.
Triggers/Events: Your game needs to have an interactive environment and not just a pretty screen saver. Game code should be written for every object that isn't static scenery. This might be as simple as intercepting a collision event and playing a sound effect, or perhaps it might be a phantom object that spawns some evil zombies when your main character steps onto a platform.
Objects/Attributes: Objects like weapons have attributes such as the size of magazine they carry or charge they hold. For every attribute you'll write some code to deal with it, hopefully in one place.
Character Interaction/AI: You might spend a lot of time in this code. AI can be devilishly hard to write because it's one of those things that gets better the more time you spend on it, and until enough time is spent on it the game simply isn't challenging enough or doesn't "seem" right.
Physics: A real physics system is incredibly complex, when you consider the problems of creating a general collision system and static dynamics solution that runs in real time. Even integrating some middleware can take a lot longer than you'd figure, since everyone stores coordinate systems differently, especially when you consider hierarchical objects.
Resource Caching/Data Streaming/Compression: Your game doesn't just spring to system RAM fully grown; it has to be loaded from CD-ROM or a hard disk. You'll want to make some good trade-offs between taking a lot of time to decompress data when moving to a new level or storing much less, although uncompressed. You might even attempt to predict what needs to be streamed in constantly to create the illusion of a completely seamless world.
Network Communication/Prediction: A multiplayer game is going to have some network communications code to exchange data over a LAN or the Internet, but also what to do when that communication isn't happening at nominal rates. This is the part of your code that will defy physics and send an arrow right around a corner. "I guess that guy needed killin'," as we sometimes say in Austin.
Tools: The smallest game I ever worked on had a little tool we used to create simple animations. Tools can be as easy as that or as complicated as a multiuser networked level editor like we had on Ultima IX, which took longer to write than the game. Ask yourself where every piece of data is coming from as you design your system. Most likely you'll end up creating a tool to create it, package it, or optimize it.
Optimization: This is a task that usually sneaks up all programmers because they don't think they'll have to do it. That's because they never knew that the rendering engine they are so proud of must run smoothly on computers that my grandmother thinks are pieces of junk.
Back End: This little bullet item needs an entire book. If your game is a client/server game, you'll need some sort of back end to manage connections to your game. This will include the login system, account administration, server monitoring, and a whole galaxy of other tools.

Asset-Based Scheduling

Asset-based schedules approach the scheduling problem by creating the list of files or components that will be shipped with the game and enumerating tasks that will be required to create each one. This works best if you are creating a port, refreshing an existing title, or you've studied the data files and gameplay of an existing product. This method bases its success on the simple fact that a certain amount of work is needed to create each asset: code, textures, models, animations, sounds, help, and so on. If you made a comprehensive list of each asset in the product, and made some reasonable estimates of the work it would take to create or port each one you'd have a good start on an accurate schedule.

Gotcha

Don't think for a minute that this is some kind of silver bullet. It's impossible to look at the executable for a game and calculate the man-hours per megabyte. It might be an interesting way to do it but I doubt you'll achieve a high degree of accuracy. This method is a good place to start making lists of things you'll have to create.

One of the best ways to begin making connections with your game design and actual tasks is to break things down screen-by-screen. Sketch out each screen from the intro, character selection, midgame cinematic sequences, options screens, and every permutation of game screen and every dialog that will ever show itself. Figure out what actions will move the player from screen to screen: a button click, waiting a certain amount of time, or hitting a game trigger. If you hang all these screen designs up on a wall somewhere the team gets a really good idea what the game will become. It also helps the artists and designers keep a common look and feel throughout the game as they complete each component of each screen.

Best Practice

As each screen or game level reaches a content complete stage, take some screen shots and print them out. Create a huge storyboard of your game somewhere the team can see it, and watch as things begin to come together. The storyboard should start with pencil sketches and napkin drawings, and be slowly replaced with the screen shots. Over time the team will see the entire game come to life in blazing color. I like doing this because it's motivating to see members of the team post new screens and it has a secondary effect of keeping those annoying producers and executives away from the programmers and artists! They just stand in front of the wall and say, "Bonuses and raises for everybody on this team. Get the project leader in my office right now, I'm giving her my BMW."

Every screen up on your wall has active areas: buttons, objects, animations, overlays, and so on. Each one of these will likely have a sound component and a piece of code that runs when it is activated. Create an exhaustive inventory of every component and figure out what tasks need to be accomplished for each one. When you are done with that, consider all forms of user input: keyboard, mouse, joystick, and gamepad. Every permutation of button press or motion that will have some effect in the game must have some code, sounds, and art that you'll need to make work. Add all those tasks to your master inventory.

As you put all these tasks in the inventory, think about the derivative tasks that you'll need to make everything work. If you have a screen with a button on it, you'll need to write the code that executes when the button is activated. You'll also need code to detect and parse user input messages, animate the button, load the button art and sound effects from a media file, and much more. Repeat this process for every task until you're sure you've hit bedrock, so to speak, and you have everything you need to make everything work.

Write Your User Guide and Cluebook

Writing your user guide and cluebook before your game is done might seem nigh impossible, and I agree. You won't be able to know what wacky things every designer, programmer, artist, and sound engineer will create on the spur of the moment. There is, however, something to be said for using the user guides and cluebooks as design documents in miniature. You can take the critical information you find there and use it to create a task list.

Take a look at any user guide of any platform title and you'll see exactly what I mean. You'll see a description of every weapon, ally, opponent, and item you can use in the game. If your design document isn't two orders of magnitude better than a twenty page platform user guide you're already in big trouble.

Cluebooks are another story since they tend to be nearly as detailed as many design documents. I seem to remember some of the cluebooks at Origin were created nearly directly from original design documents or in some cases actual data tables in C code. This makes a lot of sense, when you figure that the best way to make sure the cluebook is right is to pull information like weapons tables, damage information, or item coordinates right from the horses mouth: the game.

I might as well come out and say it: if you know enough about your game design to write the cluebook ahead of time, you'll make a perfectly accurate task inventory, and a schedule that would make any producer weep tears of joy. Now if you can only get those time estimates right!

Know Your Team and Know Your Genre

If you've ever questioned the worth of experience versus simple enthusiasm I'd like you to perform the following experiment: The next time you undertake a programming task you've never attempted in the past, make a note of how much time you spent on it. Then, delete the code and do it again. You'll likely code a better system, and in about one-half the time. Please don't do this if someone is paying you. I don't want to get angry letters. The point of this experiment is that enthusiasm will help you stay awake longer but that's about it. I'll choose the experienced programmers over the enthusiasts every day because they'll know how to solve problems specific with the game genre. While it might be possible that a senior engineer at EA Sports could be an Ultima enthusiast (yeah, right), it would be a mistake to give the EA Sports programmers the task of creating a fantasy role playing game.

Still, sometimes you have to put food on the table and take that odd project. You and your programming buddies have never seen anything like it. Make sure you give yourself some extra time on the schedule to deal with the learning curve. After all, Barbie Fashion Designer 2004 might be a lot of fun; don't knock it until you've tried it!