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. 

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. 

Games to maybe resurrect...?

 Over the years I have started many projects. Most of them I have worked on for a while and then shelved for one reason or another. Some have come back after a while and I've done some work on them again with a fresh perspective. A few games have been around this cycle more than once. As I'm trying to get back into the game design groove, one of the things that I feel could be fun is to look at some of these old projects to see if any of them spark anything in me now. After all, they all had something that interested me back in the day...

So, I've been through the records and pics, and here are some of the games that I think might be worth having another crack at. Any thoughts from anyone reading this would be greatly appreciated. 

Also, apologies in advance for most of these having truly terrible working titles. Such things are not my strong point.

"Role World"... This one was a lockdown project which I used to learn a load about Tabletopia, and is kind of a map building and exploiting game. The idea is that players each have roles, with things that they can do and things that they score points for. To start with the roles all involve laying map tiles, but later on we move to building towns, roads and the like, and also things like dragons and their gold turn up. It wasn't well organised, and the idea that the rules and objectives change through the game raised some eyebrows (it's a different experience if you know what is coming up compared to just playing as a game of discovery), but I think there may be something here. And this one has never been in a physical form and I'd like to change that, as there is something pleasing to me about tiles being placed to build maps.

"Puffins in Hats"... A few years ago I did a personal challenge of drawing something every day for a year, and during that year I drew a lot of puffins for... reasons. One day I drew a bunch of puffins with hats on, and that got an idea into my head that there should be a game called Puffins in Hats. I did a set of passable digital art of these puffins, which is a deft way to start a game design, but nobody stopped me. Then I tried out a couple of variations of rules based on the art, and never found anything that felt much good, so this is the least functional game on this list, but I'd still like to figure out a game here.

"Corlea"... This is one of the most Euro-like games I've worked on, and it has been through a couple of iterations, being something more-or-less like a worker placement game about building a wooden trackway through a bog in iron age Ireland, all inspired by a visit to a fascinating site in County Longford. This wasn't terrible, but not quite engaging enough as a game of its type, but I still like the idea of basing something on this setting, and the overall mechanism of communally processing wood in order to build the trackway.

"Steampunk Workshop"... This one is not really an engine building game in the way that most hobby gamers would understand it, but rather a game where one of the core elements is assembling a shared "machine" of tiles with half-cog connectors. You then have the ability to traverse the machine in different ways to essentially convert resources, plus there are a load of gadgets with steampunk illustrations (which came out of that period of lots of drawing I mentioned earlier) that can help you in different ways. There are potentially some interesting interactions in the "machine" as different tiles get connected and player agents get in the way of each other, but I think the game felt a bit plodding in its pace when I last tried it.

"Courier"... You're a small courier company charged with delivering packages around the city. This was my attempt at a pick up and deliver game; in this case your playing pieces are card stands that you can move around, and the consignments are cards that slot into the stands, and which show where they come from and go to, and the amount that they earn for you. Actions are card driven, so you can upgrade your capabilities by buying more stands or more cards. The big problem I was having with this was in managing how the consignments could be brought out in a way that feels right for the game. 

"Explore and Settle"... This was a bit of a beast that was way too crunchy for its own good. I don't mean that good "solve a puzzle" crunchy, but more of a "way too much to think about for what it is" combined with a bit of confusion about one of the core mechanisms. It's largely based around a map build using standard cards, where the main part of the card is a square of terrain, while the remaining "tab" produces resources and other benefits, but only until it is covered over by another card. I think there is probably something good here, and I've not looked at it for a few years, so I might have some new insight.

"Monster Invasion"... This is a little solo game about defending a fantasy village from a monster horde, where each card constrains which cards can be played next. Some cards increase "threat", some allow you to power up in preparation to use magic, and some cards reduce the threat level. If you can't play, you can draw a card and increase the threat. Too much threat and you lose; get through the deck and you win. I rather liked this one, though the play was often tense and edgy until it wasn't, and then the game just played out. That's a matter of tweaking and balancing. I was also trying to figure out how to get boss monsters into the game in an interesting way. 

"Roll-Move-Race"... So I wanted to try making a roll & move game, so this one involves racing robots across the table on a track that you build as you go, with the potential to gain upgrades that provide various boosts and luck mitigations. I quite liked this (though it certainly had a long way to go) and I'm not sure why it fell off the "active" pile, so I should probably pull it out again and give it a fresh look.

I think that'll do for now. I'm sure I can make some good progress on some of these, but we'll just have to see what grabs me most. As I said, any thoughts, questions, or input would be gratefully received.

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

Physical Artifice

So, The Artifact...

Of the projects I'm currently working on, this one is probably the one that has most consistently been developing over the last year and a half. It is a co-design with the inimitable Alex Cannon, who I got to know through a couple of Twitch streams in the first year of the pandemic, and who has an uncanny mind for puzzles. Since January 2021 we have been having an online meeting most weeks, usually working on or playing a virtual prototype we had built in Screentop.gg, and sometimes just chatting, partly about life and partly about the project.

Then a few days ago we managed to get together with a physical prototype and play the game on a real table. We sat in a coffee shop for a while, drank beverages, had a couple of plays through, and talked through some of the implications of what happened in the games we played.

A 2-player game (the blue meeples are replicants) coming close to an end.
Just off-camera to the left are project boards, which are the paths to victory.

Boy, I have missed this. While we have got this game a long way with essentially entirely online collaboration and testing, you can't beat moving components on a table, at least not when that is the intended playing format for the game.

The big headline is that the game felt pretty natural to the two of us to play, and took maybe half an hour or so per game. How it would feel to other people is unknown right now, but hopefully we'll find out sooner or later. The half hour of play felt pretty good -- a bit of brain crunch that might have been too much if sustained for a load longer -- but it occurs to me that maybe there are too many bits for a relatively short game. The setup and teardown is not exactly challenging, but... I dunno, it's just something in my head as I write this.

Just to catch you up, the central conceit of the game is that there is an alien artifact that has crashed to earth and we are corporations (or something) trying to research and exploit the technology contained within by assigning researchers to work on the expanding knowledge space that is represented by (mostly) domino-like tiles that get added on each player's turn. The game ends when one of the several project tracks off to the side is completed (each works a little differently with how they can be progressed and what benefits they provide, and there is a little interaction between them), and the completed project dictates the victory conditions for the game.

We've been tinkering with a new mechanism based on what we are labelling as alien slime (in this prototype it's to do with the yellow cubes and the black squares), which we think opens up some interesting possibilities, particularly adding more spacial elements to the game (which otherwise are less than you might think for a tile-placing game). The couple of variations on the mechanism we tried were underwhelming, but found some directions we could push in, and a later, virtual session experimented some more. Still a long way to go here, including considering whether we really should be using this. 

The Artifact has twisted and changed quite a lot in its 18 month history, with mechanisms added and removed along the way, but it has always revolved around the tile placement and use of workers/researchers to tap into knowledge resources on the tiles. We seem to have settled on a form of path to victory now, but in the last few months we have just been testing with the two of us while we made some major changes, so we don't have the important data from other people looking at what we have been tinkering with week in, week out, and that is potentially concerning. But I think we're getting to that point of going back to our friendly (but occasionally brutally honest) volunteers/friends and seeing what they think.