IDLEcon 2: Clockwise Boogaloo

Back in the dark days of December, the lovely Michael Fox, game designer, Twitch streamer and generally Good Guy, hosted a two day game jam called IDLEcon, during which time a bunch of us created something-and-write games and then played them live with participation of the audience of his stream. I collaborated with Chris O'Regan to make a game we called The Village on the River, which we have continued to work on since.

Back in the not-so-dark days of late June, Michael hosted a follow-up event, IDLEcon 2.

This time the format was different. While the original took place in the "dead time" between Christmas and new year, with most of us in some form of a lockdown, the second run acknowledged that most of us had work or other commitments, so the idea was to spend one weekend creating games, and the next weekend playing them; the intervening time allowed for more development or design, or just getting on with your life. The challenge this time was to make a game that could be played on-stream, with Michael, as host, playing with or against the people in the chat. 

Once again, the dual focus of the event was Michael's Twitch stream and his Discord server, where folk could chat, discuss ideas, team up, and so on.  I put a half-formed idea of a game into a channel and ended up talking with Bez (she of Yogi fame, as well as much else), throwing together a very rough virtual prototype (actually using a shared Google Drawing to work as board and counters) and spending the afternoon experimenting, testing and iterating until we felt we had something that was decent enough fun but needed "proper" playtesting.  I didn't have much available time over the following week, so we pretty much left it there, other than making sure that there was a usable virtual prototype on Screentop.gg and the rules were written up.

Michael attempts to avoid the robots on stream.

The basics of the game are that one player (intended to be the host of the stream) has the task of moving their character from one corner of a gridded board to the opposite corner. This is complicated by the five robots which move around pre-set routes, the distance each of them moves being tied to the results of a poll that is run for viewers to vote on. We have some general ideas about how this could translate to a tabletop version, and may work on that later, but for now it was just a game aimed at the specific challenge of the day.

The following weekend was set aside for playing the games on stream. I, however, was camping in a field, half way across the country so my daughter could take part in a folk music related activity, so couldn't really take part properly. I did get good enough mobile signal to be able to watch a bit of the stream live, and then caught up on the rest using Twitch's video-on-demand facility a couple of days later, though Bez was able to take part on the day.

So the game actually worked. There were a good few people taking part in the chat submitting their votes, so the polls actually looked like they had meaningful results, and there were points when the voters were trying to make sure that certain results occurred. It got interesting when Michael observed that the rules did not prohibit him from taking part in the votes, which mean that in some circumstances, he was able to force, or prevent, certain results.

It turns out that the way polls are implemented in Twitch, the tallies are shown while voting is taking place, which made it both easier for the chatters to know what was going on, and for Michael to throw his spanner into the works. This, combined with the predictability of the robot movements made things a little less than ideal, particularly in the second play of the game -- though the fact that everyone elected to play a second time was hugely gratifying in itself. There was a lot of discussion though about ways to introduce more chaos and unpredictability, as well as generally strengthening the game, so I think this went really well for a first "proper" play.

We've not returned to this design in the weeks since, but I think it could be interesting to have another look at it some time and see what we can make of it. Michael suggested that it could be good as a mass-play convention game, with people as playing pieces and some form of crowd voting, and that sounds like it could be great if we found the right people to partner with to make it happen. My thoughts are that it could be a one-versus-many tabletop game, with the "many" having cards with varying numbers of votes or moves for multiple robots, and everyone selects what they will play at the same time, hoping that they can coordinate without discussing the actual cards they have in hand.

Anyway, this was another enjoyable exercise, both from the angle of working with another game designer (a friend for years, but whom I had never created anything with) and of working with interesting restrictions and requirements. It's entirely possible that we'll never be able to make a commercial product out of this, but the creation can often be worthwhile on its own.

They Came, They Played, They Built

It has been well over a month since my collaborator, Chris O'Regan, and I set up an experimental play-by-blog playtest of our flip-and-write game, The Village on the River, and it's about time I got off my backside and wrote something about how it went.

If you remember, the game involves a series of rounds, in each of which, three cards are flipped from a deck of cards and you, as a player, get to make use of two of them in order to build your own little village, and what you build (and how you place it) gives you a score that you can compare with others when the deck has run out. We set up a blog post on Board Game Geek, which had a pre-set series of images of these card flips, each hidden behind "spoiler" tags, so you could go through, revealing one set of cards at a time, and play the game that way.

Over the next few days I received messages through various channels, including email, Facebook and Discord, though nobody actually commented on the blog post directly. Everyone sent an image of their play sheet, and quite a few folk sent comments about their experience. One person even went so far as to send a video of them playing the game, with the chatter with their partner about decisions being made. 

Eight playsheets, with a variety of approaches.

Just by way of a quick detour, I have heard a lot of people (most notably Matt Leacock, designer of Pandemic and much more) talking about having videoed remote playtesting as a really useful tool. This was my first experience of this, and I can totally see how useful this can be. If the players can relax enough to not worry about the camera, you can get so much information about what people are doing, what is causing them problems, and so on.

The Village on the River is, like a lot of random-and-write games, essentially a multiplayer solitaire; what you do does not affect other players at all, and the challenge is trying to make the best use of the random sequence of events that is available to all players. As such, while it appears ideally suited to solo play, the problem is that what constitutes a good score can vary greatly from game to game. Our observation from earlier playtests is that a score above 40 is generally very good and puts you in with a good chance of winning, but sometimes the winning score (even with competent players) is around 30. 

So, with that in mind, while you could set thresholds for winning or losing (and we may end up doing that), what you really need is other players' scores against which to compare yourself. The more other players there are (and the game can, in principle, scale infinitely), the better idea you have of how good your score is, and the better idea we, as designers, have of how the game performs. 

The eight sheets we received had scores ranging from 17 to 49, with four players in the 40's. There were a few small mistakes in scoring and at least a couple of players had misunderstood parts of the game until it was too late. There also wasn't a single approach that the higher scoring players had all found: several different strategies resulted in competitive scores.

Overall, we were very happy with how things turned out, particularly with the comments that helped us home in on the elements that were causing problems.  

Our big issue here was in communicating some of the rules, so it is easy to miss some parts or interpret them in a way that wasn't intended. This is something that was clear from some of the playsheets, and made even more so by the comments and reports that folk were kind enough to send. Now, with things like this, it might be that your graphical presentation makes some things less intuitive than you would like, the wording or organisation of the rules might not be clear enough, or the rules themselves might be the problem and you need to change to something more intuitive to the average player. It is too early for us to be sure on this, but we are working to improve the first two points initially.

Aside from this, though, there was a general sense of, "yeah, I'd play again", which is very helpful for morale. Of course, we'll have to see how that works out in practice. And I think that, based on this experiment, we'll be having another go at this format of testing pretty soon.

Doctor* Rob's Play-Along Blog

So here is something of an experiment. You may remember that I was working with the awesome Chris O'Regan on a "flip and write" game, The Village on the River, which we started at "IDLECon" at the end of last year (and I now realise I haven't posted about since). We have kept working on this since, tweaking here and twiddling there, and the game seems to work pretty well, but although we have had a couple of plays with a load of people (the game in principle can scale to any player count), it has mostly been tested with just Chris and myself. This results in a few shortcomings: firstly that things that make sense (or are fun) to us don't necessarily make sense (or fun) to everyone else, but secondly, we can't be sure that there aren't huge imbalances in play.

 A not-terribly-impressive result for me on a recent play.

When I talk about balance, by the way, I mostly mean that everything in the game can contribute to a winning strategy, and there is nothing in the game that is absolutely essential for a win. In this context, I am mostly thinking about the buildings and special characters, and I would be OK with things like not being able to win unless you have dwellings in your village, etc. In recent versions of the game it does seem that some ways of playing often result in good scores more than others, but I'm OK with that as long as nothing is either essential or useless.

Anyway, one of the strongest ways of testing for this is to just play an enormous amount of games and see if we can see patterns in the way people play. More specifically, in the case of this game, it is really helpful to see the results of big games so, for example, seeing the way a dozen people interpret and exploit the same set of cards.

Back around the IDLECon time, another collaborator, Alex Cannon, set up a test for a roll and write game he had designed by posting a series of die roll results on his website (actually doing several of these sequences), with the rolls hidden behind "folds" so that a player can click through and play the same sequence as other players, and so the scores can be meaningfully compared.

This all seems like a good solution to the problem and I have finally got around to having a try at this. Chris and I had a run through the rules and the playsheet to make sure we had a stable version to share. So it was a matter of how to set up and share the sequence.

As you may know, we have implemented our custom card deck on Screentop.gg, which allows easy iteration and sharing, including allowing any number of people to watch the card flips in progress and play along easily. I set up a play session with this virtual prototype and ran through the deck, three cards at a time, taking a screenshot of each set of cards.

One turn's worth of card flips.

The Blogger platform I post this blog on doesn't seem to have an easy way to handle the staged reveals of each turn, but it turns out that Board Game Geek's blog system includes "spoiler" tags which are pretty much perfect for the purpose. And so, I present to you: The Village on the River playtest play-along #1.

As I said at the start this is an experiment and it relies on goodwill of other people, possibly even more than regular playtesting as we are asking people to do something without guidance or a schedule or anything, but we hope it will be both helpful for us and at least a bit of fun for testers. If you are up for taking a look, maybe playing, or maybe just commenting, that would be amazing.

* Not a doctor.

Learning to be a Mentor

This is just a very quick post about the Tabletop Mentorship Program, a scheme run by the wonderful Mike Belsole and Grace Kendall over the last couple of years or so. The idea is that they connect people who do just about anything within the games industry, or who want to, from game design to illustration to podcasting or reviewing, with more experienced members of the community who can help them take their next steps. A mentoring period is over three months, during which the mentor and mentee agree to meet (via an online call of some sort) at least six times, for at least half an hour each time.

After discussing the scheme with a couple of friends, I signed up as a mentor for the January run of the scheme. I must admit that I was somewhat nervous, as I am still close to the bottom of the industry ladder, and wasn't sure how much I could offer, but reassured by the friends, and the information on the scheme's website, I gave it a go.

I was matched with a designer who was working on their first "serious" design (they had tinkered with others, but not got far with them), and we hit it off well on a personal level, and over the three months it was great to see the designer preparing their game and pitch for showing to publishers. They were well motivated and, I think, just needed a little reassurance on a few things and some pointers based on at least some experience of interacting with publishers, which I do have a bit of.

Overall, I found my first time as a mentor to be a really enjoyable experience. My mentee claims I was helpful, and I felt that I learned a lot from the process as well. The scheme also has great support through a Discord server, through which you can get help, advice, or just chat, plus there are regular talks on YouTube (some streamed live, some recorded), interactive discussions, and social meetups.

Applications are now open for the next round of mentorships (which will be the last for this year as the organisers will then be working on restructuring the scheme to be a long-term prospect), and I have already signed up again. If you think you could offer something as a mentor (if you have any experience in any games business related activity, there is a good chance you can!), or would like to find a mentor for yourself (or both, in fact!), it's well worth looking on their website to find out more. Applications for this round are only open until 17th May, so there isn't a lot of time.

An Ancient Space Station Rediscovered

I was having a clear up the other day and found some components stashed in a pile. Not a playable prototype, or even part of one, but a few elements of one of my early game projects that I was trying to build back in 2014, not long after I started this blog, a game that I called Space Station 7, which was about shenanigans between rival peoples/species on a space station that may or may not resemble something that appeared on TV in the 90's. I have the bones of a rules document in my Google Drive, a basic nanDECK script and associated data file, and a few blog posts discussing my thoughts (you can see everything with the SpaceStation7 tag, if you are interested) along with another, partially-written draft that I never finished, but includes some more ideas I wanted to throw in.

After working on this project for a few months I ran out of steam and inspiration and moved onto other things. For instance, it was early 2015 when I first discovered the 24 hour design contest and shifted a lot of my focus to actually getting games to a playable state quickly, which led indirectly to me getting involved in Playtest UK meetups, and the rest is history.

Nothing wrong with prototypes like this.

So I was clearly biting off more than I could chew at the time. I think the game was heading towards being a mid-weight, Euro-ish design that, if I had managed it, would have certainly had way too many weird bits and exceptions. Either than or it would have been utterly dull. 

I have a lot more experience now (though still have plenty of weaknessed) and finding this stuff has reawakened my interest in the project. Having read through the old blog posts and the rules (such as they are), I think there is still something there that I could work with. 

In summary, what we have is:

• Action is centred on a space station, but players also have their own homeworlds and colonies.
• Players have "workers" who are essentially ambassadors and other representatives of their species, which can visit various locations each round to undertake actions.
• Actions are actually triggered by card play, and "workers" have to be in appropriate locations to take advantage of the card plays (e.g. you need a representative in the Council Chamber to partake in debates and votes).
• Actions take a while to come to fruition and need to "develop" by playing other actions or simply waiting. Some of these actions might be played face-down as covert actions.
• Play of actions may be "programmed" each round and revealed in stages.
• Assassinations (of workers/representatives) happen, but the role of the victim is refilled by the homeworld, so they are not lost for ever.
• Taking direct actions against other players can result in "grudge" tokens being exchanged, indicating tensions between worlds, and can make certain other actions harder or easier.
• A was also considering a small, semi-random, semi-set deck of cards to provide a series of events that provide a scenario or plot arc for the game, a bit like having an external threat-of-the-week in a TV show to interact with while they go about their regular intrigues and shenanigans.

I'm planning on sleeping on this and seeing if the Enthusiasm Beast takes over. I have plenty of other projects to be working on, but one more can't hurt, can it?

Researching The Artifact

So, another game design project I have ongoing at the moment, and another collaboration. This one is working with Alex Cannon, who says I am allowed to blog about the project as long as I make him look good. I will do my best!

This game came out of one of the fabulously intelligent and charismatic Alex's occasional Twitter threads of game ideas, after I responded to a short idea along the lines of "friendly worker placement", where players maybe get benefits in some way from nearby workers placed by other players.  I couldn't help thinking about scientific research where, while research groups can be intensely competitive, the whole field relies heavily on the output of others. You know, the whole standing on the shoulders of giants thing. Or at least standing on each others' chairs.

We had a chat and after bouncing various thoughts around, we got to the idea of teams of scientists working to investigate a big alien artifact; a crashed space ship or something. The idea is to find ways to exploit the various forms of technology found in the artifact and earn fame, fortune and victory points!

A first shot at manipulable components, even if it wasn't actually a playable game.

As we live something like 100 miles apart and have been pretty much locked down due to Covid-19 restrictions, we needed to collaborate online. Our method so far has been to make notes and write rules in a couple of Google documents, alongside a spreadsheet for component data, all of which we are both able to edit. I built a set of nanDECK scripts for the various components, and can run those quickly to generate files that can then be uploaded to a Screentop.gg project that we both have access to. It means that I currently have to take action any time we want updated components, but unless there is some structural change required, it takes only a few minutes from changing the spreadsheet to being able to play.

Over the early iterations (we have been having a discussion, and usually a play of whatever we have set up at the time), we homed in on a few concepts that we wanted to build around, and which we have pretty much stuck with even though a load of other things have changed...

• There are no victory points in the game; you win by being the first to achieve three objectives (in the form of "projects".
• There are no spendable resources to gain and then spend; instead you just have access to levels of knowledge according to the positioning of your researchers (workers) and the layout of the board tiles.
• On every turn, you add a tile to a central layout, with domino-like placement rules and can place or move one of your researcher tokens.
• Access to knowledge via your researchers on tiles allows you to play cards to a personal tableau, representing your personal developments and special resources and capabilities.

Mid-February. The round markers are movable player tokens
and the squares are knowledge "resources".

We almost immediately simplified the tiles so that the ones that get played every turn are essentially two-square dominoes, largely for simplicity's sake, but we haven't really felt the need to change this, apart from having big tiles to add to the array when you complete a "project" (one of the objectives). 

The main changes apart from that have been to evolve the development cards that you are playing along the way, gradually adding more variety, restricting the number of developments you can have in your tableau, introducing a mechanism for upgrading from one development to another, and adding special actions to most of the developments. All this now means that there are all sorts of additional actions you can do on your turn, and you will end up losing access to some of them as you change your priorities in upgrading and rebuilding.

Up-to-date, with a three-player game and a lot more going on.

There is still a very long way to go in developing the game, but it seems to be evolving its own character and challenge. Last week we hit a milestone in having our first test play that involved a third player. While this definitely revealed a few shortcomings, as would be expected, our big takeaway was that the game did not completely collapse when played by someone who didn't design it. 

One of the most interesting points made by our third-party tester was that the game felt strategic but not tactical, and it that maybe there should be a better balance between the two -- or at least we should think hard about whether we want a game like that.  The observation was that to a very large extent you could make a plan early in the game, and then execute that plan, and the challenge was to complete the plan as quickly as possible, with minimal concern for what the other players were doing.

This is all a matter of perspective, as while the other player was executing his plan, Alex and I were getting in each others' way a bit, but the point stands: there was a different experience for different players and, at the very least, we need to decide if we are OK with that. And if we are not (in general, wildly different experiences between players might indicate a problem), we'll need to think about how to address it.

Did I make the talented and likeable Alex look good enough in this post? I guess only he will be able to rule on this. 

LCR Redux... Maybe?

You may have come across a simple dice game, usually known as LCR, or Left-Centre-Right (or, for that matter, Never Say Die, which was the version I was introduced to as a kid).  The idea is that there are three dice (usually three, anyway), each of which has three faces that are either blank or have dots on, while the other three sides bear markings to indicate 'left', 'centre' and 'right' respectively.  Each player starts with a pile of chips (or money, if you are feeling saucy) and, in turn, rolls the three dice.  Blank faces (or dots) do nothing, but the letters indicate whether to pass a chip to the player on the left or right, or into the middle of the table.  The last player with chips remaining is the winner -- and, if money is at stake, claims the central pot.

I have a fistful of LCR dice, acquired several years ago,
that have stars instead of "centre" for some reason.

This can actually be quite fun,  although, as you can see, there is no element of player skill or choice involved in the game.  You just sit there, roll dice and shuffle chips around, and then somebody eventually wins.  The neat idea is that the flow of chips to the centre means that the game steadily moves towards an end (on average, a chip should go to the centre on every other player's turn) and won't get stuck in endless chip shuffling. The other neat idea is that even when you are out of chips, there is a chance someone will pass you one and you will be back in the game.

I have been thinking about this and wondering how I could build on the basic idea of LCR to create something that actually functions as a game, with actual player choices to make.  This clearly doesn't need deep decisions: I would want to keep the fast flowing nature of the original, but if each player had at least one choice to make each turn, it would be great.

So, some general thoughts on this...

• Perhaps, instead of passing chips around, it is dice that get passed.
• Or dice and chips.
• There could be multiple coloured dice and one of the objectives could be to collect a set of one colour.
• I prefer to not rely on colour, but sometimes it can't be helped -- and anyway, as this game would require custom dice, there could be a shape on each face to help with differentiation.
• Maybe a real-time element, with more than one player able to be rolling dice at any given time.
• A real-time part to the game can substitute for decision making (at least to a point) as the game effectively becomes partly a dexterity game. 
• Possible decisions to make:
• How many, and which dice to roll at any given time.
• Who to pass dice or chips to.
• Trying to collect sets of dice faces.
• When to "bank" something.
• Taking an action to end the game, and timing when to do that.
• Whichever way, I think the game should have (most of) the simplicity and pace of the original.

Not really getting any closer to turning this into something, but I figure that if I at least write some of this down and publish it, it might be more likely that I do further work with it. That said, the amount of game ideas over the years that I have posted about once or twice but didn't go anywhere are extremely numerous.

Just for a bit of fun though, the dice themselves suggest some alternate uses -- and thank you to assorted Twitter people for bouncing more ideas around. For instance...

• Dice with "left", "right" and "★" (as well as the colours) on them might suggest a fighting/boxing game, either battling another player or trying to defeat "opponents" represented by cards.
• ...Or maybe something with a "Space Invaders" vibe, either with a similar mechanism as the boxing idea or with space ships actually moving on a board.
• ...Or some other retro-arcade type game, like the ones where you are trying to follow a winding path or dodge oncoming obstacles.
• ...Or Tug-of-War, with a rope being pulled left and right.
• ...Or something related to Twister. I think there is already a dice-based Twister game you play with your fingers -- but right now I can't be bothered to research.
• ...Or even a Yahtzee-style set collection game. Mind you, that is pretty much an option with any type of dice.

So there, a post with no conclusions or anything actionable. I'll think on this some more and write again if anything comes up. Input welcome! 😀