 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Targeting - A variation of dead reckoning |
|
 |
Anonymous Poster |
|||
 Posted - 5/17/2001 3:01:46 PM |
||||
Nice article! You asked for other sources regarding techniques similar to your article and I hope you don't mind if I post one here instead of e-mailing it to you  The book Networked Virtual Environments - Design and Implementation (chapter 7, subsection Exploiting Temporal Perception, p221-236) discusses a solution similar to what you are describing. It includes an example where lag is hidden in a multiplayer pong game by smoothly changing the speed of the ball at each player's client depending on the latency and the distance from the ball to the player. One thing to consider when implementing such a scheme is to measure lag over time by measuring the response times on your normal packets, if that is possible, instead of sending a special packet. That might get you a better average that is not completely distorted by lag spikes that can delay single packets such as your special time-measuring packet. It might also give you a more accurate reading if your normal packets are large enough to be fragmented, something that a custom lag-measurement packet might not be. Henry |
||||
|
||||
|
granat Member since: 1/1/2000 From: Denmark |
|||
 Posted - 5/17/2001 4:22:42 PM |
||||
| Great article..Gave me something to think about.. I only have one problem with it..Those pictures donīt animate when I print the article out on paper. Is there a problem with my printer ? |
||||
|
||||
|
Tim Auld Member since: 5/8/2001 From: Adelaide, Australia |
|||
|
Posted - 5/21/2001 10:18:10 AM |
||||
| Some games that I have worked on have used a similar method, which basically drags the object towards its projected destination, instead of just setting it. Works well for the most part, but there are difficulties when the movement is not as simple as your 1D example, and there is rotation as well as 3D translation, during a 300+ ms game. In some cases 'teleportation' is required. It's definitely a step in the right direction, but it's no silver bullet. Also, I would warn against advocating the use of GetTickCount(). It is extremely inaccurate! It's output would make any sensible programmer cringe. Use QueryPerformanceCounter(). I don't think there's anything wrong with sending ping packets. Your messages shouldn't be so big that they fragment (you must send and receive them as soon as you can - so avoid accumulation), and averaging the results will mitigate the "spikes". |
||||
|
||||
|
Cedric Perthuis Member since: 11/27/2000 From: Sunnyvale, USA |
|||
|
Posted - 5/30/2001 7:07:25 PM |
||||
| Some of you speak of differents techniques tried in many game so as to limit the effect of lag in real-time action game. Can you tell us more about those techniques ? Eventually, we are working on a 3D action game. I was considering the solution of smoothing player actions in a physical manner. The acceleration can't be infinite in a physical world, so no object can gain instantaneous speed. So why not to combine the technique of targeting described, and a smooth/and or delay for local player movements and actions. The smoothing could be adjust so that the action seems as real as possible. OK, that's diffcult for quick movement ( light spray, or anything of that kind ), but for the main objects such a smooth could be acceptable. That would give a little time to send movement information and to synchronized the whole movement on every clients. For a walk the smooth must be done when the player starts to walk, but when he stops too ! so when the player releases the key binded to "move forward", the player should continue to move forward on a short distance ( it seems to be done in almost every RPG game ! ) The global movement of the player seen by a remote player can be synchronised by that technique, the only difference is the speed along the path. If we only use that technique a collision could be realised for some players but not for all, that why it should be combine with the technique proposed in the article. I've not experienced that solution, so if you think it's totally stupid , don't remind silent, that could spare us some time. Cedric. our project web page Edited by - Cedric Perthuis on May 30, 2001 7:10:39 PM Edited by - Cedric Perthuis on May 30, 2001 7:12:24 PM |
||||
|
||||
|
appleweed Member since: 9/6/2000 From: USA |
|||
|
Posted - 5/31/2001 2:10:38 PM |
||||
Salut, Cedric!  There are some resources on "dead-reckoning" on GameDev that would help answer your questions:1. http://www.gamedev.net/reference/articles/article803.asp -This article gives a great background on dead-reckoning, including its history. 2. http://www.gamedev.net/reference/articles/article914.asp -This article is a bit more advanced and introduces "cubic splines". I've implemented the above and they do an excellent job. However, I do appreciate Chris Haag's article on "Targeting". I've seen some similar approaches, but not a decent explanation like Chris'. Thanks, Chris! A couple of comments I have on the article: 1. On computing latency... I think timing the round-trip return of a packet and then dividing by two is a good average, but I caution people to recognize that a given connection from Point A to Point B is not necessarily the same physical path as from Point B to Point A. But, again, Chris' approach is a pretty reasonable average. 2. Along with #1... I've heard people talk about maintaining a global clock between clients. In this approach, you would only need to synchronize the clock with respect to lag. Your targeting calculations would then involve the global clock and "time stamps", rather than lag directly. This may reduce over-head by calculating lag for a single resource and thus a smaller set of packets. (But this is probably more significant for "peer network" type games where there are muliple "clients" involved, rather than client-server.) -Omar --- "We are Indigenous. Welcome." Indigenous Technologies, Inc. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
