Event-Based Entity-Componenty-System

Question

So, I'm new to ECS. The concept is very interesting in contrast to traditional OOP and heavy inheritance. I'm working on a game right now that is open-sourced, but does not actually have a game loop. It works by sending and receiving packets, and acting upon those received packets.

In that case, what would I be looking at in this relationship between Systems and Components? Let's say I have an incoming Movement packet that is telling me to move Player A 5 units to the right. And let's say I have a lot of different types of packet types (let's say up to 100), each for different stuff, like maybe making a purchase at an NPC store. Another one for purchasing at a player store.

Or maybe inviting and expelling players from a party. Or inviting and expelling players from a guild or alliance.

At that point, I start getting a little confused. I can definitely see similarities in ..

1. Adding/Expelling people from a party, guild, alliance

But each of those packets contain different information at their core. I'm tempted to write a component that Guilds, Alliances, and Parties can use (like AddRemoveMemberComponent), but the information coming in from the packet makes me hesitant.

How would those components handle specifically? Maybe I'm just entangling myself in traditional inheritance, so it's hard for me to see the uniqueness of data. Would I have unique systems for explicitly handling Party, Guild, Alliance expulsions and invitations? And how would I dynamically know what to do with these different packets coming in (different packets for alliance, guild, party).

Answer 1

Entity movement is a great example.

In most games, they do not care what triggers the movement, only that entities move in a common and standardized way. So the idea is to design some middle-man concept that knows how to take and interpret the input source and transform that into a series of commands that the EC/ECS movement system understands.

In the case of ECS, you might have a system that knows how to listen for local input from the keyboard and mouse and upon getting input, it interprets that input into commands. It locates an entity that maintains a PlayerController component and then sets the appropriate toggles for whether the entity moves Up, Down, Left, Right.

Similarly, when network movement packets arrive, you might have another system that knows how to interpret the packet data, locates the appropriate entity by its id, checks that it still maintains a NetworkController component and sets the appropriate toggles for Up, Down, Left, Right.

Later on a movement system asks for all entities with controllers, regardless if they're player or network controlled. Its at this point the Up, Down, Left, Right get applied with the entity's current velocity and orientation to apply the requestesd movement.

The nice thing here is movement is handled in a standard way regardless of where the data came from so that you could easily replace the PlayerController with a NetworkController and allow some remote player to control your character, like while being mind-controlled or feared.

As for Guild, Party, or Alliance.... It would seem those are potentially different game constructs in their own right but share some underlying behavior where an entity particiaptes in a collective. Whether you intend to model those systems with a base class to share code, thats entirely up to you but a plausible design choice if you want.

But much like movement, the guild system would be notified when a guild packet arrives. The packet will be interpreted by the system to know which entity it should operate upon and what operation to take. Depending upon the operation, the entity is looked up and the appropriate action would be taken.

For example, if Entity 123 requested to join Guild Acme, then the system would first lookup that entity, verify that it does not presently have a guild component. If it does, we might error because an entity can only be associated to a single guild. If no component exists, we lookup the guild Acme, verify it exists, if so we create a guild component that references the guild's guid and then add that component to Entity 123's component list.

As to how you handle the routing of packets, that's entirely up to you.

You could build a map at runtime where you maintain a packet-type to either a system pointer or a function pointer for the callback or you maintain the mapping through some build-time mechanism so its effectively static at compile-time.

Answer 2

As Naro's said, you need a component for every player, that joins a Guild / Party / Alliance to save the information, that they are in that alliance or whatever.

But you most likely need a serverside system to keep track of your membership to the specific Guild.

Imagine, someone wants to join, so he sends a join request or accepts an invitation. As Naro's said, you check for that players components, but if its alright, you send a message to the server with the player-id and "join" for example.

Now, the server needs to keep track of the members in this guild. Maybe for some reason the player who wants to join is already in the Guild, but somehow didnt had the component associated with it. Or other players should get notified that someone joined.

In that case, you dont want to send that message to every player, just to the players in that guild.

That said, you could implement your Guild(s) as Entities themself, that have hasMemberComponent in addition to some other Guild-specific components (like rank, fame, community Gold etc.).

So, if something changes in the Guild, you dont have to send all these informations to every other player, just to the server. If you dont have a server and just peer-to-peer, then every client needs to have the guilds information.