System to store object specific data.

[Beliar83]

We need to think about how want to store data for objects, for example ships, warhouse and maybe other objects need to have an inventory.
The old UH used an entity component system for that, meaning that each object/entity had a dynamic list of components that defined what they can do. I'd like to have something that works at least similar but fits with godots system.

[Beliar83]

I am currently reading this : https://willnationsdev.wordpress.com/2018/04/05/godots-node-system-a-paradigm-overview/ which seems interesting.

[YeldhamDev]

The Godot way would be using OOP, making a good use of inheritance. Something like:
Place > PlayerBuilding > Warehouse

[Beliar83]

That would lead to the problems listed in the "The Birth of Component-Based Systems" section of the above link.

[YeldhamDev]

Most of the problems listed there are a result of bad implementation, not with OOP itself. A good implementation keeps things as abstract as possible, so that a Camera doesn't need to be a Bird.

But most importantly, Godot and its node system are tailored with OOP in mind. While using an ECS system with it is possible, it's pretty much a hack that tries to fight the engine itself.

[Beliar83]

I am not saying that we should implement an ECS, but something that solves the problems than an ECS solved but works with the features that godot (or rather gdscript) offers.

For example, I mentioned ships and warehouse for the reason that both have a storage, but one is a building and the other is a unit. As far as I see the storagemanagement/handling should be the same for both, but I do not see any base class for both where we would add the storage management to.

One way, as far as I see it, is to make a storage class/node and add that to the warehouse, ship and other objects that have a storage.

Whatever we use, we also need to check if a node that is a storage has another node nearby that also is a storage, without hardcoding that data (as a list of Node types that are storages).

[YeldhamDev]

So, use the best of both worlds, then? Something like:

Place > PlayerBuilding > Warehouse
                             |
                      StorageComponent

[Beliar83]

Yes, something like that would be good, if we can find a good way to check for that component. I think godot HAS some methods that would help with that.

[aaronfranke]

Buildings could contain "Inventory" which would be an array or object representing the inventory. For objects with no storage this could just be set to a size of zero.

[Beliar83]

I don't really like having fields in base classes that are only used in a few of them.

[Beliar83]

Anyone thinks that something like https://godotengine.org/qa/384/component-based-system might be a good idea?

[aaronfranke]

Yes, that's the other option, having a child node with the script that acts as the component. It's generally a good idea, the UI can just be told to search for a child called "Inventory" or something.

[Beliar83]

Hmm, you know, now that I think about it, referencing components just by their name is also a good usage of duck typing.

[Beliar83]

Ok, here is my basic idea:

• Components are, at least to the code that interacts with it, only data storages.
• An object is considered to have a component if it has a node with that name (maybe grouping component nodes under a single "components" node?)

Would everyone be ok with that or does anyone have a better idea?

[Beliar83]

If no one has a problem with that, I'll go ahead and try to make a branch for that to see how well it works with godot.