Playable Puffins

So this is yet another game project. I'm not going to go into great detail about it as it's basically just a toy I'm playing with. Long story short, last year I drew (on paper) a picture every day, and I got really into drawing puffins, and it was mentioned that a game about puffins might be fun. This jumbled around in my head until, for some reason, I got the idea of puffins in hats stuck there. (I actually wrote about this almost exactly a year ago, as it happens.)  

Some months later I decided to learn how to use a digital paint package (Krita, seeing as you asked), and soon I ended up with a bunch of pictures of puffins wearing hats.

I don't know much about art but I know when it's got puffins in it.

Actually, that's a lie, or the "soon" bit is anyway. It took bloody ages. I have even more respect for jobbing illustrators than I had before.

Anyway, I did actually have the foresight to do the art in such a way that I could separate the hats from the puffins, made some cards (adding in some cats -- this time using stock cat icons as placeholders -- because the game also needed cats, natch), loaded them into Tabletopia along with some coins and stuff, then managed to gull some innocent bystanders into trying the game.

As expected the game wasn't good, but I got some useful feedback and have tried to tern things around a bit.

The mark 2 e-prototype, now with a First Player Puffin.

So far I've just tried this iteration on my own with three other mes across the table, and it's difficult to tell if it is an improvement over the precious one. At least the changes didn't feel too aukward. Hopefully I'll get some friends to give it a go soon and we'll see what shakes out.

A World and Some Roles

This is something that has been bouncing around my head for a number of weeks now and I've been trying to find a way of expressing it. The story goes back to reading "The Well-Played Game" by Bernard de Koven, a book that is mentioned in many texts on game design. It is more a book of philosophy than of game design, and explores the interactions and tensions between "playing" and "games".  Games, in this case, including board games but mostly focusing on social and playground games and their extension, sports.

One of the lines of thought in the book included that a "well-played game" is one where the participants all take part willingly and enthusiastically, and can leave the game if they no longer wish to continue, and may even be able to change the way they play. There are plenty of angles to this well-played game explored in the book, but this is an area that had my mind firing off. Could I make a board game where players could come and go if they wish, and which allowed them to change the way they played?

As an aside, most roleplaying games I know about can be played in this sort of way: the core is the developing character narrative and a gamesmaster and the rest of the group can work together to adapt the play however the group wishes. I am certain there is a lot already written about this sort of thing (the RPG community has spent a lot of time thinking about how games are played), but that's out of my area these days.

After some sleeping on this, I started thinking about a world, growing from nothing, with players building the world, populating it, and guiding its inhabitants as stuff happens.  One player could be creating a map by laying tiles, another could be building villages on the map, and another could be an adventurer exploring the map, and so on.  You would take a role, which would give you a simple set of actions that you can take, and a way that you score points. When you choose, you may discard the role, take a new one and now, instead of being a terraforming deity, you are now a dragon gathering gold for its lair.

I threw together some tiles in nanDECK, going for an arrangement of square tiles, each of which contains four triangles that are put next to other triangles to make squares arranged at 45° to the alignment of the tiles. I'm not sure why I did that, but it seemed fun at the time. After printing and cutting a few of these I decided that I would actually take the opportunity to get some practice in playing with Tabletopia, so shifted my efforts to a digital version that I might actually have a chance at playtesting during the ongoing lockdown.

Printed tiles. You get the general idea

One of the advantages of an online platform is that you can import all sorts of components and just experiment. I have at home a good supply of assorted game components, but for tiles, cards, and so on, there is a load of printing and cutting required, which I have got pretty efficient at, but is still something of a grind. Tabletopia has a decent library of standard components (not covering everything, but good enough for many purposes) that can just be dropped into a game project. Preparing tiles and cards for upload and managing them in the system is a bit of a pain, especially at first, but there are some big advantages. Like, for example, when I decided I wanted twice as many tiles, I could just click on the existing stack and duplicate it.

I fiddled about with my virtual prototype for a while, building up a few of the roles that players could take, putting the instructions for them onto oversized cards that I added to the prototype, meaning that pretty much all of the rules would be within the game itself: each player could just take a role card, read it, and start playing.

Eventually I got to the point where I enlisted a friend to try the game out and see how it held together when I was not playing all the parts.

Testing with another human was very revealing.

As is so often the case, the game didn't play particularly well. The general concept of the game seemed OK, but it was just too damn complicated for the light-and-breezy type of game I was hoping for.  One of the big issues was that there was too much variation between the different roles, and as a player you were more or less having to learn a new game each time you took a new role. And the way that you played a role for as long as you wished before changing just didn't sit right.

At the start of the design process for this game I was wondering if it should be competitive or cooperative in nature, and I went for the former, mostly because it is what I know best and cooperative games can be so much harder to create. After all, not only do you need to make the game mechanisms work properly, but you need something for the players to be working against, and getting that right is hard.

Anyway, at this stage I decided that what the game really wants to be is a series of puzzles, where what one player is trying to achieve can interact with the other players' actions. And with this in mind, cooperative play could be best.  A game of this sort of form could be played against some sort of a timer, so the roles would now have an objective (on completion, or if you decide to give up, you switch to a new role with a new objective) and the aim would be for the players between them to complete a certain number of objectives before time run out.

A literal timer is out of the question for this. Real-time pressure, while exciting in some contexts, just adds stress and I don't want this to be a stressful game.  What I actually decided to go for is to introduce dice. A bunch of (six-sided) dice get rolled, players each take one in turn to use for the movement of their avatar, until there is only one left, and that die gets placed in a "timer" display, and a new fistful of dice are rolled.  When either one of each number (1 to 6) has been accrued, or there is three of a single number, the game ends. This way the players are partly at the whim of fate, but also have some control over how they allow the game to progress.

So building the next iteration of the game was largely about this timing mechanism and the idea that there should be core rules for everyone to learn and the roles just give minor variations, which may accumulate as you move through the game, but at no point should require anyone to absorb a large raft of new options. Getting these changes into Tabletopia can involve a little faffing, but I'm not having to print and cut physical components, so there is something of a trade-off.

I then managed to get a playtest with a couple of friends, who got on pretty well with the general concept of the game and its overall flow, but had plenty to say about it as well. I was left with a feeling that this iteration was definitely an improvement and I liked the game in its cooperative mode. The next thing to do would be to extend the selection of roles and sequence them so that there is something of an arc to their progression. One suggestion was to have three phases of play: one being to build the world, the next to add complexity and cause trouble and strife, and the third to heroically put everything right. Players then have to get through a certain number of roles, or complete some of the "ending" roles before the timer runs out.

A few turns in, working with the first set of "world building" roles.

I would also like to have some more significance to how the timer operates, maybe having events triggering when certain sets of numbers are completed, but I can worry about that later, I think.

As an aside, I have also figured out the "magnetic board" option on Tabletopia, which allows you to have components neatly snapping into position when you drop them, and have a grid board that makes placing tiles much easier.  What I made isn't as big as the potential play area, but it'll do, and you can always add more tiles alongside.

A "magnetic" board can make everything so much smoother and cleaner.

Last up, I need to think of a decent working title for this game. I've been calling it variations of "Role World Thing", which doesn't really have any sort of ring to it. Suggestions would be greatly appreciated.

Virtual Invasion

So, Invaded, my old nemesis, are you back to torture me once again?

As you may remember, a couple of years or so ago, a large amount of my game design life was spent working on a "reverse colonialism" game with the working title, Invaded. The conceit is that you are tribes in a comparatively peaceful land, and have been invaded by a powerful colonial army that wants to settle in your lands and take all your stuff. Do you try to resist, keep out of the way, collaborate, or what?

The game has changed a lot from its early days, and works reasonably well, but the experience can be pretty inconsistent, and the game takes longer than I would like to explain, but it has some interesting features, particularly the way that players compete with each other and jointly control the invading force as it pushes forwards.  Eventually I pretty much burned out on the game, and it has been nearly a year since last time I looked at it.

Back in the present day, and after my chat the other day about online game testing, I have decided to buy a subscription to Tabletopia. I don't want to get into religious wars, but right now it seems to be a better fit to me than the main alternative, which I'm sure I will also continue to fiddle with a bit.  Anyway, I now have the capability to have a few games in my workshop, so I decided to start pulling Invaded's assets in to see how I do with setting it up.

Some of the Invaded components set up in Tabletopia.
If nothing else, I think this tool will be great for generating prototype rulebook illustrations.

I've actually been musing on this game for a while now, and a way forward has been bouncing around my brain. At the moment there is a system that ramps up the aggression of the invaders through the game, making them more demanding in trades and more likely to attack. The problem is that this required multi-part cards that needed to be read in conjunction with a score on a track, and this was a bit fiddly and easy for players to get confused.

The idea I am working with is that everything is done with cards, rather than my previous system of having the invaders controlled by card play but player tribe actions coming from a standard menu of options.  Under the new system, each card a player holds involves an invader action and a tribe action, and you do both of these on your turn. The ramping up of the game can come from there being two decks of these cards, the first one being more benign, but as these cards are used, they are discarded from the game and replaced by the second deck which contains more powerful actions for both sides.  This should remove the need to do all sorts of tracking and cross-referencing of status levels and action options, and make the game flow more smoothly. That's the hope, anyway.

It'll take me a little while to get all that set up as it is a massive overhaul of the game at a level that has not happened since its early days, but I think it will be at least worth trying.

Prototyping and Testing, Virtually

I talked in my last post about playtesting online and, in those instances, playing "roll & write" style games, which can be done over a videoconference system if everyone has the wherewithal to make whatever sort of record/play sheet that is required for the game. 

Since then, I have played prototype games (both mine and other people's) using the two most commonly talked about 3D simulators for board games: Tabletop Simulator and Tabletopia.  I don't have enough experience with either system to compare their pro's and con's in any detail, so I'll just discuss my first(ish) impressions. Lots of other people are talking about this stuff in great depth, so I'll just generally hand-wave.

Both systems have a physics engine that allows components to interact with some semblance of reality, but rely on supplying the components and the players knowing what to do with them. This is fine for prototyping: I don't particularly want to code in all the logic for a tabletop game that is still in development.

My implementation of The Castle War in Tabletopia.
This is just a mock-up, but it does work for real, and I've had a couple of very useful test plays.

My overall impression of each is that Tabletopia is more polished (it still has its problems, mind: one prototype I was playing with had a recurring issue with tokens falling through tiles and ending up underneath them!), while Tabletop Simulator is more flexible. I like that TTS allows you to add components on the fly as you are playing, for instance, but I do like the cleanliness of the Tabletopia interface and the really nice library of standard components.

The cost model of both systems is important here. You need to pay to install Tabletop Simulator, as do any people you want to play with, but from then on, you're free as a bird. Tabletopia, on the other hand, allows you to dip your toes in for free, and as a player that may be all you need, but if you want to play in a load of simultaneous games, or create more than one, you need to pay a monthly subscription, but your playtesters can join you for free.

My first experiment in Tabletop Simulator, part of an idea I have just started toying with.

Playing on either system tends to result in games taking a lot longer than the physical version would and, especially at first, everything can feel really fiddly. That improves as you get experience, but I don't think it will ever go away. I also massively miss being able to actually watch how people play and engage with the game, as that usually provides some of the best feedback, but this is so much better than not being able to playtest at all, and maybe it will lead to a faster testing rate than I have managed in the past. Plus it's a good incentive for me to get better at discussing games with testers afterwards.

I think I'm going to tinker with both systems for the time being, partly because people I am collaborating with and otherwise talking to are split between the systems, and partly because I'm not yet sure which is best for me.

It is also worth noting that these two systems are not the only games in town. For instance, if you don't want all the 3D whistles and bells, there is Vassal, a pretty old project that was, I believe, originally set up to run hex-and-counter style wargames, but allows just about anything to be configured if you can put the effort in. I've taken a bit of a look at this, but not got a game running yet. Similarly, but newer, I have recently heard of Screentop, which I have not yet taken a proper look at, but may be useful.

I'll just finish off with a few links to things I have recently seen other people have been saying on the subject...

• An interesting comparison video of TT and TTS from a player's point of view.
• Gil Hova on Twitter about why he likes TTS for prototyping.
• Ian Brocklebank blogging about his growing appreciation of online playtesting.

Coronas, Crowns, Zooms, and Another 24 Hours

It has been an odd old month. Scary for many, confusing for some, disruptive to everyone, and it looks like we're only getting started. From a game design point of view, having the country largely locked down (for some definition of locked) means not getting to meet up for playtesting (or even playing), events like UK Games Expo postponed or cancelled, and meetings with publishers and other designers are having to be severely rethought.

On the other hand, this is an opportunity to rethink some of how we do things. For instance, last week I attended an online playtesting session with a group of folk who would otherwise have been having a meetup in London, made a couple of new friends, and learnt that some sorts of games (many "roll & write" -- and similar -- games, for instance) work pretty well remotely.

This week I decided to have a go at the 24 hour game design contest for the first time in... oh... far too long.  The "requirement" was "Crown", and I decided to try making a game that could be played remotely, with nothing more than an audio connection and some trust that your opponent won't cheat.

I ended up with something that works OK, I think, and is actually intended to be a 2-player only game, a race to be the first to complete two out of three scoring tracks but also doing it before enemies arrive to destroy your stronghold -- those enemies being controlled, at a very basic level, by your opponent.

What pleased me here, though, isn't the game itself but the fact that it had a couple of playtests with people who are not in my house. A shout out on Twitter resulted in a Zoom meeting with a fine volunteer (thanks Nik) over which we played the game a couple of times, the first of which revealing that, if my explanation is not sufficiently clear, the game can easily go off the rails in ways that I would easily spot if testing face to face. The second play went way better, and showed that the game basically worked. A couple of hours later I was at an online playtesting meetup with a couple of other designers (thanks Ellie and Bez), who had a play and helped find a few issues with the game, some of which I was able to address before my 24 hours was up.

As always, the aim of a 24 hour contest isn't to really to make a great, well tested game, but to get to a playable print & play game that could be taken forward from there.   I usually figure I have done pretty well if one of my entries has had any playtesting at all with a player that isn't me, so having feedback and input from three people was amazing.  If you are interested, my contest entry is here, with links to the rules and playsheets.

And I think that this is where I wanted to end up with this post. While we are all pretty much housebound due to the Covid-19 pandemic and face-to-face gaming with anyone outside our immediate domestic situation is not a possibility, gaming doesn't have to stop. We just need to be a little more creative and flexible about how we do things. And, in my case, need to consider the current restrictions in my design activities.  (There are other options too, which I expect I'll talk about soon.)

Stay safe.

Castles in Their Proper Places (ish)

A long story about a small game design decision.

I've not done anything with The Castle War for a little while, but have been thinking about it, particularly in light of some feedback I received.  If you didn't know, or don't remember, this is a two-player card game inspired by the 12th century civil war in England between King Stephen and Empress Matilda, which eventually led to the crowning of Matilda's son as Henry II. The game is based on a period of that conflict where there was essentially a stalemate characterised by a series of sieges and exchanges of castles, where there were no significant open battles.

Game play involves the two players deploying forces and using tactics and events across six castles that were all significant during the period. If one player ever controls all six castles, they immediately win; otherwise, whoever controls the most castles at the end of the game (when the card deck runs out) is the winner.

But with six castles, a tie is clearly possible. How we break that tie is a question that has taken some thought.

I drew a sketch map to show the (approximate) locations of the castles.

Originally, the castles were nameless and numbered, 1 to 6, to tie in with a dice rolling system that was used to open up opportunities to the players. Then if there was a tie at the game end, you added up the numbers on the castles you controlled and whoever had the highest score won. This meant that the high numbered castles were more valuable than the low numbered ones, but if you concentrated on defending the two highest scoring castles, the other player could win by capturing the rest, even though their combined score was not as high. This was fine, but somehow a lot of players seemed to have difficulty internalising that the scores were only useful for tie breaking.

To give the game a little extra flavour, I wanted to name the castles, so a little research yielded the six locations depicted in the rough map above. (Fun fact: I live in between Faringdon and Wallingford, and have visited the sites of both castles.)  Furthermore, I wanted to have the initial ownership of the castles reflecting history as best I could.  (Another fun fact: Wallingford castle is distinguished in having not changed hands throughout the conflict, despite being sieged and attacked with some vigour.) The problem here is that, in order to keep the initial scores balanced, I had to distribute the names of the castles along the line of six with no real attention to geography. This was fine from a game play point of view, but as this is inspired by history, it bothered me a bit.

So now a slight diversion. We'll bring this back in a bit.

Before this stalemate stage of the war, Matilda was in a very strong position and very nearly got herself crowned as Queen, it seems there were effectively three power bases that needed to be brought onside in order to become officially the monarch: the Church, the royal treasury (based in the old Wessex capital of Winchester), and the people (or at least the leaders) of London. Matilda had gained Church support and held the treasury, but never managed to convince the leaders of London to back her cause -- partly, it seems, due to her own arrogance, and partly due to the actions of another Matilda, this one the Queen, and wife of the then-imprisoned King Stephen.

Eventually, Queen Matilda and her allies managed to retake Winchester, capture some key prisoners, and arrange for an exchange, thus freeing the King and bringing us to the Castle War's stalemate situation.

Anyway, three factions that could be influenced... that gave me an idea...

If there was some form of way of tracking influence with these three factions or power bases, then whoever has influence over the most of them wins an otherwise tied game. There are a number of ways this could be handled, but I have decided to make each faction a simple binary: they are supporting either Stephen or Matilda, and I chose to represent this with a set of three flippable cards, similar to the way I have players flipping the castle cards to show ownership.

I then added an icon representing one of the factions to each card in the game, with an even distribution of these icons throughout the deck.  The plan now is that each player can now take an action on their turn to flip one of the faction influence cards by discarding a set of three cards with matching faction icons on them.  The set of three decision is intended so that, with a full hand (of six cards) you stand a decent chance of having a set, but using it will dramatically reduce your options for the next turn and you may have to give up on some other useful cards.

With the numbers on the castles being irrelevant for game end purposes, I can now arrange the row of castles in an order that follows a plausible route between them that you may see in the map, from Wareham to Wallingford, and as there are some minor elements of adjacency in the game, that makes more thematic sense now.

You wouldn't put the faction cards there for an actual game, but you get the idea.

A common question from players is about how to cycle out unwanted cards in hand, so this system will give a way to address that, assuming those unwanted cards can be combined into a set.

So far this seems to work OK, but I am a little concerned that collecting three matching icons to gain influence in something might just feel boring and unthematic to a lot of players.  I'm hoping that it's one of those elements of the game that if you totally ignore it you may be at a disadvantage, but if you focus on it too much, you will almost certainly lose.  It should give a small, but meaningful, additional option at some points in the game, without dominating.  Only more playtesting will show if this is actually a decent decision, and if the set collection doesn't work out, I am certain there are other options to allow us to do something similar in the game.

The other real issue here is that this setup gives Stephen an advantage, winning the tiebreak if nothing else changes, so Matilda gets the first turn, which also appears advantageous.  Again, playtesting should help reveal if one side has a significant advantage here and if there is, there are plenty of ways to mitigate that.

Grab Bag Hare

I haven't been to a 3rd Sunday playtest at the Jugged Hare in London for a couple of months, but finally managed to get myself in order for a trip last weekend, taking with me Grab Bag Zoo, my co-design with Mike Harrison-Wood, who managed to make the trip too, for our first face-to-face meet since we started working on the game.

There was a little uncertainty as to whether I would actually get into London as we had just been hit by the second big (by British standards) storm in two weeks, causing all sorts of problems for travel (not to mention people's houses getting flooded and property damaged) around the country. Checking the situation before I left home everything looked OK for my planned route, and the train was close to being on time, but we ended up being delayed by an hour en route due to a problem that emerged later. Unfortunately this meant I was not able to meet with Mike before the main meetup, but I managed to arrive comfortably before the playtesting started anyway.

Thanks to Mike Harrison-Wood for taking a much nicer photo than I managed to take!

While waiting for everyone to arrive, we had a quick play of Grab Bag Zoo for five players, including me, with Mike sitting out and taking notes. This worked pretty well, but the players fell massively short of winning. We suspect that the game is just too hard for larger player counts.

A little later, with the whole group assembled, we were able to get some more plays, this time for four players, this time including Mike while I observed.  One of the key things I learnt from this is that for a fast-moving, real-time game, it can be difficult to take meaningful notes about what is going on!

The group was enthusiastic overall and there was a lot of intense activity in the game, and they were keen to play a couple more times, meaning that we managed to try out all four of the zoo board sets that I had brought along between this session and the earlier game. The idea is that the game has a number of different sets of boards, each providing a different style or intensity of challenge, and this proved to be the case: the players took a different approach to each set of boards. The balancing of the board elements isn't right yet, but we are learning how the different options affect play.  However, we are also learning that some of the rules we have for the game are just too complicated and can easily get missed or wrongly applied.

So, I think that this was a really helpful testing session. We got feedback that the game is pretty compelling, but also identified a number of problems that need addressing, and we are getting to work on that.  I'm also discovering the fun of working on a very short game where you can easily just say, "Let's try that one more time, with this change..."

Of course, there were other games there, and it was fun to work through a few games designed by others: an interesting "short straw" game, a game about being a band, recording music and going on tour, and a nicely stripped back investment game. It's always good to get a look at some of the projects other folk are working on.