Trust but Verify FPS multiplayer architecture

I'm a novice programmer. And I'm currently working on a multiplayer Arcanoid-like (Breakout-like) game. I stated with a non-authoritative networking, but when I started using rigidbodies I understood that physics simulation can be ran only on one computer. So I started digging towards the authoritative networking. I successfully implemented it, but without client side prediction, so there was a significant lag between input and response on client. And I started digging towards client side prediction and I've read this two articles: "Networked Physics" by Glenn Fiedler and "Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization" by Bernier, Yahn W (PDF).
And in the latter article i found an interesting info that military simulation systems usually work with peer-to-peer networking because they are a closed system and they trust all of the clients.

And I've got an idea. Why can't we do a mixed system, partly peer-to-peer and partly client server. Thats how I think it should work (for multiplayer FPS):

1. We've got a server. It runs all physics simulation and do all the math just like in client-server architecture.

2. We've got a client. It calculates movement and weapons-related code directly on the client and it sends to all other clients it's position and weapons related info. And it sends this info to server. But it also sends to server the client's input.

3. And server verify the client's calculation's about movement and weapons based on client's input. If client's position is correct server just sends to all clients "this client is fine". And the game goes on.

But what if client's calculations are not ok?

There are two cases:

1. Cheating. Client just walked through the wall or teleported 10 meters, Or it sent to all players on the level message "I just shot you all in the head with a single bullet". Well it's easy - we make it just a simple client like in authoritative client-server architecture. It no longer sends it's position and weapon-related stuff to all clients. It just sends it's input to server and server sends it's position to all clients. And now this client that cheated is in inferior position compared to other players. But who cares - he was cheating.

2. Incorrect calculation on client.

Movement:
If there is no cheating on client than this client can be wrong in movement calculation only in one case: if it bumps into another client. Well, what to do in this case? Which client should calculate the physics and which just receive the position? I don't know. For now I think that both clients that are too close to each other should switch to authoritative client-server architecture like in case of cheating but just for several seconds and not constantly.

Firing the weapons:
If there is no cheating than the only case when one of the clients can be wrong is situation when two players are opening fire on each other. Each sends a bullet. Each hits.
(Technically, if their weapons are not lasers each player should die. Contemporary rifles have muzzle velocity of 900 meters per second, so in 50 ms bullet will be in 45 meters from the muzzle. So both players can fire, and receive bullets and die.)
But as far as I know it's not how it's done in multiplayer games. At least one player should stay alive. So we just compare the timestamps on both network messages and we can see who fired first. And for matters of live and death I think clients need confirmation to start showing death animation. And they get this confirmation. From server.

So bottom line is if there is any conflict situation - server rules. And lag increases. But I'm playing CoD2:MW multiplayer now and I should tell that all those above mentioned potential conflict situations are pretty rare.

So what are pros: just one - lag reduced in half.
Cons: More traffic, the code will be more complex.

The basic idea is simple: Most people are honest. Not all are cheaters. So why should we think that all clients are cheaters. We can trust player. But still it's better to check. Like in Russian proverb "Trust but Verify".

 

stash,

My comments here aren't meant to dissuade you from working on this game. I'm a huge fan of multiplayer game development of all types!

With that said, I wanted to mention that you chose a difficult concept to successfully pull off in non-LAN environment. In my opinion (and based on tons of experience) it is an easier task to pull off a multiplayer first person shooter than it is multiplayer pong, from a pure multiplayer standpoint. In a FPS, or even a car racing game, your eye is willing to forgive tons of inaccurate movement, and you are willing to forgive a lot of overlap in where a bullet may go and what registers as a real "hit".

But in a simple game like pong (or breakout) your eye is expecting *perfect* collisions at high speeds. In a single player game that is not a problem because you can do collisions checks 50+ times / second. In multiplayer you run into trouble, as you've seen, due to lag.

It looks like you're approaching this game by running all physics on the server and treating the clients like dummies. Let the clients handle as much of the work as possible and then only use the server's calculations if an important event (like a collision) was calculated incorrectly on a client.

The server should stream the important events to the clients, and the clients will update the screen (and/or game model) if anything important is out of sync > than a minimal threshold.

The real problem that I see in a game like this is the twitch-control of the paddle. In a game like this reaction time is important. As one or more balls flies about the screen super fast you want to be able to sling your paddle into position at the last moment to have a ball bounce off of it. Let's assume some numbers here:

Your game is 800 pixels wide. The latency (1/2 the message round trip time) for both players is, say 80ms. Which means 160ms to get a message from one player to another. Let's say the human's reaction level is such that they can move the mouse (so, the paddle) across the entire game in 1/3 of a second. That means that if the player is moving the paddle around quickly, then by the time the *other* player receives this information the paddle could have moved up to another 40pixels. The paddle could very well be 40pixels wide, or thereabouts.

What I'm getting at is this. You can't really predict where your opponent's paddle will be, and he/she can move that thing super fast. The ball can move super fast as well. The end result is that you could see collisions wit pretty good accuracy in the brick area, and then with poor accuracy in the paddle area. If you played over a LAN it would likely look great. If you played over the Internet, results would vary tremendously. But in a game like and FPS, it is much easier to hide or correct for (while still being visually believable) the latency values.

Sorry for the long post. Again, I hope I don't talk you out of working on this thing. But I wanted to bring up the biggest issue from my viewpoint.

Final note: You mentioned peer to peer. That would certainly reduce the amount of time it takes a message to travel between the players. The smaller you can get that number for a game like this the better off you'll be!

 

Well this thread was about FPS multiplayer and I mentioned my game just to tell how I bumped over this idea.

But anyway. What I'm doing now with my game is I remaking the network code. I want to change the owner of the ball on the fly.
So I want to make the following.
Players are situated on two sides of the screen like in Pong. And bricks are between them.
Most of the time server owns the ball. But as soon as ball gets to area where client can reach the ball, I destroy the ball owned by server and create the ball owned by client. Probably there will be some lag at that moment but I will look into it when I get there.

 

stash,

Sorry if I miss-read your post. I inferred that you were using the commonly known FPS architecture but applying it to another type game. Re-reading your post I still got that sense.

In any case, I wish you luck with your game.

 

Thank you.

 

Do the articles you mentioned cover the FPS architecture of server only physics rendering? Essentially the character being controlled by the user is only on the server and the user is only seeing the environmental through a window rather than an environment built on the users machine receiving data from a server on sprite locations (other characters, projectiles, environmental damages, AOE effects, etc).

I'm fairly ignorant on the subject and I'm not sure if something like you mentioned is currently in play. However I wonder if what you're mentioning is something I've been curious about. I would think servers only receiving user input and then just sending back visual data would be far less intensive then a users local box being fed constant streams of data on sprite locations which would then need to be rendered (animations, results, etc.) and then the results sent back to the server. My thinking is probably backwards, but I would make sense to me that the server should be doing the work processing the data to make the game more fluid and fair. Those with low lag would just sit on field with the server rather than bouncing around the map as the server compensates for data coming from the users box. Then again a user with low lag could actually play because there would be less data needing to transmit between the user and the server, as long as it wasn't high jitter that the user was experiencing. Is this what you're talking about or something else?

Honestly I think these types of server management FPS would be they only way to handle hundreds of players at once. Maybe that's what WOW does? Again, sorry for my ignorance.

the only other thing I'm thinking that your saying is this: players character operates inside a box. Users actions are interpreted through that box back to the server and the server information back to the players box. The rest of the information (player positions, explosions, sprites, etc) aren't sent to the users machine but only the visual representation, no data is sent. The only time that data is sent to the user is if the server interprets other users data as intersecting with the users box. Does that make any sense or am I confusing the mater?