pretty much

@@garbaj interestingly, while games like csgo use time stamps to verify who clicked their mouse first irl in a fight, games like dead by daylight have tried multiple iterations. Time stamp based, attack favored, and defense favored, and eventually landed on a solution where the defender gets priority unless more than a certain amount of irl time has passed.

@@FostFauxOld cs whoshotfirst also determined by who got into the server first.. i think there's a 3klikphilip video about how impossible it is for 2 players to die at the same time..

No there's loads of trade-off to choose between when designing an FPS game's networking. You can accept a shot that was fired by the peek'ee, after the peek'er shot them (in the peek'er's view), if that shot was faster on the draw from the peek'ee. Some games do rewinding to insert events into the past on the server & interpolation of other players on the client (Counter Strike model), others do rewinding to insert events into the past on the client & extrapolation of other players on the client (Doom 3 model). Others are completely different (P2P / hybrid P2P+server have shifting timelines instead of a server-authoritative timeline). If you know the gameplay advantages/disadvantages you want to avoid, you can design your architecture appropriately... But you'll probably end up having to accept a painful situation elsewhere 😑

Sadly there's not really anything that can be done about it. There's always going to be latency in online games, not just FPS games, no way around it.

same

thanks, glad you found it easy to understand!

I hope you are still yet to attend high school. If you already have a programing background while not knowing this (or not being able to reason and figure it out yourself), this job is not for you, or at least you have LONG road ahead of yourself. I have met people not having any idea about basic things like this at college (like one time professor asking another student "what would you liken a raycast algorythm to, consider shooter games hint hint" and he could not figure out its alomst as same as hitscan algorythm). 95% of topics covered by this channel are very basic stuff that any programmer should have understanding of, even if not knowing how to implement it step by step.

@@jakubmatousek9429 agreed, though i think ray casting isnt inherently hitscan.

Game dev is a horrible career

It’s impossible to solve this issue unless you also solve the light speed limit

@@Max-zi5wx It's not about light speed...

@@azertyuiopqsdfghjklm Because it’s about LUDICROUS SPEED

@@azertyuiopqsdfghjklm But it is, even with perfect netcode you still have to account for the distance between the player and the server

@@azertyuiopqsdfghjklm the internet has lag because of the delay between hops, not the lightspeed of a single connection. In fact, I had a commercial fiber optics like and my ping was 5ms at the distance of almost 700km in a single continuous fiber. It used a literal fiber optic duct put on the highway that was 700km in distance to the first hop. It had like 32 pairs of multi-mode optical fibers, and it was super expensive, like $20K/mo to get your own gateway BGP routing through that. 5ms is almost like LAN, I could have LAN parties separated by 700km with a friend in the state capital and the city I was living in the countryside (is that misuse of the corporate network? yep, it is, did anyone ever discovered I did that, no, perfect crime, I just used it for Overwatch, its tiny the amount of data that games use). That's what is the speed of light, that 5ms can't be subtracted because its the literal time the light spend traveling in the tube, aka 3.5ms, plus 1.5ms in the routers, because the router's circuits and CPU actually spend some time.

Hahahahahahahahahahahahahahahahahaha

An elegant yet simple solution!

i need to learn how to implement this in my projects... it will BE REVOLUTIONARY

I find this solution brilliant but I can only imagine the moral implications of this 😂

@@maulidonda we would change the definition of *life itself* forever and you're worried about the moral implications of a human TAS?

Meanwhile GTA V 10 years later: Peer to peer

@@koresaliva i dont know if you know this. But their peer to peer service has actually opened up a vile channel of hackers to abuse against randoms. It's arguably the worst implemented system of peer to peer i think anyone's ever seen from a "AAA studio". Its gotten so bad that people havw been doxxed or had their entire computer routed.

it's fuckin scary, man you have to develop the entire game with the server in mind

Yeah there's a reason you hear a lot of complaints about games with bad netcode. Writing good netcode can be extremely tough. Honestly it gets so complicated most of the time companies don't even want to risk touching it and screwing it up.

That's called a demo

I had no idea about that. That's really smart

@@someweeb3650 yep, I forgot the name for it

Trackmania actually stores both transforms and inputs, but only the transforms are used when *displaying* replays. Inputs are stored for the purpose of replay validation - this can be used to check if the replay was made using a cheated client, but they are not used when displaying the replay. This prevents replays from breaking after game updates that alter physics in any way (however, the validation will fail if using a recent client). I'd say storing *only* inputs in a replay file is a bad idea, since it's very easy to accidentally make a game change that breaks all replays - either by updating a level or any gameplay code. There are commercially released games out there that were released with demo loops that desync :) This is also why most modern Doom source ports can't play back the original demo loop, since vanilla demos only contain inputs. Modern source ports have made subtle changes that affect gameplay, intentionally or not.

Not only that but it also allowed for the fanbase to detect any cheating in the speedruns by seeing the inputs and checking for any signs of slow down since the verification method cannot catch that After all slow down "technically" isnt cheating... At least to the game

(I got confused at first when I searched "Gabriel Gambetta" here. Turns out the guide is a blog article, and not a video here on UKposts. XD )

@@novikovPrinciple oh yeah, forgot to mention it But its a great post on this topic with a nice interactive example to show how it works

This is also why Sniper doesn't need line-of-sight to kill you

I appreciate the video recommendation

youre forgetting brain lag. while my computer could have an outstanding 15ms ping, it unfortunately doesn't make up for my brain lagging 500ms behind

1. Many deaths are actually unfair due to lag, currently. If you hide behind a corner, the server has the right to un-hide you and say "you got hit before that!", which is decidedly unfair from the dead player's perspective. 2. It's nice when there is somethin inanimate to blame. I know a few games that can either use a little bit of randomness or a mode where the player knows everything in advance (in some it's damage values, in some it's a generated map/landscape) - turns out most people enjoy it more when not literally all mistakes are their fault. It's quite crushing to realise your faults and I'd rather have a loud friend than a depressed one.

The lag can't be fixed per se, it can only be reduced to very small unnoticeable amounts of time, because for it to be fixed information would have to travel instantaneously which is not possible even in the real world.

Deaths based on your movement, are at a high probability of being lag related though. An action such as crouching can easily take 60ms to get to the server at time .02s. If your head is shot at the time of .05s by another player, but has 15ms ping, the shot will hit you before your crouch has reached the server. Even if you did crouch before the other player pulled the trigger, the trigger pull reached the server first with better ping at that moment. Which gives the oppressor an advantage. We folks often send inputs to servers within fractions of a second at the same time as each other. Which means very frequent mistakes such as that based on ping. This is why peekers advantage exists. You can move into a room and shoot, but nobody, not even the server, knows you just walked in there. But after the server gets this info late, it trusts your movement is legal, and allows the shots to hit successfully. Even if nobody in that room ever saw you walk in. Movement is very sensitive in networked games.

some lag will always exist. because the speed of light is the limit. it takes light 130 milliseconds to circle the planet ( and that doesn't take into account any back and forth processing). there is a reason that each region has there own server. the laws off physics means we can never eliminate lag, but we can definitely reduce it a lot on local region servers

Sadly never going to happen

That’s not possible because information cannot travel faster than the speed of light. Or more accurately, the speed of causality

@@jacobdaniels3246 in a collapsing entangled state separated by huge distance, causality is going faster than light but information isnt

You can't transmit data through quantum entanglement

@@azertyuiopqsdfghjklm I know 😭

@@Ale4D 😭

Most people just call this peeker's advantage. It refers to the fact that the guy peeking around the corner can see you before you see them. This happens because their screen is projecting what's on the other side before the server gets the info, while your screen only puts the player on it when the server tells you he's rounded the corner. This gives the character in motion an advantage compared to the person standing still.

Can you tell me what fps game use Rollback netcode? I want to see how it play

Can you tell me what fps game use Rollback netcode? I want to see how it play

@@duyngo7697 From what I remember correclty, Quake already had its own implementation of a Rollback Netcode, since it prevented the input response to happen just moments later. I think Battlefield and Call of Duty also use their own implementation of Rollback, the connection in most of their games are quite good.

Surprised I haven’t seen any other mentions of rollback. Lots of modern fighting games basically do not need to deal with lag anymore if both players are using a wired connection

that made no sense to me whatsoever.

@@3u-n3ma_r1-c0 basically on a quantum level, particles behave differently, as in, they are both positive and negative, until something observe them, in which they suddenly become either "positive" or "negative". Now substitute "positive" with "on" and "negative" with "off" and now imagine a light being both "on" and "off" at the same time and when you enter the room it chooses to either be "on" or "off" and you see its result. Now substitute "on" and "off" with "dead" or "not dead" and now you can imagine it better, the server will end up calculating both results and in the server the player is in both states, and when its time to get the result, thats when, in the actual game, you get to see if you died or lived. (Much more complicated than that, but thats a rough idea that should fully or at least partly be right)

@@3u-n3ma_r1-c0 what the person above me said. Schrödinger's Cat is the most famous example used to teach this concept. The cat is simultaneously Alive and Dead inside of the box, and until the Box is opened, we have no way of knowing which one it is. In the above example, the player is the one who is simultaneously dead and alive until the SERVER opens the box.

@@pxldeath3561 Theres a reason quantum finishes were controversial when added to horse racing, the results tended to change when observed.

than*

What are you on about, rollback netcode has been the standard in shooters for decades now (since Quake iirc) while it's only just now becoming more common in fighting games. Fighting games as a genre are a joke in terms of the tech, content and monetization, they're literally a solid decade behind other genres because the devs are greedy fucks and fg consumers are dumb enough to pay $60 + $20 per season pass for the same re-released pile of shit with slightly improved graphics every 4 years for three decades.

@@Nothyn kid I doubt you’ve ever really PLAYED a good fighting game just from hearing you shit on the entire genre. What are YOU on about? Greed isn’t a fighting-game-exclusive thing. In fact, it’s far more prominent in FPS genres. Plus, fighting games aren’t about graphics. Too much emphasis on graphics reduces performance. FGs are about technical execution, mindgames, and competition. Rollback is only just now seeing the light of day in FGs because it’s so damn hard to implement in games where every, single, frame, matters.

@@Nothyn This is a garbage take on fighting games. You should take into consideration that the shooter genre has a much larger audience and budget than fighting games. Additionally, popular fighting games are masterpieces of game design and animation and might require a lot more work than you might think. Often times online multiplayer functionalities suffer as a result. Fighting games are best played locally anyway.

@@Nothyn bro they play for its mechanics not graphics🤭.

I doubt it, since it requires knowing what that specific human will do in that specific situation. Just the action og changing direction while running can mess with what can feasibly be predicted.

@@gimballock2084 yeah, I'm not talking about a basic setup on the server you could do today. I assume in 10 years, maybe more, it's feasible from a computing power and storage perspective to, for example, collect, store, and train a ML model on the movements of every single player, predicting from both thier history and other plays who act similarly. In a rigid, predictable environment like a shooter my guess is that people are fairly predictable with enough info. Broadly, it becomes a question of the complexity of the model- a simple one with incomplete data wouldn't work very well, but if the game could create a perfect replica of your brain and run it in the same situation, it would always know exactly what you were about to do. Realistically in 10 years, maybe the game can be right 90% of the time, combined with other existing and new more conventional tricks it could significantly improve the experience.

@@rancidmarshmallow4468 A small FPS drop and the resulting delayed input recognition from the game would get them out of sync and destroy the whole system, without the player doing anything different.

Video title : why is this card radioactive?!?!

And how is syncing time helpful? You still wait for the packet to arrive.

@@GonziHere Because you can send the time as part of the packet, so at least the server knows exactly how long of a delay to compensate for. So for example, it could build a model of not only where it thinks everyone is now, but where it _knows_ everyone was exactly .1 second ago now that all the packets have finished coming in from that moment, and undo any hits that it thought were successful based on the intel it had at the time but actually weren't.

Maybe OW's prediction algorithm wasn't designed with high ping in mind, so once you reach a certain threshold, the servers get confused. There could also be server-side issues where the servers themselves throw artifacts. Packet loss is also something that might cause this. Imagine if the server saw you run forward, and then there was 2000ms of no consistent information coming from your end due to packet loss and whatnot. The server then might assume that you have been running in a straight line for the past 2 seconds, and rubberband you a mile forward. Just my guess

^ Yeah to combat lag spikes, the server keeps a buffer of inputs it can play from. If you get a lag spike that's really bad, the server runs out of inputs to play and extrapolates based on the last move (so if you were going forward, you keep on going forward). Also, when the server sends back a correction to a player position, usually that comes with a time stamp. Since the player is "predicting" ahead of the server instead of only snapping to the correct position and experiencing a large rubber band, it replays all the predicted inputs since that correction time stamp, which typically minimizes the rubber band to something unnoticeable. However, if you're lagging really hard, the server might be predicting something completely different from what your client is predicting, resulting in you teleporting "randomly"

To me what you are experiencing also sounds like the packages that contain your input might be getting lost before reaching the server, thus making you overshoot every input that actually reaches it. Rather than just slow connection, might probably be a matter of package loss as well.

@@RookieSnow Yeah you're totally right, I forgot to mention packet loss

client: *sends a packet stating a button is being held down* server: *receives the packet, starts moving your character* *lag is happening* client: *sends a packet stating the button is no longer being held down* *due to lag the packet was never been sent or being ignored by the server because of timestamp or smth else* server: *keeps moving your character because as far as the server is concerned, you're still holding that button down* client: "MOVE THE CHARACTER ERRATICALLY!!"

its essentially the same principle though, with in peer to peer one player acting essentially as a server for the rest of the players

@@bowmanruto but also the rest of the peers are servers as well, it's complicated. With non-platform fighthing games it's a bit easier because they're 1v1. There is also an increased complexity in the snapping itself, as shooters don't particularly care if the player appears in frame 1 of the walking animation, or frame 13

It's entirely different. He is wrong, since (most) FPS are NOT deterministic, so your real position is updated from the server at all times (and hopefully the corrections are miniscule). Rollback works, because fighting games actually are deterministic and because you can easily simulate several steps of physics of the game in one frame (since it's two guys on a plane, not 32 players, 60 bullets and complex geometry).

Another factor is that these games use their proprietary tools which suck ass.

Lag has nothing to do with the amount of data (mostly), the issue is the information literally has to travel, and even at the speed of light that is not insignificant as far as games go. If we could send information around the world perfectly at the speed of light we'd still have about ~133ms worse case ping. If we could direct line through the earth there would still be ~85ms of ping worse case. Even in the future real world pings will probably always be worse than this as it will probably never be a perfect straight-line, there will probably still be delay from routing and processing along the way, and the information will probably never be travelling at 100% speed of light.

Your example is also false. Unreal is deterministic, but because of physic ticks being unstable, it comes up with different results. The results are still deterministic, because there is no random element to these results at all. It's simply a different deterministic output decided by the length of the dynamic length physics ticks based on your example.

@@SioxerNikita I mean, that's exactly what I said. Deterministic only if you take away the highly random nature of the tick (and also, you forgot that different platforms can treat floats differently, so even on a fixed physics tick it's not necessarily cross platform deterministic). If the engine is only deterministic when you do some work to ensure that an inherent random element is removed, the engine is not deterministic at its base. Usually when a developer wants to rely on determinism in Unreal (or unity), they switch the physics engine to Bullet. And when cross platform determinism is needed, floats are replaced with fixed point numbers.

@@benwillms1899 Yes, some platforms can, although floats are pretty much set in specific formats these days. But the point is that it is technically deterministic, which it is, but you are right on the caveat that it requires consistent ticks.

@@benwillms1899 Most modern CPUs and all modern operating systems use the same floating point standards right now and calculate them the same, floating points are only "nondeterministic" in the sense of a predictable human result where 0.1+0.2 == 0.3, (also yes I understand that these would not be accurate representations of the true value in floating point, these are just the rough approximations we can easily read in decimal) but that's not because they won't constantly make the same result, but because humans don't easily understand binary floating point because it must violate common rules of decimal systems to function. This is where the concept of "floating point inaccuracies" come in, its not that they're inaccurate to calculate a value, on pretty much every system you run a program the floating point numbers will become the same, its that they're not accurate to their decimal representations to such a degree of a common epsilon. This is because floating points such are only being represented as decimals and inherently are making a mathematical guess, we can only be sure of a floating point number most of the time by rounding it to a general epsilon, which in extreme cases will change as the difference between two distinct values will become more pronounced. This is in fact what causes issues like Minecraft's Farlands bug, (or in some games if you record world position as an absolute to the camera instead of being relative to it then you can get strange graphical behavior like meshes breaking or even draw buffers being screwed up) where the the difference between the epsilon grows as the floating point itself grows resulting in things like the epsilon eventually even being capable of becoming larger then 1 where in Minecraft that results in calculations being screwed up and producing some of the strange behavior. Thing is this is all still massively deterministic and could be known so long as you feel the need to calculate it. (from what I recall this is solved, aside from using a more "accurate" type, there's likely few techniques to correct it without too much of a cost of performance) Something similar happens as numbers get smaller (without reaching zero) as well, the epsilon will basically only end up supporting a limit of significant digits before it becomes junk "digits". But those junk "digits" will be consistent even across platforms.

@@Spartan322 when working with floats, it is generally recognized that determinism can be achieved on the same architecture and with the same compiler. Compilers can choose to optimize things in different ways, resulting in the same program having slightly different instructions to reach the "same" result. If the differing instructions touch floats, different "errors" can accumulate. This is where fixed point numbers come in.

that seems like it should work in 3d as well, but I wonder how the small changes in speed would feel in first person perspective.

I think most client-side prediction algorithms already do this - it's called bounding. Quake 3 certainly does for instance, and I still consider it to be one of the better implementations of client-side movement prediction out there. That, and smoothly correcting prediction errors over time instead of correcting them instantly.

Titanfall 2 canon

Isn't that just Tracer?

I don't think so, even now in most places you can play games with little to no issues caused by network lag, even on mobile networks.

@@Hietakissa what i meant and want is to play with low latency with others even if they are in the other side of the world .

the example shown at the beginning of the video where the player directly controls the server side character is probably the best ''short term'' fix, its essentially what stadia tried to do and its failure shows the hurdles to this solution... however client side prediction basically allows for this already, when you have incredibly low latency (say 5-10 ms) to the server, the client side prediction is basically meaningless as it updates often enough that the users and the servers are basically in constant alignment already, which makes me wonder when client-side prediction will become a user toggle-able setting, have it on and you get a lag free experience but with the chance of rubber banding, have it off and there's a chance you might have input lag

@@CoolSs I guess even that could be possible relatively soon as 5G rolls out more, probably when 6G comes along at the very latest.

@@Hietakissa i really want that to become a reality. there is so many . i mean so many cool game on steam that died just because people who interested in it are in different places around the globe . yes this technology will be beneficial for normal game but also will make other game live longer . and even games with small community will thrive because of it .

My town has fibre all around, but I still suffer from 300ms ping because their routing is so god awful

@@PixyEm sorry I should have said fibre everywhere plus competent ISPs lol

I have FTTH and my ping is still 15-20ms.

Thanks for the explanation 👍

The problem is that when this happens you actually teleport on all the other players screens, leading you to be extremely difficult for them to shoot because your motion is no longer smooth. According to them you'd just be warping around. And that assumes the person isn't actively creating this effect through a cheat. Rubberbanding effectively ensures that the lagger doesn't get an advantage.

yeah this works as long as the client sends their predicted position to the server, in which the server can track the distance between the server and client predictions and only rubberband once they don't match by a certain amount, otherwise the server will just trust the client's sent position

having to wait for each one IS the problem

Plus in some games, you don't snap to where you should have been according to the server, there is a smoothing period to make the correction gentle and less jarring. This only takes place on the client and is just a visual thing.