Jump to content
  • Advertisement
Sign in to follow this  
helikopterodaktyl

Projectile shooting latency

This topic is 791 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am working on a multiplayer 2D shooter to get the hang of networking. In general I am trying to make something like Alien Breed, except multiplayer.

 

 

 

I am using UDP (through Enet) for my networking, Server is running at 20Hz. I have implemented entity interpolation to smooth the movements (rendering 100-200ms in the past, didn't settle on the final value yet) and I have clientside prediction so that player's movement is instant. These parts work well so far.

 

I am trying to add a projectile weapon now (slow moving projectile). When player clicks the mouse button, I send a "PLAYER_WANTS_TO_SHOOT" packet to the server. Server creates a bullet object which will be broadcast to all players on the next server tick. The problem is, it takes roundtrip/2 time to get the PLAYER_WANTS_TO_SHOOT packet to the server, then some delay until the next tick, then roundtrip/2 time to get to the player and then I render everything 100-200ms in the past, so that's additional latency. By the time the client receives the position of the bullet he shot, he might be in a completely different spot, making the bullets away from the player, which is awkward. It's not an issue for other players shooting, because they are in the past, so the bullets will appear to come from them.

 

How to fix this issue? I imagine clientside prediction should be used somehow here, but if client was to control the bullet it allows him to cheat. Alternatively I could let the client create a fake bullet which is a visual only, while the real bullet and hit checking would be done on the server. Would that work?

Edited by helikopterodaktyl

Share this post


Link to post
Share on other sites
Advertisement

Rendering 100ms in the past seems a bit pessimistic to me. You'll probably avoid all instances of not having data in time, at the price of everything seeming slow. I'd prefer to reduce that latency significantly at the cost of having to perform occasional extrapolation and potentially snap-back to correct things.

 

You can perform client-side prediction without being client-authoritative, which is basically the 'fake bullet' you speak of. The client produces a projectile, tells the server which direction it's travelling in, and the server can confirm or deny it, just like it would for player movement if you're allowing them to move without a 200ms delay. You can interpolate between the predicted trajectory and the corrected trajectory if necessary, and you can delay the actual client-side firing to some degree as well, covering it with animation and sound fx.

Share this post


Link to post
Share on other sites

Definitely sounds like you've strayed too far away from lockstep in your zeal to make inherently slow software seem less slow for the user. Strayed so far that things stop working. While an arcade game can play faster and looser with physics than a simulation can, there are still limits as to how much you can fake. You're going to have to tighten it up some. When you have to start faking stuff because of other stuff you've already faked, you're building a house of cards - on a foundation of ethereal "sort of lockstep" physics.

Share this post


Link to post
Share on other sites
IIRC, counter strike, which has become a model for twitch action networking, spawns a predicted client-side projectile, while messaging the server to spawn one. The message includes a timestamp so the server can actually rewind if necessary to insert the projectile into the simulation at the exact moment the client requested. To facilitate this the server obviously needs to buffer a lot of simulation state so that rewinding and replaying within the configured latency window is possible.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!