# Entity iteration order in ECS system

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!

• 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? Feb 18 at 8:58
• @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. Feb 18 at 9:09
• 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. Feb 18 at 9:27
• @Philipp unless we are talking about lockstep (which is popular in RTS situations). This might be out of this questions scope though. Feb 18 at 9:28
• 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? Feb 18 at 10:10