Now that we've had the weekend to decompress a bit after the sad news, I'd like to suggest a few practical things regarding the LT code.
First, the one question that drives everything else is this: is the current code sufficient to form the base for a playable game?
Is there enough of the necessary architectural/engine plumbing implemented so that other developers can focus on building actual gameplay features? Or are there hard problems remaining to be solved so that core gameplay functionality systems can be added and still deliver good performance?
My guess is that, in addition to the project code not being productionized (as Talvieno described), there are numerous gameplay systems and support systems whose core engine structures have not been completed at this time: procedural star system generation; a dynamic closed economy that's fun
and inflation/deflation-resilient
and handles a procedurally expanding universe; NPC faction behaviors (creation/hire/fire/expand/fail); tactical dogfighting (including "terrain" in space and ship management); operational fleet RTS; strategic empire management (including factional control of political zones); NPC AI that remains both plausible and surprising across all of those levels as new star systems are added; level of detail (LOD) processing so that all those things can be both simulated when a player-controlled asset isn't there
and can be reconstituted into details when a player-controlled asset is there; planetary colonies; mining; object fabrication processes to create products for markets; research; attractive and functional GUIs to manage every one of these systems; a save system that fully and quickly saves the entire state of the game universe; a working mod management system... and I'm sure I'm leaving out some other features that are important for any working/fun space game to have.
The question I'm asking is not, "Have those gameplay systems been implemented?" but "How much architectural stuff absolutely must still be solved and coded in order to support adding all those gameplay systems?" THAT is what we don't know because Josh never shared that detailed project status information publicly. (This isn't a criticism; just a fact.)
So the first thing, if anyone's serious about creating a more-or-less working version of Limit Theory, is to answer that question. Step 1 is to generate a complete project asset inventory: all of the code itself; all of the compilers and libraries and tools needed to compile and run and test and debug and profile that code; all licenses; all supporting resources (including François's soundtrack assets); and all documentation. (VERY important additional action here: who owns each of these assets? Specifically, beyond basic copyright, what legal ownership rights are asserted by Josh over each of the assets he created? If we're serious about trying to finish LT as a distributable application, this step cannot be skipped.)
Step 2 is to assess the status of all these assets: are they sufficient (and there must not be any interminable geek arguing over which tools are perfect) to complete an LT that runs natively under Windows?
Step 3 is to assess the status of the code itself: of the core requirements, to what extent is each completed? How much required architectural stuff remains to be coded to a working state? Where is the list of gameplay systems to be coded? What is the status of each one of these? Is there any project management information stored somewhere, e.g. in Trello?
Finally, if after answering all of the above questions nothing has jumped out to cause a reasonable person to conclude, "Nope, this really is impossible," then there's a last practical question that ought to be answered: how should "Let's Complete LT" projects be administered?
Free-for-all, where Josh drops all the existing code into a public git, declares all of it public domain, and anybody can do anything with it?
The One True LT, where all existing assets go into a private repo; one person (such as Talvieno) becomes the de facto owner who can invite specific people to access the LT code; and finishing the game is managed as a small private group?
Or something in between those options?
I'd still like LT to become a thing if that's possible. But that means someone has to do the work to answer the questions: 1) Is it possible? 2) How can it be done?
Those are the questions about the code. Now I'd like to briefly consider: what about Josh?
Obviously (I hope it's obvious), before anything else there's Josh's health and happiness. Nothing I say next means I know what's best for him on those counts, or that I think my opinion in this area matters.
But maybe there is something useful that might be said about Josh as a programmer.
Ateerix wrote: ↑Sat Sep 29, 2018 3:14 pm
Would it be more viable for Josh to scrap the idea of a game, and instead just make an engine other companies could use to make games? It seems like a lot of work went into solving problems other engines couldn't do, would there not be any value in this? Note: I am not a programmer and do not know if this is a viable idea or a good one.
I'd like to very gently suggest that this is mostly backwards.
As I closely watched Josh's progress on LT over nearly six years, I cannot escape the conclusion that it is an unbounded focus on engine programming that did LT in, and left Josh feeling so down today.
Ateerix, I do think you're onto something important when you talk about Josh's gift for "solving problems." The insights and code solutions Josh came up with are legendary.
The trouble is that "problems" always exist at multiple levels. And someone who's gifted at problem-solving at one level is rarely equally gifted at solving problems typical to the other levels.
Josh appears to be a world-class low-level coding maven. When presented with a specific piece of software functionality that needs a simple, performant, maintainable code solution, I would give that problem to Josh without hesitation and
know that the resulting code product would be a thing of beauty.
But I'd also put a time limit on delivering that working, tested code solution.
And I'd have someone else make sure his code integrates as needed with other/existing code.
And I'd have someone else design the overall system, including its component requirements, and keep team members focused on building those specific components.
And I'd have someone else manage the whole project, including both task prioritization and time limits per task, with engine features well-defined in pre-production and built out to a basic functional level first thing in production, with the bulk of production development time allocated to building gameplay-specific systems, then features; then integration and playtesting; then polishing.
Some of those someone elses might be the same person. But none of them would be Josh.
Working as part of a team, on solving software problems that are bounded by function and time, would, I believe, be the best application of Josh's talents. He could focus on using his eyeball-popping gift for solving specific problems in code -- unleash the graphics monkey!
-- while knowing that all of his efforts were going into a product with a serious chance at being completed and working well.
None of this is a criticism of Josh, either as a person or regarding what he accomplished with Limit Theory. It's a recognition that there are, in fact, limits to human competence. We can't be great at everything. To create complex new things, we need other people whose gifts complement our own.
I hope, if Josh takes away nothing else from Limit Theory, that this is something he will come to appreciate soon -- not as a sad reflection on human limits, but as a practical reason why working constructively with other people is tremendously satisfying: it's how great new things get made so that people can enjoy them.
Because I really, really want to see what amazing new things Josh helps to create.