The Prototyper’s Dilemma

I’ve been rather quiet of late, mostly because I’ve had quite a bit of design stuff going on. Not only is the LoLCG project now worthy of the title- a project of more than one- but the prototypes for Wild Abyss arrived and getting both sleeved, sorted and played has been taking up pretty much all of my time.

There are other things in the works, too, but I’ll leave those for later. I have the next part of the ERI framework series about half done as well as a bit of writing on bioshock: infinite, but I think the latter has been done to death so it probably won’t see the light of day.

In the meantime, I’d like to talk about a particular issue I run into as a developer, that might be interesting for other people interested in taking their design a bit more seriously. It has to do with that most terrifying of processes, playtesting. I’m also going to use the opportunity to show off some of the goodies I’ve been working on that have been keeping me quiet.

 __________________________________________________________

In any game design, it’s important that you go beyond the people you are familiar with for testing purposes. Whether that’s your inhouse studio folks for an indie developer or a regular gaming group, these people will be familiar with you, your style and idiosyncrasies. They’re good for providing people against whom the most basic of tests can be performed, but beyond that any data you get from testing with them is likely to be inaccurate compared to how the game may perform in the market.

So you need to go about finding independent playtesters. If, like me, creating a commercial NDA and paid testing environment is impossible, that means finding volunteers from outside your normal circles.

This is where the prototyper’s dilemma strikes. In a perfect world, you could post your paper-slip prototypes and nascent ideas on the internet and get a bunch of enthusiastic, capable playtesters interested in a moment. In reality things are a little more difficult. Back when I was 14, I spent around 3 years prototyping and developing a warhammer army book. I wanted to make sure this thing was balanced and interesting, so I tried to organise playtesting. That experience taught me more about game development than all my university education put together. If you want to get tests done, you need to present your testers with a product that isn’t entirely dissimilar to the quality of commercial product they are used to… or at least one that looks like it. You need to get them to buy into what you’re doing through giving them a clear indication of just how serious you’re taking this. Hand scrawled notes on notepad paper do not do this.

One of the reasons the LoLCG looks so spectacular is because of those lessons I learned. You cannot get good, unbiased testing happening without that level of production pre-invested in your designs. Enthusiasm will fizzle, tests will be delayed, people will drift away and you will lose momentum or end up getting frustrated and making decisions based on insufficient data. To keep people attached to the project, you have to give them something that, even if it doesn’t play that well, looks and feels like it should.

The dilemma, however, is that a playtester coming in from the cold, especially one with little experience of the development process, will look at yourdesigns and assume that’s the best you can do, that your first prototypes are the equivalent of a videogame public beta, when in reality the guts of the game are about as polished as a rotten stick in a peatbog. This in itself creates expectations and dissappointments- I’ve found people tend to overlook the visual design of the LoLCG cards in order to focus on the text because they feel the text is more important.

While in the long run, that is true, the text of cards and the precise wordings are the last thing that needs polishing during the card design process. First the parameters under which those wordings must be constructed must be established- how much space do we have, what symbols are available, how many can we use before the cognitive burden becomes to high. There needs to be text there for the testing to actually be valid, but the balance of these texts is by nature rough and ready until it can be established what the restrictions under which a polished version must be constructed are.

Unfortunately, the sort of people likely to volunteer for playtesting are the sort likely to fixate on these sorts of discrepancies and thus you end up distracting your testers from simply playing the game in a relaxed, open state where you can get good information on how the areas you want to isolate are working out. Add on the natural focuses of the various kinds of players, whether you use Bartle’s suits metaphor or Mark Rosewater’s timmy, johnny and spike etc, and life is hard.

So this is the Prototyper’s Dilemma: Without achieving superficial similarity to a finished product, you will not be able to attract and retain testers. The more effort you spend in that regard, however, the more your testers will have unnatural reactions to the parts of the material that most need testing.

_________________________________________________________

I’ve discovered that it’s not as simple as simply getting your game to the tabletop or screen as soon as possible, nor is it about polishing like a madman before doing any testing. Like many things in game design, there is an elegant balance to be struck between conveying the identity and overall mechanisms of your game effectively and not jarring your testers into over-analyzing things.

I should note that the impact of this is largely dependent on just how hardcore you take your design. For games like LoLCG and Wild Abyss, everything matters- colour choices, fonts, layouts, grammar, amount of cards, visibility, even the size of a playset.

This might not seem important, but it IS. If I want people to be able to realistically play a game, having a set of cards that will fit neatly into a schoolbag or a hoodie pocket or similar is the sort of thing I take into account
very early in the process. Isolating and testing these kind of dynamics is really important to getting the desired experience for a player. Tweaking and perfecting mechanics are the last priority, not the first.

So, how to resolve this? Unfortunately, the point of a dilemma- in fact the very meaning of the word- is that there is no simple solution. Luckily, unlike the famous Prisoner’s Dilemma, this one isn’t exactly binary in its solution space. For Wild Abyss, I’ve taken what I learned from earlier games and attempted to create a prototype which strikes that balance. The visual designs are colorful at a distance but minimalistic and simply executed.

The result is a game that looks impressive but only took me around 30 hours to prototype from start to finish- less than a week’s work in the evenings. This whole game went from initial concept to first prototype in 16 days

While polished, this is clearly a first prototype- not least because it’s written all over the thing. The ship designs are just too far on the clumsy side to be finalized, the resource card designs are clean and generic etc. I’ve had a good reaction from my playtesters for this game- they’re happy to just play it, and aren’t overly inclined to focus on technicalities. The result is after only a few games I’m getting a lot of good information on where I need to make changes, and after the twenty or thirty more I want to get done with this first prototype set I should be able to make some really significant choices that will benefit the game based on solid, unbiased information.