Some help/direction with moving client logic to the server

[MeMyMo]

Hey,

So I'm messing around with Phaser and Socket.IO, I got a simple "game" working where multiple players can connect and you can see each other/move.

The thing is that movement/collisions (for the current player) is client side, relying on arcade physics and x/y velocities.

I'm a webdev, so I know it's not smart to rely on the client, but I'm having some difficulty understanding how I would do collisions/movement on the server side.

Movement might be easier, I could probably have an update loop on the server and just send over the player's moving direction and then calculate the new coords on the server and send them back, but that would defeat the purpose of using collisions on the client, no? 

Am I right thinking that I will have to run my own collision logic in the server? Any pointers on what I should do?

My "game": http://104.131.68.91:3000/ (Yeah, sometimes it doesn't spawn where it should...)

My repo: https://github.com/max-arias/mp-phaser

Any help appreciated!

[stupot]

If you run any logic in the client that affects outcomes, then players will hack and exploit that, so keep the important things server side.

The server should be recieving player movement requests, updating it's view of the world, including running the logic of the collisions, then updating the clients view.  The client could be allowed to do a little prediction to help with visual smoothness.

You could investigate getting Phaser running in headless mode in node, I'm not sure if this was ever maintained/completed.  Also checkout Phanton.js, it's a browser emulator, could be the quickest way of getting Phaser running in nodejs.

Failing that, you don't have to use Phaser's physics, you could find another Physics engine that runs server side.

[Skeptron]

Completely depends on what you want to achieve, but if you want to build a solid, robust, real-time, competitive game, then you're in for a LOT of work. Achieving this when you have no experience is absolutely gigantic. There are lots of good tutorials on several strategies regarding this matter, all with pros and cons. This one might be the most famous and well-written one : http://gafferongames.com/networking-for-game-programmers/

Also keep in mind that playing real-time stuff in the browser is even harder due to TCP being kind of slow.

I'm not trying to discourage you, but if you can afford to make your game 'hackable' (ie, if it's not competitive but simply casual with no important reward), then keep your architecture as simple as possible and don't bother spending too much time on perfect server authority.

That said, I wish you the best of luck!

 

 

[stupot]

Skeptron is right that it's quite a task. Be prepared to rewrite it as you go as you work out better ways of doing things.  You might even end up parting with cash to pay for decent server space.

If you do go down this route, then you'll learn a lot.

[MeMyMo]

I've been looking at how BrowserQuest does it and I'm getting a better idea. I'll read up on your link Skeptron, too.

For the moment I'll go with something a bit more amateur-ish, I don't think it's all that important that it's 'hackable' as much as releasing something is.

Appreciate the input guys, thanks.

[Arcanorum]

Some other thoughts if you want to do the physics on the server.

 

[soylomass]

I'm the dev of deeeep.io. I've moved most of the physics logic to the server (which is made with Java and uses gdx-box2d library for the physics, and Undertow for the websocket server). I send velocity, angle and position to the client and apply the velocity to the local object, and interpolate the angle and position when needed (to correct large differences).

It can be done better, but it works great if you don't have a latency bigger than 300ms.

I recommend that you don't use socket.io, but directly use js websockets. Socket.io has a bit of overhead.

[ForgeableSum]

13 minutes ago, soylomass said:

I'm the dev of deeeep.io. I've moved most of the physics logic to the server (which is made with Java and uses gdx-box2d library for the physics, and Undertow for the websocket server). I send velocity, angle and position to the client and apply the velocity to the local object, and interpolate the angle and position when needed (to correct large differences).

It can be done better, but it works great if you don't have a latency bigger than 300ms.

I recommend that you don't use socket.io, but directly use js websockets. Socket.io has a bit of overhead.

What are your reasons for not calculating physics client-side? Is it to save on performance or to make networking easier?

[soylomass]

29 minutes ago, feudalwars said:

What are your reasons for not calculating physics client-side? Is it to save on performance or to make networking easier?

I did at first, when the server was node.js and I could use p2 in both sides. But now, not only the server uses another physics engine and language, but there is a lot of logic that I programmed only in the server and not on the client, as the game became more complex.

Running the same physics on the client and server now became complicated, so I decided to use the clients mostly as windows to the server now (though I left the p2 collisions on, to make lag less visible).

[Skeptron]

Yeah, it's hard to keep physics on both side if you don't even have the same language. For our game we have JS on both ends, so we share the physics code : no need to rewrite it, you can test it client only, and both are sure to have the same outcomes.