A few helpful souls have put forward the idea that, if cutting a few features would help reduce the code complexity that is contributing to the time required to build Limit Theory's foundation, Josh should consider that option.

So let's consider that. Suppose you were Josh; you want to play Freelancer 2.0, and you've promised that LT backers can "be who you want." You'd really like to deliver on those promises, and you don't actually want to cut anything. But you've decided reluctantly that something has to go.

What would you cut? What, in your opinion, would have the least impact on the core Limit Theory experience for the maximum savings in code complexity and programming time?

Last edited by Flatfingers on Tue Jan 24, 2017 4:16 pm, edited 1 time in total.

this is probably the main factor why the performance dropped, as it required a script-language. It did not seem to work out as expected.
This could be shifted to a later release.
Better: just support basic definitions from a config file for now, such as scale of space, precentage chance of objects and event occurring,
and some tweaking values for the AI.

-> convert your already working simulation and GUI script to native C.
It will be messy and less flexible, but likely much faster.

Colonies

I dont like the idea of colonies with millions of people.
This kind of makes any endevor feel like a cucumber-trader in China.
You would just always feel unimportant compared to the whole population, or wonder why a colony of millions does not do more in space,
and you can easily dominate them.
Better scenario: you are a mercenary/trader in a remote area of space, a new frontier, with colonies of maybe a few hundred people.

Research

Feels to random. "unlocking" a tech tree is one thing. But "research" in its original sense feels just not plausible.
A space-flight era is not exactly a time of low hanging fruits anymore.

With 22 votes in at this time, it's still early to be drawing any conclusions.

But I will tentatively note that, of all the features that have so far attracted zero "I could live without it" votes, those features taken together describe a game that can be summed up as a "galactic economy simulator."

I thought there would be many features I would cut out but I only saw one "moddability"

EDIT: its definitely something not needed until atleast 2 or 3 updates into RELEASE according to Damocles: Moddability:

this is probably the main factor why the performance dropped, as it required a script-language. It did not seem to work out as expected.
This could be shifted to a later release.
Better: just support basic definitions from a config file for now, such as scale of space, precentage chance of objects and event occurring,
and some tweaking values for the AI.

-> convert your already working simulation and GUI script to native C.
It will be messy and less flexible, but likely much faster.

A couple of practical things to bear in mind on the "moddability" feature:

1. I strongly suspect that, from Josh's point of view, players being able to modify some parts of LT's behavior is not so much a designed feature as an emergent feature.

That is, he's trying to architect LT as a script-running engine because he needed that capability to write gameplay code faster. The fact that players would also be able to tweak scripts more easily than changing compiled code was just a nice side effect.

If I'm correct about that, then for the purposes of this poll it might be helpful to bear in mind that even if you don't care about moddability as a feature for you, Josh might still require scripting as a developer feature.

2. While it's easy to say, "stop trying to allow moddability," at this point removing it as a feature would mean rearchitecting LT -- again -- to get rid of scripting and just hardcode all gameplay functionality in C.

So when you select "moddability" as a feature to remove, you're approving another massive change to the foundation of Limit Theory. You might want to consider that practical consequence when choosing which features of LT -- as it exists today -- you would cut if you were the developer.

Flatfingers wrote:A couple of practical things to bear in mind on the "moddability" feature:
...

Hey, this is manipulation

What you described isn't wrong, but I voted for moddability because of a different aspect: The change of scripting languages in the past was mostly due to performance reasons. I'm still a fan of implementing via scripting to evaluate gameplay (not performance) early and then replacing bottlenecks by native C/C++ code. This reduces moddability to a certain extend, or the other way around: I personally don't want moddability to stand in the way when thinking about replacing code by native C/C++.

I'm glad no one voted for 'fractions'. Can you imagine how glitchy things would be if you didn't have decimals? I mean, things may end up just 'jumping' when you're at slow speeds or weird rounding errors because of truncation and such.

...oh wait, that says 'factions'.

Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.

Personally I think modding is the one feature that absolutely should not be cut no matter what.

Think about it this way. Vanilla Minecraft sucks. Skyrim is heavily benefited by mods, and modding has kept its community around. In fact, from what I can tell, moddable games - on average - keep their users around a lot longer and make them a lot happier than unmoddable games.

If you have to cut features from LT, people are going to like it a lot less. Modding could help towards neutralizing that.

I don't think he really needs to cut anything at all, though. I think he'll figure it all out.

I-War 2 would have died a horrible death in 2003 if it weren't moddable. Because it is moddable, it's still quite alive fourteen years after that. Even though there's only a few who play it, there are people who play it, and a serious TON of mods.

this is probably the main factor why the performance dropped, as it required a script-language. It did not seem to work out as expected.
This could be shifted to a later release.
Better: just support basic definitions from a config file for now, such as scale of space, precentage chance of objects and event occurring,
and some tweaking values for the AI.

-> convert your already working simulation and GUI script to native C.
It will be messy and less flexible, but likely much faster.

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.

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).