There are a million lessons I could share with you, but I’m going to keep it short and sweat, talking only about the most beneficial lesson I’ve learned from my years of game development.
Test early and often
That’s it. That’s the big secret to designing and developing more effectively. But keep on reading, I’m going to explain why, when, what, and how you should be doing it.
Why test early and often?
Everyone knows you need to test your game, but a lot of people think testing comes after development, when you start looking for bugs or tweaking level designs. In reality you need to be testing throughout the entire life-cycle of your product. Feedback is invaluable. You will learn quickly whether a new feature is enjoyable, or the menu is not usable, or the entire game concept just sucks. Why waste weeks or months building something just to learn it was a terrible idea?
When should you start testing?
As soon as you feasibly can. If you’re able to get your concept across through sketches or a paper prototype, test it. The sooner you get feedback the quicker you can improve on the idea. I’ve heard fellow game designers shy away from testing their game because “it looks so bad”. They don’t have the style down, or the sound effects aren’t in place. Well let me tell you, that’s the best time to test.
Don’t make any costly decisions until the last possible moment when you’ve gathered as much data as you can and have weighed the possibilities. Learn from my mistakes, don’t spend days working on art assets just to decide a week later that you wont need any of them.
What to test for?
Usability – how hard is it for someone to do something in your game? The best way to test this is to give your user a list of tasks to perform and observe them doing those things. Try not to answer their questions, because you’ll see first hand their thought process when they get stuck.
Engagement – A lot of times I won’t set a time limit for the testing session, I’ll give them my game and see how long they play it for, and precisely where they leave off. A little example for you – I performed a round of testing on a puzzle game I was building that had 8 levels, but I quickly noticed most people handed the phone back to me after level 5. When I started asking people why they stopped, most told me level 6 looked so much tougher than level 5 and it was daunting to continue. So I learned that I needed a smoother curve to my levels.
Mechanics – Which mechanics do people like, which do they hate, and do they have any ideas? You usually want to build your game around a single core concept. To find the right idea I’ll start by adding in a lot of mechanics I think could be interesting and then see which ones people respond to best. Then I go back and remove the fluff, leaving only whats desired in the game.
Of course there’s more to test for… but c’mon how long do you really want this post to be?
How to test your game?
You might think this is a dumb question, but hear me out.
You don’t need a large pool of people to unearth glaring problems with a product. The insight and observations of a handful of people is enough in most cases. You may not find all the issues with your game, but you’ll unearth all the big ones. And if you test often, the list of bugs and suggestions start to dwindle. I use about 4–6 people for most of my testing. Family, friends, and a couple fellow game designers. The key is to find people that will be honest with you, and not just tell you what you want to hear.
I’ve tried many different approaches to facilitate testing, but I’ll go into depth on the technique I found most useful. And it follows a very similar structure to how ux designers test for usability.
- Start by creating a list of tasks you want the user to perform. This is usually best done when adding a new feature, so its a single concise element you can test.
Example — “Put a hat on your character”. With this question the user has to figure out where they have to go to purchase a new hat, how to purchase the hat, and then how to equip it.
You want to be careful not to ask leading questions as you may get the exact answer you were looking for which is not always good. Here’s an example of a bad question
“Go to the store and buy a cowboy hat”
This question might not seem so bad, but it tells the user where they need to go, and that they need to buy it, which they might not have figured out if you didn’t tell them. You also lose out on learning which types of hats are most popular in your game.
2. Test the game in person, but make the environment comfortable.
You will gain a lot more insight from 1 in-person test, than you will from 5 people online. The reason is you can ask the person to speak their mind when they play it with you, and you can see what they try doing when they get stuck. All of that is missed when someone plays the game without you observing them.
3. Pick their brain after the session.
After you’ve observed them complete your tasks, answer all of their questions, and then ask some of your own. Ask about every hiccup they encountered, and take good notes, because you will forget things.
Well I think that about covers the basics. There really is a lot more that goes into testing, and I encourage you to do your own research, but I hope you gained something from reading this. Leave a comment if you agreed, and more importantly if you disagreed with any points I made.