1
\$\begingroup\$

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?

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Okay, most of the stuff you wrote I can follow. However, this is assuming that most of the calculation is done server side (where between the client and server, the server is the centerpiece of this all). However, in the game I've joined development on, it seems to be a half-and-half. Client actually does its own movement, sends updated movement position to the server, and the server marks that down and updates its information. Client also handles all the physics, etc (which is why it only sends position). \$\endgroup\$ – Jon Nguyen Apr 7 '18 at 12:13
  • \$\begingroup\$ At least, that's how it's working right now. Basically it's all asynchronous. Receive a packet from the client. Update everything. Send a packet back to client to update everything. As soon as possible. Should the alternative be: receive packets. Update. Wait for Systems to loop, which go through all necessary entities that have to send packets back to the client? \$\endgroup\$ – Jon Nguyen Apr 7 '18 at 12:15
  • \$\begingroup\$ Or at last, how it's working atm is akin to clicking on some UI client side sends the packet over server side, which grabs all relevant information to display as a menu for client (which is all written to a packet and sent to be displayed on client). But looking at what you've posted. When I get an incoming packet, it shoud be flagged as an event depending on what has changed. Flags what entity needs to be updated through the system, am I correct? \$\endgroup\$ – Jon Nguyen Apr 7 '18 at 12:21
  • \$\begingroup\$ In a Server-Client-System it basicly works the same, just that some Systems only work on the Server, some just on the client. You dont need grapics on the server and AI calculations on the Client, but Physics, Gamerules etc. on both. Then server and client send events to each other and sometimes the state of important components to sync the client with the server. \$\endgroup\$ – PSquall Apr 7 '18 at 14:27
  • \$\begingroup\$ So in the end, should still have a game loop that goes through any respective systems that need to be updated each frame. They perform work on any component/entity that's been changed/flagged (maybe through some event system) (?). Such as maybe enforcing the speed they're walking (because maybe speed hacking), you may get a movement packet in. Process it, but then infer that they're going too impossibly fast, do some calculations to grab the correct position, and then on the next loop enforce it by broadcasting the position packet to them and anyone else around? \$\endgroup\$ – Jon Nguyen Apr 7 '18 at 22:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.