Phantasm Posted August 20, 2015 Share Posted August 20, 2015 Hey guys! We are currently looking into various HTML5 frameworks to build a multiplayer game. One of our biggest questions is security and how it is handled, now specifically for physics such as arcade physics. I am asking her because I have scoured the topic and despite learning a bit of phaser, I can't yet give an educated answer to our questions. I would love to have expert opinions on the following :Can you prevent physics tampering with Phaser? While using arcade physics? Can movement be secured to prevent teleports, speedhack? Basically, how easy is it to make a multiplayer game with phaser that has server side algorithms for the easily hackable parts? Thanks, guys, I'm looking forward to your opinions and answers! Link to comment Share on other sites More sharing options...
netcell Posted August 20, 2015 Share Posted August 20, 2015 Since the framework is client side javascript, technically there aren't any way to completely prevent tampering without serverside cross checking Link to comment Share on other sites More sharing options...
Phantasm Posted August 20, 2015 Author Share Posted August 20, 2015 Hey netcell! Yes, I do get this is a client side framework and thus needs server checks. How easy is it to hook into phaser events from the backend, to check if tampering is occuring? Would performance take a huge hit? Link to comment Share on other sites More sharing options...
drhayes Posted August 20, 2015 Share Posted August 20, 2015 I'd think that you run the physics simulation on the server and send periodic, relatively frequent updates to your clients, probably via WebSockets. The clients could meanwhile do a dead-reckoning-prediction type thing and not use Phaser's physics systems directly. In other words: pretty easy, except for all the realities of multiplayer networking. ( = Link to comment Share on other sites More sharing options...
tips4design Posted August 20, 2015 Share Posted August 20, 2015 I'd think that you run the physics simulation on the server and send periodic, relatively frequent updates to your clients, probably via WebSockets. The clients could meanwhile do a dead-reckoning-prediction type thing and not use Phaser's physics systems directly. In other words: pretty easy, except for all the realities of multiplayer networking. ( = I agree. It is pretty easy, as you can run the same code on both server and client. Then you only have to sync the client to the server once in a while. Extrapolation is done automatically by simply running the same physics on client and server. Interpolation is easily done between the current player position and the server position. Link to comment Share on other sites More sharing options...
Phantasm Posted August 20, 2015 Author Share Posted August 20, 2015 Is running ning phaser on the sever good practice? I saw posts against doing thisThank you all for your answers Link to comment Share on other sites More sharing options...
drhayes Posted August 20, 2015 Share Posted August 20, 2015 Define "good practice"? It has a headless mode, but, honestly, I've never tried it. Link to comment Share on other sites More sharing options...
tips4design Posted August 20, 2015 Share Posted August 20, 2015 Define "good practice"? It has a headless mode, but, honestly, I've never tried it.I've tried it and it runs pretty good, even though I don't know exactly how many instances of the game you can run on the same server (so all run at 60fps) Link to comment Share on other sites More sharing options...
Phantasm Posted August 20, 2015 Author Share Posted August 20, 2015 Yeah, what I meant by good practice was would I hit performance/code problems by using phaser as a physics engine in the backend. Like do you have to run one instance per client? If it is the case, i would need to run hundreds of instances at once Else I guess I could just code checks server side and simply use phaser frontend Link to comment Share on other sites More sharing options...
drhayes Posted August 20, 2015 Share Posted August 20, 2015 That's a good point, having a bunch of simultaneous games in memory might be challenging, especially since a bunch of the chunkiness of a Sprite is wrapped up in its display. Maybe you strip out a lot of that stuff for your custom engine? Might be a good opportunity for a fork of Phaser: a copy that's made to run server-side in NodeJS, so it "only" runs physics. Link to comment Share on other sites More sharing options...
tips4design Posted August 20, 2015 Share Posted August 20, 2015 1) With Node.js you can have (and should have) only one game running per node instance. You can instantiate multiple nodes on a single server.2) You don't need to actually load the sprites, you only need their width and height for the physics calculation.3) A nice way run multiple instances would be to have something like a shared memory between the instances for the game logic (and maybe some sprites data) and each instance only allocate memory for sprite positions and physics related stuff, so by running multiple instances you won't have duplicate memory on the server.4) The ideal way would be to create a physics version of your game which only contains the absolute necessary that has to be run on the server. The thing is, no one has time to do this for multiple games, thus running directly the client version on the server usually makes sense (as long as you don't required tens of servers and the cost of running them becomes a problem). For small games it should work fine. Link to comment Share on other sites More sharing options...
Phantasm Posted August 20, 2015 Author Share Posted August 20, 2015 Thanks everyone for your opinions and explanations. I think we will be exploring other options since we are going for a very high concurrency per server (thousands of clients). That said, I might try your solution and see how it runs with many clients. Who knows, maybe it'll work! Link to comment Share on other sites More sharing options...
netcell Posted August 21, 2015 Share Posted August 21, 2015 I'd think that you run the physics simulation on the server and send periodic, relatively frequent updates to your clients, probably via WebSockets. The clients could meanwhile do a dead-reckoning-prediction type thing and not use Phaser's physics systems directly. In other words: pretty easy, except for all the realities of multiplayer networking. ( =Seriously it's just weird to do that since it can overload the server when you have big CCU. I think it's best to find some useful information to cross checking instead of put a full blown physics engine on the server, though which to check is depends a lot on the gameplay Link to comment Share on other sites More sharing options...
george Posted August 21, 2015 Share Posted August 21, 2015 Thanks everyone for your opinions and explanations. I think we will be exploring other options since we are going for a very high concurrency per server (thousands of clients).That said, I might try your solution and see how it runs with many clients. Who knows, maybe it'll work! NO NO NO! Do not explore other options. If you really want to prevent the people from cheating- server side is the way to go. You can't trust the client. Never. The server must be the authority. This is achieved with client-side prediction (since Quake 1, running headless on the server) plus lag compensation (since Counterstrike). Every AAA game and every serious web game is doing this. Server time is cheap nowadays, so you can do this too. If you're serious about your game - talking about thousands of clients make me feel so - then you have to protect the reasonable players from the cheaters with this industry-proven technique. Read those documents and you will get the hang on doing it on the server. 1. A famous read from 2001 by Bernier, an engineer at Valve. I love this piece of science. You will read about client side prediction and lag compensation in context with other parts of a game.https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization 2. The young Carmack writing about client side prediction:http://fabiensanglard.net/quakeSource/johnc-log.aug.htm 3. I just love this fact. This is again Carmack about a network ping which is faster across the atlantic than the LCD refresh rate. http://superuser.com/questions/419070/transatlantic-ping-faster-than-sending-a-pixel-to-the-screen/419167#419167 4. And a very good multiplayer guide with node & socket.io. http://buildnewgames.com/real-time-multiplayer/ How you can achieve this whole networking with Phaser & Phaser Headless? This is another question. Regards George Phantasm and drhayes 2 Link to comment Share on other sites More sharing options...
CtlAltDel Posted August 21, 2015 Share Posted August 21, 2015 I used the articles linked above to create my multiplayer shooter : http://www.html5gamedevs.com/topic/12917-wiptechdemophaser-topdown-2d-multiplayer-shooter/It uses Phaser only on clientside, the physics/collission is all handled with my own algorithms since I needed some specifics. Both the client and the server use the same collission detection and movement handling (same file, but browserified for the client and kept as a module for node server). The server however is authorative. Read up on the subjects, it's actually not hard to create a server. I think mine is around 400 lines of code (excluding the collision libs etc, purely the logic of dealing with messages and responses) Hope this helps. Link to comment Share on other sites More sharing options...
Phantasm Posted August 21, 2015 Author Share Posted August 21, 2015 Hey George! I will definitely read up these when I get the time. Running the whole game on the server looks interesting but I feared the cpu cost. Since you are telling me it is an industry proven technique, I will most definitely read up on it and try it! Thanks for your input. CtlAltDel, very interested in how you did your phaser project. I will read up on how to make a node version and a browser version! Link to comment Share on other sites More sharing options...
Recommended Posts