Jump to content

  • Log In with Google      Sign In   
  • Create Account

Accurately estimating programming cost?

  • You cannot reply to this topic
10 replies to this topic

#1 tonemgub   Members   -  Reputation: 1164

Like
0Likes
Like

Posted 04 December 2014 - 02:12 AM

As an artist and business student who is working towards producing a game, what are reliable methods for me to estimate what my programming needs will cost?

 

A description of what I have in mind is a top down space sim. Think FTL combined with planets crew can land on, explore and build.

 

While I'd appreciate a range for this type of game. I would like to learn how to make future estimations too.


Edited by tonemgub, 04 December 2014 - 02:19 AM.


Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 8005

Like
2Likes
Like

Posted 04 December 2014 - 02:28 AM


what are reliable methods for me to estimate what my programming needs will cost?

Sorry, but the true question would be

What are reliable methods for me to estimate what my programming needs will cost?

There is no reliable method, at work we estimate hundreds of projects per year and it is incredible hard to do estimation which comes close to the final costs. Some projects runs super, some projects are desasters, if you need to estimate the costs of only a single project, the finacial risks are extremely high.



#3 tonemgub   Members   -  Reputation: 1164

Like
0Likes
Like

Posted 04 December 2014 - 02:36 AM

I appreciate the honesty. I am trying to be as critical of the project as I can while continuing to delve deeper into what it will require of me financially to complete.



#4 SimonForsman   Crossbones+   -  Reputation: 6325

Like
1Likes
Like

Posted 04 December 2014 - 03:15 AM

The easiest way to estimate the cost of any project is to break it down into smaller parts and then make an estimate for each part based on your experience with similar tasks in other projects.

 

If you are buying services you should ask the contractors for an estimate and check their references.


I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#5 Hodgman   Moderators   -  Reputation: 31984

Like
2Likes
Like

Posted 04 December 2014 - 07:16 AM

You need an experienced lead programmer -who is familiar with their team of programmers- to make the estimates ;)

You can't just make estimates in a vacuum.
Said lead will break down the design into a list of technical features, identify the dependencies on other features, make a rough list of tasks, then refine it into more precise tasks. They'll estimate all those tasks with regards to the capabilities of their team.
If they've been given 5 veterans who they've worked with in the past, you're going to get a much lower total estimate than if they've been given 15 university graduates.
Ideally the actual staff will have input on generating these estimates (and then the lead might multiply the staff's numbers by Pi just to be safe).

Sometimes you might have to commit some experienced programmers to the project first, in a "pre-production" phase, so they can experiment on different approaches to solving the design requirements before estimates can even be guessed at...
e.g. If you haven't yet chosen an engine, you'll probably want your core team to evaluate your options and make that decision before going on to create the detailed task list.

#6 Tom Sloper   Moderators   -  Reputation: 10178

Like
0Likes
Like

Posted 04 December 2014 - 08:11 AM

a top down space sim.


For what platform?
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#7 Bregma   Crossbones+   -  Reputation: 5503

Like
0Likes
Like

Posted 04 December 2014 - 10:12 AM

It has been my experience that the most accurate way to estimate costs is to ask the lead engineer for an estimate, then take that, add 3, and move it to the next larger unit (eg. "it'll take three days" means 3 days + 3 extra moved from days to weeks, so your accurate estimate is 6 weeks).  This revised estimate includes all the things the engineer doesn't do, like QA and testing and packaging and translations and closing bugs properly.

 

Understand that if you give that estimate to management they will reduce it by at least half, so you will have 3 weeks to implement it.  Sales will then decide to launch it one week into your development cycle.  By the time all the bug fixing and overtime has been completed, it will have taken the original 6 weeks.  The magical thinking of tweaking numbers in a spreadsheet doesn't alter the hard facts of reality.

 

Really, it's all a game.


Stephen M. Webb
Professional Free Software Developer

#8 frob   Moderators   -  Reputation: 22792

Like
4Likes
Like

Posted 04 December 2014 - 10:38 AM

An alternate way of estimating costs is to compare it to rough costs and to find comparable titles. You say you want to start with FTL - Faster Than Light, plus a lot of features.

 

FTL started as four people with multiple months in their basements (we'll simplify to 1.5 FTE) followed by $200,000 kickstarter money in Shanghai, China. Combined with everything it took them over a half year, if I'm reading that correctly. In the US you need to estimate 10,000 per man-month.  I'm not sure what that will buy you in China, but Google suggests it is about 20% cheaper.  200000/8000=25 man months. It took four people about six months, so that sounds about right. 

 

Then you are asking to roughly double the size in new features, so we'll double that to 90 man months. Plus since your project is larger there will be more experimentation and more administrative costs, making it about 120 man months.  

 

From my own experience in smaller games, that number sounds about right for a FTL style game. You can look up various similarly-sized games and see if that feels about the same scale to you.

 

The game would have a very simplistic feel to it, and may or may not be fun (that is up to your design and implementation). 

 

 

You want it in the USA, so the 120 man months is around 1.2 million dollars for your simple little game, if you are paying for it.

 

If that means the development team is you and your nine other close friends, all of you willing to work about 2000 hours on it as a full time job, it would take about a year.  


Edited by frob, 04 December 2014 - 10:43 AM.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#9 cadjunkie   Members   -  Reputation: 1354

Like
0Likes
Like

Posted 04 December 2014 - 11:06 AM

A friend of mine who's a project manager for Microsoft has always maintained there isn't a good guide to how long a project will take. They plan for schedule A, hope for schedule B, and get schedule C. Sometimes those schedules match up, but more often than not they don't. If you somehow come up with a really good way to predict that, then you can make major dollars at any software company. 


Edited by cadjunkie, 04 December 2014 - 01:42 PM.


#10 Orymus3   Crossbones+   -  Reputation: 10700

Like
0Likes
Like

Posted 04 December 2014 - 01:18 PM

It is very hard to reliably estimate programming costs when one has no reliable means to identify scope.

In other words, the description of what you're trying to achieve is infinitely too simple, and leaves a lot to the interpretation.

While there are good methods to evaluate, you also need to have either:

 

a - A fairly good understanding of your project's scope (features, mvp definition, etc.) Hopefully a GDD, wireframes, asset lists, etc.

 

or

 

b - A relatively good understanding of your direction, with the knowledge that, through iterating on your game core, budgeting will keep evolving and cannot be measured until the project is actually done.

 

 

All projects I've been involved with used either of the above, and generally a lot more of B than A.



#11 SpiderJack   Members   -  Reputation: 445

Like
0Likes
Like

Posted 14 December 2014 - 07:38 PM

Software estimation is a skill and like all skills the more you use it the better you get at it.  I would recommend reading Software Estimation: Demystifying the Black Art as it provides several different ways to approach estimating.  Also I would start estimating every task and keeping track of every actual time spent.  This will provide you will valuable practical experience.  When I started estimating software for contract work I broke down the application into smaller pieces and created estimates for those pieces, tallied up all that time and doubled it. smile.png As the project went on I realized some tasks took less than double and some took more than double.  Over the long haul I got better at it.

 

You might also want to reach out to the creator of Limit Theory. This was a Kickstarter that I supported in Dec 2012, which had an expected delivery date of Jan 2014.  He's still working on it and has been providing regular updates.  He estimated a year and it's going on 2.  Remember that games that a long time.


Personal Twitter: @ajcniz

IndieTeamUp:  SpiderJack

 

Game Studio: Space Monkeys Down

SMD Twitter: @SpcMonkeysDown
SMD Facebook:  Space Monkeys Down

 

 






PARTNERS