Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct here to familiarize yourself with the rules and how to post constructively.

  2. Unity 2022.1 is now available as the latest Tech release.
    Dismiss Notice
  3. Improve your project's performance with our new guide on profiling in Unity.
    Dismiss Notice

Shooters - Shoot, Rotate, Move Or Rotate, Move, Shoot

Discussion in 'General Discussion' started by HiddenMonk, May 1, 2019.

  1. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    Is there a standard that the competitive shooters use when it comes to the order of actions between firing a weapon and moving your player?

    At 30 fps, Shooting before you Rotate and Move the player in that frame results in the bullet impacts looking like they lag behind (because they are in regards to your new rotation and position), however, I feel it makes more sense to do it this way since in this frame your crosshair is on a enemy, so you press fire, but the input wont be detected until next frame, so next frame we make sure to run all weapon code before moving you or your enemy translation code.
    Meanwhile, Rotating and Moving the player before Shooting makes everything visually precise, but now in the same case as above you will potentially miss your target. However, perhaps in other cases doing things this way can be beneficial, such as maybe it would make rocket jumping feel better as you flick to your side and fire.

    Youd think it wouldnt make a big difference, but its jawing how noticable it is at even 30 fps.

    Edit-
    Tested with 60fps, still very noticeable. Even 120fps is noticeable, but my old computer cant record that properly.
     
    Last edited: May 1, 2019
  2. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,363
    Most gamers run at 120 or 144hz or 90 for VR. 30 is not that usual.

    We use SteamVR and haven't even bothered to check which comes first, controller transform update or button event.

    edit: Btw, pretty sure industry standard is to move player first than handle input. But I cant swear on it
     
    Last edited: May 1, 2019
  3. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    14,455
    Maybe if you're only considering enthusiasts on PC. 60 or 30hz is very common elsewhere.

    I don't have a definitive answer, but I do have some things to think about.

    Bullets do not in fact travel instantaneously, and they do inherit momentum from the thing that's firing them, so it's not incorrect for things to behave this way. If you click and the bullet hits where you were pointed at the time, but the cursor has since moved... that sounds right to me for things that ignore momentum. For things that don't ignore momentum, you probably want to take it into account.

    You could think about different implementations for different weapon types, so that each feels and/or behaves as desired. Rather than doing this per-weapon, I'd consider hit-scan (end of frame?) vs. projectile weapons (start of frame?).

    Platforms where 30hz is standard typically use a gamepad instead of a mouse. Being a much less "twitchy" input device (it's either slower or less precise, depending on how you set things up) the effects you're noticing are much less severe. There may also be acceleration or momentum effects which could be covering this up. On platforms where 60+hz is standard the effects are much less pronounced than at 30hz simply because of the higher refresh rate, but of course only for players who have the hardware to achieve it.

    Finally, I'd pick a "standard" shooter or two and see if I could replicate how they behave. Examine the effects and match them as closely as you can. Or find a shooter which has been open sourced (a bunch of the Quake games, for instance) and see how they did it.
     
    Last edited: May 1, 2019
    Ryiah likes this.
  4. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,363
    Valve have picked a very low script execution for their VR controller pose update so it's ensured to run before logic, pretty sure this is the general consensus for the industry , it feels strange that the logic should use stale state by design

    Edit: and bullet travel time is a far greater factor anyway like suggested
     
  5. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    I tested with 60fps, still very noticeable. Even 120fps is noticeable, but my old computer cant record that properly.

    To test this in other games, you pretty much just need to lock your framerate to 10 or something to make things very noticeable.
    In Team Fortress 2, it seems that they rotate before shooting, however, I dont know if they move before shooting.
    At 30fps it seemed that they move before shooting, but at 10fps or even lower it seemed like they didnt move before shooting, but maybe that has something to do with the way they network things?

    Still unsure as to which to pick. Maybe I should download counterstrike and test on there, but I assume it would give same results as tf2, which is Rotating before Shooting, but not sure about moving. I feel like I would want to Rotate before shooting, but the game I am inspired by seemed to shoot before rotating and moving.

    Also, my tests are more so for instant hitscan weapons, no bullet travel time, and while Shooting before Rotating can give the illusion of travel time, it would still be inconsistent since it would vary depending on your framerate.
     
    Last edited: May 1, 2019
unityunity