It’s dangerous to go alone!
previously, on let’s make IF…
While this article is specifically about Inform development, most of its key concepts apply to a wide variety of interactive fiction works.
In the first post of this two-post series about playtesting parser games, I discussed best practices for testing someone else’s game. You can refresh your memory here:
What about testing your own game? As I said last time, testing the work of others is a good way to understand a tester’s perspective. It’s also a good way to learn what it takes to recognize the effort involved in high-quality playtesting. That’s important: being able to appreciate the help people are giving you.
“I don’t have time to test” and other myths.
As I wrote last time, everything that gets released gets tested. Your only choice as an author is whether your work gets tested privately, with time for you to make adjustments before release, or whether the testing comes in the form of public reviews, when it is too late for you to change first impressions. It simply isn’t true that there is no time to test, because testing always happens. The real question is whether one has time to meet the deadline for an event or not. Sometimes, it’s ok to say “no” to that question. It all depends on whether you are willing to let a deadline dictate the quality of your work. Sometimes, actually, that’s fine. It all depends on your goals as a creator.
Release context changes things a lot. It isn’t terribly feasible to do a lot of testing with speed IF (Ectocomp La Petite Mort for instance), and nobody really expects that. Some events value expression over polish. There’s nothing wrong with that! But you can’t get a do-over for IF Comp, if that’s what interests you. Consider the level of polish expected for your event of choice, and go from there.
when should I start testing.
When should you start testing? A lot depends on the complexity and size of the work. IF the game not very complex (no fiddly systems, not many custom actions, modest world model), you can probably wait until you have a finished throughline (the game can be completed, beginning to end) before testing. If you have a large game, on the other hand, you probably won’t want to wait that long. My own game, Repeat the Ending, was first tested after maybe five rooms were completed. I had a custom magic system with a lot of bugs to work out. I continued to test intermittently for the rest of the project (over a year).
You do not want to write a big game with a lot of complex interaction/simulation/etc and only test at the end. What if there are flaws in these systems? Or if the fundamentals of your story are off? It is very hard to repair the foundations of a finished game, so don’t wait.
Unfortunately, I can’t provide a “complexity equation” based on word count, custom actions, number of rooms, and number of things. This is mostly a vibes-type decision. My suggestion is that you err on the side of caution. When in doubt, test.
Some things to consider before testing:
- Make sure you can finish the content.
- Run a spell checker.
- If hints are needed, either provide them or be available to answer hint requests from testers.
- If you are going to include a content warning in your game, have it in place so that you can ask about it.
- If testing will be repetitive or if players might need extra in-game information, consider providing test commands and providing a test build so that testers can use debug commands.
how do I start testing.
Once you’ve prepared and double-checked your work, you’ll need to find some testers. For this, you’ll need to go where the testers are. Forums and Discord servers are good places to look. Typically, any place where people discuss the kind of game you are making (platform/medium/content) is a good option. Social media might do in a pinch, mileage will definitely vary. Once you’ve found a venue, you’ll need to put out a call. Ideally, the call will cover a few, key items:
- Platform and or medium (“an Inform game”)
- Genre description (“humorous sci-fi”)
- Length (“should take an hour or so”)
- Difficulty/puzzle content (“puzzler, sometimes challenging”)
- Timeframe (“I’d like to get this back in a week”)
It’s best to keep things brief here. I personally like a bulleted list, though I think you should do whatever will be enable you to be succinct.
Hopefully you will get a few testers. If not, you may want to bump your post after a day or two, or else look somewhere else. As I mentioned last time, if you volunteer to test the work of others, you are much more likely to find testers for your own work. If you are a new author, look for ways to be a part of the community; this will help you. You’ll probably enjoy it, too!
You probably don’t need a lot of testers. After all, you will need some later. This is either because you will make more game (in the case of a longer work) or because you will need people to test the fixes made after testing. Close off your call after you get a handful of people, with a comment that you will need help in the future, if anyone is interested.
Don’t put your test game in a public forum. Send it via PM instead. Publicly sharing a game, even an unfinished one, can disqualify it from events. In your PM, ask any questions you might want the testers to answer. Note that, for many authors, story and worldbuilding may be as important as mechanics and bugs. Try to consider all possibilities. You’ll want to keep these questions brief as well (I like bullet points here too), just to avoid creating confusion or distractions. Prioritize your concerns and focus on what seems the most pressing.
You could try sending different questions to different testers, but some testers don’t answer questions. They just don’t! So you may regret spreading things out and getting nothing back. In my experience, it is best to send the same thing to everyone. Those who answer will send different answers sometimes, and that’s potentially useful.
Finally, tell the tester your preferred format for results. I prefer a transcript document. The transcript is a document of parser gameplay. It contains all commands and output for a play session. I further want comments in the transcript.
Because, as of this writing, the transcript functionality of Parchment (ubiquitous web player for parser games) is a little rough, it is very possible that even experienced players of parser games will not be familiar with this process. I typically say something like “I would like a transcript file with comments. If you’ve never made one before, let me know and I’ll help you out!”
I currently recommend the latest version of Lectrote (a local application for playing parser IF games) because it automatically generates transcripts.
https://github.com/erkyrath/lectrote/releases
So far as comments go, it is customary for players to type comments directly into the game, prefacing their comments with an asterisk or other symbol. You can add some code to your Inform 10 game (if that’s what you’re using) to add a searchable response (this code was initially provided to me by Wade Clarke).
first after reading a command:
if the player's command matches the regular expression "^\p|^<*+='>":
say "(Noted.)";
reject the player's command;The in-game output will look something like this:
>* I'm so happy to be playing this game!
(Noted.)
the wait.
It’s hard to wait! Some testers will get started right away. Some will take time. Some will never get back to you. Even though you might associate high emotional stakes with your project–you may have invested a lot of emotional or intellectual energy–it’s important to try to remain philosophical. Everyone else is getting to it in-between whatever else is going on in their lives. Even if your game feels very personal to you, most people will not develop similar attachments.
If this is your first time, you might feel anxious. That’s pretty normal, I think. At least, I felt that way. Hang in there! People will get back to you soon. If you need a break, this is a good time to take one. Do some non-IF stuff for a few days, or play some games. Do whatever you like; just take care of yourself.
results.
The results will hopefully begin coming in. Ideally, you will have comments in a transcript and answers to your questions. Start thinking about how to organize things. Some authors have a spreadsheet. Others manage ideas and activities in some other ways. My method is pretty simple: a to-do list at the top of my Inform 10 project. Big-picture items, such as comments about story or gameplay mechanics, go in the list. Small items, like typos, minor bugs, and the like, are dealt with, one at a time and in order, by reading through individual transcripts.
The important thing is that you have a reliable way to manage feedback; something that works for you.
Big-picture items like gameplay loops, characters, and plot may have a discretionary element. You may or may not want to change the story, for instance. It’s often good to first get feedback from multiple people to determine if there is consensus. Perhaps some love your protagonist; others find them annoying. Consider all of this, but honor your own goals as a creator, too.
You may have a lot of bugs to deal with. If there is something flawed in a core mechanic, you will want to take care of that right away! If you add more mechanics or problems, you might be building on sand. Be sure your foundations are stable and durable.
Pay attention to what people do. If the transcripts contain many failure messages, is that acceptable? Or is some polish needed? Perhaps synonyms or more informative failure responses are in order. Distinguish between challenge and annoyance. Take the player’s side while maintaining your desired level of challenge or friction.
Carefully consider the player’s comments in the transcript. Remember that you know your own game too well to know what players will think. These are the reactions of potential players and reviewers. Are your descriptions adequate? What about the tone? Do they ever express frustration or annoyance? These comments may be immediately actionable or else turn up on a to-do list somewhere.
You can ask clarifying questions of testers. One round of questions is my recommended limit unless tester replies suggest an interest in discussion. Wait until all of the feedback comes in, then determine your top issues. These should be big-picture questions about design and story; their answers will inform your to-do list.
If you had positive experiences with a tester (even if the feedback isn’t all praise!), you can ask them if they would be open to doing more testing in the future.
disagreements.
If your experience is at all like mine, you may have some disappointments. Some players may never get back to you. Others may not “get” what you are trying to do. Still others might not answer your questions, or comment in their transcript. I know it’s easy for me to say, but don’t be bothered by this. Do your best, at least.
As I said earlier, anybody who volunteers to test your game is offering up their spare time. That’s a precious resource! There might be a million reasons for someone not to do all that you asked, and, chances are, it’s got nothing to do with you. Try to see that your disappointment and someone else’s unavailability can both be real, and that the relationship between the two is probably not malice. Try to stay out of your feelings.
It might be a little harder if someone expresses overt disinterest in your work. That feels more personal, doesn’t it? However, it’s useful information. No matter the quality or effort, some aspect of your game might be rejected by certain people. This is something you actually need to know. It can prepare you for reviews and reception later. On the other hand, you may want to make changes to please such players.
There were multiple times during the production of Repeat the Ending when I said to myself, “Oh, well, this isn’t a game for everyone.” That’s a really healthy thing to recognize and accept. Such testers will help you get there.
You do not want to argue with testers. It will probably hurt your reputation and possibly limit your chances of finding future testers. Besides: you wanted to know what they think; you can’t argue with their experience! It’s theirs, after all. Thank them and move on. While IF is a hobby for nearly all of us, professionalism is a good model for dealing with tester disagreement. Try, once more, to stay out of your feelings.
looking ahead.
While some testing experiences can have a cost in emotional energy, you have hopefully made net gains thanks to a better understanding of your project. Should you change the story? Alter the mechanics? Stay the course? That’s all up to you, of course, but you now have an idea of how detached audiences will respond to your work. What are you trying to do? Win a contest? Get good reviews? Publish an iconoclastic work, critics be damned? Weigh your own artistic goals against the feedback you’ve received and make some decisions about the future of your work.
It may seem early but consider when you might do another round of testing. These are good mile markers for a project–test dates. If you’ve made a lot of changes to a complex gameplay loop, you’ll want somebody to check them. Perhaps you’ve added more content to a longer work: that means more testing. Try to think about larger projects in an iterative way, and plan accordingly.
After all, everything gets tested eventually, but you get to decide how and when.
next.
I’ve resumed work on Marbles, D, and the Sinister Spotlight! Wow, what a doozy. Lots of varied text working in context with scenes. So much to do! I’ll try to have something up soon.
top expert 