A Beta and Playtesting Guide (with emphasis on the Debugger)

Get started with the upcoming AAO version 6.

Moderator: EN - Forum Moderators

Post Reply
User avatar
E.D.Revolution
Posts: 5743
Joined: Mon Jul 26, 2010 9:00 pm
Gender: Male
Spoken languages: English and decent Spanish
Location: Across dimensions, transcending universes

A Beta and Playtesting Guide (with emphasis on the Debugger)

Post by E.D.Revolution »

Original guide written by Rofpa for Court Records.
Copied and Rewritten with permission.

This guide is written with the newbie authors in mind. Most of the intermediate or experienced authors will not find this useful as they know all the stuff that is written.

I've covered this part of the game creation process at length in the Comprehensive Guide. The topic is actually so broad and important to the creation process that it warrants its own guide. Rofpa, a prolific author in Court Records, has made a comprehensive PyWright guide, and is also the author of a few well-received fancases for PyWright. As such, he knows what he's talking about. I'll cover AAO-specific stuff after Rofpa's words.
Ropfa wrote:WHAT IS BETA-TESTING?

So, beta-testing could possibly be the most boring part of making a case. Basically, what you do is go through your game and play it over and over and over until it reaches a quality that you are satisfied with. You need to find bugs, spelling errors, grammar errors, plot holes, and all that fun stuff. Oftentimes testing the game can last just as long (or longer!) than actually coding it.

However, it's also one of the most important parts of making a case. This is when you fully review your own work and decide how to make it the best it can possibly be. The more you test your game, the better the end product will likely be. Simply put, beta-testing is an essential part of making a fancase.

In case that wasn't clear enough...

YOU MUST BETA-TEST YOUR CASE THOROUGHLY IF YOU DON'T WANT IT TO BE A STINKING PILE OF POO.


I cannot stress this enough. No matter how eager you are to release your case, DO NOT DO IT without properly testing it first. What do you really want people to play? A good game that took a while to make? Or a bad game that was released a few weeks earlier? If you were a player, which would you rather have?

If you don't beta-test your case, then you will inevitably leave in several mistakes that could have easily been fixed. Think Big Rigs: Over the Road Racing (perhaps an extreme example, but you get my point).

If you're fine with it being a stinking pile of poo, then feel free to not test. Just be sure to expect extensive negative criticism from your players.

It's also important for you to have others test your case for you. This way, you can get a variety of opinions and suggestions for improvement. Other people are also often able to more easily notice problems that you wouldn't. Many times writers (myself included) find it hard to see mistakes or logic errors in their own work. Outside opinions help remedy this.

Again...

HAVE OTHER PEOPLE HELP YOU TEST YOUR CASE. DON'T DO IT ALONE.

So what does this incredibly important process involve? Well, first you should play through the game enough yourself until you get it to a point where your testers could also play it without running into any game-breaking errors. Not all beta-testers are experienced coders, so they may or may not be able to figure out how to proceed if they run into something big. Once you've done that, you can recruit people to test for you.

I personally usually have three or four other people testing my cases. It gives you a decent range of opinions, while still keeping it small enough that you don't have half the forums playing your game before it's officially released. Most of the time they are people who've already helped with my game, as a sort of thank you. If you personally think this number is too big or too small, feel free to adjust it to fit your own game's needs.

You can either put out an open application for testers or ask specific people. I've worked with several people in the AA fandom whom I would consider to be good testers. Generally, people who have already worked with fancases will give good feedback, because they already know what problems to look for. However, there are also many people who've never touched a fangame before but still know how to give good feedback.


FOR THE CASEWRITERS
Make sure that your testers know what to look for. You want good feedback, so if they should keep a lookout for specific things, let them know.

It's okay to beta-test a game without all of the artwork completed. You can just use placeholder images. Let your testers know beforehand that not everything is complete. Then while you're waiting for their responses, finish up the artwork.

I personally don't generally give my testers deadlines. We all have lives outside of Phoenix Wright and many people are busy in real life. Whether you set a deadline or not is up to you though. Be generous though. This is fan fiction; nothing here needs to be on a strict schedule.

While you're waiting for the testers to respond, don't just spend the time twiddling your thumbs. Use this time to finish anything you need to or make improvements to your game.

And of course, be sure to thank them once they've finished.


FOR THE TESTERS
Your goal is to give decent feedback to the creator. Think of anything you can for how to improve the game. This is not just an opportunity to play the game before everybody else. You need to be helping the creator make this game as good as it can be.

And if it's already a good case, don't just say "Hey, your case is so awesome! I literally can think of nothing to improve it!!1 Perfection!!! :fran: "

If you do that, then you fail as a tester. There is ALWAYS a way to improve. Always be on the lookout for opportunities to make the game shine.


ONCE YOUR TESTERS RESPOND...
Make the changes they recommended. For plot changes, you are not required to make every single change. This is your game, not theirs. If you think a change might alter your game too much from your vision, then don't do it. However, do keep in mind that if a tester thinks something can/should be improved, then many of your players will probably think the same thing. Don't ignore everything your testers suggest. Otherwise, there was no point in testing the game to begin with.

Once more...

DO NOT IGNORE EVERYTHING YOUR TESTERS TELL YOU.


You should have a good reason for passing over recommendations. Would the change conflict with a future plot point? Okay, don't change it.
Would the change make one of your OCs do something you know they wouldn't? Okay, don't change it.
Do you just not like the change because it would require you to put a bit more work into rewriting a scene and you prefer to be lazy? If that's the case, then it's maybe a good idea to just suck it up and make the change.

Once that's all done, run through the case one final time to make sure that everything still works. Then go ahead and release it.

Even with you and a few other people testing, your players might still find mistakes. That's no one's fault. It just means you and your testers are human. Just imagine what it would be like if nobody tested the game in the first place.



tl;dr version: Don't be lazy. Beta-test the game so it's not crap.


Anybody else who has advice on this important step to case-making, feel free to leave your input.
This is good advice for anyone who is thinking of making their own fangame, be it AAO or anything else. Most of the stuff he's talked about are also stuff I've talked about. I won't repeat any of his stuff. Now, AAO v6 has quite a bit of features for Authors and Collaborators. The most important feature, however, is the playtest feature. You have the ability to playtest your own game. Use it. It's there for you to improve your game.

Now when you get to the playtest/debugger screen, you'll see it looks somewhat like the Player. The big difference? The right panel. It's called the debugger. This can pull or manipulate useful information about your trial. Of course, the debugger is useless if you don't know what does what. Even though I covered this in length in the Comprehensive Guide, I'll cover it again here:
  • Player Status: Tells you about the order of the frames you're seeing and what position of the frame it is in relation to the rest of the frame. Now, there's two things to note. There's the Frame ID and the Frame Index. Do NOT confuse the two. Frame ID is the ID number of the frame you're viewing. Frame Index is the position of the frame in its playing order. You may have noticed that some of your frames are all over the place in the Editor. This is why you may see a discrepancy between ID and Index. For example, let's say that you have a set of the first 9 frames with the following IDs in this order: 3, 24, 66, 1, 69, 96, 50, 31, 82. Using the ASCII chart below, you will see how the Editor interprets the order in this manner:

    Code: Select all

     Frame ID | Frame Index 
        3     |    1 
        24    |    2
        66    |    3
        1     |    4
        69    |    5
        96    |    6
        50    |    7
        31    |    8
        82    |    9
    Now, the good thing about the Player Status is that both ID and Index are input boxes. You can input a number at any time to either revisit a frame or skip certain frames. This is the most useful feature of the debugger for two reasons. One, if you want to playtest a later part of the game but you don't want to go play all the way to that point, use this feature to skip over parts. Two, if you see a spelling, grammar, action, effect, etc. mistake on a certain frame, you can tell which frame it is by its ID number. This makes editing much easier for you.
  • Variables: Useful if you're doing variable work, such as press-all CEs or conditional checks or such. Once the Player reaches a frame that has a variable-affection action attached to it, you will see the debugger write out the variable name and value. Alternatively, you can define variable names and their values before the Player does that for you. However, once it is already printed, do NOT touch it. This is the buggiest part of the debugger, ironically. You can mess around your trial with this feature, but you can easily bork and break your game. Exercise extreme caution.
  • Court Record: This concerns all the pieces of evidence and profiles that you have set for this game. You can toggle each piece of evidence or profile on or off depending on the situation. It is very useful for both toggling pieces of evidence you need at later parts and removing those that you have already updated. This is the second most important feature of the debugger.
  • Scenes: If you have an investigation going on (have investigation blocks), you can toggle locations that one can travel to. You can also toggle conversations on and off per location. Conversations toggled on can be read by the player and vice versa. Again, if you need to go to a later part of the investigation without playing through the whole case again, this would be very useful for you.
  • Frames: Has the Player watch that a certain frame has been played. Arguably the most useless feature.
Use all these features of the debugger to fix your game. Betatesters won't be able to see the same stuff you see under the debugger. So use fix as much as you can before calling in betatesters.

In all, don't neglect this process. You NEED to playtest and betatest your game before you release it. Your audience and game will thank you for it. If you don't, as Ropfa said, your case will end up "being a stinking pile of poo." You don't want to produce a pile of crap for a game, do you? If you do, get out :tigre: ! You're in the wrong business. If not, please take the time to playtest and betatest your game. Your betatesters are there to help you improve your game. By the time you have completed this process, your game will have been improved significantly. So don't neglect this process.
Image
Post Reply