Discussion Computed/Derived components

Hello everyone. Currently working on the input handling for my more or less pure ECS game and I had a question. Its about handling instances of esseintially the same data that is viewed through different lenses and wether each view should have its own associated component for caching or calculate the derived values on demand. Here is an example from my game.

I have a system which captures the courent mouse screen-position and puts it into a singleton component.
Now of course most systems are not interesten in the screen-position of the mouse, but the world position. So here comes the first dilemma for me.

1. Should I remove the ScreenPosition component and replace it with a WorldPosition one which is populated by my input-system? But what if some system needs the screen position for some reason, then that system would have to get that data again itself.
2. Should I keep only the ScreenPosition component and have each system that requires the world-position do the conversion, using camera or plane or whatever, themselves? Wouldnt that introduce code duplication?
3. Should I keep the ScreenPosition component and also add a WoldPosition component, which is kept in sync, on the same entity? Either the system that captures the ScreenPosition also populates the WorldPosition or there is a second system that runs after the first one that performes the conversion. But now I have two components including essentially the same data, just "from different angles".

In my case it does not end there because actually most of my systems wont be interested in the world position either but the cell-position, calculated using a hex-grid. So then I would have to answer these questions again.

So im looking at either having the "Mouse" entity only having a ScreenPosition on it and all dependend systems convert as needed. Or having the "Mouse" include a ScreenPosition, WorldPosition and CellPosition component so that other systems dont have to do any work.

The same would also be true for all my entities which are "placed on the grid". Do they only use the builtin transform components and the cell-position is calculated on demand or should they have a CellPosition component which is kept in sync with the transform?

Im having a little issue of understanding the philosophy here. What is the ideomatic approach? I have a feeling aspects might also play a role in this discussion, but I havent figured out quite how yet.

Any help and discussion appreciated. Thanks.

 

In my opinion it's a tradeoff between memory and compute.

If you store every "view" of the data you will consume more memory.
If you don't you will need to compute the derived value.

Here it seems we are talking about a singleton entity so the added memory cost wouldn't be that big.

If we were talking about a data for every entity in your game (like the transform) then the memory cost would be much higher and the computational cost would be much more affordable. In that situation an IAspect may be you best bet to have the computational algorithm in one place in you cade and beging able to call it from any system.

 

Thanks for your response @WAYNGames. Yes, the basic trade-off is between performance and storage. I too am now thinking about putting the conversion logic into an aspect or maybe just an extension function or something. I would love to hear more peoples opinions