So, how do you go about developing your projects? If you're anything like me (until recently) then you will have just worked out what you need to do, and then got on with it – picking and choosing at tasks in some sort of correct order, and working from the foundations upwards. Whilst there isn't anything particularly wrong about this method, it's hardly an efficient and quick method of completing the project. In this article I'm going to cover a method that will help you complete your project in the most time-efficient manner.

The first time you get the feeling that the first method (the 'Old' one) doesn't work is when you forget to do something and have to go back and do it – pausing all other development in the process. This is particularly bad when working as a team. If this happens you may be working your socks off trying to correct what you missed whilst the rest of your team are twiddling their thumbs because they can't do anything till you've finished. If you'd planned it properly you could have gotten someone who wasn't busy earlier on in development to do it, while you (and others) were still working on other things.

By the end of this short guide you'll be able to work out, in almost no time at all, the quickest and most efficient route to completion.

Critical Path Analysis: Step 1

The first step to using critical path analysis is to set out the activities that must be completed in order for the project to be completed. If we take a simple game framework it might look something like this:

[A] Graphics Engine
[B] Sound Engine
[C] Music Engine
[D] Input Engine
[E] Gameplay/general programming
[F] Physics
[G] 2D Artwork
[H] 3D Artwork
[I] Sound effects
[J] Music recording
[K] Level Design

Anyone who's completed a game will probably realise that there's much more to it than the above list, but this is only an example – and it can easily be extended. You could go as far as doing a separate analysis for the development of the graphics engine. It's only limited to the detail that you include.

Critical Path Analysis: Step 2

Now that you know what activities you must complete in order to complete the project you need to decide what dependencies there are. This will involve creating a hierarchy for the activities – what activities must be completed before you can start this activity? Notice that the original list (in Step 1) has a letter for each activity. This is just for convenience. Later on when you start drawing out diagrams it'll get a little crowded and complicated to put the complete activity name in, so we're referring to them by letter.

[A] depends on:
[B] depends on: I
[C] depends on: J
[D] depends on: A
[E] depends on: B, C, D
[F] depends on: E
[G] depends on:
[H] depends on: G
[I] depends on:
[J] depends on:
[K] depends on: F

The above list is what I think the dependency list should look like. You may well disagree, but you can change it all around when we're done. Notice that [K] only depends on [F]. You may be thinking that level design doesn't only require physics to be completed – it requires almost everything else to be completed as well. But if you look closely, [F] requires that [E] is completed, and [E] can't be completed until almost everything else has been. Therefore [F] effectively implies that everything before it has been completed – in this case [E], so Level Design (K) does actually require that (almost) everything else is completed.

Steps 3 & 4