🔒 Locked

Physics on Client/Server

Started by Dae Jan 11, 2009 at 7:13 PM 6 replies 2.6k views

Original Post

Jan 11, 2009 at 7:13 PM

This observation is always in the back of my mind when I'm playing a game. Exactly how much should the server hide from the client? Any changes to items or stats in online games are merely client-side (fake). What about coordinates though? Should the server control the players actions based on input (up, down, left, right, etc), calculate the physics based on the collision/terrain/players/forces around them, and then send the coordinates back to the player for rendering? It would seem to put a heavy load on the server since it basically has to run all the game math as well as network players (maybe a physics accelerator chip and custom programming would help). It would make sense why everyone suggests 2D before 3D since then calculations based on the map are simple. It seems to me the Source Engine does that. When I'm playing Zombie Panic: Source on a server, and it starts lagging, the NPCs, enemies, and environment all pause, and you lose control of your character. It looks similar to when your computer is lagging at 5 FPS, except you computer at 60 FPS. Some servers handle this better than others. For instance in some maps you can push a ton of barrels or boxes together and the physics collisions causes certain servers to lag more than others. Maybe this is fine for servers only hosting 1 game of 10-30 players, but not for MMOGs? One should also consider how the client character syncronizes after the server sends back the coords - if the server is slow then it won't look very smooth, and maybe the client should be allowed to calculate the physics and resyncronize when the server sends back the real coords? Should the server allow player computer's to do all the collision/terrain/forces etc. calculations and update the server of it's position? This is what I see in most MMORPGs today, like World of Warcraft, as well as older games (like Diablo) where you are allowed to alter your coordinates (x, y, z) and send back the packet. These are commercial games however, so they basically monitor for cheating, so you can't always exploit it too much or it wont let you or you get kicked or banned (check coordinate changes for jumps). Low budget MMORPGs on the other hand don't always check, and let people get away with supplying the server with fake information (coords). Both of which may or may not rely on their client also monitoring for cheating, which can almost always be bypassed. Should the server allow the players to update eachother on the code of honor? peer2peer (p2p). You see this in a lot of asain MMORPGs. I'm not a fan. You could of course have the client monitor for other players cheating and tell the server to warn him, so when that cheating player amounts a high value of warnings they are investigated and/or banned. This of course could be exploited as well by a player sending fake warnings. Warnings could be limited to 1 per account per day or something though. It sure would decrease load on the server, but at what sacrifice? I'm guessing when it comes to MMOGs, you don't really have a choice and have to get the client to do the hard work for the server, have it update the server, not the other way around (when it comes to 3D physics). Then monitor for cheating. Right? Thanks in advance.

Steadtler

102

Steadtler

Jan 11, 2009 at 7:44 PM

Well, there is a wide range of solutions, and any variations/mix between them. You have to choose for your particular game requirements. And then, I know of many game with the exact same requirements that use completely different solutions.

A solution you don't mention is to send only the inputs back and forth, have all clients perform the simulation, and the server only checks for any discrepancies between the clients. This both minimize the network load, and also prevent the player from cheating by changing its own state, (e.g,teleportation/speed cheats), since nothing except inputs travel between clients. However, its not something thats easy to achieve, and still allows, even facilitate cheats like see-through walls or auto-aim. Its always a compromise...

Hum, I just realized you can probably guess the multiplayer solution of a game by the hacks that work on it...

Dae

Author

Dae

Jan 12, 2009 at 12:44 AM

Quote:
Original post by Steadtler
Hum, I just realized you can probably guess the multiplayer solution of a game by the hacks that work on it...

Haha, this is true.

Quote:
Original post by Steadtler
A solution you don't mention is to send only the inputs back and forth, have all clients perform the simulation, and the server only checks for any discrepancies between the clients. This both minimize the network load, and also prevent the player from cheating by changing its own state, (e.g,teleportation/speed cheats), since nothing except inputs travel between clients. However, its not something thats easy to achieve, and still allows, even facilitate cheats like see-through walls or auto-aim. Its always a compromise...

That's an interesting method. Have you ever seen it implemented? It would allow multi-player design to be incredibly similar to single-player design since the client is processing everything itself (as if players were NPCs). Besides the difficulty in pulling off such a solution, I wonder how the server will be able to perform it's duties without calculating player coordinates or allowing player coordinate updates? It wouldn't be able to tell player a is in range of player b, nor would it be able to save the position of players for resumption later. -Unless- we aren't talking about MMOGs here, because that solution could work for temporarily created online games. (ie. Diablo and Counter-Strike - although in both I would prefer the server doing the calculations). The client would have to calculate the coordinates based on other player input for all players in the game even if they aren't nearby (incase they bump into them later). As soon as the players join they all start at the same point so it's synced. The only problem I forsee with that is if a player joins after it starts, how will it know the existing players coords? Either the server polls the players for them (cheats) or the players p2p the coords (cheats). Actually I can't see how it would work due to the client being able to change other players positions without the server knowing (unless there are more than 2 players and it relies on consistent information from all players - I take back my warning system idea).

Only seems to be one possible way in my eyes now. I wish the server could handle it all.

someboddy

Jan 12, 2009 at 3:58 AM

Quote:
Original post by Dae
Should the server control the players actions based on input (up, down, left, right, etc), calculate the physics based on the collision/terrain/players/forces around them, and then send the coordinates back to the player for rendering? It would seem to put a heavy load on the server since it basically has to run all the game math as well as network players (maybe a physics accelerator chip and custom programming would help). It would make sense why everyone suggests 2D before 3D since then calculations based on the map are simple.

That's just a BAD idea. There is a mmorpg named "LaTale" that uses that method. The tiniest lag can make it unplayable. I mean - you press the right arrow key, and only after 5 seconds your character moves!(and ofcourse it stops moving only 5 seconds after you release the key...). Jumping and fighting is impossible that way.

Surely if the movement is mouse controlled it will not be THAT bad, but it will still suck the fun out of it.

Dae

Author

Dae

Jan 12, 2009 at 4:24 AM

Quote:
Original post by someboddy
That's just a BAD idea. There is a mmorpg named "LaTale" that uses that method. The tiniest lag can make it unplayable. I mean - you press the right arrow key, and only after 5 seconds your character moves!(and ofcourse it stops moving only 5 seconds after you release the key...). Jumping and fighting is impossible that way.

Surely if the movement is mouse controlled it will not be THAT bad, but it will still suck the fun out of it.

Exactly my point. I wasn't suggesting a 2D MMOG using that method is even possible yet, but it shows a big difference between 2D and 3D in regards to server architecture. It's actually not a bad idea if the server can actually handle it. Which it cannot if it's an MMOG. If it's simple hosted games such as Diablo or Counter-strike then it can usually handle it. It works perfectly fine in those cases, and it's also the safest method with regards to cheats (given enough resources mostly cheat-proof).

Thanks for mentioning LaTale though. Up until now I was just guessing it was a bad idea for MMOGs.

For now it's best to stick with the tried and true MMO/MUD methods with cheat detection. If anyone has more information on these topics let me know please. I need a clear view of the MMO server method, the online RPG/RTS/FPS server method, and any variations.

FPS described by oliii:

Quote:
Original post by oliii
Prediction can work differently. What the client sends is pure inputs. So, if the fire button is up or down, or reload requested, that gets sent to the server along with the movement requests.

Then, the server takes those inputs and shoot bullets if he can, according to his information about the player ammo, weapon and state.

On the client side, you just predict what the server does. According to the client info about ammo, you play the firing anim, reload, ect... hoping that the server will match the moves.

At the next server updates, the client anims and ammo count are kept in check. Most of the time, the server and client will be in agreement.

There is a command in counterstrike to hide the client side prediction for weapon firing / reload (which is just a 'fake' animation to hide roundtrip lag lag).

And yeah, if the client input is lagged too much, make the server ignores them, correction packet will most likely be sent as the server and client will be then out of sync.

speciesUnknown

138

speciesUnknown

Jan 12, 2009 at 5:06 AM

You don't have to choose between doing it on the server and the client. The client can go ahead and do its own calculations, giving it a rough idea of what the world will look like. On each server step, the client is corrected in its assumptions, and objects are set to the states they are on the server.

Meanwhile, the server is doing the same thing. It gets a bunch of info about the character from the client, and ensures that they aren't using a speed hack or some other method of cheating.

Dae

Author

Dae

Jan 12, 2009 at 9:11 AM

Quote:
Original post by speciesUnknown
You don't have to choose between doing it on the server and the client. The client can go ahead and do its own calculations, giving it a rough idea of what the world will look like. On each server step, the client is corrected in its assumptions, and objects are set to the states they are on the server.

Meanwhile, the server is doing the same thing. It gets a bunch of info about the character from the client, and ensures that they aren't using a speed hack or some other method of cheating.

I'm going to be picky and say that's the same as choosing the client for the calculations because writing a game from scratch you do have a choice.

Steadtler

102

Steadtler

Jan 12, 2009 at 2:07 PM

Quote:
Original post by Dae

That's an interesting method. Have you ever seen it implemented?

Short answer, yes.

Quote:
Original post by Dae

The only problem I forsee with that is if a player joins after it starts, how will it know the existing players coords?

.

Yep, late joining is pretty difficult with this solution. It doesnt only have to know the existing player's coord, but the entire state of all clients but be exactly the same.

Quote:
Original post by someboddy
That's just a BAD idea.

.

One game choosing the wrong solution for its specification, and implementing it wrong on top of it doesnt means its not the right solution for some games.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.