Edited by - barazor on September 25, 2001 10:47:30 PM
network examples?
Author
ok let me start by saying that im not new to network programming, i have a few years of socket experience under my belt, just not with games, and ive been picking through some quakeforge source code, which is pretty confusing stuff
what i am sorta looking for is some sample code that interprets movement for a player onscreen, and how it is used....
now, what i need is some input on how to send this info to the server. Right now, i have my code send a message(sort of an example):
<movement msg id> <player id> <x coords> <y coords> <z
coords> <pitch> <yaw>....
is this an efficient way to do this? or should i do it differently? id appreciate some input on my idea
Edited by - barazor on September 25, 2001 10:47:30 PM
Edited by - barazor on September 25, 2001 10:47:30 PM
What I tend to do and what I believe a lot of games do, such as Quake and Serious Sam, is to use "Virtual Actions" that is to send action instructions from the client to the server. In effect remote controlling the character. For example, in the simplest form you could send key states, key-up = run forward, key-down = run back. You could send actions such as stand, crawl, run... This will reduce the traffic on the network.
You then have to decide how the information will be reflected back between the server and the client. Until now I have just been sending absolute sync data in-frequently with some deltas in between (I didn''t have much choice about this approach and its not one I particuarly like).
But I believe that a more common and probably better approach is for the server to send back an action acknowldgement. Telling the client that there action has been acknowldged and accepted as valid.
I hope this will help a bit.
Perhaps someone with more experience can list the alternative methods along with the pros-n-cons.
You then have to decide how the information will be reflected back between the server and the client. Until now I have just been sending absolute sync data in-frequently with some deltas in between (I didn''t have much choice about this approach and its not one I particuarly like).
But I believe that a more common and probably better approach is for the server to send back an action acknowldgement. Telling the client that there action has been acknowldged and accepted as valid.
I hope this will help a bit.
Perhaps someone with more experience can list the alternative methods along with the pros-n-cons.
Hmm, what about doing the same as you mentioned above, but that the server sends an packet pack with the player''s absolute position, like an acknowledgement... all players can know this way what the absolute position is of the player.
I haven''t used this method... I''m using absolute coords for my game.
I haven''t used this method... I''m using absolute coords for my game.
Pritty much what I said, you send from server to client the absolute position syncronisation data. Ie coords and rotations.
The main disavatage of this method is much higher bandwidth usage. The effects of latency is very apparent too, not to mention problems on the server (momentory stalls).
One advantage is that it becomes harder to hack the message stream, because the server dictates the positioning not the client. It also means that the clients have deffinate status information for the characters.
I am usuing this method at the moment and honestly although it seems to be working for the time being (problems sooner or later start showing up). I still feel that there are much better ways of doing it.
Ajoling, could you perhaps give us a better descripton of how your method works?
With my current system -
Clients sends very small "Action request/key stroke" messages to the server. Remote controlling their character on the server.
Server broadcasts to all, including the originating client the absolute status information for their character. The message includes the likes of, position, rotation, action state (croutching, standing, running, scratching arse).
Like I say, it''s not without it''s problems.
Any suggestions here?
The main disavatage of this method is much higher bandwidth usage. The effects of latency is very apparent too, not to mention problems on the server (momentory stalls).
One advantage is that it becomes harder to hack the message stream, because the server dictates the positioning not the client. It also means that the clients have deffinate status information for the characters.
I am usuing this method at the moment and honestly although it seems to be working for the time being (problems sooner or later start showing up). I still feel that there are much better ways of doing it.
Ajoling, could you perhaps give us a better descripton of how your method works?
With my current system -
Clients sends very small "Action request/key stroke" messages to the server. Remote controlling their character on the server.
Server broadcasts to all, including the originating client the absolute status information for their character. The message includes the likes of, position, rotation, action state (croutching, standing, running, scratching arse).
Like I say, it''s not without it''s problems.
Any suggestions here?
For my game, which is based on Subspace/Netrek/Asteroids (pick one! ) I have the client''s time synchronised with the server "GetTickCount". This certainly made my live easier (See ddn''s post in Network synchronising topic from this week).
Because I can simply let the player sent his position + timestamp.
So the following happens:
A) Client1 sends his position, angle, velocity, timestamp:100.
B) Server receives packet. And forwards it (some post-processing done...secret)
C) Client2 receives packet. Servertime: 300. Packet has been underway for (300-100) = 200ms, so the position has to be increased like:
NewPosition = ReceivedPosition + timedifference * Receivedvelocity (and including the angle...sin/cos for my game)
This works perfectly. So far the only problem I''ve seen where my code really messed up was with a player that had 1second ping, and 40% packet loss. But I''ve still got to find an real time game that still works under this ''packet hell''
) I have the client''s time synchronised with the server "GetTickCount". This certainly made my live easier (See ddn''s post in Network synchronising topic from this week).Because I can simply let the player sent his position + timestamp.
So the following happens:
A) Client1 sends his position, angle, velocity, timestamp:100.
B) Server receives packet. And forwards it (some post-processing done...secret
)C) Client2 receives packet. Servertime: 300. Packet has been underway for (300-100) = 200ms, so the position has to be increased like:
NewPosition = ReceivedPosition + timedifference * Receivedvelocity (and including the angle...sin/cos for my game)
This works perfectly. So far the only problem I''ve seen where my code really messed up was with a player that had 1second ping, and 40% packet loss. But I''ve still got to find an real time game that still works under this ''packet hell''
Impressive ajoling and your right - certainly no RTS game I know of can withstand a 1second delay and 40% packet loss.
8^) ya got me 8^)
Hey ajoling, you might want to try something like this out. To prevent cheating i don''t allow the client any authoritive abilitites, so the full control loop has to be traversed for every event. That is the event from client -> server -> client, which is usually the ping of the client + transactional latency overhead. However some events can be prempted on the client side without any authoritive change to the game. One of these events is the movement events. So to prempt the event and cut down on the latency, I execute the event on the client side after 1/2 ping of client. This effectivly reduces the perceptable movement lag by 1/2 but has no authoritive change upon the game state, since if we mispredicited a new movement event corrects the game state soon after, if we did predict correctly the new event just reinforces the current state.
Good Luck!
-ddn
Hey ajoling, you might want to try something like this out. To prevent cheating i don''t allow the client any authoritive abilitites, so the full control loop has to be traversed for every event. That is the event from client -> server -> client, which is usually the ping of the client + transactional latency overhead. However some events can be prempted on the client side without any authoritive change to the game. One of these events is the movement events. So to prempt the event and cut down on the latency, I execute the event on the client side after 1/2 ping of client. This effectivly reduces the perceptable movement lag by 1/2 but has no authoritive change upon the game state, since if we mispredicited a new movement event corrects the game state soon after, if we did predict correctly the new event just reinforces the current state.
Good Luck!
-ddn
That''s certainly interesting, but I''m not sure how it would work out for my game though... it''s in space with some physics. Although I might try it this week, after I''ve finished the user database.
btw, a bit offtopic, has Ironsquad become popular?, ie: are there many people online at the same time? Just wondering...
Almar
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
