Odd Vanquish bug ties incoming damage to frame rate

Vanquish damage banner

If you’re currently bum-sliding your way through newly-ported shooter Vanquish [official site] on a high-end rig then you might be finding it tougher than you expected.

Don’t worry, your reflexes haven’t slowed overnight – the PC version is actually harder than the designers intended it to be. An eagle-eyed NeoGaf user called .:Wesker:. seems to have has spotted a bug in the port that ties the amount of damage you take directly to your frame rate.

So, if you’re playing on higher specs, or on lower settings, you’re actually taking more damage than somebody whose game is running like a slideshow.

If fits in with what Alec said in his review, noting that he “died a lot in Vanquish (on normal difficulty)”, which could become frustrating.

Take a look at the evidence below: the first gif shows the game at 30 FPS and the second at 60 FPS. Notice how quickly the screen turns red, which is an indication that you’re nearly dead. Top sleuthing on .:Wesker:.’s part.

Bizarre, although not without precedent. A similar thing happened with weapon durability in Dark Souls 2 when it was ported to PC. The higher your frame rate, the quicker your weapons degraded.

That bug took a year to fix, but let’s hope that Sega and porting house Little Stone Software can get Vanquish sorted a bit faster than that.

Vanquish is still worth playing, then, just maybe turn the difficulty down a notch. Or leave it where it is, you masochist.

21 Comments

  1. golem09 says:

    Is this kind of a japanese programming mentality? Tying everything to frame counts instead of time?

    • Jerion says:

      It’s more like a dev ‘hack’ to simplify the implementation of a game system- in this case damage. One part of building for a console is that you can choose a fixed frame rate that the game will be optimized to hit at all times; if 30 FPS is that target, then each frame is approximately 33ms. When the damage system was implemented, a designer could simply tie damage taken over time to each frame (e.g. -1 hp per frame) instead of working out a more complex time-management system in the game engine. Depending on your point of view, this is either “being lazy”, or “a clever time-saving shortcut”.

      • KDR_11k says:

        Lots of ways this could happen. E.g. if the logic that cleans up shot instances that have impacted runs 30 times per second and the game logic otherwise runs at the rendered framerate then the shot could run its impact logic multiple times before being removed. Or if the shooting is triggered by an animation being in a specific frame (that used to happen only once per cycle when the animation framerate and logic framerate were equal but now happens for several logic frames in a row). Or reload times being denoted in frames instead of seconds.

        But then my game dev experience is mostly limited to the Spring engine where we have a fixed logic framerate (30) and a dynamic rendering framerate that extrapolates movement from the last logic frame. I’m not sure how you’d make a game logic that can run at any framerate and still produce the same results (e.g. basic things like an arcing projectile travelling different distances per frame and running things like its collision logic at different rates).

        Of course there’s the possibility that they cheated by mixing rendering and logic and just threw logic into the rendering thread…

        • ScrapCupcake says:

          So, for dynamic framerates, you just need to track a delta time between the last frame rendered and the current one, and scale your outputs by that delta.

          Its taught as the default way to do any such thing in Unity at least, when you’re working inside of the render tick vs. the physics tick which is 50 frames per second fixed. So if you pass things between the physics tick and render tick and don’t don’t scale it properly, you could easily (mis)implement the above sort of frame rate conflicting code.

          • KDR_11k says:

            I’m guessing they didn’t keep a strict separation between physics and render ticks… As long as they’re 1:1 that won’t show up as a problem but now it does. Of course just increasing the physics tick rate isn’t trivial either, not all delta calcs are easy to do and I wouldn’t bet on existing code running at different tick rates without extensive QA runs…

    • Xerophyte says:

      It’s common for console games, and perfectly sane. There are basically three ways you can write a game engine:

      1. You run game and render logic at the same fixed cadence (typically 30 or 60 updates/second). This makes your code simple, as the game state you need to render is the same as the game state you need to compute. However, you have to be able to guarantee that exact framerate since slowing it down (or speeding up) does the same to the game logic.

      2. You run game and render logic at the same varying cadence. You can handle a varying FPS and your code is still simple, but now your game logic is nondeterministic. You can run into very annoying bugs where the game mechanics stop working in unpredictable ways at certain frame rates. This bug and the Dark Souls weapon durability issues are simple examples, but you can also have more serious problems like players falling through the floor (or being launched into the sky) at low frame rates because your collision logic fails. It also makes any sort of replay functionality impossible, and netplay extremely hard: no two players get the same results!

      3. You run the render logic at a varying cadence and the game logic at a fixed cadence (typically 20 or 30 updates/second, depending on genre. Starcraft semi-famously ran at 10). Your game logic is predictable and deterministic again, but now you’re no longer rendering the same game state that you’re computing. What you actually need to display is an interpolation between two game states, neither of which ever gets used directly. Handling the requisite communication is complicated and error-prone compared to the synchronous approaches.

      If you know what hardware your game will run at and can control the environment and experience well enough to guarantee 30 or 60 FPS then 1 is easily the best choice. Minimal complexity, minimal latency, least possibility for bugs and errors. If you then have to port your game to run on the extreme range of PC hardware, well, it’s going to be rough. You need to do major, error-prone surgery to the core structure of your game engine. Which is why most console ports just lock the framerate; the alternative is often a port that will explode in wildly unpredictable ways and hard-to-fix ways.

  2. thenevernow says:

    I thought it was a bit too easy to die… But then I concluded I’m just getting old. :)

    • int says:

      Traditionally getting old is a splendid way of dying. I’m trying it right now!

      • wcq says:

        I’ve heard conflicting reports on whether the best way to die is peacefully in your bed, doing something you enjoy or with your boots on, so to speak. And you never know when you gonna go, so I spend most of my time in my bed, reading comics with my boots on.

  3. Jiggeh says:

    I’m glad this is being reported on, hopefully it puts some pressure on SEGA to have it fixed. These kinds of bugs don’t seem that rare but for the most part you don’t hear so much about it. For example the recent PC/PS4/Xb1 ports of Resident Evil 4 as well as PC Bayonetta both suffer from button mashing QTE’s being twice as hard as they’re supposed to be because of the increased framerate, and I’m not entirely sure if either got/will get patched to fix it.

    • Pich says:

      Are you sure about the Bayonetta bug? because IIRC that game already ran at 60 fps on both X360 and WiiU.

      • Kasjer says:

        Bayonetta have very light requirements on PC and it’s easy to run it at well beyond 60fps on anything better than 750Ti/950. For folks with high refresh rate monitors, the game QTEs are broken. 120+ fps messes them up in really bad way.

        At least in Vanquish case, increased 60fps responsiveness along with added precision on K+M kind of helps to offset the increased difficulty.

        Also, damn, it is surpprising that game logic would be tiied to framerate so much. Even modern Quakeworld clients have physics and logic separated from rendenering so you can run the game at as much fps as your pc game is capable of (and this is first Quake – we are talking about hundreds of fps) and still have sweet spot of around 80fps for internal logic…

  4. RedViv says:

    It’s a bit disappointing considering the team porting this also ported Valkyria Chronicles, which had the exact same bug with interception fire.

    • Anarchy_101 says:

      Man, now I remember that initial “am I just bad at the game?” feeling I had running into shocktroopers for the first time.

  5. Unclepauly says:

    This is not the 1st time Platinum games have had framerate tied bugs. Also in console land this is a regular thing with their fixed framerates(at least used to be)

  6. jp says:

    Reminds me of Dark Souls and weapon durability bug with “high” framerates, which occurred even with just 60fps.

  7. Huwbutts says:

    No. Freaking. Way.
    I uninstalled it because I was getting one-shotted by Burns on the hardest difficulty, and thought it was ridiculous.
    Thank goodness it’s not me being crap! :D

  8. desolation0 says:

    So the prescription for now, turn up all the graphics settings and downsample from 8k?

  9. haldolium says:

    I was really looking forward to this and had my preservations about the port.

    But even though it feels quite okay playing with m/k I really don’t find it as entertaining as I wished it to be.

    Wasn’t aware of the garbage story and the overall flow feels a bit weak for some reason. I also can’t play it for longer.

    Well maybe go get through with it, but I really had a different mind picture of that game before.

  10. gabisver says:

    it should be said however that they have granted access to a beta patch that fixes these issues

Comment on this story

XHTML: Allowed code: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>