Good multiplayer performance possible with phaser?

[dlsso]

I am interested in creating multiplayer games with phaser. I found a very small handful of examples. I used the one that looked the most functional to create a multiplayer space combat game. However, I found that when I put it up online it was very laggy.

 

Now the original author was using eureca.io, which may be slowing things down. I am also pretty new to coding so I may be running a lot of unnecessary updates. (Feel free to point out or fix mistakes in my code)

 

My big question is:

Do you think it is possible to create a fast real time multiplayer game with lots of updates happening using phaser, or am I running into some inherent limitations?

 

 

Subquestions are:

Do you think it would be faster if I learned sockets and re-wrote it without using eureca.io?

Do you have any theories about what specifically is causing the lag?  (Running locally and making multiple connections via multiple tabs is smooth, but multiple computers even on the same local network is always laggy)

I know I am sending a lot of updates. If anyone wants to look at my code and see if there is a performance hitch there that could be fixed, that would be very welcome also.

[YellowAfterlife]

Phaser itself has little to no impact on multiplayer part of the game.

What you are seeing is also not a performance issue, it is the erroneous client-side code handling the data.

Applying "returning" data to the local player directly is a pretty bad idea.

What you should do by least, is add some actual interpolation algorithm to handle gradual changes of positions and velocity.

At some point I've used this algorithm by @thijsmie:

    t2 = t * t    t3 = t2 * t    dx = t3 * (2 * (x0 - x1) + vx0 + vx1)        + t2 * (3 * (x1 - x0) - 2 * vx0 - vx1)        + t * vx0 + x0    dy = t3 * (2 * (y0 - y1) + vy0 + vy1)        + t2 * (3 * (y1 - y0) - 2 * vy0 - vy1)        + t * vy0 + y0

Here,

(t) is time factor for interpolation (0..1)

(x0, y0) is initial position

(vx0, vy0) is initial velocity

(x1, y1) is destination position

(vx1, vy1) is destination velocity

(dx, dy) is interpolated position.

[dlsso]

Cool, thanks. I believe I understand the interpolation. Could you explain the problem in a little more detail though? When you say returning data is being applied to the local player it gives me this impression:

 

1. Local player moves

2. Local player sends update to server

3. Server sends update to all players

4. All players including local player get that location update

 

Is that correct?

 

If so, then the first fix would be to add an "if not local player"  to the update so that his position doesn't get incorrectly overridden, and then adding interpolation would help smooth it out for the other players. Correct?

[JUL]

Would it not be rather

 

1. Local player moves

2. Local player sends update to server

3. Server sends update to all players once all players have sent their update

4. All players including local player get that location update

 

?

[dlsso]

I don't recall any synchronous requirement. I think each player would be sending out updates on input rather than everyone waiting for updates to go both ways. I imagine that would be horrendously slow.

[YellowAfterlife]

Cool, thanks. I believe I understand the interpolation. Could you explain the problem in a little more detail though? When you say returning data is being applied to the local player it gives me this impression:

 

1. Local player moves

2. Local player sends update to server

3. Server sends update to all players

4. All players including local player get that location update

 

Is that correct?

 

If so, then the first fix would be to add an "if not local player"  to the update so that his position doesn't get incorrectly overridden, and then adding interpolation would help smooth it out for the other players. Correct?

Pretty much so. You can still consider the local position sent back from server, but need to interpret it accordingly (see input prediction), as it is delayed by time needed for data to travel there and back.

[Ezelia]

hi @dlsso, I'm the author of the tutorial

 

Just to make it clear.

Eureca.io adds almost no overhead when it comes to network performance, it's only an abstraction layer to make client/server calls more "natural".

what Eureca.io basically do, is translating
something like : server.foo()
to socket.emit('foo')

you can check and compare the eureca.io websocket traffic with any other library from Chrome developers tools.

and by the way, you can switch from engine.io to sockjs as a transport layer for eureca, sockjs provide better performance in some cases, but as other commenters said, it's not the network traffic that's causing the lags

websockets are very suitable for simple multiplayer games (which don't need a huge data exchange),
WebRTC would be the choice if you was making a 3D multiplayer game for example .


btw : I'm very pleased to see that my tutorial helped you creating your game !

[lewster32]

Regarding WebRTC (which is definitely the way to go if you want to minimise latency) I've had some great results with PeerJS.

[Ezelia]

Hey lewster32, what did you used in the server side to handle webrtc ?

I'm trying to find a good implementation to add webrtc support to eureca.io

EDIT : I meant, a client/server WebRTC implementation, not a P2P

[lewster32]

They provide a peer server for free or you can run your own on a nodejs server. I did the latter and got it working very quickly. The peer server just acts as a peer matching system to establish the p2p connections between clients.

[Ezelia]

Yeah but if the server is not proxying data, it makes the multiplayer implementation very complex...

What I need is a nodejs implementation that act like a centralised peer

[lewster32]

A centralised peer isn't peer-to-peer anymore, it's client-server and is best handled via sockets. WebRTC is about clients communicating directly with one another; that's the whole point! It's not necessarily more complex either, you just make one of the clients the 'master' and have each client validate any data that comes into them, and in the case of an inconsistency, the master becomes the authoritative peer and determines the correct outcome.

[Ezelia]

Agree with your approach except for one point.

The master peer need to be a trusted entity, when implementing a game you can't trust a random client. Otherwise you have to deal with complex validation algorithms.

This is not needed for audio/video conferencing but mandatory for games.

My approach is the same as yours except that master clients need to be trusted instances running on "servers"

[lewster32]

The way I've gone about it is by allowing any peer to create a lobby. Upon creation of a lobby that peer becomes the 'master'. Once the game starts, all clients will be doing basic validation of incoming data, and in the case of a situation where any peer reports an inconsistency, the master peer enforces its outcome on all peers. If the master leaves, the first player who joined the lobby becomes the master and so on until there are no players left. Doing it this way allows a similar experience to client-server architecture without the need for a server.

 

There are downsides however - the latency is higher than if all clients were connected to a nearby server, and if one or more peers is experiencing a poor connection, the whole game suffers as the amount of inconsistency errors rapidly rises. It's not an ideal solution by any means, but it can allow you to get multiplayer stuff going quickly and without worrying about scaling your servers. Also much of the code you write for peer-to-peer will be fairly easy to translate into a client-server architecture too, so all isn't lost

[Ezelia]

You have here an implementation of what p2p implementations should look like.

What I provide with eureca.io is just an abstration layer to make client able to call server declared methods and vice versa.

The server is a nodejs instance if only I can find a good nodejs webrtc client implementation I can easily provide the same abstration for webrtc like I do now with websockets... Except that it'll give lower latency

[lewster32]

Is your reasoning for WebRTC being faster the fact that it defaults to UDP whereas websockets have to use TCP? I guess that makes sense, but it does mean you're applying a slightly hacky concept to WebRTC in order to make use of that - not that I'm against hacking of course! Some of the best tools I've used have begun life as hacks

[Ezelia]

No I'm not trying to hack anything
All I want to do is to provide another mean to communicate between client and server.

the current implementation of Eureca.io with websockets (it uses primus actually) works very good. and as I said, Websocket is suited to most simple multiplayer games.

but in some use cases WebRTC usage can be justified.

I'm giving an example of how Eureca.io works so you can understand me.

in the eureca server side I'll define some methods,

 

Let's say that the server defines this function
 

server.exports.posChange = function(x,y) { ... updating client pos ... }

the client side (the browser) can call server.posChange(10,20) to send it's actual position...

the client also can define a remote callable function, for example

client.exports.setPlayerPos = function(playerId, x, y) { ... positionning remote player pos ... }

the server can use this function to broadcast other players positions to a given player using something like
 

playersList.each(function(client) {   client.setPlayerPos(client.data.id, client.data.x, client.data.y);})

in the above use case, TCP is good if I want to make sure that all the remote calls are executed.

 

 

but some developer can decide that if some setPlayerPos() is lost, it's not a big issue since it'll be updated in the next successful call.

in this case, webRTC can bring a little optimisation because it's the way it works actually


Edit : there are some examples of how eureca works in the website btw ==> http://eureca.io/

[dlsso]

Pretty much so. You can still consider the local position sent back from server, but need to interpret it accordingly (see input prediction), as it is delayed by time needed for data to travel there and back.

 

Alright, cool. I will see if I can fix it!

 

hi @dlsso, I'm the author of the tutorial

 

Just to make it clear.

Eureca.io adds almost no overhead when it comes to network performance, it's only an abstraction layer to make client/server calls more "natural".

what Eureca.io basically do, is translating

something like : server.foo()

to socket.emit('foo')

you can check and compare the eureca.io websocket traffic with any other library from Chrome developers tools.

and by the way, you can switch from engine.io to sockjs as a transport layer for eureca, sockjs provide better performance in some cases, but as other commenters said, it's not the network traffic that's causing the lags

websockets are very suitable for simple multiplayer games (which don't need a huge data exchange),

WebRTC would be the choice if you was making a 3D multiplayer game for example .

btw : I'm very pleased to see that my tutorial helped you creating your game !

Awesome, nice to meet you! It was a huge help, I used most of the update code verbatim, just adding in some extra updates so that entering players would send their position to existing players and some stuff like that. I found the eureca syntax very easy to work with as well. Now excuse me while I read the rest of the thread and lean how webRTC fits into all this.

[Ezelia]

sure !

If you use webRTC for your game let us know if it brings some performance to the game

and if the complexity of implementation worth the switch.

 

I'm thinking to add a Peer class to eureca that'll use webRTC, and later a client/server transport layer based on webRTC, but I'm waiting for more stable webRTC stacks on both browsers and nodejs, before deciding how the implementation should be.

[dlsso]

Quick stab at it didn't work. When I add an exception so that the updates don't run for the local player I can't move him at all. Maybe I was doing it in the wrong spot or something. I was sick today so my brain may not be fully functional yet.