Hi, I'm working on an arcade racer (with a rollcagesque feel) and was wondering if anyone could advise me on the interraction between the physics engine (I'm using novodex) and the network. High-velocity collisions tend to be rather chaostic in result, being 20cm to the left can mean you end up having moved hundreds of metres in the opposite direction. Now from what I can gather modern games tend to run the physics simulation on the client and the server, and then do some kind of interpolation to get things "back on track". How have race game designers dealt with the huge errors that can be introduced in the past?? I was thinking about moving towards a more "client is always right" model, but I think that might mean the server would keep having to do go back to past simulation states. (The server's internal monologue would go something like this: "Client 1 says they were in state X, t seconds ago, client 2 just told me they were in state Y, s seconds ago, and client 3 wants to know what 1 and 2 are up to. So I'll go back to how I though the world was t seconds ago, but set client 1s state to X, I'll then simulate the passing of t-s seconds and set client 2's state in the result to be Y, I'll then simulate for a further s+how much time i've spent simulating alreading, and tell client 3 client 1 and 2's state in the result." which would be quite slow...) Any suggestions would be much appreciated. Thanks, Tom

Most of the problems with arcade games online is the latency with the controls. YOu want the car / player to control instantenously, and at the same time, keep in sync with the server copy.

The rest, you can't do much about it. It's just sending entity states to all players, and have the client dumbly render them (although nothing prevents you to perform collision checks just to make sure stuff doesn't clip).

The usual process is as follow.

client :
- You take inputs from the controllers.
- you perform physics calc based on controller inputs and calculate new car / player position localy, and add that with the inputs into a command packet.
- you send a bunch of command packets to the server (say, at 20 fps, you don't want to send packets every frames).

server:
- you receive a command packet.
- you calculate the position of the player using the command packet inputs.
- you check if the position calculated in the command packet matches up with our position.
- if not, you send a correction message back to the player.

player:
- you receive a correction packet.
- put player to corrected position.


the player on screen will then jolt back to a corrected position.
this happens in the case of CS when you hit another player, or some bits of scenery that has been disturbed.
Hence the crappy barrels in CS:S and crappy player-player collision. It's OK as this doesn't happen too often, or should not.

Most of the time, there is no need to send corrections, and your player will move smoothly, even under heavy latencies. We have a system like that implemented, and the game is playable up to 200 ms (and even more apparently). We only update at 10 / 15 fps, and do a client-side prediction for weapons, with server authentications.

This is just an approximation of the process. There is also interpolation / extrapolation, redundancies in command packet to solve packet loss problems, ...

That and a delta compression, and that should get you sorted.

All the rest for entity updates is nothing more than spewing out entity states to clients from the server, and interpolating them on the client for rendering (and possibly adding collision check to avoid clipping through interpolations).

My worry was that if I'm using a physics engine, to do the server side step

Quote:

Original post by oliii - you calculate the position of the player using the command packet inputs.

I would have to send the physics engine "back in time", so that it is calculating based upon the state of the game at which point you actually pressed the button. (So say you're driving fast up to a hard right turn and you do a handbreak turn, in the server's simulation you might have already crashed into the wall, thus the server has to go back in time to the point at which your command packet says you hit break and right, and then restart using the info that you did hit these buttons.

Are you saying that the standard way of doing it is for you not to start turning "in reality" until your command packet hits the server, although you will have appeared to have started turning prior to this?

Thanks,

Tom

for FPS and our purpose, the server entity effectively stop until the next command packet is received. The server merely checks for the validity of the position, and send the latest calculated position to the other clients, that will extrapolate.

In UT, quake and CS, you can see that happening when a player crash and his entity on the server hang in mid air. The server stopped receiving comamnds form the client, and the entity is in a lock-step, waiting for more commands, and it is not updated until then.

That works OK for FPS, but yeah, car driving games require more sensitive and continuous physics.

There was an article/demo/stuff by one of the member of these boards, about network physics. Can't remember his alias, but it's a very popular article. Worth checking it out.

Also have you considered Peer To Peer? calcualte the car position solely on the client machine, and broadcast it's latest position to all other players.

You'd have to be careful if you have lots of destructible scenery, like in Flatout. The problem is who's taking control of say, a barrel when it starts rolling. Then the clients get out of sync on the barrel position. A bit like the ragdolls in CSS that get out of sync on clients. But that's OK since ragdolls do not interract with the players or other objects. They are just for show.

Probably not a good idea, unles your game is very simple.

Actually, I should know how Rollcage worked, I joined ATD when Rollcage II was into the final stages (a long time ago). Unfortunately, I didn't have a look at the net code [grin] I'll ask my ATD chums, we have a place where we all hang out. ;)

I'll check out that network physics article, sounds like it'd be useful.

Thanks loads for all your help.

Tom

P.S. I send my eternal veneration to you and your ATD chums. I'm still playing Rollcage I now, nothing's beaten it as far as I'm concerned... (^_^)

Quote:

Original post by seaephpea I'm working on an arcade racer (with a rollcagesque feel) and was wondering if anyone could advise me on the interraction between the physics engine (I'm using novodex) and the network.

What caught my eye about this and raised a question for me is the 'arcade' statement. If it is truely supposed to be an arcade game, then wouldn't peer to peer be faster and more robust because you usually have linked system of up to eight peers. I think adding a server into the mix would slow things down.

In the peer to peer, each entity could send out it's info using a Multicast (since you're in an arcade, the messaging and transport could be a closed LAN environemtn and multicasting would work perfectly) and if the car was in another peer physical view, the receiving peer could hab\ndle the rendering and physics, otherwise if the other peers could not 'see' the car they would ignore the request for rendering and physics processing.

Just a quick idea off the top of my pointy head and it fully relates to if the game is truely an arcade game.

-- Eric 'Wackatronic' Tomlinson

I meant arcade as in "fast, fun and other-worldly" rather than arcade as in arcade I'm afraid. My life would certainly be a lot easier if I could assume all connections were 1 metre gigabit LAN links...

Tom

Quote:

Original post by wackatronic What caught my eye about this and raised a question for me is the 'arcade' statement. If it is truely supposed to be an arcade game, then wouldn't peer to peer be faster and more robust because you usually have linked system of up to eight peers. I think adding a server into the mix would slow things down. In the peer to peer, each entity could send out it's info using a Multicast (since you're in an arcade, the messaging and transport could be a closed LAN environemtn and multicasting would work perfectly) and if the car was in another peer physical view, the receiving peer could hab\ndle the rendering and physics, otherwise if the other peers could not 'see' the car they would ignore the request for rendering and physics processing. Just a quick idea off the top of my pointy head and it fully relates to if the game is truely an arcade game. -- Eric 'Wackatronic' Tomlinson

That's fine, but as I said, what to do with entities other than the cars themselves? If you smash into a building and that thing crumble, who will update the bits' positions? Each client are bound to diverge pretty quickly, and if you are not careful, you'll see cars going through things or colliding with an invisible object (as the object on your machine could a few meters away from the object on his machine).

Quote:

Original post by oliii That's fine, but as I said, what to do with entities other than the cars themselves? If you smash into a building and that thing crumble, who will update the bits' positions? Each client are bound to diverge pretty quickly, and if you are not careful, you'll see cars going through things or colliding with an invisible object (as the object on your machine could a few meters away from the object on his machine).

This is a world change and would be broadcast to all peers.

Using the scenario you listed, Each piece of the building crumbling off would become it's own object that would update it position to all peers, who would determine if they were near and could see it. Your collision code should take care of the actual "collision" with the new "piece" object. The processing would not be slowed down very much at all, but this relates to the arcade thing and not a distributed Internet game. That's a totally different ball of wax with predictive paths and lagging issues.

-- Eric 'Wackatronic' Tomlinson

Quote:

Original post by wackatronic Quote: Original post by oliii That's fine, but as I said, what to do with entities other than the cars themselves? If you smash into a building and that thing crumble, who will update the bits' positions? Each client are bound to diverge pretty quickly, and if you are not careful, you'll see cars going through things or colliding with an invisible object (as the object on your machine could a few meters away from the object on his machine). This is a world change and would be broadcast to all peers. Using the scenario you listed, Each piece of the building crumbling off would become it's own object that would update it position to all peers, who would determine if they were near and could see it. Your collision code should take care of the actual "collision" with the new "piece" object. The processing would not be slowed down very much at all, but this relates to the arcade thing and not a distributed Internet game. That's a totally different ball of wax with predictive paths and lagging issues. -- Eric 'Wackatronic' Tomlinson

But the object would be generated from where? All the machines? Which machine broadcasts the object's position? How do you keep all the machines in sync for that object?