0

So I'm currently working on a Game Engine for my University and I came to the point of integrating an ECS.

Thing is, I'm currently a bit unsure if it's okay to have setters and getters for specific classes. Like implementing a setter for my transform that lets the system that accesses the transform component easily add relative rotation/movement. I also tried to outsource these functions into a separate util class. Especially in cases where I would call the component from multiple systems which would lead to duplicate code if I didn't have any sort of setter or util class.

Now what I'm wondering do I waste some of the efficiency of the ECS and Memory alignment by including those setters/getters or does that not matter? I'm a little confused here due to the statement "components should be pure data".

Jonas Schindler
  • 3
  • 1

1 Answers1

2

Please keep in mind that there is no ECS police.

Typically, you'll want to have code that's easy to read first, then fully optimized second, because you know you need it fully optimized (because you profiled it and realized it was a bottleneck).

I doubt adding getter/setters to a component to ease the reading of the code and the interaction with the class will make any noticeable difference in performance.

Yes, components should be about data only, and having setters/getters that "massage" data still count as "data only" because your component will not do anything.

One point, though, I doubt the concept of "transform" is specific to a transformComponent, and so you could very well develop a Transform class and put all the utility functions you've developed in there. A Transform is still only data. Just a bit more complex than a int healtPointsLeft; variable.

So,

I'm wondering do I waste some of the efficiency of the ECS and Memory alignment by including those setters/getters or does that not matter?

I would suggest you go with either the setters/getters, or with using a Utility class that allows you to deal with your data, what's the most appropriate for each component.

Vaillancourt
  • 16,325
  • 17
  • 55
  • 61
  • One minor caveat is if the data transformation being done in the getter/setter is more efficient to do as a batch (and the cost of that operation has been profiled and determined to be a significant optimization target). The get/set approach will encourage writing code that acts on one item at a time, which might be slower than needed if you're almost always acting on big buffers of component instances. – DMGregory Sep 29 '22 at 19:31
  • 1
    @DMGregory Yes, and this will depend a lot on the game being made. As you say, profiling will help highlight where optimization should be done. – Vaillancourt Sep 29 '22 at 20:01
  • 2
    I like the phrase "there is no ECS police"! – amitp Sep 29 '22 at 21:11
  • Thank you for the answer. I was really confused by this because of currently integrating physics and I wondered how I would go about adding force from other systems that would be run on certain objects. Thought of special addition flags etc... But I'm just flowing with my Util Classes now and will be profiling a bit in the future. – Jonas Schindler Sep 29 '22 at 21:28
  • 1
    @JonasSchindler In our architecture, we use an external physics engine, and this engine is linked to our ECS via a pointer which we consider data in the componentBody. It works well. – Vaillancourt Sep 29 '22 at 23:50