2023-04-02

City testing in a state

Recently, someone retweeted a tweet by game designer Jeff Warrender that made me sit up and pay attention: "Playtesting, especially in the early stage, isn't for fixing problems, it's for identifying strengths." He went on to expand on this a bit in the tweet, and more extensively on his BGG blog. I'd recommend you having a read.

A tweet from @BelltowerGames from November 2021. "Playtesting, especially in the early stage, isn't for fixing problems, it's for identifying /strengths/.  You can fix all a game's problems and still have a game that's just ok.  But a game with strengths has the potential to be good, which is a motivator to address its problems."

The essence is that, while finding and fixing problems in a proto-game is important and necessary, what is absolutely essential is finding what is great about the game, as if the game doesn't have that (or you don't know what it is), no amount of smoothing and polishing will ever make it into anything better than mediocre. This is all a variation of the old saying, "find the fun", but I think is a bit more specific.

So, hold that in your mind while I ramble on about one of my own projects... I'll circle round...

There's this game that I have been working on, on-and-off for quite a few years with little success, and have blogged about a bit. The game finally got going again after a conversation with Rory Muldoon, which helped me find a new direction, which involved dice sharing and allocation. After a little tinkering, I put together a scrappy prototype with hand-written cards and a fistful of dice, which I solo-tested a bit before deciding that there might be something in it. Then the game went back onto the shelf (literally, in this case), from where it fell down behind some other boxes and I couldn't find it for a little while. This is how organised I am.

Various hand-written cards arranged in groups, many cards overlapping, on a green mat with a square grid on it. There are also dice and wooden cubes on or near the cards.

A little time passed with me not getting around to doing anything more, until I finally had another run at the game, building a play set in nanDECK (and learning a new trick in that about conditionally rotating a section of the cards) so that I could output it as printable cards for a physical version, or as an asset that I could use in Screentop.

My little issue of temporarily losing the original prototype (it did turn up again a bit later) affected how this developed as I didn't have the reference point of what I had done before, other than a couple of photographs. As a result I built my card data from memory and from thoughts about how the previous round of testing had gone. I think this was probably a net positive (I wasn't being held back by my original guesswork for content) but who knows? When I did locate the original, it turned out I had managed to reimplement the equivalent of everything in it that I wanted to, and come up with some new stuff too.

Prototype game components on a table, mostly cards in card sleeves, with icons and some text printed on them, arranged overlapping each other. There is also a small player board, and there are dice and wooden cubes in various colours.

A manual, solo playtest of this setup went OK, but I was clearly going to have issues with a difficulty curve, as after a little while you end up with plenty of resources that allow you to deal with pretty much anything. There are a few ways of dealing with this that I can think of (ramping difficulty through a series of card decks, periodic disasters that knock players back, some track that adds a drag factor as play progresses, etc.) so I didn't worry about this too much.

My ability to playtest in person at the moment is limited, so I figured I would be best off fixing up a virtual prototype. This would have the benefits of allowing test games with pretty much anyone who has an internet connection, as well as allowing for much quicker iteration as the need to print and cut cards was removed. 

A virtual boardgame prototype. On the left is an area with spaces for challenges, discards, card decks, and dice. On the right are two player areas with city boards and tucked building cards on either side of them, as well as dice and tokens.

After a couple of solo tests and rounds of tweaking, a friend, Nick Drage, volunteered to help with a playtest. Nick's background is largely in wargaming of the more freeform, adjudicated type, as used in the military and business, which is a style of game that I have read about but not got any meaningful experience in. It means that he thinks about games in a very different way to me. This is useful.

So the game worked mechanically, and once I had found appropriate words to explain how to play it and in what order to do things (note to self: a list of turn phases in order would make this really straightforward) the game flowed well. The first decision point in the game felt weak to me, so something probably needs to change there - or it needs to be reframed as a "warm-up" step. We didn't play all the way through as the aforementioned difficulty curve was creaking and, frankly, we had seen what I wanted to see for this play. 

A virtual tabletop with a green background, on which are a load of cards, many of which overlap each other. On the cards are assorted icons, many of which represent buildings. There are also dice, in purple, white, and red.

And so we come to the thing that hooks (loosely) back into Jeff Warrender's tweet... 

I had divided game play into a series of phases (gain dice, reveal challenge cards, share dice... etc.), but instead of having some turn order within that, I decided to just leave players to decide what order they want to act in. Most of the time it doesn't matter, but sometimes it really does, and I figured it might be fun to just let things happen however the players want, giving them an extra layer of tactical stuff to discuss and solve.

It turns out that this was a pretty good decision for this playtester, and framing the game as effectively a framework for negotiation and collective problem solving looks like it could be a win. That doesn't differentiate the game massively from other cooperative games I have played, but the freedom in how to come up with solutions is a bit different, and could be something I could lean into.

One of the perennial issues with designing cooperative games is what is often known as "the alpha player problem", which is where one player effectively dominates play and tells everyone what to do. There are a number of ways to design a game to minimise this, and the set-up of this game is such that it could be vulnerable. However, a point of conversation that came up is almost the opposite: what if players can't agree on what to do and the game stalls out and takes too long? We discussed some ideas about adding a real-time element that actually could be really interesting. 

I'm not saying that I have found greatness, or even great potential in this game yet, but at least I know that it can strongly engage at least one person, which is my first real hint (as I still don't fully trust my own judgement when it comes to my own projects) that this is probably worth working on a load more.  The game structure is looking good, and it seems to provide an interesting framework for players to work together.

That positive reinforcement is worth more than you can imagine. Now, of course, after a few tweaks, I need to get the game in front of more different people - including over a physical tabletop. 

No comments:

Post a Comment