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.

Alone in the Dungeon

I've been tinkering around with yet another project, and one that is very different from others that I have worked on in recent years, and is one that I don't expect to ever pitch to a publisher, or even try to monetise. This is just something to play with and use as a learning experience. 

But I'll build in to that... First a little background...

As a teenager I played quite a lot of roleplaying games; mostly Middle-earth Role Playing, D&D, or AD&D (yes, at that time, Dungeons and Dragons and Advanced Dungeons and Dragons were separate products), but a few others here and there, including homebrews. One of the things that really interested me at that time was a few pages in the AD&D (1st edition) Dungeon Masters Guide: the first few appendices were for generating random dungeons, wilderness areas, monster encounters, etc., enabling you to play a D&D-based adventure game as a solo. It was kinda like a pencil-and-paper "Roguelike" game, and it was a fun thing to do when not playing "properly". 

There were also choose-your-own-adventure style books, like the Fighting Fantasy line, for your solo adventuring needs, if that fit your requirements.

Anyway, time passed and my engagement with roleplaying games varied. I've relatively recently been catching up a bit with developments (and playing a little), and one of the things that has been growing in popularity is "journaling RPGs". Whereas my old solo AD&D games involved drawing a map and then rolling dice for fights against monsters, and then rolling for loot acquired, this newer style is more about randomly generating events and writing prompts, which allow you to write a story about your character's exploits and develop their life through a series of journal entries. This was absolutely possible to do with the AD&D rules, but it didn't occur to me at the time, and the system was way more complicated that is necessary to provide the appropriate prompts.

A few solo dungeon delves and journaling RPGs: Notequest, 
Zimo's Getting Up, Apothecaria, 2D6 Dungeon, and Four Against Darkness

I was spurred into looking into this sort of gaming partly by my wife discovering them over the last couple of years or so, and then a bit more by a friend creating one about being a graffiti artist earlier this year, and as a result I developed an urge to try making a dungeon crawl game that leans into the journaling RPG form a bit more. 

I've done a little looking around for comparable games, and posted about the idea on Mastodon (my main is on tabletop.social, if you want to come and say hello) and got a few suggestions for things to look at too. Most of the clearly dungeon crawl games that I have seen (e.g. Notequest and Four Against Darkness) are effectively smoother versions of the solo AD&D: draw maps, battle monsters, acquire loot. There are some others (of those I have seen, Colostle is probably closest) that do something dungeon-crawl-adjacent, while being a proper journaling game. I've seen a few other games that are more or less adjacent to what I want to do, but nothing quite in the same zone - not that that would be a problem anyway. My searching hasn't been exhaustive though, so if you know of something that sounds a bit similar, please do let me know in the comments (or elsewhere).

So what am I planning and what have I done so far?

This is very much a background/side project for me to tinker with when I have any inspiration, and it is currently a document with some section headings and I am starting to fill in text and tables for randomly generating stuff. I've not got enough to actually play with yet, but there are odd bits and pieces that I'll start connecting up soon.

I'm not trying to come up with a flexible game system or a full campaign yet, instead creating a single adventure to play through, albeit one with some variation in how it can play out. The idea is that you, the player, are the companion and chronicler of a great protagonist or hero (think Watson to Holmes, or Ukko to Sláine), and you arrive together in a village and get sent to a nearby dungeon to deal with the evil wizard. You journey to the dungeon, work your way through a few levels of challenges, and eventually confront the wizard to, hopefully, save the day. All this time, you are creating a map to show the path of your adventure, and keeping a journal to record the daring deeds done in the dungeon. If the hero dies, maybe you escape to recount the tale; if you die, maybe the hero finishes the journal on your behalf.

I was originally planning to have a relatively lightweight combat/encounter system that would allow for some detail in how things work out, but on reflection I have decided to abstract out a load more, so that effectively there is a single die roll, applied to the situation, after which the hero and companion can apply special abilities to improve the result. This should effectively result in an outcome that could either simply be written down (if you aren't wanting to do creative writing), or could be used as a writing prompt. So, an example outcome could be: "3 orcs attack in the passageway. The hero uses her great axe to fight them but it looks like she will be seriously injured and have to retreat. The companion uses his stealth to help, and the hero uses her acrobatics skills. As a result, the orcs are slain and the hero only takes a minor wound." It's not exactly Shakespeare, but it's a basis to build a journal entry around, detailing how those skills are used to affect the outcome.

Remember how I said that I'm planning some variation in how the game plays out? One aspect of this is that you record certain events and encounters in an area of your character sheet, and some of these things affect the likelihood of other things happening. So, for instance, if you start encountering undead creatures, that increases the chances of meeting more undead, and makes it more likely that the wizard at the end is a necromancer or some sort of undead spellcaster. Again, this isn't crazy clever stuff, but it would be nice if things link together in some sort of a thematic way as it all plays out.

There will be a load of tables to roll dice against. This is a thing I used to love making, so we'll see if I still have the chops to do this sort of thing. In the meantime, I figure that at least writing a bit of this stuff down should solidify some of it in my head. 

Challenge to self: make some more progress and make another post on the subject next month.

Backs to Fronts

I have a prototype production pipeline (inadvertent but pleasing - to me - alliteration there) that I use for a lot of projects, that involves data in a Google sheet, pulled in to a nanDECK script which sets up cards or tiles, and that script then outputs a PNG file with a grid of card images that I can import into Screentop for a digital prototype, as well as a PDF that I can print out for physical components. 

Some of the games I make have multiple decks (in this context I'm meaning groups of cards with a common back), which I generally build with the same script, and the sizes of those decks can change from time to time. In the case of Sympolis (formerly the City State Co-op Game), there is currently a set of eight starter cards, and two other decks with 20-odd cards each, the relative sizes of these two decks varying as I tweak the card sets.

When making the physical versions of the cards, I just put the cards into colour-backed sleeves according to which deck they are meant to be in. My data spreadsheet has a column in it for which deck a card belongs in and I use that information to adjust the front (e.g. using a coloured border or shaded background) to make it easy to spot how to divide the cards. 

In the case of my virtual prototypes on Screentop, I need to tweak a field for each card to indicate which of a set of possible card backs is required. I can do bulk updates, so this task isn't too onerous, but it is still a little fiddly and can lead to mistakes.

After doing this for, like, a couple of years, it occurred to me that I could get nanDECK to do this fiddly bit for me.

The way nanDECK generates cards is, if left to its own devices, it just reads through the data file and generates that many cards, which seems logical to me. If, however, you reference a card in the script beyond that "natural" range of cards, it loops back of the data. So, for instance, if you have data for 10 cards, but you ask nanDECK to output an image file of 20, the system will loop through the data twice.

With that in mind, and the fact that I have been working with sheets of 55 cards (generally ignoring the last slot in order to have a convenient 54 cards for printing, which is 6 sheets of 9), I had a plan. 

Bits of nanDECK code.
The first bit defines stuff that is useful later.
The second bit creates card backs and creates image files.

I defined two ranges, cards 1 to 55, and cards 56 to 110. Then for cards in the first range I defined layouts for the card faces, and for cards in the second range we have a distinctive coloured background and a character printed in the middle to reinforce the information, based on the contents of the "[Deck]" variable, which comes from a column in the spreadsheet. It's not a sexy, final version, but it is neat and clear enough for prototype usage. Then I used DISPLAY directives in my script to output the two files.

Not good enough resolution for you to really see what's going on,
but hopefully you'll get the gist

Then, all that I needed to do was upload the two image files to Screentop as assets and tell the card components to use the same index number for front and back and take their image from the correct asset. As long as I always update the two assets at the same time, the card fronts and backs will always stay in sync.

Of course, when all that is uploaded I still need to sort the cards into the correct files, but that's straightforward enough, especially as I have some "deck holder" containers to help with stuff like that - but that is another story.

Cities Together at the Expo

So that was UK Games Expo 2023, and another great weekend it was. I worked at the Playtest Zone for most of my time there (at least during the days, anyway), met fine people new and old (in relationship terms, at least!), talked a lot, playtested my City State Co-op Game, ate mostly overpriced burgers and pasties, bought a bit of stuff, and played very few games. I'll talk about my playtest first and then move on to some more about other things, though still mostly about the playtesting.

While I was spending most of my time helping other folk at the Playtest Zone, I also had a 90 minute slot booked for testing one of my own games. As it turned out I didn't need to wait for players as I had been talking to a few people about the game through the day, and a couple of them turned up specifically to play, each bringingong a friend to make up a perfect table of four.

As an aside, my opening line when asked about the game was, "It's a cooperative game where you have to attack each other", which is probably the strongest hook I have ever had for a prototype, as it always resulted in some sort of a "tell me more" response. Well worth remembering.

A few turns into the game, showing cities developing very differently.

I wasn't sure about how long the game would run, but guessed about 45 minutes, and it actually came in at almost exactly 50 minutes, which was pretty good, and the players commented that it didn't feel that long, which is definitely a very good sign. I think I took over 10 minutes to teach the game though, which I feel was probably a bit long. I think this was partly because I am not yet used to explaining the game, but may also be a sign that the game is a bit fiddly.

The dynamic was interesting. One of the players quickly took to being a sort of MC, stepping through the turn order and starting discussion. This could have turned into an "alpha player" problem (where one player effectively dominates a cooperative game), but there was definitely discussion with input from all players, and when we talked about this afterwards, nobody seemed to feel that they were being railroaded or anything. I think that this game could easily suffer from having a dominant player, so I will need to consider whether I will address this or not.

My biggest problem with this game is now, I think, trying to get a meaningfully "difficulty arc", as you might call it. In this play through, the players had a fairly gentle start, then in the mid-game they felt that they were under serious pressure, before the last round or so eased off and allowed them to cruise home. From my position of just observing, and knowing what was likely to happen, I could see that the mid-game pressure was illusory, but it was amazing to watch (they felt that they were about to be punished for earlier decisions), and something I would really like to see happening in the game. Basically, what I would like to see is a tense ending, with a few points of tension, with partial release, through the rest of the game. 

We had a good discussion after the game, and I think that one of the biggest points to address is that it turned out to be way too easy to defend against each others' attacks, and the most obvious fix for that is to greatly limit - or maybe even remove - the supply of buildable defences. Without the city wall cards, there would be a lot more pressure and more difficult decisions to make. I might try that on its own (with tweaks to rebalance the decks to compensate) and see how that goes. There was also a turn-by-turn reveal of cards from an additional "wrath deck", which kinda worked, but was an extra thing that needed to remember an additional (simple) action each round, which was easy to forget, and I have a couple of thoughts about how to address this, though I may leave that until later.

After playing, the players asked for a reminder of what the game is called. I told them my working title, which of course is not exactly evocative of its theme. One of the players I had is actually a Greek speaker, and as the setting of the game is currently based on a mythical view of classical Greece, she had a suggestion for a title that we all liked.

As a result, the City State Co-op Game now has the new working title of "Sympolis", which apparently can translate as "cities together", which seems a great option. Thank you so much, Vilma!

Anyway, that was part of my Saturday afternoon; there was a lot more to the weekend.

I arrived on Thursday afternoon to help with the setup of the Playtest Zone. This is actually pretty light work, the hardest bit being deciding how to lay out the tables and chairs, and the rest being largely putting the trademark red cloths on the tables and sorting out the various bits of stationery we have. Other than that it's a good opportunity to say hello to a load of people - although many of them are busy setting up their own stands.

The rest of the days were spent working, mostly welcoming designers and players and trying to put them together, alongside a core team (five of us in total) plus a small army of volunteers turning up to do shorter shifts, and an extra who came to help whenever he had spare time. There were a few quiet spells (largely Sunday lunchtime, but a few other periods too) where we had to work to bring in potential players, but a lot of the time we were finding people just coming up and asking to play something, and far too often there was no space at that point. It's a shame when we can't seat people who are keen to playtest, but I guess it's a good problem to have.

Its-a me, standing by the Playtest Zone.

The way things work is that most of the tables are booked in advance for a period of either 3 hours or 90 minutes, but there are a few tables available to be booked on the day for designers who haven't been able to sort things out beforehand. It turned out that demand for tables greatly outstripped availability. A note for anyone who is considering joining us for playtesting at future events: seriously, book in advance if you can.

On the Friday evening was the designer-publisher networking event. This is an event that typically involves having a drink or two with fellow designers (my experience is minimum publisher attendance) and listening to a couple of talks, generally one from the event sponsor (Panda Game Manufacturing this year) and one from some other industry insider (past years have included luminaries like Alex Yeager and James Wallis). This year it was straight to the drinks and no talks. There was a point when someone was speaking over the PA, but the noise of conversation was so loud that most people didn't even seem to notice, let alone hear what was being said.

Other than that, my evenings were largely catching up with people and very little actual game playing. I can play games at other events, I guess. I managed to spend my breaks looking around the trade halls, and even managed to get out to watch the vikings telling a story, complete with illustrative acting, throwing of water at each other, and bad jokes.

For all the lack of game playing, and the fact that I always leave with aching feet and a befuddled brain, UK Games Expo is one of the big highlights of my year. Attendance at this year's event comfortably surpassed the biggest pre-Covid year (and Saturday seemed ridiculously busy), and I heard really happy noises from a lot of small traders. I'm already looking forward to the next one.