Return to “Polls”

What LT features would you be willing to give up?

Individual character AI guiding ship behavior
Total votes: 5 (5%)
Large-scale conflict/economic activity
Total votes: 5 (5%)
Dynamic level-of-detail (LOD) scaling
Total votes: 1 (1%)
Procedurally expanding universe
Total votes: 5 (5%)
Procedurally generated ships and stations
Total votes: 2 (2%)
Atmospheric graphics
Total votes: 4 (4%)
Moddability
Total votes: 18 (16%)
Ship designer/editor
Total votes: 7 (6%)
Ship component configuration
Total votes: 3 (3%)
Emergent production-based economy
Total votes: 2 (2%)
Tactical dogfighting
Total votes: 5 (5%)
Fleet operations
Total votes: 5 (5%)
Strategic empire management
Total votes: 10 (9%)
Factions
(No votes)
Colonies
Total votes: 5 (5%)
Research
Total votes: 7 (6%)
Asteroid mining
(No votes)
Detailed scanner/sensor operations
Total votes: 4 (4%)
Information as a commodity
Total votes: 11 (10%)
Slick, highly configurable user interface (UI)
Total votes: 12 (11%)
Total votes: 111
Post

Which Features Would You Cut?

#1
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.
Post

Re: Which Features Would You Cut?

#5
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.


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

Re: Which Features Would You Cut?

#7
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.
Post

Re: Which Features Would You Cut?

#8
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. ;)
Post

Re: Which Features Would You Cut?

#9
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++.

Cheers, smurfer
Post

Re: Which Features Would You Cut?

#10
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'. :squirrel:
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: Which Features Would You Cut?

#11
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.
Image
Have a question? Send me a PM! || People talking in IRC over the past two hours: Image
Post

Re: Which Features Would You Cut?

#14
Ah, I see what you're saying. That makes sense, and is a valid point.

Another point I haven't addressed yet:
Your earlier post stated:
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.
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.
Image
Have a question? Send me a PM! || People talking in IRC over the past two hours: Image
Post

Re: Which Features Would You Cut?

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

Online Now

Users browsing this forum: No registered users and 1 guest

cron