Zoo In A Bag

I think that one of the most promising designs I have in the works is the one that I am working on with Mike Harrison-Wood, Grab Bag Zoo. We have already pitched it to publishers (no luck so far) but it still needs a load of work, and we have basically spent the last year with the game on the shelf as we took a break from it.

When you are working on a project that hits a point where forward movement becomes really slow, taking a break and getting some distance can be a helpful approach. If you don't get back to the game, then maybe it wasn't so great after all.

This is most of the components from the most-recently tested Grab Bag Zoo version.

As I mentioned in my opening sentence, I actually think that this game has a lot of potential to it. A conversation with a publisher who took a look at it helped us figure out what the game has going for it. To start with, the combination of a cooperative game (you all win or lose together), which is played in "real time", and involves feeling in a bag for things is an unusual combination. 

The essence of the game is to complete collections of different types of animal by pulling shaped animal tokens from a bag without looking. Players take it in turn to have the bag, but have to work quickly as there is a sand timer running. If you complete all the collections before time runs out, everyone wins!

There are a few real time cooperative games out there; Magic Maze and Escape the Curse of the Temple are two that immediately come to mind. Grab Bag Zoo has a different kind of vibe to it due to the communication that the game affords. In Magic Maze, verbal communication is banned apart from at specific times, and in Escape everyone is so focused on their own dice that it is often hard to get much information across to your co-players other than "help, I need an unlock!" In Grab Bag Zoo, only one player is properly active (with the bag) at any time, and watching groups playing, there is often urgent encouragement and advice thrown across the table. ("Just pull anything out, dad!")

For bonus points, the fact that it is based on animal shaped pieces feels like a win for a lot of people. I get the impression (but no supporting data) that most folk get a warm, fuzzy feeling from handling animal toys. Additionally, you don't need to explain to people that this piece is an elephant and this one is a giraffe, you just need a picture and everyone gets it.

That said, the game might work better thematically if players were trying to pull parts to fix a spaceship, or service a formula 1 racing car. The whole "collect this set of animals for some reason" thing feels a little weak at the moment, but I can't help but feel that the response of most potential players to that would be, "OK," rather than, "Why? That doesn't make thematic sense." I'm happy to be proven wrong.

So if the game has so much going for it, then what is the problem? Why isn't it already on shelves in my local game shop?

(Deep breath...)

OK, so fundamentally there is the trilemma of the cost to produce, what the game delivers, and the complexity of the rules. I will explain...

The game as we originally built it had 45 wooden animals, 5 each of 9 different designs, plus some cards, a bag, a sand timer, and maybe some other tokens. Working out an approximation of production costs, it turns out that the game would be likely to retail for something like £30 to £40, unless a publisher could do a huge print run in order to bring the costs down. That price is pretty fine  for hobby games, but the game play was a lot more like a family game, and most families feel that £20 is quite a lot for a board game. 

If we make the game more interesting for hobby gamers, we probably don't bring the price down, and we risk making it more inaccessible for families, who we would really like to be able to enjoy it. Having more to think about is likely to make the game harder to teach - unless we can come up with some really clever angle. In essence, we need to square the triangle of:

1. Reduce the cost of production as much as possible
2. Make the game really easy to pick up and start playing, even for very casual gamers
3. Make the game interesting enough for folk to keep wanting to play it

I think that right now a good starting point would be to deal with those first two points on the basis that if the game can be picked up, played, and enjoyed really quickly, then there can be optional additional challenges and wrinkles that can be added in later. Let's try to make the core as slick as we can.

First off, the number of components... We started with 9 different animals because it felt like a good selection, but then we ended up trimming this back for a starter game, introducing more types of animals over the course of a few plays. This wasn't terrible, but it did mean we still had a lot of wooden components and there was more sorting out of stuff in order to get playing, which pushes against point 2, which is to make it easy to get started.

So I have decided to try simply reducing the number of types of animal in the play set to 6, with 4 of each, and created a set of collection cards featuring only those animals; the set isn't well thought out at the moment, but it's a start.

Aside from that I have a slightly expanded set of "helper" and "challenge" cards; the previous iteration also had these, with mixed results, and I want to explore that space a bit. Again, I have gone for a "throw it at the wall" selection that will allow me to try out various combinations of options and see what grabs people's interest.

Finally, I have changed the time track to be a small pile of cards which can be combined to provide the same effect, and I have done away with other tokens for the time being.

This all means that the game components are down to 24 "animeeples", 1 bag, 1 sand timer, 20 tarot-sized cards, and 25 poker-sized cards, which feels a bit more manageable, though, and actually gets the wooden components to fewer than classic kid's game Tier auf Tier, so that feels like a bit of a win.

I think I should have a couple of playtesting opportunities over the next couple of weeks where a game like this would be suitable, so I wanted to be ready as I have been very lax at this sort of thing over the last few years. But now, I'm ready... I think...

Getting Systematic For That Dungeon

It has been a while since I wrote about my solo dungeon crawl project, and to be honest, I've not done a lot of work on it in the meantime, but neither have I been entirely idle, so here's a catch-up on where we are.

You may remember that I decided to try making a solo journalling roleplaying game based on a fantasy dungeon crawl. So you play a character on an adventure in an underground cave complex, the game provides prompts, challenges, and situations to overcome, and you write a record of what occurs in the developing story.

I've been trying to figure out a game system to handle this, and last time I wrote on the subject I had come to the conclusion that I wanted to be light on rules and light on detail, leaving room for the player to fill in details. 

Since then, I have been leaning even further into the light touch territory. So here is an outline of the game system as I am currently writing it up. This is going over a fair bit of stuff I talked about in the previous post, but it feels to me like it is getting more solid.

If I were to make a dungeon crawl game, I'd be very tempted
to go for an unoriginal (some might say classic)
"adventurer entering a dark cave" image for the cover.

As a player, you control a hero and their sidekick. The narrative conceit is that you are actually the sidekick, recording the exploits of your more mighty companion.

Character creation is essentially rolling for (or choosing) some broad skills from a couple of tables, which could result in, for example, the hero might have athletic prowess along with a quick mind and knowledge of natural things, while the sidekick might be good at armed melee combat and solving puzzles. I have tables for generating this, but I don't think I have them "right"; they are, however, something to get started with.

You also have a number of health points (run out of those and the hero dies) and fortune points (run out of those and you can't escape any consequences of things going wrong).

When something happens to your little team, you basically have to decide which of your characters' abilities could be used to overcome the problem and write this into your journal. I won't provide detailed guidance about what is and is not applicable - it's a matter of deciding for yourself. I was previously thinking that there would be a limit to the number of times you can use each thing, but for now, not so much. Each thing that you apply adds a +1 to your ability to overcome it. Then you roll a die, add those modifiers, and if you meet or beat a target number, you succeed and write this up as appropriate. If you fail, then failure by a small amount results in the loss of either health or fortune as you sustain an injury or ride your luck to get out in one piece, or if you fail by a lot, you lose both health and fortune. 

I reckon you can probably award yourself additional fortune if you use an ability you haven't used before, or if you are able to write in a thematic link to something that you had previously encountered - in particular, omens, which I'm planning to introduce as part of the journey to the dungeon.

Yes, this can easily be abused, but having decided that this is more about writing up an adventure than it is about detailed Old School style dungeoneering (there are plenty of very good options it that's your jam), I feel freed and able to just go with the flow. Of course, once I share a playable version with other people, feedback could completely blow my assumptions, but we'll see. 

Just as a little aside, in board game design I would always advise that it's a good idea to just get something, anything that is even remotely playable to the table as quickly as possible, even if it is just for a solo test, and not spend too long "theorycrafting" and thinking about how best to create everything in the game. So why am I not following that advice in this project? 

Well, it just feels like the style of game this is allows me to just think it through and gradually write more stuff down. I can even try rolling on tables I create and think about what I do with the results, so in a sense I am testing as I go, but if I am honest, I am not doing that very much. I feel that what I should be doing is settling down for an evening or two and blasting out a first draft that I can then try playing through, but I think my brain isn't really in the right place for that yet. So I plod onwards, and every entry in every table that I create is a step in the right direction. We'll get there eventually.

I was going to go further with this post, but I feel that I would be better off just posting smaller bites for now and try to get the momentum rolling. Next up: travelling to the dungeon, omens and stuff, and maybe the start of the dungeon itself. And I'd better also actually get my working document into a state that I can share.

Civilization 1: No, not the computer game

I'm going to try something a bit different here and start a deep dive into a classic game, looking at some of the things that make it great and some of the things that I might want to change, and thinking about how I might create a game that takes some of its ideas and implements them according to my own design aesthetics. This may or may not turn into a playable game, but we'll see how things go.

The game I want to look at is Civilization, an epic game about the ancient peoples of the Mediterranean basin, designed by Francis Tresham and first published in 1981. To be clear about my own credentials with the game, I am not an expert in it, having only played it a handful of times, and not for a good few years now. Part of the reason for this is that, while I very much enjoyed every time I played, the game is huge and long - the back of the box I own says that the full game takes 6 to 8 hours, and I feel that range is optimistic if any of the players are inexperienced. This is a game that I would normally say that you should start in the morning and not plan anything for the evening. 

My copy of Civilization: box, board, and photocopy of rules from a different edition.

And to be absolutely double clear, I am not trying here to "fix" Civ, or make a new, better version. I'm just taking a closer look at something that has been stuck in my brain for quite a while now to see if I can learn anything from it. There are whole communities of people out there hacking the game in all sorts of ways and there is no way I can compete with their knowledge, so if you want to see what the real fans have got up to, Board Game Geek's forums for the game might be a good place to start looking.

Anyway, this is all way too much for a single post, so I'll just look into some aspects of the game this time, and hopefully continue in future posts and see where it takes us.

The version of the game that I own is the late-80's Gibsons edition, but with a missing rulebook that got replaced at some point by a photocopy of the rules from one of the Avalon Hill editions. I don't think it matters that much (apart from things like tokens being different shapes to what is described). I'll be basing this discussion on that edition (though I might go looking online for more material) and not on any expansions or other developments of the system like Advanced Civilization or Mega Civilization. If you think I'm missing out on something important because of this, please comment to let me know.

By way of overview, Civ is a "sweep of history" game for up to 7 players, set in the area around the Mediterranean Sea, and takes players from a period of growing tribal kingdoms up to a period around the time when the Republic of Rome were developing a significant beef with Carthage and Archimedes was advancing scientific knowledge by taking baths. The game sees players expand the influence of their nation by settling (and sometimes fighting for) new lands, forming cities, trading goods with each other, developing new technologies, and withstanding calamities that strike from time to time. This takes place over a series of rounds, and at the end of each, time moves on and, if they have achieved certain goals, the players all move along the snappily titled "Archaeological Succession Track" - and whoever gets to the end of the AST first is the winner!

Where to start?

Sidebar, kinda: I've been sitting on this topic, and then this particular post in an unfinished form for quite a long time. What if the post isn't interesting? What if I get bits wrong? What if I just look like a clueless idiot? Eventually I just figured, what the heck? Plenty of my posts in the past have probably been interesting to nobody but myself, but then some of the ones I though uninteresting resulted in someone contacting me to say thanks for introducing them to something. So I guess the real message is to not listen to that voice in my head that keeps questioning and being negative: if I just write stuff down, then I at least have thought something through and can move on, and there is always a chance of being useful or interesting to someone. Anyway, sorry for the digression (this post is partly about thought processes, though!), and on with the actual plot...

I guess the board is a good place to kick off. It is a map, divided into land and sea areas, with the land areas further divided into regions, different combinations of which are used for the game depending on player count, which can look a bit weird during play, but works well to keep gameplay tight regardless of how many of you are playing. The areas vary dramatically in physical size, in an attempt to mimic the effects of real life geography, which does mean that tokens can get very crowded in some locations.

To get more tokens on the board (you start with one in your home area) there is population expansion: at the start of each round, you add tokens to locations where you already have tokens, which represent your population (though they represent your economy too, as we'll get to later). You can move each token by one space on the board during the movement phase. Then later in the round, any locations with more tokens in than the location's population limit (as marked on the map) loses the additional tokens.

So far, so straightforward. There are boats too, which can be important, but I don't think I need to go into them for the line of discussion I am on here. The area movement and population limits thing is simple, easy to explain, and quick to do in practice. 

Conflict, then, and this is another element that is shockingly straightforward. Different players can coexist in an area, but if the total number of tokens in an area is greater than the population limit, then tokens get removed, one at a time, starting with the player with the fewest tokens, and continues until the population limit is met. In principle, players can coexist all over the board without much in the way of conflict, but in practice, this doesn't happen much due to the drive towards cities...

Cities are quite literally essential for progress in the game - you need an ever increasing number of cities to move along the aforementioned Archaeological Succession Track, and cities provide you with trade cards which provide the currency to acquire civilization cards, which provide helpful advantages to your people as well as forming part of the final victory conditions - but I'll leave discussing all that for a later date.

If you gather either 12 or 6 tokens in a location (the number depends on which location you are in), you can remove them and replace them with a city token, thus getting tokens back into your supply, which brings us to one of the really clever and subtle parts of the game which feels like it belongs in a far more modern Eurogame: the tax phase, which occurs at the start of each round, before population expansion, once cities are in play.

When not on the board, you store your tokens on a player mat that has two areas: treasury and stock. For the most part, tokens move between the board and the stock area. During the tax phase, you must move two tokens from stock to treasury. If you are unable to do this, your "untaxed" cities revolt and get taken over by another player, which is a pretty brutal punishment for miscalculating, but I don't remembering it happening often. 

A player mat and a bunch of tokens, cities and ships.

These treasury tokens can then be used towards purchasing civilization cards or for building ships, in which case they go back to stock, and as the game develops you will need to make sure this happens, in case you become rich but unable to collect taxes. This does sometimes lead to the weird phenomenon of players cycling their tokens by scrapping and rebuilding ships, which I think is a kink in what I think is an otherwise smooth and awesome mechanism. I think that if I made use of this system in a game, I would want to make the treasury tokens more generally useful than they are.

Anyway, that brings us pretty much full circle on a round, other than the little, clunky matter of the census phase, which involves counting up tokens on the board in order to determine who goes first in the movement phase. This makes sense (it means smaller nations can react to the movements of their larger neighbours) but a few minutes of everyone simultaneously counting tokens on the board is not much of a good time. 

The stuff I have discussed so far is actually pretty much all you need to know for the first couple of rounds or so (I absolutely love that!), but once cities come into play you get those trade cards, which opens up the rest of the game and most of the complicated stuff, which I'll discuss another time, as and when I have the spoons.

So far I've only really been thinking about the game from a mechanical point of view, but of course, its theme, and the way the theme is expressed through mechanisms, is a whole other kettle of fish that I might get into later, but if you are interested, Georgios Panagiotidis wrote an interesting critique of the game a few years ago, picking up on a load of stuff, both thematic and mechanical, that he found jarring.

Until next time...

Sen's Lens

You may have come across Sen-Foong Lim, an experienced game designer with an impressive portfolio, and part of the Ludology and Meeple Syrup teams, as well as plenty of other cool things he has done. Well, he recently shared an image titled, "Your Board Game Critique. Things I'd probably tell you if I had playtested your game", I believe initially on Facebook, but it soon started getting passed around on Twixxer, Bluesky, and I assume other bits of social media too. I gather there was a bit of pushback due to the slightly blunt language, but I was instantly taken by the truth of the document. I have heard most of the points Sen makes aimed at my own designs over the years, as well as at other people's games.

A day or two later, Sen released an updated version with slightly softened and also tightened up language, but making the same points, and I've added this version below.

I first saw the list just before a planned chat with Alex, who I am working with on The Artifact, a game project that I need to blog about again soon (though this post kinda counts). We're working through some structural ideas at the moment and trying to figure out if we are on the right path, and Sen's points proved to be a really useful starting point for discussion. We went through the list, point by point, and had a discussion about whether that criticism applied to our project. 

So, is there too much going on? Is anything detracting from the core experience? Maybe - we have a couple of elements that are currently a bit extraneous, but overall we think the game is about the level of intricacy we want.

Is the audience ill-defined? We have to admit that we're basically making a game that we'd like to play together rather than having a strongly defined target, which probably isn't great for when we get around to pitching the game.

Would the game be painful to manufacture? We don't think so - despite having been developed mostly in virtual form, it is manufacturable with a pretty standard number of cards, a few punchboard sheets for tiles, and not-that-many additional tokens (maybe wooden, maybe punchboard), plus a board, so while it won't be a budget game, it shouldn't be a problem.

...and so on. We got to identify a few things that need further thought, and had some good discussion  about some other areas that should help us move forward. We've both worked on assorted games before, and this game has been through a good few playtesting loops, so we were pretty sure we wouldn't be too far off the mark here, but it's interesting how revealing it can be to just work through some of these basic points.

If you're working on a game yourself, I'd really recommend having a look and asking yourself to answer honestly to each point: does this apply to my game?

 

How much wrath is too much wrath?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Preparing For That Dungeon

I have thought about a bunch of things, read through the basic rules of another game, D100 Dungeon (hat tip to Andy J for the recommendation), and written a few more bits into my working document, but not made a huge amount of progress in the last month. I'll use this post to discuss some of the decisions I have made so far, and muse about a few of the other bits that are up in the air...

One of the key things I have noted from the games I have looked at in the solo dungeon crawl space is that they are almost exclusively pretty highly "statted" games with very much a D&D vibe to them with skills, attributes, equipment lists, classes, levels, and so on. This is not a bad thing - dungeon crawling as a genre feels to me like it should be a tactical challenge as much as anything, so rules for a game of this type will, of course, support this play style.

Let's not do that.

Stepping back a little, one of my favourite roleplaying systems is in Over The Edge by Jonathan Tweet (I'm basing this off the 1st edition). I admit that, while I really enjoyed reading the book, I have never played the actual game in its original setting. I have, however, used its core system in other settings (it worked well for me for a 7th Sea one-shot, for instance) and love its simplicity and flexibility. The basic concept is that you have four traits: one is a central trait (often a profession, trade, or similar), two are side traits (hobbies, interests, side-hustles, etc), and one is a flaw. The positive traits give you dice to roll to achieve things that fit within the scope of that trait (fuzzy definitions to be decided by the games master) and the flaw causes dice to be deducted from your rolls when it applies. 

I'm not proposing to do this myself, but using this as partial inspiration, I think character creation will effectively be to simply define some broadly applicable strengths. I may add in some sort of flaw later if it seems appropriate. The OTE system relies on agreement between the game moderator (as OTE expands GM) and the player on the interpretation of whether a trait or flaw is applicable at any given time. That won't work in a solo game without either heaps of lookup tables or challenges in the game being defined with a set of applicable traits. I'm reckoning on focusing on the journaling aspect of my game, so the important thing is more to provide interesting writing prompts rather than a tactical game, so it'll be mostly left to the player to decide. If you want to cheat, fine, this sort of game isn't really about winning or losing, it's more about having an engaging experience and creating an interesting story.

The idea is that you play a party of two characters: a renowned hero with mighty skills, and you, their sidekick, who can help out from time to time, and who will record the tale of the adventure for posterity.

How does this all fit together to actually make a game? To be honest, I'm not entirely sure yet, but what I am working on as a core mechanism is that an encounter in the dungeon has a description, including a suggestion of what sort of challenge it is...

"You enter a cavern with a pool of water in the middle and two other exits. There are a whole buttload of goblins, counting their saucepans. There is a boss goblin who looks angry. This could turn violent."

I mean, not Shakespeare (or even Gygax), and I need a way to generate that, but this is a problem for future me, who I'm sure can handle it.

As the player, you decide how you will use the skills and traits (as well as equipment, magic items, etc.) to deal with the situation. I currently think that each of the things you can bring into play may have a number of times you can use them (boxes to tick off), and each thing you use adds +1 to a die roll to resolve the encounter. The modified roll is checked against a results table (with other factors being taken into account) and you get an outcome from that which indicates how successful your efforts have been, so then it's down to you to turn that into some narrative in your journal. If things don't go perfectly, you are likely to lose some luck or health (two scores tracked on your character sheet), and maybe be forced to retreat or something.

I'm currently in the process of writing up the character generation element, which effectively takes place at the tavern in the village while getting the call to action. Then the idea is to have a "travel to the dungeon" section, where there can be some sort of encounter that could set the tone for the rest of the game. Finding a way to link encounters together thematically will be an interesting challenge; to a large extent this can be left to the player's narrative, but there should be some help or encouragement for this from the game mechanisms, maybe something like gaining a checkbox somewhere if you make a link between certain things.

One step at a time though. My aim for the next few weeks is to get the character generation and travel sections into a first draft form, so it can be played to that point. Oh, and also work on some other projects along the way.

Three Books I Found Useful

There's a lovely chap called Adam Porter, who is a talented game designer, and who also has a YouTube channel called "Adam in Wales", where he mostly talks about game design from a number of different angles. This week he released a video entitled "10 Books Every Board Game Designer Should Read"  and, as always, it's a great bit of viewing. Please do go and watch it, and if you like that, watch more of his stuff - he has a lot of interesting insights.

Anyway, I have read more than half of Adam's recommendations (and agree with them), and the others have gone onto my wish list, but this made me think of what books I would recommend for a game designer. I'm not going to try to come up with a thorough survey of the field, but here are three books which I would suggest for a reading list.

Adam recommends a book by Austin Kleon, "Steal Like an Artist", and I would absolutely support that, but to be honest, I think I got more out of another of Kleon's books, "Show Your Work", which is full of more great advice, but is more focused on the idea that sharing your creative process and your output is a great way of building community, getting feedback, and generally developing as a creator. It was one of the driving forces behind me blogging about what I am doing in game design.

"The Art of Game Design: A Book of Lenses" by Jesse Schell is one of those books that gets recommended a lot - or did when I was first looking for reading material a few years back - and for very good reason. While coming from a mostly video game angle, almost all of it is still relevant to tabletop games as well, and the book effectively provides a set of questions for you to ask yourself about a game you are working on, in the hope that thinking about the game through the lens of some of these questions might cast light on what is going on (or wrong) with the game. There is also an adjunct set of cards (both physically and a digital version in the form of a mobile app) that distils the key points of the book into a form that you can basically just carry around and fiddle with.

And finally, what is probably my favourite book about game design: "Uncertainty in Games" by Greg Costikyan. This is a small book, focusing on one thing, but which pretty much blew my mind when I first read it. Basically, a game needs uncertainty, but that uncertainty can come from many different sources from whether you will roll a six to if you can flick that tiddlywink into the pot, or if that other player has a plan that you hadn't thought of. The book catalogues a load of sources of uncertainty and discusses how they are (or can be) used in a game.

So that's my three for today. There are a load more I could suggest, but I have to stop somewhere. If there is anything else you can recommend, please do share in the comments. I'm always on the look out for good new stuff.