6 ms·

>Games are traditionally single threaded and hard to parallelize. ECS and being able to safely run "systems" within your game concurrently is becoming a thing

>Games are traditionally single threaded and hard to parallelize. ECS and being able to safely run "systems" within your game concurrently is becoming a thing rapidly as "lists of objects" do not scale. I just checked Doom Eternal: it's running 81 threads. (Of course, not all of them are always active or doing things concurrently. It's just a datapoint.) Intel basically only wins by a non-significant margin at video encoding nowadays thanks to AVX512 which AMD does not implement. AMD wins or is comparable at a lower TDP on everything else.

p1necone 7y ago
Learning about ECS and how to use them made gamedev so much easier for me. Although now I'm hamstrung by only being able to work on games in languages/frameworks with a solid ECS library (does a good/community agreed upon one exist for rust yet?). ECS, the observer pattern, and behavior trees are probably the three main things that answered all the "how on earth do they build something this complex" questions for me.
- gentleman11 7y ago
  I would add state machines to any list of amazing techniques
  - p1necone 7y ago
    Definitely. Behaviour trees are kind of a special case/evolution of regular ol state machines, but I find both useful in different situations.
    - gentleman11 7y ago
      I was considering learning them soon for enemy ai. Are they useful in other situations too?
      - p1necone 7y ago
        Basic state machines are useful for controlling flow between different menus/game screens - this "current mode" state exists across iterations of the game loop so you need some kind of data based state machine. e.g. in say a jrpg you have "new game/continue" menu -> world map -> battles and character menu and back again. Edit: oh I misunderstood you - you were asking about behaviour trees. I haven't used them for anything other than controlling game unit behaviour (although not necessarily just enemy ai - one other example is using them to combine a bunch of simple actions into one thing that the user can tell a unit to do - so like an attack move in an RTS is actually "loop (is enemy nearby? -> no -> move towards location -> yes -> attack (which is probably it's own behaviour tree))
- Nullabillity 7y ago
  > does a good/community agreed upon one exist for rust yet? Specs? At least that's what Amethyst uses.
- steveklabnik 7y ago
  > (does a good/community agreed upon one exist for rust yet?). I just ran across this: https://csherratt.github.io/blog/posts/specs-and-legion/ https://csherratt.github.io/blog/posts/specs-and-legion/
nmfisher 7y ago
I read a Twitter thread the other day about id Tech 7 (the new engine underpinning Doom Eternal). Apparently there is no “main thread”, everything is scheduled to a set of jobs that can be executed concurrently. https://twitter.com/axelgneiting/status/1241487918046347264?s=21 https://twitter.com/axelgneiting/status/1241487918046347264?... I’ve been wondering if this will become de facto standard for multi-threaded/multi-core systems going forward.
- TwoBit 7y ago
  The EA/DICE Frostbite engine has worked like this for many years now.

p1necone 7y ago

Learning about ECS and how to use them made gamedev so much easier for me. Although now I'm hamstrung by only being able to work on games in languages/frameworks with a solid ECS library (does a good/community agreed upon one exist for rust yet?). ECS, the observer pattern, and behavior trees are probably the three main things that answered all the "how on earth do they build something this complex" questions for me.

gentleman11 7y ago
I would add state machines to any list of amazing techniques
- p1necone 7y ago
  Definitely. Behaviour trees are kind of a special case/evolution of regular ol state machines, but I find both useful in different situations.
  - gentleman11 7y ago
    I was considering learning them soon for enemy ai. Are they useful in other situations too?
    - p1necone 7y ago
      Basic state machines are useful for controlling flow between different menus/game screens - this "current mode" state exists across iterations of the game loop so you need some kind of data based state machine. e.g. in say a jrpg you have "new game/continue" menu -> world map -> battles and character menu and back again. Edit: oh I misunderstood you - you were asking about behaviour trees. I haven't used them for anything other than controlling game unit behaviour (although not necessarily just enemy ai - one other example is using them to combine a bunch of simple actions into one thing that the user can tell a unit to do - so like an attack move in an RTS is actually "loop (is enemy nearby? -> no -> move towards location -> yes -> attack (which is probably it's own behaviour tree))
Nullabillity 7y ago
> does a good/community agreed upon one exist for rust yet? Specs? At least that's what Amethyst uses.
steveklabnik 7y ago
> (does a good/community agreed upon one exist for rust yet?). I just ran across this: https://csherratt.github.io/blog/posts/specs-and-legion/ https://csherratt.github.io/blog/posts/specs-and-legion/

nmfisher 7y ago

I read a Twitter thread the other day about id Tech 7 (the new engine underpinning Doom Eternal). Apparently there is no “main thread”, everything is scheduled to a set of jobs that can be executed concurrently. https://twitter.com/axelgneiting/status/1241487918046347264?s=21 https://twitter.com/axelgneiting/status/1241487918046347264?... I’ve been wondering if this will become de facto standard for multi-threaded/multi-core systems going forward.

TwoBit 7y ago
The EA/DICE Frostbite engine has worked like this for many years now.