I have an Actor class that has a logic part and a graphical part. The parts are separate classes that know about the Actor, but not about each other.
Right now making a new entity involves inheriting the three classes, and I’m trying to create a clean way to communicate between them. I welcome feedback on which way to go.
The observer pattern or an event queue is one approach. The advantage is it gives a simple and clean decoupling…at the cost of having to write switch statements everywhere that reason about the type of the message.
The next approach would be casting. Casting is frowned upon, but I’m not sure it really is that much worse than just using messages.
Then there’s letting abstract or virtual methods accumulate in the base classes. This means that my base classes start becoming much more narrow and applicable to only this game, which feels like a poor job separating concerns. I also dont want sprawling base classes.
Maybe there is another approach I’m missing. I’ve been leaning towards either the first approach, or the third followed by refactoring. Maybe there’s something i can do with generics or turning the pieces into interfaces over classes, I’m not sure. Any thoughts?
I think this boils down to a categorization and parameter problem- if I think about messages as either being entity state/location messages, property messages, or menu option messages there’s only really a handful of categories and they can all go on the base classes without needing to give up type safety. Then the graphics class just has to interpret a state byte.
You can avoid sprawling base classes by dividing up your functionality more cleanly. You can give that behaviour to the objects instead of having them own it by default, then having to expand it again and again as you want to add more.
A very simple version of this might be just handing behaviour objects to an entity in its constructor, abstracted by interfaces if you don’t want to couple directly to implementations, and then just call them in your Entity’s update method.
A more complex example would be to look into an Entity Component System (ECS) where you define components that store data and systems that operate on entities that contain a given component, or set of components.
I know what you’re getting at with a messaging system, I’ve worked with a few myself, but they can be a bit of a pain to deal. That’s just been my experience though. Either way, whatever works best for you, I just wanted to give you another option that doesn’t mean a base class that grows and grows
Thank you for the advice! Composition of behavior objects, eh? That’s something to consider. When i think about it more, I need to be clear on how logic objects can interact with each other… your input might help that…
