🎉 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!
Everything working...and now?
Author
Finally I''ve got everything working fine in my multiplayer game. I''m usig cubic splines to create smooth paths for the ships. Currently an update every 75/100ms works pretty well. Now, the game isn''t been build to stop the main problem: Latency.
I''ve done some experiments, and it results that lag will be visible, even if it''s 30ms. Although the path is smooth. I need to add some extra interpolation code, because there''s a minor calculation error somewhere...
Anyway, I''m wondering if the best option to reduce the latency problem is "Time synchronizing". Thus, adding the latency of received packets to the packets thast the server will sent (I''m using Client-Server style) And that the receiving player will add it''s own latency to the received data. now the position should be relatively correct.
Anyone can confirm that this is the best option, or are there other posibilities
Almar Joling
(PS: I''m using VB, DP8, not that it really matters)
This depends a bit on the type of game you''re writing. In most cases, though, your method works just fine.
On the other hand.. well I posted a quite extensive post on the Half-Life netcode a while ago, and HL doesn''t predict movement of things that are controlled by the server or other players. Instead, the server will go back in time a bit when it receives a client packet to make sure collision detection, damage calculations etc.. will have (more or less) the same outcome as they had on the client.
HL does predict the local player''s movement though. Otherwise... well try to play the game when movement commands are delayed by 200ms (BTW, you can simulate this by typing "pushlatency 0" in the console; this might work with other Quake-alikes as well).
cu,
Prefect
---
Sanity is the trademark of a weak mind.
On the other hand.. well I posted a quite extensive post on the Half-Life netcode a while ago, and HL doesn''t predict movement of things that are controlled by the server or other players. Instead, the server will go back in time a bit when it receives a client packet to make sure collision detection, damage calculations etc.. will have (more or less) the same outcome as they had on the client.
HL does predict the local player''s movement though. Otherwise... well try to play the game when movement commands are delayed by 200ms (BTW, you can simulate this by typing "pushlatency 0" in the console; this might work with other Quake-alikes as well).
cu,
Prefect
---
Sanity is the trademark of a weak mind.
Author
My game is like Netrek/Subspace; you control a ship in space and "fight" the other players
I read your post about a "retroactive" system, or was it something else? Well, anyway I''m having problems with the client side prediction, so I''m going to try it first with time synchronizing. I thought I saw some code on codewhore.com on this.
Almar
I read your post about a "retroactive" system, or was it something else? Well, anyway I''m having problems with the client side prediction, so I''m going to try it first with time synchronizing. I thought I saw some code on codewhore.com on this.
Almar
quote: Almar Joling wrote:
Now, the game isn't been build to stop the main problem: Latency. ... Anyway, I'm wondering if the best option to reduce the latency problem is "Time synchronizing".
Interpolation (smoothing) is only half of the solution; the other half is extrapolation (prediction). Take advantage of "spaceship physics" to prevent your players from stopping/turning on a dime -- force them to reverse thrust and slow down for anything but minor course corrections. This makes dead-reckoning and other prediction techniques that much more accurate.
Also, don't throw in more interpolation code if the current stuff has an error. Post your algorithm or source and we can help track it down, but don't hide the error under more layers.
Next, network clock synchronization is intended more for collision detection and other state changes than it is for interpolating or extrapolating object paths. Since your NetClock/drift and your modeling/prediction are probably both derived from the same latency statistics, you would just be shifting the blame. Use position updates to keep all ships moving smoothly on the screen, and use the NetClock to resolve exactly where your ship was when it crossed paths with that alien.
quote: Prefect wrote:
Instead, the server will go back in time a bit when it receives a client packet to make sure collision detection, damage calculations etc.. will have (more or less) the same outcome as they had on the client.
This method scares me a bit. We've discussed doing something like this for our network games, and the problem is that you fall quickly into speculative backtracking: "if I shot him, he didn't shoot the guy who was about to pull the lever."
Now, I'm not saying that these issues are unsolvable -- but they do move alot more work up into the high-level code that is better left in the modeling and prediction layer. Especially in a threaded engine, where crossing that line means more synchronization headaches.
Of course, the type of game will have a big impact on this as well. I guess there's alot more research left to do.
Ford (the other Prefect)
Edited by - fprefect on February 9, 2001 3:10:16 PM
Author
I don''t have access to the code right now, but I''m using the Cubic spline code that can be found on the "programming" part of the Gamedev.net site (http://www.gamedev.net/reference/articles/article914.asp)
The clients sent position/velocity data of their current position. Every time when new data is received the client will "shift" a vector... v1=v2, v2=3, v3=4, v4=Received position.
The game will calculate a spline (path) between those 4 points, and let the ship "follow" this path. So no jumping, when the packets arrive at time. (0 ms latency :o).
When the path is at it''s end and there''s still no new data, the game will *try* to calculate a new position using the last received position(x,y)/velocity(x,y). and add this position to the spline, so that the ship will travel without any jumping to this new point. The Cubic spline code is perfect at the moment, though
The ships velocity is increased/decreased with:
.X = .X - Sin(Angle)
.Y = .Y - -Cos(Angle)
(This one is used to increase speed)
So a player has to reverse thrust, or has to turn around and give more thrust (it''s just like the controls of Asteroid!)
The ships cannot goto "0 velocity(x,y)" with one key press
Hmm...something aside:
Now you say this I''m wondering how this can actually work, I might be wrong...
There are two players Client1 and Client2, playing a First Person Shooter . Client1 has a ping of 50ms to the server and Client2 has 300ms to the server. Client2 shoots Client1, and he will hit him. Now this happy "shoot" packet will go to the server. Client1 also sees Client2 and also puts a bullet through him. This packet will arrive 250ms earlier than Client''s2 bullet. Who will be killed? Probably Client2, because the server received Client1 as the first shooter. Now while I''m typing this I''m thinking of the answer: time synchronizing :o) that would probably the only solution to this problem... I''m not going to remove this part though, might be some help to some other people :o)
The clients sent position/velocity data of their current position. Every time when new data is received the client will "shift" a vector... v1=v2, v2=3, v3=4, v4=Received position.
The game will calculate a spline (path) between those 4 points, and let the ship "follow" this path. So no jumping, when the packets arrive at time. (0 ms latency :o).
When the path is at it''s end and there''s still no new data, the game will *try* to calculate a new position using the last received position(x,y)/velocity(x,y). and add this position to the spline, so that the ship will travel without any jumping to this new point. The Cubic spline code is perfect at the moment, though
The ships velocity is increased/decreased with:
.X = .X - Sin(Angle)
.Y = .Y - -Cos(Angle)
(This one is used to increase speed)
So a player has to reverse thrust, or has to turn around and give more thrust (it''s just like the controls of Asteroid!)
The ships cannot goto "0 velocity(x,y)" with one key press
quote:
This method scares me a bit. We''ve discussed doing something like this for our network games, and the problem is that you fall quickly into speculative backtracking: "if I shot him, he didn''t shoot the guy who was about to pull the lever."
Hmm...something aside:
Now you say this I''m wondering how this can actually work, I might be wrong...
There are two players Client1 and Client2, playing a First Person Shooter . Client1 has a ping of 50ms to the server and Client2 has 300ms to the server. Client2 shoots Client1, and he will hit him. Now this happy "shoot" packet will go to the server. Client1 also sees Client2 and also puts a bullet through him. This packet will arrive 250ms earlier than Client''s2 bullet. Who will be killed? Probably Client2, because the server received Client1 as the first shooter. Now while I''m typing this I''m thinking of the answer: time synchronizing :o) that would probably the only solution to this problem... I''m not going to remove this part though, might be some help to some other people :o)
Yep, going back in time is a bit problematic to say the least 
It''s use really depends on the type of game.
In Half-Life Valve did this, but only for weapon calculation. If a shot kills another player, he will be dead, but not at the time when the player fired the shot (on his machine), but at the time the shoot packet arrives at the server. In other words, the server doesn''t bother with checks like the "he was shot by (1)Player, so he couldn''t have shot the guy who pulled the lever that opens the trapdoor through which (1)Player should actually have fallen to death"...
This is of course inaccurate, but it''s a lot more satisfying than having to "lead" your shots depending on your ping time.
Basically, if you write a real-time strategy game or a hack-n-slash game it''s not necessary IMO. For a shooter where your aim is highly important, it''s the way to go though.
cu,
Prefect
---
Sanity is the trademark of a weak mind.
It''s use really depends on the type of game.
In Half-Life Valve did this, but only for weapon calculation. If a shot kills another player, he will be dead, but not at the time when the player fired the shot (on his machine), but at the time the shoot packet arrives at the server. In other words, the server doesn''t bother with checks like the "he was shot by (1)Player, so he couldn''t have shot the guy who pulled the lever that opens the trapdoor through which (1)Player should actually have fallen to death"...
This is of course inaccurate, but it''s a lot more satisfying than having to "lead" your shots depending on your ping time.
Basically, if you write a real-time strategy game or a hack-n-slash game it''s not necessary IMO. For a shooter where your aim is highly important, it''s the way to go though.
cu,
Prefect
---
Sanity is the trademark of a weak mind.
Author
I just discovered that the Cubic Splines worked so well, because I accidentally used 10ms packet rate instead of 100ms. This means back to the drawing board, cause it doesn''t work pretty well with this interval
:o(
Almar Joling
:o(
Almar Joling
Is there a releaseable demo of your game in action? I''m intrested in how splines perform in that manner.
Good Luck
-ddn
Good Luck
-ddn
I''d recommend that you continue to use cubic splines, even at 100ms, but use them for your prediction and not just for smoothing your graphics -- the first will still give you the second. This was discussed in another thread, but here''s the basic idea.
When you get a new status update for a ship, you have to accomodate the difference between current position and velocity. Here are the 4 points for the spline: (1) the current location of the ship *on the local host*, (2) the predicted location of the ship at T+100ms (or whatever interval), (3) the correct location of the ship *sent by the server*, (4) the predicted location at T+100ms using the updated numbers.
(Use dead reckoning for your basic prediction)
This will generate a smooth curve from point 1 (the current location of the ship on your screen) to point 4 (the location of the ship when the next update packet arrives). If the local data matches the server''s version, then your curve will just be a straight line.
When you get a new status update for a ship, you have to accomodate the difference between current position and velocity. Here are the 4 points for the spline: (1) the current location of the ship *on the local host*, (2) the predicted location of the ship at T+100ms (or whatever interval), (3) the correct location of the ship *sent by the server*, (4) the predicted location at T+100ms using the updated numbers.
(Use dead reckoning for your basic prediction)
This will generate a smooth curve from point 1 (the current location of the ship on your screen) to point 4 (the location of the ship when the next update packet arrives). If the local data matches the server''s version, then your curve will just be a straight line.
Author
Hmm, I''ll try to implent your system today Fprefect. Ddn, I''ll have a try with Fprefect''s method first, then I''ll put it online, so that you can have a look at it, not sure when, but I think I can do it this week (limited time)
I''m wondering. Is a packet every 100ms very much, compared to other games? I''ve calculated my bandwith usage. It''s 25 for each packet, but for "packet loss" problems, I''ll add another packet, making it 50 (excl. UDP header) Or would the "send at keypress" method work better?
Thanks already,
Almar Joling
I''m wondering. Is a packet every 100ms very much, compared to other games? I''ve calculated my bandwith usage. It''s 25 for each packet, but for "packet loss" problems, I''ll add another packet, making it 50 (excl. UDP header) Or would the "send at keypress" method work better?
Thanks already,
Almar Joling
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
