[Question] State Machines and Animation, or Complex Components

[alter-kaker]

Hi, I am trying to implement a very simple state machine for my project, and I'm not sure what is the best way to integrate it with my hecs systems.

The requirements are very simple: at this time I have no need to control valid transitions; I only need to ensure that each entity has only one state at a time, that I know what this state is, and also I need to perform some actions on entry/exit for different stages. My issue is that I need to cache some information for each state (a list of texture coordinates), even if it's inactive.

I know very little about how hecs works, so I'm not sure what would be the best way to implement. I did read this article by Sander Mertens , but much of it goes beyond my requirements.

What I am trying to understand is what would be the best way to cache the inactive states? In a state machine component that holds the current state as well as inactive states? In separate components with an inactive flag? In an asset manager, with ids stored in the machine component? In a hashmap mapped to entity IDs?

Generally, what are some guidelines with caching data in hecs, or having components that store more than just a little data? How much is too much? Is it even a problem?

[Ralith]

Simple state machines in Rust are often represented with an enum that has a variant for each state. There's no reason not to use such thing in/as a hecs component.

Notions of inactivity or caching are difficult to consider out of context; as a general rule of thumb, prefer to avoid changing which components are had by large numbers of entities at high frequency, but don't bend over backwards to avoid changing them ever. Component sizes are generally not a problem. When in doubt, test your application's use case and profile; most likely ECS operations will never register in the performance of a real application that is doing other work like rendering or simulation.