We are searching data for your request:
Upon completion, a link will appear to access the found materials.
One of the most complicated aspects of game development is planning. Some would argue that small indie projects don't need this step; they simply need to work on the project until it's done. This is far from true.
The design framework laid at the project's origin will determine the course for the entire project's development. It's important to remember at this step that nothing is set in stone, but you should attempt to be as accurate as possible.
First, analyze the design document and determine the game's requirements. Then, split out each requirement into a list of features that will be needed 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 (a group or person, depending on the size of your team).
The lead of each group should then create initial time requirement estimates for each task and assign them to team members. After this is complete, the lead should work with the team to ensure that the estimates are correct and reasonable.
The project manager then must take all the task estimates and place them into a project management software package, either Microsoft Project or 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 doesn't have impossible relationships that prevent it from being completed within necessary time frames. For example, to fully implement a racing game, you wouldn't schedule the coding of tire durability before the completion of the physics system. You would have no framework to base the tire code upon.
This is where things get particularly complicated, but where the need for project management in the first place becomes more apparent.
The project manager 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.
It's 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 take to complete.
What to Do With the Data
By looking at this project plan, you can 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 might decide that delaying a feature to update-or even a sequel-makes more sense.
Also, tracking how long you've worked on a feature is useful in determining if it's time to either try a new technique to solve the problem or cut the feature for the good of the project.
A frequent use of project planning involves the creation of milestones. Milestones indicate when a certain element of functionality, a time period of working on the project, or a percentage of the tasks has been completed.
For internal project tracking, milestones are useful for planning purposes and for giving the team specific goals to aim for. When working with a publisher, milestones frequently determine how and when the developing studio is paid.
Project planning is regarded by many as a nuisance, but you'll almost always find that developers who plan projects well in advance and hit their milestones are the ones who succeed in the long run.