would it not be helpful to highlight to the beta tester issues that have been found. It’s no good send a email list 37 different errors within a game when 36 of them have already been found. It not only wastes the beta testers time but the writers time as well because he/she will have to read the email and check if the error has been addressed.
If the writer wants the beta testers help in making his game better then surely they can find the time to ensure that the beta testers are kept in the loop, even if it is only with standard replies. Apart from anything else it’s just being polite.
The other thing I have just thought of (while having a bath) is do the writer know who is beta testing there game?
I doubt I will ever do another open beta. I receive tons of feedback that boils down to requests for customizations (like @Mary_Duffy mentioned in the other thread). I also received reviews stating they were upset there was not much more content in the published game than the beta (50k words isn’t much, I guess).
I still run a core closed beta group while I write and will run short-term betas at milestones. Otherwise, open betas are a thing of the past.
Correct me if I am wrong (which I normally am) but in beta testing arn’t the betas looking for errors in code / game play and spelling mistakes rather than giving there opinion on how the character should behave or this should happen in that scene etc?
Here is what Jason prefaced my beta test with–I didn’t check to see if this is standard:
"I’m looking for “high level” and “low level” feedback. Not mid-level feedback.
"Low-level = typos and continuity errors. A continuity error is when a character’s gender flips, or someone comes back from the dead, or you run into a plotline that just doesn’t make sense (because it’s probably a coding error).
“'High level” feedback has to do with things like plot, pacing, and characters. “Scene A didn’t work for me because x, y, and z,” is useful feedback. “B character was entirely unsympathetic, because u, w, and v,” is also useful feedback."
I’m not sure where “how a character should behave” falls on the mid-level/high-level spectrum. Probably it has to do with how broad the feedback is.
I hate looking for spelling mistakes and generally avoid doing so. Yes I’m the annoying person who will say “there are multiple spelling mistakes” and then not point them out, but I figure they can ask someone else to point them out, or look for them themselves. I’m not going to do the part of beta-testing I hate the most.
Code errors are generally picked up by the quicktest tools (although there are sometimes errors still in the game.) I do make note of any I come across, and read the code once I’ve finished playing to pick up anymore errors I see in that. There’s a few common errors that the testing tools won’t pick up, but it’s easy enough to spot as a beta-tester. Pronoun problems is one of the most common of those.
I keep an eye out for any unexpected stat changes too. If stat changes don’t seem to make sense, or if the stat bars are moving in the wrong direction. Also missed brackets on variables.
I generally gave feedback on everything I could think of. How consistent characters acted, if there seemed to be minor choices missing. I’ll usually comment on inclusivity stuff as well. That’s me though.
During our Monday call, we resolved to do the following:
When a game goes to copyedit, we’ll send an “the beta is now closed; thank you for participating” email.
We’ll encourage authors to respond to beta feedback: either ask clarifying questions, or send thank yous as they see fit.
We’ll invite authors to a closed thread where they can discuss a game with beta testers that have submitted feedback. We’ll see how that goes.
We’ll encourage authors to submit a (brief) changelog with beta updates.
@Mara I’m sorry you misunderstood the “one beta at a time” rule. As soon as you submit feedback on a game, you’re free to apply to other betas. You don’t have to wait for a beta to close. You just have to submit feedback. It’s only if you apply to two betas simultaneously, or apply for a beta when you haven’t provided feedback on a previous one that is still open that you are denied. And, as long as a beta is open, you’re free to keep playing and providing more feedback, even if you’ve joined a new one.
My attempt to communicate succinctly failed; I apologize. I’ll attempt to clarify my statement and leave it at that.
“schedule” in this regard, is not a work schedule given to direct the tester but rather a communication of “projected deadlines and milestones to be met and achieved”; the purpose of which is to help the tester focus on areas of which the author/developer is currently working on. Feedback given after the work has been finalized is an example of what this communication tool is geared towards preventing.
“testing needs” is not CoG directing the tester on “how to play the game” which in of itself is both counter-productive and results in skewed testing. Rather, it is the communication to the tester on the order of the “We need high level feedback and low level feedback”
The author/developer can often get specific feedback on areas of particular concern by just stating what is of concern. Something akin to: “I am having particular trouble with this particular scene; how is it working for you guys? Are there too many repetitions, or does the repeating make sense? Is the lore provided here in context working or is it overwhelming you as a reader?”
This focus on communication would increase the efficiency and the quality of the testing and testers themselves would not feel like they were spinning their wheels in the same rut over and over. More importantly, this would give the author better feedback which was more actionable and on point to their specific needs.
Thank you for taking the time to listening to me - I hope the process and experience will be more fun and productive for everyone involved.
Well In Spanish law that was no contemplate so I didn’t know That was a issue in America. Here if you firm or even accept a basic form you could basically do the same as a paid professional except the consequences of the break it.
However a way to direct us without affecting that law is simply a Update description that’s perfectly legal. For what I have check on internet .
12/16/16 Update 2.12 Changed Fred dialogue adding new content in x path.Added new ending.
That’s legal and we as testers could totally freely say oh maybe I should check out that… Or not… So you have not violate any law. You didn’t change my neutrality.
After playing MUDs for 20 years and being a part of various processes in both player & admin roles I’d say you have your solution.
Create a private forum thread with topics inside of it the list of games currently being tested.
Then have each thread password protected and only accessible to the author and beta testers.
That allows an inclusive testing process rather then a top down structure where testers feel their feed back is going into a black hole akin to letters to congress.
I’m new to Choicescript but for the last year I’ve bought and played nearly every choice game on the market that appealed to me.
If testing feels like work then you will have to add appropriate reinforcement in order for people to continue with the behavior. Free access to a few games doesn’t seem to be cutting it, but access and feeling valued certainly will.
Belatedly: I just wanted to say how much I value the feedback I’ve had over the years on the XoR forum thread.
It would be a much weaker game without the steady flow of feedback there, and I intend to keep writing future games in the series with ongoing testing on an open forum thread.
I can understand that it won’t be for all authors; but I’d much rather have feedback at a stage when I can still change the game to accommodate it than only offer it up for testing once it’s pragmatically too late to deal with significant changes.
So, I was just talking a little about this process with some people, and I had an idea which I was wondering if it’d be useful
When I decide if I want to buy a CoG, I always use the preview of the first few chapters to see if it interests me. I’m wondering if it might be useful to include a similar preview for official beta tests as well. I think I would be more likely to join a beta test if I could see the the writing of the game intrigues me, rather than going off of the description. I’d imagine that many other potential testers might feel similarly, and I’d think it could be a way to garner more enthusiastic and specifically-interested testers as well.
I can also understand if some authors might not want a preview of their early draft available to anyone, but if that’s the case, I’d suppose it could be the author’s decision, yes?
(Sorry if I shouldn’t be bumping such an old thread, but I thought it’d be preferable to starting a new one, yes? )
I’m not sure I understand why that would necessarily be a negative I’d think that people who’d comment on the preview but not the full game wouldn’t give any feedback at all if no preview is provided, so I don’t think CoG would be losing any feedback
I can see how they would be similar on the receiving end, but I don’t think they’d feel as similar on the user end.
Joining a beta feels like more of a commitment than reading a preview, and it’s a commitment based on a premise, not something more substantial, like a sample. And since you’re not supposed to join more betas until you’ve sent in feedback, it’s not as easy to see “oh, yes, this is a game I’d really like to test!” before taking the plunge. I could see a preview as a way to entice people in who might not otherwise try it out at all.
I realize that I am speaking for myself, inasmuch as previews like these would definitely draw me in… so that’s why I’m inquiring here, to see if anyone else would similarly find that previews would catch their interest more than blurbs.
Alternatively, if a preview is too much, perhaps just including a writing sample might help?
My experience with beta testing has been very rewarding, but a lot of it requires self-motivation.
From my understanding, the company cannot direct beta testers in any way as far as length or quality of feedback, or going through the scene files with something like Notepad++, or anything like that.
The reason is that once they start directing people, they may be considered “employed” and there’s too many complications that go along with that.
Of course there are staff members like Rachel, but she has her duties and is paid.
The beta testing thing is entirely unpaid.
What you do end up getting is your name on the credits list.
The projects I’ve beta tested were of final-draft quality, almost ready to go to production.
It’s hard work and takes a great many hours to go through the files line by line and then follow along in a browser window to see if the story makes sense, is engaging, has no continuity errors, coding errors, is of sufficient length, etc.
But you know what? I appreciate the chance to do it.
It helps me to sharpen my own skills, and helps build a positive rapport between myself and the company.
(A good thing, I think.)