Making a tester’s life less miserable 2


Most game developers know that sharing an early prototype of their Next Big Thing™ with friends and fellow devs is usually a good move. It’s a great way to iron out bugs, gather ideas and start moving in the right direction. It’s also incredibly encouraging to receive positive feedback early on — as long as your audience doesn’t consist of the sort of people who foam at the mouth and start gnawing at every half-arsed pixel push you make.

A problem that I frequently see, however, is the tendency of some people to release stuff a little too early: they’ll assume that people like me are either (a) bereft of any purpose in life aside from playing undercooked prototypes or (b) absolute gaming gods who can adapt to obscure situations and experiences at the drop of a hat.

I now speak to you, dear reader, as an ordinary man. I’m not a professional playtester and I don’t get paid in any way to look at people’s work. I’m just some game enthusiast who likes to help fellow devs with their projects. Quite frankly, that’s the perfect set of qualifications right there. A lot of people who test your game will be average blokes like me: developers who can exercise a reasonable amount of patience, sensitivity and respect when they play through an early release.

But I say reasonable for a reason. As a game developer it is inappropriate — nay, selfish! — to expect that testers will bend over backwards for you, or plough through a release that has no guidance, structure or gaming value. Remember that when people try out your game release, they’re doing you a favour. This isn’t to say that they’ll hold you to it, or that they’re doing their work with any reluctance — I personally take great delight in seeing new projects and helping fellow community members shape their art. I do, however, think that any self-respecting dev owes it to their audience to add some important components here and there to avoid making the test process a chore or — worse still — a waste of time.

No matter how early in development your game may be, here’s a few “minimum requirements” that your first release could do with adhering to:

1. Make it a damn game!

Once upon a time, I spent about ten megabytes of my precious Internet bandwidth on a game test release that promised to be awesome and revolutionary and a whole bunch of other stuff. It was an early release, of course, but with ten whole freaking megabytes of content, there must have been at least something cool to play around with in there. It started off well enough: a nice flashy menu with a pretty cool background and a few effects here and there. It was at this stage that the warning bells should have gone off (and in this regard you can refer to my next point: “Don’t give me a damn menu”). But of course, I’d just spent ten megabytes on this bugger. And at the time I was sitting with a GPRS connection (with ridiculously overpriced South African Internet, no less), making those ten megabytes a pretty big deal. So I pressed on to get my bandwidth’s worth.

After starting the game and quickly scrolling through the back story (perhaps another unnecessary touch, but one which I tend to forgive anyway), the screen faded to black and took me … back to the main menu. Suspecting that something had gone a little screwy, I decided to give it another go to see if I could bypass this awful little bug. Again, I clicked on “start”. Again, I scrolled through the story. Again, I was returned to the menu.

With a furrowed brow and no small amount of panic (ten megabytes, dammit!) I frantically clicked through the other options, trying to figure out which set of levers and smoky mirrors would take me away from this cruel joke and lead me to the actual gameplay.

I had no such luck. The game was a lie.

Ten minutes later, after wiping blood and pieces of fingernail off my cheeks, I went back to where the “game” was posted and wrote out the most politely-worded response that I could muster. It turned out that halfway through paragraph two, I was threatening to strangle the dev with his own intestines. So I deleted the response and remained silent instead, stuck in the mindset that if I couldn’t be kind and supportive to a fledgling dev, I probably shouldn’t write anything at all. To this day, I still shed tears of blood knowing that I’ll never get those ten megs back.

I think I’ve made my point clear enough: don’t give testers a game that they can’t play. If you’ve got nothing more than a barely interactive tech demo, label it as such and the people who like that sort of thing will have a look. But don’t make the common tester download and watch trailers for games that don’t yet exist. Don’t tease them with marketing bullshit and hype. If you get someone to try out an early prototype, don’t turn them into a customer — these people are your peers, and they’re trying to help you, so give them what they need. Treat them with respect.

2. Don’t give me a damn menu!

Related to the point above, putting a fancy menu into your game indicates that you’re paying a little too much attention to presentation at a very early stage. This goes for just about anything related to basic navigation and what I would call “grunt interactions”. Unless your testers are a bunch of dim-witted troglodytes who think that having a nice user interface is more important than examining your core game dynamics (in which case they shouldn’t be testing game prototypes in the first place), you really ought to take a look at trimming fat like this.

This point is reasonably flexible, of course: sometimes a game’s interface is very important to establish because it’s a core part of the experience. If you want to try out a new RPG combat system that has players gliding smoothly through command menus and environment interactions, then by all means set up a few carefully placed buttons, verb coins and menu options. If you’ve thrown any sound or music into your proto, maybe give testers an option to switch it off. And if you’ve got multiple levels, a stage selection screen or a load/save feature will make the testing process a whole lot easier.

Just follow one simple rule: if you’re going to throw in a GUI, make sure that the core game is at least as well developed as the padding you generate. A fun, experimental prototype with a basic start/load/quit screen up front is quite forgivable. A proto with a well-developed button system but no enemy AI, on the other hand, will raise a few eyebrows and beg for a wet trout to the face. Menus aren’t special. Everybody has them, and they’re not what players are looking for. The IGF doesn’t have an awards section for “Best Effing Admin Screens Ever”. Please stick to what’s important for your first release, and look at streamlining the menial chores later.

And for the love of dev, DON’T PROVIDE US WITH BUTTONS THAT DON’T HAVE A PURPOSE YET. There’s nothing more annoying than selecting “Xtreme mode” from the main menu only to be presented with a message saying that it’s not available yet. If it’s not available, then why do you need that button? To get people amped up for it? Again, stop marketing the game to testers. They’re your helpers, not your customers.

3. Provide a damn tutorial!

This may sound obvious, but it’s surprising how often this rule is broken. A startling number of first prototypes come ill-equipped in the instructions category and become nearly impossible to play unless a determined tester decides to stick it out or happens to be quite fantastically bored. There’s a few liberties that can be taken with dedicated playtesters, especially if they’re fellow developers: they’ll experiment more than the average player would, and they’ll exercise more patience if things aren’t absolutely clear. Part of their job will be assisting you in making your game more intuitive, so grey areas and confusing situations will be acceptable to start with. It’s a common dev error — making a good tut actually requires considerable skill and reworking.

But don’t abuse the “benefit of the doubt” that is given to you. At times you can assume that testers will try using the arrow keys (or maybe even the WASD combo) to move a character around. It’s usually assumed that buttons can be clicked on. And if something in your game looks like a spike, it’s universally accepted that these spikes will kill a character on contact.

But if, for example, you’re creating a game like the ones in the Karoshi saga (where the core aim is to kill your character), don’t skip out on the bit where you tell players that the spikes are their *goal*. Don’t assume that they’ll try every combination on the keyboard in the hopes of finding a jump button (oh, sorry, you were supposed to press Z!). If you’re making a real-time strategy game, don’t assume that a description of “its simlar 2 command and conquer, jus klik around lol” is going to make anyone happy.

Anything that interferes with a playtester’s job is unacceptable. In the worst case scenario, they may never figure out that all-important (and totally cool) QCF combo that you threw in to make the game ten times more awesome. They’ll just see the crappy 10% that’s immediately obvious.

Your tutorial doesn’t need to be extensive. You don’t have to throw in an entire campaign of introductory levels (though I certainly wouldn’t object to it). If you can cover everything in a single readme with a control overview and some important gameplay points, that’s cool enough. But don’t you dare hide a lone enemy in the corner of an otherwise blank 3200×3200 map and expect us to hunt it down. That just ain’t cricket.

A good tester will do his or her best to figure things out, but throw them a freaking bone. Throw them a lot of bones. Throw them so many bones that they won’t have any idea where to keep them all. Make your testers bone-crazy. It’s the right thing to do.

4. Don’t look to me for your damn ideas!

There are exactly two situations where you should ask other people for game design ideas. One: you’re a talented game programmer/artist/whatever with a nice concept who is specifically looking for a designer to hop onto the squad and help out. Two: you’re a game developer with a cool prototype, an idea of where you’re going with it and an open attitude when it comes to accepting feedback, suggestions and idea bounces.

There’s a fine line between looking for suggestions and asking other people to design your game for you. If you have a concept for an awesome FPS with moddable weapons and unique enemies, that’s *your* concept. Slapping together a quick demo with a generic guy running around a generic arena and then asking people to figure out a good play system is like offering to cook food, buying the ingredients and then asking someone else to prepare it for you. And then buying a microwave dinner instead because you got impatient.

Playtesters can make suggestions and help you in ways that you would never have suspected, but don’t ever put the burden of game design on them. Without sounding like a dick: if they’re not a formal member of your project, then it’s not their game and they definitely don’t want to do your work for you. Bring something to the table, and people will usually comment on it or suggest improvements. But if it ever becomes clear that you don’t have any idea what direction you’re heading in, don’t be surprised if support is less forthcoming. Either figure something out or ask another developer if they’re interested in committing themselves to your project. Hugs and smiles all around.

5. Give it some damn polish!

Admittedly, this advice sounds really weird and usually shouldn’t even be here, but there’s method to the madness. If you’ve just spent a day or two working out the greatest game concept the world has ever seen, adding just a teensy bit of polish in the right places can work wonders. Improve a collision check here, tweak a level design there — spend just a little time ironing out the very worst and most obvious flaws before giving it to your pals.

Not only is this a nice gesture, but it’s far more helpful when testers can get a feel for the game without running into sticky geometry, impassable walls or constant game crashes. Ironing out a few bugs and giving the game at least one thorough test run before throwing it to the dogs can make the difference between receiving a mountain of excited feedback from players and finding that your game is completely unplayable because stage one had an extra block in the wrong place. Dealing with that sort of situation is about as embarrassing as releasing a game that consists of nothing other than, say, a main menu and story screen.

And yes, there’s always going to be stuff wrong with your game that you won’t figure out immediately. But if you do see something wrong and it’s easy to fix, why not invest that little bit of extra time?

A final point: ignore these rules

With the exception of point number one (which, if broken, will inspire me to hunt you down, chop off your fingers and throw them into a stew), you can probably disregard all of the aforementioned rules if and only if you know what you’re doing. If you want to skip on the tutorial because you genuinely need testers to examine how intuitive your game is without instructions, then fine. If your game consists of randomly generated terrain and procedural doothingums up the wazoo, or if it relies on a complicated set of scenario combinations that will take forever to examine thoroughly, then you could be forgiven for taking a shortcut here and there while testing yourself.

And yes, we all occasionally fall prey to the idea of putting something in just because it would be cool to show off. I have one or two friends who are interface enthusiasts and enjoy putting makeup onto their early protos — for them, it’s all part of the fun and I don’t begrudge them this luxury as long as they give me something playable in the process. Heck, some people craft a good 90% of their game before releasing the first test version, and that can work out too.

Breaking these rules won’t instantly render your work unfit for testing, but I would suggest that you only break them when (a) you understand that they’re important and (b) you understand why they’re important. Making your game in whatever fashion you want is really awesome, but if you’re going to expose other people to it, remember that they have needs, expectations and a less than godlike level of patience.

Take what you need from this, ignore the rest and listen to what’s been said here with the right attitude. Like everyone else, I’m just a humble playtester who wants to help my friends and I’ll do that to the best of my ability — I just need to be met halfway, and so does the rest of your early audience. We don’t hate you, we just want to help.

… Of course, that applies to everyone except for people who insist on breaking rule number one. They’re a bunch of bandwidth-chewing dicks and my GPRS will never forgive them.


About Nandrew

Rodain Joubert is a South African game developer based in Cape Town, currently working for QCF Design. He likes his job. He likes being opinionated on the Internet. He likes fighting evil with his heat ray vision. And he also likes cats. [Articles]

2 thoughts on “Making a tester’s life less miserable

  • Van

    I agree with your points here. I think most people just forget that beta playtesters are doing you a favour, some devs think that they are doing the playtesters a favour by showing them unfinished buggy games.

    Oh did you ever play the game from question 1? Was it ever finished?

  • a

    amazing favorite’d, reading whatever else you write, have written when I , have time.

Comments are closed.