I'm working in Unreal Engine and have already built a modular, data-driven gameplay system using an object-oriented approach. A data asset represents a gameplay action and contains several UObject-based effects. Each effect overrides an Execute function, while interfaces let actors respond appropriately to different effect types.
I now need to build something similar for Mass Entity, but ECS does not use UObjects, interfaces, or the same kind of polymorphism. I'm unsure how to preserve the modularity without putting behavior directly into structs or creating a large switch statement based on an effect enum.
For example, should an action contain only effect data, with separate Mass processors handling each effect type? Would that require a central system to recognize every new effect and add or remove the appropriate fragments and tags? I'd like to understand the intended data-oriented design and how to keep it extensible when new gameplay effects are added.
3 Answers
An enum plus a switch is not automatically wrong, but it is usually a sign that several different concepts are being forced into one system. If the effects are few and stable, a switch can be perfectly practical. If they are expected to grow, split them into separate command types or processors instead.
A useful pattern is to store an action definition as asset data, then have an action system emit commands such as damage, healing, movement, spawning, or applying a status. Each command contains only the parameters needed by its processor. Processors query their specific command or fragment, perform the operation, and clean up the command afterward. This gives you modular behavior without putting virtual functions or function pointers inside Mass data.
Trying to preserve the UObject hierarchy inside Mass will usually give you the disadvantages of both approaches: indirect calls, scattered state, and poor batching, without getting much of the ECS benefit. Structs should generally be passive and trivially accessible; processors should be organized around the data they read and write.
Also consider whether Mass should own every part of the gameplay system. Unreal’s Gameplay Ability System already provides a data-driven model for abilities, effects, tags, attributes, and execution logic. It may not map directly onto Mass entities, but it can still be useful as a reference or as a separate gameplay layer, with Mass handling large-scale entity simulation where appropriate.
The main shift is to stop thinking of an effect as an object that executes itself. In ECS, an effect is usually data: a command, event, fragment, tag, or entry in a small effect queue. Mass processors own the behavior and query the entities or commands they understand.
For example, an action could generate a DamageEvent containing the target and amount. A damage processor queries those events, applies the result, and then removes or consumes them. A status-effect processor can handle a different event type. The data stays passive, while systems contain the logic and can process many entities in batches.
You don’t necessarily need one giant manager. A dispatcher can route generic action data into typed command fragments or event queues, while individual processors handle their own categories. Adding an effect then generally means adding its data definition and processor, rather than adding another case to a central Execute function.
So a small routing layer is acceptable, as long as it only converts incoming action data into the appropriate event or fragment and does not contain all of the gameplay behavior? My concern was that a central switch would become a maintenance bottleneck whenever a new effect was introduced.
That makes sense. The action asset can remain a description of what should happen, while the actual work is represented by commands that the relevant processors consume.