The Secret to Good Game Iteration

Hello, and welcome to my talk called The Secret to Good Game Iteration. I'm gonna be talking about game design, more specifically, game iteration and prototyping and how to iterate on your game properly, and how to run your playtest smoothly and that.

If you don't know what any of those big scary words mean, don't worry about that, because we're also going to talk about that at the beginning of this talk.

But first, hello my name is Tamta Satyani, I'm a game developer from Georgia, the country not the state. I've been working on games for five years now, and five years ago is when I created my YouTube channel where I talk about game dev. And I also recently co-created a game dev team here in Georgia called CEDA, and we make small, innovative games, or at least we try to.

Quick overview of the game development process. Before you make a game, you must make a prototype, which is a minimum version of your game that you can make quickly to test out your game idea. The way you make your prototype is, first you design it, so you come up with the rules for your game and the mechanics and all those things, and then you implement it, whether on paper or you make a digital prototype. Generally, you should try to make a paper prototype if possible, but sometimes that is just not viable with some game mechanics, and so you must make a digital prototype. Then you playtest your prototype. Usually, first playtest is done by the developers, or the developer, if there is only one. Then you analyze the results of your playtest. How did the playtest feel? Did the game feel as it tended to? Usually, the answer during the first playtest is no. You design your game again, you change some things about it, and then you implement those changes. You playtest again, and analyze again and again. This process of designing and analyzing and changing is called the iteration loop, and you're iterating on your game when you're doing this.

Then, after quite a few iterations, you finally come up with a prototype that you like, and you then continue making the actual game. You're done with the prototype phase. But today, we are going to be talking about this prototype iteration loop. When you go through a couple iteration loops, at some point you want somebody that is not a developer to play test your game. Because you need an outsider's perspective on it. You might feel very good about your game and you might like everything about it. But it might not be as good for somebody who hasn't worked on it for hours. And to make sure that your prototypes run smoothly, invite a person or a group of people and test your prototype ahead of time to make sure everything is in order. If it's a digital prototype, make sure that there are no game breaking bugs. And if it is a paper prototype, make sure that no key components are missing. Which is usually very easy to fix with paper prototypes. Take the pressure off of the playtesters. Make sure that they understand that they are very important and vital to the design process.

And without them, you wouldn't be able to make this game. Which is true, playtesters are very important for game designers. And also, don't shame your playtesters. And don't get frustrated with them. I've had my students get really frustrated with game designers and I've had... not game designers, the playtesters. And I've had a student think that a playtester is messing with them by pretending to not understand the rules. Which is... which was not the case then and is usually not the case. It's just that things that seem obvious to you because you made the game don't seem so obvious to playtesters because they have no idea about your game.

Try to be a silent observer and not interfere with the testing process because you're not going to be there for every single player, right. When your game comes out, you're not going to be able to sit in front of everybody and explain to them how your game works. So you have to really check and see how your game will do in the real world. A playtest is the best way to do that, so you should not interfere, you should not give any hints. Sometimes when a playtester is really stuck in some place, you might give them a small hint. But do note that you should then work on that area to make sure that a player can still go through that area without the hint. Also, don't make your playtesters wait too long.

So if you're inviting a few groups of people, a good arrangement that works for us for example, is that we usually invite people with a buffer that is twice as long as we think the prototyping of a single game will take. So for example, we think that prototyping this game for this person or this group once will take one hour and we invite people two hours apart. This also gives us a chance to rearrange the pieces and get everything ready for the next group in case... you know, just to get ready for them. And we usually don't have to wait because too long for the next group because play tests usually take longer than you'd expect, especially for inexperienced game designers. You might think your game takes one hour to play and then it takes an hour and a half to play. Also, make sure that why we're doing this in the first place is that if you make the play testers way too long, they might get tired or bored or hungry and then that interferes with the design process. So you're not sure anymore if your play testers weren't happy because your game was bad or was it because they were hungry and angry and cranky and wanted to go home at that point. Also, I'd advise to have some drinks, cold drinks, water first of all, but also maybe some soda, it's where you're play testing and maybe also just some light snacks and play test with your target audience.

So for example, if you are intending to make a game, if your game is intended for 10 year olds, you should get a group of 10 year olds to play test your game. During and after play tests, we should analyze how the test went. During the play test is the most crucial, the most important part, because the live reaction of your play tester never lies. Your play tester, you might ask questions about things later, if you're not sure why they did or didn't do something.

But people have false memories and they have biases, so that method isn't always reliable. So the best way to tell what your play tester is feeling and thinking is watching them carefully as they play the game. Are they stuck on a level too long? Are they confused? Did they get scared by the jump scare? Did they think it was funny? Those are the kinds of things that you should look out for.

And if you're not sure about something, you can ask questions, but ask the correct questions. So for example, your play tester skipped a door on level 1. You shouldn't ask, did you notice the door at level 1 and didn't want to go through it? Or did you not notice at all? Because your question prompts the answer. And the play tester might want to impress you and say, oh, yeah, I noticed the door, but I didn't go through it. They might be compelled to answer like that. Instead, you should say something like, okay, level 1, tell me about everything that you saw and thought. What was your thought process while going through level 1? And if they noticed the door, they might mention it. They might have noticed the door but thought it was insignificant and then they also won't mention it. So, yeah, this is basically don't try to make an option or an answer more appealing, which is a hard thing to do when asking playtesters questions because we are very biased on our own games as well, just as playtesters are biased and we kind of want them to give us specific answers to take a game in specific directions but you have to try and be as objective as possible if you want your game to be the best version of itself.

Also, remember that you want the playtesters' problems and not their solutions, but you shouldn't let them know about it. So what do I mean by wanting the problems and not the solutions? So first of all, for example if your playtester says didn't like the boss with the scythe and you should remove it. That means that you should absolutely do something about the boss with the scythe, but you don't necessarily have to remove it. Maybe the boss' tutorial is just confusing and you need to work on the boss' tutorial. Maybe the boss should be nerfed instead of removed. Maybe there's some other factors in play. You should pay attention to the gameplay process, but also you should ask the tester some leading questions like why do you feel like that? What specifically did you feel when playing through the boss? Maybe the boss has some specific mechanic that makes it annoying and you should take that behavior out? Or maybe you should change that behavior and reprogram it in a way? Basically, there is no shortage of ideas for game designers. You will probably come up with a thousand better solutions than your playtester will. So you don't need their solutions but you do need their problems because you will definitely overlook problems with your games. But don't let the playtesters know about this because you shouldn't be arrogant with your playtesters. You shouldn't take them for granted. You shouldn't say oh don't tell me your problems. Your problems don't matter. Your input doesn't matter. You should make them feel good about it. Good about the playtest. Good about the game. You should make them feel like they contributed because maybe they'll want to playtest again, which is again what we want.

Because playtesters are very important and we really really need them. They're crucial during the design of a game. The urge to over complicate. So if you're mechanic, if your prototype is boring, there's usually an urge to pile on new game mechanics on top of the existing ones, because the thought process is that if there's more things to do in my game, then it will be more fun. But piling mechanics onto a boring game usually doesn't fix it. And piling more mechanics onto an awkward and tedious game definitely won't fix it. Because more things to do doesn't equal more fun.

A good example of this is, we all know the game Rock, Paper, Scissors, and there's a variation of it called Rock, Paper, Scissors, Lizard Spock, I believe, where it is just same Rock, Paper, Scissors but there's more symbols to make with your hands and those symbols beat each other the same way that in Rock, Paper, Scissors this one beats that one and that one beats this one. And it doesn't really add any gameplay it's just more signs to make. There's no new gameplay in Rock, Paper, Scissors, Lizard, Spock as opposed to Rock, Paper, Scissors. So, yeah. Just piling on new mechanics does not solve your problems. Instead, you should make your design more cohesive. So, different parts of the design should be more interconnected, and you should make the different game mechanics intersect and work with each other in interesting ways to create what is called a game dynamic. Also, you should make your existing mechanics more enjoyable. For example, if walking in your game is boring, don't add an option to fly, but think about how you can make walking fun. For example, yeah.

This is usually done with rapid playtesting, which rapid playtesting is when you have a bunch of just a huge list of ideas of how to fix something, and you implement them quickly, and you play test all of them as quickly as possible. For example, in the case of walking is boring, what can we do about walking? We can change the camera zoom, change the camera position, change the camera turn speed, change the smoothness of the camera, change the smoothness of the player movement, change the speed of the player movement, et cetera, et cetera, et cetera, change the feel of the player movement. There are so many things we can do about it, and we should test all of these ways to find what is the best way of making this mechanic fun, in our case walking. And if you don't find the solution, rapid playtesting will usually at least get you in the right direction. Okay, so when my camera is smooth, it's kind of fun, but how can we make this even more fun? How can we, maybe we can completely transform the game to make it just instead of a third person walking simulator it can be a, you know, just a little spirit looking around the room, with a smooth camera, or something along the lines of that.

A personal example of what I just described is when we, Alteida, we're working on our current game, Beast of Colchis, which is a board game, a 1v1 board game, where the heroes that are in the corners here, find, fight the Gueleshabi, which is a mythical creature from Georgian folklore that is kind of like a huge dragon. The thing about the, you know, boss essentially, the boss Gueleshabi, is that it is much stronger than the players because all of the players are against it, but it is also much slower because otherwise it would quickly catch up to all the players and kill them off one by one. But when the boss is slow and the players are quick, they can all kind of avoid him until they get strong enough and then they can easily defeat them, defeat him, which is called a degenerative strategy, when there's one undeniably great strategy, which in this case is avoiding the boss until you get strong enough and then killing it off easily. So we needed some way for the boss to control the players and sort of lead them in a specific location or perhaps weaken them. And so we added the little minions, and the way the minions worked is that each of them had its own dice roll. All the players roll walk by rolling a dice, and that was also how the minions walked. And it was very tedious and very boring because the all of the minions also had their own health and so it was very hard to track. Reminder that this is a board game, and we quickly realized that that wasn't going to work.

So the first thing we did was we removed the health for all the minions so now they die in one hit but they also retaliate, so every time a player kills a minion, they also get some of their health removed. And then we also removed the dice roll so the minions move two pieces on each turn, which was still very tedious and boring and so we replaced the minions completely with fire.

Fire doesn't move at all, it stays on the board until the game is over, and the boss throws the fire by drawing a fire card. This was much more fun because now the players can try to sneak up on the boss and hit and run, but there's the risk of getting hit by fire. And also fire, since fire stays on the board, the board itself became more fun because kind of the makeup of the board, new things would get added to the board as the game went on, which was another complaint from our play testers, that the boss was too boring.

So this way, we made the game both more cohesive and we solved multiple problems with this single solution. So to wrap up this talk, remember to prototype. Be nice to your play testers. Don't try to solve design problems, but by piling on new mechanics, instead, think about how you can make your games cohesive and make sure the process of playing your game is enjoyable instead of just making some fool like, you should kill this boss and, you know, so what if the process isn't fun. Thank you for listening to my talk. Please tell me if you have any questions. Those are my socials on the top, my YouTube channel, etc. And the ones on the bottom are of our team and you can follow our development process if you're interested...