As a game designer, I am of course interested in “game systems” both as a concept, and specifically, as objects to own and play. I love the idea that games can be broken down into parts that can be used to compose other games, and I’m always looking for patterns in games that I play that I’ve seen used in other games, and thinking about how to abstract them.
So finding the Everdeck, a card game system meant to map its cards to multiple card game systems, is something that is of interest to me. Incidentally, I think I’d perhaps stumbled onto the Everdeck previously, but it wasn’t until the company that manufacturers my computer keyboard of choice also produced a similar deck, which they call ZSA Cards, and finding that they consulted with Wilhelm Su, who created The Everdeck, that I gave it a second glance.
I have a few stories to tell about card game systems that I’ve worked with:
First off, I did make a few different game designs for the Mystique Deck, a card game system designed and produced by Nestor Andrés, of nestor games. There may have been a contest, I can’t remember, but I designed several games, and at least one of them went into the book that was produced.
Secondly, at some point I had the idea to make a deck of cards for use with the Loony Pyramids game system. My friend August Brown illustrated the cards, and I playtested a bunch of ideas none of which really became “the game” for the system, and then eventually I just posted the PDF on my blog without any real fanfare. Ideally, I would like to formalize a game or two I think is outstanding with the cards, and then approach Looney Labs, but I haven’t done either of those things yet.
Finally, of course one of the oldest card game systems is the 52 card deck, and I have designed several games over the years for that system. Most notably, I published a solo deck-building game for a game contest, and it got a lot of comments on BGG, but I got too busy to really follow-up on most of them, and it was eventually disqualified from the contest for some reason. But I enjoyed that process, and think the game isn’t too bad as/is.
Here are some other card game systems I’ve enjoyed:
The Ell Deck – a deck of letter combinations, by Behrooz “Bez” Shahriari. I backed the Categorickell kickstarter, and was quite happy to finally have the deck in my hands earlier this year. There are 30+ games to play with these simple 2-letter cards.
Nautches – This is a hexagonal game system with a pun in its name (because all the sides have “notches” on them), and if anyone who knows me well heard that description, they would know I needed to own this. I was a little disappointed the deck itself isn’t larger, and that it didn’t come with the rules or ANY supporting materials, but the quality of the cards and hexagonal box is very high. Sadly, there are still only two games using the system posted on the site, but it does lend itself to playing around with different designs, and I’m very happy to own it. I have at least one or two designs for this, and I should probably make a separate post about those, or at least submit them to the Nautches site and see if they get posted.
Pairs – This new-ish card game system was also linked from the ZSA Cards site, and is published by Cheapass Games (and designed by James Ernest and Paul Peterson). There are already quite a few games you can play for it, and my “deluxe” copy (with rules for 30 games) is on its way.
An open source example project (on GitHub it’s called SKHexGrid) for how to use a Swift package called hex-grid to generate hexagonal grids in various configurations.
An easy (and fun?!) way to draw hexagonal game boards.
Here’s some text from the newly re-worked About screen in the application:
There are a couple of other uses imagined for this application (outside of serving as a nice example for the HexGrid library):
You can configure and then Save images of hexagonal grids for use elsewhere. (For example, you might configure a grid for a board game played on a hexagonal grid, save it, then find it in your photos library and print it from there.)
So yeah, I think this first released in the app store back in March of this year (2023), although it had been on GitHub for almost a year now. I’m only just getting around to writing about it.
I guess I took a break from working on it for a while after Blither came out, but I’m back to thinking about it again, and I have a long list of things I want to make it do. You can see that list in the project README, but it’s a big bullet list that’s not really in any sort of order. I’ve written more about this below.
How did this come about?
While working on the app for Blither, I obviously needed to draw some hexagons on the screen. I had done this at least a few times previously, so of course the first thing I did was go look at my old code. The most extensive project with hexagons was of course Catchup (RIP earlier this year :sad:), but when I opened that up, I found that the hexagonal drawing was quite specific to the app, and not really all that extendible to different sizes or shapes of hexagonal grid.
I was disappointed by this revelation, and really wanted to use a library that could draw a multitude of different sized grids without too much extra effort. First-thing-first was to look to see whether such a thing already existed.
When making Catchup (and possibly even before!), I had been aware of the quite extensive tutorial on drawing hexagonal grids written by Amit Patel (Red Blob Games). That website is, as far as I can tell, the definitive guide on the subject. There are even links to other libraries, and it was there, in the Swift section, that I first found reference to the Swift package called hex-grid, that I ended up using for Blither.
So, while evaluating hex-grid, I still hadn’t quite decided what iOS framework/library I would use for drawing. Catchup uses UIKit, and I’ve used that professionally for over a decade, so it’s definitely the one I’m most familiar with. The only demo (at the time) for hex-grid was written in SwiftUI, which is Apple’s hot new declarative UI library, so I spent a bit of time with that, and realized the demo was quite limited. It really didn’t show off most of the features of the hex-grid library. (I’m also not sold on SwiftUI, but I did use it for all the menus in Blither as well as the menus in SKHexGrid, so I guess I’m coming around.)
I was starting to become familiar with hex-grid, and I decided to experiment with using SpriteKit , which is a 2D game engine/framework/library created by Apple. I’ve always avoided it because a) it’s proprietary to Apple, and b) UIKit is plenty capable of drawing a bunch of stuff really performantly, but at the same time, it has some nice capabilities, and I’d never used it before, so… why not?
Before long, I realized my “test” project (which I’d made specifically to easily switch around which grid is drawn) was a much better example of what hex-grid could do, and as I’d been in contact with the developers of that library a bit (mostly creating issues and asking them to add features for me), I showed it to them, and they promptly added it to the README.
One thing I’m really proud of creating for the application is all the different ways you can configure the coloring of the hexagons inside the grid. This is functionality that is unique to SKHexGrid, and not something that comes from the hex-grid project. (This is a candidate for pulling out of this project and contributing to that one, but it just sounds like a lot of work to me.) There are the following options for shading grid cells in the application:
grid shading types built into Hexagon Grid Generator
There is also a random color shading, but I didn’t picture that here. Each of these (aside from single and random color shadings) required their own algorithm, and were pretty fun to write. I only just thought of another shading type that might be fun, so I added it to the README.
What’s next for this project?
I did just yesterday submit the latest version (v.0.4.2) for app store review, so that should come out shortly. In it, I added the ability to draw and configure dots in the center of each hexagon, as well as lines between each of those center points. Just to illustrate, here are some example hexagons showing off those new features:
grids showing the new “center dots”, and “lines between center dots” features
As I said earlier, I have a long list of things I want to make the project do. I’ll just list a few of them, roughly in the order I want to work on them.
I really want to allow you to save the grid that you’ve customized, so the next time you load up the application you can see it again. This will let you toggle between different grids you’ve created, or save a “game in progress” that you’re playing with the app. But the serialization of colors makes it all a bit annoying. (SwiftUI uses a different object for colors than UIKit or SpriteKit, and it’s not serializable for some dumb reason.) I also think Apple’s new SwiftData framework is going to make syncing your serialized hexagon “save files” via iCloud a no-brainer to implement, and I’m kind of eager to play with that, so I might hold off on this feature until that is released along with the new iOS in the fall.
I think the next thing I’ll actually work on is showing coordinates not on the hexagons themselves, but as a sort of “key” along the side of the grid. This is common if you are doing any sort of annotation of your games, and should be highly configurable. Currently the cell (individual hexagon) coordinates are configurable, both in how they are displayed, as well as which coordinate “style” to use. But I’d like to be able to show the “axial” coordinate style both as two numbers (as it’s used in the library), as well as with a single number and an alphabetical character. Additionally, it would be nice to be able to “rotate” which side shows the coordinates, but I’m not yet sure how I would do that, so we’ll see.
After showing coordinates along the edges of the board, I’d also like to be able to show arbitrary colored borders for the entire grid. This is because one of the kinds of game most commonly played on hexagonal grids are connection games (like Hex). In connection games, the goal is to be the first player to have an unbroken group of your own pieces from one side of the board to the other. Or, as in The Game of Y, between 3 sides of a hexagonal board. Incidentally, showing the lines between hexes, makes the kind of board that is typical for The Game of Y possible, because (as in Go) you typically play your pieces on the intersections of lines, as opposed to inside the grid cells.
Anyway, if you’ve read this far, you are probably in the target market for this kind of application, and you should go download it now!
I never have enough time to work on the games that I make. So when I am working on them, I want to stay focused on the game screen, and spend as little time as possible writing the other boring (but still necessary!) screens for the App. Apple’s SwiftUI framework is very easy to use, and if you don’t much care about making things pixel-perfect, it can sure save a lot of time.
I am not yet convinced that SwiftUI is all that great at navigation, however. I feel like I only just got used to coordinators in UIKit (admittedly many years ago now), and maybe I’m still in the honeymoon stage with them or something.
So for my latest game, Blither, and somewhat by extension this open source Hexagon Grid Generator that I released, I’m using SwiftUI for all the straightforward UI, SpriteKit for the “interesting” views (game and grid), and UIKit mostly just for its UIViewControllers.
In Blither, I have a single UINavigationViewController, and a class named AppCoordinator that manages the navigation stack. It looks like this:
public final class AppCoordinator {
public enum Route: Int {
case about
case appIcon
case back
case game
case mainMenu
case newGameConfig
case options
case rules
case stats
}
public let navigationController: UINavigationController = {
let controller = UINavigationController()
return controller
}()
public func navigate(to route: Route) {
if let presented = navigationController.presentedViewController {
presented.dismiss(animated: true)
}
switch route {
case .about:
let viewController = AboutViewController()
navigationController.pushViewController(viewController, animated: true)
case .appIcon:
let viewController = AppIconSceneViewController()
navigationController.pushViewController(viewController, animated: true)
case .back:
navigationController.popViewController(animated: true)
case .game:
if let topVC = navigationController.topViewController, topVC is GameViewController {
// already showing the GameViewController, so pop first
navigationController.popViewController(animated: true)
}
let gameViewController = GameViewController(coordinator: self)
navigationController.pushViewController(gameViewController, animated: true)
case .mainMenu:
if let topVC = navigationController.topViewController, topVC is MenuViewController {
return // already showing the MenuViewController
}
let menuViewController = MenuViewController(coordinator: self)
navigationController.pushViewController(menuViewController, animated: true)
case .newGameConfig:
let configVC = PlayerConfigurationViewController(coordinator: self)
navigationController.present(configVC, animated: true)
case .options:
let viewController = OptionsViewController(coordinator: self)
navigationController.pushViewController(viewController, animated: true)
case .rules:
let rulesViewController = RulesViewController(coordinator: self)
navigationController.pushViewController(rulesViewController, animated: true)
case .stats:
let viewController = StatsViewController(coordinator: self)
navigationController.pushViewController(viewController, animated: true)
}
}
}
That may look like a lot, but if you look closely, almost every switch case is the same. The AppCoordinator instance is created in the app delegate’s standard didFinishLaunching function:
@main
class AppDelegate: UIResponder, UIApplicationDelegate {
/// The root coordinator for the app.
var appCoordinator: AppCoordinator?
/// The main window
var window: UIWindow?
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
let window = UIWindow(frame: UIScreen.main.bounds)
let appCoordinator = AppCoordinator()
self.appCoordinator = appCoordinator
window.rootViewController = appCoordinator.navigationController
window.makeKeyAndVisible()
self.window = window
Blither.setup()
appCoordinator.navigate(to: .mainMenu)
return true
}
}
All of those View Controllers getting created in the AppCoordinator are UIHostingController subclasses, and look almost exactly like this one for the main menu:
public final class MenuViewController: UIHostingController<MenuView> {
private weak var coordinator: AppCoordinator?
init(coordinator: AppCoordinator? = nil) {
self.coordinator = coordinator
let menuView = MenuView(coordinator: coordinator)
super.init(rootView: menuView)
}
@MainActor required dynamic init?(coder aDecoder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
}
If you’ve worked with SwiftUI and UIKit together before, you’ll recognize the UIHostingController, but even if you haven’t, all you really need to know is that MenuView is a standard SwiftUIView, meaning it’s dramatically fewer lines of code to add something like a button. And because it also holds a reference to the AppCoordinator, the definition for a button can look like this one:
Button("Read the Rules", action: {
coordinator?.navigate(to: .rules)
})
When that’s tapped, the coordinator pushes the RulesViewController onto the stack.
If I wanted, I could get rid of the coordinator reference, and do something like this:
…but I don’t like how that looks quite as much, and it also closes the door on dependency injection.
Hopefully you can appreciate how simple this all is! I’ve been pretty happy with how easy I found it to create new screens using this framework. Let me know in the comments or over on mastadon if you have done something similar, as I’d love to hear about similar approaches.
Last week I launched an app for my board game Blither. I’ve written about Blither on this blog twice previously, the first time describing Blither’s rules and a bit about how and why it was created, and the second time talking more about some basic play strategy. I was particularly proud of Blither as a game when I first designed it, and I am still pretty happy with it.
After launching the app, I spent a bunch of last week improving it in a lot of ways, and I recorded a video introducing the app and showcasing some of those changes on Sunday:
As you can see if you watch the video, I was (and still am) especially excited about the “high score mode” (which I’d only finished coding-up that day).
For now, the app is just $0.99 (USD). I’ve got a long TODO list in the project’s README, but I’ve already said semi-publicly that I’d like to increase the price when I hit certain milestones:
I’ll add $1 to the price when I add an actual interactive tutorial (that’s probably next up)
another $1 if I can get the AI up to at least “giving me a challenge” level
and +$2 if or when I add asynchronous multiplayer (almost certainly via GameCenter again)
I’d also like to add some leaderboards for that “high score mode” I mentioned. We’ll see.
I’m working on a playdate game. It’s sort of a mishmash of tile-matching mechanics, and attempts to get the crank working with various ideas I’ve had for square-grid manipulation. I’ve sort of thrown a bunch of ideas together and what I need to do now is decide how I’m going to focus it into an actual game. Currently there are both realtime “action puzzle” levels and also some more discreet puzzle levels that are not really designed so much as some tutorial and proof that puzzles could be designed pretty easily. I’m tempted to write a generator so I don’t have to do any level design, but I’ve gone down that road before, and once I’ve got the generator, I still have to pick levels that seem fun, and that’s usually where I crap out. I’ve mostly been focused on the action puzzle mode, which is what I really want to be the game, but if I’m being honest, I think the other mode seems maybe slightly more fun right now. I think I might try and think of ways to make the levels not be realtime, but still have recursive puzzles.
Playdate game screenshots
As I touched on in my last post, toward the end of last year and into the beginning of this one, I spent a bunch of time building some framework stuff for iOS grid-based games. I only mention this because now I’ve re-built a lot of that stuff in Lua for Playdate dev, which has me thinking lately about how I could re-use it in Pico-8, and maybe also in Love2D. The Love2D aspect is interesting because I could then target/publish back on iOS (in addition to desktops), bringing my development path pretty much full-circle. (I still definitely prefer Swift to Lua though, and have been daydreaming a bit about writing a Swift package that generates my Lua for me… that’s probably silly though.)
But no Unity
After publishing Thrive Digital last fall, I have yet to even install Unity on my new MacBook Pro. I think I may be “done” with Unity as a platform. (At least until I have another VR or AR project, but possibly not even then.) Unfortunately, this means a whole lot of my “in progress” projects are kind of abandoned at this point. That includes remakes of Action Chess and Go Tetris (which I’d been planning on calling Action Go when I do finally finish it), as well as a handful of prototypes and game jam games.
One of the jam games I thought was particularly promising and that I always meant to finish up was called Tetro-Buddies, and it had excellent art by August Brown.
Tetro-Buddies game jam art made with cardboard by August Brown
Also in my Unity “in-progress” folder is Puzzle Prison, a game made for and targeting Google cardboard (no relation to Tetro-Buddies). I more or less abandoned Puzzle Prison around the time the first Oculus Quest came out. It was very near completion for a while, and I should probably have just released it. I actually showed Puzzle Prison at a number of events, and for a while it was my go-to demo whenever I wanted to show off VR on my phone. (It was a 3DoF Chain-Shot clone where the “puzzle was all around you”.)
Puzzle Prison screenshots
I have been meaning to blog about Puzzle Prison for years. I even had an amazing OST made by musician Paths (who was calling himself DR00 at the time). The gameplay was… fine, but nothing special. I had all these ideas for making it more of a unique take, (mostly I just implemented a few additional block types, but I entertained plenty of other ideas) but none of the ideas really improved the gameplay much, and I think that had a lot to do with my never releasing it beyond TestFlight.
Now this article has become more about what I’m not doing than what I am, so let’s get back to that.
And some Action Puzzle game cataloging
The other thing I’ve been spending a lot of time on lately has been action puzzle game curation and Taxonomy. I have a relatively long blog post I’ve been working on, so I won’t go into it here, but of course action puzzle game taxonomy is a topic I’ve written about, and even felt compelled to present about, in the past. One piece of this is that I put together a relatively long list of action puzzle games on IGDB, mostly to make it easier to get feedback from fans of the genre about any that I may have missed or just don’t know about while putting the list together. I think there are a ton missing from the last 10-20 years, and I’d love for this to be as close to comprehensive as possible, but I’m not including any sequels or games that just don’t add anything to the design-space (although of course sometimes that judgement is subjective, so I’m erring on the side of inclusion).
One thing that’s decidedly missing from the IGDB list are smaller indie and hobbyist games. The list started not on IGDB, and the original is more comprehensive, and includes a bunch of iOS games not found on IGDB, a well as Pico-8 games. Of course it is possible to add games to IGDB, but I’m not sure that’s the best use of my time. The Pico-8 curation has been especially fun, because I recently bought an Anbernic RG351V, and have set it up to play all my favorite Pico-8 games, including some excellent Action Puzzle games like Pushamo, PullFrog, Bondstones, Drop Blop, TetraChess, and Sirtet. I definitely feel like I’ve barely scratched the surface on finding them.
Anyway, look for that blog post… sometime soon-ish.
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.
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:
Evaluations: Assessing a position, locally and globally.
Strategies: Global methods and formulation of subgoals.
Tactics: Local methods, generally small scale and short term.
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.
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:
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.
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.
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.
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.
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!
Last week I launched 
