Amount of websocket messages in a multiplayer game

[kurhlaa]

Hi,

I have a strategical question. Imagine a standard multiplayer shooter. What are the ways to broadcast and sync the shooting events?

I ask because I'm confused by the weapons like automatic rifles - they shoot many times per second, or can fire just 1 bullet, it depends on how long you press the mouse button down. If in a match there are 20 players, all of them have rifles and shoot constantly - does this mean, that each player sends tens of websocket messages every second, which means the server side broadcasts hundreds of them every second? And if there are hundreds of parallel matches - that feels like a huge network traffic generation.

Are there smarter ways to sync shooting?

[b10b]

One approach would be to share "commands" rather than object positions.  Ultimately within a game there are zillions of things going on, whereas each player only makes a "new" decision every second or so - and not every decision affects every other player.  Tune into that "need to know" strategy for significant optimisations.  Also, games need not always be fair - if it feels "good" that's often a better result than being accurate.  Big topic ...

[kurhlaa]

@b10b, at the moment I already send a weapon's "fire" event itself, not the position of every single bullet at every frame. I also wish to avoid sending identical "fire" websocket messages tens of times per second from every player. So I'm interested to know how other projects deal with syncing every bullet.

About feeling that it's "good" - agree.

[b10b]

5 hours ago, kurhlaa said:

I already send a weapon's "fire" event itself, not the position of every single bullet at every frame

Good, keep abstracting and reducing it down to the minimum delta and interpolate.  Without knowing the exact details I do risk giving bad advice ... but ... you may wish to consider sending nothing about the weapon at all, instead send the player's inputs, or better - only the change in player's inputs (which is often a minuscule data stream).  Then have each client be deterministic (bullets need only exist here).  With some dead reckoning (and periodic corrective packets and occasional jury) it can be almost permanently "wrong" yet feel "right".

[kurhlaa]

@b10b, what do you mean by "Then have each client be deterministic (bullets need only exist here)" ?

[b10b]

@kurhlaa The deterministic principle is that randomness is not present within the system.  So if the same inputs to the system occur in the same order, the system's state is accurately replicable.  In the case of bullets they would only exist on (each) client, they are spawned locally based upon synchronised player control streams (one of which is the local player), they terminate locally, and they are (theoretically) ~identical in their lifespan across all clients.  This is just a simple explanation - to fully trust the deterministic principle can be naive - but it's a start towards understanding that even a highly complex game's data stream need not be any more complex than a simple game's.  As mentioned additional data layers should be added (but need not be as frequent) to challenge and evaluate the naivity.

[WombatTurkey]

Kinda. It totally depends on the tick rate of the server, how fast you want to send input,  and how the data is interpolated to make an illusion of smooth gameplay

 <insert google'd networking guide here> gambetta / valve's article, etc

 

Quote

does this mean, that each player sends tens of websocket messages every second, which means the server side broadcasts hundreds of them every second? And if there are hundreds of parallel matches - that feels like a huge network traffic generation.

Basically yeah. You'll need a master game server to handle the game instances to horizontally scale 

There are tricks you can do to mitigate the load, by trusting the client a little bit, etc. 

Take a look at treasurearena's websocket frames in Chrome's dev console. You'll get an idea.