Packet/Event-Based Entity-Component-System

Question

I know what one of the big commonalities I see in ECS projects is that there is a main game loop that iterates through systems and calls their respective update methods (for example, RenderSystem).

I'm a bit stumped on how this applies to an event-based game where the client sends packets of information and you update from there. For example:

MovementPacket

1. Read incoming movement packet and send to appropriate packet handler, which makes changes to appropriate components regarding entity through systems.
2. Packets are then sent back through the systems (which work with components to access the data needed to write these packets).

 

Now, I'm not sure where a game loop really comes in here, since everything seems to be event-based. I'm scared that most of the work I'm doing ultimately for ECS just isn't being done right. My systems are typically becoming "containers that do logic and stuff, but don't operate within a game loop."

In fact, the game itself doesn't have a game loop, since we haven't really found an area to insert it in.

Is the approach just wrong? Is my approach towards interweaving ECS with this packet-based game for the most part incorrect?

Answer 1

You dont quite seem to understand, what events are really there for.

First of all, the game loop has an intentional order. Imagine you would first do the movement, then the physics in one frame, but in the next frame you do it the other way round. Maybe your character could suddenly move through walls or similar strange behavior.

As you describe it, your events are basically just callbacks from one system to another. One system does something, the other system has to react to it, so the first system calls it and sends its data to change. That would imply, that every system knows each other, so it can call it with an appropriate callback-function. This would mean, that you couldn't guaranty the order the systems are called, let alone how often a system is called each frame. Or if the other system even cares if it should react to an event.

Events are like messages in a message board. Back to your example:

1. Your MovementSystem registeres the player presses the button for moving right, so it set the value in the direction component and creates an event marked for the PhysicsSystem(to calculate the real position change) and the GraphicsSystem (to maybe start an animation loop).
2. The next System is the GameplaySystem. Its update function is called and sees that the character is in a trap, so it posts an event only ment to the physicsSystem saying not to move. It also posts another event but with a 5 second timer, to accept movement again.
3. Next in line is your PhysicsSystem, so it does it regular update and calculates every frame stuff (like gravity, etc.) and then checks the EventBoard for events ment for the PhysicsSystem. Now the interesting part: it finds the MovementEvent, so it changes its velocity component to the right value, then reads the Trap event and changes the value back to zero. Then still in the update function, it sets its position of the character depending on the velocity, which is now zero. Since it read both events, it checks that it had read them. so the trap event disappears. The other event with the timer is not yet due, so it won't be read.
4. The GraphisSystem calls it update and checks for events, where the movement Event is still on the board. It doesn't care, that the position hasn't changed, so it starts the movement animation. Your character is now Moonwalking in the trap (if that is intentional). Then it draws the players view.

To cut short, your events can be handled asynchronous, delayed and by different systems at the same time/frame, without dependency of knowledge with system exists. And just to make it clear, it is important to call some systems every frame, like physics, graphic and AI.