1
\$\begingroup\$

Something I have been looking into for a while is developing my own PC game. I'm very into CRPGs like Fallout 1 and 2, UnderRail, Wasteland 2, etc. I have long desired to create my own game like this, with an emphasis on plot.

While I don't have any experience in development, I use several (mostly proprietary) programming languages in my job, and have a natural aptitude for learning syntax etc. I have taken a few tutorials in Unity and Godot but generally I prefer to feel my way through software myself (tutorials rarely give you enough 'why and how') or reverse engineer an existing product.

I plan for the game to be quite minimal on the asset front, at least to begin with. I've done some basic 3d modelling and mapping (a long time ago, in Source engine - I built my school!)

My question is, if I decide to dedicate the time to this, how long does it generally take for one person to create a game like UnderRail or Darklands? I'd like to know if it's a doable project or a laughable pipe dream for an inexperienced one-man enthusiast!

\$\endgroup\$
1
  • 6
    \$\begingroup\$ Even expert gamedevs tend to have a pretty poor track record at estimating how long tasks will take. ;) To guesstimate, for a stranger we've never met, making a game with undefined scope, on undefined tech.... who knows. Maybe a decade, plus or minus a decade? I have a feeling though that what you're hoping to get out of this question isn't really a time estimate. Are you just looking for validation that yes, you can make games? If so: YES, YOU CAN MAKE GAMES. Just start small, smaller than what you think "small" is. Build up your skills on something you can finish in a weekend for starters. \$\endgroup\$
    – DMGregory
    Oct 20 '17 at 9:57
6
\$\begingroup\$

WARNING: this answer can be depressing. It can be depressing in two fronts: A) Our tools and data on software (size and time) estimation are not that good, and B) It probably will take longer than you think.

Positive aspect: expending extra time studying and familiarizing with development tools is probably always a good idea. Up to what extend it is unclear. Yet, one of the best ways to do it is by using those tools, for example to develop a game. If you do not expect this game to be your final game, but one you do to learn, you will be good.


I will take for reference the case of a single developer working on Underrail engine and alpha game: Dejan Radisic. This was from 2008 to September 2012, at which point it went on steam early access (there were a few prereleases before), which game him money to hire some help, and the final version was completed on December 2015.

Therefore, Dejan Radisic worked for about four years alone, and then there were three more years working in a team. It is unclear how much it would have taken him to complete the task alone.

Consider that new people on the team would have required Dejan Redisic to teach them how to work with the engine and familiarize them with the code base, during this phase we would expect his output to be lesser because he is giving time to train the other developers. After this initial phase (which I have no idea how much it took, or how relevant was its impact) we would expect the team to have some level of synergy, meaning that their output would be greater than if they were working on it independently. Furthermore, some tasks cannot be broken apart, and adding many developers will not make them any faster.

See: The Mythical Man-Month.


Next, we know that the output of a developer is roughly stable in terms of lines of code per unit of time, regardless of language. It can be improved by incentives (although the effect of incentives plateaus) and better tools and training. This is good news for high-level languages and tools, because using high-level languages will allow you to finish your work in less time. Furthermore, we know that number lines of code is the best predictor for software defects. Thus using a language that allows you to accomplish more with less lines of code (or an engine that allows you accomplish so much, with even less) are good in terms of software quality and developer output.

Of course, everything is a tradeoff… using high-level tools means that you will have less control over the performance. As a result, you may end with a game done in less time, with less defects… but that runs too slow.

See: Making Software: What Really Works, and Why We Believe It - see also: Greg Wilson - What We Actually Know About Software Development, and Why We Believe It’s True.

Note: We do not know how you compare to Dejan Radisic. Assuming that you are as bad (or good) as Dejan Radisic will result in a wrong estimation. Yet, I cannot control for this.

Addendum: We also do not know how many hours per day did Dejan Radisic put into the development.


Considering all that. Creating a game like Underrail, for a single developer should take somewhere from 4 years to 13 years (at the end Underrail was a team of 3 people for 3 years, plus the 4 solo years... 3*3+4=13; and I know that estimation is wrong because of The Mythical Man-Month).

Do you know Hofstadter's law? - The truth is that the majority of software development projects fail their estimation. We know that agile methodologies are arguably better; we can attribute this to the steady adjustments they do to their estimation during development. A common practice in agile teams is to multiply the estimation they get by some arbitrary factor... because It always takes longer than you expect (see Standing Group's CHAOS Report). In fact...

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Therefore, I may pick the arbitrary factor 3 and multiply our estimation to get a total time of 12 to 39 years. Then Hofstadter's Law.


On the other hand, most of that time is expend into creating a custom engine. If you use an existing engine instead, it will probably save you around 3 to 9 years of work.

If you use free art assets, or can get somebody to work on the art assets (sound, music, graphics, etc...) I would expect it would save you... ern... some time. It is hard to compare making assets with programming; also, the amount of work depends on how heavily your game depends on art assets. Let us say it is 50% of the time, just to be politically correct.

Now, if we start on 39 years, we take 9 years off, and half the time, we have: (39-9)/2 = 15 years.


Note: I base the above on what we know about software engineering and a single data point: Dejan Radisic working on Underrail. Do not consider this single data point statistically relevant. We also know that software estimation is susceptible to psychological anchoring (that is, given a guess estimate, even professional and well-trained engineers will yield estimates that approach the guess estimate given).


Finally, consider the Wait Equation[1]. We are steadily getting better developer tools and reusable software that will allow you to develop a similar product in less time. Therefore, there is an ideal wait time that optimizes the total time to finish a development task by taking advantage of the improvements in the technology.

It might be the case that it took Dejan Radisic three to four year to work on the game engine simply because the tools available at 2008 were not as good as those you find today. I do not think we have enough data to calculate the how much time you will save by just waiting to start your project (and taking that time to study software development and familiarize yourself with a variety of tools) by merit of improvement in existing tools and you getting better as developer.

[1]: The Wait Equation is the formula for the wait calculation proposed by Andrew Kennedy in his paper Interstellar Travel - The Wait Calculation and the Incentive Trap of Progress. The underlying idea is that given the improvements in travel technology, for a given arrival date to a destination there must be an ideal departure moment. Since tha article in Wikipedia has been proposed for deletion since I wrote this answer here a mirror, and two YouTube videos that mention it for context: The Race to a Habitable Exoplanet - Time Warp Challenge | Space Time and Will We Ever Visit Other Stars?.


Addendum: If you did pay attention, I told a lot of reasons why these estimations are wrong.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for your response - very useful. I've come to know from working in a quasi-development area that everything always takes longer than predicted! \$\endgroup\$
    – TCassa
    Oct 22 '17 at 10:30
  • \$\begingroup\$ @TCassa and going even further. You need a LOT of planning and most things fully decided before you can even get that incorrect prediction. \$\endgroup\$
    – user106170
    Nov 12 '17 at 17:50
2
\$\begingroup\$

Doing a prototype could be a good idea in your case. Do it as small as possible, like a single room with one NPC, a little bit a dialogue and/or combat.

This will let you:

  • Try out the underlying technology and learn
  • Spot some issues you may not have thought of
  • Get an idea of the amount of work involved

After this you can scope your full game based on what you want the final result to be and how much time you are willing to commit.

Building a full game as a one person team generally takes months even for an experienced developer, maybe even years. The usual advice is to start small. You can always expand more on a small game later - maybe that first prototype evolves all the way into a final product. Or you start a fresh one making use of all the skills you learned building your first small game. The important thing at your stage (and I believe the only way to truly answer your question) is starting to develop something.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .