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 3200x3200 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.