Jump to content

  • Log In with Google      Sign In   
  • Create Account


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
20 replies to this topic

#1 maunovaha   Members   -  Reputation: 279

Like
0Likes
Like

Posted 12 February 2014 - 04:55 PM

Hi all,

 

I just wanted to post a topic here which I asked recently at other forums also but didn't get yet much feedback.

 

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 smile.png

 

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? sad.png 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.

 

Why this thing is bugging me is that I feel that I have tried to make own multiplayer rpg many times at the past and finally when I am comfortable actually making it (and have the skills to make it), I see a big wall in front of me. As a bright side, I am much better programmer at this point than ever before. tongue.png

 

If UDP is the only way, I might quit my dream of making it to browser environment, that being said I also know java/c# and some c++/c just push me towards to making this all happen.. I would just hate to start it all over again to different environment.

 

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



Sponsor:

#2 Nikopol_AU   Members   -  Reputation: 421

Like
2Likes
Like

Posted 12 February 2014 - 05:17 PM

Realm Of The Mad God.
Real-time; Multiplayer; Client is written in Flash and can be played in browser.

So, yes, it can be done.

#3 maunovaha   Members   -  Reputation: 279

Like
0Likes
Like

Posted 12 February 2014 - 05:31 PM

Realm Of The Mad God.
Real-time; Multiplayer; Client is written in Flash and can be played in browser.

So, yes, it can be done.

 

Hmm that's a good point, I actually remember trying it once before.. even though it's with flash I assume that it really goes over TCP/IP (right!?) and works so well, that would be really good news rolleyes.gif



#4 Nikopol_AU   Members   -  Reputation: 421

Like
0Likes
Like

Posted 12 February 2014 - 05:50 PM

I assume that it really goes over TCP/IP (right!?)

Yes.

#5 maunovaha   Members   -  Reputation: 279

Like
0Likes
Like

Posted 12 February 2014 - 05:57 PM

thnx Nikopol, I think you break the myth, at least for now ! cool.png



#6 hplus0603   Moderators   -  Reputation: 5163

Like
3Likes
Like

Posted 12 February 2014 - 07:38 PM

World of Warcraft uses TCP. A bunch of real-time-strategy games use TCP. Whether you *need* UDP or not is dependent on your gameplay.

If your gameplay is twitch-based, first-person-shooter style, then no, TCP probably won't be a good choice.
If your gameplay can accept some command latency or sync latency, then TCP can give you much better compatibility than UDP, because you can run it in the browser (websockets, etc.)

For most games, I'd rather have 10,000 players that play something because it's fun and easily accessible, and sometimes complain about an occasional lag spike, than 10 players that can download and play an installable game for some particular platform.

Another reason to use UDP is if you need player-hosted servers, in which case the UDP NAT punch-through story is better (higher compatibility) than TCP.
enum Bool { True, False, FileNotFound };

#7 AllEightUp   Moderators   -  Reputation: 4184

Like
2Likes
Like

Posted 12 February 2014 - 08:40 PM

Another item to keep in mind is that UDP is no longer a guaranteed win in any case.  Many routers are configured to prioritize tcp over any form of UDP and as such have a very high drop rate for games.  Given this, the increased logic of routers to handle tcp packets better, along with the generally higher loss rate of UDP compared to even a few years ago, TCP *can* often provide better gameplay than even the best UDP.  Keep in mind, I'm not saying UDP sucks and you should not use it, just that as far as the win scenario goes, it is no longer easily cut and dry like it was.



#8 SeanMiddleditch   Members   -  Reputation: 5108

Like
1Likes
Like

Posted 12 February 2014 - 11:18 PM

TCP works fine for most real-time games if you disable the Nagle algorithm. Which, thankfully, some (maybe even most?) browsers do with their WebSocket implementation.

#9 jbadams   Senior Staff   -  Reputation: 17968

Like
2Likes
Like

Posted 13 February 2014 - 02:23 AM

You might be interested in this recent article on applying lessons from financial software to optimize TCP in a multi-player game. smile.png



#10 maunovaha   Members   -  Reputation: 279

Like
1Likes
Like

Posted 13 February 2014 - 05:33 AM

Thnx for the replies hpus0603, SeanMiddleditch and jbadams. Very interesting details, I definitely continue my project further and use all the techniques I can find and think of which could benefit making a game over TCP.. even if it means making small gameplay compromises, which I will make if game experience benefits from them. thnx!



#11 hplus0603   Moderators   -  Reputation: 5163

Like
1Likes
Like

Posted 13 February 2014 - 11:32 AM

Many routers are configured to prioritize tcp over any form of UDP


Every now and then, I hear this, but I have not seen any actual data or evidence of this being the case.
UDP is used for voice-over-IP, which is a large, important technology for the backbone carriers (that carry telephony and internet data interchangeably.)
UDP is also needed for DNS look-ups, which happen before most TCP connections even start; a slow DNS resolver is a more visible source of "slowness" to a user than almost any other reason!
I would be highly surprised if it was general behavior on the internet to drop UDP and favor TCP.
enum Bool { True, False, FileNotFound };

#12 zzzz....   Members   -  Reputation: 88

Like
0Likes
Like

Posted 13 February 2014 - 01:33 PM

.


Edited by spinningcube, 12 April 2014 - 08:02 PM.


#13 maunovaha   Members   -  Reputation: 279

Like
0Likes
Like

Posted 13 February 2014 - 06:23 PM

In HTML5 you have support for WebRTC which can go through UDP (or is it SCTP?) in Firefox (at the moment). Maybe check that out?

 

https://code.google.com/p/sctp-refimpl/

 

spinningcube

 

PS - It is something I am looking into myself, so quite interested

 

Hmm good point mate, however, that seems sort of a too far future to me when considering all the browsers people uses today (including mobile/tablet) ? we just got over the fact that websites doesn't need to work well at IE 6 anymore biggrin.png I don't even have Firefox installed, wouldn't this be same as using some another plugin in browser which could enable UDP (maybe unity?).. I mean that I am trying to look this thing from user point of view also - for me, browser based games is awesome because you can just navigate to a website and play. If you kill that idea, it is (almost) same to me than making some desktop app which you need to download. hehe.

 

I don't mean to be offending but this thing just crossed my mind smile.png if I continue programming games I might use WebRTC within few years from now.



#14 zzzz....   Members   -  Reputation: 88

Like
0Likes
Like

Posted 13 February 2014 - 06:51 PM

.


Edited by spinningcube, 12 April 2014 - 08:02 PM.


#15 zzzz....   Members   -  Reputation: 88

Like
0Likes
Like

Posted 14 February 2014 - 12:19 AM

.


Edited by spinningcube, 12 April 2014 - 08:02 PM.


#16 hplus0603   Moderators   -  Reputation: 5163

Like
1Likes
Like

Posted 14 February 2014 - 12:03 PM

OpenGL ES 2.0 compliant -> LLVM -> Emscripten -> Browser


FWIW, at work, we do just this for our newer and upcoming projects!
We actually have a C++ engine that targets native for mobile, and targets Emscripten for browsers.
There is a cost, both in development and runtime, for using Emscripten over using a native JS engine, but that cost is shrinking, and the cost of building two engines (one for native, one for JS) would have been *much* higher.
enum Bool { True, False, FileNotFound };

#17 zzzz....   Members   -  Reputation: 88

Like
0Likes
Like

Posted 14 February 2014 - 01:18 PM

.


Edited by spinningcube, 12 April 2014 - 08:02 PM.


#18 Phuein   Members   -  Reputation: 151

Like
1Likes
Like

Posted 16 February 2014 - 08:44 AM

I sense the uncomfortable vibe this topic brings to some, and I have recently ran into this little video:

 

http://www.youtube.com/watch?v=NpC1GbPw-fk

Charlie Crane: Game server development in node.js -- JSConf EU 2013

 

These good Chinese fellows are pretty much tackling this topic, in a serious scale. Open source, too. Great stuff. Video has some interesting statistics towards the end. I don't know any details, personally. Their code seems clean.


Edited by Phuein, 16 February 2014 - 08:45 AM.


#19 zzzz....   Members   -  Reputation: 88

Like
0Likes
Like

Posted 16 February 2014 - 12:49 PM

.


Edited by spinningcube, 12 April 2014 - 08:03 PM.


#20 hplus0603   Moderators   -  Reputation: 5163

Like
1Likes
Like

Posted 16 February 2014 - 01:30 PM

Super-dyanamic langauges like JavaScript (or PHP, or Python) can be highly productive while developing, but end up costing not only a bit of performance (a LOT for PHP, a little for JavaScript) but also in maintainability.
Check out this link, about how a single missing "var" statement ruined the launch of a product: http://blog.safeshepherd.com/23/how-one-missing-var-ruined-our-launch/
Sadly, all too common in JavaScript projects (although using jshint helps to some extent: http://jshint.com/ )
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS