How to write a free RPG - Chapter 7: Testing

Your game needs to be tested before it’s devoured by the general public. Testing ranges from simple mechanics tests all the way through to a full blow campaign play test. If you do not have a group to test with and cannot find a kind group to test it for you, there is still testing that can be done. Testing takes a long time, be prepared for this step to take as long as the rest of the game design.

If you are following the "Release Small, Release Often" principle (described in the next Chapter) then ensure you state clearly that the game has not been tested when you perform releases.

Smoke Test

A smoke test ensures that the system won’t catch fire when you try to use it. It will only find glaring holes, not mechanic niggles (see Mechanic Edge Cases) To smoke test the game, do the following:

• Make 10 characters.
• Write out 4 full combats step by step. Write out what everyone says and does and draw a battle map of what happens. Ensure each combat is different from your rule examples.
• Find a non-gamer to read through the whole game to check for grammar and spelling.
• Update the table of contents and index.
• Check your table of contents and index by randomly picking 6 items from each, located at different places in the book and check the pages are correct.
• Make sure that images are near the text that talks about them.
• Print out some test pages, is it too dark or too light? Is the font large enough? If you're using a background image, does it obscure the text?
• Ask a friend in a different country to print out on a different size, if you're in the US, try A4. If you're elsewhere, use US Letter.
• How does it look on screen? If a friend has a tablet device, check it on there too. If not, ask the internet, a friendly RPG geek will check it out for you.

Read it again

But before you read it again, check back to the style section of Chapter 3 then read through the entire game, contents, index, everything. Make notes as read through go, do not stop to edit. Check all the captions on the images and headings on the tables. If you are linking sections of the document together (in HTML or PDF) then click every link. You might be sick of your game by now but this is a very important step, so do it. Then ask yourself these questions:

• Does it fit the concept I was aiming for? Go back to when you wrote it down in Chapter 1 and check each item off.
• If it does not, have I still made something worth playing?
• Does it feel like the genre I am trying to represent?
• Did I solve the mechanic problems I was trying to solve?
• What’s best about the game?
• What’s worst about the game?
• Can I add any more images to spruce it up?
• Is all the information I need on the Character sheet?

Trim

You’ve used too many words to describe your game. It is normal to do that, your brain is not wired for brevity when it is describing concepts. Cut down every paragraph to its bare form. Is it still intelligible? If so, keep it that way. Your second draft should be 10% shorter than the first.

Mechanic Edge Cases

The success of a mechanics system can be judged on its ability to still operate when under stress. You can stress test your system by seeing what happens when the parameters are at their limits. You cannot test all possible edge cases (especially when it comes to combinations of spells) but you can certainly pick some example worst/best case situations.

For example, if the mechanic is combat what happens when a character has maximum strength, the best weapon, highest skill, excellent armour and so on. Do you have a monster that will challenge a character like that? How many rounds will it take to kill a character like that with medium monsters? How many medium monsters will it take?

A team of 5 people all firing guns that have been upgraded 5 times should be able to kill a monster in 5 combat turns. "Upgraded 5 times" guns do 5 damage, that's 25 damage a turn. So a normal monster should have 125 hit points. Basic characters have weapons that do 1 damage will take a staggering 25 combat turns.

Ask yourself these sorts of questions for all the mechanics, paying particular attention to modifiers and special items. A sword might have a reasonable power but may unbalance the system when enchanted by more than one spell. If you find that it is difficult to find edge cases with your mechanics then perhaps the system is too complex and consider simplifying it. Spreadsheets can be useful for testing out the range of dice roles and probabilities but do not forget the affects of special powers or feats on the numbers.

Imaginary game

A good way to test your game is to run an imaginary game. Take 4 of the 10 characters you created earlier and then run through your example setting and adventures. Ensure the characters have goals that fit your setting, is it easy or difficult to create goals that are possible. Try all of the mechanics, use the characters to defeat the monsters without using your imagination (by grinding) and using imagination. During your game, try and answer the following questions:

• What is the quickest way to end an encounter?
• What is the best combination of skills, spells, weapons and equipment to solve each encounter?
• Is there anything missing from the starting character setups that make the game impossible?
• Is it fun?

Play Testing

Play testing is the act of playing the game to see if it meets your concept. It’s important to remember that a play test isn’t really a normal game. Most GMs will bend rules, ignore sections and only use 50% of a ruleset in ten sessions worth of a play. A good play test should be precisely by the rules and use as much of the ruleset as possible. You should reward the playtesters with a credit in the front of the book, or a signed copy if you are feeling flush. Make sure that your playtest group is made up of your target audience (see Chapter 1). You should playtest only when you feel the game is complete, playtesting should not be used as a tool for design, only for verification.

Playtest Pack

A playtest pack is a ready-to-go pack of information that makes it easy for the playtest group to test your game and provide feedback. To get the best from the group running your game for the first few times, you must provide additional support. When compiling your playtest pack, you can do so assuming that the player knows roleplaying games well. It should include:

• A form for the player to put their name and contact details on. Give them the opportunity to opt-out of being included in the book credits.
• A one page rule summary detailing the main mechanics.
• Character sheets. Both blank and pre-generated. Although character creation should be part of the playtest, the players may not have the luxury of making a character.
• A sample adventure that makes use of as many of the mechanics as possible.
• A feedback form (see below).
• A summary of what is required by the playtesters.
• A Non Disclosure agreement (NDA) - optional as this is a free game after all.
• Your contact details for the player to leave with.

Feedback

It is important to get feedback from everyone who plays the game. Feedback forms are the simplest way to garner information but if possible socialising with the group in a relaxed atmosphere (in a pub/bar) is a good way to dig into details. Players more likely to focus on the good things if confronted but at least you can question about particular mechanics this way. Have your notebook with you when talking to play testers, write down their good ideas then and there. Do not trust your memory to remember the details. The playtesters won't mind, they will appreciate their point of view is important.

Feedback Forms

Your feedback form is there for you to gauge whether or not you have managed to satisfy your concept. Player/GM fun is important too but it is important to note that not all players like new systems at first and the act of learning them can be tiring and less fun. You can provide two sorts of questions, check box ones and written replies. I would recommend having both as play testing can be tiring and lengthy prose without inspiration from pointed questions can be difficult. Here are some example questions:

Questions to be used with tick boxes under the headings "Strongly agree, Agree, No preference, Disagree, Strongly Disagree"

• The game's rules are too light
• The game's system feels like [game's genre]
• The setting feels different to other games
• I understood the rules
• The game looks good
• I was surprised that the game was free
• I would play this game again

Questions to be used with plenty of space to reply.

• What I liked about the game was...
• What I disliked about the game was...
• What I thought was missing was...

What to do with feedback

All feedback is valuable, not all of it is useful. For each of the forms and notes you have made, assign them a priority and then use your concept to check to see if you feel the feedback is useful. Concentrate on the problems that are raised rather than the solutions that the players offer. As the game designer, you are the expert. Mechanics changes will mean restarting your mechanics testing (easier if you have used a spreadsheet). Be prepared that not everyone will like your game. Thank them for the feedback but do not dwell on it.

When to stop play testing

Play testing must end when you feel that the game meets the concept you originally set out. Play testing cannot be used to find every rules hole and it is possible to play test too much. Too much play testing is procrastination, pick an end date and finish your game.

Post play test release

Ensure that you schedule time after your play test is over to update the rules and put out another release of your game. Do not make the playtesters feel that you have wasted their time by sitting on the changes for a year.

Resources

• rpg.stackexchange asked What can I learn from Playtesters.
• Ben Lehman argues that playtesting should be directed at a finished product, not as a means of design. And storygames discussion
• Playtesters.net a place for finding tester for your game.
• Wikipedia rather banal entry.