Input and output of a server side game using web sockets

Question

I am having a look at redeveloping an old flash based top-down zombie shooter game I made in highschool so that it supports multiplayer using socket.io. My experience over the last 5 years has been mostly writing server-side code, so writing the game logic itself on the server isn't a huge concern. The places I am having trouble with due to my very limited experience with sockets specifically is:

• What the most appropriate input and output should be to and from the server in a game context.
• How much data is appropriate to send.

Off the top of my head, I imagine the process would look something like:

• The server runs the game (using NodeJS).
• Clients that connect send their input to the server (key presses, clicks, etc).
• Those inputs are queued against the client ID on the server and interpreted to move their character or whatever it does.
• The server sends back the updated position of the client as well as everything else around the client in the "world".

The last point is where I have the most doubts. Assuming a reasonable collection of objects in the world, I am not confident that sending through the position of everything every ~30ms to every client would be sustainable (though I really don't know what is sustainable with web sockets). Then again, maybe it actually is perfectly fine to do this.

Obviously I can limit the amount of objects by only sending ones who have actually been updated (so static objects would never come through, etc) but I am not sure whether that is necessary at all or whether that is something extremely crucial. I also don't see this working if we implemented something like everyone being able to fire 100s of projectiles (or some other massive collection of constantly updating objects).

Are there any general guidelines or common knowledge around how much data you would expect to see come through a web socket and how frequently? Am I way off the mark or would this work okay for a moderate amount of clients?

I realize this all sounds very broad so to try tighten it up a bit I am specifically interested in how much data is realistic to send through web sockets and how frequently. Any auxiliary information based on the above is a great addition.

Answer 1

I don't think the WebSockets protocol has the speed that you'd be looking for in a real-time game.

"The technique is effective, but is not well suited for applications that have sub-500 millisecond latency or high throughput requirements."

Websockets are built on top of TCP, which ensures that every packet of information is received by the client. Do you need this sort of reliability? Maybe not.

You might build on top UDP instead, which doesn't guarantee the transmission of every packet of info. Because of this, it's a lot faster.

There's a great article that goes into a lot of depth on this answer, and which basically states that although TCP has a lot of bells and whistles and reliability, because in UDP you sacrifice these layers of protection (and is a bit of a pain in the ass) you get much faster speed.

Answer 2

I've worked on a very similar personal project similar to one you have mentioned. It was my first real attempt at creating a real-time multiplayer game using Node.js with Socket.io. You can check it out here.

Not saying my game is anything of a good example of a multiplayer server, however if you check the network data (chrome - f12) when playing on it you'll see what kinda data the server can send, and the client can receive.

My server does not send unique info to each player (by sending only relevant, nearby data), but instead sends all of the game info to every connected player every 50ms (or something close to that). this, whilst a bad practice, kind of answers your question. My inefficient game can send every single bit of game data, to every connected client, every 50ms. I've had almost 20 people playing simultaneously with no noticeable hit to server lag.

So, if you're thinking of implementing functionality that sends unique and relevant data to all connected clients, you're already one step ahead of me. (And my game works fine™).