Prototyping Snake Shapes

Posted on by
Snake Shapes prototype app icon

I don’t know that I have ever written a blog post about a game I’ve prototyped before. I mean, of course I prototype every game, but I don’t often talk about games that are in the early phase of development. In this case, I spent a non-trivial amount of time working on a game with the WIP title “Snake Shapes” in December 2021. I don’t think I’m going to spend any more time on it unless I have some big epiphany or something. I don’t know how many games I’ve worked on where I abandon them like this, but there have been a few over the years, I just don’t think I’ve done very much, if anything, to document one of them before.

First, what is Snake Shapes?

The original idea came from an entry in my game design journal on October 15th. Around the end of November, I knew I was going to have most of December to spend on some new game idea, and “Snake Shapes” was just one of many ideas that were competing for my attention. It wasn’t actually what I considered “the best idea”, but it was one that I thought would be “quick and easy” to prototype using a new written-in-swift version of my Generic Game Model (GGM) library.

Anyway, the idea for the game was a turn-based version of Snake, where you try and form shapes (initially just squares) with your tail. This evolved during development a bit to have less emphasis on the actual shapes created. I was going to have a pop-up every time you created a shape, saying how many of that shape you’d created, and giving extra points for shapes that hadn’t been created before. I did not implement that aspect. Every time the snake moves there is something new that gets added to the gameboard. The first 8 are fixed pickups of only two colors, but they are randomized after that, and every 4th thing added is a “wall” square that you cannot move into or through. The game as it is currently is just to get the highest score by eating things and making shapes with your tail until you run out of room to move.

I did spend a bit of time trying to brainstorm different names for the game. I might use the terms “Snake Shapes” and “Square Snake” interchangeably, because I’ve called the project both things, and frequently mix them up. I did also try to entice my 11 year old (who is getting quite good at making art in Procreate) to make artwork for the game, but without any luck.

At some point I had and latched onto an idea that each shape created would boost a counter for “number of power-ups” for a given type of collectible on the gameboard. I thought these would be fixed, one per type, but then I couldn’t decide what all the power-ups should do, so I decided to ask the player which one they’d like after each new square color. I implemented 6 power-ups in total, (which only took 3 days or so, including the popup, which took almost a whole day itself). They are:

  • sort your tail by color
  • remove half the walls on the board
  • convert half the pickups on the board to a random color
  • remove half the pickups on the board
  • clear out a 5×5 grid around your snake head
  • push every wall 1 square away from your current position

Unfortunately, one of the power-ups breaks the game by allowing the player to continue to play indefinitely. Can you guess which one?

Updates to Generic Game Model

I have written a bit a few times about Generic Game Model, but I’m especially proud of a talk I gave about the library to the MN Cocoaheads in 2014. That original version of the library was written in Objective-C, and for at least a year or so, I’ve been working periodically on a new version written in Swift.

Because I haven’t really had a specific project to use it on, I’ve mostly been trying out different things as the mood/whim strikes. For instance, at one point I really wanted it to be a swift package, and you can find a version of it on GitHub that kind of works, but I ran into so many problems using it that way (specifically for Square Snakes development, and while the package is “in flux” so to speak) that I just copied all the files in the project. (I still need to copy the files back out of the project into my package again, as there have been a ton of changes and improvements.)

Another thing I spent extensive time working on was deciding how much to embrace SwiftUI for this iteration of GGM. There’s another repository on Github where I decided to ONLY use SwiftUI, and I abandoned that idea too, after numerous headaches. I think I might know enough now to give that version another go, but I have some concerns (possibly unfounded) about performance, particularly in regards to animation. (SwiftUI does have animatable properties, including offsets and frames, but it was unclear how complex animations would be possible, and animations weren’t the only place I was seeing performance issues, but they may have been my fault entirely.)

What did I really accomplish here?

What am I proud of about working on this game? It’s not really the game idea, frankly. I proved it out, but sadly, I think it’s more fun to play without the power-ups. That said, there are a lot of different directions I could take it, and it could be that it just needs some tweaking in one direction or another to be fun. At this time, I just don’t think I’m going to spend the time necessary to figure that out.

Mostly, the tech was fun to build, and I’ll list some aspects of that here:

  • SwiftUI – It was surprisingly quick to build out new screens with SwiftUI. I used it to build essentially everything outside of the game grid itself, including a bunch of tutorial screens, and a popup that asks you to choose which power-up you want to associate with the color of square you just made. I’m not sure it would work in a “real” app, but I was pretty happy with the structure of the State object that controls all of what is displayed in the Application.
  • Xcode Cloud Build – This was one of the last things I did on the project, but it’s a fun one. It was only a day or so of work to set up the project so that when I push to the GitHub repository, Xcode Cloud will create a new TestFlight build for me using the new changes. It’s kind of amazing that, as a solo-indie developer, I can get continuous integration working on a project in an afternoon.
  • A-star pathfinding – This was actually something that came out of doing Advent of Code (adventofcode.com) in December as opposed to the Square Snake project, but if I hadn’t been working on the project, I am certain I wouldn’t have been as excited about the pathfinding problem. I essentially followed the A-Star tutorial over at Red Blob Games, and had it working in only a few hours. I didn’t really have a use for it in Snake Shapes, but did the work to integrate it with my library anyway, and that work paid off a few days later when I implemented the “push every wall 1 square away” power-up. I didn’t use the A-star itself, but used the PriorityQueue struct that was part of the code written for it.

What could I have done better or differently

This wouldn’t be a good retrospective if I didn’t think about what I could have done differently on this project. To be honest, even though I’m abandoning development, I’m fairly happy with how it turned out. Not happy enough with the game itself that I want to spend any more time on it, but happy with the things I learned and my progress toward making my GGM-swift library a usable tool for native iOS game development. I felt pretty “focused”, and even though what I was building meandered around a bit, I’m pretty happy with how on-task I stayed and the personal growth as a result of the project.

Here’s a few (minor) regrets:

  • I would like to have spent more time on the Tetronimo aspect of the game. As previously mentioned, at some point I decided it would be “too easy” to make shapes other than squares in your tail, and abandoned that aspect of the game idea. That meant I could be exceedingly lazy with the code to detect “shapes” in your tail, and allowed me to abandon one of the aspects of the game I was looking forward to developing. (I have several Unity prototypes that do Tetronimo shape detection, and I was kind of looking forward to porting that code to GGM.)
  • Also previously mentioned, I abandoned SwiftUI for drawing the game squares themselves. Because the library relies on UIKit for this aspect, it means it’s limited to iOS. If I really embraced SwiftUI, it would support iOS, MacOS, tvOS, and possibly watchOS. This is an area I’d still like to spend more time experimenting.
  • I had a TODO in the project to flush out the tutorial views in the app with examples. I didn’t do it because it felt like “work” (in a way that working on the game itself didn’t), but also because I wasn’t sure if I was going to change to using images for the game states themselves at some point, and that might have necessitated re-work. Anyway, the tutorial as it exists now is pretty much the worst kind of tutorial in that it’s just a bunch of text you have to read.

Demo

Demo time. Here’s a video of a couple of play-throughs of the last version of the game, so you can get a sense of it.

2021 in games Played and Created

Posted on by

In 2021 I wrote 73 game design journal entries. Of those, I think I made (or started making) 6 board game prototypes (most notably for Blither, I think), and worked on at least 2 new digital game prototypes. There were 28 entries for game ideas I’d already had or worked on in some previous capacity.

I did only one game jam in 2021, the Global Game Jam.

I also released one game on two platforms in 2021, Thrive Digital, for both iOS and Android.

The played log

This was my third year keeping track of all the games I played. (You can also read my previous year’s posts about 2019 and 2020 if you’re curious.)

I played 319 different games in 2021.

My “played log” boils down to a list of entries per day, with a comma separated list of games, and each game has an associated platform (iOS, Switch, tabletop, etc.). This is the epitome of manual data collection, so I’m just trying to remember to add to the log whenever I play something. Usually after I get done, but sometimes in a batch at some point later in the day.

I added a totally new type of entry this year after last year’s resolution, which is just a single line with a name of a game and a (mini) review. I think in every case it was about something I’d played earlier that day. Before I parsed the log, I was certain I would be disappointed in the number of reviews I wrote because I could only remember writing a few of them, but I’m happy to say that I ended up with 38 reviews!

Top Played Games

I’ll write about some of these individually below, but here’s the top 10 list of games:

  1. Good Sudoku: 365 days
  2. Stone Age: 319 days (33 games, 18 won)
  3. Innovation: 293 days (70 games, 40 won)
  4. Splendor: 215 days (42 games, 26 won)
  5. Race for the Galaxy: 212 days (53 games, 36 won)
  6. 7 Wonders: 200 days (45 games, 15 won)
  7. Flow Fit: Sudoku: 128 days
  8. Roll for the Galaxy: 128 days (43 games, 27 won)
  9. New Frontiers: 119 days (25 games, 19 won)
  10. Picross S6: 106 days

This list includes games I played on Board Game Arena, some of which span multiple days. I think this year I’m going to log games on BGA slightly differently, and only include the names of games that I complete that day. This will reduce some of the tedium of figuring out which turns I just played on BGA (I don’t usually log them until after), but of course at the expense of being able to figure out which days I thought about each individual game, however briefly. Also worth noting that BGA collects extensive statistics itself, and that’s how I was able to see how many of each game I played (as well as the number of victories).

Here’s a list of the top 10 games not on BGA:

  1. Good Sudoku: iOS, 365 days
  2. Flow Fit: Sudoku: iOS, 128 days
  3. Picross S6: Switch, 106 days
  4. AM2: iOS, 102 days
  5. Picross S4: Switch, 84 days
  6. Picross S5: Switch, 63 days
  7. Picross S: Switch, 40 days
  8. Cozy Grove: Switch, 21 days
  9. Genshin Impact: PS5, 19 days
  10. God of War: PS5, 19 days

I’m happy to say I’m no longer playing AM2, and I’m hopeful that next year there will be no clicker or idle games on my top 10 list. (Though I’m not ashamed of checking them out now and then.)

Daily Routine

It’s obviously worth noting I played more games this year than last year. 319 unique games versus last year’s 297. I think one reason for this may be that among the many changes the global (COVID-19) pandemic has wrought on my life is a new and more-regimented daily routine. More so than at any other time that I can recall, I now have a set pattern to my life. (Maybe this is as much attributable to age as it is to the pandemic, I truly don’t know.)

In the morning, I drink coffee and usually catch up on my Board Game Arena games before starting my workday, with breaks for lunch, picking up my kid from middle school, and sometimes a walk with my wife or (rarely) the whole family. Around 6 is dinner, and by around 9:30 or 10 my wife goes to bed and I begin my daily workout. (Don’t worry, this is when my evening games routine begins.)

My workout involves my Apple Watch (the completion of my “fitness circles” is a game in itself), and also a fitness/physical therapy tracking app called PT Timer. The PT Timer app tells me which “routines” need completion. Currently this is: a floor stretch, standing neck stretch, some upper-body strength stuff on M-W-F, and finally a 20-minute-minimum cardio that I don’t use the app to complete, but enjoy “marking completed” at the end. During my cardio (which has a variable length because I try not to stop until the Apple Watch tells me I’ve burned enough calories for the day) I jog in place on a small trampoline in front of the TV… while playing something on the Nintendo Switch. Almost always, it’s some form of Picross.

After my workout, I read a book or some poetry, sometimes play another video game, sometimes do some writing, and somewhere between 11:30 and 1:30, I brush my teeth and head to bed. While I’m brushing my teeth, if it’s past midnight (and it usually is), I do the daily Sudoku problem in Good Sudoku. And recently (well, for the last 125 days) I also do the daily puzzle in Flow Fit: Sudoku.

Good Sudoku

There is an achievement for a full year of Good Sudoku. I should have it, but I don’t. About halfway through the year an update lost my current streak. This was 182 days ago. (My current streak.) I actually emailed the developers about it, and they offered to fix it for me, which I definitely indicated I would be happy about, but then I never heard back from them again. I get it. I’m not great about supporting my apps either. Anyway, this is the only game I actually played all 365 days in 2021. I’m 100% sure Good Sudoku is the first and only game that I’ve ever played every day for a year. Mostly I consider using the hint button cheating, but the Sunday puzzles are sometimes really hard, and if I’ve spent more than a half-hour on it, and am still having problems, I’ll do it anyway. Usually one hint is all I need.

Flow Fit: Sudoku

Flow Fit: Sudoku feels a lot like Sudoku. It’s got tetrominos with numbers in them, and you have to fit them onto a grid such that no number occurs more than once in any row or column. It’s a really engaging game for me, and if the daily puzzle is too easy or quick, I will pretty frequently do some of the other puzzles to fill out my toothbrushing routine. It’s also a frequent go-to if I’ve got some time to kill. So far I’ve done 410 of the 2625 puzzles bundled with the app.

Platforms

I modified the script that parses my game log a bit this year to count number of days played per platform. Last year’s platform numbers were all the games multiplied by all the days they were played. This year’s can tell me both number of unique games played as well as number of unique days. Here’s the full list:

  • BGA – 96 unique games on 346 days
  • iOS – 74 unique games on 365 days
  • Xbox – 40 unique games on 93 days
  • Switch – 34 unique games on 329 days
  • PS5 – 22 unique games on 82 days
  • tabletop – 10 unique games on 12 days
  • steam – 13 unique games on 15 days
  • AiAi – 19 unique games on 2 days
  • web – 8 unique games on 7 days
  • Tabletop Simulator – 5 unique games on 6 days
  • pc – 5 unique games on 11 days
  • Ludii – 3 unique games on 2 days
  • Quest – 2 unique games on 2 days
  • tvOS – 2 unique games on 1 days
  • Blinks – 2 unique games on 1 days
  • Oculus – 2 unique games on 3 days
  • Itch – 1 game on 1 day
  • Mac – 1 game on 1 day

A few observations:

It’s interesting that no Xbox games made it onto my top 10 games list. I managed to find an Xbox Series X even before I got a PS5, and I definitely played a lot of games on it. I subscribe to Microsoft’s Game Pass, which is fantastic for someone like me who likes to try and sample a lot of different games.

My top played game that was definitely on the Xbox was Astroneer (13 days), which I was playing at the beginning of the year. I also played a bit of Deep Rock Galactic (11 days) with my friend Angela, as well and Path of Exile and Sable tied for 10 days playtime each. I finished Sable, and really enjoyed the experience. I’m surprised it was only 10 days, because I became a bit of a completionist about it, not wanting the experience to end.

It’s also interesting to me that BGA and iOS are kind of both leaders, since I played games on iOS more consistently than BGA. Frankly, I’m rather surprised there were 19 whole days I didn’t play any turns on BGA.

I like calling out Stephen Tavener’s AiAi. 10 of the 19 games in the log were the ones I reviewed for the BEST COMBINATORIAL 2-PLAYER GAME OF 2020 competition, but I know I opened up AiAi more than just a couple of times this year to try out various games I saw show up in his announcement thread. AiAi has become an incredible resource for playing abstract strategy games, and Stephen is able to add them at a simply incredible pace.

I called AiAi the platform when I could have just said I played these games on “PC” or desktop. I did already manually “roll up” a bunch of different ways of saying “web” into that category (as opposed to “browser”, “puzzlescript”, or just a plain URL.) If I add up: Steam, AiAi, pc, Ludii, Itch and Mac, I get 42 games & days, 47 if you include Tabletop Simulator. But that’s not quite right because of course some of those days might have been the same between the different platforms.

I’m pretty convinced I forgot to log some VR plays. There’s no way that I only used my Quest 2 on 3 days last year. I can actually think of 3 days off the top of my head, and I’m sure there were some days I used it in my living room as opposed to getting together with my friend Nate in the park, or the only in-person VR meetup of the year (also outdoors) where we played the new Space Pirate Trainer “Arena Scale”. Still, it’s worth noting that I didn’t use VR very much in 2021.

I was surprised to see that I played 15 different tabletop games across 18 days, so I decided to dig into the data. Turns out, I am deliberately only taking the first word when I parse the data for platform, and I had a bunch of entries where the platform was “tabletop simulator”. I fixed those entries manually and the actual numbers are displayed above. I did play more tabletop games than expected, given how seldom I went anywhere outside of my apartment this year.

Reviews

As mentioned previously, I wrote 38 game reviews, but they were all very short and casual, and several of them (3 to be exact) were second reviews of games I’d already written about before. Those games were Astroneer, which I wrote about twice in January, Ori and the Will O’ the Wisps (in February), and Shapez (in August). Also, it’s worth noting that 10 of those reviews were written over two days for the previously mentioned Best Combinatorial Game of 2020 competition. I can’t really decide if I want to publish these anywhere. They’re written a lot like my goodreads reviews, which is to say that the audience is definitely “future me”, as opposed to “anyone else”. I usually just say something short about what I felt the game was about, as well as anything unique or interesting I observed while playing. And of course I say something about whether I enjoyed the experience.

Wrap-up

I sometimes do wonder if there’s any point to the game log. It feels… kind of narcissistic to keep track of all my game playing. But being able to write this post (and have these introspective insights) definitely feels “worth it” to me, so I have no plan to stop. (And feel a renewed vigor for the project as I write this.)

I’d like to do more releasing of games in 2022, but I’m not going to hold myself to that too strictly. It’s more important that I continue to enjoy creating games as much as I enjoy playing them.

Happy new year everyone!!! Here’s to playing (and making) all the games in 2022!

Blither Heuristic Notes

Posted on by

Note: If you haven’t already, you’ll probably want to read my original blog post introducing Blither before you dive into this one.

What’s a heuristic?!?

I promised to write up some “strategy notes” for Blither, but then yesterday I read this excellent article by David Ploog about Abstract Strategy game Heuristics, and had the revelation that most of the advice I’d already written would not actually be in the realm of strategy. Ploog lists 4 types of Heuristics: Evaluations, Strategies, Tactics, and Patterns. To quote:

  1.  Evaluations: Assessing a position, locally and globally.
  2.  Strategies: Global methods and formulation of subgoals.
  3.  Tactics: Local methods, generally small scale and short term.      
  4.  Patterns: Specially denoted moves or structures on the board.

I think most of the advice in this article falls into the category of Evaluations. How to read the board, and what to look for that might be an advantage to you while playing. (Possibly some of it will drift into the realm of Tactical decisions.)

Caveats

It’s a new game still, so I can’t promise these are all anything more than tips for beginners. It is also certainly possible that someday this post will only serve to prove how terrible I am at playing my own games.

It’s worth noting that I haven’t played that many games of Blither, although probably more than anyone else at this point. (A few dozen at most.) It’s also possible that some of the tips here are circumstantial, and don’t apply in situations that I haven’t considered yet.

More than anything, I hope this post will give you a sense of what a person could be thinking about while playing the game, and whether that appeals to you. To that end, I’ve also included an example game at the end of this post, and I’ve attempted to annotate it with my reasoning for each move.

Tip1: Try to maximize your liberties

In Blither, you capture opponent’s groups by surrounding them, so you want to be sure to leave your pieces with the maximum amount of empty spaces, or liberties, around them. As with Go, I’m certain that higher-level play will involve some amount of counting empty spaces around your pieces. Fortunately, the small board means the numbers are never very large, and it’s not the counting that is difficult, but anticipating what your opponent will do.

Designer note: Initially, Blither was designed with a hex6 board. Only a few games were play tested on that size board. It just felt like hex4 let you get to the “meat” of the game faster.

Blither, liberties illustrated

Tip 2: Move into the center early

Corner spaces only have 3 liberties. Edge spaces only have 4. But a space in the middle of the board has the potential for 6 different empty spaces around it. For this reason, you should only play on the edges of the board when it’s giving you a strategic advantage to do so. (Or at the end of the game when there aren’t any other options.) Leaving a piece in the corner is even more dangerous.

Tip 3: Pieces are stronger in larger groups

Because your own pieces also remove a liberty, it only makes senes to play next to your own pieces when they are of the same type, which does increase liberties for the entire group. But unlike most games with surrounding capture, in Blither, you can actually move away from surrounding pieces. Ideally, strive to maintain any group connections when doing this, however.

Tip 4: Try to position pieces next to open spaces of their own type

The reason for this is one of the things that (I think) makes Blither interesting. It is possible to move a piece onto its own type, and either 1) place the resulting new piece back on the original space, or 2) place the new piece elsewhere, thus migrating the piece that moved. Because, the original piece is now on a matching space, it has no immediate movement opportunities to another matching space, but the newly placed piece, assuming it was placed next to that original piece does have that potential. Toward the end of the game, there’s often a period where you wish you could move onto a specific shape, but you just don’t have that potential. Keep in mind what shapes your opponent wants to place as well, and try to deprive them of those types of move.

Tip 5: Your pieces types that have been captured are now safe

I don’t meant that those types can’t be captured again, but rather, if they are, your opponent is no closer to winning the game as a result. This means moves that were previously too risky are now a little more acceptable. The previous tip about keeping your pieces in a single large group can safely be ignored.

An Example Game

As promised, here’s an entire game, illustrated and annotated. This took way more time than I intended, and I got a little rushed at the end. Please let me know if you see any incorrect moves or if anything is unclear.

Thrive is out for iOS, Android is still forthcoming

Posted on by

Update: Thrive is live now in both the iOS AND Android app stores.

First the good news – Thrive, the digital version, has been released for iOS. It’s available now, and you can find it in the iOS App Store.

https://apps.apple.com/us/app/thrive-board-game/id1528236222

You can also find it by searching for my name “Martin Grider”, or “Thrive Board Game”. (If you search for “Thrive”, you won’t find it, maybe it’ll start showing up in search results after some folks have bought it, who knows.)

I would very much appreciate your purchases and reviews!

Now the bad news: I thought I was prepared and ready to release the Android version simultaneously on the Google Play Store. This was going to be my first simultaneous app store release EVER, and I was very excited to make it happen.

Sadly, I ran into unforeseen issues, and all I was able to make live is the store page itself. You can wishlist it there, and hopefully it’ll be live in the next week or so:

https://play.google.com/store/apps/details?id=com.AbstractPuzzle.Thrive

Back to the good stuff: This release features a full interactive tutorial for learning the game, 3D graphics that I hope are close to the actual physical product, and the ability to play two-players on the same device. Probably most importantly, it also includes an AI player to play against. But my favorite feature that made it into this release is that it also has the “variable setup cards” from Pond Life, so you can very quickly and easily jump into a game with different setups and peg layouts.

I hope you enjoy it!

Blither – An Abstract Strategy Game

Posted on by

Blither is a simple capture and territory game for two players.

Setup

Each player takes all the pieces of one color. 

Players place one piece of each shape along the two sides of the gameboard closest to themselves, with the only restriction that no piece should start next to any other pieces.

Choose a starting player.

Goal

Players are trying to capture groups of their opponent’s pieces. The goal is to be the first to have captured at least one of each of their opponent’s three piece types.

Gameplay

On a turn, the player moves one of their pieces already on the gameboard one space to an adjacent unoccupied space. After they move, the player must add a piece from their supply matching the type of the space they moved onto, placing it onto any unoccupied space on the gameboard.

Finally, all of their opponent’s groups are evaluated (each type forms a different group), and any groups that have no liberties (empty spaces around them) are removed from the board. The capturing player keeps one of each type of piece that was removed, displaying it clearly on their side of the board. If a player has one of each of the three types of their opponent’s pieces, the player immediately wins the game.

Example Move

In this first move of the game, the Red player moves their Star piece onto a Square space on the board. They then choose any space on the board to add another Square piece.

Example Capture

In this example, the Red player is moving their Square piece onto another star space on the board (next to the Blue player’s group of Circle pieces). They will then add another Star piece on the space indicated, after which the Blue player’s group of two Circle pieces will have no empty spaces around it, and both pieces in the Blue Circle group will be removed. The red player will keep one of the Blue Circle pieces and display it on their side of the board.

Extra Stuff

Inspiration

Blither was inspired by the Abstract Games Magazine Unusual Board Spaces Game Design Competition, specifically, by the game Hox, which is described as an example for the competition. It was also inspired by Blooms, by Nick Bentley, and Slither, by Corey Clark. Mechanics from both games have been adapted here, and the name Blither is a portmanteau of the two. I am especially happy with this design because, at least to me, Blither also feels like both of those games.

Online Play

You can play Blither on Tabletop Simulator here: https://steamcommunity.com/sharedfiles/filedetails/?id=2492141466 This is actually my first Tabletop Simulator mod, and I’m pretty happy with how it turned out. It doesn’t do anything especially fancy though.

Watch it played

You can watch a game of Blither on YouTube from when it was played as part of the Twin Cities Playtest event in May 2021. I do also introduce the game and the rules before they play.

A screenshot from Blither played in Tabletop Simulator on YouTube as part of the Twin Cities Playtest event in May 2021.

About the Components

The number of pieces of each type is not meant to be limited. But in practice, I have not seen a game where any player used more than 14 of one piece type. (That said, I haven’t seen that many games yet.) It would of course be theoretically possible to use many more than that. I have played a game or two with a limited number of pieces (9 of each type), and that seemed to go okay as well.

I have spent some time working on 3D printed components for a physical version of the game, but I haven’t finished printing them out yet.

Why is it interesting

If you’ve played Blooms and/or Slither, you already know why those games are interesting. Briefly, here are my takes:

Blooms feels like an expanded version of Go, both because it’s on a hexagonal board, but also because there are four colors in the game. (Each player owns two of them.) The choice of which color to place is an expansion of the decision space in a similar way to how there are additional liberties for each board space. (There are 4 in Go because it’s a square grid versus 6 in Blooms because it’s played hexagons.) I am by no means an expert Blooms player, but my impression is that you must analyze each color’s liberties alone as well as in tandem with your other color, which is more than just double the thinking, but fortunately, the board is much smaller overall. Abstract Strategy Games magazine had a feature article on Blooms (and hexagonal Go in general) in their 20th Issue, and I do recommend it.

Slither is a very interesting version of a connection game because you get to move your pieces. As a connection game, the goal is to form a connected group of stones from one side of the board to the other. But because you get to move your pieces, (and the name is particularly apt here), those lines of stones end up slithering around the board over the course of the game. In Slither, you move a stone, and then place a stone, (although unlike Blither, the move is optional). This is, of course, an expansion of the decision space of a traditional single-placement connection game (Hex is probably the most well-known) because the movement opens up many more possibilities for connection in a single turn. David Ploog has written a nice article about Slither that introduces the rules and goes into more depth on why the game is interesting.

Blither combines some of the mechanics of both Blooms and Slither. But I’d argue it does so in such a way that expands the decision space in a similar way to how both of those games expand the decision spaces in respect to their direct predecessors. In terms of how it feels to me to play Blither, I’d argue that Blither is to Blooms what Slither is to Hex.

Blooms and Go and Slither and Hex are all in a family of abstract strategy games that connoisseurs of such games refer to as combinatorial. Combinatorial games are games for 2-players with no reliance on luck or hidden information. Some definitions say the game also has to be finite (meaning it can’t end in a draw). People who value combinatorial games also tend to value the following game attributes: elegance and simplicity. I could definitely write an entire article about just the previous sentence, but I won’t go into detail about what that means just now. Blither is combinatorial, but it might be that the number of components (hopefully not the number and complexity of the rules) is beginning to impinge on its claim to elegance and simplicity.

Right now, I feel like Blither is one of the better games I’ve designed. I hope you’ll give it a try.

UPDATE (2021-12-07)

I updated the rules explanation in this post to my current favorite version (v1.1). Also added a couple of visual examples.

Features and Considerations for Digital Board Game Conversion

Posted on by

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.

Xcode tips and keyboard shortcuts

Posted on by

I love working in Xcode. It was my first “real” IDE experience, and while I still use vim pretty regularly it’s generally not for editing code (anymore). These days, whenever I’m not working in Xcode (lately it’s almost always Visual Studio on Unity projects), I’m wishing I was.

I read iOS Dev Weekly (https://iosdevweekly.com/) most weeks, and it was via that lovely resource that I discovered this great GitHub page full of Xcode-Tips (https://xcode-tips.github.io/). I already helped include one tip there (about enabling spell-check), and this post is inspired by one of the tips I found there in particular, about using `cmd-shift-j`. 

Xcode is a 3 panel layout. The middle panel where you actually edit code can be split up in a number of ways, (tabs within tabs? c’mon), but I won’t go into that in this post.

The left panel is called the “Navigator”. It has tabs across the top and defaults to the first tab, or “Project Navigator”, showing all the files in your project hierarchy. 

  • Filesystem tip/aside: When I first started using Xcode I was surprised to learn that files presented here are not necessarily 1-to-1 with the files on the filesystem. On one of my current projects, we are using the awesome open source XcodeGen (https://github.com/yonaskolb/XcodeGen) to generate the project from files on the filesystem. It’s actually called from a script that we run from a git checkout-hook, so we almost never have to think about it. This was a new-to-me workflow, but has a lot of benefits, including keeping the project files consistent with the filesystem!

Keyboard shortcuts relevant to the navigator:

  • Hide (or show) the whole Navigator pane with `cmd-0`. (That’s a zero.)
  • Jump to any of the tabs in the navigator with `cmd-<number>` where number is the index of the tab. So `cmd-1` opens the Project Navigator. This works even when the Navigator is hidden!
  • Best of all, the aforementioned `cmd-shift-j` will open the Project Navigator and select the file you are currently editing. You can then use the up or down arrows to browse different files, and `cmd-j` and then `enter` to return to the code editor.

The panel on the right side of Xcode is the Inspector. It too has tabs, and what’s great is that the keyboard shortcuts are very similar to the ones for the Navigator, but with the addition of alt:

  • Show/Hide the Inspector with `cmd-alt-0`.
  • You can also jump to one of the tabs with `cmd-alt-<number>`, again, where number is the index of the tab. What’s interesting here is that there are a different number of tabs here if you are editing an interface builder file. (I don’t think I’ve ever used these shortcuts.)

In general, I am far more likely to want to hide the Inspector pane than the Navigator pane, so it’s kind of a shame the shortcuts to show/hide them aren’t reversed (not to mention the fact that cmd-alt is a difficult combination on my Moonlander keyboard, but of course I could fix that).

I wrote this up in part so I can create another PR and reference myself as the source for a tip about showing and hiding these panes, but this post was also inspired by sharing with another member of my team that I do the majority of my development on a MacBook, without external monitor. <insert scream emoji> One of the aspects that makes that experience tolerable are all these keyboard shortcuts that let you maximize the space you’re using to edit code quickly and easily.

I hope you learned something from this, but if you didn’t, go check out that Xcode-Tips site, because you’re sure to learn something there!

Played Log 2020

Posted on by

I kept up my played log through 2020, and I ran some analysis again this year.

One thing to note is that I don’t think it’s as valuable as my (admittedly quite brief these days) goodreads book reviews. I’ll be looking for a way to maybe improve on that this year. (Maybe writing periodic reviews of games I’m playing?) Games seldom have the same finality that a book does. Usually my interest wanes or is diverted to other games, and I just stop playing them without reflection. So knowing when to write the review would be maybe the hardest part! One option is to write something down any time I play a new-to-me game. I might try a few different things.

Stats and Observations

Again, not a day went by without at least a game or two played. There were 297 unique games logged. (Although there is probably a statistically significant number of those that are misspellings or differently-worded versions of the same game. 186 of those games were only played on a single day.)

Here are the top ten games played with the number of days that I played them:

  • stone age: 189 
  • good sudoku: 162
  • go: 158
  • innovation: 147
  • blooms: 73
  • animal crossing: 67
  • teotihuacan: 55
  • thrive: 52
  • hive: 40
  • pixelpuzzle: 37

This is definitely a skewed list, because for most of the board games on that list, I was playing async games on BGA. This means, most of those days I didn’t actually finish the game, only played a turn or three. 

The only real surprise on there for me was Hive. I didn’t really think I’d played that many games of it, and I also think of it as a relatively fast game to play. So I did some digging, and sure enough, when I look at my BGA profile, I only played 13 games of Hive, it just took me 40 days to play those games. Amusingly (and so coincidental that I’m rather skeptical of BGA’s statistics), I also finished exactly 13 games of Go, AND 13 games of Stone Age.

Here’s a top ten list of games not on BGA:

  • good sudoku: 162
  • animal crossing: 67
  • pixelpuzzle: 37
  • diablo 3: 27
  • forager: 22
  • satisfactory: 20
  • picross s4: 19
  • picross s3: 19
  • i love hue too: 18
  • hades: 17

Obvious if you look at the numbers, I played a lot of Good Sudoku. I do highly recommend it, especially if you are interested in getting better at sudoku puzzles, or anyway learning additional techniques for solving them. There are three daily puzzles, and the app keeps track of your “streak” for each. I am currently on a 97 day streak for the main game mode. There’s some kind of comparison to be made with the desire to keep up my streak and a sunk cost fallacy. Opening this app is typically the last thing I do before bed, and often the first thing I do when I wake up. 

I was surprised to see PixelPuzzle in this list again. I finished all the puzzles last year, but there is a games+ kind of thing going on. I didn’t play Picross nearly as much as last year because I totally fell off doing my workouts when covid quarantine hit. (I was no longer going to the workout room in my building and doing the elliptical with a switch strapped to the machine.)

I’m happy to report that I did eventually resume daily workouts, (but not until November). Now in my living room. Still playing the Switch tho, it’s hard to hold a traditional controller and do any actual movement.

I only started playing Hades in December, so the fact that it made the list at all is pretty impressive.

I also tracked what platform I played the game on, and here’s the number of entries for each platform. (Note that I usually have 5-10 games going on BGA at once, and typically take my turns two or three times a day, but I would only count each game once per day, but if I played 5 games on BGA, that would count 5 times for these numbers.)

  • bga: 1050
  • ios: 319
  • switch: 258
  • pc: 70
  • web: 20
  • xboxx: 14
  • ps4: 14
  • quest: 8

Nintendo weighs in

Those of you with a Nintendo Switch probably recognize the screenshot above as coming from Nintendo’s year-in-review email. I was not terribly surprised to have played twice as many hours of games as in 2019, but I was surprised that it was fewer games in total. My guess is just that spending more time playing (due to pandemic quarantine) led to getting more sucked into a few games in particular.

About the log itself

Two things of note: the first is that I was much more rigorous with keeping up the same format for each day of the log this year. So parsing the log didn’t involve any data “fixing” at all, which was fantastic. (In pretty sharp contrast to last year.)

Secondly, I wrote the log parser last year in python, and while it was perfectly serviceable, when I went to run it again this year, I wanted to do some additional analysis. It was daunting enough looking at last year’s script that I just re-wrote the entire thing in Swift. I spent at least a few hours over the course of several days on the python script last year, and I did this year’s Swift version in about an hour. I’m crediting advent of code for how easy it went. 

Worth noting I only made it through day 18 of Advent of Code, but I just realized I only put it in my game log a few of those days. If I’d put it in all the days I actually did it, it would have edged out Hades in my top 10 played list!

Blinks 3D Printed “simulator”

Posted on by

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

Posted on by

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)