What are the advantages of having component logic in a "system" versus the component itself?

Question

For the past few days I've been trying to make my first game. I did some research on usual development practices and patterns and I settled on a composition system where the different components communicate using messages that the container-GameObject distributes.

For instance say that I press the attack key. The playerInput component sends an AttackMessage to all the other components using the notify function of the GameObject. The Weapon component picks the message, sets some local variables and sends a RigidBodyStateMessage to the RigidBody component which in turn sends another message containing the rotation and position of the GameObject. The Weapon component catches the message and instantiates a bullet using the information passed in the message.

Communication between different objects is achieved using messages sent in message buses on which the GameObjects have registered. For example, the PhysicsComponent continuously sends messages to the collisionBus which are then delivered to the registered GameObjects.

This approach allows for complete decoupling between the components but I am not sure if it may create any long-term problems. Some people also told me that components shouldn't have any logic in them and that they should only keep data which will be processed in systems. I was wondering what advantages the latter method would bring compared to the one that I am currently using. Sorry for the wall of text, I am writing from my phone.

Any help is much appreciated!

Answer 1

First, it is perfectly acceptable for a component-based system to support components with logic, or to support components without logic. There is no codified standard for component-based implementations used in game development.

There are advantages and disadvantages to either approach, but in the end none of the advantages really outweigh the others. The right choice for your game will be to choose the pattern that best expresses how you want to, or need to, reason about your components and their place in your larger architectural space.

Components as "pure data" allow you to make certain assumptions about them: for example, you know there is no execution state (such as "where they are in their update method") that you would need to persist if you wanted to serialize the component out to persistent storage. This can result in a simpler, cleaner system of serialization for components (both for save data and for sending across a network). If you really implement them as pure, plain-old-data objects they can be faster to copy around in bulk (depending on your language and its idioms regarding "objects" versus plain data).

However, components as "pure data" also mean you need a third-party (a "system" in your parlance) interface to drive any behavior or processing you want associated with the components. This can be disadvantageous if the overhead of creating a new "system" in your API is large. If the overhead is small, then this problem is essentially reduced to the issue of syntactic sugar for OO operations (this->Method() as a member function is not much different then Method(object); both can be used to implement OO design).

Now, there are fairly compelling advantages to processing components in external "systems" objects versus within the entity itself ("foreach entity, foreach component in entity, update the component"). Externalizing the processing provides for potentially better cache locality, makes concurrent processing easier, and other sorts of things. That is orthogonal to the concept of requiring that components only be data though; you can have components with behavior that are also bulk-processed by a "system" interface.

Answer 2

Generally I think it boils down to code maintainability. In your current design, would adding a new component require you to update all the others respectively? Or would it suffice you add some code in one specific spot. If it's the former than you may be doing something wrong.

The reason I often use systems is that I don't wish to expose all the data (instances) to all the components. I also don't want to "spread my code to thin". If there is code that is strongly related I'd rather have it in one place where I can update all of it in one full swing. Using a system (at least) appears simpler because all the interaction between objects is handled by a specific external unified body of code. This way I don't need to expose aggregations of instances to every specific component. On the other hand it is important to avoid the "God Object" Anti-Pattern. Each aspect of interaction should be dealt by a unique system relevant to that specifically.

This (I think) helps me when I find data has been corrupted. I know more specifically where to look and how to track the fault's source.

There is nothing wrong with combining this approach with the alternative one when this becomes relevant because a certain behavior / interaction is perhaps unique to a specific component. It can be avoided though by having the components interact with the system.