Some bugs can be very hard to encounter.
Imagine I’m programming a boss fight. At the end of the fight, if the player has more than 50% of his life left, I play a big celebration animation. If the player has less than 50%, I play a more somber animation. I test my code ; it works flawlessly.
I ship my game. The vast majority of players go through the fight fine, but some players experience a weird bug where nothing happens after the fight and the game soft locks.
Those players ended the fight with exactly 50% of their life left. There was a bug in my logic that was highly conditional and hard to spot.
Maybe not ELI5, but I think you can handle it
Imagine the code has something like dividing by x or taking the square root of x. You might play and everything will go well, but then your friend does something and suddenly x=0 and 1/x crashes, or x<0 and sqrt(x) crashes
The bug is there for everyone, and if you do the same thing with the same computer at the same time and reproduce everything revenant, you’ll see it too. This is why when you report a bug is important not only to screenshot the glitched out screen, but also describe what you did to get that problem and what computer you have. There are many many variables that interact in many many ways, and bugs might be difficult to get (which is why they weren’t fixed before the game was released. The devs didn’t know the bug existed)
Imagine you‘re playing Chess.
Imagine there is a bug in Chess that IF the white king is standing on C5 and white rook is standing on F7 AND its blacks turn and whites king gets checked by a black bishop from G2, then suddenly and unexpectedly the board is gonna combust.
Now have 1 million chess matches from players all around the world. How many boards do you think are gonna go up in flames?
Game code is an set of complicated instruction (that spans to thousands of branchig if this than that kinda situation).
Due to the huge amount of branching of possibilities, there will be a set of choices that might lead to unexpected outcome that they did not handled.
+++++++++
Game also has to operate within numerous amount of different environment (that is your pc).
Some of this environment is simply better for the game compared to the others (due to them being more tested and its hard to test on all known combination of used hardware that is recommended for the game)
Think about twins. They both share the same player code (DNA) but ultimately end up in different states in life (the game world) based on their unique qualities and decisions. One may even get cancer and die before the other because they were exposed to more radiation. The analogy is such that your DNA represents your game code and bugs represent undesired consequences of your unique path in that game (life).
When you play a game, you download a piece of software that we’ll refer to as the game client. The game client is written in some higher level programming language(s) like C and Lua and compiled down into assembly code containing a long list of instructions to your CPU, also called the instruction set. This instruction set is like a maze with a set of paths and waypoints. There is only one entrance and any number of exits. A waypoint contains a single card (instruction) that you read and execute (as the CPU).
Outside of the maze are various buckets storing apples. Some of the buckets reset for each attempt made at the maze (RAM). Other buckets don’t reset (hard drive). Each bucket has an ID.
Now, if you zoom out, there are many mazes (programs) all sharing the same bucket store. Many of the mazes have dedicated bucket stores, and generally the maze manager (the operating system kennel — which is the parent maze) keeps everything separate and organized, but contamination can happen by faulty or malicious instructions.
When you are attempting the maze, you make one move at a time based on some input from the operator. You’re just the CPU, so you don’t make any decisions, you only execute instructions. Examples of these instructions involve adding apples to a bucket, emptying a bucket, counting what’s in a bucket and doing arithmetic, copying the contents of buckets between each other, etc.
Your instruction can also teleport you to another point in the maze. In fact, you started in the parent maze (the OS) and have now wandered into one of the smaller mazes (a program). Lastly, some instructions have a surprise (also called a bug), they can teleport you to the wrong place or give you an instruction you can’t actually do, like:
*add more apples than the bucket can hold (buffer overflow)*
*work on the wrong bucket (memory address error)*
*do impossible arithmetic (divide by zero)*
*or teleport back and forth forever (infinite loop)*
Imagine now that each operator has a unique decision tree. If the operator attempts a particular maze many times, you will find yourself taking very distinct paths through that maze and having a distinct apple store state at any point (since each instruction can alter the apple store and your operator is randomizing the selection of those instructions). And as we explained above, some combination of those instructions can lead to an undesired state.
On top of that, you have cosmic rays randomly zapping certain buckets of apples and changing their contents and you have malicious mazes built by bad actors ill intent on taking over the parent maze (the OS).
Simply put, two reasons:
1. While the code is the same, outside of consoles everyone is playing on completely different hardware and software. Your version of windows is different than my version of windows because you’ve installed and done different things. Your CPU is doing different tasks in the background at different times than mine, etc.
2. Your gameplay state is not the same as mine. Maybe you played for one minute and twelve seconds before you ran into the buggy wall, but I played for one minute and thirteen seconds, and this bug only triggers if the playtime ends in a two.
Games are played on millions of computers with many different combinations of hardware. Any sort of other processes may also be running on that hardware and certain bugs only occur under very specific circumstances. What this basically means is that even though the game is essentially the same for everyone the reality is that the conditions under which it’s running may be wildly different.
Let’s suppose that you like the color red, and I like the color blue. Therefore, you tend to dress your character in reds, whereas I tend to dress mine in blue.
Now let’s suppose that a dev wrote some code that caused an NPC to react slightly differently to someone wearing red, perhaps compliment the player on their color choice.
Now let’s suppose there is a bug in the code around that specific dialog.
Me, wearing mostly blue, would not trigger that dialog, and so I wouldn’t encounter the bug.
You, wearing at least some red, would trigger that dialog, so you would encounter the bug.
Latest Answers