[gameprogrammer] Re: Networking
- From: Jake Briggs <jakbri@xxxxxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Mon, 03 Jul 2006 10:16:37 +1200
1) I suppose things get out of sync. I can wait for opponent data each frame,
so the game blocks until this data arrives, but I suppose this would harm the
overall performance. But if I don't go for complete synchronisation, how can
I expect player collisions to be detected correctly and, most importantly, in
the same way on both machines?
I have thought a wee bit about this problem, I would take the approach
of "make it go correctly, then make it go nicely". To keep things simple
I would have the server do all the calculations, the clients would
simply do whatever the server told them to do - the clients are dumb.
Your client would tell the server that the user has hit the "turn left"
button, and forget it ever happened. The server would validate that
input (i.e. there isn't a wall in the way) then update the client with
its new position.
The obvious problem with this is lag. The action would be a bit jumpy,
or a lot jumpy depending on the ping :) I believe that on a local
network, you wouldn't notice the lag though. But that's basically the
"make it go correctly" part.
The "Make it go nicely" part basically consist of implementing some
client side prediction. The clients would re-implement some of the
functionality from the server, they would provisionally turn left upon a
"turn left" button event (validating the input the same way the server
would), tell the server that the "turn left" event occurred, then when
the server has validated the input and got back to the client with the
new position the client would respect that position rather than the one
it came up with itself. You may even be able to do some "smoothing" type
calculations - if the server's position is "close enough" to the
position the client calculated, don't update. This would introduce
compounding position errors, but I think you could get around those.
My thoughts on this matter are fairly immature - I have only done the
"make it go correctly" part irl :) I have formed this opinion from
basically playing online fps's and watching how they do things, and how
they do things differently from each other. For example, q3a seems to
play the "i fired a rocket" sound as soon as you hit the fire button,
but doesnt fire the rocket until its told it can by the server. UT seems
to hold of playing the "i fired a rocket" sound until the server tells
it it can. This example may not be correct but I think it illustrates my
point :)
There are other people on this mailing list who could give better
advice, and probably correct some assumptions I have made in my approach
- which would be cool :) There's probably some good documentation on the
net about this, it has to be a fairly well explored problem and we must
know some best practices by now :)
Jake
--
Jacob Briggs
Systems Engineer
Core Technology Limited
Level 1, NZX Centre
11 Cable Street
Wellington
Phone +64 4 801 2252
--
object doAnythingConceivable(string whatToDo, object whatToDoItWith) { .....
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
- References:
- [gameprogrammer] Networking
- From: Marian Schedenig
Other related posts:
- » [gameprogrammer] Networking
- » [gameprogrammer] Re: Networking
- » [gameprogrammer] Re: Networking
- » [gameprogrammer] Re: Networking
- » [gameprogrammer] Re: Networking
1) I suppose things get out of sync. I can wait for opponent data each frame, so the game blocks until this data arrives, but I suppose this would harm the overall performance. But if I don't go for complete synchronisation, how can I expect player collisions to be detected correctly and, most importantly, in the same way on both machines?
--------------------- To unsubscribe go to http://gameprogrammer.com/mailinglist.html
- [gameprogrammer] Networking
- From: Marian Schedenig