#Creating More Generic Systems?

9 messages · Page 1 of 1 (latest)

slender parrot
#

For my game I am going to have a bunch of different kinds of enemies. I am going to have some common logic for all the enemies and some logic specific to each enemy.

Whats the best way to make systems that can operate over multiple kinds of enemies?

I could imagine myself making a component enum called enemy that holds all the kinds of enemies I have in my game, then just calling my systems with filters for enemies. That seems like it would work. But I was wondering if there was some other way of doing it.

I have never needed to have a system be this generic before, so I wanted to try and catch any problems I might have before they arise.

unborn rune
#

Typically with ecs you wouldn't have a type for each specific enemy, rather your enemies are defined by their components - which essentially define their behavior.

So if you have a goblin and a dragon, they both have hit points and defense, but the dragon might have a BreathesFire component. So you have many systems that operate on enemies with health and defense, but probably only 1 for Fire breathers

slender parrot
#

Ahh, you know, I was thinking about this, and I think you might be right. My enemy components should probs just be empty components mostly used for filters. And my actual components should be things like shooting, moving, and so on.

#

Which is strange caused it's not how im used to thinking about things

#

Instead of getting the answer to my question, I think I now what to rewrite my game. Which might be fine I guess lol

#

And the reason we write our programs like this is for performance reasons, right?

unborn rune
#

Not necessarily, modelling your components as behaviors/attributes just kind of fits with ECS I guess. The way you were doing it sounds very much like OOP which is going to end up with a lot of the same pitfalls - like attaching way too much behavior to a single entity. Then you end up with huge systems touching all different parts of your game which is basically just a swapped out version of a big monolithic oop class. You want to keep your components small and simple (within reason). It makes it easier to reason about your logic and change things in isolation.

#

Tends to result in writing a lot more code but it will scale up way better than OOP - at least that's been my experience

fierce kestrel
#

Having general components also makes it easier to have enemies share certain abilities. Instead of just the dragon breathing fire, you can have anyone else breathing fire if you add the component.