testing isn't about fixing bugs in Design Philosophy

ID:731280
 
May 7 2012, 6:15 pm
You make your game. It's playable. Oh em gee. So now we test.

...This is where most people go the wrong direction.


Testing a game isn't about fixing the bugs. Of course, you should always do your best to keep the glitches out of the game. That's obvious, but fixing bugs is something to do more often when you're actually developing the game and not entirely into the "testing" phase.

When you're testing your game, you have one goal:

Make this game not suck.

It's pretty simple and easy to do. Gather a handful(best to have a variety of people with different preferences, ages, etc. Try to reach the widest chunk of your target audience that you can- stupid, smart, casual, hard-core, etc. Don't even worry about whether you have a huge audience or not- Most of the time when you take the risk to go for a super-specific niche, you'll reach everyone. [minecraft, swords & sworcery, legend of grimrock)

Sometimes your tester can be any random dude who decides to give your game a spin. In fact, when you're testing your game to fix your gameplay problems just about every single person who plays it is another test subject.

Think of yourself as GLaDOS. You won't even need cake(since it's a lie). Watch every player carefully, and see how they play your game. An easy way to collect information is to see the key points where a user logs off, complains about something, dies, etc. Note things like what makes them raeg, what makes them laugh, and the habits the player builds. Be very open to criticism and feedback- A tester who isn't afraid to vocalize his opinion will be a very useful asset to you. Chances are high that if one person has a problem with a certain level or game-play aspect, then everyone does.

And when they tell you what's wrong, they're literally doing the work for you by figuring out why your game isn't that 1337 masterpiece it was in your head. A couple tweaks and changes can dramatically change a game for the better.

It's important to be very dynamic with your development, 100% of the time. Don't EVER restrict yourself to some stupid design document you wrote up before development. If the game isn't fun, then the game isn't fun. Learn that fixing a key aspect of your game can be as simple as writing out 10-20 quick lines of code.

i'd write more on this but i think you get the point. this is the testing process I used for Epic, and the reason I'm writing this is because dynamic game-play testing and development is a process used by the mainstream(valve takes pride in their flexibility)

As with all things, game design and development will come easier to you the more experience you have making games. If you make 10 mini-games and the last three or four are actually pretty fun, that is because you learned a lot from making the first 6. Compared to the guy who hasn't made a single game but has dedicated his life to making one huge project over the same amount of time(and possibly equal amount of effort) you have a lot more experience. But that's a totally different blog. Today we're talking about testing... lol



#1 May 8 2012, 4:20 am
I don't know, but a lot of great developers improve their game by testing.

How else are you going to find bugs and fix them? The public release? That seems a bit too late for any last-minute fixes.

So folks:


Test your game for bugs. Do it. Test your game for gameplay. Do that too.
Testing a game is very general. You test it to basically test it for it's functionality, and well, bugs fall into that category.
#2 May 8 2012, 6:04 am
Maximus_Alex2003 wrote:
How else are you going to find bugs and fix them?

Most bugs are found while you're developing the game. You implement a feature, then run the game and test it out. If it doesn't work, you fix it. You don't need to round up a group of people to determine if a feature works, you test that stuff yourself.

Yut Put wrote:
Testing a game isn't about fixing the bugs. Of course, you should always do your best to keep the glitches out of the game. That's obvious, but fixing bugs is something to do more often when you're actually developing the game and not entirely into the "testing" phase.

When you're testing your game, you have one goal:

Make this game not suck.

I generally agree but it's important to have a more specific goal than that. Testing is only important for certain things. You don't need to waste the tester's time, energy, and attention on something you can easily test yourself. As a game developer you should be an experienced game player. You should be able to look at your game and know whether it's fun or not. Still, there are some things that are difficult to test on your own:

1. Sometimes you can't test something simply because you're the one who made it. You can't determine if a puzzle is too difficult because you already know the solution. You can't determine if a hidden area is too hard to find because you know exactly where it is. You can't determine if the gameplay is too complex/confusing because you made it and it'll always make sense to you.

There are signs you can look for. If the player isn't given any hints about the hidden area (ex: a townsperson telling them that the hidden area exists, a visual cue in the room to indicate where it is, etc.) it's probably too hard to find. If all new players have to go through a lengthy tutorial the game is probably too complicated (or you're presenting too much of the gameplay up front). Even with the bias of knowing exactly how the game works you should still be able to determine if your game may have these problems, but testing is an effective way to get feedback about these issues too.

2. Some things are just a matter of opinion. If you have two tilesets of the ice cavern there's just no way you can determine which one players will like better. You have to show lots of people and get some feedback to figure it out.

Most people do "alpha testing" or "beta testing" because they've heard that real games do those things. For commercial games this is important - they don't want to release a game and have it get bad reviews because it has some bugs or gameplay issues. They have one chance to release the game and have it be a success. BYOND games don't have this problem so this level of organized testing isn't necessary. If you want to get feedback, just release the game. Testing is only useful for specific things, so if you're going to do testing first identify the issues that need to be tested. You can't just give players the whole game and expect that they'll test (and provide good feedback) for the specific issues you'd like to get feedback on. You may need to change the game so it's set up in a way that players will be exposed only to the parts you want to be tested.

Also, this is the reason why it's important to be a good programmer. You have to get the game to a playable state before you can ask "is it fun?". The more effort it takes to get the game playable, the more likely it is that the developer is out of motivation or the code is too messy. Even if they find ways to make the game more fun, there's a good chance they don't have the motivation to make the changes or the code is in such bad shape that they just can't make the changes.
#3 May 8 2012, 7:31 am
In response to Forum_account (#2)
Forum_account wrote:
run the game and test it out.

It's okay to agree with me, just don't actually single me out and try to sound superior.
#4 May 8 2012, 7:41 am
In response to Maximus_Alex2003 (#3)
Maximus_Alex2003 wrote:
Forum_account wrote:
run the game and test it out.

Yut Put was talking about a "testing phase" where you get other people to help test the game. This is from his post:

Yut Put wrote:
Testing a game isn't about fixing the bugs. Of course, you should always do your best to keep the glitches out of the game. That's obvious, but fixing bugs is something to do more often when you're actually developing the game and not entirely into the "testing" phase.

He's saying that you don't need to get other people to test the game to check for glitches because you should be doing that yourself during development, the testing phase should focus on testing the gameplay instead.

Maximus_Alex2003 wrote:
It's okay to agree with me, just don't actually single me out and try to sound superior.

I didn't agree with you and I didn't try to sound superior. You misinterpreted the original post and it seems like you misinterpreted my reply too. I was explaining the difference between the kind of testing you can do yourself and the kind of testing that you need other people to do.