Sympol Numbers

I've had a few tests of my cooperative game, Sympolis, over the last month or so and am now pretty comfortable with the overall shape of the game, but of course, the devil is in the detail and now I am trying to get that devil pinned down. 

So here's the thing: if you make a competitive game, the players provide a lot of the balance; in a cooperative game, the game systems have to do all the work. I'll unpack that a bit. If I want a cooperative game to feel challenging to experienced players as well as newbies, the mechanisms, set-up parameters, etc. need to provide that challenge and have a way to scale and adapt. With a competitive game, an experienced player can usually get more challenge by playing against other experienced players.

One of my traditional blurry photos of a recent playtest of Sympolis.

The last few playtests of Sympolis have all been won by the players fairly easily, with a period of perceived pressure mid-game, followed by that pressure easing off until we reached a relatively straightforward final round that felt more like a victory lap than a finale. The level of that feeling has reduced as I have tweaked settings, but it hasn't gone away. One of the focuses of the game is the pair of "wrath tracks" for each player, which indicates the level of trouble you are getting from the gods and the people of your city respectively. If either track gets too high, your city falls and everyone loses the game. In recent iterations, if the tracks go too low, you gain complications due to the people being too lazy and hubristic, or the gods getting jealous of the pampered people. It turns out that the "high wrath" situation is currently too easily managed, which reduces pressure far too much.

In essence, the game asks players to walk a tightrope, but that tightrope is more of a footbridge, with handrails that look insubstantial, but are actually pretty solid when you test them. 

And that's what I'm trying to deal with now. My usual approach of making games is to just make general guesses about numbers, quantities, and so on, and then revise as I get a feeling for how a game plays out. I think that in this game, I may have got to the limit of how far I can go by doing that - or at least, further progress will be slowed massively unless I adapt.

So that's what I am attempting to do at the moment. I have a spreadsheet page counting up numbers from my main card data source, which is another page in the same document that I use as an input into a nanDECK script in order to build my card decks. This is giving me a decent view on the state of my card decks, but there are things that aren't easy to capture automatically, like figuring out the number of dice that are likely to be required to complete any given challenge card, or even group of cards. 

I think that a potential approach would be to come up with a system to provide a rating for each challenge card, working initially on the expected number of dice needed to complete it, maybe boosting it a bit if there is some complicating factor like requiring precise numbers. In fact, I could extend this and rate the production use of each card also, maybe with production of a die giving 1 point, and provision of some die or card manipulation ability having probably some fraction of a point. Then I should be able to analyse the likely production rating at any given time and compare it with the likely challenge rating on a given turn. Once I have that information I will be better placed to tweak numbers to get the game to the challenge level I am looking for.

How much wrath is too much wrath?

Probably the biggest problem with making a cooperative game (i.e. one where the players all win or lose as a group, and not individually) is getting the challenge level right. If the game is too difficult, most players will just get frustrated and not bother trying again. If the game is too easy, players just win and don't feel motivated to have another go. 

What we are usually looking for is where defeats feel like a victory was achievable, and victories feel like they were just by the skin of our teeth. And, ideally, we want this to be reliable, so we don't see wild, swingy changes where one time a given group has an easy time, and the next play, with the same initial setup, the same group has a nightmare where the whole thing falls apart in a couple of rounds. Oh, and we need to have varying difficulty levels or alternative scenarios, so that once a group masters the basic game, they have a new challenge to move on to.

We'll not worry about that last point for now, as it seems to me pointless to worry too much about varying scenarios until the basic game is solid but, that said, it's worth keeping an eye open for where opportunities for varying the game come in.

So, just to recap on where we are at here: Sympolis is a cooperative game that I am currently working on, where players are each the leaders of city states, inspired by a mythical view of classical Greece, where they have to deal with various demands from both the gods and the people of the cities. Those demands might be to build a new building, to hold a festival, or to attack one of the neighbouring cities. Fail to deal with the challenges and the gods or the people will get angry. If either of these influences get too angry, or if an attack ends up sacking a city, everyone loses as a neighbouring empire takes advantage of the situation to sweep in and crush the collective culture.

This is what it might look like when you are about to lose the game.

I tend to think of games having a set of "knobs" to twiddle to tune the experience, making it more or less challenging, increasing or decreasing the importance of a subsystem, or whatever. In this game, some of those tuning knobs are the number and proportion of the different types of cards (eg. ones that produce useful resources or abilities vs those that are primarily challenges), the costs of cards, the failure points on the wrath tracks, the details of the "wrath cards" that turn the screw as you play as well as how those cards are added to the game, and so on. There are quite a lot here, maybe too many; like in any complex system, a lot of the elements are interdependent, so tweaking too much at once could have dramatic and unpredictable results.

And thinking of unpredictable results, one of the issues I have with this game currently is at least partially due to there being two independent sources of randomness: cards and dice. This setup feels natural for this game, but there is a big difference between drawing a challenging set of cards and getting the "wrong" dice rolls, and having a game where everything goes right for you. Bad (or good) luck can really compound in a way that can be frustrating for players. Conventional wisdom in game design circles is that, for games that are meant to have strategy or other thoughtful elements, multiple sources of randomness is usually not a good idea. If I am going to keep both sources of random uncertainty in the game, I need to also include ways to mitigate against the bad luck - and maybe even limit the impact of good fortune.

I'm still pondering ways to do this at the moment, and I'm not sure of the correct approach. Right now I'm feeling that I should give the players more tools to allow them to be clever and get around the bad luck, while making the game more consistently punishing. Now, how to twiddle knobs to make that happen...?

One way to address the first part of the equation is with the starting setup. At the moment, each player has a couple of buildings in their cities which produce dice that can be used to deal with challenges. Some of the additional buildings that can be gained allow for dice manipulation, but if these don't turn up, life can be really hard. Maybe the starting selection of buildings given to players could include some dice manipulation options, so some of that flexibility is available right from the start.

Then there is the "investment" track on player boards. At the moment, dice of any colour or value can be used to push a marker up this track, and this investment can be cashed in later for more dice or reductions in wrath. This works fairly well, but I think I will try allowing the fruits of investments to be sent to other players, thus allowing an opportunity for "richer" cities to bail out their neighbours at their time of need, introducing some more flexibility in how the games challenges can be approached.

Up to this point, the game setup has involved each player having two starting buildings in their city, as mentioned above, and each turn providing a base number of challenges that scales with the number of players. This actually will mean that, amongst other things, the number of turns in a game will vary with player count. I'm starting to think that maybe there should be a set number of starting buildings in the game (divided amongst the players) and a set number of challenges each turn. This would mean that a smaller player count would mean each player has a lot more to deal with, which might either make the low player counts feel too busy, or the higher player counts seem too simple. This sort of setup would allow for a single, more stable configuration to the game that would allow me to work on that consistency more easily, but it's not a silver bullet.

Of course, I could require numbers of cards to be added or removed according to player counts. This wouldn't be the end of the world - many other games do it, and the current number of cards in this game would make it relatively easy to do - but I am a fan of games where you pretty much take things out of the box, shuffle the deck, and then go.

I guess I'll just need to try some of these options.

Finally for today, just some thoughts on what I call the "wrath cards". These are cards that provide a condition that increases the tension in the game, for instance, populations getting more angry if a war demand is unprosecuted, or an earthquake hitting everyone if the gods are sufficiently displease with any one player. The idea is that these periodically enter play, providing a thematic and mechanical incentive to "get a move on" rather than simply spending ages building up production systems. The problem is that I have tried a number of ways of introducing these to the game, and while the effect of the ramp up feels like something I want to keep in, every mechanism so far has felt like a bit of a kludge.

My latest approach is that, at the end of each turn, one of the wrath cards gets shuffled into the "easy" challenge deck (the one that mostly provides production buildings), thus making it riskier to take the easy route each turn. This, of course, provides yet more randomness that can make the game even more swingy than otherwise. I've had a couple of tests using this mechanism, and in one, hardly any wrath turned up, and the other flooded the table with nastiness very quickly. The challenge of the cards was cool, but the brutality was not.

So maybe the way for this is for the wrath cards to not be random at all, or at least the pace of their arrival not random. Perhaps we just have one flipped each round, also using this as a timer for the game as a whole - hey folks, you have 6 rounds to appease the gods... good luck!

Anyway, this has been long, rambly, and not really resolved anything, but writing it has helped me work out some ideas in my head, so it's time to put those ideas into a new iteration of the game. If you are still with me (thanks!) and have any thoughts, questions, or suggestions, please do feel free to comment.

Cities Together at the Expo

So that was UK Games Expo 2023, and another great weekend it was. I worked at the Playtest Zone for most of my time there (at least during the days, anyway), met fine people new and old (in relationship terms, at least!), talked a lot, playtested my City State Co-op Game, ate mostly overpriced burgers and pasties, bought a bit of stuff, and played very few games. I'll talk about my playtest first and then move on to some more about other things, though still mostly about the playtesting.

While I was spending most of my time helping other folk at the Playtest Zone, I also had a 90 minute slot booked for testing one of my own games. As it turned out I didn't need to wait for players as I had been talking to a few people about the game through the day, and a couple of them turned up specifically to play, each bringingong a friend to make up a perfect table of four.

As an aside, my opening line when asked about the game was, "It's a cooperative game where you have to attack each other", which is probably the strongest hook I have ever had for a prototype, as it always resulted in some sort of a "tell me more" response. Well worth remembering.

A few turns into the game, showing cities developing very differently.

I wasn't sure about how long the game would run, but guessed about 45 minutes, and it actually came in at almost exactly 50 minutes, which was pretty good, and the players commented that it didn't feel that long, which is definitely a very good sign. I think I took over 10 minutes to teach the game though, which I feel was probably a bit long. I think this was partly because I am not yet used to explaining the game, but may also be a sign that the game is a bit fiddly.

The dynamic was interesting. One of the players quickly took to being a sort of MC, stepping through the turn order and starting discussion. This could have turned into an "alpha player" problem (where one player effectively dominates a cooperative game), but there was definitely discussion with input from all players, and when we talked about this afterwards, nobody seemed to feel that they were being railroaded or anything. I think that this game could easily suffer from having a dominant player, so I will need to consider whether I will address this or not.

My biggest problem with this game is now, I think, trying to get a meaningfully "difficulty arc", as you might call it. In this play through, the players had a fairly gentle start, then in the mid-game they felt that they were under serious pressure, before the last round or so eased off and allowed them to cruise home. From my position of just observing, and knowing what was likely to happen, I could see that the mid-game pressure was illusory, but it was amazing to watch (they felt that they were about to be punished for earlier decisions), and something I would really like to see happening in the game. Basically, what I would like to see is a tense ending, with a few points of tension, with partial release, through the rest of the game. 

We had a good discussion after the game, and I think that one of the biggest points to address is that it turned out to be way too easy to defend against each others' attacks, and the most obvious fix for that is to greatly limit - or maybe even remove - the supply of buildable defences. Without the city wall cards, there would be a lot more pressure and more difficult decisions to make. I might try that on its own (with tweaks to rebalance the decks to compensate) and see how that goes. There was also a turn-by-turn reveal of cards from an additional "wrath deck", which kinda worked, but was an extra thing that needed to remember an additional (simple) action each round, which was easy to forget, and I have a couple of thoughts about how to address this, though I may leave that until later.

After playing, the players asked for a reminder of what the game is called. I told them my working title, which of course is not exactly evocative of its theme. One of the players I had is actually a Greek speaker, and as the setting of the game is currently based on a mythical view of classical Greece, she had a suggestion for a title that we all liked.

As a result, the City State Co-op Game now has the new working title of "Sympolis", which apparently can translate as "cities together", which seems a great option. Thank you so much, Vilma!

Anyway, that was part of my Saturday afternoon; there was a lot more to the weekend.

I arrived on Thursday afternoon to help with the setup of the Playtest Zone. This is actually pretty light work, the hardest bit being deciding how to lay out the tables and chairs, and the rest being largely putting the trademark red cloths on the tables and sorting out the various bits of stationery we have. Other than that it's a good opportunity to say hello to a load of people - although many of them are busy setting up their own stands.

The rest of the days were spent working, mostly welcoming designers and players and trying to put them together, alongside a core team (five of us in total) plus a small army of volunteers turning up to do shorter shifts, and an extra who came to help whenever he had spare time. There were a few quiet spells (largely Sunday lunchtime, but a few other periods too) where we had to work to bring in potential players, but a lot of the time we were finding people just coming up and asking to play something, and far too often there was no space at that point. It's a shame when we can't seat people who are keen to playtest, but I guess it's a good problem to have.

Its-a me, standing by the Playtest Zone.

The way things work is that most of the tables are booked in advance for a period of either 3 hours or 90 minutes, but there are a few tables available to be booked on the day for designers who haven't been able to sort things out beforehand. It turned out that demand for tables greatly outstripped availability. A note for anyone who is considering joining us for playtesting at future events: seriously, book in advance if you can.

On the Friday evening was the designer-publisher networking event. This is an event that typically involves having a drink or two with fellow designers (my experience is minimum publisher attendance) and listening to a couple of talks, generally one from the event sponsor (Panda Game Manufacturing this year) and one from some other industry insider (past years have included luminaries like Alex Yeager and James Wallis). This year it was straight to the drinks and no talks. There was a point when someone was speaking over the PA, but the noise of conversation was so loud that most people didn't even seem to notice, let alone hear what was being said.

Other than that, my evenings were largely catching up with people and very little actual game playing. I can play games at other events, I guess. I managed to spend my breaks looking around the trade halls, and even managed to get out to watch the vikings telling a story, complete with illustrative acting, throwing of water at each other, and bad jokes.

For all the lack of game playing, and the fact that I always leave with aching feet and a befuddled brain, UK Games Expo is one of the big highlights of my year. Attendance at this year's event comfortably surpassed the biggest pre-Covid year (and Saturday seemed ridiculously busy), and I heard really happy noises from a lot of small traders. I'm already looking forward to the next one. 

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...

Activate the containment field

My current virtual tabletop of choice for prototype work is Screentop.gg, which provides a 2D environment that you can access from a browser, and do this for free (though paid-for premium is apparently on the way - and has been for a couple of years now!) without installing anything, and without melting your PC from the load. This works well for me and makes me happy. It is also under active development, and new features crop up periodically, generally without fanfare (unless you are paying close attention in their Discord server), which makes for occasional excitement or confusion.

Note: this post is likely to not make very much sense to a lot of people. If you're not interested in Screentop configuration, I really won't mind if you move along and do something else with your life. Anyway...

A relatively recent addition is grid "dropzones", which appear by default on "container" components (which are the type of component you use if you want to put something on top of or in it - like a board, say), which made a huge difference, allowing containers to have a simple and useful default behaviour without having to mess about with setting up anchors in precise locations.

Anyway, what I wanted to talk about here is how you can make anchors (lines or points where you can drop other components) interact on containers in order to make some neat and helpful behaviour with little effort.

The driver for this is making a virtual prototype of my "City State Co-op" game, which requires cards to be tucked behind a small player board, and overlapped so that the main information on each card is easily visible. Like in the following picture.

The way this works is with a set of dropzones on a "player zone" container that I created for arranging player components on, arranged in a particular way:

In this, it is the "Cards" and "PlayerBoard" dropzones that matter. Screentop arranges things in order, down the list, so in this case the player board is rendered after the cards, and thus appears on top of them. If I rearranged this so that the cards are after the player board (the 6 dots to the left of the names are handles that you can drag around to rearrange the order), the board would appear underneath.

The PlayerBoard dropzone just has a point anchor in the middle of the container and isn't interesting other than its presence. The Cards dropzone has a bit more going on with it though:

The highlighted line in the image is the "Challenges" anchor, which isn't massively interesting, as it is a place to dump cards that have not yet been dealt with in the game - this anchor ensures that the cards are face-up, and aligned vertically with respect to the player zone, and makes sure they are lined up neatly (unless you have way too many in play - in which case you have probably lost the game) which is cute, but that's about it.

The other two lines are, I think more interesting. They are effectively mirror images of each other, and ensure that the cards that need to be tucked line up the correct way.

The x coordinates of the line here run left to right and the cards are aligned to the end (the right) of the line, with a gap setting that overlaps by the right amount to show what I want of the card. The rotate makes sure that the card is on its side, in the correct direction, and the "open" and "up" settings ensure that the cards are face-up. (Actually, in this case the cards are modelled as containers, which allows some other handy behaviour not available to tiles, which would usually be a good choice for cards, and so only the "open" setting actually matters.)

The "Buildings-right" anchor differs in that the x coordinates (which are shifted to the other side of the component) run from right to left, so that the "end" alignment now hits the left, and the rotation is 270 to allow the cards to rotate neatly the other way.

And the upshot of all this is that I can basically drag a card to the general area of one of these anchors and let it go, and the card will flip, rotate and tuck appropriately without further assistance, making the game much smoother to play than it might otherwise have been.

I realise that this post is very dry and probably of interest to about two people, and they may never see it, but please do let me know if this sort of thing is helpful. 

Starting over for a new year - March is the new year, right?

Over the last couple of years, the board game design part of my life has stagnated quite a lot. While online game development and testing works pretty well, it turns out that I am most energised by regular face-to-face sessions of testing. Before Covid, I was visiting London for an afternoon of playtesting most months, having a monthly meetup with a couple of semi-local designers, and having occasional other testing opportunities at other times too. It was never the several-times-a-week testing that some folk manage, but it kept things moving along pretty nicely.

In recent months, I have started getting back to the London meetup occasionally (not regularly yet), and we have just reinstated the semi-local meetup, though I've not yet tried recruiting other local playtesters again. 

During an email exchange with another game designer recently, it occurred to me that I used to enjoy writing this blog as a rough journal that encouraged me to get thoughts into some semblance of order, and very occasionally being the start of a conversation with someone out there. I've fallen into a cycle of not feeling I have much to say and editing myself too much, as well as finding all sorts of excuses why I shouldn't write anything. I don't think this is a helpful situation, so maybe I should just pull my finger out and write something.

So, in the spirit of getting things going again, I'll make a quick note of a few of the projects I have been working on recently...

The Artifact is a tile-laying and some-other-stuff game that I have been working on with Alex Cannon, almost entirely online. There is a core of game play that works pretty well and there are several other bits of game that we have tried, but while the game has had many forms that have played pretty well, there has always been something that we have been unhappy with. This has been a really interesting process, and I think we are gradually homing in on a game that we can then work on refining properly, but there is still a little way to go.

Squirrel Invasion is a re-imagining of a game that I was working on long ago, that long-term readers of this blog might remember as Invaded. The idea is that players control tribes (now of squirrels) trying to get by in their homeland, which is invaded by an aggressive, non-player, colonial power (grey squirrels). The current version is very light and plays more like a wonky family game than I would like, but it plays, which is something, and I have some ideas.

City State Co-op is an implementation (with a terrible working title) of an idea I posted about on this blog several years ago. The core idea is players each control city states in an ancient world that are beholden to demands from both their populace and the gods; the problem is that some of the demands involve attacking each other, and you need everyone to survive and thrive in order to win. I was stuck on this for a very long time, but a discussion a few months ago with Rory Muldoon got some good ideas up, and I now have a functioning version which I think has some merit, but the challenge curve is currently terrible.

Now, let's see how often I can continue this blog...