Randomness in Video Games | Compilation | Extra Credits Gaming

Welcome to Unnamed Game Show we won't name for trademark reasons. The game where you the player can win fabulous prizes or a goat. Now, behind one of these doors is a Half-Life 3 beta key. Ooh. And behind the other two is, you guessed it, goats. So, pick a door, any door, and what's behind it is your prize. Okay, since I can't actually hear you because this is a gag in a YouTube video, I'm going to assume that you picked door number one. But before we show you your fate, I'm also going to reveal what was behind door number three. It's a goat. Getting nervous? Well, I'll let you switch to door number two if you'd like. Go ahead. Take a moment. What's the right move?

Well, if you're talking about shaving, the correct answer will always be a handsome razor, but more on that after the episode. Ready to have your mind blown? You should always switch. But why and how that's relevant to video games we'll get to in a moment because that little exaggerated example up top was the famous Monty Hall problem, a brain teaser loosely based on the game show Let's Make a Deal which Monty originally hosted. And now that I've finished with my very poor impersonation of that, I'll explain the problem a little more robustly. Imagine a game where players are offered to pick between three doors. One of them has a good prize behind it and the other two have duds. When a player picks a door, the game, knowing what's behind all three doors, immediately opens one of the other doors they didn't pick to reveal a dud. And then the game asks if the player wants to change their choice. In this situation, the game always reveals a dud and there's no attempt by the game to trick the player. So, what should the player do? Setting aside the fact we kind of already spoiled that one, most people's immediate gut answer is probably something like, "Well, it doesn't really matter because I got a 50/50 chance either way." And that was

certainly my answer at first, but it's actually incorrect. The truth is, the player should always switch doors. Why is this, you ask? Well, there's actually a lot of ways of looking at this, so let's run through them. The first is just to enumerate all the possibilities. So, for the sake of argument, let's say you picked door number one. In that situation, there's only three possible outcomes. Possibility number one, door one is the prize and door two and three are duds. Possibility two, door two is the prize and door one and three are duds. Or possibility three, door three is the prize and door one and two are duds. In possibility one, you win if you stay, but in possibility two and three, you win if you switch. So, you've actually got a 2/3 chance to win by switching, but only a 1/3 chance to win by keeping your original pick. Because as counterintuitive as it seems, the player's winning chance depends solely on whether they've initially picked the prize. And whatever the odds are of initially picking the prize is, their odds of winning by switching are its

inverse. But here's a simpler way of looking at it. Let's say instead of going through all of that rigmarole of having the game reveal a door, it just offered you a simpler choice while all the doors were closed. Let's say you picked door number one and the game then offered you the option of opening both doors two and three instead. Because that's actually what's happening under the hood. It's just obfuscated by the mechanics that are layered on top of it. If that was how it was phrased and you knew the game wasn't trying to trick you and that the prize was randomly distributed, you'd immediately go, "Of course I'll take doors two and three." And if you don't believe me that that's how it works under the surface, let's try imagining this with a thousand doors, where like in the original example, all but one unpicked door ends up revealed. You start by picking a door and the game says you can either keep that one or have the other 999 doors. It's pretty easy to pick what to do here as it's clearly not a 50/50 choice. So, why does this matter when we're designing games? Why is the Monty Hall problem important? Well, because humans are both great and terrible at

probability. And how good or bad we are at it in any given case depends as much on human psychology and how the probability problems are presented as it does the problems themselves. As designers, it's vital to understand that and use it in our design. Sometimes this can be to make simple problems more interesting or play on the player's desires. For example, critical hits play on our desire for power, making us feel like a mighty hero getting lucky, even though from a design perspective, in 90% of games, crits are pretty easy to convert to a straight damage formula and balance against. Let's say for the sake of argument, your character hits for 100 damage, but 10% of the time you do double damage. Behind the scenes, we're just balancing enemy health as if you're doing 110 damage with every swing. Even more humorously, investing in your character's critical damage skills in many games is sub-optimal because any overage damage is useless. If you hit an enemy that has five health with 100 points of damage, you're just wasting 95% of the attack. And if you put all of

your resources into critical hits, so that you're normally doing something along the lines of two damage, but on occasion hitting for 100, you're strictly worse versus a five health enemy than if you'd set yourself up to just hit for five consistently. But as often, this idea that humans understand probability differently depending on how it's presented is also essential for what James calls design UX. Good designers make their design easily parsable by human beings so that players can focus on making the interesting decisions that come out of the design rather than making blind guesses at how the design actually works, or worse still, operating under a completely false understanding of the design. Now, that doesn't always mean you want to make your design as straightforward as possible. After all, game shows that use things like the Monty Hall problem are much more exciting for everyone because no one knows the right decision to make in the moment. And so, making the decision to switch or not feels full of peril. So, it's important to realize where the engagement comes from in your design, and only make your design deceptive or obtuse when the suspense of

a blind guess is more thrilling than trying to make the most rational choice. In the Monty Hall example, the engagement comes from wrestling with how to make the best decision, so that decision is abstracted and made more complicated. However, we know that in many games probability estimates aren't really where the fun comes in. They're just there to make larger systems work, leading us right back to the idea of understanding the psychology of your players as they approach a probability problem in your game. Because when we Monty Hall it up, it's not the probability problem itself that's engaging. It's how it makes you feel. Is it supposed to make you feel nervous? You could lose everything by picking the wrong door. Is it supposed to make you feel hopeful? Okay, the situation looks dire, but if you can just win this coin flip, maybe you've got a chance. Is it supposed to make you feel powerful by giving you the possibility of high rolling all the way. BOO-YAH, NATURAL 20. SO, when you next look at probability problems in a game you're designing, remember clarity when you want to make the player think, obfuscation when you want to make the player feel. That's the real lesson of

the Monty Hall problem. If you would all be so kind to quickly follow me down this rabbit hole real quick. Picture yourself trying to kill a few minutes in a waiting room. So, you pull out your phone or laptop and open up Solitaire. Now, in that moment, do you start to feel like Captain Kirk? Well, you should. Because just like the infamous Kobayashi Maru scenario from Star Trek, there's a chance right now that you've been dealt a hand that is entirely unwinnable. So, let's take a second and examine something that we often take for granted when we sit down to play a game. The idea that it can be won. Recently, our illustrious EC streamer Will has been playing a lot of Slay the Spire at Ascension 20 over on our Twitch channel, which you totally should go check out via the link below after the episode because it's fun as heck. And he's been musing a fair bit over the way that the game makes itself harder, and whether or not all of those increases in difficulty make some runs of the game unwinnable. Is it possible that from before you begin your first fight,

you're doomed to failure? And if so, does that make the game any less worth playing? Now, before we dive in, let's go over some terminology just to be sure that we're all using the same words to describe the same phenomenon. When I say a game is unwinnable, I mean that there's no set of player-generated moves and randomness that will allow the player to achieve victory. No matter what you do, no matter how many times you reload and try, you won't be able to win. It's pretty easy to establish you can end up in an unwinnable state in the middle of a game of Solitaire or Spire, and we can also work backwards from there to show that it's possible, no matter what set of moves you make, that you'll end up in a similar or even identical position and be doomed. In the case of Solitaire, the randomness is locked in once you shuffle and deal the tableau of cards onto the table. And from the very beginning of any hand of Klondike, the most popular form of Solitaire in the US and Canada, there's a 21% chance that the game isn't winnable. No matter what series of moves you make, you can't fulfill the victory conditions by placing all the cards in rank order in their suited piles. And Slay the Spire is actually kind of the

same. Though it's harder to see in Spire, every possible move is determined before you start. This is also, of course, a problem unique to randomly generated games. Because if we could test each and every seed or position during the design process, it would be possible to eliminate this fear entirely. But that's never really going to happen because the very strength of randomly generated content is that it lets designers gain an extraordinary amount of possibilities without doing a ton of manually checked work. So, with all that said, is this the problem that even needs to be solved? Is the possibility of us not being able to win really ruining our enjoyment of games that rely on randomness to generate a scenario for us to play through. Well, I don't think so. Though to be fair, I don't know if that's the right question that I just asked myself. Because games with no win situations, like solitaire, are enjoyed by a ton of people. Some of whom might not even know that unwinnable deals even exist. So, rather than debate the validity of doom scenarios in games, I think it would be much more interesting to take a look at the different ways we as players can approach this kind of loss. And we're

going to do that by boldly going back to a place we visited before the intro. Because one possible philosophy that is applicable here is given to us by Captain Kirk. And another one by Captain Jean-Luc Picard. Kirk rejects the notion that there's such thing as a no win scenario. Therefore, when running the Starfleet test simulation, the Kobayashi Maru, where he's forced into choosing to go on a rescue mission designed for him to have no winnable outcome, he simply hacks the test and changes the situation for the better in order to fit and to prove his outlook is correct. But looking past whether or not you think that might be cheating, does this outlook really teach us anything? If our approach to losing is changing the conditions of the game or the test, do we really learn anything from our struggle? Sure, we accomplish something that looks like a win. But then we're no longer playing the same game that we were when we started. Plus, you know, if Kirk had been in that scenario IRL, his crew and all the folks he was trying to rescue would have been super dead. A different outlook is one outlined by Jean-Luc Picard in the next generation

episode Peak Performance. Lieutenant Commander Data, an android, begins to doubt his abilities following a loss in a strategy game to a much more experienced player. When Captain Picard tells Data, "It is possible to commit no mistakes and still lose. That is not a weakness. That is life." What he's saying here is that we need to be able to accept that some challenges are beyond our reach and that losing to them doesn't define us. What matters is that we've tested ourself against the challenge and as long as we've learned something from that loss, it isn't a wasted experience. Okay, but fun Star Trek examples aside, in both games and life, we're going to encounter situations where we just can't win. In games, you have the option to step away, to restart and try again from a fresh save if you need to. If you stick with a no-win scenario, however, you might learn something about yourself that you can use in your life. You can begin to understand what happens when you're confronted with something that's out of your control. Because in life, sometimes you're going to lose, no matter what you do, no matter how hard you try. And while sometimes it's not fair, you can't

let that define you. So, that ability to predict how we'll feel, how we'll react to those situations, should be the real lesson that we're after when we take on challenges that we know can't be won. Thanks for indulging us in this little roundabout discussion to get to a sort of life lesson. That was fun. But what do you think about no-win scenarios? Is their existence in games a hindrance, an opportunity for personal reflection, or something else entirely? Let us know in the comments section below. Oh, and one last thing. If you're interested in talking more about Spire, winnable games, or learning from failure, then may I suggest you go over and engage with us over on Twitch. And be sure to tell Will, Darmok and Jalad are most certainly at Tanagra. Save scumming, as it's commonly known, is the practice of saving just before making a risky move in a game, and then reloading it until either the RNG gods are forever in your favor, or you know all of the information that was supposed to be hidden, like exactly where the enemies are, for instance, in order to

get the perfect result. Some players decry it, while other players say it's inevitable and embrace it. But the real question is, how do we design around it? As designers, one of our goals is always to make our games engaging. And you know what's not engaging? Reloading your game 10 times and doing the same move over and over and over again until you happen to get a critical hit. And yet, if that's the optimum play pattern, especially if there's things at stake like character permadeath, hitting some achievement, or unlocking some new powers or equipment, players are going to feel like they have to do it. And those that refuse to play the save and reload game are going to feel punished for not doing so. But before we talk about how to design around this behavior, we should discuss the question that rages on fan forums everywhere. Is this behavior cheating? As a designer, James kind of doesn't believe in the concept of cheating in single-player games, and I'm right there with him. You're playing a single-player game for you. So in that case, play them

any way you find satisfying. Now, does saving and reloading all the time go against the designer's intent? I mean, yeah, maybe. But you also don't have to read a book in the exact way the author intended for you to get the most out of it. So doing away with the idea that save scumming is inherently bad or makes you a bad person for doing it, we're going to focus on how to keep your game engaging if it encourages that type of behavior. But what type of games do encourage this type of behavior? Well, we've already touched on it a bit, but really, it's any game that has all of the following to some degree. Randomness or hidden information, which makes it possible to change the outcome of an action if you reload your save, an incentive to reload your save, such as better rewards or better clear times, and it needs to be the sort of game where you can realistically anticipate and save before events you might want to try over and over again. And if your game has all three of those things, there's still one last ingredient it's going to need to create an environment where players will reload over and over again in search of the best result. A generous save system. Getting rid of any

of the other parts will eliminate save scumming as a player behavior, but if you want all of those other component parts in your game, namely randomness and reward for optimal performance, then the easiest way to keep players from save scumming is restricting when they can save. And relying on a robust infrequent auto save system and not allowing players to save freely can cure your game of save scumming and is a good start. However, restricting where players can save leads to other problems, especially in strategy games where this most frequently comes up. Because no one wants to play 20 minutes of a game, much less 3 hours of one, only to find out that they lost due to a move somewhere in the middle of that time. And now they have to start all over again. Which means, if your game only saves between missions or battles and your battles run long, you're setting your players up for frustration. This can be alleviated by essentially having restore points in your save system, where your game auto saves every move, as well as whenever the player exits the game. But also holds on to a

library of saves that are visible to the player that are just far enough apart to discourage reloading. The most interesting option though, if you're thinking about it from the outset of your design, is to have metrics in your game which vaguely indicate the player's chance of success in a scenario. In a strategy game, it might be comparing the total value of all the players' units and equipment to the total value of the enemies' units and equipment. Or in an RPG, it could be something as simple as comparing HP and MP totals. And then using that information to have the game itself pick the save to reload when the player loses. The game would still be saving after every move, or in real-time games after short intervals. But those saves would be invisible to the player. And instead, at the game over screen, it would ask the player, "Would you like to try again from here?" and show a screenshot of when things were still firmly in the player's favor. This takes saving and reloading out of the player's hands, but still gives them a non-frustrating place to restart from. Hey, but what if you don't care? That's right. What if you are 100% on board

with save scumming and everything that entails? Well, then there's a different sort of design you have to do. You have to think about your game holistically to make this process enjoyable. For instance, you could do something small and cheeky, like what Undertale did by changing the dialogue of characters if you reload a save in order to change the outcome of an event. But on a larger scale, if the joy of the game is actually in always performing optimally, in uncovering all of the hidden information, and then utilizing that to find the best answer to whatever challenge the game has presented you, then save scumming itself is actually the intended play pattern, which can be very cool. But understand that as a designer, if that's what you're building for, you're essentially building a puzzle game. It may have the trappings of a strategy game or an RPG, and it may even use their mechanics. But conceptually, as the designer, you have to think of each move and each scenario as a puzzle. It's really a cool way of thinking. I mean, for an example of this, just take a look at all of the

awesome puzzle modes digital card games have presented us. I mean, that's essentially auto save scumming right there, because there's usually a save state of a single turn that reloads if you don't win. So, is save scumming bad? I don't know. Is broccoli bad? I mean, they're both kind of personal choices, but what we're saying here is if unplanned for, the type of design that can lead to save scumming can create an erroneous task that every player feels like they have to do, and can really drag down the pace of your game. But like most other elements of design, if you know your game encourages this behavior, you can just think around it and make it as positive for the player as possible. Actually, Zoey, I think I can do that last line better. Let's take it back. And make it as positive for the player as possible. No, that was game showy. Okay, hold on. Re- reload, reload, reload. And make it as badass for the player as possible. What am I in a biker gang? Hold on. Re- rewind, do it again. Yee has lo lo mas positivo posible para

el jugador. Duh, that might have been better if I actually spoke Spanish. Thanks for nothing, Google Translate. One more time, we got this. And make it as positive for the player as possible. Nailed it. Zoe, show me the score. All right. I mean, it's the internet, so I guess that's an S ranking. WHEN IS RNG TOO much RNG? It's one of the most fundamental questions in game design. Yet, try as he might, James has never found any book or article that gave a good answer. Every discussion about it seems to fall back on either play test or do what your gut tells you. And while play testing is always a good idea, as we start to formalize game design, we can't just have that be the default answer for everything we don't know. So, today, we're going to pretentiously present Portnow's postulate. The simplest version of it reads, player frustration with RNG

equals time lost multiplied by the percentage chance of losing that time. At the highest level, this formula can serve as a simple gut check. A better way to think about what your intuition as a designer is telling you. And while you could go into infinite depth to find the exact numbers for these variables, and if you're working on a $200 million project, it's probably worth a few hours trying to nail these down. But, most of the designers I know are looking for a more quick and dirty system that will give them a loose way to compare games and see if theirs has a higher than average RNG frustration cost. Small side note, when using quick and dirty exercises like this, it means you're usually going to have to just make an educated guess about how much time is lost by losing a game due to RNG, and then throw in an approximation for how often RNG causes losses. This is always going to be inaccurate, but it forces you to do something perhaps even more important than run the formula itself. To think about the real-time costs of

losing your game. So, with all that said, let's take a look at three games through the lens of this method. Slay the Spire, Hearthstone, and roulette. Starting with Hearthstone, let's say 25% of the time losses are due to RNG. And let's say that Hearthstone games are about 10 minutes long. This gives us a player frustration number of 2.5. But actually wait, that's not correct. Cuz what happens when you lose a ranked game of Hearthstone? Not only do you not gain anything, you also lose one game's worth of progress. So, when thinking this through, the true time loss number for losing is 20 minutes, not 10. This makes RNG losses much more frustrating and leaves us with a player frustration number of five. Next, let's talk about Slay the Spire. Examining it with this algorithm forces us as designers to immediately recognize the fact that this game has wildly variable game length. A death before the first boss may only take 10 minutes,

whereas if you die on the final boss, you're probably an hour in. This equation also makes it clear to us that the further you get, i.e. the more time you've sunk in, the less randomness should play a determining factor. After all, losing a 1-hour game due to drawing a hand with no blocks is a lot more frustrating than losing a 10-minute one. But let's look at this practically. Let's say you were making Slay the Spire and you found a frustration level you felt your players could bear. How would you maintain that across the whole game? By trying to have progression reduce randomness over the course of play. Let's say you wanted the game to have a player frustration level of seven throughout the game. Well, 20 minutes in, that means that RNG can cause the player to lose 35% of the time. But by the time they get to that last boss an hour in, only 11.7 of the games should actually be lost due to RNG and any other loss should just be due to poor play. Which makes a deck building roguelike a good choice for Slay the

Spire, as the core systems of the game, both roguelikes and deck building, actively reduce randomness as gameplay time increases. It's one of their strengths. So, now let's talk roulette. Let's say you're betting on red. Roughly 53% of the time you're going to lose due to RNG. Note that even though this is a pure luck game, we only care about how often you're losing because only losses cause player frustration. Let's say a spin of roulette takes maybe a minute to play out. So, player frustration equals 0.53 multiplied by 1. I.e., you have a player frustration number of 0.53. That's pretty low. Great. Except, we can't calculate time here that way because the key factor in roulette is the wager. So, let's say the player is making a $20 wager. We have to convert that wager into the time it took that player to earn that $20. So, this bet is going to be 10 times more frustrating for someone earning $20 an hour than some whale that makes 200 an hour. But,

there's also weird mitigating factors to games that have an explicit wager. And that's the possibility of gaining time. Our brains don't usually attribute a Hearthstone win to luck. And when they do, it does little to take the sting out of that next game where you can't pull a card that costs less than seven for your life. But, that's not true in wager games. In wager games, how much the player has won or lost is actually what impacts their frustration level. So, in those type of games, we have to subtract the chance of winning from the chance of losing and multiply it by the amount the player would win. So, in this case, we have the player basically putting an hour of their time on the table. So, we take 60 minutes and multiply it by the chance of losing, 53%, minus the chance of winning, 47%, times the payout divided by the bet. Since in roulette the payout for betting on red is usually one to one, the whole equation can be boiled down to 60 minutes the bet times 0.06 or a 3.6

frustration level. For our whale's frustration level, it'll be a minuscule 0.36. I bring this up because it has interesting implications for microtransaction games. Let's jump back to Hearthstone. An arena run has radically variable time cost for players based on how they perceive 150 gold. Here, there are basically three types of players. The first type is the player who is mostly focused on the constructed game. So, they just earn gold as they play and occasionally use it for an arena run. To these players, the time cost on losing an arena run is barely more than the time they put into the arena itself. They'll find losses due to RNG in arena the least frustrating. Then there's the players who pay a $1.99 in real money for an arena run. To them, the additional time cost is whatever it takes to earn around two bucks. So, for our person earning $20 an hour, that's an additional six minutes of time invest, whereas for someone earning $10 an hour, it's an additional 12 minutes.

The frustration level here will be higher, but not as high as the next category, the grinder. This is the player who only wants to play arena, but either for cost reasons or as a point of pride won't put in real money. Instead, they earn the currency required to do their arena run through playing parts of the game they might not necessarily like. For these players, every minute they do this is a minute you have to add to your time lost calculation. Of course, it's mitigated by the gold they earn back at the end of a run, but these players tend to be the ones that have the highest level of frustration due to RNG. And in many microtransaction games, they're going to be the majority of your players. So, as a designer, you always have to keep this in mind. Most importantly though, none of this is to say that you shouldn't use randomness. Playing around the RNG, thinking of how to control the RNG and tip it in your favor can be one of the most interesting strategic elements a designer can present a player. Also, none of this is absolute. None of it will tell you how

much frustration your players can actually take. Different genres have different player expectations for frustration and player frustration tolerance can be influenced by all the non-RNG aspects of your game. Portnow's postulate is just a lens for looking at your decisions. It can help you think around the problems and realize the levers that you, as a designer, have to play with. Because in the end, RNG isn't bad. It just has to be used well. After all, a situation being hopeless is a lot less engaging than a situation being a long shot. Of course, there are certain things you never want to leave to chance, right? Like the narration voice you adjust to better match your old YouTube videos or the razor that you want to shave with. I don't have to tell you that buying razors these days kind of sucks, right? Because the big companies that make the quadruple bladed moisture strip coated gimmick infused nonsense cartridges are just doing so so they can jack up the price of the thing they know you're going to have to buy over and over and over again. Fun!

Capitalism for the win or whatever. But, let's look beyond all that nonsense and look more toward what the real goal of shaving is. Sure, to remove unwanted hair, that's a given. But, I would posit it's also to not wreck your skin while doing it. Just nicks and cuts and toilet paper and But, thanks to Henson Shaving, that is a fear of the past because they've taken their expertise at designing precision things for stuff like the Mars rover and the ISS and turned it towards making my weekly shaving routine more healthy and precise than ever and in turn, helping me avoid vampires. They're not going for it anymore. Just get out of here. Henson has crafted a precision engineered safety razor designed to hold the blade at exactly the optimal angle of 30° from your skin. Combine that with how securely the blade is held with no wobble and how minimally the blade is exposed and it truly takes the guesswork out of getting a super close shave. Plus, since the replacement blades are only 10 cents each, you end up saving so much money in the long term. Seriously, I'm still going through the box I got from Henson last time we did a read for them, and I'm only like halfway through.

It's crazy. It They last forever. Not really forever. You get the a long time. They last a long, long time. And actually, Zoey just told me that right now, we can shave a little extra off for you. Because if you go to the link below, then throw one of their handles in a cool color plus 100 blades into your cart, do you know what happens, Ozo? If they use the code EXTRA CREDITS at checkout, those 100 blades that cost them goes down to zero. Zero! That means they got 100 blades, like a year's worth of shaving blades, absolutely free. I It's crazy, I know. So, for a skin-friendly shave, click right here, and then once you're feeling smooth, slide on over to our next video here. I got to tell you, Akuyakoi, Joseph Blame, Izzy Coin, Hunter Z, Fox Doc, Dominic Valenciana, Arclight Games, and Angela Valenciana are just the best legendary patrons.