Fundamentals of Game Project Duration Estimation

Indie game projects easily miss their deadlines. Planned milestones pass, and patches don’t come on time. This article points out 15 reasons for missed deadlines this and gives a clear guidance on how to estimate your game projects duration. Getting better estimates will not lower costs but will help you estimate the time scale and costs related to the project.

#1 – Avoid Over Optimistic Estimations About Your Skills and Energy Level
It’s quite common for people to over estimate on what they are capable of. There might be times when your skills are simply not enough and you need either help from others or time to learn new skills. It’s also notable that your level of energy might change during the project – on some days your diligence and motivation could spike while on other days they might be really low. Estimating projects and believing that you will have 110% energy level every day is over optimistic way to approach.

#2 – Avoid Over Optimistic Estimations About Your Time
How much time you spend on chatting, emails, eating, breaks, phone calls, and organizing daily? You must notice that if your typical work day lasts for 8 hours, you propably use some time for general issues. You propably receive interruptions in different ways. It’s not realistic to assume that you could use 100% of your time for the project. Depending on your assignments it will propably be something like 60-80%.

#3 – Estimating Too Large and Abstract Components
This is propably the key reason why projects estimates miss their targets. If you try to estimate how much would a new multiplayer FPS game would make you would need to list the components/objects. The first list might contain only big components like:
1. “Network”
2. “Server”
3. “Client”
4. “Players”
5. “World”
There’s no way to estimate durations for these. You’ll have to break your big projects into hierarchical list of smaller tasks.

For example: “Players” could be divided into several tasks:
4.1. “Player Design”
4.2. “Player Graphics and Animation”
4.3. “Player Sounds”
4.4. “Player Network Code”
4.5. “Player Scores & Ranks”

After you have listed these taskyou would need to divide them into smaller actions: “Player Sounds” for example could have actions like:
4.3.1.”Create death sound #1: ‘aaargh'” – 2 hours,
4.3.2. “Create mock sound #1: ‘you lose'” – 2 hours.
4.3.3. “Create footsteps sounds”, 3 hours
And so on.

Now you could total the hours for each task and you would have a much better idea on how much time your project could roughly take. Breaking large units into small manageable task is essential for you to make realistic estimations. It’s up to you how detailed plans you want to have. Sometimes 2 levels is enough, sometimes 3rd level is needed.

#4 – Fixing Errors & Bugs & Other Problems
Don’t assume everything will right in the first time. There will be always errors and bugs in your program. You will need to revise your code. Putting a 10-30% time buffer for “unknown bugs/problems” is a good way to make a better estimation.

#5 – Remember To Estimate Also the Integration of Different Modules
Besides bug fixes you must notice that integration of several modules will take time. If one programmer codes the server and another one the client then you must also estimate the integration – the time it will take for server and client to work together.

#6 – The Feature Creep
Game developers – whether they are artist or programmers want to make the game perfect. They want the textures to be perfect. The code must be perfectly optimized. The rendering must be perfect. The details must be perfect. It’s very hard to make a decision when something is considered finished, but there are times when you must make sure the project goes forward. Polishing over and over will eventually lead to a non-finished product. There are times when you must make a tough decision – and accept some level of quality. It doesn’t have to mean that there couldn’t be many areas where the perfection is done – it just means making a conscious decision about where polishing is really needed and where you can survive with lesser quality. To make better estimations, be sure to add ‘feature creep’ extra time for some parts of the game.

#7 – Producer Tasks Has to Be Noticed
Meetings, project planning, estimations, project management, design document updates all are tasks which aren’t usually noticed when making game project estimations. All these take time and should be somehow taken into account.

#8 – Unclear Goals and Task Objectives
This is another huge problem in project planning. If your goals or objectives are vague, there’s no way to estimate them. If your goal for making the graphical user interface is listed as “Make a better GUI” it’s not possible to estimate duration that. What does “better” mean anyway? Does the GUI mean also designing the graphical user interface? Does it mean coding it – or is it only making the pixel graphics for it? Make sure you state and write your goals and objectives clearly.

#9 – Wrong Person Is Doing the Estimations
If you are a coder and try to estimate hours for modeling without any relevant past experience there’s no way you can do it. If you don’t have any idea on what a making of MMORPG would take then you shouldn’t do the estimation. You should either find the people who can help you to estimate or learn more about the subject. Use designers and programmers to estimate – let your team participate in the process if necessary.

#10 – If You Cannot Find Answers From the Team Members, Ask Outside
Estimating a massive game project without previous experience is a difficult process. Consider asking other game developers. Go to some game development forum and ask what people would estimate about your project. You propably won’t find exact answers, but you’ll most likely will get some rough ideas about the duration. This might help you to make a better evaluation by yourself.

#11 – Estimations Are Not Updated When the Project Gets More Content
One quite strange phenomena is to create huge timetables and large estimations for the game project and then forget these estimations. If you are going to estimate your project then you should update the estimation when you add significant changes into it. Otherwise it’s no use.

#12 – Time is Not Tracked
Without tracking your time spent on different tasks you won’t learn. You’ll estimations will remain on the level they are now – and if you don’t track your time you propably will live in a dream house believing your estimations are always correct.

#13 � Nothing is Learnt From the Earlier Projects
If you have completed or progressed in some previous projects you should store the estimations and actual durations. If you have past experience about estimating a project it can come handy when doing new estimations.

#14 – Quick Estimations
One of the worst ways to estimate projects is to do it in haste. If estimating a project takes 30 seconds you can bet that person is not doing a good job. I’ve asked many people “How much time will that take?” and listened them to answer right away: “It’s 90% complete, will be finished in two weeks.” After two weeks the same person is in the same point giving exactly the same answer. If you make estimations – don’t make them quick.

#15 – Don’t be Afraid to Be Wrong
Bad estimation that is tracked and learned from is much better than no estimation at all. If you want to make better estimations, start tracking time and making your guesses. Note how much time it took, and what changed during the project. If you want to learn, you must accept to make mistakes. Start learning, and get better on making estimations.

Juuso Hietalahti


  1. @Fernando: Yes, I also believe that agile development methods are great (used those), but if your planning timeline is only the next 2 weeks, it’s impossible (in my opinion) to run business. You just cannot ‘do things forever’ (‘when it’s done’ ;) if there’s money involved. You have to know – or have some kind of estimation – about when then game is done & when the games starts to sell.

    But as you said – agile methods are good for many indie projects.

  2. For indie projects I think the Agile methodologies works very well. The last project I worked on, we adopted parts of several methods including Agile Development, Scrum, and Xtreme Programming.

    This was a great benefit to the team because we only planned out features that were going to be implemented into the game over the next iteration(2 weeks). By planning things out in short iterations we gained two serious benefits.

    – We did not have to worry about cutting features that have been planned for hours during the pre-production phase. Planning takes place every two weeks – so – we only needed to take on the tasks we felt comfortable with for that time period.

    – After a few iterations, you can begin to predict how much work can be done within one iteration. This allowed us to predict how much work would be done based on how well the team performed the previous iteration(s).

  3. well I had two deadlines for my last two games, Christmas (for Xmas Bonus) and Easter (for Easter Bonus). I needed to get everything ready at least a month before so the portals could wrap it in time. So I had to plan the work, assign estimates, and then decide what to cut out of the plan! I kept a very accurate timelog in Excel which includes time started, time ended, task type, and comment, plus a total time for the task calculated from the started and ended times. This information is all summarised on a different page. For Easter Bonus 10% of my time was writing emails to the artist and musician!! Anyway, I’ll release the time stats if Indiepath releases the sales figures in a few months.

    Before making games , I wrote business software for 9 years, you can’t have fuzzy deadlines or feature creep when a paying customer is expecting delivery on a certain date, and hotels are booked, staff are ready and waiting for training etc.

  4. The only estimates I do are these:
    Release first playable version – 1 year
    Finish the game – Another 1 year
    Total 2 years to make a good game.

  5. I’ve never bothered with time estimates in my indie projects. I could never keep up to them because I never know when I have time to develop the game. Much less pressure this way.

Comments are closed.