1
\$\begingroup\$

While learning ECS architecture, I found out that some ECS libraries gives me unsorted entity ids when iterating over filtered entities in system. (Seems like deletion algorithm in sparse set is the reason...)

Won't it be a problem if you need deterministic results(Networked game, replay feature, etc...) for your game?

For example, assume there's entity 1 and 2. They have a CollisionBox component.

When they hit an entity with a GoalBoundary component, the one who hits it first wins.

If somehow entity 1 and 2 arrived Goal at the exact same frame, then iteration order will be critical to the game's result.

Maybe my example is not perfect, but hope you get the point - Sometimes iteration order is so critical in game logic and I am confused about understanding how these kinds of issues must be solved in ECS architecture.

Any help will be appreciated, thanks!

\$\endgroup\$
6
  • \$\begingroup\$ I'm not very familiar with such architectures, but are you using a 'pure' ECS architecture? Does it prevent you from having some end-of-loop processing to check if multiple objects hit the goal? \$\endgroup\$
    – Sacha
    Feb 18 at 8:58
  • \$\begingroup\$ @Sacha just imagine how many goal states there could be and it quickly becomes impractical to resolve them in a second loop. Iterating over stably sorted entities is so much simpler. \$\endgroup\$
    – Kromster
    Feb 18 at 9:09
  • \$\begingroup\$ Determinism is overrated. In networked multiplayer it's impossible to achieve determinism due to network latency. Clients don't see the exact same game state anyway. The only state which should matter is the state of the server. And for replays, it's often easier to replay the results instead of replaying the inputs. \$\endgroup\$
    – Philipp
    Feb 18 at 9:27
  • \$\begingroup\$ @Philipp unless we are talking about lockstep (which is popular in RTS situations). This might be out of this questions scope though. \$\endgroup\$
    – Kromster
    Feb 18 at 9:28
  • \$\begingroup\$ Yes, I think determinism is not a point here. What I am really curious about is - If entity iteration order affects the result, is it misdesigned ECS code or not? And if it is, how should I avoid it? \$\endgroup\$ Feb 18 at 10:10

1 Answer 1

0
\$\begingroup\$

Firstly - check your ECS dictionary implementations - are they really producing non-deterministic results and why, what is the source of randomness there?

I'm suspecting this could be isolated and resolved. If not - you might need to re-introduce the order yourself. Iterating over stably sorted list of entities is so much simpler than any competing conflict resolutions.

However there's a second side to it - do you really need the identical results? In some cases (RTS lockstep) this is vital, but on others (e.g. FPS) you can just record the resulting world state and replay from that (without re-simulating it).

\$\endgroup\$
5
  • 1
    \$\begingroup\$ One source of non-deterministic iteration order can be when the ECS framework is able to parallelize the exectution of a system. When multiple threads process different chunks of entities then all bets are off. \$\endgroup\$
    – Philipp
    Feb 18 at 9:22
  • \$\begingroup\$ One source of non-determinism I found was from serialize-deserialize phase, where all entities and components are saved as some kind of snapshot. I used sparse sets to filter entities by component types internally, so deletion of entity during runtime results in unsorted entityId array. Then, serialize and deserialize entities in entityId order results in different iteration order when running systems... \$\endgroup\$ Feb 18 at 10:00
  • \$\begingroup\$ Anyway yes, sorting filtered entities by entityId is not that much hard(...with less performance tho), but what I wanted to know was that If entity iteration order affects the result, is it misdesigned ECS code or not. \$\endgroup\$ Feb 18 at 10:17
  • \$\begingroup\$ @GarlicDipping Let me rephrase your question - "Is the ECS be inherently non-deterministic or not?". Cos entity iteration order shall and will affect the result (only one agent can pick a single cake). The question becomes - "Should I care and fix it?". If you need repeatable simulation and stable outcome - yes. If you can just record the state and play it back - not. \$\endgroup\$
    – Kromster
    Feb 18 at 10:23
  • \$\begingroup\$ Well that's simple and clear wrap-up, thank you sir. \$\endgroup\$ Feb 18 at 10:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .