Server Collisions

I'm designing an authoritative server at the moment and I'm trying to figure out how to correctly move the a player around on the client. At the moment I've got the client sending key presses to the server, and the server processes that then applies the players movement speed to their position to get the approximate new location, this also happens on the client. The server will then occasionally compare the two positions to see if they're approximately the same (if the client is using a speed hack then the positions will be vastly different). However I'm not sure how to get around collisions on the client since the server is command line based, say if the player walks into the side of a building and keeps trying to move forward they'll be continually sending commands saying they're holding down the forward key, so the server will keep applying the movement.

I could compare the players location every so often to check if they haven't moved very far and detect the collision that way, but then I run into the issue of players editing the levels (which I'm sure they'd be capable of) and removing the collisions of objects, then being able to run through buildings which the server would be fine with since it doesn't know it's there. Another way I could solve this would be to periodically send a check to each client and make sure that all the objects haven't been tampered with (checking to see if all the buildings still have colliders and that those colliders are enabled, the correct size etc.).

I was just curious if there was a best practice for correctly detecting this sort of thing.

 

Command Line based?
Is this a FPS/RPG? If so, you'll probably want to run the map on server and client, so both have the same colliders. If the server is authoritative, then what it says is accurate. It should probably be regularly distributing positions of things to all clients that need to know about those things.

 

Yes, command line based so the server has absolutely no graphical constraints, it can focus entirely on receiving and distributing data. It'd be for an RPG. Hmm, I don't really want to be locked into needing a graphical display to run the server, although it could be handy being able to store nearby players by simply having a sphere collider around them, I'll look into it.

 

The server doesn't nead a graphical display. It runs a unity instance headless with no graphics. Use the command line options -batchmode and -nographics.

Unity already has all the physics routines, and terrain - makes sense to run the same thing as client and server.

 

Y'know, I've seen those commands mentioned so many times and never thought anything of them, thanks for bringing them to my attention again I'll try it out.

 

That's what I use. It just makes so much sense to have the same workings on client and server. I can use the same scene and terrain in an assetbundle, and instantiate it on client and server. On the server, I remove all Renderers, so only the colliders are left - but other than that, it makes things a breeze.

 

Mm, it really does, just out of curiosity what do you do in the case of multiple different scenes? Like if you have say, dungeons.

 

I have one server per scene (game zone). When the player moves to a new zone, the client disconnects from the one server, and connects to the new server. The number of players in the world is a limiting factor, so having the world split into zones means it's possible to have more players in the world.

 

So then you'd need to have multiple computers/virtual machines to make up one 'realm', greater cost for additional performance. Well thanks for the information, you've given me a bit to think about.

 

I only have a single rented server, and can run a whole realm from that, but for more intense and populous realms you could easily split that into onto more physical machines

 

Don't you have issues with figuring out which data is meant to go where if they're all using the same IP, unless you have a master server directing all the traffic... which you probably do.

 

Each zone-server is on a different port - so that makes it easy. I have a list of address and port for each zone-server, so the master server can tell the client where and what to connect to.

 

Oh of course, servers can listen on different ports, right, well I may have to use that idea and I see what you mean by easily split it, just set the addresses in the master server to what they need to be, very nice.