Cities in the Smoke

It has been a while since I last made it into the monthly Sunday playtest session in London, but this month the stars aligned, so I got on a train, with my City States Co-op prototype in the bag. I tend to allow plenty of time to travel, so I have time to have a walk around, sit in a coffee shop, or whatever when I get there. This time it was a nice day and I felt like a walk, so I went down the road, across Vauxhall Bridge, along Albert Embankment, returning to the North over Lambeth Bridge, and then back along Millbank. A pleasant enough walk, and a change from my usual environs.

Anyway, at the Jugged Hare, the venue for the meetup, there were only four of us at first, joined by a fifth after we had got started on a game, but this new arrival was happy to observe and was able to helpfully contribute to the discussion at the end. The first game we played was my prototype, run as a three player game with me observing, which was pretty much my dream situation for the session.

So how did the test go? Well, I was already a little uncomfortable about the early phases of the first round or two, where players all contribute dice to central pools associated with challenge cards. My initial discomfort was that in the first turn or two this is effectively not a choice, though one of the players did say that it was cool to have some aspects of the first turn or two acting as a training phase which expands later. The problem was that in practice, this whole part of the round throughout the game just felt fussy and the players didn't really feel that it added any interesting decisions; one of the players couldn't engage with this at all and pretty much zoned out.

We had some discussion about stuff related to this and one of the players was asserting that actually if the cooperative element was all about distributing challenge cards between players and you own your own dice, that should just do the job. 

This is potentially painful to me as one of the central points of the initial discussion that lead to this prototype's form was about sharing dice, and the thought that unrolled dice are a resource that are full of potential that may or may not pay off as you hope. I really liked that thought. It might be that I could find an expression of that concept in this game, but right now, I'm going to explore the feedback and observations from this playtest, scrap the whole dice sharing part of the game, and then adjust the rest of things to fit with that.

Another random comment came from as we were setting up. I have two decks of challenge cards, one of which is nominally "harder" than the other. The idea I was working with was that the aim of the game is to empty the tougher deck, and you can choose which deck to draw cards from (this was actually an idea that was a bit spur of the moment) each time you draw. One of the players said something about the first deck being the "engine" and the other being the objectives. This was partially true, and tickled me, and I think I might lean into that some more: deck 1 could mostly provide capabilities and deck 2 mostly problems. 

The difficulty curve was also off, but I'm not really worried about that yet. Actually the game ended up with a very narrow defeat for the players, which is cool, BUT most of the real pressure hit early on, and the rest of the game was trying to make up for that. This could be great for some groups, but I'd rather we had a general ramp up (with a few comparative lulls). It's all a matter of tuning, once the main structure is more solid, but the new approach to the two decks should help control this.

So, there are plenty of problems with this game, but I felt that the flow of the game was mostly looking pretty good and I have a feeling that the game might be "a thing", that is probably worth some more time. I think I know what to do for the next iteration now...

Back to the monsters

I'm looking back at one of the games I mentioned a few weeks ago as possible targets for resurrection. This is currently a solitaire game (though it could become a co-op) with the working title of Monster Invasion. This is a project that first got going in late 2015, had its last serious bit of work in the summer of 2017, and then saw a little bit of poking in early 2021. As you can see, some of my projects can get dropped for a very long time.

The idea of the game is that your village is under attack from a horde of monsters. You play cards that represent the waves of monsters, the actions you take to fight them off, and the adventurers and strangers who might turn up to help you. Two quantities are tracked, "threat", which is represented by red counters in the picture above, and "power", which is the blue. Threat increases mostly when monsters arrive or when you need to draw an extra card to allow you to play, and can be decreased by fighting back or using magic. Power is your ability to use magic, and goes up and down as you take magical related actions or encounter certain monsters and visitors. If you get through the deck and manage to reduce the threat level to zero, you win. If the threat level reaches ten, you lose. Why ten? It's a number that seemed about right when I was doing the initial work on the game.

How the cards actually get played involves chaining icons together. Cards all have one or two icons in their top left corner (most have one) indicating the card type, and up to three icons at the bottom. When you play a card, the next card you play must have a card type matching one of the icons at the bottom of the card you just played.

By way of example...

In the picture above, we start off with the arrival of some Orcs. That has a running person icon at the bottom, so we are able to play the Run and Hide! card. This card in turn has a book icon, which means that while we are hiding, we can find an Ancient Tome and do some research in order to raise our power level via the Summon the Power card we are able to play next.  That gives us a sandtimer icon, which allows us to have A Quiet Night, after which we are well enough rested to fire off a Power Blast that reduces the threat level.

This all actually worked pretty OK, and gave me a fairly fun way of spending 10 minutes or so. While something like this can be really lifted by nice presentation, and well-directed art could really help suggest a developing narrative in your battle, the game as it stood probably wouldn't engage most people for very long, and it really needs to do that without an investment in art.

The last couple of iterations of the game were toying with the idea of boss monsters, one or two of which could be added to the game, possibly seeding them into certain parts of the deck. The boss monsters could potentially have special effects that shape the way you approach playing the game, perhaps making certain actions you can take more or less effective. Boss cards might just be like the other cards in most respects, or they could stick around as modifiers until you find a way to get rid of them. I built versions of the prototype with a selection of bosses, but tests so far have resulted in lacklustre effects, though I was only using them as "normal" cards other than you having to play them as soon as you draw them.

Another issue is that sometimes you can just be caught for ages without drawing a playable card, building up threat as you keep drawing more cards, looking for something that won't get you killed. In some cases this happens due to a bad decision, but it can also just be that you draw eight times in a row and get nothing. This is bad, and may be fixable by tweaking the icons present on cards, or it may require some sort of special action like being able to play any card regardless of the continuity of icons. It may just be as simple as having too many different icons.

I think that, having had a bit of a play with this again, I want to have a bit more of a play to see if I can make this game a bit more solid and reliable. As a result I spent a little bit of time putting together a set on Screentop.gg, with a playmat that helps organise the components and make playing a little easier. I far prefer playing a game like this (as with most games) with physical cards, but once the basics are in place, I'll be able to iterate over this far more quickly, and will be able to share it with other folk who might be interested in taking a look.

If you look closely at the above, things like the sideways Orc Spellbinder card don't make sense, but they are set up for when I try something different for the boss cards. Aligning them sideways makes them stand out visually as a reminder that they should be used in a different way.

So, that's where I am right now. I have an urge to create some basic card art, which I may or may not do (note: this is entirely because I like having this sort of project sometimes, not because it is really needed), and will look at how the boss cards affect the game and how the icons are grouped and distributed. 

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.

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.

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.

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. 

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. 

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.