Updates and Artifacts

Just a quick update... 

I've been slowly chugging along over the last month, keeping things moving along with The Artifact, and also reestablishing a monthly meetup with another semi-local designer who I used to see a lot of before Covid. A big part of things is building up a routine again. 

Interestingly, the semi-local meetups have already resulted in a new design, a light, cooperative puzzle game which we think is close to pitchable already. Obviously we'll be continuing to work on it, but it's looking pretty good so far. 

I've also had a tinker with something very new that didn't work, but I want to play with a little more. I'll probably write up something about that soon.

The end of a recent 2-player test of The Artifact. 

The Artifact has stayed in roughly the same state for a couple of months now, with Alex and I both having tests independently, trying out different variations of the game in relatively minor details and comparing notes. This seems to be working well and making progress a lot better than we have managed for a good long time. It helps that we have found a core of the game that we are both pretty comfortable with and can iterate on at a relatively fine level.

I'm also at an interesting point with my approach to the game where I am actually starting to think about balance between elements of the game. This is something I tend to resist for a long time when working on games for a lot of reasons, so the fact I am allowing myself to even start thinking about it makes me think that things are really moving.

Return to anarchy

It seems that it has been pretty much four years since I last wrote anything here about The Castle War. This is a two player game inspired by the period of 12th century English history often referred to as The Anarchy, where the anointed king, Stephen, was fighting to keep his crown from the Empress Matilda, the daughter of his predecessor, who many believed to be the rightful monarch. Game play is built around playing cards to develop military forces at a row of six castles, control of which is the aim of the game. There is a little asymmetry in the game, so there are slightly different aims and capabilities on each side. 

Before Covid I did quite a lot of work on it and got it pretty solid, but since then I did a little work via virtual tabletops, but as with many projects, this one fell out of my schedule and nothing has really been done on it for a couple of years.

The latest version of The Castle War implemented on Screentop.
Note hackiness to allow you to peek at face-down cards. 
It's better than nothing.

I recently had an in-person test with a designer friend who had played the game before, and we played the last version I had in a physical form, which missed out on a few changes that I had implemented virtually, but was a useful reminder of the game after a long gap. We actually had a pretty tight play and it felt like there were interesting decisions most turns, with some twists delivered by cards and dice along the way.

There were, of course, a few issues that we found, which were mostly user interface issues, where the presentation of certain elements on the cards made things harder to understand than would be ideal. We also identified a few areas where there were opportunities to increase what I could describe as "thematic interest".

I'll elaborate on that with an example. There are three cards that are always in play that represent three "power bases" (the Church, the Treasury, and London) that either player can play cards to take control of. The castles are the main objective, but these power bases are used to break ties at the end of the game, so can be important, but for most of the time I've been working on the game, that was all they did. I recently introduced a couple of card effects that key into the power bases (e.g. an event that triggers for the player that controls the Church), and these seem interesting and fun, but have only drawn attention to the fact that there is not much of this in the game.

The newly printed card set with a few already cut.
For single-sided cards I load these into sturdy, opaque-backed
card sleeves, which is easy, forgiving of bad cuts, and 
not bad to shuffle and play with.

So now I have rolled fixes for some of the issues we came up against into the prototype and updated both physical and virtual versions of the game. I have had a solo play through, with myself playing both sides, and it looked OK so far. To be clear, this game is not set up for solo play, especially as a lot of the actual play involves hidden plays, so there is room for uncertainty, bluffing and misdirection, which is hard to simulate. Still, the exercise is a passable test that the core of the game still works OK.

Of course, there is no substitute for actual, human playtesting.

New types of artifice

If you've been here a while, you might remember about The Artifact, a project I have been working on since... ages ago with co-designer Alex Cannon. We've been working on this mostly in a virtual form (implemented on Screentop.gg), and have had a core to the game, about which we have tried a heap of different approaches to make a full game. Some of the iterations have been quick and light, and some have been crunchy brain-burners, but none have really felt right to us.

We got into another fresh approach a couple of months or so back, which felt good. Alex managed to arrange some in-person playtesting which helped develop the idea into something that worked pretty well, and I was able to get some further tests that have added some additional shape to the project. After a period of slow progress, we have got into something of a rhythm with one of us doing some independent testing and development, then working together to consolidate, then the other doing something, and so on...

A recent 2-player test of the game on Screentop.
Note the very basic "it'll do for now" grid on the right -
enough to test with and no more.

It feels to me that we have reached a shape to the game that we enjoy playing and shows promise. It still has plenty of flaws, some of which we have identified already, and some we are sure exist but will need testing to find, but we seem to have a workable direction of travel for now.

The core of the game has always been built around placing domino-like tiles to a central play area, placing "researcher" tokens onto these, and using those researchers to access "knowledge resources" on the tiles to gain... something, generally including "projects" that progress towards victory, but in some iterations there have been other things involved.

Right now, added to the spatial game of building the array of tiles and having researchers in the right place to achieve objectives, we have a secondary board representing the projects and developments that can be achieved using the researchers and the resources they access. This board provides a second spacial element as victory comes from connecting up a group of completed spaces on its grid, and as you complete projects you get actions which can manipulate the state of the tiles, so there is a circular dependency.

A 3-player test that got really bogged down and ground to a stop.

This all works pretty well for two players, but for three, it seems a lot more patchy and the current setup can get bogged down quite badly, with some turns involving some serious puzzling out, and active blocking moves making it very difficult for someone to win. That latter point can certainly be addressed, and we'll have to see if the former is a problem for players. We haven't yet tried more than three players. I think that there are ways around this though, with plenty of elements we can adjust, including costs of projects, layout of the project board, effects that take place with completed projects, and so on. We'll be exploring this over the coming weeks.

We're likely to continue to test primarily with two players for the time being, there being the two of us working on the game, but we'll increasingly have to look at higher player counts. It might be that we can get it to work great for two but struggle with more, and that's fine, but would frankly be a little disappointing. There may need to be variations in setup for different player counts, and this is something we already have some ideas about.

All in all though, progress is good.

The UK Games Expodition

It has been nearly a month since UK Games Expo, with the official attendance figures showing that the event has fully recovered from the hit from the pandemic and is now bigger than ever before. I haven't seen any breakdowns, but from where I stood, Friday seemed to be incredibly busy, Saturday even more so (though the end of the day seemed to drop off more), and Sunday was a lot more relaxed - though still very full of people.

As planned, I spent almost my entire time at the Playtest Zone, wearing a red t-shirt and helping keep things going there, though for most of the time it wasn't hard work. We have a sort of saying there: unlike most other stalls and zones around the Expo, the busier it gets, the less we have to do. When things are going well, there are a constant flow of players wanting to playtest a prototype, and sometimes they don't even need directing to a table. 

The Playtest Zone (red tables) in full flow on Friday morning.
There were more tables behind me and to the side as well!

I actually found that most of my effort was spent explaining to passers-by how the area works, as it isn't really obvious, especially as so much other stuff around the halls requires you to book a spot in advance. In the Playtest Zone, if you are a player looking to test something, you just need to turn up and if there is a game requiring players you can just sit down and play.

There was a nice facility next to us that I didn't take advantage of, but may do in future: this was an area run by Panda Game Manufacturing, who sponsor the Publisher-Designer track of the event, where they provide a few tables that can be used by designers and publishers for ad-hoc meetings, and there were quite a lot of people using the tables throughout. Panda also had some giveaways, including the rather cute "Game Design Toolkit", which is a small game box full of tokens, dice, stickers, and blank tiles and cards that you can use to create a game. It's largely there as a promotional demo of the sort of quality of the components they can produce, but it's genuinely a cool box of stuff and would be a great focus for an introductory game design workshop or something. 

I managed to get playtests of both Sympolis (in an official playtesting slot) and Grab Bag Zoo (as a casual play one evening), getting valuable feedback for both.

Sympolis in play for three players, one of whom is
accumulating Jealousy and Hubris cards at an alarming rate.

As seems to be my way, I didn't get to play many games over the weekend and didn't get to spend as much time as I would have liked with... anyone really, and I spent most of my evenings just too tired to do anything much, but it was again an amazing experience all around and I'm already looking forward to pretty much doing the whole thing again next year.

I'll just sign off for today with the most exciting news (for me, anyway) of the weekend: we have found a publisher for Grab Bag Zoo! We are in the process of negotiating a contract (so it's not quite a done deal) and I can't tell you any details at the moment, but when there is anything to officially announce, you bet I'll be shouting about it! Watch this space for more information when I can... 

Getting Ready for Expo

It's that time of year! Yup, in less that two weeks, it'll be UK Games Expo, the biggest gaming event I go to regularly. My plans are the same as they have been for the last few years: I will be working at the Playtest UK area (Stand 1-384, at the far left corner of hall 1), where we will be providing tables for designers to have their unpublished games tested by all and sundry. If you are going to be there, please come by and say hello, and maybe play one of the prototypes there.

The current version of Sympolis, which I'll have with me for playtesting.

I haven't gone for the rounds of pitching meetings this year (though I am hoping to meet up with a few people at various times), but I have a playtesting slot booked for Saturday from 4:30pm, to round the day off. Hopefully I'll get at least one play through of that. I'll also have a copy of Grab Bag Zoo with me, in case the mood strikes.

I'm really looking forward to this. I usually end up physically, mentally, and emotionally drained, but in a good way that, once I've rested, I bounce back re-energised. It's then a matter of trying to make the most of that over the month or two that follows. Fingers crossed...

The State of the Zoo

Grab Bag Zoo is a game I have been co-designing with Mike Harrison-Wood since before Covid hit us. Literally just before the pandemic - we had our first playable prototype in January of 2020, with the lockdowns in the UK starting in March. This would have been problematic for most projects, but this one had the extra problem of being a game that relies massively on tactility to work (with players feeling in a cloth bag for the token that they want), so an online version just isn't viable for the foreseeable future.

As a result of all this (and the difficulty I have had in getting regular in-person testing set up since the effects of the pandemic have faded), the game has made very slow progress, but we have managed to iterate steadily, and while we are regularly finding issues with it, the game always seems to entertain.

The current Grab Bag Zoo prototype.
So compact compared to what it used to be.

When we first started, there were over 50 animal tokens in the game and each player had their own bag. This swiftly reduced and we now have a single, shared bag and only 24 animals.

The game has a fast and frenetic style of play, but we wanted to include some way to make multiple plays rewarding so, for example, if you win a game once, your next play is more challenging. We've tried a staged "campaign" style play, a set of elements that get added to the game depending on whether you win or lose, and so on. They all seemed OK, but not quite right.

We've now got to a variation where there are a small pile of challenge cards, each defining how many animals that you need to collect, how much time you have to do it, and any other special rules for that challenge. There is a simple one to start with, and then you can simply choose a challenge you want to try next, with the overall objective to eventually complete every one. This seems to be working well and with a minimum of fuss, though I am certain that there is some fine tuning to be done on the various challenge cards.

The game is also fitting into an ever smaller box.

At the moment we are taking a bit of a breather, but have the great news that a publisher (no, I'm not going to say which) is currently taking a look at it. This is just the first stage down the publication road and that road has very many off-ramps, so it is still most likely that nothing comes of it, but we hope that at the least we should get some useful feedback. Fingers crossed.

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.