Skip to content
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

Open
ekolis opened this issue Jan 24, 2021 · 8 comments
Open

Go full on ECS with abilities #159

ekolis opened this issue Jan 24, 2021 · 8 comments
Assignees
Labels
breaking This change will break savegame compatibility. idea A large scope idea that needs to be discussed before it can be implemented. technical debt Things that would make the code cleaner but deliver little to no value to users.
Milestone

Comments

@ekolis
Copy link
Owner

ekolis commented Jan 24, 2021

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:

var thrust = ship.GetAbilityValue<int>("Movement Standard");

it will be:

var thrust = ship.GetAbility<MovementStandardAbility>().Thrust;

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!

@ekolis ekolis added idea A large scope idea that needs to be discussed before it can be implemented. technical debt Things that would make the code cleaner but deliver little to no value to users. labels Jan 24, 2021
@ekolis ekolis added this to the future milestone Jan 24, 2021
@ekolis
Copy link
Owner Author

ekolis commented Jan 25, 2021

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"?

@ekolis
Copy link
Owner Author

ekolis commented Jan 25, 2021

Alt-fire could actually be implemented as a special case of morphing components like in THANCS...

@ekolis
Copy link
Owner Author

ekolis commented Jan 25, 2021

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

@ekolis ekolis added the breaking This change will break savegame compatibility. label Feb 8, 2021
@ekolis ekolis moved this to To do in FrEee Core Jul 30, 2022
@ekolis
Copy link
Owner Author

ekolis commented Dec 10, 2022

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

@ekolis
Copy link
Owner Author

ekolis commented Mar 12, 2023

The "generic math / abstract interface methods" feature of C# 7 might be useful when it comes to stacking abilities...

@ekolis
Copy link
Owner Author

ekolis commented Jun 8, 2024

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.

@ekolis ekolis pinned this issue Jun 8, 2024
@ekolis
Copy link
Owner Author

ekolis commented Jun 8, 2024

This is going to require rewriting everything... Probably going to have to save this idea for a future project!

@ekolis
Copy link
Owner Author

ekolis commented Jun 15, 2024

Could probably do it in steps though:

  1. Convert existing abilities to ECS component-type abilities, and IReferrable to IEntity
  2. Convert functionality of subtypes of IEntity (e.g. Ship, Planet, Component) to abilities (splitting them up into granular pieces such as CanWarp, Colonizable, and InstallableOnVehicle)

@ekolis ekolis modified the milestones: future, alpha-10 Jun 23, 2024
@ekolis ekolis self-assigned this Oct 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break savegame compatibility. idea A large scope idea that needs to be discussed before it can be implemented. technical debt Things that would make the code cleaner but deliver little to no value to users.
Projects
Status: To do
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant