how do games talk???

[JPulham]

I'm trying to write an online FPS... could someone tell me if this looks kinda right or am I doing something horribly wrong?
heres a simple idea of my network:

Code: Select all

// client = c; server = s;
c: hello... can I play
s: yes, you are player number ###

s: add/remove player to lobby:
s: leave lobby... start game

loop
 c: I'm standing here *continues physics sim*
 s: wait... heres your new physics results:
 c: *snaps to new pos and interpolates other players*

 c: I'm dead
 s: new score, go here to spawn in 10 sec etc...

s: game over... heres the score
c: thanks bi.

How often do I send update packets... 10 times a second?
also, using newton how often do I update? I need deterministic physics for client side prediction.

thanks... JPulham

[buhatkj]

yeh im working on this sort of thing too. doing physics over the network is supposedly one of the more trickier things one might attempt.

the little bit I know is this:
-I've heard that most FPS games try to send 30 packets/sec to keep everything smooth.

-in some games, the client side doesnt run the physics simulation, the server does it, and the client only interpolates between packets, draws the scene, and sends input to the server. supposedly one of the reasons for this is to help prevent cheating as well as ensure the physics simulation plays out the same on all clients, regardless of hardware, cpu, OS, or other differences that might make it vary.
Of course, running the physics on clients reduces load on the server, which may then only be IO-bound and simply shoot packets around - so I've heard that some physics engines have a special solver which is written so as to ensure accurate and repeatable simulation results on all hardware/platforms. I think that's how cellfactor does it, since the physics are so intense.

[JPulham]

When reading up on client side prediction I read that the client does the physics and then discards the old simulation once the new packets from the server arrive. since the simulation should be pretty similar the client shouldn't have to 'snap to' too much.

how do you interpolate? I read about cubic splines on gamedev.net and that looks sound, or is it too much work for 30 updates/sec?

[omar shaaban]

well for heAVY 3D online games the physics simulation is done in the silent because
1-it is very hard to the server to send over 10 packets(for physics) to over 1000 players , it will slow him down and why
2- yes why u want the server to handle the physics!!? the cilent will do it.
or if u want to slow down the server a little bit
and for updates will basically there are 2 updates:
one(manually) when u walk,attack,enter a building....etc
and other (automatic "ex.each second") for updating the game (players postion,if one attacks him....etc)
easy huh!?

[Ico]

I'd do it this way: Client AND server do physics!

If it affects gameplay (look that pillar smashing a player ) the server will calculate/update the object and send the results to the players. If it's just for visual effects (glabber glibber splat, body parts everywhere) let the client handle it alone.

[JPulham]

OK... so ragdolls and player physics on the client, gun shots and objects on server... got it. Thanks... I'll try it and see.

[Klasker]

It is not entirely related to physics over networks, but I think you might find this article at gamasutra interesting. It is about how to efficiently send information to clients while avoiding lag and "warping" at the same time. It is well worth a read, even if it does not describe in detail how to implement the techniques. I remember warping was a big problem when I was playing Guild Wars (don't know if they fixed it yet).

About physics, I agree with Ico that the client should use physics to "guess" where an object is, in the time between the server's messages. Doing this right is not easy, but the link above might help.