Networking strategy for FPS?

[bbmario]

I'm adding networked multiplayer capabilities to my first-person shooter written in Babylon, but i'm worried about the scalability of the game. Right now, i'm using socket.io. It works somewhat well with 1 player, but a small test with more than 4 players ended up turning the whole experience unplayable. Other than socket.io, are there any other networking mechanisms that can be widely used between browsers? How would you guys tackle this problem?

[jodo]

In my opinion the socket.io is the best and fastest option you have (I would be glad if somebody told us otherwise, I would love to check it out then).

How often are you sending updates to the server? How often is the server sending updates to the clients? What are you sending to the server/clients? You could for example cache inputs from players for some milliseconds and only update like every 100ms. No need to update at 60Hz. And of course always try to send only the information that is actually needed.

And well in the end, a good connection + fast server will help. But that your application is already struggeling with 4 players sounds wired. That shouldnt be much of a problem in my opinion if you just send some position updates (all the time) and things like kills and health changes / hits when the event occures.

[slobacartoonac]

Hi I had exact same experience with my flight simulation game. Every single package that arrived is followed by 15 ms of js doing nothing. That resulted that game was unplayable for 2 players. Tried socket.io and few webrtc libs with same result. I assume that this problem might be in 2 event systems, since Babylon has its and browser has its native. Socket packages trigger native, so that might make problem. I'm new to babylon so that is only assumption.

[bbmario]

It's a first person shooter, sending 1 packet each 100ms means 10 packets per second, resulting in terribly choppy gameplay. I was inclined to use WebRTC and raw UDP, delta-compressing the game state and embracing package loss, but it seems that WebRTC is nowhere near 100% compatibility or even feature-parity among browsers.

[jodo]

When talking about internet connections you already have about 50-150ms delay just from the connection. There are different techniques to tackle that problem like interpolation of movment. But than you still have the lag problem. This for example could be solved by letting every client see a game state from the past and than calculate for example a head shoot on the server. That would mean 1. you have to run the physics engine you are using in babylon on the server and you have to determine the worlds state at different times.

I remember a discussion we had in the Babylon forum and lets say, this task as of right now is quite hard to handle with any WebGL Javascript framework. But its defently a interesting task. I tried to run oimo.js on node.js and use it to implement the technique i proposed earlier in my post ... but well, I failed miserably and gave up pretty fast ;). 

[WombatTurkey]

Try the ws module instead , it's the fastest websocket library right now and faster than socket.io. Although, I don't know if that will help since websockets is not true UDP. But there might be a performance increase.

 

Also, are you using binary or string websockets? Binary is faster as there is no encoding/decoding going on at the transport layer.

 1 packet every 100ms seems excessive? 

 

 

And for scaling, you will need zeromq or Redis Pub Sub.  I recommend zeromq as it's more lightweight for what you need, unless you need an in-memory database. (Guess you could use Redis for in memory database, and zeromq for pub sub too)

[jodo]

@bbmario I have created a FPS in Babylon. Really simple (and ugly ; ), i am no artist at all as you can see). All I do is sending information about position, hits and health to the server and broadcast it to the other players with socket.io, no interpolation, no chaching, no physics checks on the server, nothing else.  It think it works quite fine even with some people being in the game. You can check it out here: http://185.82.21.82/game/public/ or the code here https://github.com/j-o-d-o/game. It runs on an super slow Linux VPS (2GHZ CPU, 512 MHZ Ram...)

[rgk]

If you like some of the more advanced features of socket.io and want to try numerous libraries you can switch around with, try primus.io! ( https://github.com/primus/primus ) Its lightweight if you use ws.

[WombatTurkey]

@bbmario I was thinking about this today and you could use electron or nw.js and use node's native udp module instead of websockets?

[Fricken Hamster]

I'm thinking a lot of the laggy feel is solved by other games by a lot of estimation and interpolation on the clientside. In reality, the real game will always look choppy, but the client does a great job of masking it.
Theres a pretty good article on how the source engines does it.

[bbmario]

Of course the client masks it, but on top of UDP, not TCP. Valve engines are UDP. TCP is too heavy for any kind of network-heavy game like FPS. It might work for RTS, but certainly not for an FPS.

[jodo]

Well, than you are out of luck, there is and will be no way of using UDP with browser and javascript. WebRTC is the closest you can get, which is built upon UDP. But as you already said yourself, it's a quite new and does not have 100% cross browser compatibility.

[WombatTurkey]

I've just tried UDP with electron last night, and it works great (use node's api).  But that being said, it would have to be in an electron app (or nw.js). Maybe browser's in the future can some type of udp connectivity.

[Fricken Hamster]

On 2/15/2016 at 11:07 AM, bbmario said:

Of course the client masks it, but on top of UDP, not TCP. Valve engines are UDP. TCP is too heavy for any kind of network-heavy game like FPS. It might work for RTS, but certainly not for an FPS.

UDP makes it fast, but the perceived smoothless is all client masking.
TCP nowadays isn't too bad in a lot of places. With a good connection, minimal dropped packets, and not enough data to trigger congestion control, I doubt there would be a noticeable difference between TCP and UDP for a real time game. It does matter for a game like counterstrike because all those factors matter for fast and accurate hit detection and counterstrike is a competitive game. For your example, clientside magic would do a lot more than running on a different transport protocol.

I don't see what the point of worrying about 100% compatibility on webRTC is. UDP has never been supported on browsers and probably never will be. webRTC isn't udp, but it supports unreliable delivery. Its the best that we'll get with browsers in the near future, so even your game only works on chrome, its a big step up from anything that was ever possible before. WebRTC support will grow, so it will get better over time. If you wanted real UDP support, you wouldn't be making browser games.

[Galvus]

Small correction to Fricken Hamster. WebRTC does go over UDP when it can and supports SCTP for reliable transport. http://stackoverflow.com/questions/18897917/does-webrtc-use-tcp-or-udp

As for UDP vs TCP, really you just want to send your positional data over UDP and keep anything of importance over a reliable channel. Sending the positional (spammy) data over UDP just means you can get away with sending it more frequently without bogging everything down. Hit detection lag due to latency is going to happen regardless of you using UDP or TCP but at least you should have a slightly more up to date picture of the client's position.