I need to make sure I have a solid understanding of a few pretty basic concepts, as they relate to the design of multi-player online games.  I've been reading all the websites and pdfs and etc. that I can find that describe the common practices of multi-player server/client design.  I really have to deconstruct things sometimes in order to understand them.

So, in an ideal situation where everybody can trust everybody and nobody ever cheats. 

Would it not be perfectly acceptable for every game client, in this perfectly aligned world, to be completely authoritative over their *physics simulation*?  Only sending data about their player character to the server and letting it rebroadcast that out to other clients?  The receiving clients would need to do some interpolation and whatnot with that data so it looked like fluid movement and didn't cause network players to teleport from lag/etc. 

Is there some big glaring technical or logical or etc. reason why the above would not be a functional approach, given the impossible circumstances of folks never cheating?  I feel like I'm missing something when I think about it like this, besides the hoards of cheaters and crooks.

I think, conceptually, and more or less actually this is pretty much how my system is going to work, and it appears to be working so far...  Only, I'm building a pretty big layer of cheat detection, player movement monitoring and policing/reconciliation on top of it, as well as working on a Hell-ban system for those that get detected cheating...

Please do point it out, if you can spot the light at the end of my naivete... 

If you want to prevent cheaters in this fashion then you need to keep everything important server side and broadcast to the client what the user needs to see. The client essentially acts as a TV for the player, and allows the player to send input commands to the server for 'requests', but any actual logic is done on the server side.

Anything client side can be ripped apart regardless of the anti cheat in place. Some anti cheat detection will make it harder than others, but it's not impossible by any means. This is why you see constant patches in certain games.

I've played plenty of server side games, and only encountered bots... You can do client side changes in memory, such as change stats, items, ect... but it wont register on the server side so even if you set 10000 HP client side, if the server never trusts the client but verifies, the player will have the normal HP regardless of what they do client side.

Bottom line, never trust the client. Send requests to the server and relay the appropriate information back.

2 minutes ago, Rutin said:

Bottom line, never trust the client. Send requests to the server and relay the appropriate information back. 

Indeed, and that's still what I'm doing.  I'm talking purely about the physics simulation.  The client being authoritative for THAT only.

I edited the OP to reflect the distinction I missed making.

If you've got two players driving virtual physics vehicles in game, but 500ms apart from each other in the real world... And they collide with each other... how are vehicle collisions resolved?

Firstly, if they're travelling at a fairly normal vehicle speed of 100kmh, then during a round-trip, they travel ~28m. That's a large enough distance that they probably can't agree on exactly where the collision occurred, and they might not even agree that a collision occurred at all!

You can let each client resolves collisions themselves, without moving the other player's vehicle at all. But then if two clients disagree on whether a collision occurred, you might get rammed off the track by someone who's overtaking you, while they keep driving without penalty (no collision at all on their side)... and you'll feel cheated.
Worse, both players might resolve their own collisions in such a way that another round trip of communication, they're still colliding in a different way now, and end up in a situation where conservation of energy is violated as collision resolution keeps adding forces to the system...

You can set up arbitration rules -- e.g. in a collision, the client who is further along the race track has authority to resolve collisions. But in that same hypothetical situation, the overtaking client (who disagrees that a collision occurred) will suddenly get a large physics force applied as a result of a collision that they didn't see happen... And they'll feel cheated.
In some sports games you'll see systems like this where the client who's team is currently (or was most recently) holding the sports-ball is the arbitrator for interactions.

On a slower scale, e.g. characters who walk around a world, the exact same issues apply. The jankiness is just exaggerated and more obvious in the race car example

And then once people hack clients to actually cheat on purpose... well...

2 minutes ago, Hodgman said:

If you've got two players driving virtual physics vehicles in game, but 500ms apart from each other in the real world... And they collide with each other... how are vehicle collisions resolved?

The same way they would be in a central physics simulation.  By the data that is available.  What is a physics simulation but a bunch of data acted on by some mathematical formula?

A standard setup will generate a physics simulation on the server and allow other systems to interact with/view that simulation.  Telling those who misbehave that they are misbehaving and that there will be consequences.. however they choose to implement them.

My setup will use a real-time data reconstruction on the server to determine who is cheating and who is somehow moving too fast or otherwise behaving inconsistently.  The servers can still order the client to do stuff.  The servers still get to decide what and who to rebroadcast, and to whom.  The ONLY thing I'm trying to omit from my server logic/control is the actual calculation of physics forces. 

If my real-time data is half-as-realtime as anybody elses then I don't see why it couldn't be feasible to make corrections to misaligned clients in the same latency window as a system running a physics simulation locally.  Am I completely daft for thinking this?

Maybe I am, maybe it isn't possible for anything approaching fast action..  I dunno, I guess that's why I keep asking strange questions like this.

2 hours ago, Septopus said:

The same way they would be in a central physics simulation.

My point was that a central server can perform Physics(State of A, State of B), while if each client is an authority over different parts of the simulation, they can only perform Physics(State of A, Estimated state of B). In many genres, those are two very different things.

2 hours ago, Septopus said:

who is somehow moving too fast or otherwise behaving inconsistently

The point of the vehicle example was to highlight that consistency is impossible when objects under two different authorities interact. In a real-time racing game, it's typically not possible to define what is and is not a consistent / expected outcome of the two vehicles bumping each other... because Physics(A, ~B) != Physics(~A, B).

For what you're trying to do, you probably just don't want to have real physics at all, and instead rely on a lot more state-machine / animation / deterministic methods of player interaction.

Yeah, I get ya.. I'm pretty much sol..

Back to the drawing board.....

Wait... what?  Not have physics at all.... hmm???

Well, I guess that may be the only way this stays out of the scrap-heap at this point...

I'll see if I can kill the physics and still make half of the game I intended.

Thanks for the input.

There's always a lot of solutions, but they differ greatly depending on what genre / what kind of game you're making.

For example, in an RTS game, it might be completely valid to have a built-in 500ms delay between a user giving a command, and units acting on that command. In the 56k modem days, this restriction allowed devs to put any number of units of the battlefield without requiring any network bandwidth to support them -- instead, you make the entire gameplay simulation deterministic, and the networking layer's job becomes to get all players to exchange commands and agree on the commands to be injected into the simulation on the next "turn". Even though it's a real-time simulation, the fact that user inputs were only injected once every X (milli)seconds lets all clients agree on what will happen next, and then make those changes simultaneously. As long as the simulation is deterministic, all clients stay in sync without ever actually transmitting any simulation data.

Or in the racing example that I gave, you can set arbitration rules. For example, when two players collide, the player who's winning the race acts as the master authority to dictate what the definition of a consistent crash outcome actually is. Or, you just disable player<->player collisions and let people drive through each other!  

The correct network architecture can only really be decided on with input from both the network-programming staff and the game design staff.

I'm guessing you probably haven't poked around on my blog and checked out what I've been trying to make.  

LOL you're funny... Staff... I sleep in a tent and work out of my buddy's extra unheated garage space, no joke.

I am ALL the staff my friend... And my communication skills are tenuous at best, if you haven't gleaned that much thus far.

Pretty much every bit of physical movement I have in game is at least partially dependent on physics right now....

I think there's a slight chance I can replace most of that with some more deterministic movement code, but it's going to be an ugly path getting there and I don't know if it will even work, or look right if I do....

Again, thanks for the info, I really do appreciate it.