Hi,
i’ve been developing a roguelike multiplayer fps, and now having a good base for my game, i started thinking about bandwidth usage - as of now
every single interaction is its own packet sent (for example, shooting a player sends 2 packets , one sent with UDP containing information about the bullet tracer and one with TCP containing damage information)
Which obviously is very bad for the network. Is there any way to profile the bandwidth usage to figure out the golden spot between sending a million small packets (which introduces overhead) and sending a couple enormous packets? Also, is TCP performant enough for informing clients about frequently occuring key events (such as damage receival)?
The main issue with TCP is that if something stalls then you can get a pause in transmission and then suddenly catch up with a bunch of redundant-and-now-useless messages. But for things like damage received, it can be ok… depending on what “frequent” means.
Something like SimEthereal does real-time object syncing by keeping track of frame deltas, packing things into small UDP packets (trying to be smaller than MTU), automatically resending missed data while ignore redundant data, etc…
It can fit about 70+ object objects in a single 1500 byte UDP message, depending on what has changed from frame to frame. It will automatically break up event chunks etc.
And while it is focused on syncing objects, it does support child objects… and as such SimEthereal can be tricked into sending additional data by having fake child objects and using their x,y,z, etc. as status values. I use this for setting animation frames but it could easily be used to send a health percentage.
Very interesting, thanks. Seems like my approach was wrong - as of now many of the events were relayed to other clients whenever the server itself received a message (reactively). I’ll have to rethink my approach to “book” the changes and batch-send them every delta time (as i do with positions that changed every X server ticks).