• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

How do you test/balance your game?

flyinian

Member
I'd like to know how you test/balance your game.

I'm looking for ideas is the main reason for this post.

Thanks.
 

Yal

šŸ§ *penguin noises*
GMC Elder
My own test play cycle basically is "make thing" --> "verify it works" on repeat. I only do more thorough tests nearing a release (playing through the entire game from start to finish on a fresh save). Usually you stumble over a lot of bugs along the way even if you're not actively looking for them, it's important to take notes IMMEDIATELY so you don't forget.

Balance is not my strong suit, but I'm firmly of the opinion that being allowed to break a game is a completely reasonable reward for understanding the game's systems. The only thing you need to watch out for balance-wise is dominant strategies that are easy to execute and easy to find. For instance, if you have a skill that lets you double melee damage by holding your weapon in two hands (making you unable to use a shield), which is unlocked in the first class you get, chances are every player will use that, deal twice as much damage as you expect, and never care about using a shield (making the entire shield skill tree useless, and making everybody complain on the forums once they reach the fight against that one boss you need to use a shield to deflect their attacks and show your complete mastery of the entire shield skill tree - which they haven't invested a single skill point into). When adding new mechanics, try to think about how powerful they are, and how "easy" they are - balancing those two out against one another is a good starting point. Situational abilities might be more or less situational than you expect, and that tends to make them either useless or completely broken respectively.

Having a friend that's completely new to the game test it is a great way to find bugs and exploits, usually they do stuff you'd never thought about and stumble over lots of completely fresh bugs. Make sure to give your test players as little information as possible (so you don't steer them into doing any particular behavior), just hang back and observe what they're doing. Have a notepad ready or something so you can scribble down notes instantly before you forget. If they get really stuck on something, make a note about it (players getting completely stuck on something is a design error, unless you specfically intended it to be a hard puzzle / boss) and then tell them how to progress. (In these trying times, watching them stream the game using e.g. Discord while also being in a voice call could be a substitute for physically shouldersurfing them during a test play session)
 

flyinian

Member
My own test play cycle basically is "make thing" --> "verify it works" on repeat. I only do more thorough tests nearing a release (playing through the entire game from start to finish on a fresh save). Usually you stumble over a lot of bugs along the way even if you're not actively looking for them, it's important to take notes IMMEDIATELY so you don't forget.

Balance is not my strong suit, but I'm firmly of the opinion that being allowed to break a game is a completely reasonable reward for understanding the game's systems. The only thing you need to watch out for balance-wise is dominant strategies that are easy to execute and easy to find. For instance, if you have a skill that lets you double melee damage by holding your weapon in two hands (making you unable to use a shield), which is unlocked in the first class you get, chances are every player will use that, deal twice as much damage as you expect, and never care about using a shield (making the entire shield skill tree useless, and making everybody complain on the forums once they reach the fight against that one boss you need to use a shield to deflect their attacks and show your complete mastery of the entire shield skill tree - which they haven't invested a single skill point into). When adding new mechanics, try to think about how powerful they are, and how "easy" they are - balancing those two out against one another is a good starting point. Situational abilities might be more or less situational than you expect, and that tends to make them either useless or completely broken respectively.

Having a friend that's completely new to the game test it is a great way to find bugs and exploits, usually they do stuff you'd never thought about and stumble over lots of completely fresh bugs. Make sure to give your test players as little information as possible (so you don't steer them into doing any particular behavior), just hang back and observe what they're doing. Have a notepad ready or something so you can scribble down notes instantly before you forget. If they get really stuck on something, make a note about it (players getting completely stuck on something is a design error, unless you specfically intended it to be a hard puzzle / boss) and then tell them how to progress. (In these trying times, watching them stream the game using e.g. Discord while also being in a voice call could be a substitute for physically shouldersurfing them during a test play session)
Thank you for this.
 

pixeltroid

Member
1. If I'm testing an object, I just drop it in the first level and check if it works. If I'm happy with it's behavior, I'll drop it in the room it's actually supposed to be in, and forget about it.
2. My enemy AI is based on state systems and timelines. I use the draw event in the enemy object to display the state the enemy is in. So for example, if there's a problem with state "jump", I'd know that I need to look at the script for "jump" and then ask what I'm doing wrong on this forum. Sometimes, I test it at a lower room speed , as it helps me spot mistakes easier.
3. For testing entire rooms, I place portal objects in the first room and give them the co-ordinates of the rooms that need testing. So I start the game, and enter the portal and go to the room that need testing.
4. To check general object placements, and if all the doors are working correctly, I must play through the entire game. I do so after increasing my players walking speed. So I just dash around to see if everything is in place or if something needs work.
5. Sometimes I make playthroughs of my game and then watch them on my phone during smoke break. For some reason, my analytical brain works better when I'm watching gameplay footage on my phone than on my work station.
6. I have 2 real world friends who playtest my game. I ask them to screengrab everything, and send me the footage.
 

flyinian

Member
1. If I'm testing an object, I just drop it in the first level and check if it works. If I'm happy with it's behavior, I'll drop it in the room it's actually supposed to be in, and forget about it.
2. My enemy AI is based on state systems and timelines. I use the draw event in the enemy object to display the state the enemy is in. So for example, if there's a problem with state "jump", I'd know that I need to look at the script for "jump" and then ask what I'm doing wrong on this forum. Sometimes, I test it at a lower room speed , as it helps me spot mistakes easier.
3. For testing entire rooms, I place portal objects in the first room and give them the co-ordinates of the rooms that need testing. So I start the game, and enter the portal and go to the room that need testing.
4. To check general object placements, and if all the doors are working correctly, I must play through the entire game. I do so after increasing my players walking speed. So I just dash around to see if everything is in place or if something needs work.
5. Sometimes I make playthroughs of my game and then watch them on my phone during smoke break. For some reason, my analytical brain works better when I'm watching gameplay footage on my phone than on my work station.
6. I have 2 real world friends who playtest my game. I ask them to screengrab everything, and send me the footage.
Thank you.
 
Top