I'm writing a game using the Java Artemis-odb ECS library, and have been stuck on this design question for a few days: what is the proper way to store a function/command in an ECS?

The use-case is that pressing a key should activate the currently held item in the player's Equipment component. This would have an entityId linking it to an entity with a Useable component. The question I have is what should be stored in Usable that could preform a variety of effects (shooting a gun, gaining health etc.) Another consideration is that the component should ideally be serializable.

Right now, my current thought is to use the event system, and have Usable return an EventFactory which EquipmentSystem will call to get a new event & send it. This would be listened to by GunSystem or HealthSystem etc.

It seems a little gross though, and making an ItemEvent subclass, ItemEventFactory subclass, and ItemEventListener function seems more heavyweight than necessary.

Is there a better way to store an action/function inside a component?

Thanks!

ECS in the first place means “no functions in components” because every funcionality should be handled by a system. So instead of forcing a workaround egeinst the ECS pattern, why don't you have an action event?

Input by design is always event driven, so the input data is by nature coming from an event source. All you now have to do is to let your event system handle that action. It might then trigger an update on the action system.

If I were in your situation, I'd have several kinds of different ECS approaches. One for the game itself, which is updated every frame and always batching all components of a kind and the other would be an event pipeline which has different systems attached to, where those systems decide which event they want to process. So the pipeline could have an ItemTriggerSystem attached to it where the input data is the button pressed, the system when performs a lookup to the player component to find out which item is attached there and then passes another “event” onto the pipeline which is processed by the corresponding item system

@shaarigan I guess the problem I'm having is that I have both the ECS loop and event queue loop, but I'm not sure what should be stored in the item's component so that when the system looks it up, the right event will be passed and the right system will get it.

Right now, I have the component storing an Event Factory, but that seems awkward. I'm also considering some sort of enum and a big file mapping the enum to a function to be called by the Item System.

Ideally, this would be generic enough that it could work for a Collision handler or Input handling etc.

The end dream is to be able to create new items by randomizing the components and the values of the components

@hplus0603 I'd love a lambda. There would be onCollision components that have a lambda, onUse functions, onKeyUpPressed etc.. Unfortunately, it seems to go against the ECS paradigm of only having data in components, and additionally I'm not sure how well they serialize. That's why I'm considering weird hacks like a giant switch statement in a system that maps enum → lambda

@hplus0603 I'm also not quite sure the right way to recreate polymorphism in ECS, but that's another thing I definitely miss having. Is there a good way to use it in ECS?

spencerflem said:
I guess the problem I'm having is that I have both the ECS loop and event queue loop, but I'm not sure what should be stored in the item's component so that when the system looks it up, the right event will be passed and the right system will get it

Usually you have the frame update, which is a batch processing of certain set of components. This may be the transform component for example which is bundled with a physics or velocity component to determine the direction and speed an entity moves, or the mesh component which tells the renderer what mesh to display.

Then there is the event loop as I wrote, which is simply a storage of events like input or something and processed on every frame. The difference is that if you handle an event, it isn't batched with all components of the same kind but you have a single component or a set of components which are involved. In your case, from a naive standpoint, I'd get the player entity and the item component from a certain input and let a system decide what to do, based on the item itself. You may for example put an event into your event system, which contains the item ID and a general event ID for let's say “use” or something. Your event handlers may then consider if they want to handle the event based on the item ID you passed and so you could simply hook new actions into the game.

We're using something similar but for our build tool. It receives some input and has a data driven pipeline which has processor units attached to it. Those units handle a certain type of event and/or data and could themselves also pass events/data to the pipeline which is handled by other PUs