strategy game playtest

Contested!

I managed what could just barely be called a first playtest of The Game the other day. It took place on a totally unskinned, hex-constrained map that looked more grognardesque than in any way 1337, where I controlled all three sides involved in the game, and that went without benefit of probably 75% of the features I want to get in over the coming months — but I count it a success, for all that. In fact, it’s because it’s in such a rudimentary form that I count it a success, and I plan to get it in the hands of some trusted friends as soon as possible (and more and more gamers after that). Collecting reactions on a project like this from the earliest stages gives it the best chance to become something truly great, enjoyable and fun. While this kind of iterative development cycle (of building only a very early version, gathering feedback, refining, and building some more) still isn’t second nature to a lot of product developers, it has become more and more common as a conscious operating philosophy over the last decade, and five years ago spawned a pretty interesting book on the topic of customer development that you should read if the project / startup / game you’re developing is more complicated than a feature you can knock out in a weekend.

Just playing through The Game by myself was a great way to get some insights into things that weren’t working right, what information was important to bring to the foreground, what felt good, what felt like it needed to be pushed up in my priority list, and a couple of potential new feature ideas as well. While that sounds too obvious to mention, what’s not as obvious is that foisting this warty troll on a next circle of friends / advisors / gamers, even at this early stage, should yield insights just as valuable, if not more so. I have been involved in too many instance of product development in the past in which too little feedback was sought, usually at too late a stage for it to have much impact. The results in those cases are usually not good.

Designers and developers have a natural reluctance to expose their work at an early stage. It doesn’t yet match your vision for the product, after all, and it’s the product as envisioned that you’re banking on — not some ugly, clanking electronified board game that isn’t even quite a game just yet.

But abstract it from your brilliant vision and what you’re really banking on is your ability to build something people will want. The problem with the “Build –> Test –> Sell” development model, however, is that you don’t find out what it is that people really want until it’s more or less too late. (I know you think you know what they want already, but you really don’t.) By the time you’re halfway through the “Build” phase, most of the decisions have been made already, and it’s unlikely you can afford to step back very far into that phase in order to tune your product to your findings once you get it in customers’ hands during “Test.” Even if you have the cash (and time), all those decisions come with their own weight and momentum (technically, product-wise, and from your audience’s perspective), and undoing or redoing them is more work than you think.

Instead, it’s becoming more and more common to very consciously “Test –> Build –> Sell,” with liberal reapplications of the first two of those in an iterative way. Rather than wait until you have something pretty or something fun, get your game (or your photo-sharing site, or your location-based check-in app, or your speedier email delivery service) in the hands of people who represent your customer base as early as possible. Find out if they really do have the problems you think they have, and which you want to solve (hopefully you’ve done this before you start development, actually). Find out whether they like the idea of the solution you’re presenting. Listen carefully to what they have to say about your first, rough draft of that solution — these will be the kinds of things I mentioned above: what’s not working, what information do they need, what feels good, what needs to be higher priority, what are things they just won’t use, what are the things they wish they were getting. Then use that information to guide (though not dictate) the decisions you’re making as you Build. Make those decisions with your customers. Build a couple of them into your product. Then go back to the “Test” phase again and repeat. It’s pretty common wisdom these days, but it’s still surprising to see how many companies and products ignore this model — even some of those that pay it lip service. But experience shows that it works.

This is why I’m happy to advertise my game as currently ugly and un-fun. It is definitely the best place to start.