Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
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.
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.
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.
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.
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.
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.
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.
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.
