The point I am making is, if the devs are really genuinely serious about game development as a business, rather than a personal hobby, they can definitely come up with solutions to their problem, maybe it's an issue with lack of staff? hire more, lacking in funding? try crowdfunding.
It might seem difficult, but there are solutions and the true test is the attitude.
Look if the devs came out and said the game was just a personal hobby, and released it for free for everyone to play around with, I doubt most people would complain about development time.
While I understand the point you are making and it is a valid one, I would like to point out that the perspective you are taking is one of the consumer who does not understand the industry (which is understandable and shouldn't be expected don't get me wrong) vs the
actual reality of the industry. This isn't just a game design issue but generally an "any technical undertaking" issue. The real truth is that over 60% of all technical projects
fail even at billion dollar companies or government funded projects with top talent and huge budgets. That's only in the last decade or so too. Before then it was more like 80%. There are very good reasons for this.
This stat should not be taken as a reflection of a poor attitude or a lack of trying by the devs involved in those projects. (Though there certainly are plenty of technical managers who feel this way - the best ones understand because they once were down in the code/design trenches themselves. The worst tech managers are business managers with no experience in the tech industry taking this same opinion: "Why can't we just make this happen??")
It's not that laziness or discontent doesn't happen, trust me it does. (Though I don't believe that is the case for Starsector by any means.) But that is rarely the cause of project failure. Most of the time, the reason for failure is:
Spoiler
A) Most common reason: Changing requirements or poor or rushed early design foundations causing the scale of the project to get out of control and become unmanageable even when making simple changes. The cost of training and acquiring new talent becomes overwhelming because the project complexity requires months or years of specialized knowledge before any new features can be added or, even, any bug can be fixed. Seriously. It happens to the best of companies throwing millions at projects and willing to hire industry experts at the top of their respective fields.
B) Changing technology thresholds or competing projects obsoleting the original project.
C) Management wanting or promising a feature before they have spoken with their experts - and then when they do and realize the cost or time to implement the feature is more than the project sponsor is willing or able to tolerate yet the feature is required. Project terminated as a result.
D) The project relies on 3rd party software or hardware - and that 3rd party discontinues support or makes changes that are incompatible with the project's implementation of the 3rd party component.
Many people are used to other industries that are more standardized and therefore its easier to "make things happen" by hiring an expert or throwing more money at the project. If a pizza company wants to increase their output they can expand their kitchen and add more staff and ovens. That is fairly simple if probably expensive. The only way that can backfire is if they don't have the actual customer input to support the additional output and can't ever return their initial investment. It is so, so
so much more complex than that with a technical project.
Technical projects (including games) just don't work that way. Even though there are some standards, code is often flexible enough (it needs to be) to allow someone to really dig themselves into a hole that they can't get out of.
Ever heard of
? The more you rush a tech project the more you will find yourselves in this kind of situation. And a developers worst nightmare is stumbling upon a "Rube Goldberg Machine" kind of design and being asked to change the final result or to change a component of the machine into something else while
preserving the final result. For example from the video: "Can we change the result to soda from lemonade?" or "Can we just skip the bathroom altogether and still get lemonade?"
Sorry if this is a long explanation, but I hope it helps explain some of the considerations being made by any dev and why it can be confusing for the end user to make heads or tails out of some projects' ability to succeed or their propensity to fail. Hopefully it also pointedly explains why long dev cycles tend to pay off a lot more than short ones.