Designing a Scalable Combat System with Composition

[dragonforge-dev]

@VISIX

I’m trying to get a better understanding and practice with composition, so everything I did with the project was based on it (using Mastering Composition for Beginners in Godot and Using Composition to Make More Scalable Games in Godot for reference).

I thought I had watched that first video, and maybe I did, but I was also confusing it with the one in this thread:

Godot Architecture: 7 steps for more flexible, extensible, testable code (video)

Really good intro. Around 12:20 You recommend replacing hardcoded $NodePaths. That was good. You then said you can use @export variables. That was less good. $NodePaths should be replaced with @onready variables. For example, in your code, you changed this to an @export variable. var start_button = $layout_margin/layout_options/start start_button.pressed.connect(on_press_start) This is a common thing I see in people with Unreal/Unity experience. The drawback to @export var methods are it clut…

Feel free to read my comments on that.

I then talked at length about composition in Godot in this thread:

A discussion about composition and code complexity

Those are very kind words. Thank you. Sorry it took me so long to get to this, I spent the weekend replacing my broken CPU cooler. General Thoughts First, naming is a very powerful thing in programming. What we name things tends to direct how we shape things. I talk about the Manager Anti-Pattern at length on this forum. (That link will take you to a post that links the other posts as well.) In this case, you need to carefully define what you mean by “component”. Like @normalized said, you s…

I’m linking them because it’s a LOT to type.

First Video

This guy kinda gets components, and kinda doesn’t. First of all, his naming SUCKS, but he shares that with the second guy. You don’t name something “Component”. You just name it what it is. Sprite2D isn’t called Sprite2DComponent, so why should yours be called that?

Also, an Input component seems like a good idea, but it actually breaks the Single Responsibility Principle that he’s talking about while he’s showing off his components. In fact, SRP is really hard to implement well, and when you do it looks dumb. Using SRP would mean you have one object for left input, another for right input, and well… you get the idea.

Instead, input should be handled by the object that is affected by it. Or, by a component in some cases. But not an Input component. Here’s why: That Input component doesn’t DO anything. For the Movement component to work, it has to rely on the Input component existing. This is called tight coupling, and again, goes against the SRP he says he’s following. (The one exception to this is if you’re using a Command Pattern.)

I stopped about 5 minutes in, but overall, he was discussing the benefits of components well. I just don’t feel like watching an hour of video.

Second Video

In the second video, his intro is good, but his naming convention SUCKS. Notice how everything he made was called HealthComponent and HurtBoxComponent. Right after he got gone explaining how Sprite2D and AudioStreamPlayer are components.

In this post, I walk you through creating a Health component:

Am I doing Components/composition right?

So Godot itself is a system built on the idea of components. A Node is a component. A CharacterBody2D is a component. The CollisionShape2D that you have to attach to the CharacterBody2D is a component. Now imagine that to use ANY of those nodes, you had to go through a ComponentManager object. Imagine how frustrating and complicated that would be. Componentization is the process of splitting a larger system into smaller re-usable pieces that can be re-used. In object-oriented programming, it’s…

It even has a cool icon:

And a number of visual representations for the same component:

Your Stuff

I would say the Resource approach you’ve adopted is the best one. I walk someone how to implement something like that in this thread here:

How to approach modifiable item stats

So you can do this a number of ways, and a few have been discussed. Have a Dictionary that stores all the stats. Have Resources that store all the stats and add them as variables. I think it helps to ask what you want the whole thing to look like? So let’s say this is a 3D game, and I want to drag and drop gems onto a sword, and that modifies the sword’s properties. I also physically want to show the slots so that the player can customize the look of their sword. In the original description I…

For your needs, basically you are using a Command Pattern. So if you keep all the details inside your Resource object, you can just attach them to the Weapon. Those Resources can even have generic functions in them like attack() or use(). Then you can just call those functions and have custom code when necessary.