Replies: 1 comment 1 reply
-
|
Hi @lzuwei, Ark is an archetype-based ECS, which means it is primaryly optimized for fast queries and iteration. With this architechture, adding and removing components are relatively costly operations, as entities and their components need to be moved between archetype tables. So for a state machine with frequent transitions and states represented by components, this architecture is not optimal. You can find benchmarks for typical ECS operations in Ark in the Benchmarks chapter of the user guide. An architecture that suits this use case better would be a sparse-set ECS. In sparse-set ECS, adding and removing components is fast, but queries and iterations are much slower. However, I am not aware of any mature impementation in Go. Among the somewhat mature implementations I am aware of (mainly archetype-based), Ark is still the fastest in all aspects. See the go-ecs-benchmarks repository for a comprehensive overview. An alternative way to implement an FSM could of couse be to just use a state variable in a component. Given that you expect around 10 states, and Ark's fast query iterations, iterating all entities and using if/else or switch statements inside query loops would probably be faster than using components for states if transitions are very frequent. Another alternative could be to store the entities (just the plain Hope this helps and answers your question. Best regards, |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi mlange, thank you for contributing an ECS to the go community.
I am interested in using an ECS to develop a simulator for my work. Ark looks really like a well polished implementation of a ECS in go and I am excited to give it a try. However, the simulation contains entities that has a complex state machine (ie: approximately 10 states). In every time step, entities in different states need to be iterated and depending on their current state and attributes they will transit to a new state. Essentially the simulation requires implementing numerous state transition logic.
We can implement each state as a component but not sure Ark is efficient enough to manage this since we will be adding and removing components each time you transit to a new state.
Happy to hear your thoughts designing efficient FSMs in Ark or an ECS. Thank you!
Beta Was this translation helpful? Give feedback.
All reactions