How is server-side collisions done?

Wouldn't you need to have a separate game running on the server to do this? You couldn't rely upon client side collisions because that would easily allow them to hack files and go wherever they wanted to, collision-free. Would this be done by having the server-side game have all the geometry, receive clients' requested player position, see if it's valid server-side, send back okay/not okay back to client?

No. The server would be running the same game. :wink:

Exactly like you said. Client might find a way to hack collision checks and they’re ignored on the client side. Client informs server about his current position (and velocity etc) all the time and the server applies that to his simulation. Client cannot do anything to allow him to clip through walls on the server side. If client and server position or velocity differ by a configurable threshold, the server tells the client where it is supposed to be, and the client obeys that. Or might even get kicked. Though that is very difficult because it could have simply been an issue of lag, packet loss or packets arriving out of order.

If the client doesn’t obey the position reset because that is hacked too, the client may still clip through everything, but the client won’t be able to use that to get behind the enemy team’s back because on the server side, any interaction of that player happens where the player is on the server, and that client might even die because of running defenseless into walls.

However, you cannot prevent the client from clipping through walls in order to “see” more of the map, possibly even enemy player positions, unless you extend that system to provide even more security, such as not updating enemy players that the client cannot see. Not sure if that is a thing, probably isn’t.

What I mean about having a separate game is that it seems more practical to have a version of the game to where it runs one instance of say, a dungeon, and all clients use it. You only need one geometry of a dungeon to have hundreds of players running around on it server-side for the sake of checking collisions. On the client’s end, they don’t see all the extra players. They only see the ones they are grouped with for their dungeon instance. So… same geometry, different version of game. You couldn’t possibly run an exe of the game for every player that is connected to the server, right?

How does running the game client on the server work? Can you rent a server like havoc or AWS, run the game on there, and see the screen through streaming? I’ve gotten simple web hosting before, but there was never an option to run exe’s on it.

I see “dedicated” servers with “root access” being advertised. Does root access essentially mean you’re able to run the exe of the game on there?

Thanks for the info. I’m full of questions about this because I’ve only just recently considered making a multiplayer game.

That’s not how this works. You can build a dedicated server from your project and Unity just doesn’t draw anything in it if you do that. Check the manual.

For controlling visibility, that’s in Netcode and probably any decent networking lib.

You get the option to run executables on a web server only if you rent at least a virtual server, or a dedicated server. Those usually run Linux but you can also get Windows server for extra cash. And yes, a dedicated server build is what you would have running on your self-hosted web server and that’s what you need root access for. If you haven’t done server hosting before I wouldn’t recommend it unless you like to learn the ins and outs and spend a significant time on it.

Alternative is to use Unity Gaming Services, Photon, or others.

I didn't know Unity could do that. Thanks for the information. I'm going to try to watch some YT videos on it next to learn more about it. Really just wanted to get pointed in the right direction quickly and I think I know where I want to go now.


In best case, clients only send input, not any state. The benefit of running a host/server is that clients don't need any authority of the game state. They can locally predict movement (which is overwritten by the server's correct updates) so it looks smooth.
Instead of running dedicated servers, a player can act as server (in the same process usually), which is then usually called a "host".