Better Than the Worst:
A Newbie’s Guide to Sidestepping Ridicule
The 2008 Revival
Part Seven

By Jeremy Bursey (Pepsi Ranger)

Well, now that your game is finished, your treasure chests sound suspiciously like your flip-top cellphone snapping shut, and you’re ready to reveal the whole package to the world, it’s time to start thinking about your rough spots.

Lesson #14: Playtesting is for Winners.

We all know that feeling we get when we made something cool. We can’t wait to share it with the world. But we also know the rough spots might mar the experience for players if we upload it too early. So what do we do? Find playtesters, of course.

First of all, any long-term member of the community will tell you that getting a good playtester is hard. Most of the time no one wants to volunteer. Of the two that do, at least one will only play half the game. In short, commitment is a bad word in the OHR community and playtesting is one of its redheaded stepchildren. But to make the family complete, it can’t be shunned. Redheaded or not, that magic playtester must be found.

Before you find him, though, you need to set your guidelines.

As anyone can tell you, the point of playtesting is to find the game’s flaws. Not only does this include technical details like finding coastal tiles that don’t animate or cut scenes that break halfway, but also story points that don’t work or characters that don’t belong to the scene. When you start recruiting playtesters, make sure you tell them what you expect.

“But won’t this turn them off even more?” you may ask. Well, it might, but that’s the risk you take to make the best game you can. The idea behind playtesting is not to give the tester a free play, but to utilize his or her viewpoint to better shape your game. Again, this not only includes technical details, but story points, as well. Perhaps there’s an angle you didn’t consider in that scene where the king betrayed his guard—like maybe the guard flipped off the king. The playtester might find it. Does it mean you have to use his remedy? No, but you still need to ask for his viewpoint. The same applies to scripting issues, grammatical issues, etc. When you start recruiting for this position, make sure you ask at least one of your volunteers to look out for stuff like that.

Secondly, it’s important to know what you want them to find. For me, I like to have one guy who’s never played the game to give me a general opinion; one guy who has strong opinions about the game to give me feedback on specific scenes (about what works and what doesn’t); and one guy who will explore every nook and cranny to tell me what’s broken, what has unresolved solutions, and what’s missing wallmaps. But, like game design, the playtesting needs are subjective for the game. Because my game is stuffed with multiple directions and hidden Easter eggs, I need to recruit the third playtester, whereas someone making a straightforward game may only need two.

Thirdly, you need to make your playtester’s job as easy as possible. Tell them up front what you know is wrong with the game so they don’t waste time telling you what you already know. Draft a progress log of your game’s development (like mine) to show them what’s new or changed since the last update. Anything you can do to make your playtester’s job easier is better for you in the long run since they’ll stick with your game longer if the hassles are eliminated.

Lesson #15: Don’t Be Afraid to Use a Bug Zapper.

“What if we’re afraid to use a bug zapper?” you may ask. Well, read the title of this lesson. If you’re gonna make a game, you might as well use every resource you can. This includes the use of Bugzilla.

For anyone who’s traveled into the realm of Bugzilla, you’ll know it’s the number one resource for squashing bugs and requesting new features. For anyone who’s actually read the entries submitted there, you’ll know the site really works. The engine adopted the use of custom menus recently because it was nominated on Bugzilla.

So how does it work? It’s simple, really—just like any community site. You register with your email, create a password, enable cookies if you have the option, and start submitting descriptions of trouble areas. The trick is to make sure you don’t submit something that’s already been mentioned.

There are three advantages to using Bugzilla: you’re more likely to fix your game’s broken places, you’re more likely to get the feature you want implemented, and you’re more likely to get the feature you want implemented faster than if you stay away from the site. There’s really no reason to avoid it.

“So what you’re saying is, if my hero won’t walk up the hall, I should create a bug report for Bugzilla?” Not necessarily. First check to see why he isn’t walking up the hall. Are you pressing “up” on the keypad? If you press the End key or anything other than “up,” then your hero won’t move in that direction. If you’re pressing the correct key and he still won’t move, then check your wallmaps. Go into the wallmap editor and make sure you didn’t block off the hall with a flashing silver wall. If both of those check out, then check your plotscripts. If your activated plotscript doesn’t have the words “suspend player” in fine print, then you’ve found a reason to submit the entry for Bugzilla.

To submit the entry, first log into the site, write the description of the bug in the appropriate field—be thorough—highlight the appropriate system arguments in the selectable fields, and then hit “Commit.” Once the site gives you confirmation that Bug ### has been submitted, you can move to the next thing.

Be warned, though: if your bug has priority or is especially curious, one of the developers may start discussing it, and you may be asked to retest the case. Keep a save file handy in case this happens. Also, if your bug is actually two bugs or more, be sure you file each bug individually, or the developers might snap. Trust me, you don’t want hamster teeth tearing out the back of your hand.

“What if my hero moves fine, but I want him to run around on my title screen?” Well, first check to see if that’s possible with plotscripting. This would be the time to segue to another place called the Castle Paradox Message Forums (“Plotscripting Help” would be the best channel in this case) and ask around for ideas. If in your research you discover there’s no way to do this yet, then create a new bug asking for its implementation and mark it as a “Feature.” Now you’ll have a feature request that the developers can consider.

“Yeah, great, but I hear that some features take years to happen,” you may say. Okay, well if you want it that badly, cast some votes for it. The more votes a bug has (including features), the more the developers will focus on getting it fixed or implemented for the next release. It’s for this reason that custom menus are coming out with Voxhumana rather than Xocolatl or later updates. Vote for your favorite features and you might just get them sooner than you think possible.

Remember, if you use both playtesters and Bugzilla, you have a better chance at seeing your vision come to life than if you try to take the solo road completely. Don’t be proud. Don’t think you can do it all alone. The reason we have precision timing now is because I asked one of my playtesters (a developer) for help getting a music-based script right. I thought my way would work. His way was better. Now we can do things with milliseconds. Just make yourself heard.

Next