Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

zppz

problems with key/mouse events as network messages

This topic is 5225 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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...
Advertisement
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]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!