Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
I was developing an game. I using single threaded nodejs(socket.io) server. It is good for simple games or games like basic 3d world? Usually game will have 10-20 players(clients).
Also is single threaded server can handle multiple clients same time?
like player 1 walks player 2 jumps same time.
There is nothing good or bad about using NodeJS.
I have experience with multiple relatively heavy loaded projects (2-500 users on a 1 CPU machine) using nothing but NodeJS and Web sockets. No problems with performance. Games were not very complicated - mostly moving units on a 2D plane, units can shoot missiles or do melee attacks.
I'd recommend one of these packages: wse or vanilla ws.
NodeJS is actually not that slow in compare with c++ or g++.
Talking about performance - I'd recommend avoiding socket.io - is a very comfortable and simple library, but it works much slower. But it still not a problem for quick prototyping or a small number of connections (2-30 is small here).
I hope this answer is subjective enough to match the subjectivity of the subject.
P.S.: I'm currently working on a thing capable to handle 1000+ connections per machine. With no fear.
ws has optional modules for performance boost - npmjs.com/package/ws#opt-in-for-performance-and-spec-compliance wse is a simple wrapper around ws to make some boring things easier. I used 1 or 2 CPU machines on DigitalOcean m.do.co/c/72cfd6567301 If you're not using docker or some other extra-layers - 1000 connections are actually not that much. And again - NodeJS is optimized (see v8 performance) - I'll add a link to my answer so you can see actual numbers.
\$\endgroup\$
– Vladimir Ishenko
Nov 26 '20 at 13:52
Usually you would have multiple threads in the case of TCP, each for one client connection, and a thread for gamestate/logic. In the case of UDP you have one listening/sending thread and one game state/logic thread.
Anything comes in from a client you put it in a shared queue. For instance, you may have a seperate queue for jumps, for shooting, etc. Any game event happens you broadcast it across the clients.
Anyway, using TCP is a pretty bad idea anyway (for the game itself, for a chat it's good). You want to get packets out as fast as possible, and not wait for stuck packets that may take seconds to clear (which is why you have to use seperate threads, otherwise one bad player connection can throttle everything).
You might want to keep track of the order of packets, if that is important to you. Also include a little header in each packet of what packets were last received, so you know if you have packet loss and need to resend anything. Here's some links that explain in more detail with code: https://www.gafferongames.com/post/virtual_connection_over_udp/ https://www.gafferongames.com/post/reliability_ordering_and_congestion_avoidance_over_udp/
As you can tell, both TCP and UDP have drawbacks and strongpoints.
TCP: very reliable, but slow, blocks a thread. Good for web servers, chats, user account login, anything that does not require millisecond speeds, but does require reliability.
UDP: lightning fast, non-blocking, unreliable. Used for things that just need very fast speed, use your own programming or a library to make it reliable.
Luckily since you are using node, somebody else has probably figured it out, sadly I'm not familiar with the node ecosystem.
Also, I'm not sure if it still applies on modern routers and modems, but it's often claimed that using both TCP and UDP on the same port can lead to connection problems. So I recommend you use different ports for your chat (TCP) (if you have a chat) and your game (UDP). It doesn't hurt either way.
