search

unknown-horizons / godot-port

Unknown Horizons Godot Engine Port
https://www.unknown-horizons.org
GNU General Public License v2.0
665 stars 83 forks source link

System to store object specific data. #23

Open Beliar83 opened 5 years ago

Beliar83 commented 5 years ago

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 commented 5 years ago

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

YeldhamDev commented 5 years ago

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

Beliar83 commented 5 years ago

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

YeldhamDev commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Place > PlayerBuilding > Warehouse
                             |
                      StorageComponent
Beliar83 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Beliar83 commented 5 years ago

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

aaronfranke commented 5 years ago

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 commented 5 years ago

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

Beliar83 commented 5 years ago

Ok, here is my basic idea:

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

Beliar83 commented 5 years ago

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.

Beliar83 commented 5 years ago

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.

YeldhamDev commented 5 years ago

I'm going to take a deeper look later, but just a heads-up, use tabs instead of spaces for indentation.

Beliar83 commented 5 years ago

Is that specified somewhere? I am used to spaces from python.

YeldhamDev commented 5 years ago

Engine's default, and specified in the official style guide.

Beliar83 commented 5 years ago

Right, I must've changed it back when I first started with godot. If everyone agrees with it I will change it back.

YeldhamDev commented 5 years ago

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.

willnationsdev commented 5 years ago

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

Beliar83 commented 5 years ago

@willnationsdev Heya, thanks for that link. It seems interesting, at least for me personally.

Royber121 commented 4 years ago

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.