Video Games are Lying to You

Added: 2026-05-08

[00:00:00]Ever wonder if the multiplayer game you're playing is really showing you what's happening? What if I told you that everything you're seeing is actually a lie? Yep, that perfect snipe you thought you hit, it didn't even count. If you've ever played Fortnite, Call of Duty, Valorant, or literally any multiplayer game, you've probably noticed some pretty strange moments when the game didn't behave like it should have. It's like the game on your computer tells you one thing, but the server behind the scenes is doing a completely different [music] thing. This is where multiplayer games really start lying to you, and I'm going to break it down for you.

[00:00:31]>> [music] >> See, this should have been a headshot.

[00:00:35]The first lie starts with a technique called client-side prediction. Sounds fancy? Well, client-side prediction is basically where the game does things before they actually happen, as prediction [music] says though.

[00:00:48]I'm sure we've all had a moment when you know you've sprinted in a game, and it looks like you're moving in the game, but you're kind of jittering or not moving at all. This is because your computer is guessing the movement to make it [music] feel instant, when it's not actually instant. But, guess what happens when the server finally updates?

[00:01:04]You end up lagging and looking like you're way behind. This bug is called rubber banding, and it happens when your computer makes a wrong guess, >> [music] >> and teleports the player back to where it actually is in the server.

[00:01:14]It's all one huge illusion. The game makes it look like you're right there, but you're really nowhere where you think you are.

[00:01:20]You see, when you walk or shoot in a multiplayer game, you're not actually moving on your screen.

[00:01:25]>> [music] >> You're sending data to a server in a completely different location, and that server tells your game, called the client, what to show.

[00:01:32]Say you want to move right. Well, you would press the right arrow on your keyboard, or D if you're not a baby.

[00:01:37]Take that, you Gen Z scratchers. If you're on a single player game, the game would detect that you're pressing move right, >> [music] >> and run code to make you move right, and it would update instantly, or well, almost instantly on your screen. But, in a multiplayer game, we have to make sure the players can't cheat. [music] There's a saying that I learned when coding my own multiplayer game, Afterblast, and never trust the client.

[00:01:58][music] So, when you press the right arrow on your keyboard, will first send input to the server to check and make sure that it's [music] valid, and make sure you're not trying to press the right arrow 100 times in a second to teleport. Then, after the server says, "Yeah, [music] that guy ain't cheating." The server will end up giving your client the go ahead to finally move [music] to the right.

[00:02:17]That means there's always a delay between what you're doing on your client and what the server has you doing, because messages on your computer and the server, which could be hundreds or even thousands of miles apart, are not instant.

[00:02:29]The farther you live from the server, the more noticeable the delay will be.

[00:02:33]>> [music] >> Which is why multiplayer games have servers all around the country. This also makes sure you never [music] have too much latency. To cover up latency, games use tricks like interpolation, where the server guesses where you should be, and then moves the client to that position while the server is still validating the movement. It all gets really complicated the more you dive into it, which is the rabbit hole that I had to face. So, when you miss that headshot, yeah, you can finally have an excuse to blame it on the lag. Now, here's when programmers really lie to you.

[00:03:03]Bullet hit registration. Have you ever had moments when you know you shot someone, and the bullet goes right through them, even though you know it shouldn't have hit? You're not crazy.

[00:03:12]That's the server bugging out.

[00:03:14]When you shoot, your game calculates where the bullet hits based on what you see on your screen, but the server is calculating something entirely different. Remember, you can never trust the client. So, your client is going to say you shot here, but the server is going to say, "Nope, you didn't actually aim there." The game server is always a few frames behind the player, whether you have 0 milliseconds of latency because you literally live inside of the game servers, or 1,000 milliseconds because you live out in the middle of nowhere in Australia. That's what ping measures, how long it takes for a message of information, or a packet, to send from your computer to the server.

[00:03:49]So, that means the bullet is hitting the server's version of the world, not the one you're seeing on your screen. That's why sometimes you end up getting hit even before enemies can see you, and also why sometimes you hit blank shots.

[00:04:01]So, what happens when the server glitches out? Things like rubber banding, where you teleport [music] back to where you were, or ghosting, where you see enemies who've already moved, but the game shows standing completely still.

[00:04:13]So, what did I do? I made the mistake of building my own multiplayer system to test it all out, and see how deep it really went. And let me tell you, things broke [music] in ways I never could have expected.

[00:04:24]Wait, what?

[00:04:26]If you watched the last video where I was working on Afterblast, you could see that the game just didn't look very fun.

[00:04:30]The movement just felt stiff and unnatural, and the game felt like it had no purpose. So, I made a couple of changes. First, I moved the camera from a third-person view to [music] a first-person. And with the first-person camera view, it already felt way more immersive and fun to play. I don't know, there's just something about FPS games that make them feel way more fun. I've also been wanting to add another mechanic to [music] the game for a long time, because Afterblast has just been a normal third-person shooter game. If I wanted my game to be a hit, I needed something unique and original to make it stand out. I couldn't think of a unique for the life of me, but then someone in the comments suggested that I add parkour movement to the game. So, I decided to add wall running and wall jumping. Now, normally, coding in wall running would be pretty easy. When the player is running and pressed up against the wall, all I have to do is make the player stick to the wall. But, since I have a multiplayer game, it's 10 times harder. So, first I coded in the player to stick to the wall when it detected that there was one nearby. It worked a little bit, but the player would spaz out sometimes, like the wall running code only worked half of the time. It took me almost 2 weeks of moving around code to figure out why the wall running wasn't working. I tried putting the wall run function inside of late update.

[00:05:38]Nope, that didn't work. I tried putting inside of fixed update. That didn't work either. I tried commenting out all the other movement code to see if it was that that was causing the jittering.

[00:05:47]Nope. After scrolling through a multiplayer Discord server, I found a guy who was having the same issue as me.

[00:05:52]He was creating movement for his game, and it was having the same jitter problem. And the way he fixed it was by syncing the variable from the update function and putting inside of the replicate. I I put it I made it so that it pans on the head bones.

[00:06:05]So, like you can hear Yeah, except it it's not it's not great. It's kind of messed up. Why am I holding the gun like this? I don't know.

[00:06:14]>> I was trying to fix it the whole time.

[00:06:16]The body just glitches, and it only happens when like only when I upload the server when there's other people in there. You're holding like three guns. I don't know why it's like that. Where's the circle?

[00:06:31]We're back. We're back. Where we Where Just where did you go?

[00:06:36]Stop bumping into me. Oh, there you go.

[00:06:39]Okay.

[00:06:40]Yo, what is this?

[00:06:42]Dude, what happens when you shoot?

[00:06:43]>> He shoots.

[00:06:44]Yeah. Does it Does it No, you killed yourself. Let's just say you never appreciate how bad it is to code a multiplayer game, and how good multiplayer games have it when everything works out, until you're [music] the one coding them. So, after all the failures, I learned a ton.

[00:07:06]Multiplayer is way harder to get right than most players can even begin to realize.

[00:07:10]But, after a bunch of tweaking and improving, I finally got a pretty decent system going for Afterblast. [screaming] So, what did we learn in today's video?

[00:07:18]Multiplayer games lie to you every single second, probably even every single frame. And as a game developer, you can now see how much math, tricks, and fake magic it takes to make it all seem real. But, honestly, I kind of love that about video games. They don't have to be perfect. They just have to feel real.

[00:07:37]If you liked this breakdown, don't forget to hit subscribe and leave a comment. What's the craziest multiplayer bug you've ever seen? Thanks for watching, and I'll see you in another video.