or... here is an idea...
How are you detecting the other ****p?
If it is radar, there is a time delay caused by the distances involved...
closer, more up-to-date, further away, more guess work...
have the server send to the player where the ****p was X turns ago based on
distance...
--
(All advice is checked, re-checked and verified to be questionable....)
"Gabriel Belingueres" <gaby@[EMAIL PROTECTED]
> wrote in message
news:1161783425.328865.126160@[EMAIL PROTECTED]
'm doing a 2D multiplayer game too. I'm still in early stages (I'm
working on the graphics now), but I think I will use some dead
reckoning technique.
You may want to read something called Position History-Based Dead
Reckoning (PHBDR).
HTH,
Gabriel
Brandon ha escrito:
> I'm writing a little 2D overhead multiplayer space shooter. I use
> client-side prediction to make movement smooth for the local player,
> and it looks great. For the local player. My problem is that I want
> to show the player the current location of the other space****ps in
> regards to the local player, and to do that I need to predict them,
> too. Now, fortunately, the movements of the enemy space****ps are
> pretty smooth, since they smoothly accelerate rather than zip left and
> right instantly.
>
> My problem, though, is turning. When a player presses left or right,
> his ****p immediatley begins to rotate at a set rotational velocity, and
> when the player releases the key, the ****p immediately stops turning.
> This, again, works great for the local player. However, when the local
> player receives notice that another player began rotating 5 game states
> ago, the local player predicts the motion ahead a bit and continues to
> extrapolate how the other ****p is rotating. With a bit of smoothing,
> that looks fine, too.
>
> The problem is that when the other ****p stops turning, the local
> machine has already predicted it turning a bit further, which it then
> needs to take back, causing it to snap back after fini****ng a turn like
> it's on a spring. It happens every time, and if there's 500ms of lag
> or so, it can be more than a 180 degree turn.
>
> In order to solve this problem, I've tried a few techniques. The
> first, obviously, was to stop the prediction of turning. I still use
> the predicted turn angle to compute motion (if you're accelerating), so
> if you have quite a bit of lag, you might notice the ****p not quite
> flying in the right direction briefly on occasion, but it's hardly
> noticeable. I haven't quite worked out a good way to smooth between
> these messages yet, especially in a situation with high variance in the
> network connection's lag, but I'm sure I can work out something that
> more or less works.
>
> So, I'm asking for general input as to how to handle players controlled
> elsewhere in a system that uses client prediction. In half-life 2, for
> instance, I do not notice the other players take a step back every time
> they stop walking forwards. Does half-life 2 not predict the locations
> of other players? Or does it use some other, neater trick?
|
