Jump to content

Authoritative Servers - Event Driven vs. Game Loop


Ralph
 Share

Recommended Posts

Hey all,

I'm currently in the process of re-writing my authoritative server from one that was completely event driven to one that relies heavily on a game loop and I had some questions I'm sure some people can answer.

To give some insight for my question, the way the old event-based system worked was basically the client would do something, then send tell the server what it was trying to do. The server would then check if this was legal if it was, do nothing but tell other players what that client did, if not legal,  would set the client back to its previous state.

For example, movement was handled by the client telling the server where it was a few times a second. The server would make sure it's getting consistent updates from the client and calculate if its velocity and other parts of its movement was legal, if so the server would accept that update and store it and push it to other clients. Similarly, shooting was handled in the same way. (Bullets do not travel btw, shooting would essentially just spawn a point of damage wherever you clicked) Client would tell the server where it wants to shoot, server would give it the okay or not then push that info to everyone else and calculate damage if it hit someone etc.

Now, I'm switching to a game loop so that my entities can have a more robust "ai" behind them. While in the process of this I've moved a lot of the server logic (like movement) to the loop and it seems to be much more functional (and authoritative) to do it this way. I always knew the loop made more sense, I just didn't want to hassle myself with it yet.

Now the main question I have is should I be handling things like shooting in the game loop too, or is it okay to keep them event driven. Do I lose anything by having half the game event driven and the other half of the game ran in the loop? Since bullets aren't a traveling entity and is just damage at a point and all the server needs to do is calculate if you can shoot there, and if there is a player there, then damage them. Should I move this logic into the loop for cleanness/speed/efficiency? Same thing with other things like opening an inventory screen. When you open your inventory on the client, the client requests the server for its items, the server just immediately sends the client the info it needs (while doing some other logic obv). Should I move this to the loop and set like a flag that says on the next loop serve this client their inventory? Or does it really not matter at all and whatever makes sense to me?

Let me know if I need to elaborate some more, I'm sometimes not too clear hahaha.

 

Thanks!

Link to comment
Share on other sites

  • 3 weeks later...

Not really a bump, but since I'm curios on others thoughts still go ahead and shoot a reply if you have some input. Either way though, I've kind of already moved forward with moving everything into the loop. Some events remain but they're there now mostly for readability and simply set a flag that tells the loop to handle the event on the next tick. Just a word of advice to if anyone sees this in the future, save yourself the trouble of even attempting an event-driven game (unless your game really caters to event based logic). It will work and work great at small scales but it simply isn't practical or worth the effort for anything other than a proof of concept. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...