Damocles wrote:I dont even mean, not to USE a scripting solution for the development of the games logic.
It lets you engineer and test complex mechanics with less code and boilerplate.

But once the logic works out as expected (eg, the algorithms, balancing and general structure),
then convert the parts that are most performance critical (eg anything often or costly called in a loop, or is too heavy in the GC) into a C language representation.

So first develop the logic, then "recode" it for the release version. (its more work, and kind of messy, but it might be the only solution
to keep the logic running at the intended performance level).

Already been suggested, and I think Joshes response was that, that approach is the last resort for if the current ideas all fail to pan out.
It's problematic in the coding, but yes, it would provide the required performance.

But I think Josh has found the magic of rapid prototyping, which C is not capable of. (Compiling sucks for this, JIT solutions are better, but no-compile scripting is the best option for this) Which if you have a look at how Josh has progressed with his potential "solutions" matches the reverse of that thread of thought. (script, JIT, then finally compiled)

It should be pretty simple, the point of the thread is just asking us "What features don't need to be in the 1.0 release build on day one." and with this in mind I believe most people like myself are willing to see LT released day one without mod support so long as it is implemented at a later date. Of course, if something is helping Josh finish LT then by all means, continue working on it. However, if something is becoming a headache and doesn't necessarily need to be part of the game, then drop it for a while, get 1.0 out and then patch it in a few months later.

BFett wrote:It should be pretty simple, the point of the thread is just asking us "What features don't need to be in the 1.0 release build on day one." and with this in mind I believe most people like myself are willing to see LT released day one without mod support so long as it is implemented at a later date. Of course, if something is helping Josh finish LT then by all means, continue working on it. However, if something is becoming a headache and doesn't necessarily need to be part of the game, then drop it for a while, get 1.0 out and then patch it in a few months later.

This is a good summary of the "don't need modding" perspective.

What I was trying to say earlier is that the difference between an LT that is entirely hard-coded in a compiled language (and thus probably not supporting easy modding), and an LT that is built to support scripting (and thus easy modding) is enormous.

Basically, if Josh shipped a fully-compiled LT as LT 1.0, and then wanted to create a version whose gameplay was mostly made out of scripts, that latter version would nearly be an entirely new game: LT 2.0, only available months later at the very best, leaving Josh zero time to implement new & improved smaller gameplay features.

This could be done. There's nothing technically impossible about it. The question is whether taking the time to return to a purely compiled Limit Theory makes the most practical sense -- in terms of features and when LT 1.0 ships -- or if we'd all do better by Josh continuing to work toward a high-performance scripting solution for LT 1.0.

Moddability is a perfectly reasonable thing for people to say they'd be OK without, which is why I included it in this poll. It's only if we start looking at it in practical terms, as what happens if Josh actually tried to go back to a fully compiled LT, that scripting/moddability starts to look like an extremely expensive feature to cut.

When I chose to vote for (or against, however you are looking at it) moddability, what I was thinking was that Josh should not go out of his way to make the game easier to mod. I don't think a single minute should be wasted making it easier for someone else to mod the game. If he wants to have tools and stuff like that later, that's fine, but it doesn't need to be there day one. I think most people will be satisfied playing the vanilla version for awhile before they feel like they need to mod it.

Talvieno wrote:The reason he has it in scripts is because he couldn't mentally handle writing it all in C or C++. The fact that scripts also happen to be moddable is a coincidence, and not the main reason he switched. The game might be faster, but it would be a lot more difficult to code. It wouldn't really be solving a problem, but reintroducing the same one that made him put parts of it in scripts to begin with.

Hey Tal, I'm not quite sure about this. As said before, using a scripting language for implementing gameplay is very good in my opinion and as you wrote, it might be difficult to handle in C/C++. But replacing scripted parts of the engine, while the whole context is already set and working, is a lot easier from my experience.
So, I would definitely support implementing gameplay using a scripting language, the modding which comes as a coincidence as you mentioned, is fine, too. But the aspect of moddability should have no impact on getting the engine performant and thus, should be dropped where needed.

As for me, I have never been using any mods, but related to some other posts that suggest implementing moddability later: It's one of the hardest things to make an engine capable of mod support if it wasn't designed in the architecture from the beginning on.

smurfer wrote:As for me, I have never been using any mods, but related to some other posts that suggest implementing moddability later: It's one of the hardest things to make an engine capable of mod support if it wasn't designed in the architecture from the beginning on.

This. In that case is usually just doesn't happen or modding is reduced to hacking around in the game files and executables.

Indeed I would be happy with a procedural universe and ships with the cool graphics, with some commerce and (first-person) fighting (so "driver AI") as well as ship configuration. Having this released would already be a great step forward. Prio 1.

Then my subjective list:
Prio 2: I think adding mining and the scanner can throw the game in an interesting direction. Add missions to the mix as well.
Prio 3: Fractions and reputation/upgraded mission system (with some "fraction AI" thinking strategically)
Prio 4 is large scale conflict/economic activity with LOD scaling and possibly the emergent production-based economy.
Prio 5: Fleet operation and strategic empire management with colonies (i.e. the player can become a fraction, sort of)
Prio 6: Research, Info as a commodity

Nice UI is a must. But it is a given. Moddability is the way to make your game a long-duration success, but not a requirement of Kickstarter, so it's not prioritized (even if I would love it).

It amuses me that the option the most people selected by far was the one option that Josh can't remove without completely rewriting the game - and wouldn't be able to add back in later without completely rewriting the game.

Talvieno wrote:It amuses me that the option the most people selected by far was the one option that Josh can't remove without completely rewriting the game - and wouldn't be able to add back in later without completely rewriting the game.

It amuses me that you still come up with this argument, since in my opinion that's not exactly true . I don't know if you read the other posts, but for me it's not removing moddability for the sake of removing just something, but allowing to reduce moddability to replace bottlenecks with C/C++ code. And that isn't exactly rewriting the whole engine, it's similar to the optimisation pass that is commonly done when the gameplay is set.
Will it come to a point where modding isn't possible at all? I don't know. Will it be hard to reimplement it then? Definetly. But as said before, personally I don't care much for moddability, so I'd rather allow replacing bottlenecks now and have full functionality and performance than trying to find another scripting language.

This post by Josh himself very clearly states that this isn't an option (actually, that's most of the point of the top half of the post). The problem was that there was already too much C/C++ code for him to mentally handle. To continue programming, he had to offload it to other languages with simpler code.

Removing that would quite literally be rewriting the whole engine, because he'd have to strip out all the stuff that let him do that in the first place and then re-code everything that's in the files - shaders, procedural algorithms, game logic, etc. Then, assuming he could even finish the game after going back to square one and battling the original problem (there was too much C/C++ code), he would have to take everything back out of the game and put it exactly as it is now - undoing all the work that he did to take out the moddability in the first place. Then he'd be back where he is now: trying to figure out how to make the game both moddable, and fast.

But, as you don't care for moddability, you'd probably be pleased to know that at that point, the game would probably never be moddable. I doubt he'd try to get the moddability working again after all that. Personally I think moddability is important to help maintain a strong community and encourage growth and development. Without mods, Limit Theory would be fun only to the players that wanted LT exactly as it was released.

So, essentially:
1. Josh has problem he cannot solve; brain absolutely cannot 100k+ lines of C
2. Josh solves problem by introducing script; script simpler and easier to handle than C
3. Script permits modding. It is not the purpose, but merely a byproduct
4. Josh has problem he has not solved, but is working on solving; the game is slower with script instead of C
5. Your solution: Undo all progress from last 2.5 years, GOTO 1, try to solve the original problem which he made less headway on than this one (which is what prompted this in the first place)

To a non-programmer, it might seem trivial to roll back to an earlier version, but in actuality, so much has changed since pre-LTSL that he really would be rewriting the whole engine. That's the reality of any project. Code evolves over time, and it especially does so in a 100k+ line project. Trying to roll back to a previous version would require him to almost completely rebuild the engine, and then he would have to rebuild all the stuff in the scrips, in the engine. (And that's before putting him up against the wall that was even more impassable than this one.)

Personally I would suggest he multithread it. While that would also require him to rewrite large portions of the engine, he wouldn't run up against the 100k wall, he wouldn't have to rebuild everything in the scripts, and the game would be faster. Alternatively, he could hire another coder or two... but frankly, I don't think he has the funds left for that.

Regardless, there is no conceivable way that undoing all the work of the past 2.5 years would actually move the project forward. In fact, it would bring it to a standstill and guarantee it would never be released.

Talvieno wrote:It amuses me that the option the most people selected by far was the one option that Josh can't remove without completely rewriting the game - and wouldn't be able to add back in later without completely rewriting the game.

Even if this is correct, it is not surprising or illogical: nobody said you have to invest work to make it not-moddable!
But modulability includes more than having part of the features in scripts. It involves for example having all features interesting to mod in script, it may involve documenting the language/options/headers or making your script interpreter/integration more stable/complete in order to fulfil needs that are not present now but may come with mods.

I would love modding, but I say: do not invest 1 minute for the sake of modding. Obviously do not invest 1 microsecond for the sake of removing or avoiding moddability!

Talvieno wrote:Okay, just going to try to clear up some misunderstandings here.

I'm not sure if there are any misunderstandings

Talvieno wrote:This post by Josh himself very clearly states that this isn't an option (actually, that's most of the point of the top half of the post). The problem was that there was already too much C/C++ code for him to mentally handle. To continue programming, he had to offload it to other languages with simpler code.

Yes, I read that, but even there you can find different opinions. But given that this is really -- independend from code design, which I believe has a big influence -- Josh's mental barrier, I would repeat myself again: Yes C++ code might get unstructured when evolving, using scripting then is a natural structuring of the complex things that happen in the background while saving time. But: cherrypicking bad-performing parts of a very well structured scripted code and replacing these is quite modular and therefore better to handle. It's not near rewriting everything from scratch from my experience.

Talvieno wrote:
Removing that would quite literally be rewriting the whole engine, because he'd have to strip out all the stuff that let him do that in the first place and then re-code everything that's in the files - shaders, procedural algorithms, game logic, etc.

See above, it is not everything, it is just very well defined parts. Of course it will take a certain time, but it should be by far better managable then writing everything from scratch.

Talvieno wrote:Then, assuming he could even finish the game after going back to square one and battling the original problem (there was too much C/C++ code), he would have to take everything back out of the game and put it exactly as it is now - undoing all the work that he did to take out the moddability in the first place. Then he'd be back where he is now: trying to figure out how to make the game both moddable, and fast.

Apart from the fact, that I still think the engine architecture plays a big role when talking about "too much C/C++ code", you are right with the second part. This is exactly why I voted for moddability, because I don't want this to have an impact on possible replacements of bottlenecks (sorry for repeating that often, but I can't see any argument against this, apart from the mental barrier which doesn't fit in my opinion for the mentioned replacements).

Talvieno wrote:
But, as you don't care for moddability, you'd probably be pleased to know that at that point, the game would probably never be moddable. I doubt he'd try to get the moddability working again after all that. Personally I think moddability is important to help maintain a strong community and encourage growth and development. Without mods, Limit Theory would be fun only to the players that wanted LT exactly as it was released.

Never said I'm pleased about non-moddability, it doesn't do no harm. But in this case, I think it might prevent other possibilities that have more potential in my view.

Talvieno wrote:
5. Your solution: Undo all progress from last 2.5 years, GOTO 1, try to solve the original problem which he made less headway on than this one (which is what prompted this in the first place)

No, no, and no . This is not what I'm talking about. Again: Finish up gameplay by scripting, profile and then replace bottlenecks, that's all.

Talvieno wrote:
To a non-programmer, it might seem trivial to roll back to an earlier version, but in actuality, so much has changed since pre-LTSL that he really would be rewriting the whole engine. That's the reality of any project. Code evolves over time, and it especially does so in a 100k+ line project. Trying to roll back to a previous version would require him to almost completely rebuild the engine, and then he would have to rebuild all the stuff in the scrips, in the engine. (And that's before putting him up against the wall that was even more impassable than this one.)

I'm not a non-programmer and I certainly don't want Josh to roll back to some old version, see above.

Talvieno wrote:
Personally I would suggest he multithread it. While that would also require him to rewrite large portions of the engine, he wouldn't run up against the 100k wall, he wouldn't have to rebuild everything in the scripts, and the game would be faster. Alternatively, he could hire another coder or two... but frankly, I don't think he has the funds left for that.

Multithreading is some good advice, too. But I honestly doubt that this is less expensive than replacing... you guess it... just bottlenecks

Talvieno wrote:
Regardless, there is no conceivable way that undoing all the work of the past 2.5 years would actually move the project forward. In fact, it would bring it to a standstill and guarantee it would never be released.

Talvieno wrote:It amuses me that the option the most people selected by far was the one option that Josh can't remove without completely rewriting the game - and wouldn't be able to add back in later without completely rewriting the game.

Even if this is correct, it is not surprising or illogical: nobody said you have to invest work to make it not-moddable!
But modulability includes more than having part of the features in scripts. It involves for example having all features interesting to mod in script, it may involve documenting the language/options/headers or making your script interpreter/integration more stable/complete in order to fulfil needs that are not present now but may come with mods.

I would love modding, but I say: do not invest 1 minute for the sake of modding. Obviously do not invest 1 microsecond for the sake of removing or avoiding moddability!

That makes sense, CSE. I would say he should stop putting any effort into making the game moddable if he could reasonably do it easily after release, but certainly don't rip out what he already has in.