Physics in a Client-Server situation
Author
I've been designing a Client-Server game architecture and I've gotten almost everything down except for physics.
Now I was thinking that the physics can be simulated on all the clients themselves so they can keep a good smooth game going. At the same time the server needs to be simulating the physics for the entire game world (or at least the parts that the clients are currently in).
Depending on the size of the world itself this could potentially take up a lot of memory as all of the collision geometry (Terrains, Bounding boxes etc.) would need to be loaded in order for the server to get an accurate value for the current position and orientation of any game entity.
The idea being that a client could, at any time, request information on any entity and the server would need to be able to get the position and orientation of this entity and send it on.
If this entity happened to be a car mid barrel roll, for example, it would be very difficult to get this data without the server having simulated the stuff leading up to the barrel roll.
It just seems a but strange to have an entire, complex physical simulation happening when the only reason the results of it would be used is when a client ants to know where something is.
Sorry for the slightly convoluted description but I was wondering if you helpful chaps can help me find a way of allowing the server to keep track of all the entities in this way without having to constantly simulate the physics or, if that's not possible, how to keep the performance hit down to a minimum (In general terms).
Quote:It just seems a but strange to have an entire, complex physical simulation happening when the only reason the results of it would be used is when a client ants to know where something is.Why would this be the only reason to have the physical simulation? Surely it would be ideal to have your server enforce physics to prevent cheating. While I can't really offer much to your issue, I would recommend doing physical simulations on your server, otherwise it can be cheated.
In server clients, clients are usually merely terminals. They send commands to the server, the server handles the client commands and requests, and broadcast the game state to everyone concerned.
Doing physics on clients usually apply to trivial stuff that will not influence gameplay. For example, particles, ragdolls (see Counterstrike:Source and the ragdolls not being in sync), bottles, maybe glass panes, ect...
The important stuff is done server-side, and the client may run some prediction on their end, that will be overruled by the server updates (for example again CS:S, the barrels, the dropped weapons, bomb, and whatnot).
So in a server-client situation, the server does the simulation, as he is the authority on most things.
Doing physics on clients usually apply to trivial stuff that will not influence gameplay. For example, particles, ragdolls (see Counterstrike:Source and the ragdolls not being in sync), bottles, maybe glass panes, ect...
The important stuff is done server-side, and the client may run some prediction on their end, that will be overruled by the server updates (for example again CS:S, the barrels, the dropped weapons, bomb, and whatnot).
So in a server-client situation, the server does the simulation, as he is the authority on most things.
Author
Yeah I guess that makes sense, thanks for the tips. I suppose if I have the "world" split into sectors then I only need to simulate physics in sectors that the clients can directly interact with. Any thoughts on this?
You seem to already be grasping the core logic. You need to simulate anything that 'matters'. What exactly matters is up to the specifics of your game. If you can be sure that actions occuring in 'sectors' where no player currently is won't impact players, then of course you don't need to simulate it. Likewise you may not have to simulate it to the same detail on the server.
Suppose a car is going to explode, big fireball, lots of smoke, and bits of car go flying. You'd likely want to simulate the explosion concerning where the car itself moves (if the explosion moves it). You'd want to calculate on the server if any objects were close enough to be affected by the explosion and where those went. But lets say those flying bits of car do nothing, let's say they're just for effect and they just kinda fly off and don't affect anything even if they hit it, well now you don't need to simulate those on the server. The client can do a full simulation and they can bounce off stuff and come to rest somewhere, but the server won't care if it doesn't affect gameplay.
Suppose a car is going to explode, big fireball, lots of smoke, and bits of car go flying. You'd likely want to simulate the explosion concerning where the car itself moves (if the explosion moves it). You'd want to calculate on the server if any objects were close enough to be affected by the explosion and where those went. But lets say those flying bits of car do nothing, let's say they're just for effect and they just kinda fly off and don't affect anything even if they hit it, well now you don't need to simulate those on the server. The client can do a full simulation and they can bounce off stuff and come to rest somewhere, but the server won't care if it doesn't affect gameplay.
most common model to the hole physics conundrum is this.
"Why do the same math twice, and why do the same math for people who dont care"
the only thing the client needs to know is where something is, not how It got there. however at the same rate, the last thing the server needs to be doing is trying to figure out how something happened as well.
so a split system is not uncommon where the server just keeps track of where things are, and the clients decide where to put them, a parent child system usually pops up where this logic is taken on. simply put a player is married to the physics that effects his actions and his player. his client dose all HIS collision detection, while the server handles all world entity's. in other words the client broadcasts his position and his actions, while the server just keeps track, then when something happens that requires the attention of all clients involved (big explosions for example) the server handles the physics. again the idea is to avoid redundant math at the server level.
another approach is to leave all the physics to the clients, and the server just relays all the events, and lets the clients handle the math. this can cause bottle necks with items such as grenades and the like, as its no one systems entity to control however the server needs to be posted with its position and direction and what not, as such you have 5 clients sending the server redundant information, thus a parent child setup is some times adapted, but this is week to client side lag.
"Why do the same math twice, and why do the same math for people who dont care"
the only thing the client needs to know is where something is, not how It got there. however at the same rate, the last thing the server needs to be doing is trying to figure out how something happened as well.
so a split system is not uncommon where the server just keeps track of where things are, and the clients decide where to put them, a parent child system usually pops up where this logic is taken on. simply put a player is married to the physics that effects his actions and his player. his client dose all HIS collision detection, while the server handles all world entity's. in other words the client broadcasts his position and his actions, while the server just keeps track, then when something happens that requires the attention of all clients involved (big explosions for example) the server handles the physics. again the idea is to avoid redundant math at the server level.
another approach is to leave all the physics to the clients, and the server just relays all the events, and lets the clients handle the math. this can cause bottle necks with items such as grenades and the like, as its no one systems entity to control however the server needs to be posted with its position and direction and what not, as such you have 5 clients sending the server redundant information, thus a parent child setup is some times adapted, but this is week to client side lag.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
