How to Plan A Game Development Project

One of the most complicated aspects of game development is planning. Some would argue that small indie projects don’t need to take this step, they simply need to work on the project until it’s done.

This is the farthest thing from the truth.

Initial Planning

The design framework laid at the project’s origin will determine the course for the entire project’s development. It is important to remember at this step that nothing is set in stone, but you should attempt to be as accurate as possible.

Feature List

First, analyze the design document and determine the game’s list of requirements. Then, split out each requirement into a list of features that will be required to implement the requirement.

Breaking Down the Tasks

Take each feature and work with your leads in each area (art, animation, programming, sound, level design, etc) to break it down into tasks for each department (group, person, depending on the size of your team).

Assigning Tasks

The lead of each group should then create initial time requirement estimates for each task, and then assign them to team members. This complete, he should work with his team to ensure that his estimates are correct and reasonable.

Dependencies

The project manager then must take all of the task estimates and place them into a project management software package, whether it is Microsoft Project, Excel (the two long-time industry standards), or any of the newer choices available for agile project management.

Once the tasks are added, the project manager must look at the tasks and match dependencies between teams to ensure that the timing of creating a feature don’t have impossible relationships that prevent them from being completed within necessary timeframes. For example, in order to fully implement a racing game, you would not schedule the coding of tire durability before the completion of the physics system...

you would have no framework to base the tire code upon.

Scheduling

This is where things get particularly complicated, but where the need to do project management in the first place becomes more apparent.

The project manager then assigns estimated start and completion dates for each task. In traditional project planning, you end up with a cascading “waterfall” view, which shows the timeline for completion of the project and the dependencies that link the tasks together.

In order to do this, it is critical to remember to factor in slippage, employee sick time, unexpected delays on features, etc. This is a time-consuming step, but it will quickly give you an idea of exactly how much time the project will actually take to complete.

What to Do with the Data

By looking at this project plan, you have the ability to determine if a feature is going to be costly in time (and therefore, money), and make decisions about whether the feature is necessary for the game to succeed. You may decide that pushing a feature to an update—or even a sequel—makes more sense.

Also, tracking how long you’ve worked on a feature is useful in determining if it is time to either try a new technique to solve the problem, or cut the feature for the good of the project.

Milestones

A frequent use of project planning involves the creation of milestones. Milestones indicate where a certain element of functionality, time period of working on the project, or percentage of the tasks have been completed.

For internal project tracking, milestones are useful for planning purposes, and giving the team specific goals to aim for. When working with a publisher, milestones frequently determine how and when the developing studio is paid.

Final Notes

Project planning is regarded by many as a nuisance, but you will almost always find that the developers who pre-plan projects and hit their milestones are the ones who succeed in the long run