Beta Testing your game

A Basic Tutorial
Glossary of Terms Development Tools Setting up ChoiceScript Structure of a ChoiceScript game Startup.txt Scenes Variable types Data types Indentation Basic Scene Scripting Displaying variables Basic Scripting Techniques Choicescript_stats.txt Arithmetic operators Concatenation Publishing your game
Advanced Tutorials (Click to expand)
Practical Scripting Techniques Loops Adding Sounds Automatically testing your game Beta Testing your game Style.css Choice Game Marketing

      So, after considerable effort you've begun to feel comfortable using ChoiceScript, have devised and outlined your idea for a cool new game, and have managed to produce what - to you - seems like a decent start with your story... Perhaps even a whole chapter or two? But is it really any good, and how could it be improved?

The answer is to playtest it.

Development / Testing stages

In programming / game development circles, Alpha Testing is usually performed in-house by the developer(s) themselves. Conversely, Beta Testing is performed by a number of potential users - in our case, the actual fans (often including fellow authors) of ChoiceScript games. A game still in development / playtesting stage is known as a WIP (Work in Progress).

Alpha Testing is a preliminary testing stage intended to find and resolve basic bugs and other problems. The branching nature of a typical ChoiceScipt game can however make this difficult to do properly - especially as your game grows - unless you include useful alpha testing code in your game files at a fairly early stage.

Beta Testing is a secondary, usually public, testing stage, using a number of willing testers. It is intended to uncover any remaining, rarer bugs, to deal with gameplay and narrative consistency issues, and to help refine and improve your story and the choices available to the reader.

While some public playtests are "closed" (i.e. the number of testers is limited and often by invitation only) many are "open" to the public and can be played by anyone as often as they like.

Strictly speaking, any Choice game still undergoing development (as opposed to final fine-tuning) is still in the Alpha Testing stage, whether or not it is already using actual public testers, although it's worth noting that there is a tendency among ChoiceScript authors to refer to it as a Beta Test for that very reason. If you prefer to describe your playtest accurately, however, feel free to use "Open (or Closed) Alpha Test" while still in development, and upgrade it to "Open (or Closed) Final Beta Test" when all actual development is done and you're now just refining things ready for a a final release.

Open or closed playtest?

The basic difference between an Open or Closed playtest is whether or not the link to play the game is made freely available, such as by posting it to a WIPs forum for just anyone to click on.

The advantage of an Open ("all welcome") playtest is that it's very easy to set up and announce, it helps to build up a following for your game, and even those who don't necessarily like the sound of it may at least give it a try since you've placed no restrictions on their ability to do so. In theory you should receive suggestions and ideas aplenty for how you might improve the game, as well as bug reports and similar helpful comments.

The main disadvantage of an Open playtest tends also to be the main advantage of a Closed ("limited number, invitation only") playtest, in that a significant number of people who try an Open playtest game do so only because it's free and easy, but actually have little or no interest in providing you with useful feedback. It's often argued that these "freeloaders" then see no reason to actually pay for a final release of the game, despite the fact that many Choice games cost less than the price of a glass of [insert preferred beverage].

Conversely, it's argued that the restricted nature of a Closed playtest limits the game's early fanbase, reduces the number of helpful ideas and suggestions for improvement, and can sometimes be so difficult to keep private that it's really not worth the hassle.

We continue to see both types of playtests conducted so there is no general consensus on the matter, although it would seem that the majority of WIPs tend to adopt an Open style for simplicity's sake.

Should I bother with testing before actual playtesting?

This is very much a matter of opinion, but there's a strong argument for why it's rarely - if ever - a good idea to lazily rely on your public playtesters to find & report even your most basic bugs. Not only can such game-stopping errors be incredibly frustrating for them, forcing your playtesters to start over & over again with each & every basic bug they encounter (which may cause many to lose interest until it achieves a more reliable state), it also severely distracts them from performing their main function for you - i.e. helping to improve the game, not your actual scripting of it.

It's a fine distinction, but an important one.

Two-Version development

The acknowledged best practice for developing a ChoiceScript game is to use a Two-Version development model. Quite simply, consider using two versions of every game file, not just a single one. The first version would be your development project, which is not made available to the public and in which you write your story, script your game, and perform your own vital alpha testing to resolve any basic scripting errors.

The second version of your game files would be your live project, saved in a separate folder and made available to your playtesters by publishing your game online. That Wiki article explains your options.

When you have added a significant new chunk to your development project, and are reasonably certain that you've also eradicated most if not all of the basic scripting errors from that new code, you can then commit this to your live project by the simple expedient of copy-pasting your new development files over the old, live ones, then publish (upload a copy of) the latter to your chosen online hosting service. By the same token, there's also no harm in retaining the old live project files separately as a sort of safety net, rather than overwrite them each time - whichever method you feel works best for you.

Editing live playtest files

Using the Two-Version Development model, combined with a reasonable attempt at proper and regular alpha testing, you should only rarely, if ever, have a need to directly edit any live project files. All story writing and game scripting should generally be confined to the development project version of your files.

However, even with extensive alpha testing there may still be occasions where a playtester encounters a serious scripting error in your game, and which you will wish to quickly fix in order to avoid other players encountering the same problem.

It's also entirely likely that your current development project may not be in a fit state to immediately go live with a quick fix, due to ongoing but still incomplete development in that particular Scene file (which would serve only to introduce yet more bugs into your live version), and this is the real advantage of having a separate live project version. In this instance - and generally only in this instance - it may be worth considering editing a live project file to implement a quick fix, but do remember to also immediately edit the development project version of that file and make an identical change to your scripting there, thereby keeping both versions up-to-date so far as known bugs are concerned.

Related articles

• Publishing your game
• Practical Scripting Techniques
• Automatically Testing your game