Designing a Scalable Combat System with Composition

[VISIX]

I’m sure you’ve been told that many times, but WOW was that a very resourceful reply! Very informative and eye-opening!

I did forget to include in my post that I’m not exactly an experienced developer and I have only a single Asteroids clone as a finished project. If anything, I’d say I’m barely crossing over from a beginner to intermediate, and that’s probably a stretch. I admit plenty of the stuff you linked was way too advanced for my understanding as of now.

Based on the code the author of A discussion about composition and code complexity included, they actually used the first video I linked as reference as well.

@dragonforge-dev

[…] 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 have learned about composition so long ago that, clearly, I had forgotten its purpose. Instinctively, I knew why I’d want components for stuff, but I was completely missing the Single Responsibility Principle you mentioned. I had thought it was weird that the MovementComponent required InputComponent to work in that video’s code, and found it even weirder that they were communicating within the player script, but I hadn’t questioned it since the author of the video clearly has more experience than I do. Thank you for snapping me back to reality on that one.
I will also refrain from naming things “ThingComponent” from now on so I don’t get scolded for it!

Your post on Am I doing Components/composition right? was by itself far, far more helpful than every single video I have watched on the subject so far. You have also cleared my confusion about “call down, signal up” in there, too.

Although I don’t really see how I’m using the Command Pattern as you mentioned (and would love to find out how you identified that!), I’ll target this subject and follow through with the Resource approach! I did believe it was heading towards the right direction and you did say it was the best one, so I’ll capitalize on that. The post you linked with that was extremely helpful already, after all!

I’m sure I’m not going to immediately figure it out — in fact, even with all your help I still can’t really visualize how to make this scalable —, but at least you pointed me towards a concrete direction by pointing out the Command Pattern and how that could work with Resources. I’ll probably stop trying to approach everything as components and leave them for the upgrades as it sounds the most appropriate use for them in the context of my project.

Once again, thank you!