Components, lambda, callable, resource... class... I need help making my code more flexible

Question

I need help visualizing how I should build the idea I had, in order to facilitate the creation of a game.

I will give an example:

I want to instantiate an enemy in my game. This enemy scene randomizes 'what is this enemy' that will be instantiated, that is, the code linked to it checks how many items I have in my DB and selects one, so I can get the values of their respective variables and thus create it.

The DB has variables that is common to all enemies (i.e. life, attack value, defense...). However, there is a line from the DB that says, 'which way will this enemy attack'.

This is where my doubt lies... can I create components for each way of attacking and, through this code linked to the enemy scene (remembering that it is the same code and a single scene for everyone), link these components? "Go to the library, see which component is linked to the key you assigned as your enemy's way of attacking and 'fit it here'" ...or is this done with resources?! This part I have difficulty seeing how things fit together... =/

Because the enemy scene, it will have a Sprite, CollisionShape, AnimationPlayer... I don't know, it will have a HealthComponent... and this is common for everyone!!! I need to learn how I see in the DB what type of attack the drawn/instantiated enemy has and make it connect with it (.append component?!). This way, I think, I avoid creating a scene for each enemy. I have a single scene that can take on 'infinite' different characters (as I can have 10 components related to 'ways of attacking' and create combinations between them).

...I don't know, I could have a single scene called 'items' and within it decide, randomly, whether it is a consumable, usable item... and link attributes to it (i.e. my enemy can cause me poison, but this 'poison component' can also be used in the items scene so that when consumed, it will cause the same effect... just as I can have tiles in the game that, when stepped on by the player, would cause me poison).

The idea is to use the same item (in this example, poison) and link it to several scenes, allowing the game this flexibility.

*DB = Database

Answer 1

I do not understand the specifics of what you want. I do not know the nature of your database, and I do not know how your "components" are implemented. Thus, I will be answering in general terms.

---

Start by the idea that you want a factory that given an entry from your database (however you represent your database) will create an appropriate instance.

To create the instance, the factory would - at least - instantiate an scene. Once instantiated, it might also set properties based on the values form the database entry.

However, notice that nothing precludes the factory from:

• Creating a different instance depending on the values of the database entry.
• Or even creating multiple instances and composing them. Or creating multiple objects and composing them. I'm not making a distinction between instance and object, I'm highlighting that the factory can do whatever.

For example, you might want to create an instance of a Resource type, to set it to one of the properties of another instance. Note: an Script is a Resouirce and a PackedScene (a serialized bunch of nodes commonly referred as a scene) is a Resource.

And also for example, the factory might create instances of other scenes, and their instances as children to the main one.

---

You are making a factory, with code. With Turin complete code.

In fact, you might go the opposite direction: Instead of creating instances for things that the enemy will need and adding them to it, you have have an enemy scene with everything and then have the factor remove what it does not need based on the values of the database entry.

---

can I create components for each way of attacking and, through this code linked to the enemy scene (…), link these components?

I do not know what are the "components" you talk about (how are they implemented in Godot), but I feel you are limiting yourself. Whatever the components are, the factory can use.

---

need to learn how I see in the DB what type of attack the drawn/instantiated enemy has and make it connect with it

I do not know the nature of your database. I cannot help you with this.

---

The idea is to use the same item (in this example, poison) and link it to several scenes, allowing the game this flexibility.

You will need to define an API for these "components" to act. For example, the enemy can have a "poison component" (be that a Node, a Resource or whatever), but what does it do and when?

If the "component" is a Resource, you are going to need an API to effect them. For example, if the enemy will "cause poison" to the player character, there must be an interaction, for example a physics collision, that you need to handle. And then in the code that handles that interaction you need to be able to call some API that can take an arbitrary component (the "poison component" in this example) and "cause" it.

On the other hand if the "component" is a Node (or rather, I should say, an instance of a scene) it might be able to handle this itself. For instance the "component" might be a physics object that detects the collision and "causes" itself on any viable object that it collides with.

In this sense making an scene for each "component" is arguably more flexible, as this allows each "component" to have custom code, and gives them freedom to interact with other systems, without a central API.

---

With that said, you might need a combination of both: A Resource reference can scene, and a Node can reference a Resource.

Thus, you could create a custom Resource to represent your "component". And this custom Resource could have a PackedScene which you instantiate and add to the scene tree to effect the "component". And - of course - the Nodes in the scene might have scripts that do whatever is necessary.

Furthermore, the code that effects the "component" might also set a property on the scene instance to reference to the Resource itself.