Replies: 1 comment 1 reply
-
I have thought about that as well, both in terms of how to handle arbitrary components and how to handle components with some variation, like the consumable component. I probably won't implement it in this version of the tutorial, as it would mean some refactoring, but a solution that came to my mind (and which I would probably use if I would redo this) is to have the Here's an example how that could work with one of the classes. consumable_component_definition.gd would be expanded like so:
Then, in the concrete sub-classes you could implement the proper function. For example, healing_consumable_component_definition.gd would look like this:
You still would need to type all the different types in each of the definitions. However, I do feel like it would improve organization. Then, in the entity you could just use the following line:
Each definition class would then be responsible for instantiating the correct type. And as you are likely to create consumable components and their definitions together you can just add or remove consumable components without the need to edit entity.gd. The only thing to remember is to implement the |
Beta Was this translation helpful? Give feedback.
-
Title, is that possible? i'm trying to make it so the script automatically handles any components it has, rather than making more and more if statements for every item i make, which scales badly
Beta Was this translation helpful? Give feedback.
All reactions