#ECS: Design guidelines to split user input and runtime state into separate components?

5 messages · Page 1 of 1 (latest)

dusty monolith
#

Hi- I'm looking for feedback or design guidelines regarding the structuring of data into component(s).

Generally for any feature you need 1) some data provided by the user, and 2) some cached/runtime data calculated at runtime. The easy approach is to put all of that into a single component; however this has a few drawbacks:

  • it mixes "public" and "private" data, which forces using getter/setter accessors and prevent the use of the ..default() paradigm used in Bevy's built-in components (so, which users are familiar with)
  • any change to any data by default triggers the change detection for the entire component, which may not be desirable (for example in 🎆 Hanabi this triggers GPU shaders rebuild, which is costly)

So I'm looking at the alternative, which is to split the user-facing data from the internal runtime data. This is very similar to what Transform and GlobalTransform are doing (ignoring for a minute that you can set the GlobalTransform too). Or what Visibility and ComputedVisibility are doing too (maybe a better example):

  • one component for the public user-provided data: this component triggers change detection if the user changes it, which instructs the library to update any internal data based on that user data
  • one component for the internal runtime data: this component is entirely managed by internal library system with an expectation the user should/will not ever touch it

Is anyone having some experience with this design. Is there any drawback to that split? I'd like to get feedback before I make the move to switch 🎆 Hanabi to this; this would neatly (I think) solve some existing issues, but I don't want this to become a pain for the users.

Thanks! 💚

indigo marten
#

This is effectively the split I have with InputMap and ActionState in LWIM

#

I agree with your analysis on the whole

#

You should consider making the runtime data private, and only providing a bundle as a builder

dusty monolith
#

Thanks @indigo marten ! I did it and I think I like that design indeed. I'm not sure if this can be abused into making "too many" components (I'm thinking about Bevy's Style split now...) but in my case I went from 1 to 3 components and suddenly several pieces of code are simpler and feel less hack-y.