Lesson 7: Randomness
In this lesson, we explore the role of randomness in games, distinguishing between input and output randomness. The discussion emphasizes balancing randomness to maintain fairness and enhance player satisfaction, sometimes even tweaking probabilities in the player’s favor to foster a sense of achievement and prevent frustration.
Lesson 7 Transcript
So what I want to talk to you about in this design talk is randomness in games.
Now we already implemented some randomness in our snake game, and I think that just makes it better. It’s more interesting and that way the game is more fun to play over and over.
But what kinds of randomness are there? Is it always good? Is it always bad if you’re a pessimist? And how often should you be using it?
So there are two primary types of randomness that are agreed upon in games, and that is called output randomness and input Randomness. Now, the two of them are kind of on a spectrum as they play with each other, depending on how heavy you use one over the other. But you can think of input randomness as the player has no control.
So if you’re starting a game where a map is procedurally generated like Minecraft or civilization, that is input randomness, you had no control over it, the name is kind of deceiving, you had no control over it, and now you have to deal with it.
You have to strategize around it. Sometimes the whole game is based around how you can deal with that input randomness.
And then output randomness, on the other hand, is when you make a decision that is not guaranteed, such as shooting in excom where you have a percentage or making a role where you play a card, and it has the ability that it might hit a player, a 50% chance.
That is, you are taking action and you have a chance to succeed. It’s not guaranteed. So input randomness, you have no say over the game, actually input it and do something and then you react to it.
Output is from us, the player. So those are the two types of randomness that you’ll find when you start talking about it in video games.
So is one better than the other, and is randomness good or bad in general?
And that question is kind of deceiving because depending on your experience and your feelings and how you like to play and make games, you’ll have different feelings about randomness.
And in some cases, you might not want any randomness in your game because it doesn’t call for it. If you’re doing a story-driven RPG, then you probably don’t want randomness in your game, or at least in the combat section because you want your players to always know that what they do is going to work.
But if you’re doing a strategy game or a game that involves a lot of luck, such as a board game where you have to roll dice, and things like that, then randomness is required.
And if you take that away, you take away a big part of that game. Now it’s not always a bad thing if you’ve ever played risk, you can understand the frustration of randomness when rolling dice.
Now you take that away and you essentially have the underworld another board game where it’s very similar to risk except that when you attack, if you have more
Troops, then you win. There’s no randomness at all. So taking it away can create something entirely new that isn’t good or bad either.
So using them is the key to it. Doing too much or too little one or the other can lead to a bad experience. So not every game needs randomness, but when you have it, you want to make sure that it’s fair to the player.
So a lot of times in games you’ll actually end up what is called, but in video games you’ll also often find that randomness isn’t actually what it says on the screen. You’ll often find that programmers actually tip it in the player’s favor.
So something that excom does is if you take a lot of shots and you miss them, it’ll actually make the next couple shots more likely to hit than what it actually says.
Because as humans, it’s really important for us to feel that the game is fair, which we’re going to spend a lot of time talking about fairness and what that is and how exactly to implement that in games.
But if we are supposed to make a hit when we take a shot in a game and it says 87% and we miss, that’s frustrating.
If we take another 87% shot and we miss again, then we start feeling like the game is unfair. So developers will often tip it in the player’s favor and make it more likely to hit if they’ve had failures recently.
So in that case, it’s not as much as a random as it is kind of cheating the system to make the game feel fair, but it still feels, or at least it looks random. And we’re much happier when we get that.
And a side note on randomness is that it’s always better to play into the player’s favor. So if you wanted to have a system where they make random actions, then it’s okay if you weigh it in the player’s favor because the player will always be happy if something works for them.
When it seems kind of risky, they’ll be much happier if that happens. And they’re not going to complain if they take a risky shot or they play a risky card and it pans out. That’s great. And that’s really all I want to say about it.
We’ve talked about it quite a bit and I think you should have a much better understanding of it now. Randomness can be great and if you want to use it, do it. Just make sure you test it out plenty before you ship your final product so that you don’t upset a lot of players.
In the next video, I want to have another talk about what makes up a game. What are the essential components to a game, and does the game we just made have that? Let’s talk about it next.
Lesson 8: What Is A Game
In this lesson, Aaron discusses the evolving definition of what constitutes a “game,” acknowledging the blurred lines between traditional games with set rules and win/loss conditions and modern, experience-based games that prioritize player engagement and exploration.
Lesson 8 Transcript
So here’s a question for you. What exactly is a game?
How would you define it to someone who has never played a game, not just a video game, but just like a game in general?
What are the requirements that distinguish a form of activity that is a game from not a game?
It’s kind of a blurry line and it’s gotten even blurrier in recent years with many games becoming more of an experience. Things that we thought were required to be a video game or a game in general. A lot of games have come out and said, no, we don’t want to stick to that.
We’re going to do our own thing. So you may have heard of some of these games. They are more experience-based. A lot of times there’s no combat.
Sometimes there are no real mechanics besides just moving around and reading things, and they can still be extremely engaging and fun to play.
So we have to broaden our definition of what a game is. It used to be that a game was something that you would play, had strict rules, you could win or lose, and then some other things mixed in there.
But from a super-wide, broad view, it’s more like a game is just something that you can do with your time and you can enjoy it. So with a super loose definition like that, as a game designer, you have a lot more freedom now.
So anything that you want to create, any kind of experience that you want the player to have will probably be considered a game. And because of that, as a game designer, you now have the freedom and the flexibility to do whatever you desire.
Now for traditional games, like the ones we are going to create, a game is going to consist of rules, and mechanics that the player can do in a win and loss condition.
So they’re going to be fairly traditional in that sense. You’re going to go from one level to the next. There’s going to be some combat, and then eventually you’ll be able to beat it or you’ll be killed and you’ll have to restart.
That’s what a game usually is and still normally consists of. So if you’re going to make a traditional game that is not just an experience for the player, you’re going to want to keep those things in mind.
The win-and-loss conditions are going to be important. The mechanics that the player has are essential for how they play it and what they get to experience it.
And so right now is both a great and kind of a terrifying time to be a game designer. You have total freedom in what you get to make, and pretty much everyone will consider it a game as long as it produces some kind of experience for the player.
But that being said, you also have a lot of pressure to produce that experience, something that is memorable, exciting, and engaging.
So if you know what you want to make, focus on that experience. Sometimes that experience will come from reading, text, hearing people talk, or challenging the player with doing specific actions, critically thinking, or solving puzzles.
There are so many different ways to engage the player and give them an experience that you really have total freedom when it comes to designing your games, which is really, really cool.
But what we’re going to tackle next is the ability to lose your game, because still, that’s an important aspect. You need to be able to win or you need to be able to lose sometimes both.
But at the very least, you need to be able to lose, which is what most endless runners games these days have is that you can lose. So we’re going to look at implementing that in our snake game next.
Lesson 9: Losing The Game
In this lesson, you’ll learn how to create a barrier in our game using a new sprite called SPR_block, which ends the game if the player collides with it, enhancing the game’s difficulty and engagement level.
Lesson 9 Transcript
So now that we understand how to lose and win, let’s look at implementing a way to lose this game.
So we want to create a block that basically acts as a barrier, and if you run into it, you die. So let’s make a new Sprite.
We’re going to call this S P R block, and we’re just going to fill this up. We’re going to first change it to 32 by 32. Then we’re going to fill it up with Red Press F for the fill tool and voila. And there we go.
Then we’re going to make an object called O B J Block, and we’ll assign it to Sprite. Let’s come into the room. Let’s make sure we’re on our instances layer, and let’s drag in a block and side note.
If you do anything with these layers and you move them around, or you accidentally close one, you can come up to the room and reset windows on the current desktop and set everything back to the way it was originally.
You can do that everywhere as well.
So in a room that pops up in a workspace, it disappears. But in images, if we come in here, you can see that there are contextual menus here, so you can reset all of that kind of stuff. So that’s helpful to know.
So let’s place a block and now let’s come over here. And what we could do is then place more blocks all the way around, but that would be a lot of blocks and a lot of time. Instead, we can actually stretch these.
So I’m just going to grab the bottom of this and pull it and make one long red block, and then I’m going to control C to copy, control V to paste, and then I have a second block that I’m going to put over there.
Then I’m going to grab one more block, place it up top, and do the same thing.
You can stretch it once it’s there, once you see that little icon, and just pull it across. Copy, paste, and voila. Now we have a barrier inside of our game, so if we run it, we’ll see that all the way around the edges, and that looks really good.
Now we want to make it so that when we run into this block, we die. And when we die, we lose the game. And because we want it to be fast-paced, we want it to keep trying. We’re just going to restart immediately as soon as we die.
The way to do that is by using a function actually called Game Restart. So let’s add an event collision with the snake. So if we collide with the snake at all, we are going to restart the game. And the function is called game restart.
It doesn’t take any arguments and it just does exactly what it says it does. So for speed of testing, I’m going to pull this guy right over here, press F5, and now I’m going to move up a little bit. I’m going
To come over and bam, the game just restarts immediately. And that’s exactly what we want.
So depending on how much we’ve done and how much score we have, it doesn’t really matter, but we’re playing. We hit a block and then we die. And that makes it, well, essentially, a game.
We have a goal, we can achieve that goal through our skill, and then we can lose and we can keep playing when that happens. So this is, although not a fun one, it is essentially a complete game.
Now, there’s still a lot to do because right now the player knows how many foods they’ve collected. Well, assuming they can keep track if they start doing really well, but the game is really boring.
If we look at it, we have just a snake and a food and a barrier, which is all we need, but we need to do more with it. Currently, we don’t go any faster.
We don’t see our score because we’re not actually keeping track of it inside of our game. So there’s a lot that we can still do to make it more interesting and definitely more fun.
So in the next one, let’s look at adding more of a challenge to our game and making it more fun to play.
GameMaker Studio 2 – Module 3: Attack of the Snake
- Lesson 1 – Breaking Down Snake
- Lesson 2 – Creating Our Snake
- Lesson 3 – Comments
- Lesson 4 – Snake Food
- Lesson 5 – What Are Functions
- Lesson 6 – Creating New Food
- Lesson 7 – Randomness
- Lesson 8 – What Is A Game
- Lesson 9 – Losing The Game
- Lesson 10 – Adding Difficulty
- Lesson 11 – Game Difficulty
- Lesson 12 – Game Expectations
- Lesson 13 – Adding A Score
- Lesson 14 – Sharing Your Game