System to store object specific data. about godot-port HOT 23 OPEN

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.

from godot-port.

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

from godot-port.

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

from godot-port.

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

from godot-port.

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

from godot-port.

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

Place > PlayerBuilding > Warehouse
                             |
                      StorageComponent

from godot-port.

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.

from godot-port.

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.

from godot-port.

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

from godot-port.

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

from godot-port.

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.

from godot-port.

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

from godot-port.

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?

from godot-port.

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.

from godot-port.

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.

from godot-port.

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

from godot-port.

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

from godot-port.

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

from godot-port.

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

from godot-port.

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.

from godot-port.

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

from godot-port.

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

from godot-port.

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.

from godot-port.