Zanteogo wrote: My point however is, at some point Josh did have a partly working game with many features that ran at what seemed like a at least an acceptable frame rate most of the time. The last couple dev videos DID have a ton of features working in them. Not all of promised features, and not perfectly mind you. I'm not saying he needs to go back to his last dev video and release that. I'm just saying that after 2 years of mostly sideways progress he perhaps needs to look at the fact that perhaps LT 1.0 can't be EVERYTHING he promised in the kick starter.
Two parts to this: first, are you saying that you would be happy if Josh released the last-working-version and was unable to ever modify it to include something new or fix anything, because it would then be too slow?
And second, I 100% agree that once he finds a basic platform that can be added to, he should definitely figure out an MVP and work towards that - he seems to be in this for the long haul :-p so we know we'll get all the features eventually. I think the real problem for now, is that he can't be certain he's found a basic platform that can be added to without slowing down too much without adding in lots of features to test the limits of it, and that kind of approach to an architectural problem (not a programming problem, which is why he hasn't solved it yet) is not really sustainable if he wants to release something in our lifetimes.
I have a hard time believing that removing any amount of features made no difference.
My understanding was that he would have to remove large number of basic features, and that if he did, he had no way of improving what was left.
Again, we SAW the game function to a reasonable degree without "just the graphics". I'm not saying just release a No Man's Sky clone, I'm not saying just re-release the prototype with slightly better graphics. I'm saying at the end of the day, if it means 2 more years of sideways progress with no reasonable end in sight, perhaps some sort of feature cutting needs to be put on the table for the 1.0 release. He can always patch up in the future.
I imagine it as a 10m-square yard, in which you plant an apple tree every 3m. If you see the yard with 9 trees in, it looks lovely, produces apples, and everyone is happy. But if your business model is to sell 100 trees' worth of apples, you're going to have to change something. You could just sell the 9 trees' worth, and they would be lovely, but you could never get more than that. To do that, you have to work out an alternative planting arrangement. And if apple trees don't produce apples unless they have 3m of space around them, you have to devise some cunning plan to make it work. If you try different arrangements and one of them ends up with co-mingled roots, you'd discard it. Another that is too susceptible to disease would go. And so on. Each time, you have to plant almost the entire yard with trees to see if they grow up straight and produce the apples, so it takes time and you have to accept that you may never find the right arrangement.
Of course there might a third solution that I already brought up, that perhaps this is just too much for one person and he needs to look for help at this point. Perhaps a combo of both.
Again I think you're 100% correct at this point - if you spend this long trying to find a new solution, pragmatically you need to speak to someone else.
To refer to points other people have made about developing in C rather than a script language - this is what I meant before when I said that Josh had made some terrible decisions using some inappropriate technology in inappropriate ways. Script languages (especially like Lua - I was shocked when he went for Python instead) are traditionally used to add modding support as has been said, because explaining how to call the engine from lower-level languages is a massive PITA. Using it to provide all your game above the render level, well, just leads to the current situation.
The JiT compiler was invented to improve performance, but not to the degree needed in this case. I remember developing one in the early 90's to replace PC Emulator code with more optimised versions that dynamically skipped checking some CPU flags, and in extreme cases, to chain dozens of instructions together into a single native block rather than re-interpreting each one every time; but the compiler itself takes a lot of engineering effort to support enough instructions in enough circumstances with enough optimisations to make it infeasible for one relatively-inexperienced developer to use as a substitute for a more standard architecture.
I've written floating-point CPU emulators in C and assembler, and even written compilers to take an intermediate language designed by us and output native C or assembler, and these require significant devotion of resource to do. Writing the game in C should really be Josh's first choice when faced the current problems, but it's almost impossible to tell someone that - they almost always need to discover it for themselves.