I got my simple arcade game working via net now. It uses a client/server model. Everytime a key is pressed or unpressed on the client side the key state is sent via the net, server processes it and retransmits it to the other clients. That helps avoiding huge traffic loads. But now i got another problem... How do i defeat the network latency? I was thinking of a time sycnronization, but i don''t know how to implement it... Any ideas? Thanks in advance.

This is my system... I have no idea if it works since I've never made something to test it...

You have your system just like you said... the server retransmits control updates to each client.

However, the clients don't necessarily wait for all of the controls to come in before they update physics and draw the next frame.

All computers keep track of two full game states: one state is the last state where info was received for every participant (I call this the "known" state. the other state is the "current" state, which may be missing info from people with high latency.

In-between the two states is a info list that holds all of the "moves" (as I call them) for each player since the known state.

When a client sends or receives info, the packet contains the frame number for that info. On receive, a client inserts this into the move list and sorts it. The physics engine then calculates the new Current state based on the initial Known state and all of the moves in the Movelist. Whenever the earliest section of the move list contains entries for all players in one frame, that frame becomes the new Known frame.

This is the basic idea... I have never implemented this so I don't know specific pitfalls that it might contain. Anti-cheating stuff like the server testing to make sure that clients aren't sending turn packets intentionally out of order to fool the "prediction"... stuff like that.


What should happen is when a late player sends their control info, all of the other players who are ahead of them will see the late player's character jerk. If this gets too out of hand, have some way of slowing down the fast players' framerates.

[edited by - Nypyren on May 31, 2003 6:42:14 AM]

Well, what I do is have two systems, one ''local'' and one ''global''. The global state is maintained by the server, and is the ''God'' of the network game. Whatever the server says, goes. The local state is kept on each clients machine, and consists of the world around the player, and all the entities in it. The local state is updated just like a single player game, but the other players are retrieved solely from the server, and the ''local player'' is TESTED against the server. If for example, the player moves, you update the local state IMMEDIATELY, and run all the physics, etc etc. You then send this command to the server, who will then reply every second or so with "This is your position [#,#,#], velocity, etc RIGHT?" and if it isn''t, you''d better set them that way! Every time the server receives a command, it updates the global state, and every now and then, sends out ''lag packets'' to check if a player is staying updated. If a player''s local state is SO out of whack, the server sends the ''global'' state to that machine, and the machine ''jumps'' the new state. You can take this in a million different ways, such as prediction on the server, and ping testing to know how long to wait before you say "hey, here''s the way it SHOULD be. make it so!"

A system similar to this was implemented in Unreal 2003 (according to several UT2K3 technology sites) which reduces lag and bandwidth usage. For example, on my machine, I would connect to a dedicated server on another machine, and intentionally sabotage my connection, which doesn''t force the game to ''quit'' (if you do it right, that is) but merely to say "hey, the server''s got a hell of a lotta lag!" and you get to see all the prediction and lag reducing algorithms working. This is due to the fact that the game hasn''t received an update from the server in a LONG time and is trying to make up for it. When I do this, I can still move my character around all I want, and I can do everything except fire (the animation plays, just no bullets ), jump, or change weapons. I can see players moving like they were JUST before I ''disconnected'' even though no update has been received. It just shows you what the server handles and what it doesn''t eh? Good luck!

Chris Pergrossi
< ctoan >
My Realm

Hmm...
Let me explain... I don''t want packets to be transmitted every hard-set period of time... I only want packets to be sent when the user input state changes...
For example:
A client presses a key. The packet is sent to the server. And on the client side the object begins to move. The server receives a packet and retransmits it to other clients... And the begin to move the proper object. Each client continues moving the object untils the ''stop'' packet is received for that object. Then the first client unpresses the key... And the ''stop'' packet is sent to the server. The client stops moving the object. The server retransmits the packet to the others. And now we''ve got a desyncronized state. Because of the internet latency the clients could receive the ''stop'' packet on different time. So the object on different clients could move further than it actually did on the original client (the client that controls that object). And i want to know the basics of synchronizing such a system...

I cannot make my clients and server send packets every hard-set period of time, because it overloads bandwidth (that''s critical when the user has a dialup connection with his ISP)...

perhaps you could also send the time (gametick) in which the key event was received. But that would make it necessary to allow for the state to be rewound and recalculated when an event was received late... which would be pretty much all the time. One way to avoid that then, would be to have ''no event'' messages sent regularly, when nothing is happening, and the game state cannot progress until these are received.
I''ve thought about this sending events only strategy and I like it quite a bit but I think it''s only really feasible for non ''twitch'' games - i intend to make a RTS game using this kind of messaging.

Well, i don''t want to send not-necessary tcp packets, because every packet ''eats'' 40 butes of traffic... I wnat packets to be sent only when some event has occured. And I don''t know how to syncronize those ''time stamps'' between several computers (the clients and the server)