3 ms·
What a great question. Part of the answer comes from the question itself, which defines the problem as a well-funded long-term project with almost no hard spec
by wildermuthn 6y ago
What a great question. Part of the answer comes from the question itself, which defines the problem as a well-funded long-term project with almost no hard specifications beyond “open-world sci-if that will be hailed as one of the greatest games ever made.”
So on one hand, you have enough time and resources to hang yourself in a thousand different ways. And on the other hand, you have a genie-wish specification that thinks money and time can solve any problem.
Already, we can see that we have two problems - software engineering and product management - and among these two, product management is the hardest due to the formulation of the problem itself.
The first thing that should have been done is reduce the budget, timeline, and scope — focusing on innovative gameplay rather than innovative technology. The most obvious first result of this smaller scope is not making your own game engine. That should have been the first huge red-flag for the project. If you give talented engineers unlimited time and resources, and tell them to build any sort of “best ever” product, they will happily go down premature-generalization rabbit holes and never come out, creating spectacular architectures that shine in technical art museums (if such things existed) but fail in production. Premature generalization kills projects more often than premature optimization, as it is the leakiest of all abstractions due to solving problems that only exist in our imagination of the future.
So the answer is 1) reduced budget, scope, and technical innovation, and 2) gameplay innovation of existing open-world RPG technology set in a new genre (sci-if).
The hard part here is that gameplay innovation may require technological innovation: so the most important software choice is finding an existing open-world technology that is 1) available for license/purchase at a decent cost, and 2) is extensible and performant enough to handle gameplay innovation.
The problem as I see it isn’t that these technical considerations of buy vs. make weren’t asked. It is that they were asked in the context of having seemingly unlimited time, budget, and ambition.
Reduce your timeline. Focus your ambition. Choose proven technology. At least then you’ve got a shot at making what people want!