New Coder Having Issues With Composition + Resources

Paultimate

Hi all hope youre well.

So Im very new at this and ive watched dozens of tutorials and I even made a simple game but it was mostly just me following along.

I have gotten to the point i want to have a better foundation when coding and I found that composition looked like what I was after. I could make nodes that were like HealthComponent, MovementComponent, etc. However I also saw resources looked really good for modularization too and want to use that, i.e. playerstats, enemystats etc.

The issue im not able to wrap my head around and videos arnt getting through my thick skull is how do i incorporate these things in the below example?

Say I have a HealthComponent, i put it on the player and i put it on an enemy. I assume they use the same thing because thats the point of the components right? Anyway i then have 2 stats files. 1 for player and 1 for enemy. How do I get the HealthComponent to use these without being tired to one or the other?? The tutorials ive watched had a HealthComponent that just had a default health value. How do I make a single component read from a resource file i want it to? Even if i have 100 diff ones and only one HealthComponent?

xyz

Paultimate

class_name Stats extends Resource
@export var some_stat: float

class_name HealthComponent extends Node
@export var stats: Stats

Select a health component node and you'll see the stats property in the inspector. Here you can create a new embeded resource of type Stats that will be assigned to that health component instance.

Alternatively you can pre-create resource objects in the inspector, save them to disk and then do the above just instead of creating a new resource object, load one that you previously created from the disk.

Btw, don't use the suffix "component" in the names of your component classes. It just makes the names repetitious and bloated.

Paultimate

Thanks for trying to help but I just cant get this to work. I think im going to ditch custom components and just use resources till components become something really needed. Im spending too much time trying to work this out and its just too frustrating.

xyz

Paultimate I'm not a big fan of this "components" approach but this is rather straightforward to setup.

The main question is; does your type of game really needs fully modular components. Should the player health really be the same as enemy health? They often aren't.

You can look at this approach in a simpler way. Don't think about those nodes/scripts as "components", but merely as a way to break down entity functionality into several script files. They don't need to be "reusable" at all.

You also need to decide what exactly are you storing in stats resources. If you plan to store actual runtime state of the stats as well (e.g. max_health and current_health) then you'll need to duplicate the original resource object for each instance of an entity. The engine has a built in mechanism for automatically doing that (the resoruce_local_to_scene flag in Resource class). Although I would opt for storing max_health in the resource and current_health in the component.

And as a general advice - don't overdesign and abstract your systems in advance. Implement them in a simple, dumb way first. Only start looking for possible abstractions after a system becomes functional.

housatic

xyz Implement them in a simple, dumb way first. Only start looking for possible abstractions after a system becomes functional.

^ Good advice. I'm a fan of making things dynamic from the start, but only in ways I've done a hundred times before and know will work. Don't throw away your time/energy on learning new features before you actually need them

(Edit: though as a beginner you might not be able to tell what's excessive and what you do actually need to learn... but that's what forums are for 😃)

xyz

housatic Yeah the ironical thing is that people with least experience tend to dwell in premature-abstraction-land the most. When the concept of abstractions clicks with you for the first time, you tend to get so delighted with its apparent power that your common sense completely evaporates.

As any system designer worth their salt will tell you; adequate abstractions are almost impossible to premeditate. Instead, they reveal themselves during the implementation process. The bigger the system, the more true this is.