Real-time multiplayer in a browser with node.js and HTML5 is a myth?

[user123456789]

Hi all,

 

I just wanted to post a topic here, because to put it simply I didn't know any other place where to state my concerns.

 

For starters, I wan't to say that I am currently middle of process researching/writing my own first real-time multiplayer roleplaying game to browser environment using technologies such as node.js/socket.io and I have my doubts whether I finish it some day or not - so won't be showing any cool links, at least, not yet

 

The thing which really concerns me is that I have stumbled upon an issue that TCP/IP (according to many resources and literature) is just not suited for real-time multiplayer games, it works for multiplayer games with slower pace where getting responses from server with varying even bigger milliseconds (or second(s)) doens't matter and don't affect the gameplay much. For instance, Heroes of Might and magic (turn-based) in a browser? possible. Games likes the type of Diablo (real-time), not possible.

 

To be honest, this is sort of a broken dream for me.. articles (from ACM) and through internet worries me that I have jumped too early to a train of technology, which simply to put - is not there yet.

 

I have tried my best to use techniques such as prediction, delta-packets vs full world snapshots and interpolation (which is sort of under dev atm.).. which makes my game use less bandwidth and be more latency tolerant.  

 

However, the real problem is in TCP/IP itself and how it works, because socket.io communicates over it, it is argued not to be not suited for real-time multiplayer games at all.

 

The fact which concerns me most is packet loss and how TCP/IP behaves in front of it compared to UDP:

 

"..whenever a packet is lost, everything has to stop and wait for that packet to be resent. On the client game objects stop receiving updates so they appear to be standing still, and on the server input stops getting through from the client, so the players cannot move or shoot. When the resent packet finally arrives, you receive this stale, out of date information that you don’t even care about! Plus, there are packets backed up in queue waiting for the resend which arrive at same time, so you have to process all of these packets in one frame. Everything is clumped up! Unfortunately, there is nothing you can do to fix this behavior with TCP, nor would you want to, it is just the fundamental nature of it!"

As a reference where this text is taken, section: "Why you should never use TCP to network a multiplayer game", see: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

 

So to speak, TCP/IP is not suited because it will try to resend data every time again and again through the line when it detects packet loss (including all buffered data which happened to every client at that time), even more, because it tries to guarantee this delivery it is much more slower than UDP. And the problem within case of a multiplayer game is that every new user joined to a game is a big risk in terms of service quality. We all know that packet loss is way too common.

 

In favor of TCP/IP I must say that I would really like to use it - I though that I could use it, but facts are really getting into me at this point. I have also seen resources like http://onedayitwillmake.com/blog/2011/08/creating-realtime-multiplayer-games-using-node-js/ which demonstrates that "hey this can be done". But lets be real, that is an example with few clients connected to a localhost? (At least, it looks like it) rather than running a remote server under real circumstances.

 

The thing which I also noticed earlier is that in node.js you can send messages using "volatile" flag while emitting, to avoid resending when failure is detected, however as I traveled through google I began to understand that it was only some internal queue issue rather than somehow mystically getting rid of problems of TCP/IP ?

 

Now, the question is - does someone have actual facts and proofs that TCP/IP is a winner in terms of real-time multiplayer games for browser environment or not?   Can it be done? and how? I am sort of a in a dead end right now.

 

If I need to abandon the idea of TCP/IP and just go for the UDP, within browser environment it is sort of "impossible" I found this reference: http://blog.alexmaccaw.com/chrome-tcp-udp but that's basically it, pretty limited.

 

Thnx, hopefully posted to a right forum, i need answers from other multiplayer game developers 

[AshleyScirra]

It's funny you posted this today - the same day we ran our first public test of the new WebRTC DataChannel powered multiplayer engine we've been working on. It had some bugs, since it was the first big test of a large codebase, but it worked surprisingly well and was pretty responsive. WebRTC DataChannels can use UDP transmission, which our engine does, and like traditional engines interpolates over gaps of missing data.

[user123456789]

It's funny you posted this today - the same day we ran our first public test of the new WebRTC DataChannel powered multiplayer engine we've been working on. It had some bugs, since it was the first big test of a large codebase, but it worked surprisingly well and was pretty responsive. WebRTC DataChannels can use UDP transmission, which our engine does, and like traditional engines interpolates over gaps of missing data.

 

Hehe, yea.. and this is sort of cool actually that WebRTC provides channels for TCP and UDP type of connections, however, within context of multiplayer games P2P is very dangerous, I recall that being number one communication architecture for cheating because game providers usually ends up broadcasting game states between clients. Sry, If I in rush understood something wrong but I checked its explanations related to peer-to-peer data channels. dunno if those are how you use it. 

[Antriel]

I didnt read all of what you wrote, just want to say that even though TCP isnt the best, it can still be used for real time games. If I remeber correctly even some older mmorpgs like Lineage 2 used purely TCP.

[Quetzacotl]

Actually most of RPG online games are using TCP. Article you are reffering to is mega old (I read it like 5 years ago at least) and it's not really accurate. UDP is needed when you change some values often and you can discard older changes (like position of character controller by WSAD). But most things you do in online game must be reliable (attack, cast a spell, say somethings, whatever). Some titles that use TCP: AoE, Warcraft 3, Guild Wars, WoW.

What matters is implementation, if you send packet every time unit moves a pixel then of course it will be slow. But if you are contorlling your character by mouse click, then all you have  to send is positiion where player clicked and moving will be simulated by client.

[Gio]

I think in an ideal world you would want to use both TCP and UPD for your real-time multiplayer games: send non-critical data such as position changes via UDP, send really important data (like an attack action) via TCP.

 

In practice though, unless you want to go with the p2p approach (and I agree with you, it isn't a great idea), you are restricted to TCP. So not ideal. Is it unusable though? I don't think so!

 

I haven't made any real-time multiplayer games using the technology that you described, however I have worked on real-time multiplayer games that worked very well over TCP only. One of these was a racing game, where latency is pretty critical, and yet it worked. It had an UDP  option too, and that worked better, but TCP was still OK-ish.

 

I've also used socket.io for turn-based games and I've found that the latency is minimal: our turn-based strategy game plays a sound on every client when you end your turn and if you have two people playing in the same room (still going through our server over the internet), you could end the turn on a PC and hear the sound on the other PC pretty much at the exact same time! Surely it depends on the host (ours is nodejitsu), and the server load (we never have more than 100 concurrent sockets).

 

I would imagine that if you made a real-time RPG, you wouldn't want many more concurrent sockets on the same machine either, but you would implement a "room" system where people in the same area subscribe to the same "room" and are isolated from the rest of the players. You could then have each room on a separate machine if and when lag becomes an issue.

 

There is also the fact that there are several ways in which a TCP-based protocol checks for errors and tries to recover. There is a very low-level mechanism that you can't control, that's true (your device's drivers take care of that). But there is usually also a higher-level control mechanism, that you can bypass by setting that volatile flag you mentioned in socket.io. This actually helps a lot, as this is the type of error checking that really slows things down.

 

The most important factor is probably how you design your networking protocol. Like Quetzacotl says, don't send messages every time a position changes, just send messages for the "target" positions, or try to extrapolate a position on the client that is moving and send extrapolated positions every so often, etc.

[user123456789]

I didnt read all of what you wrote, just want to say that even though TCP isnt the best, it can still be used for real time games. If I remeber correctly even some older mmorpgs like Lineage 2 used purely TCP.

 

Thanks for noting that and I remember reading something like that from the article once (about lineage 2) but I couldn't find it anywhere.

 

Actually most of RPG online games are using TCP. Article you are reffering to is mega old (I read it like 5 years ago at least) and it's not really accurate. UDP is needed when you change some values often and you can discard older changes (like position of character controller by WSAD). But most things you do in online game must be reliable (attack, cast a spell, say somethings, whatever). Some titles that use TCP: AoE, Warcraft 3, Guild Wars, WoW.

What matters is implementation, if you send packet every time unit moves a pixel then of course it will be slow. But if you are contorlling your character by mouse click, then all you have  to send is positiion where player clicked and moving will be simulated by client.

 

well, thats interesting info.. I also got a response that real of the mad god uses TCP also, I would prefer going to direction of arrow movement but I think it is just up to me to try and make it to see how well it performs. If it doesn't maybe I just make game design compromise and switch over to mouse movement and live with that its anyway faster than doing it all from scratch.

[user123456789]

There is also the fact that there are several ways in which a TCP-based protocol checks for errors and tries to recover. There is a very low-level mechanism that you can't control, that's true (your device's drivers take care of that). But there is usually also a higher-level control mechanism, that you can bypass by setting that volatile flag you mentioned in socket.io. This actually helps a lot, as this is the type of error checking that really slows things down.

 

The most important factor is probably how you design your networking protocol. Like Quetzacotl says, don't send messages every time a position changes, just send messages for the "target" positions, or try to extrapolate a position on the client that is moving and send extrapolated positions every so often, etc.

 

Okey Gio. I have currently tried to minimize bandwidth usage with my own movement but because it is arrow moment (instantly switch direction) I need to tell server basically at every step where I am. I obviously need to change that, maybe I can first even make 50ms lag to start of the moment, (before anything happens) which will skip some of the input and something like braking time instead of straight switching direction. This stuff will be interesting to try out thnx for the response!

[AshleyScirra]

Server-based is a subset of peer-to-peer. So you can still make a WebRTC game server-based, just make a special peer for the host.

[Maxime]

Mozilla game BrowserQuest is using webSocket to make the multiplayer side of the game.

And as far as I saw it works like a charm.

 

WebSocket is based on TCP and so maybe TCP is not as bad as you might think. (https://hacks.mozilla.org/2012/03/browserquest/ for tech under the game and https://github.com/mozilla/BrowserQuest for the source)

[jamesaustin]

The multiplayer version of Score Rush uses WebSockets and also supports host migration. Host migration is a system where one of the players acts as the host for the game, if they drop out another player takes over.

 

Score Rush is a pretty intense shooter and whilst WebSockets are far from the most optimal communication transport it is sufficient in this case.

 

https://ga.me/games/scorerush-mp

[drhayes]

Just wanted to jump in on this thread to point out Realm of the Mad God. It's an in-browser MMO coded in Flash.

 

I have no experience coding networked multiplayer games, but I've read that TCP is sufficient these days because of our faster, more reliable connections. Is this not true? Does the engineering cost of rewriting reliability and packet ordering in UDP really outweigh the overhead of TCP?

[user123456789]

Just wanted to jump in on this thread to point out Realm of the Mad God. It's an in-browser MMO coded in Flash.

 

I have no experience coding networked multiplayer games, but I've read that TCP is sufficient these days because of our faster, more reliable connections. Is this not true? Does the engineering cost of rewriting reliability and packet ordering in UDP really outweigh the overhead of TCP?

 

Yea, point taken.. and yes we got now better connections and I have began to believe that TCP is good enough up to some point. But with UDP you would get so much more control on packet transferring that it could be tuned up for the purposes of your game "perfectly". Considering engineering costs and reliability, you should never even consider using UDP if your game will tolerate latency and you can measure that TCP is good enough (now and in the future of the game), imo. On the other hand, if you or me haven't before programmed any network games over TCP, UDP could be too big leap to take anyway. After finishing programming it, you might have similar "TCP features" over UDP which works worse than using that TCP right away. hehe. I definitely continue programming over TCP and learn from it first.