Working up a steam

Sometimes ideas just come. I'm not sure where this was from, but it has some similarities to the rather great game, Azul, and a couple of other things.  The idea was for a simple mechanism where you take items from a location (on a ring of spaces) and then draw a couple of items from a bag and place them on adjacent locations on that ring.  Then a game could be built around collecting and using those items.

Version Zero: minimum viable prototype.

I made a quick prototype with a bag of gems in three colours that I had lying around, a quick, hand-drawn board, and some cards scribbled on the back of some old cards from a previous prototype, to provide something to spend the gems on.  This was all perfectly fine for a proof-of-concept sketch of a game.  I had a couple of plays with this, playing multiple virtual "players" myself, and it seemed to be not terrible.  Bear in mind that this was pretty much the minimum I could do to make something that was actually playable, intended to check that a core mechanic is at least plausible, and as such I think I gave myself a thumbs up on this one, so decided to try progressing the game a little.

At this point, the game was just an abstract mechanism, and experience has taught me that I cannot develop an abstract game: I need some sort of theme to guide me in future decisions.  This theme might change later, but it would be something to work with along the way.  Fortunately, another project came to my rescue: this year I have decided to draw (and share online) something every day of the year if I can. This is old school: drawing on paper, though the implement I use to make the drawing can be whatever I fancy at the time, as can the subject matter.  As I was putting together this prototype, I drew a page of random steampunk-style gizmos, and this actually looked like it could be the start of a theme.

My first sheet of steampunky things, based on pics found all over the place.

So, what I ended up with was the idea that players are apprentices in a workshop, tasked with putting the finishing touches to various gadgets before they are dispatched to their final owners. You might even be able to make use of some of these gadgets to help you in your task, but if you break it you have to fix it!  The resources are still abstract coloured gems, but I can work on that later.

With this all in mind, I made use of the artwork I had, with a cog icon as a default for cards that didn't have their own picture, and made a new prototype for some solo testing once again, this time setting up a NanDECK script, pointing at a Google Sheet, to build cards that I can quickly print and cut out.  Some of the gadget cards had special abilities and a chance that they would break when you use them (they always work, but you roll a die to see if they then break), a cost in resources to complete, and a score for completing them (based on the resources -- which are of varied rarity -- required to complete them).

Version 1: more like a game, but not a good one yet.

It turns out that a bunch of MDF discs I had lying about were handy instead of having an actual board (though it starts looking a bit like Azul) and a silicone cupcake case is perfect to sit in the middle to collect discarded resources.

So at this point, the game works mechanically, but is somewhat dull.  My idea that you can use the abilities of gadgets is fine (though the abilities I had here weren't great) but the risk of breaking them was really harsh, and disincentivised using them quite dramatically.  I really should have learnt by now that there is a tendency for players to want to avoid risk of loss, and this sort of mechanism rarely works very well when I try it.

I am now overhauling the game, removing the potential punishment for using actions, but doubling down on the idea that there are actions to use.  I'm aiming to make this a game that has a similar complexity and pace to, say, Splendor, and to be fair, the flow of play (gain resources, then use resources to acquire things that win you the game) is fairly similar. I'm not too worried about that at the moment, and there are solid differences, but I will need to be sure that having an inspiration does not result in the game being too derivative.


London Bog Castles

This month's playtesting trip to London coincided with St Patrick's Day, and realising this a week or two in advance nudged me into dragging Corlea, my game about building a trackway through a bog in Iron Age Ireland, back onto the workbench and seeing if I could get it into shape following some serious problems with it a few months ago.

A big element of the original concept of the Corlea game was that building the trackway created new action spaces that you could use, and players would progress along it in a "Tokaido" style (the player at the back can move as far forward as they wish).  This never worked as I wanted it to, and I decided that this was a darling that I should kill, and so I rebuilt the game with something closer to a regular "worker placement" mechanism.  And that is what I tested.

The Corlea board could definitely do with a redesign: it gets hugely cluttered!

When playtesting it is important to know what you want to get out of the exercise and can also be useful to let your players know what you are wanting from them.  In this case, I knew that the balance of the scoring elements of the game, and the usefulness of various cards and possibly action spaces, was likely to be questionable at least.  I asked my testers (who were, remember, game designers themselves) to try to ignore game balance for now and just see how the game flows and help me decide if I had something that felt like a game rather than an exercise in frustration like the previous version.  If it passes this test, I can start looking at the details.

So how did we do?  Well, I think the game passed the initial smell test.  Quite a lot went right: turns zipped along, so downtime was not long, total playtime was just short of an hour, pretty much nailing the sweet spot I was aiming for, decisions felt reasonably interesting most of the time (though got less so later on), we saw some variety in styles of play thanks to some of the skill cards and, slightly comically and unexpectedly given that I was certain that the game had horrible balance problems, the end game scores were reasonably close.

There were plenty of problems we found.  For instance the set collecting part of crafting and burying offerings just didn't hang together properly, there was no lure to get players to try collecting "King's Favour" (one-off, instant effect) cards, later in the game the positioning of workers in various tasks became rather stale, we ran out of one of the stacks of cards, and various effects felt either over or under powered.  All these things are totally solvable, and I count this playtest as a huge success: the game overall mostly worked and I now have a list of things to look at next.  Onward!

After playing a couple of other games from another designer, we reached the point where everyone who had brought a prototype had had at least one play, and the afternoon was getting fairly late, so people started to leave.  I did, however, manage to get a quick test of my two-player Castle War card game with a designer I was chatting with.

This play of Castle War was basically a casual play-through, with only a minor tweak since my last try of it, hoping to largely get another perspective on the issues identified in other recent tests.  The outcome was that the minor tweak (which was just a slight nerfing of an effect) seemed to have been positive, and the feedback I got closely aligned with feedback and observations from my last play or two.  Essentially the game could do with a little more ability to manoeuvre troops, the unit types didn't seem as distinct as maybe they should (though maybe that's not actually a problem), and occasionally you can end up with a hand of cards that is just useless in your current situation, so we want a little more flexibility there.

So, all in all another really enjoyable and productive day. Thanks due to everyone who attended and made it so good, as always.


What's been going on?

I've not been very good at blogging lately, but I have been moving a number of projects along, so I thought I'd just write a quick post about some of the things I have been working on lately.  If you know me personally or have been reading this blog for a while, you will know that I tend to flit around between many projects and am not very good at concentrating on one thing until it is "done", but I am finding a sort of rhythm where there are a number of games that I bring back after months (occasionally years!) of lying fallow, and on going through a few iterations like this with several games, it looks like the time spent is beginning to pay off.

The main game I've been working on over the last few months is Scurvy Crew, a pirate game which has its origins some five years ago, but has finally got to a stage where I think it is mostly there.  I stripped out a load of complexity, while leaving some engine-building aspects of card play (where you can spend part of the game building an "engine", in this case a set of cards, which you then move on to exploiting as you push for victory), leaving a game that generally only takes five minutes to explain and around half an hour to play.  I'm still not happy with the end game, and the balance of the cards needs looking into, but I really feel I'm getting somewhere now.

Scurvy Crew heading towards a conclusion. 

The Castle War, based on a 12th century war in England, is a game that hasn't been on the back burners for more than a few weeks at a time, and is less than six months old as a project, but has come fairly quickly to be close to how I want it to be.  I think it is a bit more of a "Marmite" game than Scurvy Crew, but I'm pretty pleased with how it is going.  There are some fairly serious balance issues to work through, but it's a small game and I feel pretty confident about it right now.

Mid way through The Castle War, which saw some interesting swings and roundabouts.

In a very different style, Corlea is the closest thing I have made so far to a regular "Eurogame".  It's inspired by an archaeological site in Ireland, and is about building an oak trackway through a bog.  My last attempt at working on this one was last summer, and it just wasn't working, but I have stripped out one big element of the game (building sections of trackway that you could then use to activate actions within the game) and moved much closer to an ordinary "worker placement" game (you have "workers" that you put in various parts of the board to take actions).  I'm still having all sorts of trouble with this but I think it's now moving in the right direction, so we'll see how it goes over a couple of playtesting sessions.

A three-player (though all of them were me!) game of Corlea just before I abandoned it.

Apart from these things I have also created early prototypes of two (count them!) very different games inspired by the bizarre instances of snail-related warfare in early 14th century illuminated manuscripts.  Not much to report on those for now, but we'll see.


Pieces of Eight

So, another month another trip for playtesting in London, and a cracking afternoon it was too.  These particular meetups are generally run as a series of 90 minute slots, during each of which everyone divides up to sit around a few separate tables, with a game being played at each.  If there are shorter games in the mix, they often get teamed up so that one table plays through two (or sometimes more) games in a row.  Most recent playtests of Scurvy Crew (last month's London test notwithstanding) have been fairly consistent at around 40 minutes or less, so I was sharing with another designer for a spell.

The other game, a bicycle racing game, was really good, by the way, and is in one of those states where it just needs relatively small tweaks to become a great little game.

First off, I was delighted to find that this play of Scurvy Crew (now on version 8) took almost exactly 30 minutes for a 4-player game. I didn't time how long it took me to explain, but it can't have been much more than 5 minutes.  Of the players, one had played the game last month, and one had played it about a year ago, when it was in a very different state.

Version 8 was a fairly minor revision, mostly being some tidying up of terminology (still not perfect!) and some tweaks to presentation, but it was also trying out a different way of handling end game scoring, making the primary scoring a "Knizia-like" (you score the smallest set of things you have collected, thus incentivising you to diversify your collecting of stuff) system, with a tie-break based on the crew you have deployed. 

I think that this scoring did work out a bit better than the previous version, but it's still not right.  It seems a bit bizarre that I have an almost complete game now other than the fact that it has no satisfactory way to determine a winner.  This is something that needs fixing as soon as possible.

There is an often-quoted adage that you should "kill your darlings", and I think that one of my darlings in this context is the whole thing about collecting sets of treasure icons.  I have tried it in various forms, and while it's fun to be gathering treasure chests and jewelry, it has never really felt right.  I am now thinking that I might just go for a simpler option and simply have a points score for each merchant ship captured and see how that goes.

Several other issues came up, including some very interesting thoughts from one of the players who came up with a number of suggestions for ways to improve the thematic feel of the game.  He was absolutely right about them, though in the majority of cases, they had actually been part of the game in the past but changed for gameplay reasons.  It is really useful to get a "reality" check like this from time to time, as it is a reminder that remaining connected to the game's setting and themes is really useful, and where compromises are necessary they should be done carefully.  I don't think I will go back on these particular changes, but I shouldn't shut off the option completely.

Time to get to work on version 9, I think...


Of Snails and Grails

I was vaguely aware of this in the past, and I don't know what reminded me of this recently (I think it was just some surfing the web for cool pictures), but medieval monks seem to have had some bizarre ideas when illuminating manuscripts.  In particular, there was a period around the late 13th and early 14th centuries when a significant number of manuscripts were decorated with images of knights doing battle with giant snails.  Don't believe me? Here is a great blog post at the British Library (check out their Catalogue of Illuminated Manuscripts for a wonderful resource of medieval stuff) with a load of examples and some context.
I have a personal challenge running at the moment to draw something every day
and this is my approximation of one of the snail battles depicted on a manuscript.
This is golden stuff for game inspiration.  There really need to be games about knights doing battle with snails.  I've been chatting to a friend who came to the same conclusion some time ago, so maybe we will be able to come up with something cool between us but I have also, after a few nights of weird dreams come up with a first attempt at a prototype of a light, trick-taking game based on the idea of knights fighting snails combined with a suggestion from a Twitter friend that grails would fit well with this.

This game involves simultaneous play of cards, tricks being played to collect sets of knight cards in assorted suits, get bonuses for collecting grail cards, and penalties for snails. We tried a three-player game of it today and it kinda worked, but it felt maybe a bit too chaotic.  I think I would like to play it a few times and with assorted player counts, as often trick taking games need everyone to get a feel for the game before it really shows its character.  The character of this game may be deeply flawed, but I need data to find that out.  On the plus side, as it is the game takes maybe ten minutes or so to play a hand, so it shouldn't be too hard to get more testing.

And here's what my quick, sharpie-scribbled first prototype looks like.
I don't think I see myself pitching this game to a publisher, but I think it could be a good exercise and if game play holds up after a bit more testing, working towards making it into a nice print and play game could be a good objective.  I just need to work on making medieval illumination style artwork.

And, of course, there is the possibility of a meatier game with the same thematic inspiration...


24 Hours of Pitchforks

It has been a while since I entered the 24 hour contest, but this weekend was the time to break the drought, with a game using the requirement "pitchfork", which is effectively an in-joke from a recent discussion amongst some of the contest regulars.

The idea that had been bouncing around my head since the start of the month was about a vampire, holed up in his castle, being assaulted by hordes of angry villagers with pitchforks and torches.  That sort of set-up is plenty enough to be a valid entry for the contest, and as I thought things over, a plan developed for a simple tower defence solitaire game, with lines of angry villagers attacking the castle from four sides, maybe with dice controlling what they do, and the player gets to (...mumble, mumble...) in defence.

Castle Crumpula: the first prototype. Totally functional, if nothing else.

By the time I started my 24 hours (and was officially allowed to actually make notes and stuff) I had managed to avoid forgetting everything I had been thinking about, and things had crystalised a bit.  I made an initial prototype, with cubes representing villagers, dice representing the strength of the four sides of the castle, and another die controlling where new villagers arrived.  I also made some cards with special powers on that the player could use to defend the castle, which you flip over to use, and flip back again when (...mumble, mumble...). I quickly added a few "special" villager mobs which brought friends with them, making the rate of their build-up less predictable.

Over a few test plays (including one with my long-suffering daughter) things developed some more. I added an additional "braver" type of villager, made tweaks to the vampire powers (actually changing them less than I thought I would) and gradually upgraded the prototype components to a submittable form.

The game is still very luck-based, probably with too low a chance of winning, and can sometimes take too long to come to a conclusion, but I'm pretty content with it.  I have all sorts of ideas for relatively simple ways to make the game graphically more interesting, and upgrade the components by mounting them on foamcore board, but the time constraint doesn't really allow such niceties, and I feel it is also good to keep things reasonably printer friendly.

Castle Crumpula: the version submitted to the contest. A bit prettier and a bit more functional.

So, if you are interested, here is my entry on the contest thread, which includes links to download the rules and components.  If you do take a look, then it's worth looking through the rest of the thread. There are some great looking other entries in there; it looks like this is a vintage month.

Edit: If you would like to see the full set of entries, here is the voting list.


Hunting the Scurvy Hare

We've just had the first of 2019's monthly Sunday afternoon playtesting session in London, which I make the third anniversary of my starting to attend the event.  This time I took along the venerable Scurvy Crew, in its seventh major iteration, along with my new, hand-drawn play mat to help organise the card layouts.

The group I had playtesting Scurvy Crew felt a bit different to what I usually get at the PlaytestUK meetups, and seemed to me a bit more like a slot I might have had at UK Games Expo.  Two of my players were game designers (one of whom had brought his own game, which I enjoyed testing later in the afternoon), while the others were enthusiastic people who just wanted to play something.

This resulted in a different type of playtest to what I was expecting.  Usually meetups like this result in some pretty intense and nit-picky feedback from designers, but the two non-designers in this group were inexperienced in this sort of game, and were struggling to get their heads around some of the concepts, so I instead got a good view of what parts of the game might confuse the unprepared.  The players were lovely and kept reassuring me that they were having fun, but the way they played and the questions they asked were quite revealing.
Heading towards the end, and the play mat works!

The main issue I saw recurring again and again was that they didn't understand the core card mechanism: you "recruit" crew cards by taking them into your hand from a display on the table, then "deploy" them by putting them face-up on the table in front of you, and "withdraw" them (take them back into hand) to use their skills and abilities.  Actually the "withdraw" action is a little more complex than this as you put the used cards aside and then take them into back your hand at the end of your turn.

I need to think about this.  While most players who have tried the game have had no difficulty with this mechanism, the fact that less-experienced gamers can get so mixed up is worth pondering.  It is entirely possible that the rules are fine and my explanation just didn't click with these players, or it might be that there is something more fundamentally wrong with the game.  Given feedback from the other players I am inclined to think that the terminology I use in the game may not be ideal, and also I need to figure out a cleaner way to explain the game.

Developing this thought a little more, I also think that the detail of I handle "withdrawing" a crew card to use its action is not quite right: you put a card aside to use it and then draw it into your hand at the end of your turn.  The reason that you can't just pick it up into your hand (something that you could do in an earlier version of the game) is to make the timing of card interactions clearer and prevent loop effects that would totally break the game.  I could get rid of the effects that are potentially loopable, but I think that they add more to the game in terms of potential "combos" (combine the right set of cards in the right way to make for exciting plays when you are able to do it) than they cause problems -- and this has been borne out by playtests so far.  So, on balance, I want these effects in play, so I need a mechanism to control timing of them.

I'm pondering this, but I might try simply flipping cards over when you use them rather than putting them aside.  It's more an explanation thing, but it might help a little.  We'll see...

One of the players also raised another issue which I was kinda aware of but hadn't really been thinking about.  Basically, two of the skill icons on crew cards ("navigation" and "repairs") work differently to the others: navigation can be withdrawn to give extra movement, and repairs used to counteract damage to your ship.  It's not too taxing, but it does mean two extra rules for players to remember, so if I can find a way to reduce that cognitive load a little it should make the game that bit easier to play.

Finally (for the purposes of this blog, anyway), a player suggested that another bit of complexity comes from the way that there are different actions available depending on whether your ship is in port or at sea.  I'm not sure that this really is an issue in itself (and can be addressed pretty well with a simple player aid card), but the additional comment he made was interesting: is it as much fun to be in port as at sea?  It clearly isn't: in port you are picking up crew cards and putting them on the table, while at sea you are blowing stuff up and amassing treasure!  I like the two-part nature of the game, but this comment tells me that I should at least consider making the port actions more powerful so that you can spend less time there.

Notwithstanding the handful of issues shown up, all the players said nice things about the game, which is really gratifying alongside the more actionable results.  Playtesting is mostly about trying to improve a game by finding its faults, but morale does need a boost from time to time.