Features and Considerations for Digital Board Game Conversion

Some Definitions

  • Conversion: The labor/effort involved in porting a game from a tabletop or “boxed” version to a digital platform.
  • Digital Platform: An environment where software can run. Possibilities include: mobile devices (iOS/Android), desktop (Windows, Apple, Linux), game consoles (Playstation, Xbox, Nintendo) 
  • UI: This stands for User Interface. Sometimes used interchangeably with “graphic design”, the user interface refers to the visual elements that make up your application. Typically an artist or graphic designer (or both) creates mock-ups of your UI in an early stage of the project and then the developers implement it, or “make it real” throughout the project.
  • UX: This stands for User Experience and is not to be confused with UI. The UX is all about the actions the user takes to accomplish various tasks or access the features of your application. UX for games (especially on mobile platforms) can be a bit more complex than non-game applications, and should be well thought-out either before, or early on in development. 
  • Costs: For the purposes of this document, this can mean time or it can mean money. Because you can convert from one to the other.

Basic features every mobile board game must have

  • Basic game playability – This essentially means the “engine” of the game. It’s nothing you can see, but represents the cost of implementing rules enforcement and game state.
  • Game UI – A basic game screen. Costs include UX considerations and graphic design as well as the implementation of that design. This can be entirely 2D (cheaper), or entirely 3D (which will look more like the physical version, but generally costs at least 2x), or a combination of both.
  • Menu screens – At least a “main menu” (before start screen), and in-game (pause) menu will be required. These are usually 2D.
  • Rules reference – At minimum this is just the rulebook of the game implemented as a screen in the application. (See Tutorials in optional features.)

Additional features

Gameplay

  • Pass-and-play mode – This is a feature where two or more players can play the game using a single copy of the application. Essentially the only cost of this is the amount of effort it takes to implement the UX and UI necessary to support the feature. (Typically fairly minimal, although it does necessitate a game setup screen.)
  • AI – This enables playing without an opponent. Costs can vary wildly for this feature, and there are many cost considerations and options just related to this feature. It is typically a fairly large portion of the cost of conversion, however statistics that I’ve seen show that most players are looking for solo play in their digital board game conversions. (If you do not have “play against an AI” in your list of features, many users, including some reviewers, will not even look at your application.)
  • AI Difficulty Tiers – Typically once an AI has been developed, it is not too difficult to make it play “better” or “worse” by tweaking some parameters.
  • AI “Personality” Tiers – This means implementing multiple “play styles” for the AI opponent. This is typically more work than tweaking AI difficulty. It is more noticeable/effective in some games than others.
  • Online Multiplayer – There are so many options and considerations here that I gave it its own section below.

UX & UI

  • Game Setup Screen – Depending on the game, this can be a required feature. This allows for the customization of the game before play begins.
  • Tutorials – There are a number of varying approaches you can take here. Simplest (and lowest cost) is a non-interactive or “step-through tutorial”, which essentially just allows the user to page through what amounts to screenshots of the application while highlighting the rules of the game as well as highlighting the actions the user must take in the application to play it. This is generally considered a poor tutorial experience for all but the simplest games. A more effective tutorial strategy is an interactive or “in-game” tutorial, guiding the player through an example game (or part of one), allowing them to perform some of the actions of the game while the rules are pointed out to them in a scripted sequence. Finally, a third approach is to allow the user to start playing the game right away, while seamlessly presenting them with “contextual prompts” that either tell them how or why to perform the actions available at any given moment. A blend or combination of all three approaches is also possible.
  • Music – Usually considered the minimum effort, a single musical loop is quite easy to implement, and will improve the user experience for some players significantly. An actual soundtrack is not usually cost prohibitive, however, and the true cost is that of the additional development time incurred in deciding when to start and stop playback.
  • Sound effects – Note that some lists would probably put music & sound effects in the required list. They are typically a very high cost to benefit ratio, and there are a not-insignificant number of users who will complain if your conversion doesn’t have at least some basic audio effects.
  • Settings – At minimum, you probably want to implement a mute switch for the aforementioned game audio.
  • Additional “static” screens – Typically these include things like: logo splash, a sales pitch for the physical game, or about the publisher. Costs here are generally fairly minimal.
  • Visual Polish – “Juice” is a game industry term that generally refers to how good the game “feels” to play. This is its own discipline, and a major part of almost all commercial game development. One way to think of it is to break down each of the actions you can take in a game and ensure that they have appropriate feedback for the user. (Usually some combination of both visual and audio effects.) Often it makes sense for these effects to have animations associated with them. Generally, the more pleasing the effect, the more the user will want to continue to play the game. Most video games incorporate quite a lot of these animations and graphical effects. This is not always the case for board game conversions, because the players can be counted on to be attracted to the physical game they already know (or know about). Put another way, these players are not playing because they saw a fancy trailer or because they saw a screenshot and decided the art looks amazing. That said, amazing art and fancy animations WILL absolutely help you sell more copies of the application, which in turn will help you sell more copies of the board game. Visual polish is unfortunately, very time consuming, and while some simple animations can be built easily “as you go”, generally the more animation and “juice” a game has, the more likely the developers spent a some amount of time after the development of the basic game on additional visual polish. This additional effort is referred to as “juicing” the game.

Metagame

  • Statistics – A collection of metadata about the user’s game playing over time. Typical statistics might include: number of games played, win percentage, average score, etc. Each game usually also has some distinct things specific to it that can be collected into statistics. An example in Chess might be the number of pieces captured by your Queen. Usually for each statistic you can give at least two numbers, a total over all games, and an average per game. Statistics generally have three costs, the cost of collecting the statistics (generally there will be a list built up during gameplay, as well as a few that can only happen when the game is completed), the cost of saving the statistics (whether to disk or in the cloud), as well as the cost of displaying the statistics to the user elsewhere in the application.
  • Achievements – Often the statistics mentioned previously will be used to drive these, but your game might also suggest specific goals that can be made into achievements as well. You want each achievement to be a singular accomplishment that the user can take pride in completing. Most platforms have their own systems for achievements, and many of them require an image (or icon) to be associated with each achievement. If you are building a cross-platform application, you’ll typically want to build some kind of custom visual display (UI) for these yourself, as well as push them to the platform’s achievement APIs.
  • Leaderboards – These are rankings or ladders where players can compare their own statistics with other players’ statistics. The best platform implementations of this allow the user to see a filtered list of these comparisons against just their list of friends on the platform. All the major platforms have their own leaderboards. As with Achievements, if you are building cross-platform, one decision you’ll have to make is whether to allow users to compare themselves to users on other platforms. If so, this is a feature you’ll need to leverage your multiplayer server to create.
  • ELO or Skill Ranking – This is a number meant to represent the player’s skill in a particular game. It is generally calculated after every game, and in some games (Chess, especially) used to match players with other players of similar skill.

Online Multiplayer

Here are some important questions to consider: 

  • What kind of multiplayer gameplay? – The most common options are “real-time” and “asynchronous”. Asynchronous play (meaning both players do not have to be online at the same time to play against one another) doesn’t work for all kinds of board games, so the game itself may influence this decision. In general, it’s usually possible to develop an asynchronous implementation in such a way that real-time play is also possible, but not vice versa.
  • Where will you store the online games? – For all multiplayer, there is a server component needed. Here again there are a lot of options. Generally speaking, the easiest option is to use a 3rd party multiplayer service. (Some examples are PlayFab and Photon, both providing relatively “turnkey” solutions for Unity developers.) Many of these exist, and each have their own costs (as well as features and trade-offs) associated with them. Each of the platform holders also have their own multiplayer servers, but then you are limited to multiplayer opponents (and features) specific to that platform. Yet another option is to create your own “custom server application”, which allows for a lot more flexibility and some efficiency gains, but has a higher up-front cost.
  • Will you require an account? – You can do online multiplayer without accounts, but generally the user won’t be able to switch devices or recover the account if they delete the app and reinstall it. There are other limitations as well. Some server options (platform-specific ones especially) have accounts “built in”.
  • What kind of matchmaking? – Some examples of matchmaking: “pit me against a random opponent”, “invite my friends to a game”, “play a game with someone at my skill level”. Each of these has their own difficulties and feature requirements. Some options will not be available on all server types.
  • What social features? – Like matchmaking, which social features you chose to implement will have a lot to do with the capabilities that are available on whatever choice you made for your server component. Here are some examples: “allow the user to create a friend’s list”, “allow the user to react to another player’s move in some way without text (an emoji, for example)”, or “allow the users to chat with one another (text or audio) during a game”.

Monetization

Anything above a straight fixed-price for purchasing the application (the fixed price could be free) is going to take additional development effort. 

  • Ads – I generally recommend against this approach to monetizing digital board games. You’ll need a significant number of daily active users in order to see any appreciable revenue (generally around 100,000), and there are significant drawbacks.
  • In-app purchases – These come in basically two flavors, although both flavors involve building some kind of UI, in addition to the costs associated with integration with the various platform (or separate payment platform) APIs. Some examples: 
    • 1) The most straightforward in-app purchase has a single-use. (Examples of this include game expansions, or sometimes cosmetics, for instance allowing the user to play on a different game board or with different color pieces.)  
    • 2) Another common in-app purchase is for “consumable goods”. Examples of this include coins or some other currency in the application that can then be “spent” on essentially whatever you like. Other examples include allowing the user to purchase hints (or undos) in a puzzle game, or tokens redeemable for additional multiplayer games, or any number of other consumable digital goods.
  • Subscriptions – This is a strategy that is gaining in popularity, but is not very common for individual games. All the major games platforms have a subscription service, and it’s worth noting that these platforms do solicit games to be included in their service. As of this writing, Apple Arcade is boasting about including over 180 games, and Google Play Pass says it includes “hundreds of awesome games and apps, completely free of ads and in-app purchases”.

Conclusion / About this post

I wrote the original version of this document many years ago. (At least 5, but that probably came from notes I’d made even earlier.) I was recently exchanging emails with a potential board game conversion client, and I mentioned that I had a list like this floating around. I made another significant revision before sending off, and decided to present it here. I’m sure it’s missing some things, and of course every game has its own considerations above and beyond the ones that are listed here.

Blinks 3D Printed “simulator”

I’ve previously only mentioned once on this blog (in passing) that I spent some time a couple of years back working on a prototype for the Blinks game system (https://move38.com/). I backed the first Blinks Kickstarter, and was very excited to make games for the platform when I received my development kit.

I worked the most on a game called Takeover (https://github.com/mgrider/takeover), which I’ll admit doesn’t take advantage of the real-time possibilities that Blinks as a platform affords. It uses the digital aspect for a sort of rules enforcement, but the game is more or less a traditional board game, gussied up in fancy LED clothes. It’s got fairly simple rules that you can read on the Github page linked above (in the README.md file that is automatically displayed on that page). Although since I’ve made a physical prototype, (more about that in a second) I’ve been experimenting with different rules variations.

Takeover was well-received at the events where I showed it off, but much like demoing VR, it’s hard to gauge whether that reception was for the game I’d developed, or the medium in which it was presented. In contrast, Takeover had a rather lackluster reception on the Blinks forums, so I sort of soured on making another game for Blinks. Or probably more accurately, I just didn’t have another idea that compelled me to spend the time it would take to code it for the platform. (It’s also worth noting that all of this happened before I got the final retail version of Blinks in my hands, and by the time that did occur, I hadn’t worked on anything Blinks related in several months.)

Fast forward about a year, and it occurred to me that, precisely because Takeover doesn’t use the Blinks platform to its fullest advantage, it would be entirely possible to play it with only physical components. This of course led to the question of what those components would look like.

I landed on 3D printing hexagonal trays with “slots” for 1 cm cubes to sit in. Because I think there’s a chance other game designers have these 1 cm cubes laying around, and they might also have access to a 3D printer, I’ll also make the .obj file available for download.

Click this image to download the corresponding .obj file.

To use this, you’ll obviously want to print a bunch of them. I think there are lots of possibilities for these above and beyond “simulating” blinks games. If you come up with something cool, please let me know!

Formal Game Representations

There are a few different specialized “languages” out there now for describing games. Perhaps because Abstract Strategy games are often quite “simple” in terms of rules complexity, these sorts of game description languages typically have examples that are abstract strategy games. (But also, I think, there’s probably an overlap between people interested in this topic and people who are interested in games that require an extraordinary amount of logical analysis to play.)

I have been very interested in this topic many times over the years as I became aware of various projects and aspects of this topic, and this post will be my attempt to outline some of my findings.

Early game description work / History

There is a relevant “History” section of the Wikipedia article on General Game Playing (https://en.wikipedia.org/wiki/General_game_playing#History). This is a page on Artificial Intelligence (AI) that can play multiple games – as opposed to a specialized program that just plays a single game like Chess, for example. The article says that this concept was first proposed by AI researcher Barney Pell in 1992, with something the article called a “Metagame System”. Pell’s research, at least some of it, is still available via the wayback machine, and I read through one article called “Metagame: A New Challenge For Games and Learning” (https://web.archive.org/web/20070706185808/http://www.barneypell.com/papers/metagame-olympiadUCAM-CL-TR-276.pdf) from 1992 that was surprisingly readable (and fascinating). In it, Pell says:

“In order to write programs which can accept a set of different games, we must specify how these games will be represented. Although fully-general representation languages are possible (like first-order logic or Turing Machines), it is likely that classes of games will be much more specific, especially those which can actually be produced by a generator. So, any representation language can be used, so long as the games produced are guaranteed to be unambiguous in the chosen representation, and so long as the semantics corresponding to the representation is clear. A natural method of representation, pursued in ([Pel92]), is by means of a game grammar.”

Metagame: A New Challenge For Games and Learning

“[Pel92]” here refers to a companion article titled Metagame in Symmetric Chess-Like Games. This second article does get far more into the weeds with details about the game grammar used to define games that the Metagame-playing AI will learn to play. I found it actually kind of disappointing, because much of the article is dedicated to defining the types of game the grammar will describe, and it was surprisingly limited in scope.

It’s worth saying a bit about the context of these papers, and noting that this research is all about developing AI. The premise here is that an AI that can play multiple games would be more useful than an AI that can just play one game. The whole point of this project was to be able to pit different AI against one another in a tournament. This grammar was going to be used both to more easily facilitate the AI learning the games, but also to generate new games so the AI would be playing something never before encountered.

This is probably worth repeating: The earliest effort to formalize a language for describing games was only undertaken in service of an effort to teach games to computers.

Zillions of Games

I remember playing a program over 20 years ago now called Zillions of Games (http://www.zillions-of-games.com/). The copyright on the ZoG website says 1998. I remember using it to play Othello and many Chess variants, and (perhaps more importantly) explore a ton of other games that I’d never heard of before Zillions. They were probably also games that it would have been near-impossible at the time for me to hunt down in physical form.

Zillions of Games came bundled with ~250 games, each of which was described individually in a .zrf (presumably “Zillions Rules File”). If you owned the full unlocked copy of the game (this was the shareware era when game demos were near ubiquitous), you could import your own ZRFs, and there was (amazingly still is!) a community of folks who spent time implementing new games.

I have a very distinct memory of liking Zillions of Games enough that I wanted to learn how to develop games for it. But I was in college at the time, and distracted by many other things vying for my attention.

You can find some information about ZoG, and the language used to encode the games, on the website, but also on Wikipedia (https://en.wikipedia.org/wiki/Zillions_of_Games). The description language for ZoG is lisp-looking, (with parenthesis everywhere). I only call this out because it’s influenced future projects with this gaol. ZoG had lots of limitations. It was notably not suitable for card games or other games that required any hidden information, probably because ZRF had no concept of variables!

It’s worth noting that, while it’s not exactly the same thing, I do see a parallel between ZRF creation and other platform-specific game creation languages, like Game Maker Studio’s GML, or Godot’s GDScript. Zillions of Games was a Game Engine as well as a product that allowed the user to play the games made in that engine. The games just happened to be board games.

Ludii

More recently, (in the last few years), I’ve been aware of a project called the Ludii General Game System (https://ludii.games/). This is (at least partially) the brain child of Cameron Browne, a game designer, computer scientist, and author, who is very well known in some abstract strategy game design circles. He wrote a book on connection games that I have on my shelf.

Ludii has some very interesting project goals, but more importantly, the project has now written description files for literally over 300 games. (There are over 2,000 games with descriptions for use in Zillions of Games, but that software is quite old now, and I think Ludii is far more interesting.)

You can download Ludii now, and play all of the games it comes bundled with, and even create your own .lud files and load them into the player. There is a language reference for Ludii (https://ludii.games/downloads/LudiiLanguageReference.pdf) that is 386 pages long!

To really dive into Ludii development, unfortunately, I don’t think the language reference is going to be enough. There is also a Ludii tutorials document, but I found it a bit disappointing in its brevity. As of this blog post, there are really only two pages that are particularly relevant to writing your own .lud files. This one on the “basics”: https://ludiitutorials.readthedocs.io/en/latest/lud_format_basics.html and another one on recreating the game Amazons in Ludii: https://ludiitutorials.readthedocs.io/en/latest/tutorial_amazons.html I also watched a nice introduction to Ludii on youtube. (https://www.youtube.com/watch?v=pTkO8h8RBBI)

I’m in the process of posting a few different places (in various BGG forums) to see if there are better tutorials that I’ve just been missing.

Other systems

For the sake of putting everything I know about this subject into this post, it’s worth noting there is another competitor to Ludii that may have been around even before it, called GDL, or Game Description Language (https://en.wikipedia.org/wiki/Game_Description_Language) GDL looks like it was developed at Stanford, very likely in conjunction with some AI coursework. I’ve dug around some of the GDL related sites and there are broken links galore, but there’s lots of information about it online. Some of the earlier Ludii papers reference GDL, so I’m fairly certain it came first.

There is ALSO a javascript project called Dagaz (https://github.com/GlukKazan/Dagaz) which shows quite a bit of promise, and has been used to port all of the games at MindSports (https://mindsports.nl/) from java to javascript. The author of Dagaz write a very nice article on some of this stuff (which someone else translated to English), which you can read here: https://habr.com/en/post/481868/

One more footnote is that there is another comparatively young project aiming to do some of this same kind of stuff in python called Zero Play (https://donkirkby.github.io/zero-play/).

Conclusion

So it seems to me that there are a few reasons someone might be interested in describing games (in a language tailor-made for that purpose):

  1. To improve and teach generalist AI to play multiple games.
  2. To generate new games programatically.
  3. To use a common codebase to facilitate the playing of games.

I am interested in all of the above. Although the implementation details of AI optimization and improvement are not in the circle of my particular venn diagram, access to generalized AI is of interest to me. (I thought about splitting #1 into multiple bullet points.) It’s worth noting that the last project mentioned above (Zero Play) is named after AlphaZero, (https://en.wikipedia.org/wiki/AlphaZero) a general game playing AI that was created by the same team that made AlphaGo. (AlphaGo being the Go-playing AI that famously beat one of the best human Go players in a series of very public games in 2016.)

The second bullet point is definitely one of the goals of the Ludii project, and one that Cameron Browne has extensive experience in. Games which have been created by computers are listed in a “family” on Board Game Geek (https://boardgamegeek.com/boardgamefamily/22566/misc-computer-generated-games/linkeditems/boardgamefamily), (containing at this time only three entries, two of which have Browne listed as designer). Probably the most well-known AI-created game is Yavalath (http://cambolbro.com/games/yavalath/), which Browne created using an earlier program (called LUDI) while he was working on his Ph.D. in 2007. While the earlier work by Barney Pell definitely indicated this was an objective, I didn’t find any evidence that it succeeded.

Finally, it is the facilitation of a general platform for game playing (& playtesting!) that I think a description language will be most valuable to me, personally. This is the primary reason I am interested in Ludii. Ludii’s platform (java application, but also online multiplayer) seems very stable, and has an increasingly tantilizing list of features. There is a category of simple games in particular (with simple rules) that seem to be a very nice fit for the platform. On their forums, the Ludii team have said that web-playability is on their roadmap, and that will lower the barrier to entry even farther.

I am going to try and implement some games in Ludii, and evaluate whether it’s a good platform for playtesting new games. It already includes features for analyzing games like 1st player advantage, and branching factor. These are metrics for their games that every game designer will probably find interesting.

Update:

After writing this post (and promoting it on BGG), Cameron Browne actually pointed me to some additional resources relevant to this discussion, (which led me to even more resources) and thought I’d drop some additional bullet points in here.

  • Brown pointed me to an article by Jacques Pitrat from 1968 called “Realization of a General Game Playing Program”. In his words: “… doesn’t specify a GDL as such, but shows that the idea of GGP has been around for more than half a century!”(https://www.semanticscholar.org/paper/Realization-of-a-gener…) Alas, I haven’t yet found a way to access the paper.
  • Jon Orwant wrote his Ph.D dissertation in 2000 about what he calls the EGGG (Extensible Graphical Game Generator): https://dspace.mit.edu/handle/1721.1/9164
  • Stephen Travener’s program Ai Ai uses a description file type called MGL, for Modular Game Language (http://mrraow.com/index.php/aiai-home/mgl/). It’s worth noting that Stephen Travener is a person quite relevant to this discussion, as he has worked on both Zillions of Games and Ludii, as well as his impressive Ai Ai software, which is also capable of playing and analyzing hundreds of games.
  • Browne pointed out that there are description languages for card games (I haven’t done any research into this yet.) and Video Games. Specifically, he pointed me to General Video Game Description Language (GVGDL), which I haven’t been able to find in a quick search, although there are plenty of hits for VGDL, and I haven’t really looked into that yet either.
  • Finally (again), the Ludii project website has a history page that I hadn’t read until after posting this. It outlines the history of a few other projects that led to Ludii’s creation, including Browne’s previous project Ludi, which I at least mentioned earlier. Well worth a read if you’re interested in more on this topic. (https://ludii.games/history.php)


Thrive – IGDA Twin Cities talk

Last night I gave a talk (on twitch.tv/igdatc, as all of our IGDATC talks have been for the last 6 months) about Thrive. It was basically a retrospective on the design and development of Thrive as a physical board game as well as a bit of a preview of Thrive as a digital board game app. You can watch the talk on YouTube already, but I’m also embedding the slides here for posterity.

Incidentally, I am now distributing the Thrive app on TestFlight, so if you see this and want to play it on your iPhone, let me know, and I’ll send you a link!

Spiel 2019

This year I attended my first ever Essen Spiel, the world’s largest board game convention.

Bucket list item: Check.

I came back with this pile of games

…as you can see, they are mostly (but not all) abstract strategy games. And for the most part (with a couple of notable exceptions) they are games that I am unlikely to see in a store here in the states. I haven’t played them all yet, but I have made a dent, and I’ve quite enjoyed Control V, Nova Luna, Hetrix and Stackers so far. My family played a game of Miyabi, and my wife even declared she approved of the purchase!

I was demoing and exhibiting with Adam’s Apple Games, who had, months ago, during the kickstarter, hoped to have Thrive there for sale, but alas, there have been manufacturing delays, and it now looks like it’ll be next March (probably at the earliest) before we see the final production copies. You can see me here standing next to the 3D printed prototypes that we’ve been showing around for the last year or so.

Spiel is more like a trade show (they refer to it as an expo) than most of the other board game related events I’ve been to. Comparing it to Gen Con in particular is interesting, because at Essen there are really no “events” at all. Some exhibitors might post a list of events they are having in their booth, (signings or tournaments most likely), but the convention itself has no designated spaces for events, and doesn’t post a schedule. At Gen Con the expo hall is maybe 1/4th of the designated convention center space, and probably 1/2 of the total space is purely for events. (Many of which are ticketed and cost additional money.) Another difference is that most people expect to actually play games in the exhibitor booths. So most booths, even the smallest ones, have a demo table (or a dozen!), and folks sit down at them mostly to play entire games. Although many of the larger games at the bigger publisher booths (but not all) were just shorter-length demos, which is usually what you get to do, (if anything!), on the show floor at Gen Con. But of course Gen Con has all that additional space for events, most of which are just scheduled times to play specific games.

A lot of people attend Spiel, this year nearly three times as many as attended Gen Con. (If Wikipedia’s numbers are correct, 209k vs 70k.) But for that, it never felt significantly more crowded than Gen Con to me. Yes, there is more physical space, certainly, but I think another factor could be that more folks attend Spiel on day passes than Gen Con, and so you have fewer people at any given time. Certainly Saturday and Sunday did feel very crowded, but I saw very little shoulder-to-shoulder, wall-of-humans that is common walking the expo floor at Gen Con.

You don’t see stuff like this at Gen Con.

You can’t throw a stick without hitting a designer. Not thinking of the attendees so much, but as I walked around the convention, the folks staffing the booths were quite often the game designers themselves. This was definitely not as true in the larger booths, but the smaller ones it felt very common for the designers to be present, and if there was only one person staffing the booth, I’d guess it was 50/50 whether that person also designed a game being shown.

It was super multicultural. There were definitely publishers there from all over the world. I personally met folks from Australia, Korea, China, Spain, the UK, Ireland, and of course Germany. But as large as it was, not all the US publishers were there. I can only speculate why, but certainly some of them don’t think a cost/benefit analysis holds up, but I also think it’s just plain impossible to go to all the events all the time. I’m fairly certain you could find a board game event somewhere in the world to go to every weekend, if you tried hard enough.

I’m definitely glad I went, and I would do it again. I really enjoyed wandering around the show floor and seeing all the new games.

Thrive is on Kickstarter!

So Thrive is a game I designed during my game-idea-a-day project, way back in 2016! It’s a two-player abstract strategy game (which should surprise nobody), and the big innovation is that you augment the way the pieces move as you are playing the game. A little over a year ago it was picked up by Adam’s Apple Games, and just NOW, TODAY, it’s on Kickstarter.

This is my first ever board game getting a print run of any size. I’ve been extremely grateful to Adam for taking me along on this ride, keeping me in the loop on many of the decisions along the way, and allowing me to be such a part of this project.

Protospiel MN 2019

Last weekend was Protospiel MN. After how much fun I had at the Madison protospiel (was it just a month ago!?!?), my expectations for this one may have got away from me. I ended up spending quite a bit of time in the last few weeks prepping new prototypes. Here’s what I brought and tested:

Adam Rehberg and I both brought copies of Thrive in various states of quality. It was interesting to compare his 3D printed pieces to my own. (We are using a new model courtesy of local artist Colin Cody-Waters, and his printer does a better job with it than mine.) At this point, we are more in marketing mode than actual play testing, but we did have some new things to playtest.

Worth noting that there will be a kickstarter for Thrive at the end of February, or beginning of March, and at least in part to collect email addresses for that kickstarter, there is a Thrive print-and-play contest going on right now over at Adam’s Apple Games.

I managed to get a new “pyramid tile laying / fitting / stacking game” to the table several times. The tiles are (some of them) glued together in 1/4th overlapping shapes and patterns. (This is harder to describe than I realized.) I’ll include a photo of one of the end-game pyramids below, but you can’t really get a sense from the photo which tiles are actually glued together and which are singletons. The idea is that you use the singletons as currency to pay for the larger tiles. One of the last parts left to design was how to score the game, (though I had plenty of ideas), and I got lots of useful feedback on those ideas, as well as plenty of other helpful suggestions from my play testers. One of the games we ended up calculating scores for each player in 4 different ways. None of them fully met my criteria for how I wanted the scoring to incentivize building up rather than out, so I still have some thinking still to do on this one.

Oh Tetrominoes! – just the blocks – I made a version of this game by gluing 1-inch cubes together (pictured below). It was easy to get to the table, because it just looks and feels really nice, I think. Adam gave me some great feedback about wanting a “qwirkle moment”. And someone suggested having blocking pieces. Next time I play it I want to try where only the three polygons score, and the spaces marked X are blockers. Notably, the game board (with score track) was the first and only thing I’ve ever created in Illustrator, only about an hour of work.

Windrose – I did playtest this again at the convention. There were some new ideas thrown around. I sort of thought this was “done”, but the conversation left me bristling with ideas. I sort of feel like most of them would result in a different game entirely, but that’s not necessarily a bad thing.

I did also bring my Blinks dev kit, which was running my game Takeover. I only actually brought it out on Saturday night, after the main convention hall was closed for the evening. Immediately after we played it, we played Oh Tetrominoes!, and someone paid me the compliment (paraphrased) “You’ve shown me both the most sophisticated (technically), and least sophisticated (physical components) games that I’ve seen this weekend.”

Other highlights:
– My standout game for the convention was a numbers-heavy (but not at all otherwise heavy) strategy game by Patrick Yang. He’s calling it Mathemagical, which is a great name, and I really liked the game.
– I got to play a tetromino stacking prototype called Lots. It was light and quite fun.
– My daughter attended with me on Sunday, and she ended up spending at least an hour (maybe two) prototyping a game in collaboration with another little girl who was there. I think they both really had fun, and there were even some neat ideas they came up with together.

Protospiel Madison 2018

This was my first time at this particular Protospiel. I do think the space was bigger than the MN one, but only by a factor of maybe 1.5x or 2x. I heard tell it was actually more space this year than previous years, but I have no idea if that was true. I also heard there was less of a publisher presence this time around. The only ones I saw, were Adam Rehberg from Adam’s Apple Games, (who I traveled over with), and the GameCrafter (if you count them as a publisher). Of course others may have been there incognito. (Or just less obviously.)

Adam (who is publishing my game Thrive) and I set up Thrive as a blind playtest on one of the back tables. This was the first time it had been shown with (some of) the new artwork, and we got a lot of praise for it. (I’ll post a photo.) I did feel bad briefly on Saturday when it was especially packed for taking up the space, but there was almost always someone playing it, and I had so much positive feedback, both about the game itself, and about doing a blind playtest at Protospiel (which several folks said they’d never seen before), that the feeling was easily allayed. We got good feedback on the rules, and added about 15-20 names/emails to our signup sheet to let folks know about the kickstarter when it happens. (Incidentally, we talked about a date for the kickstarter on the car ride home, and we are currently aiming to have it now in March.)

My personal goal was to get more games of my two current favorite designs in, and I got both on the table several times. The first, (with working title Oh Tetrominoes!), was played 3 times to completion, and only actually broke on the 4th play through. While it mostly felt like it works mechanically, I think the consensus was that it’s a bit fiddly, and not especially fun. It’s a mashup of three or four game ideas I had that all feature tetrominoes, and while they are integrated well (I got compliments on this!), they still feel weirdly disjointed, and one of them really feels like the core of the game (which I reluctantly agree with). After the last (failed) gameplay, one of the playtesters actually convinced the rest of the table (including me, but I didn’t need much convincing) to play a game of just that main core mechanic, without the other features. That went really well, and I’m definitely going to pivot the game a bit. (I mean really, I think it’s basically done, but I suppose I should playtest it a few more times to be sure. I’ll probably try and re-use the other mechanisms in a different game… someday.)

I felt like my other game, Windrose, had each playtest go better than the last. My goal for that one had been to play it with 4 players. as It had previously only been tested with two. I got in 2 more 2-player games, 3 4-player games, and one 3-player game (in that order). It really felt like it worked just fine with 3 and 4 players, although after the first 4-player game, we added a rule that changed strategies quite a bit without making the game feel all that different. I do think I prefer it with the new rule. Otherwise, the game didn’t actually need any tweaking, which feels kind of amazing to me. It’s another super simple abstract strategy game, and creating one of those that plays 4-players is really exciting to me. (Probably not something any publisher is going to be interested in, but you never know!)

Other highlights for me include:
– Playing a couple of new-to-me Adam’s Apple Games prototypes.
– A game played with “kite and dart” Penrose Tiles, which really looked cool.
– Seeing, (but sadly not actually playing) Cartographers: A Role Player Tale, which looked like a contender for my favorite take on the emerging “Flip and Fill” genre that is hot right now.
– Having dinner with Nick Bentley, who I have been acquainted with for some time, (I turned his game Catchup into an iOS app a few years ago), but until this trip might not have actually called a friend. We had such great conversations at dinner on Friday that we resolved to do it again on Saturday, and then I managed to convince him to play a couple of games late into Saturday night.

There were way more games that I was interested in trying out than I actually got to sit down and play. I did play a lot of games though, and I hope I gave some good feedback. I’d say the ratio of playing my own games to others’ was probably 40/60. All in all, definitely a great event for me. I’d recommend it, and definitely hope to do it again.

Eigenstate on BGG

I wrote a forum post about Eigenstate over at Board Game Geek in the Abstract Strategy Game Forums. In the post I cover where I got the idea, how I made the original prototype, and a bunch about ideas that I tried to incorporate and didn’t work nearly as well as the current rules.

Speaking of rules, I also posted them.

In prep for all of this, I submitted a BGG entry for Eigenstate, and uploaded a few photos of it on my BGG designer profile.

But the big news is that Adam from Adam’s Apple Games is planning to publish the game. This is obviously extremely exciting for me, as it’ll be my first board game to have a real box and print run.

Anyway, I’m going to reproduce the BGG post here for posterity:

New game: Eigenstate

Eigenstate is a 2-player abstract strategy game with incredibly simple rules that grows in complexity as you play.

Each turn you move a piece and then add two additional eigenstates (pegs) to your pieces giving them more possibilities for movement on future turns. Land on your opponent’s pieces to remove them from the board and when you’ve reduced them to one piece remaining, you win the game.

You can check out the rules and a 3D printer file for the pieces here: https://tinyurl.com/eigenstate (I’d really love to hear about it if you take the time to print it out!)

Design by subtraction

As you can see from the photo above, each piece has 25 holes, and all but the center space correspond to a possible move for that piece (relative to the center). Each piece only starts with a single movement peg, facing forward.

This design was a direct result of my playing a lot of The Duke and Onitama, and realizing that I wanted to make a game with similar movement mechanics. This was back in the summer of 2016, and at the time I was doing a project where I tried to come up with a new game idea every day. This game was the result of one of those ideas, and because of that project, I know the precise date I came up with the idea. (2016-03-28, and it’s outlined in vague terms in this blog post) I wrote again about the idea once I’d built the initial prototype, (and started thinking about it as a game system) about a month later, on 2016-04-25.

I’m extremely happy with the current simplicity of the game rules, but as usual, it took a lot of playtesting and experimenting to get there. After the initial idea about pieces that gain additional movement possibilities over time, I had a lot of different ideas about how the game should play. But first I had to make a prototype.

I bought some cribbage pegs online, and then spent a couple of afternoons in my friend Lloyd’s garage with his drill press. Once I had a physical prototype, I started playing versions of the game wherever I could, often with pretty wildly different sets of rules.

Ideas that were interesting, but didn’t quite work included: allowing piece rotations; action point allocation for placing pegs and moving around the board; using the checkmate mechanic from Chess; using different colored pegs for different movement mechanics; recycling (repurposing) the pegs you capture from your opponent; forcing your opponent to put pegs in their remaining pieces when you capture one (with the end-goal to make them fill up a piece); and all kinds of ideas related to scoring based on the number of pegs in your control. Some of these were more complicated than others, but all of them resulted in a far more complicated game than the game as it exists today.

Notably, in this period of floundering around, I sat down with Patrick Leder (at GlitchCon a local game development conference here in MN), and also Nick Bentley (at Gencon 2016). I don’t think either of them were all that impressed, and around that time, I basically shelved the game for about a year after that.

In the summer of 2017, I signed up for a table to show my games at the Twin Cities Maker Faire. Most of my games are for touchscreens, so faced with the prospect of a 10-foot table mostly empty but for a couple of phones and an iPad, I decided to lay out Eigenstate. This meant I had to explain it to people very quickly. Without referring to my notes, and pretty much off the cuff, I decided on the simplest possible rules I thought would produce a playable game. Essentially you only needed to remember to do two things on your turn, move a piece, and place some pegs. (I decided on two.) It was just piece elimination, the easiest possible win condition to explain. I’d playtested variations on each of these rules separately, but never in that combination, and again, always as part of a more complicated ruleset.

I was a bit surprised by how well the game played with those simple rules. The game was played a bunch of times throughout the day, with really positive reception. I think if there is any part of the design I’m still looking for specific feedback about, it’s the victory condition. Capturing your opponent’s pieces is fine, but it doesn’t feel very unique.

Theme

In quantum physics, the term eigenstate refers to the possible movement of a particle. It’s a bit more complicated than that, of course, (and honestly, I have only a slippery grasp on the concept), but once I hit upon quantum physics (and in particular using the uncertainty principal as a metaphor for movement in the game), I began hunting around for suitable quantum physics terms. I think there’s a cool extended metaphor about each of the pieces being particles in a system, and the players competing to observe their opponent’s system first. How moving your own particles (pieces) helps you observe that system is left as a thought exercise for the player.

It’s worth noting that the rules as written don’t really reflect this metaphor, and I’m not sure they will (other than some flavor text) in the final version. As with the idea itself, I know when I came up with the name, on 4/26/2016.

Happy announcement

I am very pleased to be able to announce that Eigenstate is slated for publishing by Adam’s Apple Games. Adam has already 3d printed some additional copies of the game, and it’s being playtested internally. It will probably get a kickstarter later this year sometime.

Playing Eigenstate with Scott Gaff at the 2017 Twin Cities Maker Faire

A Strategy for Abstract Strategy Game Reviews

Today I posted over on Board Game Geek asking for help defining a review system for abstract strategy games. For posterity, here’s the contents of that post:

I’ve been thinking about criteria for reviewing abstract strategy games. In particular, I’d like to end up with a list of ratings, (not just one) that give the reader a sense of how the game plays in comparison to other abstract strategy games.

As an aside, I’m not using the term combinatorial, although I do prefer those games, both because I don’t want to limit the scope of games reviewed to those criteria, and also because I feel the term is hard to understand and explain to someone not already familiar with the nuances of game rules (and abstract strategy game rules in particular). I will certainly indicate the presence of any non-combinatorial elements in the review, and maybe even “at a glance” as part of the rating section. Maybe something like this:
– Number of players: 2
– Luck: Yes/No (If yes, maybe with some details.)
– Randomization: Yes/No (With an indication how.)
– Hidden Information: Yes/No (Again, indicating where.)
– (More needed?)

My goal, to be up-front about it, is eventually to start a new game review site, focused on abstract strategy games. That site’s mission will be: To promote and evangelize the beauty of abstract strategy games.

Here are the criteria I’ve come up with so far:

Strategic complexity – How strategically complex? I.e., how far ahead can I think about my turns with any real expectation of implementing a specific strategy?

Tactical Complexity – How individually complex are each of my decisions in a given turn? How many factors are there influencing my decisions based solely on the game’s state in a single turn?

Rules complexity – How easy is the game to understand and begin playing? How well are the rules written?

Game Readability – How easy is the game to understand at a glance? Can an experienced player take in the game’s state and gauge whether a player’s position is superior or inferior to that of their opponent?

Game Depth – How deep is the game? This could mean a lot of things, but for my reviews, it will mean how much can experienced players be said to be playing at a “different level” from beginner players? Or in other words, how much do the game decisions made by an experienced player change versus the decisions of a beginner player?

Spacial Engagement (Geometric Engagement?) – How much does the game rely on the player visualizing the positions of game elements in relation to one another or in relation to imagined elements?

Mathematical Engagement – How much do mathematical equations or general math principles (counting, etc.) play into the tactical decisions and / or long term strategies in the game?

Originality – Have I seen games like this before? Do I feel like there are new ideas in particular that deserve calling out in this particular game?

Physical Beauty – If this is a game played with standard components, or PNP, it may get dinged here, but since I am attempting to promote abstract strategy games to the general populous, it’s actually a super important criteria.

Overall Elegance – This could be expressed dispassionately as a ratio of rules complexity to strategic depth, but I actually think of it more as an expression of my feeling of satisfaction with that ratio. Did playing the game feel like more than the sum of its parts? Did it inspire me to think about it?

Again, I’m definitely looking for feedback about these. In particular:

– Is there anything obviously missing? Are there other criteria you use when judging a new game?

– How are the names? Any you feel should change or that you feel could be articulated better?

– Is “Overall Elegance” even needed? It’s probably the most subjective, but the concept I’m attempting to capture is just how it feels to play, which is absolutely subjective. Is there a better way to say that, maybe one that doesn’t seem as subjective?

– I’m thinking about doing a scale (probably 1-5) for each of these, and giving the game a score based on the sum total, or possibly an average. Thoughts on that final score?

– Are there other game ranking schemes you particularly like? I’d appreciate pointers to any that break the review down into a list of criteria like this. (I know there are more of them out there, but I’ve only managed to “find” a few links so far.)

This entire thing essentially came about because I was thinking about the term “combinatorial game”, and whether I wanted to use it along with (or instead of) “abstract strategy game”. When thinking about a rating system for Abstract Strategy games, it’s a no brainer to indicate whether there are elements that fans of “pure” thinking games might not appreciate: randomization during gameplay, hidden information, player manipulation, and generally just anything that gets in the way of the player determining their win or loss through skill alone. Generally, this is why the combinatorial term came about. (Although some might argue that it came around the other way, from actual academic game theory, as it was definitely used there first.) But I feel like it was only co-opted by game designers because “abstract strategy” has been used too frequently in the board game industry at large to describe games that are only abstract in theme, and don’t meet the other criteria.

If you visit the wikipedia page for abstract strategy, you’ll see the description carefully adds qualifiers like “almost all…” and “most…” or “many…” when describing the no luck and no hidden information qualities. It’s a controversial term.

I’m partial to the term “abstract strategy” though, partly because I just like its connotations. Abstract thought is one of the things that sets us apart from other species of life on this planet, and has far-reaching implications for humanity and civilization. Not to mention that games essentially wouldn’t be possible without it. In addition to the reasoning I gave in my original post, I also feel that the term “combinatorial” hasn’t reached critical mass yet, and not enough folks know what it means for it to be super useful. (Thus, I went with Abstract Meeple rather than Combinatorial Meeple, though both have a ring to them.)

Back to my thought-process: Indicating the presence of any of those non-combinatorial elements in a review will be easy, but some games that contain one or more of those elements still feel like abstract strategy games to a greater or lesser extent to me. I want to be free to review those games, and also want to communicate that feeling and quantify it somehow in my rating system.

But simply telling my readers that a game “feels abstract” seems too subjective, and also, it won’t give them enough information about whether they might also share that feeling. So I realized I’d need to break it down. Which led to the question: Why do games feel like abstract strategy? This led to my list of rating criteria.

And somewhere in making the list, it occurred to me: All the issues of combinatorial (or not) being equal, I have the same problem when comparing two completely combinatorial games. Other than my personal feelings about them, how would Chess rate any differently from Go? I thought about it some, and that also influenced the list. (In particular, the addition of Spacial and Mathematical engagement.) As it says in the post, I’m definitely looking for feedback on all of this. Feel free to post a comment, or head over to BGG and join the discussion.