3 ms·

You seem to have deep fundamental misunderstandings about ECS systems. You can absolutely access multiple components in a system, for some reason you think a c

You seem to have deep fundamental misunderstandings about ECS systems. You can absolutely access multiple components in a system, for some reason you think a component and a system must have a one to one relationship, when really it’s many to many. The only caveat is that you have to think carefully about the order that some of your systems are executing in the game loop, since you want to make sure component data has been updated appropriately for later systems to act on. ECS is really the best way to make games. It lends itself well to rapid iteration and experimentation of new game concepts.

Jyaif 3y ago
> ECS is really the best way to make games. A little bit of nuance would go a long way. Even in games where ECS is a good match, having to implement a boss with ECS is wasteful in terms of dev time and performance: You have to create components and matching systems unique to the boss, where with a traditional approach you just have to create a single Boss class.
- Coder1996 3y ago
  I suppose it depends on how the ECS is coded. You could create a database table called "Boss," that contains all the Boss components. Then for each system, you create a function that operates on a Boss.
- deadbabe 3y ago
  A boss is nothing special it is just an entity, also after you beat up the boss you can have later enemies use components from the boss to reflect the players progress in killing enemies using similar mechanics as the boss, until you reach a final big boss.
  - TeMPOraL 3y ago
    On the other hand, the classical approach lets you treat the boss as the one-off actor of an one-off scene, which it really is. This narrows the scope of your work (and associated testing). Integrating it into your overall ECS means you either make all aspects of a boss fully generic, working everywhere, or risk someone at some point adding "SpecialLaserCannonHelmet_Boss1" component to a random mook and breaking the game.
    - deadbabe 3y ago
      It wouldn’t break the game, it just probably wouldn’t render correctly since a boss works with certain graphics. Having a one off actor is really limiting. You can create several boss components and build entire permutations of bosses just by mixing and matching them up, without writing specialized code. Designers can put together the entities without developer input.

Jyaif 3y ago

> ECS is really the best way to make games. A little bit of nuance would go a long way. Even in games where ECS is a good match, having to implement a boss with ECS is wasteful in terms of dev time and performance: You have to create components and matching systems unique to the boss, where with a traditional approach you just have to create a single Boss class.

Coder1996 3y ago
I suppose it depends on how the ECS is coded. You could create a database table called "Boss," that contains all the Boss components. Then for each system, you create a function that operates on a Boss.
deadbabe 3y ago
A boss is nothing special it is just an entity, also after you beat up the boss you can have later enemies use components from the boss to reflect the players progress in killing enemies using similar mechanics as the boss, until you reach a final big boss.
- TeMPOraL 3y ago
  On the other hand, the classical approach lets you treat the boss as the one-off actor of an one-off scene, which it really is. This narrows the scope of your work (and associated testing). Integrating it into your overall ECS means you either make all aspects of a boss fully generic, working everywhere, or risk someone at some point adding "SpecialLaserCannonHelmet_Boss1" component to a random mook and breaking the game.
  - deadbabe 3y ago
    It wouldn’t break the game, it just probably wouldn’t render correctly since a boss works with certain graphics. Having a one off actor is really limiting. You can create several boss components and build entire permutations of bosses just by mixing and matching them up, without writing specialized code. Designers can put together the entities without developer input.