How to: Authoritative servers with phaser?

[christianstrang]

I'm currently developing a 2-player multiplayer game with phaser, Node.js and Sock.js

Right now the users just send there x,y-position coordinates to the server which then broadcasts this information to the other player and vice versa.

 

This was the first prototype and after evaluating the functionality I now want to switch to a server-authority model to prevent cheating etc.

 

My question is: How would this be best done with phaser? Is there a way to install phaser on the server or at least the physics engine? Are there any tutorials that specifically target phaser with this approach? Looking forward to your experience with this topic

[lewster32]

Phaser can indeed run in 'headless' mode (though I'm not sure how well tested it is running in nodejs) but I reckon you may be opening a huge can of worms performing server-authoritative physics as even the smallest amount of delay will lead to literally chaotic results - as well as the potentially large load you'll be creating on the server.

 

Real time client-server games programming involves many very nuanced concepts, especially around prediction and other lag compensation techniques, and these are not addressed within Phaser.

 

I'd probably suggest that if you do go down this route, the server is written from scratch to do only the things your game needs from a server standpoint as optimally as possible. This may include a simplified but analogous physics implementation that maybe runs at a reduced timestep, and which acts as a server-side way of checking that the things the players are doing are within a certain tolerance of what should be possible. That way, you can have the gameplay progress more smoothly, and only step in when things get weird.

 

The very best of luck with this, and please do share your progress with us as this is an area that's presently not well covered in the HTML5/JS world.

[Vaughan]

You really should not try to embed what is supposed to be a client-sided framework into your server. They server two different purposes and Phaser is going to provide a lot of overhead on what you really wanted. Instead, write a server that contains the components and simulation data you require. This will be a lot easier to do and way less overhead. There's quite a few examples online, check out my project OpenORPG which uses this model. It's written in C#, not Node though. 

[christianstrang]

@lewster32 & @Vaughan: I just created a prototype that uses the P2.js physics engine on the server and phaser on the client, is this what you were referring to?

 

The next step now would be to implement the various multiplayer concepts, referring to these articles:

- http://buildnewgames.com/real-time-multiplayer/

- https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

- http://www.gabrielgambetta.com/fast_paced_multiplayer.html

[lewster32]

Those are all excellent articles, and the last one in particular explains the main concepts behind realtime multiplayer programming.

 

I would go so far as to say that running P2 physics on the server will almost certainly create a lot of headaches, especially as the connection quality decreases. Generally the model of the game on the server will be highly simplified and specific to the purposes of gameplay (basic collision detection, position synchronisation and entity state management) and will be used to determine if actions are reasonably likely to be valid. The more server authoritative you go, the more laggy and glitchy the game will appear to players - which is a poor tradeoff in most cases to catch cheaters.

 

Modern games usually back off somewhat on server authority and deal with cheating in other ways. This is why, for instance, cheating is rife in games like Battlefield 3 - the server model is deliberately lax so that the game can efficiently handle the sheer amount of things that are going on with minimal lag. A client-side physics engine then takes care of smoothing it all over and, in the case of non-essential items, applies more realistic physics to them - i.e. fragments from explosions and other decorative elements. These elements are not synchronised between the various players as they usually only respond to the environment, rather than affect it; the position of a small piece of debris has no impact on the gameplay and no-one will notice if it's in a different place on their game.

 

The bottom line is that you have to decide where you want the tradeoffs to be, because inconsistent network delay will always remain a factor, and even tiny discrepancies will cause all but the most simple physics engines to literally spiral into chaos.

[Vaughan]

I agree with why lewster has to say. Simplify your model as much as you can. Trying to run huge physics simulations every tick will not scale well.

[christianstrang]

Thank you for your answers, I already backed off from P2 on the server and reverted back to simplified movement (x += 2 for example). I will try to implement the other concepts as well in the prototype to figure out how this all works. Will update you here as I dig deeper into this topic