BamBam, having the client do the calculations (without having the server verify the calculations) opens the door for packet hackers (stupid cheaters >=( ). the client will only send user input to the server such as key presses and mouse movement. so if i''m pressing the up arrow, it gets mapped to a move forward command which gets sent to the server. the server then moves the player forward at the speed that player can move.. not much you can hack there. and since i can pack all user input into a single DWORD using a bit vector this is also the cheapest solution for bandwidth.

Anon Mike, my game universe is set in space around a planet that i want to be accurately scaled about the size of a small moon, so shrinking the position vector probably isn''t advisable. i also require 6 degrees of freedom since the player is in a spaceship. the aim is independent of the ship direction, but only requires 4 degrees of freedom which means i can get rid of 2 bytes on the aimDir (around 2 axes, i think thats 4 DOF ) i can make the bodyRollAngle a WORD which would free up 2 more bytes....

soul808, that sounds like the best solution, update player movement on both the client and server at the maximum refresh rate and send out intermittent resync packets from the server. SWEET!

You will have to do client side stuff too, you can''t just send key strokes as the minimum 25ms latency will be very noticeable. I think the general approach is to have a consistent physics driven by the key strokes running on both client and server with the server being authoritive.

I dunno how you are planning to implement the actual data transfer, but Quake 3 has a really nice architecture for this that makes it pretty tough to hack too.

Basically he sends state snapshots, not as absolute values, but as deltas to a previous state. The sublety in Carmack''s approach is that he sends the state as a delta of the last acknowledged state from the client. So packet loss is irrelevent as the client can always unpack the delta since its based on one it acknowledged. The only disadvantage is that it can be slightly memory and bandwidth heavy. The plus side is that you don''t have to try and build you own reliable UDP layer (which he did in Q2 and says was a complete arse to debug)

The other plus is that you have to run an accurate state machine to be able to decode game state - hard for a hacker to screw with your client as a result. Especially as it needs to process data in both directions (to cope with the state acking etc.).

Anyway dunno if the technique is any use to you, but I don''t think I''ve ever seen it written up (one of Carmack''s friends asked him for some info on UDP when we were all having a big debate about it on another forum).

If you want a better write up I can try and find the original post as this was pretty brief (and badly explained).

Dan

here''s how i am doing my networking (or at least planning to), but it''s just a draft so it can change anytime.

this system is very similar to half-life''s. note that i''m only discussing player movement, nothing else such as firing weapons, reloading, etc.

also note that each packet is time-stamped. meaning that it contains the time when it was sent.

a client presses a key move up. every tick_time (which is 50 ms) it checks the state of the move up key. it''s down. so we indicate that in the state packet, and send it off to the server. we also log it in a local buffer for later self-movement prediction, as well as the current time (assuming the clock on the server and each client is in sync).

the server receives that packet some time later (depending on the latency). it understands that we were holding down the move up key, so it does all the necessary calculations and comes up w/ the new position for that player. it sends a packet to that client containing the current server time, the time this state update is from (it''s the time the packet from the client was sent), and the resulting position of the player. it also contains last known positions of other clients and their time (the time at which those positions were valid).

meanwhile, the client want to render the scene (i''ll only discuss his own-position prediction, not other clients). he knows that last world state update (what server send to clients - discussed above) is 0 ms (because it never got one yet. as soon as it will, it will update the clients position and the time that position would''ve been valid - the last_world_state_update time). right now it''s 14 ms. and we have one buffered user command - move up. the date of that command is, let''s say, 7 ms. that means it came AFTER last_world_state_update which is 0 ms, so we apply it. here''s some pseudo code.

start with last authoritative update the server sent to usfor ( each movement that is time stamped after the movement thatpreceded the state update ){    run the movement on the client and predict our new player    origin;}set the final origin as the render origin for this frame 

now i will talk about lost and our-of-order packets. what i have in mind right now is something like this. each packet is not only time-stamped, but it''s also numbered. so if a packet gets lots, we''ll know. if that happens, we wait for some period of time, hoping that it was an ooo (out of order) packet, meaning it will be here soon. if it does arrive, we apply it. as long as there aren''t any holes (like packets 1, 2, 3, 4, and 6 came: there''s a hole - packet 5), we can send world state updates to the client without a doubt. meanwhile, while we''re wairing for an ooo packet, the client predicts his own position using the logged key presses (or rather key states) w/o any warping. if we''re lucky, and ooo packets arrive and fill in the holes before a certain amount of time (right now i''d say it should be around 150 - 300 ms), we can safely send a correct world state update to the client. if everything goes correcly, there shouldn''t be any errors or differences (other than the errors in limited precision of floats, but that is so little it''s completely unnoticable), so to that client his own movement will appear very smooth w/o any warping (sudden "teleportations").

but what if we''re not lucky, and the packet never makes it? in that case we could either send a request for it, or if there''s enough bandwidth, we could always send each packet twice, or the last method, which so far we (our team, including me) think would be to average out the clients movement. that, of course, can only happen if there aren''t any big holes, or too many of them. which is why there''s another constant (which, atm, is 2), which indicates how many packets may be missing so that the "averaging" algorthim (will be described below) would be left enabled. what that is, is nothing more than just "averaging" our the missing packets. so if packet 5 didn''t come, but in packet 4 and 6 we were moving forward, we will assume that in packet 5 player was also moving forward. that way the maximum error will be the least possible, and since in our game player movement will be very smooth (ie. no sudden changes in directions, low accelerations, etc.), the warping the play may experience will be minimal.

i am kind of tired right now, so i might''ve said something wrong, or just didn''t explain it well, for which i ask your forgivness.

above goes for player movement, but we still have to figure out how to do weapon hit checks. the problem is that we have many "timed" weapons, meaning they will explode only after some time, allowing us to get the explosion sync on all clients and the server. that is very benificial, if used correctly. which is why i talked about it more thoroughly in this post, asking for your help/suggestions/comments/etc.

thanks for your time, i hope i''ve helped you, and maybe you''ll help me.

ps. sorry for a long post, i usually do that when i want to describe something well (and usually it turns out to be other way around)...

---
shurcool
wwdev

here's the post that the AP (aka Dan) was talking about
link

[edited by - Fragmo on July 16, 2002 9:31:48 PM]