Does your FPS game logic have the PUBG DPS problem...

The problem in PUBG is the FPS of your game affects the DPS (damage per second of your weapon).



71 fps on the left 70 fps on the right, note this compares the recoil pattern and not the actual DPS but it's a good visual to show the disparity FPS makes.

Article on the issue with more details -> https://www.destructoid.com/pubg-pl...e-directly-affects-weapon-recoil-539718.phtml

Video highlighting the problem

Graph that highlights the issue note > 60 fps and if not aligned with weapons rate of fire you can have a > 10% drop in DPS.

I think the problem is most FPS code looks like this:

Code (CSharp):

1. time = Time.currentTime;
2.  
3. if (time >= nextShotDelay) Shoot();  //** This logic is the culprit.
4.  

When it should be more like this...

Code (CSharp):

1. time = Time.currentTime;
2.  
3. while (time >= nextShotDelay) Shoot(); // I'm assuming the Shoot function adds the intershot delay value and checks if rounds are available and it's firing on burst or automatic.

So does your FPS logic allow for multiple-shots per frame and should we update all those Unity examples to fix this problem?

 

The problem lies with the fact that firing rate is frame rate dependent. I've got this problem with my bullet pooler using non-ECS. If you set the delay to 0 ms, then the game fires bullets as fast as it can in Update()... I think its safe to say that at this point the PUGB devs don't have much of a clue about what they do. XD

 

I work on single player only, so I don't care.

 

Timing-critical code in my game is in FixedUpdate. It's not perfect but it allows pretty much everything to remain stable and functional at any frame rate.

My game is set up like this:

Time critical code for gameplay (timing, attacks, physics) - fixedupdate
Animation, everything else - update / late.

To illustrate how robust fixed timestep is, you can jump up and down on the spot from from 1FPS to 100 (It doesn't matter if it's ms or FPS in this conversation) and the character will always reach the same height before falling over the same amount of real world time. Granted, it hits the CPU a lot harder than something relying on deltaTime would, because it's still doing 60 frames internally, per whatever render refresh it can manage.

The trade off is you will spend more CPU time.

 

Assuming both those shots took the same amount of time, the DPS is identical.

Honestly for most games, this is a non problem. The tiny difference in recoil isn't going to make a difference to the average player. This only really comes into play at elite levels.

Unless you are targeting those elite levels, its really not worth the time to fix.

 

Please note that the Recoil pattern is still a big problem as this affects your aim and the accuracy of your burst.

However the image only shows the disparity the videos show the timing difference.

We are talking a competitive E-Sports game with large financial rewards for winners so raising your DPS or lowering it can mean winning and losing a lot of money. e.g. a one bullet difference can change the game.

Actually fixed update would still have the underlying problem DPS would still vary depending on ShotsPerSecond and FixedUpdatesPerSecond only they should be constant across all platforms (assuming FixedUpdate is constant). In other words it would be a feature of the game the developers would be tweaking around and not the variable problem they have with delta time.

 

Cool, it's 100% OK for my game though.

 

I know the gaming community is gonna be up in arms and pissed off about this, if they aren't already.

 

That's still not frame rate independent! On some frames you're going to fire two (or more) simultaneous shots. Is that desirable?

Try writing a bullet hell shooter where you can see streams of bullets and get that to look right.

When you want to shoot, check the time since the last shot. If there is enough time to have fired one or more rounds, check how long ago that round should have been fired, then move the spawn point forwards based on that duration and the projectile's speed (and collision detection), then create your projectile, and update your timing. Repeat until you've caught up with the current time.

 

https://docs.unity3d.com/ScriptReference/Experimental.LowLevel.PlayerLoop.html
And do whatever you want.

 

Good that you solved the problem you raised, nice solution.

Another factor would be the recoil from two shots that would need to be applied, it could look a bit jarring when it moves two or even three shots a frame (low < 30 FPS).

 

Just to clarify for anybody who does not play PUBG and has not watched the videos, the issue is beyond simply problems at low framerates. The issue in PUBG is that guns fire faster when the framerate is a specific multiple relative to the gun's intended firing rate. This is one of the clumsiest bugs in PUBG right now. When the framerate is slightly higher or slightly slower than the magic framerate for each specific gun, then the gun fires slower.

For example, some guns in PUBG shoot faster at 140 FPS than they do at 141 FPS. Others shoot faster at 125 FPS than they do at 146 FPS.

 

Sure, but if that's a thing in your game you need the logic for it anyway, so applying it should be straightforward in most cases.

It'll just be a shaky blur, which is exactly what I'd expect it to look like anyway.

The real question is why is shooting being calculated on clients in the first place? The gun animation makes sense to happen on the client, but projectiles and hits should surely all be done on the server?

 

Because PUBG does not use a traditional animation to manage gun recoil. A really good player will eventually memorize the recoil pattern in games that use a simple recoil animation, and will be able to automatically counter the recoil. With PUBG, the guns react uniquely every time you fire them because the gunplay is managed through client side procedural code instead of simple animations. It is one of the best features of PUBG.

 

Ahh, I was referring to visuals only. Still, if it's an important mechanic that's yet more reason for the server to be involved. There's no reason that a procedural animation couldn't be based on a seed shared between client and server.

The thing is, the server shouldn't be trusting clients with much past user input. It can't trust any mechanic calculations performed by clients.

What's to stop someone writing a hack that just eliminates recoil?

 

Involving the server in the recoil mechanic would add latency to the recoil and make it feel terrible.

Nothing is stopping people from cheating, and some people do cheat. For example, I have seen people use no-recoil cheats, aimbots, and even shoot through buildings without any line of sight in PUBG. It does happen. Thankfully the cheating is fairly rare. And PUBG has an excellent system for viewing the deathcam and reporting cheaters as needed. It is reactive instead of proactive, but it works.

The bottom line is the PUBG devs made choices to make a game with awesome realistic gunplay mechanics, huge maps, and lots of players. It is a very fun experience. In making those choices, those devs decided they needed to run the gunplay entirely on the client side, and they decided that it would be better to allow some cheating in order to have the gunplay feel so nice. Honestly, it was right choice for PUBG. Moving everything to the server side could have reduce opportunity for cheating, but it would have ruined the game.

 

That's what the shared seed is for. There's no need for latency. Both the local machine and the server can calculate the same recoil, so the local machine can animate it correctly and the server can figure out where the projectile should go without relying on the math done by the (untrustable) client.

If they've made the decision that they don't care then that's their choice. But for that bit in particular there definitely is a latency free solution.

 

Pretty much any server side solution to gunplay is going to degrade the overall gameplay in PUBG. The game feels good because it is a freewheeling client side game. I understand the obvious tradeoff regarding cheating, but I will be the first to admit that PUBG is fun to play. PUBG's design choices regarding using client side gunplay actually make the game really fun to play.

 

Specifically talking about a shared seed, I don't think that would work well for PUBG. There are 100 players and all of their guns shoot rapidly. By offloading all of the gunplay calculations to the client side, PUBG can scale. If PUBG cloned all of the player's gunplay calculations to the server side, it would add a lot of workload to the server side. And what would the server do when the client and server calculations did not match for gunplay? Would it kick the player, or would it prevent that bullet from firing? If it did either, it would be jarring to players.

With PUBG, the decision would to give up scalability by trying to prevent cheating, or to just make the game feel great and accept that some people will cheat. I honestly think the devs made the right choice for PUBG, even though it means they have to rely on reactive measures towards cheating.

 

If you can calculate it on the client side then an anti recoil bot can also calculate it negating much of the benefit of putting it on the server in the first place.

Edit: To be clear it does solve the timing issue but not all other related issues.

 

If someone's cheating then they can potentially send whatever messages they want from the client at any time.

Well, a lot of the calculation happens after it has fired if it's "realistic".

Surely the server needs to be authoritative at least for, say, damage and deaths? Because there will definitely be imperfect synchronization between players, so there will be legitimate cases where from A's perspective A can see (and hit) B, but from B's perspective A can not hit them. Even when there's no cheating there are many complex cases to be handled.

 

Yes, an authoritative server would reduce chances for cheating, but the freewheeling client side style of PUBG is more fun to play on. PUBG is very trusting of clients and happily offloads most of the work to clients. Even for damage and deaths, PUBG seems to rely on clients.

 

If I were to manage cheating...I'd just let em' cheat, but make sure I knew when they cheated, then ban them all in a giant batch every six months, then let them repurchase my game for another chance at cheating (and repeating the process!). Sorta like how Blizzard does it. >

 

Do you have any reference about them using a client side authoritative setup instead of server?
I can see where having high fire rates of bullets could have problems for server especially when time between bullets gets in the low ms. And client side logic would help. Especially if bullets are simulated as projectiles and not raycasts like some earlier FPS.

 

well pubg is a huge game that has made millions... doing it right should have been mandatory atleast by the v1.0 release which they used last year as a big announcement.

ofc it could just be a 'feature' that adds to the random bad/good luck of the game, almost like skill doesn't matter as much if you fall within the right fps level, ofc that is giving them way to much credit on coming up with that on purpose when they didn't.. they've left bugs in that game for ages and it seems a lot of it is timing based code that hasn't been done right.

 

Make the game first
@
Think about architecture & cheaters later

 

I have not seen any official posts by the PUBG devs about it, but it is obvious through gameplay how the gunplay is implemented on the client side, especially when studying cheaters using the replay feature in PUBG.

For example, I was playing squads in PUBG with a few friends. We landed at the military base on the original Erangel map in PUBG. We were inside a building fighting another squad that was just outside of our building. Suddenly my squad, the squad we were fighting, and a couple dozen other players nearby all died. I looked through the PUBG replay and found the cheater. The cheater was inside a different building about 200 meters away. The cheater picked up a DP-28, reloaded it, and then spun around in circles firing full auto. The cheater did not have line of sight for any other player, yet the cheater managed to successfully land a one shot head shot on every player in the area. The cheater could not even see another player, yet managed to kill dozens of us in seconds.

I have studied a bunch of examples like that to come to the conclusion that PUBG is doing all of the gunplay on the client side. The PUBG servers don't check if a shot was possible. Cheaters in PUBG can easily kill through multiple buildings without any line of sight.

 

To be completely honest, I would rather have PUBG feel good to play, even if it means needing to endure an occasional cheater.

But the fire rate vs frame rate issue definitely needs to get fixed. Guns fire fire at magic frame rates that are a multiple of the fire rate. That makes guns feel far less smooth at time. And as I mentioned above, it is not just low frame rates slowing down the fire rate. In some cases, guns fire faster at low frame rates. The SCAR fires faster at 125 FPS than it does at 146 FPS. I doubt PUBG did this on purpose. I strongly suspect it is a bug.

 

Lead designer Brendan Green claims his inexperience with programming lead him to create the circular safe areas as he wanted the grid based system seen in the movie Battle Royale. (source)

So was this an indie hit game out of the blue?

 

After asking I searched and found this.
https://steamcommunity.com/games/578080/announcements/detail/1689300456332644145

This seems to make it look like it is server authoritative at least to some degree.
I am not discounting cheaters or their ability to work around either type of authorization.

It mentions shooting and other typical FPS server stuff.
I was thinking even with high rate of fire weapons all you really need to send the server is Trigger pulled, Trigger released. The server can simulate the number of bullets during those time windows. Then if the client is updating the servers state with your input (look direction, movement etc), which can be done at a higher rate from the actual server reply tick rate the server could track high rate of fire guns. (Obviously this would not match your client exactly)

For the previous examples, the only way i think to really have more evidence that the things people see on their clients are real (authoritative) is to compare two sessions looking at the same place. The original picture of the different fire rates based on FPS doesn't mean anything if there is no correlation between two clients, then it is possible its all just client side issues that are not actually affecting the real (authoritative) state.
For instance I would expect it could possibly be the decal locations and bullet tracers to be a client side thing. And may or may not actually match what what is really happening or where they appear on other clients screens.

If it was server side authoritative then I would almost expect that bullets etc on the client would be close but not necessarily match what is happening on the server.

I played PUBG and found it to be pretty buggy and the gun fights very hard to get any good feedback from.
Feeling like on my screen I shot the guy but them not dying, Which seems much more server type of authority.
I also observed other things where my friends are saying they are hitting a guy but on my screen the player is not showing any blood splatter. Again to me seems very server like.

I have not played since they have gone through their major bug fixes though.

But cheaters can find ways to cheat and even if it is server side doesn't mean they did good job of locking things down.

 

Actually there is the issue with Lag in PUBG that highlights the authority of client side shots:

1, Player A with no lag moves behind cover.
2, Player B with lag sees the player outside cover and shoots them.

Player A has the experience of being shot behind cover.

From this you can see that the shooter is Authoritative, not the server or the none lagging player.

 

That's a common behaviour on shooters. Even Overwatch and CS:GO will show the same problem with different degrees based on how much the lag compensation will allow to go back in time.

Here you can see a little old test (Blizzard have made improvements since then) showing this in Overwatch:

The issue is a little deeper and happens even with full authoritative servers. Authoritative on client, P2P with high latency, interpolation, low tick rate, fast movement, etc will make it more evident.

[]'s

 

When did you play PUBG? To their credit, the PUBG devs did finally fix one of the nagging desync bugs in PUBG in recent months. For a long time, there was at least 500-1000ms of desync in PUBG because of a bug in their interpolation code. An attacking player could run around the edge of a building and kill a hiding player before the hiding player even saw the attacking player. That was terrible, and that same bug made it seem like a moving enemy could not be shot sometimes. Anyway, that desync bug was eventually fixed, and PUBG has played a lot better since then.

The desync bug in the PUBG interpolation code was fixed on November 7, 2018:
https://twitter.com/PUBG_Support/status/1060410749581844480

 

Being shot behind cover is actually the main problem with server side authority.
Due to the timing differences between Server, Player, Other Player and how most servers work it will do a rewind in time to check for hits. I believe most new servers limit this time, but yes someone with lag will see other players at different places. And when they fire the server knows where their target was at the time they shot. It will move back the simulation to that point and check for hit.

The player shooting is actually in the future from the server and is seeing the target in the past from the server. Which makes the real position of the person being shot actually total lag in the future from the person shooting. Hence they are behind the wall on their game but getting shown in front of the wall on the shooters.

I am not trying to argue either way but I have always thought PUBG was basically straight basic game for unreal.
They looked a lot of tutorials, bought a bunch of assets.Yes the innovated in several areas of gameplay and then shipped.
But from the quality, bugs etc I would expect their initial networking would work exactly how it would for unreal out of the box. Just under a load of 100 people compared to a more typical 32.

Most new games have bumped their server tick/updates rates into the 60hz range. Looking at the other article i posted PUBG was way low, like 20hz. Which would make the problem you are describing even worse.

 

I mentioned I played before they went on that big campaign about bug fixes etc.
So its has been several months (july maybe). I would assume that a lot issues have been fixed and or changed.

 

Which makes it pretty easy to allow for lag cheating. A cheat bot could wait for the feedback from the server, which gives the enemies precise position, then give the server instructions timed to kill the enemy at their previous position. Basically allowing clients to see forward in time.

 

In our game we have a dynamic delta that is always adjusting for overshoots in time.

 

Apparently the flaw is in Fortnite as well as PUBG probably any Unreal engine FPS weapon system has the same issue.

Article -> https://www.tomshardware.com/news/fortnite-pubg-gameplay-frame-fire-rate-relationship,38496.html

Every Unity shooter example I have seen and code I have written has the same flaw built in to the logic.

It's so easy to forget that real-time games are snapshots in time with gaps between each snapshot.

 

Honestly its not THAT far fetched to have cheaters hacking the server to gain an advantage. Its not impossible, nor improbable. If someone wants to cheat, they will. I mean I recall back in the PlanetSide 1 days a guy bragging about the fact that the developers of the game didn't even know he had an account and so was unbannable! True or not it demonstrates that people can and will hack the game servers to get away with things. I'll bet the guy was stealing service. In fact if a game server uses metrics and stuff to 'check' the client then its an even greater incentive to hack the game server, because otherwise one can't cheat!

 

Surely the issue of gameplay being dependant on framerate isn't inheritantly a multiplayer problem. In multiplayer the worry is some players having an unfair advantage, in single player you are still playing against something - the computer, and framerate dependant code means the game could be artificially easier or harder due to factors outside the players control.

In the worst case certain challenges that pass play testing and game balance on development computers might become hard or down right impossible given certain framerates. I don't understand what it is about a single player game that suggests you can ignore the issue?

 

Made a graph to illustrate the problem the left axis shows how far below the weapons DPS you are based on your FPS, as you can see even at 60+ FPS you can be running with about a 10% disadvantage if your FPS does not align with the weapons rate of fire.

 

In my design(s) guns aren't toys. 1-2 hit and you're dead. And vice versa. The game play does not allow you calculate with DPS at all, if you pull the trigger you better hit the target and kill in max two shots. I don't do war-games.
Lower DPS does not render anything impossible. My designs aren't for the "do stuff as quick as possible, rinse and repeat". This is why I can ignore this issue, it's a non-issue. Maybe it's slightly easier if you have a zillion FPS? Yes, maybe, but probably not. Circumstances matter. If I were building "Call of Duty", sure. But I rather build "Thief" (or CoC: Dark Corners), so who cares?

 

I think you are oversimplifying the issue...

If one player shoots another and their rate of fire is better due to fps then they will win the encounter, without having a fire rate that is time based and not frame rate based you still have the problem.

Even if it's a single player game that single player can be at a disadvantage or advantage compared to enemy characters if there is any difference in rate of fire between weapon types.

Or think of it as a turn based game (every turn is a frame) where some characters will get to shoot first due to their FPS initiative matching their weapons rate of fire.

 

I don't get the logic behind this statement. Why? In my designs (I was referring to) usually the one shoots first is winning the encounter (unless misses, then it will get interesting), but shooting is rare and last resort. So, player shoots with the FPS rate. Enemy is acting with the FPS rate, where is the gap? I don't see it.

 

OK do you accept that if on the second shot player A shoots a frame ahead of player B then player A would win.

That's it in its simplest form a one frame advantage when shooting.

 

Since we are talking about Single Player games, there is no Player B.

 

Player B can be any shooting character with different rate of fire.

Test it put your 'shooters' in a room and get them to attack each other with different rates of fire and at different FPS and see the difference it can make for yourself.

 

I didn't say you can't ignore this, I just pointed out that the reason you stated for feeling you could do so wasn't necessarily valid (not just for you - a bunch of people liked that post souggesting they agreed)

If your game mechanics change significantly based on small flucuations in the frame rate, you have a problem if your game is single or multiplayer (or both) - you're now saying you don't have that problem because your logic tied to frame rate doesn't have a significant effect for reasonable frame rates.

 

Yes, in Single player, when the enemies equally tied to the same frame rate as your shooting mechanic, there is no effect (or minuscule). Since the enemies' actions aren't frame rater independent, if your FPS slows down (so your fire rate), the enemies also slow down with the frame rate. So there is no significant impact on game play.
I don't understand what is the problem or where do I have the flaw in my logic? I was solely talk about Single Player. And if you don't go out of your way and code your enemies FPS-independent but your player FPS-dependent, you don't have a problem. EOS.

(ps: I stated that enemies may have advantage because <30FPS they have, they don't care if the game is sluggish, the player usually does, so they have the advantage)

 

I pointed out the issue the single statement (with no mention of shooting, or type of game, nor consideration of effects): "I work on single player only, so I don't care. "

You do what you want, you've obviously given this some thought and made at least a somewhat informed choice.

I have talked generally, and not mentioned shooting once nor your game's mechanics which I have no knowledge of. In the general case, for a single player game, nothing you have said has addressed my point that having machnics vary with frame rate is still a really bad idea.