top expert

Did you answer the author’s questions?

playtesting is a way of life.

Note: I write about my experiences writing about and making parser games, though most of this essay is not system-specific.

We’ve been talking about making games for quite a while now, but we haven’t talked about testing them. Playtesting is essential to making a good game. If you follow larger IF events that have review threads at intfiction.org, you have likely seen again and again reviews that mention testing, as in: “this needed more testing,” or “this problem would have come up in testing,” or “these typos would have been caught during testing,” or “this content warning should have been run by testers.” Off and away on some shadowy discord somewhere, someone might say, “playtesting would have prepared the author for these reactions.”

If you’ve published a game before, you can imagine how frustrating it must be for every review of your game to be about testing. Wouldn’t you rather read reviews about what is actually in your game? Reviews about bugs are disappointing: you had specific things in mind as an author: stories, or problems, or mechanics. Themes, characters. This is where you would like players to focus, most likely. Achieving this without some level of testing will usually be a matter of luck.

If you put a lot into your work, don’t skip testing. Doesn’t your game deserve the best?

There are two types of perspective or participant involved in testing a game: the author, and the tester. It’s good to try both roles, even if your main interest is testing your own work. Why? In the first place, it will be helpful for you to understand what testing is like and how the interactions go between involved parties. Second, there is the community element: help the community out! In my experience, it’s hard to find testers who vibe with your work and answer your questions. Be one of those people, be the change and all that.

More selfishly: people who test games have an easier time finding testers. Unless you’re IF famous (and I don’t mean me, I have to hustle for testers), you are going to need the goodwill. It’s for that reason that I’ll start with advice for playtesters first.

so you want to be a playtester.

If you want to test games, you need to be where people are looking for testers. For parser folks, that might be intfiction.org. You might be active on some discord servers where people talk about authorship. If you’re doing a Neo-Interactives jam, for instance, you can look for other entrants, and possibly test for one-another. The key is to hang out with other IF people. Someone will ask eventually.

Asks don’t always contain a lot of information. Don’t be afraid to ask for clarification! Here are some things I generally want to know:

• Is there a timeline or a due date?
• If this is a puzzle game? If so, are there hints (I’m not much of a puzzle tester)?
• General info (genre, etc)
• What information does the author want? As in, are there specific questions to answer?

Usually, an author will offer most of this stuff on their own. You may have other questions! If it’s a question anyone would want to know about (when is it due), I ask publicly. I might ask other questions in a PM expressing interest.

It’s good to be clear on expectations before you commit. Why? Usually, authors have a specific number of testers in mind. If you commit, you are taking up a slot. There’s an opportunity cost for the author if you back out or simply never test the game. Make a firm commitment and find out whatever you need to know if you aren’t sure.

It’s not too serious; for most games testing is a minor effort of a few hours. Just remember that authors likely have an emotional investment in their work, so try to keep promises involving it. At the same time, it’s possible that something will come up that prevents you from completing the test. That’s alright! Just be sure to let the author know right away. They will almost certainly understand. Communication, as the cliche goes, is key. Don’t make them come looking for you.

playtesting in action.

You’ve made a commitment, and now you have a game file. If you’re testing a parser game, you will want to keep a transcript. For Inform 7 works, that’s as simple as typing “transcript” at the command prompt. Alternately, the most recent version of Lectrote automatically keeps transcripts. I play exclusively with Lectrote for this reason. If you’re as forgetful as I am, you might want to consider it! You can download the latest version here.

OK, you’re transcribing your play session. Now what? Keep notes in the transcript! The convention is to type comments directly into the game, preceding your comment with an asterisk (“*”) symbol. For instance, if someone misspelled “their,” I’d key this in at the prompt:

>* "thier"

If I had a comment about a hint or a clue, I could type in something like:

>* am I supposed to do something with the frob? I'm having a hard time with this.

We can just as easily comment on the text itself:

>* great description, really strong vibes

Play the game, taking notes as you go. If you get stuck and there are no hints, message the author for help. Don’t wait too long. Sometimes, bugs seem like puzzles, so you don’t want to wait until you are intensely annoyed with the game. You probably won’t be a good tester if you are completely out of patience, so there’s no need for it to come to that! Get help from the author.

What kinds of things should you be looking for while testing and commenting? Priority number one is ANSWER THE AUTHOR’S QUESTIONS. For all you know, a professional editor is proofreading the punctuation even as you play. If you only send back comments about commas, you have spent hours on something that the author cannot use. The only thing you know for certain, so far as their needs go, is in THE AUTHOR’S QUESTIONS. That doesn’t mean you shouldn’t comment on other things. Here are some ideas:

• Since a professional proofreader is unlikely: typos.
• Story beats.
• Puzzles (clues, difficulty, etc.).
• Mechanics or gameplay loop.
• The map or game world.

Another good idea: every tester (well, usually) will finish the game. That means that the only thing that you know will be thoroughly tested is the main throughline, i.e., the critical path for finishing the game. There are no guarantees that testers have looked at anything else. Your best chance to give the author information they aren’t getting elsewhere is to get off the beaten path. Some simple ideas:

• Try to examine everything.
• Try pointless or even nonsensical commands like PUT [something] IN SOMETHING for many different nouns.
• Try TAKE ALL everywhere.
• See if there are custom error messages by doing things like typing ADLKJHASD at the prompt.
• Be curious.

Once you get all of this together, you can write a short summary of your experience in a message containing your attached transcript. What should go in there? The first thing, of course, is to ANSWER THE AUTHOR’S QUESTIONS. What else? If there is a core loop or mechanic, give an evaluation. Would anything make it better? What makes it great? How do you feel about character, or setting? The story? Address the key elements of the game in terms of play and writing but consider going further. In my experience, it is rare to get “big picture” feedback about themes, or meaning, or just how everything is working together. This isn’t a checklist or a lit paper, of course. Even saying a little about the overall text will be helpful to the author.

What about the suggestions and their tone, though? As I already said, the author likely has an emotional investment in their work. And well they should! I suggest we bear that in mind, and honor it. Some general thoughts:

• If there are a lot of spelling errors, suggest the author run spellcheck on the transcripts. There’s no need to note 50 spelling errors; just point them to a method for finding errors. Inform has a spellcheck option, though it may not suit the author’s needs (be aware that somebody else is probably pointing them out anyway).
• If there are a lot of grammatical errors, I might just suggest spending more time on grammar, whether it’s looking for someone specifically willing to help out in that capacity or else running it through some sort of machine checker or productivity software. It’s worth noting that grammar can emerge from specific social conditions, so it’s good to be thoughtful (be aware that somebody else is probably pointing grammar errors out anyway).
• The whole “say x good things for every negative thing” is a bad rule that leads to disingenuous feedback. But be sure you are saying the good things that are real.
• If there is content that audiences will find off-putting, I wouldn’t necessarily tell an author to change it. I would tell them that audiences and critics will likely have trouble with it. One point of your feedback is to prepare them for reviews, be they good or bad. The author of a game should not be surprised if audiences dislike something. They may not care, which is the right of every artist, but they should never be surprised.
• Your advice should always focus on helping the author meet their goals, even if you have different preferences. Saying “I don’t like reading a lot” about a game with a lot of text isn’t helping, it’s complaining. What is needed for the author to realize their vision?

What if a work seems hopeless? Completely unredeemable? Well, “unredeemable” is a very rare case. It is more likely that the author is unwilling to redeem it. That’s their business! And who knows, in the long run, they may be right. We can’t know that. All we can do is take stock of what’s in front of us. If I were a playtester of a work that appeared to have very poor prospects, I would prioritize the foundations. Anybody can fix commas, and these can be fixed very late in the development cycle. But problems with core loops or worldbuilding are nearly impossible to address in a late-phase or beta work. Tell the author where you would spend your time first.

I think I might start by saying, “Like most works in progress, a lot of polish will be needed when it comes to copyediting grammar and spelling. Those can be worked out later in the project. My advice would be to prioritize work on x, to make sure you have a solid foundation.” No lies!

Don’t argue; your goal is to give a thoughtful and constructive assessment. What an author does with it is up to them.

Take a last look at your message to make sure that you have ANSWERED THE AUTHOR’S QUESTIONS. If so, fire away! There’s no obligation to say you’d be willing to test again, but if you are, it’s nice to say so.

If you are both considerate and honest in your feedback, you have met your obligation. If you’re new to this, you’ve also learned something about what it might be like to test your own game.

Hope to see some of you over at Bluesky! I just joined.

next.

Getting your own work tested.