EnTT: Gaming meets modern C++ 3.9 (ECS library and much more) • Hacker News Board

Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)

#21

Post by jazzfool » Wed, Dec 22, 2021, 4:39 AM UTC

ncake wrote: post #19

jayd16 wrote: post #14

Earlier quoted context omitted.

In some ways ECS could be considered stateless, as the entity holds the game state as raw data, while the system operates on that data without holding a state of its own. How would you implement ECS, a system for tracking the state of game entities, in a stateless manner? Can you expand on that?

I'll try to explain what I mean. Suppose you want an in game character to change the displayed weapon in their inventory. Stateful way: your Inventory Manager component iterates through its private array of item entities to mark their model components as shown or hidden, then calls the dependency injected character's avatar component to update its animation state. Stateless way: you flip an integer in character's str…

The "stateful" way you present is not at all how you would approach that problem in an ECS. I think you misunderstand what ECS refers to.

Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)

#22

Post by verdagon » Wed, Dec 22, 2021, 4:41 AM UTC

BoorishBears wrote: post #10

ncake wrote: post #9

Unpopular opinion, but I personally think ECS has no place in C/C++ game dev. Every supposed advantage is either curbed by limitations of the language (e.g. serialization) or can be implemented more logically in a stateless manner.

I can't even imagine game dev without ECS. There's more performant architectures but it's such a useful mental model for the type of rapid iteration games need that so many people are willing to put up with the drawbacks

What are some of the more performant architectures?

Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)

#23

Post by ShrigmaMale » Wed, Dec 22, 2021, 5:27 AM UTC

jazzfool wrote: post #21

ncake wrote: post #19

Earlier quoted context omitted.

I'll try to explain what I mean. Suppose you want an in game character to change the displayed weapon in their inventory. Stateful way: your Inventory Manager component iterates through its private array of item entities to mark their model components as shown or hidden, then calls the dependency injected character's avatar component to update its animation state. Stateless way: you flip an integer in character's str…

The "stateful" way you present is not at all how you would approach that problem in an ECS. I think you misunderstand what ECS refers to.

Maybe for ECS newbie, please say more on how you would approach this problem?

Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)

#24

Post by chmod775 » Wed, Dec 22, 2021, 6:56 AM UTC

ncake wrote: post #19

jayd16 wrote: post #14

Earlier quoted context omitted.

In some ways ECS could be considered stateless, as the entity holds the game state as raw data, while the system operates on that data without holding a state of its own. How would you implement ECS, a system for tracking the state of game entities, in a stateless manner? Can you expand on that?

I'll try to explain what I mean. Suppose you want an in game character to change the displayed weapon in their inventory. Stateful way: your Inventory Manager component iterates through its private array of item entities to mark their model components as shown or hidden, then calls the dependency injected character's avatar component to update its animation state. Stateless way: you flip an integer in character's str…

I don't think the terminology you're looking for is not stateful/stateless, it's single source of truth vs multiple.

The latter is an anti-pattern, and you can do either with ECS.

With ECS nothing prevents you from just having the "physical" game state as the single source of truth, and having the render function for the player inventories look at it.

Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)

#25

Post by BoorishBears » Wed, Dec 22, 2021, 7:00 AM UTC

verdagon wrote: post #22

BoorishBears wrote: post #10

Earlier quoted context omitted.

I can't even imagine game dev without ECS. There's more performant architectures but it's such a useful mental model for the type of rapid iteration games need that so many people are willing to put up with the drawbacks

What are some of the more performant architectures?

Data oriented instead of object oriented:

https://gamedevelopment.tutsplus.com/articles/what-is-data-o...

Instead of treating each object as a collection of components, you can operate on bags of components

So say in you're modeling space invaders:

  every frame: 
    for enemy in enemies              
      enemy.transform.y += 10

The CPU is hopping to a random memory address where your "transform" component is located before modifying it, over and over.

Data oriented would be something like:

    each frame:
      for transform in transforms
         if transform is enemy
            transform.y += 10
         if transform is player
            transform += input

So you get cache locality as you're running through your transforms.

Now imagine if instead of space invaders we're trying to model say blades of grass. Suddenly we go from a very cache unfriendly method to something that's cache friendly, branch prediction friendly, and easy to parallelize.

If you want to experiment with it Unity has some great examples under their new DOTS system

https://github.com/Unity-Technologies/EntityComponentSystemS...

APIs can make data oriented more ergonomic than my contrived example implies, but it's still not nearly as intuitive as ECS imo.

To me data oriented subsystems are fine, but not as a core concept for your game's architecture.

Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)

#26

Post by meheleventyone » Wed, Dec 22, 2021, 7:14 AM UTC

chrsig wrote: post #17

jayd16 wrote: post #13

Earlier quoted context omitted.

>Or triggers to abstract away cascading updates. Triggers might be counter productive. Games usually have a fundamental concept of a game loop. Changes can be processed in the loop and side effects can be processed in the following iteration. Triggers would cause this processing to be unpredictable (or at least harder to predict). ECS provides a clean way to define the order in which systems are processed each loop.…

That's a great insight. I wonder if it'd be practical to defer them until after the causal operation was complete say translating all positions, then calling all of the triggers for the positions component. that'd keep everything in tight single purpose loops and preserve cache lines. fair enough that it'd probably make execution order harder to predict, but also in theory it would be in the realm of possibility to g…

A lot of game engines have the concept of messaging that tends to happen synchronously or with a delayed dispatch step which sounds very similar to triggers. The latter comes with a verification cost because the message might not be valid anymore.

The thing with the actual gameplay layer is your often processing mainly heterogeneous elements rather than homogeneous so all the worry and focus on cache is largely academic for most kinds of game.

Re: EnTT: Gaming meets modern C++ 3.9 (ECS library and much more)

#27

Post by jayd16 » Wed, Dec 22, 2021, 7:14 AM UTC

ShrigmaMale wrote: post #23

jazzfool wrote: post #21

Earlier quoted context omitted.

The "stateful" way you present is not at all how you would approach that problem in an ECS. I think you misunderstand what ECS refers to.

Maybe for ECS newbie, please say more on how you would approach this problem?

ECS is closer to the second way that was described. Data is represented as arrays of structs (referred to as components), similar to what was described. Systems can mutate or read these structs.

A physics system might change the position components while a decoupled rendering system might read that position components and the rendering details components to add draw commands.