Drafty Meeples

As you probably know, I go to London most months for a Playtest UK meetup, but there is also a monthly session in my nearest large town, Oxford. The events being on Sunday evenings tends to make them less convenient for me, but I've made a few of these over the last couple of years, and this week I managed another.

Unfortunately this session had only four of us in attendance, but with a little negotiation and planning, all of us managed to get one of our games played -- though one was a longer game and we only managed a partial run of that.

I forgot to take a photo of my game in play, so here's a pic of a 4-player setup at home.

I had a two-player game of Drafty Valley (which will need a new name at some time), which was enough to give a reasonable test of the changes I made since its last trip to the table.  The game ran for about 45 minutes, starting with a very short explanation of just the rules active with the initial setup, and learning the rest as they came up, which is my planned teaching method for the game. The first few rounds were a bit slow as the new actions cycled through, but things sped up a lot and after the first time through the action deck the game was flying along nicely.  We even ended up with a nice, fairly tense ending, which was pleasing -- though probably more by luck than design.

Overall the changes I made seem to have moved the game in a positive direction, but the game start is still a little slow in terms of getting things on the board. This was actually feedback I got from the previous playtest, but I didn't really address this time. I think that next time I might have everyone starting with a control cube on the board, which should accelerate the early stages quite a lot.  Other than that, I'm planning to run at least my next playtest with the same prototype and hopefully see how it looks with more than two players.

Incidentally, the paper-thin theme on the game and the general "get resources and swap them for money or more resource production" makes the game perilously close to the Eurogame cliché of "trading in the Mediterranean", but at this stage of my game design career, maybe that's not necessarily a bad thing. I've been explaining that the conceit of the game is that players are businessfolk in a corner of the kingdom, getting contracts from outside to develop the land in various ways, and that the objective is to fulfill certain key contracts and make as much money as you can while you do so, and that seems to fit just fine right now. Maybe I'll be able to come up with a more interesting thematic justification for everything later, but for now I'll just let it ride.

Other than Drafty Valley, I got to play a couple of others... One was ostensibly about investment and market manipulation, but is actually focused on negotiation, and does that very well once you get into it, and shows great potential, even though it's not a style of game I get on well with.  The other was an ambitious cooperative game about defending a village against ravaging monsters; the concept is great and the designer has made some absolutely charming character illustrations, but at the moment the gameplay seems a bit fiddly compared to what the game seems to want to be; if the designer can find his way through the complexities, this could end up being really great fun.

24 Hours of Eggs

The requirement for the April 24 hour game design contest is "Egg", and I had an idea bouncing around in my head. The problem here is that I really wanted to test the idea as early into my 24 hour period as I could, which made scheduling look challenging, given a load of other things in our lives.  Eventually, though, we hit a week where I was able to go to a Thursday evening gaming session where I didn't mind talking the others into playing a prototype for 10 minutes or so, followed by a (mostly) free Friday which I could use to finish things off and submit my entry.

The idea was not very ambitious -- a nine card microgame with a little bluffing and reading, and a lot of luck -- but not every game has to be particularly clever or complex. It's a kind of egg-based Russan roulette.  What happens is that everyone has (and looks at the face of) a card representing an egg, which can be either raw, boiled, or rotten, and there is an additional, unknown, card on the table. Each player announces what is on their card (lying is allowed) and places it in the middle of the table. After a short countdown, each player grabs a card and slaps it on their own head. The aim is to avoid getting covered with raw -- or worse, rotten -- eggs.

Blank cards plus Sharpies... a useful part of the toolkit, quickly resulting in a serviceable prototype.

By the time we got to testing the game, I had decided that one player announces what is on their card, and then everyone else makes the same announcement, regardless of what they actually have. This ensures that on most rounds, some players are lying, and some are telling the truth, and also takes a certain amount of pressure away from players who are uncomfortable with lying in games.

The result of the initial test game was sufficiently encouraging that, with a couple of minor tweaks, I could progress to writing up full rules and making a printable set of cards.  A post-play discussion came up with a few potential names for the game: I ended up settling on "The Yolk's on You".

Keep It Simple, Stupid. It's nice to be able to make really simple components.

The Friday was spent largely trying to make decent looking cards and finding graphics to use on them (this time the art is public domain stuff from Pixabay, with one of the images tweaked by me), as well as writing up the rules and wondering if I should try to fill them with hilarious egg puns. I decided that I rarely come across well when I try to be funny, but there may well have been one or two places in the text where I cracked.

So, that's my twelfth entry to the 24 hour contest submitted, and the first for this year. Hopefully I'll get at least a couple more done before the year is up.  In case you are interested, the game entry post is here, and includes links to the rules and print & play card files.

It's Drafty in Victoria

After missing last month's playtesting meetup in London, I actually made it this weekend, and on a whim decided to take my hand-made and still unplayed (other than some solo plays) prototype of "Drafty Valley".  I was chatting with one of the other designers before the session started, and we agreed that the type of feedback gained from other designers at this sort of meetup can often be amazingly useful in the earlier stages of a design, but might be less productive later on. That's been my experience anyway.

I was selected for the first round of games, and quickly had three volunteers to join me for a four-player game. Pleasingly, they were all willing to go with my preferred approach of, "We'll just explain each new thing as it turns up," and the game started in what must be a record time.

A few rounds in and there haven't been any builds yet. Hmm...

I won't go into a play-by-play or anything, but will report that many aspects of the game were just horrible. For instance:

• Several actions just didn't take place because people couldn't capitalise on the selected cards.
• The players producing grain and sheep found that there was precious little to do with their resources.
• It took ages before we were really interacting on the board, and even then a couple of the players were still pretty isolated.
• The scoring cards seemed pretty random and poorly thought through (well, there may have been a reason for that...!) and not knowing what was on them at the start of the game left players with no real direction for the first couple of rounds. 
• The benefits of buying and selling on the market were massively disproportionate compared with the other things you could do.

And so on.

However, I knew that the game was shonky when I set out.  What I was really wanting to test was the overall concept of mashing together several variants on a drafting mechanic (where players pick some sort of a resource from a pool, generally taking turns to do so), and with the activities on each turn also based on drafting from a pool of options. How did that general idea work?

Well, towards the end of the session, one of the players said something along the lines of, "I don't know why we're doing what we're doing, but what we're doing is fun." He, and the others, had a lot of criticisms about the details of the game (as above), but the consensus seemed to be that the overall shape of the game (if not its current dynamic arc) has potential.  I am more than happy to take this as a result for a playtest.

So I need to build a new prototype which fits together a little more coherently, is not as slack at the beginning, is less likely to leave players unable to act on their turn, and gives everyone a bit more of a clue about what to do early on. All this while avoiding adding extra elements as, while I have a number of ideas for more features that I would love to add, there is probably enough here already to make a decent game once it is all knocked into shape. It would be great if I could get this one to play in, say, 30 to 40 minutes, but we'll see how we go.

Aside from my own game, I got to play two prototypes from other people. One was a midweight Euro with some really interesting challenges; it was a bit fiddly, and the various subgames weren't quite in sync with each other, but I really enjoyed playing it and can't wait to see it finished. The other game was a really neat and colourful abstract game that was teetering between being a crunchy puzzle-strategy game and a semi-mass-market family game, which I also very much enjoyed playing.

Building in the Valley

Following on from my post about my "drafting" game a couple of weeks back, I have spent a little more time on the game and am getting closer to a complete game.  There's still a little way to go, but it's coming along.

This game has been developing along an interesting path. What I did was to start with enough components to just about play a first round with three players, and solo-played all three positions myself, adding extra components when I needed them.  Unusually, by my recent standards, I was working by drawing on bits of card, something I usually only do for initial experiments with small parts of a possible game.

The big, green pawn, by the way, is a first player token.

This is a method that works pretty well with a supply of index cards, sharpies, scissors and a paper trimmer, and assorted "stock" components. The game starts with five actions available (claim location, produce goods, sell goods, buy goods, and select score cards), so the game can pretty much be started with knowledge of what those actions do, and more introduced as they are added from the deck, including the opportunity to build locations and roads, and expand your control from claimed locations.  Some of these required additional components to be added, and I was making new action cards when I thought of them.

At this point, the only thing really preventing the game being playable all the way through is a lack of score cards (I just fluffed through that when it came up), and I'll need to throw something together there before I can get much further.  The idea is that when the "select score cards" action is chosen, everyone gets to select a single score card which gives them a scoring condition to apply at the end of the game. Each player will acquire maybe three of these through the game, and not all of them will be in play in any given game. The idea is that your strategy is shaped by the score cards selected as the game progresses.

One major decision (which is reversible if I don't like the outcome, so it's not really a big deal) is whether victory is based on how much money you have at the end of the game (in which case the score cards give you bonuses to your earnings), there is a victory point tally, or something else is used. Victory points seems natural to me as a gamer, but they can be unintuitive and seem very arbitrary, suggesting that it is usually better to have some other measure of success.  I'll probably plump for "have the most cash" as the victory condition to start with.

Anyway, that's where we are at right now. Once I have an initial set of score cards I'll start pushing the game at playtesters, starting with some who I know are OK with incomplete and terrible games.

Simulating War, Casino-Style

One of the biggest challenges for me in game design is getting enough playtesting done. I get to playtesting meetups with other designers from time to time, and have a couple of groups of great people who help me out when they can, but I just can't get as much playtest time as I would like.  So I need to make the most of the playtesters I do have.

Methods to increase the effectiveness of playtesting include solo testing before involving other players, having several games on the go so there is more likely to be a game that can make use of whatever playtesters I have available, getting cleverer at observing tests and questioning players, and using maths or computer simulations to analyse the games and focus aspects of games from a statistical point of view.

Most of the games I have worked on to date haven't really lent themselves to maths and simulation, but my wargame, currently codenamed Craghold, absolutely does.  And, more to the point, early playtests have revealed a question that I need answered.  Combat in the game involves each player rolling a bunch of six-sided dice depending on the situation of their unit in the engagement, and counting the number of dice that roll at least a set target number.  Assuming the general mechanism is OK, then what is the best target number to use to get the sort of combat results I want to see?

A chart of some of my results. I'll explain a bit...

I'm not a great mathematician, so I don't feel confident about doing an analysis of the game by manipulating the various probabilities. I'm not a great computer programmer either, but I know enough to be able to code up a quick simulation of any given battle: the number of dice used by each of two players, and the target number they are rolling against.  I could then, in a matter of seconds, choose the relative unit strengths and run a thousand simulations for each possible target number. I'm not considering a target of 1, because in that case the more powerful force always wins.  A little bit of coding to produce numbers which I fed into a spreadsheet meant that I quickly had charts representing the outcomes of several different situations.

The resolution of an engagement is basically to find the difference between the number of "hits" scored by each side: whoever has the most wins, and the loser is penalised according to the size of the difference (being driven back, "shaken", or destroyed).  On the charts, the bars of each colour indicate the number of times a result occurred for the target number matching that colour. Positive numbers on the horizontal axis mean that player A wins, while negative numbers mean player B is victorious.

Fewer dice in the combat tightens the results up.

Armed with these charts I was able to use an entirely unscientific method of deciding which set of bars looked most like what I wanted the results to be.  For instance, with a target number of 2, the results went overwhelmingly in favour of the stronger force, and with more dice the results would end in absolute carnage.  This is actually probably a good choice for a game like this, rewarding the player who can bring large masses of force to bear where it counts, but I want the game to be a bit looser and lighter than a true strategy game.  On the other hand, a target of 6 makes engagements extremely unpredictable, but generally only marginal outcomes occur, which seems both boring and frustrating.

I'm planning on going with a target number of 3 as it gives the sort of profile I was looking for.  We shall see how this works out in actual playtesting when I next get a chance...