My ‘ideal’ is 20 testers. I’ve never actually made it that far, though. I think 12 or 14 is the most I’ve ever had. Testers help my games so much, I wish testers could win awards for being great.
2 Likes
I would hope never to change the story or the design of a puzzle (unless the puzzle is a complete disaster). At the point where a tester sees the game, the design should be completely locked down.
I’m also currently having a game in betatest, so I dare to disagree. 
What kills me regularly the replay script (don’t know what’s the correct word for it in TADS or Inform) is that someone tries something “wrong” and I think “Damn, that should work.” - and so I add it to the code. So when I rerun such a script, probably an item is gone or an action is already done in a completely different way, and as a result of this the script fails. So this is why I think that fostering and updating this replay scripts for your advanced tester is maybe something that’s crucial for them reaching the end of the game.
There are about 100 rooms and 70 or 75 distinct puzzles. Some of the puzzles are multi-part, some require logic and close observation, and some are simply find X/use X. Also, there are at least 8 NPCs, some of whom are very chatty – that is, you can ask or tell them about all sorts of in-game topics, and a few of their responses may give you in-game clues.
Sounds really promising and definitely big enough.
Another appreciation is the number of testers listed. To test a game in its final steps you need 2-4 players, never 9. Then, who are going to judge and vote it?
Not more than 2-4 in the stage of testing when there’s a high risk that some logic stuff breaks seriously. 9 testers for details, language issues and general feedback (e.g. a puzzle needs a stronger hint) seems appropriate to me.
1 Like
I think you aren’t right at this point. I agree with articles mentioning chain testers, one by one, and even more online realtime testing as we did in IFmud.
Edit: I would become totally mad if I had to listen to 20 people talking all at the same time about what is right or bad implemented in my game.
2 Likes
Hmm, I will try out that way with my next game. I think I will do an Ectocomp game this fall so maybe I’ll do chain testing and/or realtime and then report on my experience with both ways.
1 Like
For anybody in here who’s claimed they enjoy testing big games, I’ve got a 200 ish location game that will probably be ready for testing in two months or less… I’d probably take warp chunks or whole play throughs or whatever I could get…
2 Likes
If this is a common belief, I am in so much trouble. I changed a LOT of stuff in each of my games after the first round of testing. Narrative changes, puzzle changes, even radical redesigns of the entire structure.
For me, that’s part of what testing is for-- to see what isn’t working and what needs changing, even if that’s really big stuff.
4 Likes
You can count on me. I will be pleased to test your game.
Totally agreed! I’ll be starting a second round of testing for my current game in a couple days’ time and the game is almost unrecognisable from the way it was before the first round in March. Sometimes testing helps you realise that there are really huge changes that need to be made.
3 Likes
That can certainly happen, and I applaud you for being willing to tackle the big changes. It just hasn’t been my experience, that’s all.
I seem to recall that a couple of testers wished “Heavenly” had been structured differently, but I didn’t quite see how I could manage it. Once in a while I think about going back to that game, tearing it apart, and making it deeper. At the moment it’s kind of a one-trick pony. Maybe the Strolling Sugar Cookie Girl has an agenda…
2 Likes
[quote=“Jim_Aikin, post:49, topic:56259, full:true”]
That can certainly happen, and I applaud you for being willing to tackle the big changes. It just hasn’t been my experience, that’s all.[/quote]
I’ve certainly found I do less reorganization than I used to after sending something off for testing. So it may be partially a matter of experience. (Not all, of course.) Certainly, my first few efforts, I had some idea how to organize things, but I was still learning how and had a lot of “Oh, it’s obvious now I see it” moments. (I still do. I wish I had more. Those help you grow!)
I forget where I read it (Emily Short’s blog?) but I remember reading that Alpha testing with people you’ve worked with before is a great time to share a very rough big-picture draft, because if you’ve slipped up, they won’t run screaming from the mess. Beta testing, not so much.
It’s a tough balance for me when to send stuff out for testing to people I may not know. If I wait until everything is in place, that’s too long. So I generally accept one or two things won’t work, and transcripts that say “why not do it this way” will unlock something better. Also, maybe part of the problem is that I get bored after a certain amount of planning and just want to hack at things.
I’m willing to give authors a couple mulligans on “hey, I haven’t figured this out yet, but I have a good-enough idea, and I don’t want the perfect to be the enemy of the good.” And I’m grateful when my testers do so. It’s tough to figure out that line of getting something out there vs getting something polished out there.
My style is I’m willing to potentially miss on a few things and fix them later, even if people might see them in-comp, because I enjoy the process, and I find I need to push myself to find that next idea.
And I certainly think if I got something with huge holes or a need for reorganization from either of you, it wouldn’t ruin my enjoyment of getting a sneak peak at something cool before everyone else did.
4 Likes
Thanks, Jade! I’ll jot that down so I don’t forget in a month or two…
1 Like
This is probably the big difference between alpha testing and beta testing. Most IF authors skip alpha testing, but if you feel you need it, go for it. Just make it clear to your testers that it’s a work-in-progress and dramatic changes may be made pending the outcome of their testing.
Nah, we thrive in the cloudy and opaque primordial self-congratulatory muck, far away from prying eyes.
----pats self on shoulder----
3 Likes
Alpha tests look for functionability issues. Interface, commands and system errors, typos, punctuation.
Beta tests look for usability issues. Breaking of inmersion (MIMESIS), deaf parser.
Betatest round 1: Play the game as generic player.
Betatest round 2: Try to break the game anyway.
- Jade.
1 Like