-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go full on ECS with abilities #159
Comments
Weapons fire can become an ability too; this could allow for a component that has multiple weapon abilities, if for whatever reason you wanted that. But would they act as independent weapons or as alternate fire modes? Maybe a toggle somewhere for that, or some sort of ID based matching where you can fire one weapon ability of each "fire group"? |
Alt-fire could actually be implemented as a special case of morphing components like in THANCS... |
I wonder if it could make sense to make even the most basic properties of objects into "abilities"? Things like their cost, size, HP, whatever... |
Yeah, that could help with making the game more generic - for instance, instead of only being allowed to colonize planets, you could colonize space objects that have the Colonizable ability, which specifies things like a population cap... |
The "generic math / abstract interface methods" feature of C# 7 might be useful when it comes to stacking abilities... |
I've been talking with hyunahri on Discord and he explained a lot of things about ECS to me. So your entities, as I've discovered, are basically just IDs that are stored in a repository and linked to abilities (ECS components, but let's not confuse them with vehicle components) by the repository. Even their linkages to other entities (e.g. ships contain components) are mediated by abilities. The abilities are the meat and potatoes of the architecture, storing data and performing functions as you'd expect. They are linked to entities via the repository. Or for convenience they can be stored within the entities. The third part is systems, or interactions as hyunahri called them. An interaction is an object passed in to a special Interact function on an ability, which is called using the visitor pattern on each ability belonging to the targeted entity, where the HoldComponents ability would pass the interaction on to the components too. Each interaction could also request the abilities to be sorted in a particular fashion so that it can do what it needs, e.g. armor gets hit first while repair priorities are respected. Stats and stacking can be a special case of interactions: there can be a GetStat interaction type which queries the abilities for their contributions to various stats such as speed and tonnage, passing in the current values and returning the values as modified by the function. This is a very powerful feature because it allows new stats, modifiers, and stacking rules to be plugged in at will. The data files, then, will become more flexible as any entity can be any type of object, or several types, or a brand new one we don't even have a file for yet. I'll want to redo the data files to take advantage of that flexibility! Serialization will also be much simpler as there will be less inheritance in the code. |
This is going to require rewriting everything... Probably going to have to save this idea for a future project! |
Could probably do it in steps though:
|
What needs to be cleaned up?
Abilities are basically a cobbled together version of the Entity-Component System architecture, with various game objects being the entities and the abilities being the "components". Maybe we should go ahead and rewrite the ability system to behave more like a "proper" ECS architecture?
How will this benefit us?
Abilities will be strongly typed. So instead of:
it will be:
or something like that.
This also ties in with #156; defining abilities as their own classes allows for greater flexibility in modding.
What potential drawbacks are there to making this change?
We need to be careful not to break custom abilities; right now they're defined in AbilityRules.txt, so we'd need a way to translate that over so modders don't need to code the ability rules in C#.
Data file structure will probably want to be changed, so we'll need to define a converter to convert SE4 mods to the new format. This will be less of an issue than previously, as no one's making new SE4 mods anymore, the only one that's active is Fusion Mod and its authors would love to convert it to FrEee once FrEee is more stable!
The text was updated successfully, but these errors were encountered: