Apart from some initial handshaking routines, my network messages consist only of low-level user input events ie. mouse button up/down at (x,y), key ''a'' up/down etc. These events are sent to the server which just bounces them with a timestamp to all players. Each client simply takes these events from the server and feeds them to the game object, which doesn''t care whether they are coming from the local player or somewhere else. I like this because it''s very simple to make and abstracts the networking so much that fitting in a whole different game is easy. I''ve got this much working fine, but the issue obviously is response time. I read this article especially noting where it says that they kept two copies of the game state to hide the time lag between input and (official) response. One copy of the game is updated immediately upon user input and used for rendering, and the other is kept in line with the the state dictated by the server. When these copies get out of whack the official copy is used to reset the other. So far so good, I decided to try that idea. However since then I''ve realised that they were probably sending higher level messages about player actions ie. player accelerates to speed x, player faces angle xyz. I want to make an RTS with this system, but one problem I can foresee is that someone clicks on a moving unit to select it, and it appears as selected on the players screen immediately. The click message gets back from the server slightly later, and the official click will not select that unit because it has moved. The official game state will override the rendered state and the unit will be unselected (after being selected for a brief moment!). I don''t think this problem will go away even if I use a lockstep style simulation together with scheduling events in the future like this article describes... does anyone send low-level events like this or is it just a dumb idea...

Sending such low level input data isn't a good idea.
If you select unit A, you don't send over "user clicked on screen position X/Y" (where your client displays the unit), but "user selected unit A".
If you want to send it to poistion P, don't send "user clicked to position P" but "move (selected unit) to position P".
To attack, send "attack unit B with (selected unit)".
(Here you can let the server care for what unit you have selected, or even tell the server what concrete unit you want to move/attack by using the information on the client about what unit was selected, resulting in "attack unit B with unit A")
By already interpreting the users input clientside it will also become easier to support different screen sizes, window positions etc.
The client deals with the interpretation, sends the interpreted commands to the server. This way you have no problem with timing (and units can't move away from under your mouse pointer).

[edited by - OmniBrain on June 3, 2004 3:28:09 AM]