I am nearing completion of my first ever work of IF. I am hoping to enter it in ParserComp 2021. It is relatively small in scope, I think, about half the size of Impossible Bottle for those who have played that. I would like to find some folx to beta test the game but I am uncertain what realistic expectations are for the process. How long should I give testers? When do I post the request for testers? How much time should I give myself to parse and implement the feedback from the testing? Things of that nature. Thank you in advance for any help.
I’m really extreme with this, but I like to have about half my development time spent in testing, just assuming that there are going to be parts of the game that need overhauling.
I think it’s more normal to have a few weeks spent testing, and usually giving testers about a week to test it out.
Most of the testing I did for last IF comp came in 4-6 weeks before the deadline, with a couple of late test requests just a few days out. Requested turnaround time generally a week (but I usually turn mine around within a day or two). I’d think that you’d want it complete and self-tested enough before you get to that stage that you can be confident you won’t need months to overhaul it after a first round of testing.
I got the core code and original iteration of the backgrounds in for Budacanta in just over 2 months. At that point, I started testing, even though I knew my game still wasn’t finished at that point. What I did have was a minimally-viable product (the smallest amount of game I could submit and not feel completely embarrassed). While you can wait until you have a full game, you can do the first few cycles on a partial code base. The golden rule, however, is that every game must at minimum have the final cycle done on the exact version of the game you propose to publish. (The technical term for this is confirmation testing).
I also auto-tested my game before inviting anyone else to playtest - investigate what options are available to you for your authoring system (Ren’Py has a built-in auto-tester called Lint, some other systems either have their own built-in systems or accept modules for auto-testing). This reduces the amount of typo-based code errors and generally makes things a bit easier and quicker for play-testers. If you have an auto-tester that works with your authoring system that you’ve not run on your game yet, do that before inviting the playtesters on board.
If you’re going for a semi-open playtest (i.e. for the game to be playtested by specific people you don’t know), I’d put the request for playtesters in as soon as you have a minimally-viable game that (if relevant) you’ve auto-tested. The earlier you start testing, the more chances the testers have to identify issues, and the more chances you’ll have to fix them. You can use the same core of testers through multiple cycles, though for long games, mixing things up some is advisable to increase the number of perspectives.
Strictly speaking, I had my game in testing for a month. During this, I had three test cycles - of me sending the game to select testers, getting their feedback, prioritising and putting in the fixes. However, I was finishing the game’s intended scope during the first test cycle, and during the other two test cycles I added more features. (In particular, the last version got music added two days before submission, resulting in me taking one tester aside and staying with them while they tested it - because I knew it wouldn’t get done in time otherwise. I count this as part of the third cycle rather than a fourth separate one).
Expect it to take between three days and one week between giving your game to your beta testers and them returning with a full report, though some testers will respond a lot quicker. Checking in regularly and politely, actually fixing stuff they mention and giving the testers proper credit in your game will all help with response time… …but having multiple testers is always wise in case life gets in the way.
My first cycle was longer than the others because the problems were bigger and more numerous than in later cycles. Cycle 1 took 2 1/2 weeks in total, whereas the others were 1 week each. Give yourself as much time as you need to parse and implement feedback. However, plan with the ParserComp deadline in mind, and give your testers enough time to test the fixes you make. Consider improvements in the broadest range you can - sometimes testers will give you feedback on things that aren’t strictly errors, but are things you can do to improve the game in other ways.
In the end, the only request I didn’t manage to fulfil was that I never did find a compatible Linux installer (rather than the unzip-and-run method). However, if you can’t fix everything that is found, it’s OK to just prioritise the most important issues (especially those likely to stop the game from running, crash the game or render it accidentally unwinnable).
Thank you for the replies. This helps quite a bit.
It really depends on the size, complexity and difficulty of the game. My gut feeling is one month. For a small to medium sized game that’s not too difficult, a good tester should be able to get through it in a couple of days (remembering that it takes a lot longer to test a game than to just play it). So allow a week or two for testing, a week or so for bug fixing and enhancements and a further week or so for the second round of testing and bug fixing.