godot-port
godot-port copied to clipboard
unknown-horizons
System to store object specific data.
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.
I am currently reading this : https://willnationsdev.wordpress.com/2018/04/05/godots-node-system-a-paradigm-overview/ which seems interesting.
The Godot way would be using OOP, making a good use of inheritance. Something like:
Place > PlayerBuilding > Warehouse
That would lead to the problems listed in the "The Birth of Component-Based Systems" section of the above link.
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.
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).
So, use the best of both worlds, then? Something like:
Place > PlayerBuilding > Warehouse
|
StorageComponent
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.
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.
I don't really like having fields in base classes that are only used in a few of them.
Anyone thinks that something like https://godotengine.org/qa/384/component-based-system might be a good idea?
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.
Hmm, you know, now that I think about it, referencing components just by their name is also a good usage of duck typing.
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?
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.
So, I have a working system up in the "component_system" branch. It is based on the, as of writing, current dev branch.
There are 4 main parts of this:
Components (component.gd) are simple data storages for the game logic.
GameObjects (gameObject.gd) are nodes that groups components. It needs to have a "Components" child node that contains the components. It has methods to access and check components by name.
GameSystems (gameSystem.gd) work with data of specific components.
The GameWorld (gameWorld.gd) should be attached to the map, it allows easy access to GameObjects based on what components they have. They are also where every GameSystem should be attached to.
I have modified the test world to have the "WorldPlace" node controlled by a "position" component and a "movement" system.
I'm going to take a deeper look later, but just a heads-up, use tabs instead of spaces for indentation.
Right, I must've changed it back when I first started with godot. If everyone agrees with it I will change it back.
Okay, I checked the system. I think I mostly got the gist of it, but as for how things currently stand right now, I don't see much use for it...
When the game start to get more complex it will probably make more sense to implement some parts using this method, but for now, OOP will get the job done.
@Beliaar Hey! I'm the author of that blog you linked near the top of this Issue (blog stats said it was referenced here). I did a quick read here and just wanted to pop in and mention that using component-like nodes can be pretty performance-draining on large projects, based on some benchmarks another guy named MysteryGM did. I gave an explanation in this Reddit thread (2 relevant comments, second one demonstrates an alternative implementation using Resources). Let me know if you have questions about any of it, or feel free to ignore me if I'm just getting in the way.
@willnationsdev Heya, thanks for that link. It seems interesting, at least for me personally.
Well this issue seems to be dead. I looked at the possibility to use resources for data storage. You can look at it here https://github.com/Royber121/godot-port/tree/data-as-resources.
I made a very basic inventory resource. In the base classes you can export Resources that child classes could potentially use. If you want a child class to have an inventory you just assign it to the exported resource. It seems to be very straight-forward for me.
