Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 06 Nov 2012
Offline Last Active Jun 03 2013 02:06 PM

Posts I've Made

In Topic: Alternate solution to Valve's lag compensation for melee combat

06 November 2012 - 12:40 PM

Thinking about extrapolation some more... I currently slow down significantly (but not stop entirely) movement speed during melee attack sequences, another addition could be to send exact position and movement velocity along with every attack message, and extrapolate an amount equal to the transit time, and smoothly snap to that position.

In Topic: Alternate solution to Valve's lag compensation for melee combat

06 November 2012 - 12:20 PM

Thanks. I didn't realize fighting games did that, I actually stole a simple implementation of that idea from the GDC presentation on Networking in Halo Reach from Bungie (they did it with the armor lock animation, and grenade throws I think).

My current system similarly allows me to set different lengths for the wind-up, slow-down, and follow-through segments of an attack sequence (in an attempt to telegraph attacks: for instance, a 0.2 second wind up, 0.2 seconds of super-slowed animation speed while the arm is cocked back, and then 0.4 seconds to follow-through for the rest of the animation, for a 0.8 second total attack sequence). I am actually currently distributing the latency of a newly-arrived attack event message over the wind-up and follow-through (for instance: if the timestamp is 100ms old, i'll reduce the wind-up time by 50ms and the follow-through time by 50ms). I put a cap on the compensation at 200ms, though.

I thought about using extrapolation, but in a fully 3d environment like a TPS or FPS, is that really a good idea? Player movements are notoriously unpredictable, I feel that might do more harm than good. I'm not sure how else to smoothly render remote players though, without using interpolation back time. I'm currently just lerping remote players to the latest position that comes through at a fixed rate.

I also thought about, rather than 100% relying on authoritative server hit detection, I'd let clients "claim" to hit other players, then the server could check some deltas and and say "okay, that sound reasonable", but the timing would be very late, and it seems like it might be a waste of bandwidth since I couldn't bundle it with the initial attack message (because the hit test doesn't occur until ~50% through the attack sequence).