🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Measuring lag time precisely
Author
Hey, I''m working no my first multiplayer game using DX.
I got it all set up pretty well and have it going better than I thought I could at first, but of course I''m not done. It''s not even close to done.
Anyway, in this game I have the person situated at the top of the screen (2d game) and he fires bullets. For multiplayer, every time you fire a bullet it gets sent to the other player and the other player sees the bullet you sent (I send position_x, posy, velocity_x, vely)
Now I noticed that this was ok, but PROBABYL (not sure) due to lag the scoring was off because on one screen there was a hi while on the other there wasnt. So to combat this I figured I''d calculate the lag and multilpty the velocity by the lag to figure uot how much the bullet shuold have moved since it was started. So I aded a DWORD StartTime to teh bullet msg struct. Then when I send I do BulletMsg.StartTime = timeGetTime() then send it
then when I recieve I get the delay by doing delay = timeGetTime() - BulletMsg.StartTime;
I didnt realize how stupid this was until I looked at my log file and saw how off the delay was. I was testing it uot on my computer with two isntances of the game running, so it worked ok, but then I tried it with someone over the ent and realzied timeGetTime will enver be the same thing on 2 computers.
So I was wondering, is there a way I can accurately determine the delay time so i can get this right? If not, how would I go about fixing such a problem? (This is a client-client setup, 2 players only) Is there anything but timeGetTime() that IS the same on 2 different comps?
Thanks a lot in advance guys!!
- Rob
ByteMe95::~ByteMe95()
Cerebrum Software
You might be better off making one a server with it''s information always being correct so when one computer sees the hit, the server will make the call. I was going to suggest time syncing the two computers, but that is just the same thing as what you were doing. Even if you got the times on the computer''s semi close, they''d never be exactly the same due to lag and it would almost be impossible to do over the net as performance is rarely consistent.
Author
The problem with doing client-server is that we dont have a server :o)
And I dont really know how to set it up either way.
Is there any way to do this using client client?
It''s done in duel and brouhaha (If u have "Inside DirectX") with client-client connections, but i dont know how
I know they do dead reckoning, but I''m not sure what that is :O)
ByteMe95::~ByteMe95()
Cerebrum Software
And I dont really know how to set it up either way.
Is there any way to do this using client client?
It''s done in duel and brouhaha (If u have "Inside DirectX") with client-client connections, but i dont know how
I know they do dead reckoning, but I''m not sure what that is :O)
ByteMe95::~ByteMe95()
Cerebrum Software
I remember reading that DirectPlay has a function for getting the average lag on a line, once a connection is set up. (I forget the function name, but if you can''t find it, let me know... I''ll look it up (It might be a Win32 call... if I remember incorrectly... but I know it exists) In any case, It''s also easy to compute with a ping (to find round-trip time), and a comparison with the other side''s "round-trip" result.
As for dead-reckoning, it involves sending velocity information along with position; then the receiving end keeps plotting that path using the velocity until it is notified of a new position/velocity over the network. Great for things involving physics simulations, like racing-sims, but I don''t know how much use it would be for a bullet-collision situation. One thing you COULD do is take lag into consideration locally... that is, find out the average lag over the network ("this may take a little while"), then on local side, only show user interaction after a short time (equal to the lag time). So when a user hits the "fire" key, the action is placed in a queue for a short time, and the bullet isn''t displayed until it comes out of the queue. For information coming over the network, it bypasses the queue and goes straight to the display. This way, all actions essentially occur at the same time. The downside, of course, is that what the user sees on the screen is not an immediate result of input. With a low enough lag, though, it can pass for real-time. (You might want to make a check for lag time, then use this method when the lag is small enough, and use some sort of prediction method when the lag is larger)
Also, you can implement Client/Server on a Client/Client connection simply by deciding during the connection phase who will be the master and who will be the slave. There are a few ways to do this, but the most straight-forward would be to make the side that initializes connection be the master. There are more convoluted ways to do it, like making the one with a faster processor be the master (unreliable, since two sides could have equal speed specs, and you''d have to rely on another approach in this case... so you might as well always rely on another approach), or if the lag differs between the two sides, make the one with less upstream lag be the master. You can even go as far as letting the user decide who will "host" the session.
Once you''ve got a Master-Slave relationship, detecting hits becomes much easier... all decisions fall back on the Master''s scenario of how things happened (both sides still let each other know what''s going on).
Let me know how it all goes...
"Man is the only animal that laughs and weeps; for he is the only animal that is struck with the difference between what things are and what they ought to be."
--William Hazlitt
As for dead-reckoning, it involves sending velocity information along with position; then the receiving end keeps plotting that path using the velocity until it is notified of a new position/velocity over the network. Great for things involving physics simulations, like racing-sims, but I don''t know how much use it would be for a bullet-collision situation. One thing you COULD do is take lag into consideration locally... that is, find out the average lag over the network ("this may take a little while"), then on local side, only show user interaction after a short time (equal to the lag time). So when a user hits the "fire" key, the action is placed in a queue for a short time, and the bullet isn''t displayed until it comes out of the queue. For information coming over the network, it bypasses the queue and goes straight to the display. This way, all actions essentially occur at the same time. The downside, of course, is that what the user sees on the screen is not an immediate result of input. With a low enough lag, though, it can pass for real-time. (You might want to make a check for lag time, then use this method when the lag is small enough, and use some sort of prediction method when the lag is larger)
Also, you can implement Client/Server on a Client/Client connection simply by deciding during the connection phase who will be the master and who will be the slave. There are a few ways to do this, but the most straight-forward would be to make the side that initializes connection be the master. There are more convoluted ways to do it, like making the one with a faster processor be the master (unreliable, since two sides could have equal speed specs, and you''d have to rely on another approach in this case... so you might as well always rely on another approach), or if the lag differs between the two sides, make the one with less upstream lag be the master. You can even go as far as letting the user decide who will "host" the session.
Once you''ve got a Master-Slave relationship, detecting hits becomes much easier... all decisions fall back on the Master''s scenario of how things happened (both sides still let each other know what''s going on).
Let me know how it all goes...
"Man is the only animal that laughs and weeps; for he is the only animal that is struck with the difference between what things are and what they ought to be."
--William Hazlitt
Author
I do have it set up as client-client with a "master" or host. I thought about doing it that way, but then couldn''t something disappear on the slave side even if it wasnt actually hit there, it was only hit on the master?
And so wevery time there is a collision, I should send out a collision message and take care of it from there? Sounds like it could work. Wouldn''t be 100% accurate, but could be good enough. I''ll guive it a try
Have you read Inside DirectX? Cause igf you have my game is pretty much set up like bruohaha is, just so you get a better view of what it is im diong.
Thanks again
- Rob
ByteMe95::~ByteMe95()
Cerebrum Software
And so wevery time there is a collision, I should send out a collision message and take care of it from there? Sounds like it could work. Wouldn''t be 100% accurate, but could be good enough. I''ll guive it a try
Have you read Inside DirectX? Cause igf you have my game is pretty much set up like bruohaha is, just so you get a better view of what it is im diong.
Thanks again
- Rob
ByteMe95::~ByteMe95()
Cerebrum Software
Looks like you want to synchronize clocks across the clients. There is a well known algorithim which will synchornize both your clients to within 10 ms of each other. Look on this page.
http://www.codewhore.com/howto1.html
With a 10 ms error at small velocites it would result in an object being a few pixels off from each other on either client, but this is hardly noticable. If the lag between the clients is small itself, this method your using to synchoznize object postions across the network will work well. However if the lag is large, shots will magically teleport a large distance from the player who shot them, so i suggest taking this into account. You''ll proably want to do a collision test from point of origin of the shot to its corrected position, so shots dont teleport through close up players. For even more accuracy you might want to buffer in objects past positions, for perhaps 500ms, and perform collision test for instantanous weapons using the most accurate poisition data avaiable to the simulation. Instantanous weapons are weapons like lasers etcc.
Good Luck!
-ddn
http://www.codewhore.com/howto1.html
With a 10 ms error at small velocites it would result in an object being a few pixels off from each other on either client, but this is hardly noticable. If the lag between the clients is small itself, this method your using to synchoznize object postions across the network will work well. However if the lag is large, shots will magically teleport a large distance from the player who shot them, so i suggest taking this into account. You''ll proably want to do a collision test from point of origin of the shot to its corrected position, so shots dont teleport through close up players. For even more accuracy you might want to buffer in objects past positions, for perhaps 500ms, and perform collision test for instantanous weapons using the most accurate poisition data avaiable to the simulation. Instantanous weapons are weapons like lasers etcc.
Good Luck!
-ddn
why do you send the bullet every time??
just send
"create new bullet"
you know already the bullet pos(enemy pos) and you know who
shot the bullet...
you are wasting time man!
just send
"create new bullet"
you know already the bullet pos(enemy pos) and you know who
shot the bullet...
you are wasting time man!
I agree with Arkon, just send the create message.
One thing to note is that in most multiplayer games the "screens" do not match exactly. Just take a game like UltimaOnline or Everquest and have a character on one system complete an action, you will notice that it does not match what is happening on the other system.
I basically never code multiplayer games to be exact, I just try code what is believable. If the players never suspect something is out of alignment then you are safe. Its when they start asking questions that you have problems. For this you can use dead reckogning and other techniques.
-AG
One thing to note is that in most multiplayer games the "screens" do not match exactly. Just take a game like UltimaOnline or Everquest and have a character on one system complete an action, you will notice that it does not match what is happening on the other system.
I basically never code multiplayer games to be exact, I just try code what is believable. If the players never suspect something is out of alignment then you are safe. Its when they start asking questions that you have problems. For this you can use dead reckogning and other techniques.
-AG
I think there are two different ways of solving it:
- First is with a client-server session, where the server makes all the physical simulation and calculates the bullets hits
- The second is using dead-reckoning or somethin similar. You just send a CreateBullet message, with the position and velocity (vector) of the bullet. After this, the simulation of the movement of the bullet should be done internally. If there are two players, to know if there has been a collision, every player should check the bullet''s collision with local object, if collides in the local machine it has been a hit, and then send the hit message to the other player.
There''s a very good article in the GameDeveloper about Internet games, "Internet sucks" from the people who made XWing vs TIE Fighter, check it out! www.gamasutra.com
Hope it helps.
Edu Garcia
egarcia@ubisoft.es
- First is with a client-server session, where the server makes all the physical simulation and calculates the bullets hits
- The second is using dead-reckoning or somethin similar. You just send a CreateBullet message, with the position and velocity (vector) of the bullet. After this, the simulation of the movement of the bullet should be done internally. If there are two players, to know if there has been a collision, every player should check the bullet''s collision with local object, if collides in the local machine it has been a hit, and then send the hit message to the other player.
There''s a very good article in the GameDeveloper about Internet games, "Internet sucks" from the people who made XWing vs TIE Fighter, check it out! www.gamasutra.com
Hope it helps.
Edu Garcia
egarcia@ubisoft.es
Such a system isnt good enough for an action game, in my opinon. Without a more robust synchornization scheme objects which you see on your screen have too much inherent network error to be trusted. How can you develop any skills if you always doubt what you see on screen? Shoot someone 20x and he doesnt die becuase your shots are actually 30 pixels behind where you see them? This effect is lessend by people with good connections to the server ofcourse, but even then different latecny will result in quite different representations. For much slower paced games like MMORPG or turnbase games the event base scheme with little synchronzaiton will suffice. Good Luck.
-ddn
-ddn
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
