nexustix/godot-nexustix-utilities

Fork 0

Use composition instead of inheritance for Entities #17

New issue

Closed

opened 2026-02-23 00:53:42 +00:00 by nexustix · 5 comments

nexustix commented

2026-02-23 00:53:42 +00:00

Owner

No description provided.

nexustix added the

pondering

label

2026-02-23 00:53:42 +00:00

nexustix added this to the Ready for Kellerspiel milestone

2026-02-24 21:21:03 +00:00

nexustix commented

2026-02-25 16:45:08 +00:00

Author

Owner

It is unclear if this is going to be worth it. Since Entities are plain data objects most of the Node based approaches won't work properly. Using nodes would require to declare a bunch of "Data Scenes" and that might be a silly idea.
The idea is that Entities should be mostly plain data with utility functions, so inheritance should work well enough for now.
If composition is to be used there needs to be a cleaner way to check for a "has a" relationship, and so far none has been discovered.

It is unclear if this is going to be worth it. Since Entities are plain data objects most of the Node based approaches won't work properly. Using nodes would require to declare a bunch of "Data Scenes" and that *might* be a silly idea. The idea is that Entities should be mostly plain data with utility functions, so inheritance should work well enough for now. If composition is to be used there needs to be a cleaner way to check for a "has a" relationship, and so far none has been discovered.

nexustix commented

2026-02-25 16:49:38 +00:00

Author

Owner

There is an option for a blind approach using "best_component" in Entity checks. That would require calling code to be aware of all viable components ahead of time, and necessitate the components to always be registered under the same name.

This may be viable and worth a try, since it would stay reasonably clean from a data point of view. And clean structuring with consistent naming scheme would be desirable anyway.

There is an option for a blind approach using `"best_component" in Entity` checks. That would require calling code to be aware of all viable components ahead of time, and necessitate the components to always be registered under the same name. This may be viable and worth a try, since it would stay reasonably clean from a data point of view. And clean structuring with consistent naming scheme would be desirable anyway.

nexustix commented

2026-02-25 16:50:40 +00:00

Author

Owner

It needs to be decided what to do if an Entity needs more than one of a component; should lists be used?

nexustix commented

2026-02-25 18:15:11 +00:00

Author

Owner

@nexustix wrote in #17 (comment):

There is an option for a blind approach using "best_component" in Entity checks ...

Attempted implementation of Inventory and Item using this approach: 489f866cf8

@nexustix wrote in https://git.nexustix.net/nexustix/godot-nexustix-utilities/issues/17#issuecomment-103: > There is an option for a blind approach using `"best_component" in Entity` checks ... Attempted implementation of Inventory and Item using this approach: 489f866cf8

nexustix added the

priority

normal

label

2026-02-25 18:22:34 +00:00

nexustix added

and removed

labels

2026-03-09 21:00:22 +00:00

nexustix commented

2026-03-09 21:58:56 +00:00

Author

Owner

The current approach has been refined a bit 7df1509936. Things seem to be in a good enough place to put a pin into this for now, and check if i gather new insights when consuming them in an actual project.

The current approach has been refined a bit 7df1509936. Things seem to be in a good enough place to put a pin into this for now, and check if i gather new insights when consuming them in an actual project.

nexustix closed this issue

2026-03-09 21:58:56 +00:00