Tutorial: Playtesting (Beta Testing) Games

RinkuHero — Wed, 19 Nov 2008 14:56:52 -0700

I also wrote this for my LiveJournal several years ago, but I thought I'd update it and post it here too. There are many things which separate good games and bad games, but probably the most essential is that great games were playtested, and bad games weren't sufficiently playtested. Here are my recommendations on playtesting.

1. The more playtesters, the better, because you can see what a wider variety of people think about your game. Try not to pick only people who are "gamers", as what's pleasing (or obvious) to them might not be pleasing (or obvious) to others who don't play games as much.

2. It's better to watch someone play your game than to read a report about it. What you can learn from watching people play your game you simply can't learn from what other people tell you via email or instant messenger about your game, and I kind of even feel sorry for games which are released without the developer watching anyone play it in front of them -- usually one can tell when they didn't.

3. Constantly add new eyes. Adding new playtesters with each newer version of the game helps: when someone has played earlier versions of your game they tend to look at it differently from someone who hasn't seen the versions without all the current features, since first impressions develop very differently if the first version they played was 10% done or 90% done.

4. When it comes to taking their suggestions seriously, don't do that. Ignore most of what they recommend -- it works better that way. Use what they say as raw data to make your own decisions about the game, and do think about their suggestions, but keep in mind that game players usually don't know much about game development. They do know what they find fun, what they had trouble with, what was confusing, and what they found annoying. Those are the things you're looking for, not suggestions about new weapons or new gameplay elements, you're still the author of the game, don't make it a design-by-committee game.

5. Spend a lot of time playtesting, preferably constantly; I probably spend at least ten percent of my current game's development time watching people play it or talking about it with people who have played it. Think of it this way: you want people to have fun with your game, so what's the best way to ensure that they will? Let them play it to learn what they find fun and what they don't. It's simple empiricism.

6. Your team, and you yourself, do *not* count as playtesters. You can play your game for fun and look for bugs, but you know far too much about it to be a good judge of many aspects about the game, particularly its difficulty level and how confusing or easy to learn it is. Likewise, what's intuitive to you about the control scheme or even the strategy isn't intuitive to people who didn't make the game. Make sure people can figure it out on their own, just from the game, without your advice.

I found this quote by Shigeru Miyamoto in an interview: "If a fan makes a suggestion, I will often put it in my mind, and I will take in whatever comment I feel is useful. But I make my own predictions of how a user might react to the games I create, and I would say I am sensitive to whether those reactions are in line with what I predicted. People generally have different views and opinions about anything. So I would only listen to whatever information is useful for me. It is interesting to hear what other people say. But instead of reading the blogs, I would rather stand behind a person playing the games and sense how the player is reacting to the game -- whether he is unhappy with the games, or if he is having fun. I can feel all of that directly. It is more useful for me to do that than to read what he thinks of it."

For those of you who want to see a great example of how games should be playtested, read this series of posts by Auriea of Tale-of-Tales, they're wonderful.

Tutorial: Design Documents

RinkuHero — Fri, 14 Nov 2008 13:41:10 -0700

A lot of people don't design their games first in any written form, they keep it all in their head or just make the game up as they go along. That's fine, but some games are too large for that, and some games take so long that you begin to forget some of the stuff in your head. If you have a team, a design document helps everyone as a reference source. So I thought I'd explain how to write a design document.

Some people feel that writing things down is restrictive, but I don't think so myself, I find it makes me more creative to have all the ideas written down in front of me, rather than trying to come up with things as I need them. And it's not as if you design the game once and then make it without editing the design at all, the design usually changes as the game goes through development.

Media

The format doesn't really matter, but I find a Wiki to be the most useful, because it can be edited quite easily as needed, and because it can be shared with others on the team online.

The best two I've come across are MediaWiki (which Wikipedia uses) and DocuWiki. DocuWiki has the advantage that it doesn't require a MySQL database, it runs entirely on text files, so it can be run on free servers without any MySQL benefits. There are also wiki's which can be set up on your hard drive, but I find them less useful because I usually work with others online on games.

Format

I'd recommend using the design document primarily for "lists" -- the type of list varies with the type of game, but often it includes a list of enemies, a list of playable characters, a list of areas or levels, a list of the music the game will need, and so on. Typically my design documents are around 80% lists, and around 20% description of the game in general.

Each item in a list, for example an enemy list, wouldn't just list the names and that's it, it'd also describe it to some degree: what the enemy does, how it moves, strategies the player might use against it, places where the enemy appears, etc., typically a paragraph or two is enough.

It's also important to think about the overall idea of the game, what it's trying to accomplish as a whole, and include a few sections on that.

Length

The length of the design document varies by the complexity of the game; I've written design documents which were only a few pages long, and others which were hundreds of pages. Try to include enough information about something that when you get to coding something or drawing something you have a good idea about what you're trying to do, but not so detailed as to include too much unnecessary information.

Also, it's a good idea to make the game and the design document at about the same time: don't spend a few months making the design document and then a few months making the game, because that just leads to laziness, it's better to start the game prototype first, work on it every day, and occasionally add to the design document during the process of creation. I find that it's easy to fall into the trap of all design no actual work, so try to avoid that.

Examples

Here's the design document of the game I'm working on now as an example; it's incomplete and contains spoilers so if you do check it out skip the characters and story section. Although the game of course will change in the future, so don't take the design there to be a good representation of how the game will ultimately end up. But reading that can give you a good idea of the format I use and what a design doc looks like.

Here are two good examples of design documents I've come across:
- Planescape Torment's design document
- Metal Gear Solid 2's design document

I'm sure there are more but those two are the most interesting I've read so far.

Use

The main use of design documents is as a primer for working on parts of your game. For instance, when working on a new enemy, you can go and look at what you wanted that enemy to do, even if you wrote that part 20 months ago, and then have an idea about how to proceed, rather than having no starting point. It's not meant to be something restrictive, don't feel as if you have to translate the document directly, it should work more the way an outline to a novel works.

Also, don't use it as a substitute for a to-do list: you'd still probably need a separate to-do list for all the tasks you want to do next for the game, to list bugs you need to fix, and so on.

Another great use of a design document is to share it with others on the team, get their input, and then change parts of it after discussing the game, to give the team a shared vision of what they want the game to be like. That's more difficult if there's nothing written down, because often team members have completely different ideas of what the game will be like if they don't have a shared reference.

Most likely the design document will be more ambitious than the game itself, if you want to get the game done at all. It's easy to list 100 enemies and all the ideas you have for each, but it's harder to code them all in, so generally parts of the design document probably won't make it into the game. That's true of the MGS2 and Torment documents above, and it's probably true of most design documents, so don't be afraid to "over-design" with the intention of only including the best parts of the design in the actual game. I.e. don't be afraid to write up descriptions for 100 enemies, and then just use the 40 or 20 best ideas in the game. Don't feel that a game is only complete if it contains everything in the design document, it can be complete even if it only includes half of the stuff in there.

tutorial