Alpha and beta testing
After all designing is completed for a scenario, there are two testing phases. The first, alpha testing, is similar to the testing you've been doing so far. But instead of just testing the latest section you've completed, you'll be testing your entire scenario, beginning to end. Make sure that's it's possible to play through the entire thing as intended. Look for errors: sometimes when writing code for the second half of a scenario you'll accidentally introduce a bug into the first half of a scenario. Look for typos. Pay attention to the flow of your story. Does your scenario make sense as a cohesive whole, with each event in the story feeding into the next? What about combat? Do you only win fights when you get lucky? Or is every fight a breeze, over too quickly?
It's important to be critical of your own work during alpha testing. It's easier to fix problems now than after release. And while other people will be playing your scenario during beta testing, it's best if they don't suffer through bugs you could have found yourself. This scenario is short enough to complete all alpha testing within a hour, but you should expect a much longer testing period for larger scenarios.
Once you're confident in your work, it's time to move to the next phase: beta testing. Head over to the Blades of Avernum forum and make a topic asking for beta testers. There are two options here. The first is to ask everyone to give you their e-mail addresses, then zip and e-mail the scenario to them. You'll also have to e-mail your scenario to all testers whenever you make a change during the beta testing process. Testers can give you their feedback either through e-mail or private messages (PMs).
The second option is a public beta. If you have a website where you can host your work in progress, upload it and provide a link in your forum topic. Now anyone can download and play your scenario (and, ideally, provide feedback). There are pros and cons with each approach. Public betas require you to have a place to host your scenario, but if you do, you don't need to get personal e-mail addresses from your players. Private betas require you to be in direct contact with your testers, rather than testers choosing to contact you as is the case with public betas, but on the other hand people who sign up for private betas tend to be more committed. Additionally, you may not want to have your unpolished work available to the public quite yet. For this project, I went with a public beta:
![[IMAGE]](/static/tutorial/testing/post.jpg)
NOTE: My intent was to use actual beta testing reports as examples. However, no one responded to my request for testers, even when directly asked. I suppose this is a lesson in itself.
There is one obscure bug I deliberately left in to be found in testing. If you return to the hideout after opening the chest, the closed chest will still be there (you won't be able to open it, though). Additionally, if you trigger the chest, but leave without fighting the goblin, the goblin will not be there when you return, thus stopping you from winning the scenario! The chances of this event happening is small, but it's still possible. When testing your scenario, it's important that you and your beta testers approach encounters from every angle, and actively try to find flaws. This is one reason why beta testers are so important: other people might play with a different sequence of events than you expected.
In this case, the bug fix is simple. At the end of the INIT_STATE, add the following code:
if (get_flag(1, 2) == 1) {
set_terrain(8, 5, 0);
if (get_flag(0, 1) < 2) {
activate_hidden_group(1);
}
}
If the chest has been opened, the chest terrain is removed. If the chest has been opened and the goblin hasn't been killed yet, (re)activate the goblin's hidden group.
That's all the changed we'll be making for this scenario, but for other, longer scenarios you can expect the beta testing period to last longer. Even if your scenario is free of bugs and typos, you'll still receive on combat and story. Balancing combat can be tricky, and you might have some players find it too easy and others find it too hard. In general, it's best to err on the side of "too easy"; players might be bored of too easy fights as they progress through your scenario, but too hard fights will stop them from progressing though your scenario at all. It's also a good idea to ask your testers what kind of party they're using; specifically, what level, how many characters, and what kind of skills and items each character focuses on. A party of fighters and archers will be challenged by different kinds of encounters than a party of priests and mages.
Feedback on your scenario's story can also be tricky to handle. Like any story, it's important that your scenario has a firm introduction, steady rising action, an exciting climax, and a strong conclusion. Your testers will undoubtably have (possibly conflicting!) opinions on the characters and events in your story. Be willing to incorporate their suggestions if it improves your scenario (and be sure to do another round of testing whenever a major change is made). At the same time, it's impossible to please everyone. You're at the last stage of scenario design, and you should hesitate at adding a lot of work just to please one or two beta testers. You have to release your opus sometime.
Above all else, treat your testers with respect, and thank them for volunteering their free time. Once you're fully satisfied with your scenario, it's time to finally release it.
