When should I be using events/signals vs. implementing everything as a system?

[ZaneL]

I'm not sure if I'm asking this question properly...but anyway, here it goes.

Right now I'm writing a simple 2D game where everything moves around on a grid. I'm using your library, which I love so far. Now I'm at the point where I want players to be able to interact with each other. Lets say one feature is that a player can communicate with nearby players. So a player could type something into a chat-box and then the text message gets sent to all players within a certain radius.

I figure one method of implementing this would be to use your event system where all players could be listeners, and when a player publishes on an emitter I could implement something where nearby players retrieve the message.

On the other hand, couldn't I just do the same thing by implementing a simple system that runs on every tick, and it would check to see if all players have pushed a message into some buffer associated with them, and then it would distribute the message to nearby players.

Same thing with a weather system. I could have the weather be broadcasted on some emitter and entities would receive the current weather, but wouldn't it be just as easy to implement this as a simple system where I loop through certain entities and update each one with the current weather?

I'm trying to use "best practices" when writing my simple game, but it isn't totally obvious to me when I should be using signals/events.

[skypjack]

Hi, do you mind if I convert the issue in a discussion? It seems more appropriate to me.

As for your question, there isn't a golden rule for that. It depends on many aspects like:

• The underlying model (some are less prone to having you add and remove components at runtime).
• Your coding style/preference/tastes.
• The kind of message and especially the types of receivers.

In general, the model of EnTT has good performance when it comes to adding/removing components.
For this reason, I usually like to use them to share messages between systems. So, I'm a little biased here. 🙂
The rule of thumb for me is in general: if it's intra-simulation, then use a component, if it goes to other parts of the software, then use the event/signal stuff.

[ZaneL]

Okay great, thanks for the reponse! And yeah sorry about that - feel free to move this to a discussion.

When you say "other parts of the software" are you referring to stuff like the GUI/overlay? Or just the different systems within the game?

[ZaneL]

Also one more question. I read your article about implementing inheritance related features with EnTT. It was a nice article, but since my game is extremely simple I decided to do this:

struct Parent {
    entt::entity parent{ entt::null };
};

struct Children {
    std::set<entt::entity> children;
};

So when I create my various entities, I can assign them to a parent, and then I populate the parent's children. I decided to use a C++ std::set, because I can easily insert and remove the children using the entt::entity ID. It works nicely, but in an ideal world, would you consider this to be a bad design? In your article it looked like you recommended using fixed-size arrays when possible (or a linked list sort of deal), I'm guessing because it has speed benefits?

[skypjack]

When you say "other parts of the software" are you referring to stuff like the GUI/overlay? Or just the different systems within the game?

Anything that isn't defined in terms of entities, components and systems.

It works nicely, but in an ideal world, would you consider this to be a bad design?

You must find the right balance between performance and fun. If it works for you, it doesn't represent a bottleneck and it makes it easy to work on your codebase, then go with it. Especially if your game is extremely simple.
As a side note, the next release will offer a way to have pointer stability on your types. So, in theory, you can also rework the whole thing and use direct pointers if you like/prefer.