Let's have a JavaScript gaming related networking discussion.

[BTOnline]

There's quite a few posts like these all over the internet, however most of them dating back to 2010-2011. Everybody is aware that technology is ever-so expanding. I'm sure most of you, if not everyone here is familiar with, or has at-least heard of Node and the advances that it's made with JavaScript servers(and other applications). However considering this is  a forum about gaming, let's go ahead and cut to the point of the discussion.

 

Games are constantly evolving, and while technology is as-well, sometimes you wonder which one can't keep up with what. Games like Tera have really showed us that technology has come a long way and we can do so much more with it than we used to, simply due to the speeds of networking. We're able to transfer a much greater amount of data at much faster rates than previously possible. These limits increase day by day.

 

However when it comes to developing games with JavaScript we really have to stop and think. What can we really accomplish? Sure, some networking can be accomplished, but to what scale? Creating a cookie-cutter mmorpg that follows in world of warcrafts footsteps wouldn't be that hard. We'd use the same TCP latency-hiding techniques that they use, such as all of the pretty animations before the server responds. When data is lost over a TCP connection, unfortunately, that's what I like to call a "Stop and drop", because the network forgets about everything else besides for the lost data, and does whatever it can to retrieve it. This causes a temporary latency spike (for everybody connected to the server). Unfortunately for us, WebSockets are layered on-top of the TCProtocol. 

 

This limits what's accomplish-able. There's an example of a game that was created with PlayCanvas called tanx which sports networked play over web-sockets, and it looks fairly smooth. There's no telling how many players are actually online at any given time, but the game-play seems really, really smooth. They've done a nice job making sure of this in their code. (Tanx is open source and can be found on github) They store movement data from opposing tanks and lerp it into position, giving it a really smooth visual on the screen, but that's not exactly the case. I have fairly good internet (Around 17ms latency to most games) and I could feel the lag just by playing. You'd have to shoot in-front of the other tanks (Sometimes even visually missing them on your screen) for the server to register a collision. Sometimes you could shoot at a tank numerous times and a collision would never be registered, but let me tell you, they sure sailed across the screen smoothly. Once again, this is a simple implementation of latency hiding (Although, also a common implementation for movement to prevent jitter). 

 

So this leads me to ask the community, what can we really accomplish? Day by day I'm slowly starting to rethink having my main project worked on in HTML5. I've been working on my own engine and everything for it, but I slowly start to regret not using a more popular and established engine that compiles to native code, such as Unity. Fortunately for me, I have plenty of experience in Unity and my own networking libraries I've created for it in the past, so all I'd be sacrificing is quite a bit of development time and HTML5 support. The game that I'm working on is close to das-tal a PvP sandbox mmorpg(Alpha) in the event that it has skill-shot only based combat. However it's actually 3D and far more aesthetic. As-well as far more fast-paced. The game takes place in a fantasy environment. 

 

Sure, let's say with 4-8 players online I could accomplish this, granted everyone had a good connection to the server. However how would this scale with web-sockets? The goal in my game is to have one master-server where everyone will play together. 

 

So, what do you guys feel are the current limitations of our networking access with HTML5? 

[b10b]

Very interesting topic to me.  I won't pretend to know the detail of the answer yet, and have just begin a journey with NodeJS and Socketio to explore such things.  I have non-JS experience with lag and jitter correction techniques and server authoritative models so will probably create a model where I can tweak the relative input of each towards finding the best balance.  But you make the bigger point, TCP is not ideal for synchronous, it will belch eventually, all we can do is hide the smell.  Perhaps there lies our answer?  Designing to the problem.  Near real-time asynchronous (over multi platform) perhaps best suits players' needs these days - the abillity to pick up and resume when they feel like it, not when their competitor is available?

[BTOnline]

Very interesting topic to me.  I won't pretend to know the detail of the answer yet, and have just begin a journey with NodeJS and Socketio to explore such things.  I have non-JS experience with lag and jitter correction techniques and server authoritative models so will probably create a model where I can tweak the relative input of each towards finding the best balance.  But you make the bigger point, TCP is not ideal for synchronous, it will belch eventually, all we can do is hide the smell.  Perhaps there lies our answer?  Designing to the problem.  Near real-time asynchronous (over multi platform) perhaps best suits players' needs these days - the abillity to pick up and resume when they feel like it, not when their competitor is available?

 

When it comes to very simple things such a real-time turn based games, etc.. I feel like TCP is just fine, even with the occasional lag, it'd just be more of an annoyance than a corruption to game-play. When I speak of a real-time game, I think of something such as a 3D action combat game. Where data is constantly being sent back and forth between the network. The user is going to be spamming his mouse-button for attacks, and the server is going to have to respond to each one of those requests. Even if you don't respond to the request in your code, the nature of TCP will respond to the request just to say "Yeah, I got it, thanks".  You could obviously attempt to limit the amount of requests on the client-side code, for instance say your character can only attack once every 1.50 seconds. Creator a client-side timer that prevents sending the packet to the server. However hackers are everywhere and you know they're going to try, so we still need the server to be able to handle the events when necessary.

 

In a highly active real-time "real-action" game like this, any type of TCP stutter cannot be hidden. It just.... can't be done. Unfortunately. For more basic, slower things it'd be simple. A card game? Sure. Lets hide the smell of server lag by playing a drawing card animation / flipping card animation before the server actually responds, that way when the animation finishes chances are that everything will look normal. (Unless of-course you have a really bad connection or the lag spike is ridiculous). 

 

There's tons of examples of people "hiding the smell" of TCP stuttering, that we don't even realize. 

 

Just a single instance of a packet dropping sends everything spiraling into a massive mess that we need to cover up.

 

My favourite quote that I direct towards TCP connections all of the time, is the next 2-3 seconds in this video: Click here.

 

"One thing, and the entire thing comes down."

Just to state, I am in no way a professional. I'm a hobbyist and I study during my free time. I'm not an advanced JavaScript programmer and I've only been messing with it for a few months. I mainly come from a Java background where I've written most of my servers. With some C# experience from the few years of working with Unity3D

[mrmaxm]

Hi there.

Regarding tanx, it has been written initially on 12 hours hackathon. And whole networking since then pretty much hasn't changed.

It uses WebSockets as main transport layer, and does simple interpolation. Even players input is not extrapolated/applied on player on press.

Everything is simply interpolated, which is most simple and lazy approach. Although as you've said: it feels smooth still. It does until you have latency 100+, which simply achieved by playing from another side of planet earth, although to go around it, I've created another game server in US, and it load-balances based on lower latency to one of two datacentres.

 

In order to make real-time multiplayer experience better, all you need is to implement optimistic network model, with authoritative server.

Where all clients will be extrapolating game state in the future based on their latency, by that trying to match game state at the present time on the server.

Server in meantime has to store game states on each tick, for last second. And should try to apply important user input from the past, propagating on game states from past till present, based on players latency. Higher the latency - further in the past state server should go to calculate user input against.

 

If those mechanics are implemented into design from the beginning, then players will have pleasant experience, where game will feel very fair, and there will be no flying through bullets or anything unfortunate like so.

 

There is a conversation regarding UDP that would improve quality of some data delivery (speed when reliability is not important), it can indeed. But event with TCP (WebSockets), loads can be achieved, and way bigger games can be made than tanx, which was just a weekend hackathon project.

 

 

Most important, is the audience and its size. As you build html5 game that lives in the web, you have to focus on making the most quickly loading game, with most easy way to engage with other players from the start. If you can make 1-click experience to get to playing, and game loading below 1-2.5 seconds, then web requirements are satisfied, and next will be just making cool gameplay.

Audience in the web is huge, it is bigger than any platform out there, with almost 90% WebGL coverage you get loads people, in minutes (just tweet url, and you get them on your game).

 

Best thing here, is start small, and progress forward, make cool and enjoyable simple game, and publish it out, you'll be pleased and surprised by number of people and their engagement with your game.