How Blither uses the coordinator pattern and SwiftUI together

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:

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
        self.window = window


        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 SwiftUI View, 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:

                Button("Read the Rules", action: {
                    (UIApplication.shared.delegate as? AppDelegate)?
                        .appCoordinator?.navigate(to: .rules)

…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.

Blither for iOS

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.

2022 in Games Played and Created

2022 was the 4th year in a row that I kept track of all the games I played. This is the 4th recap I’ve written on or around new year’s, and I’ve only just created a category for them if you care to go have a look back through the others. I hope to keep up this tradition as long as I’m alive. But no pressure.

My Games Played in 2022

I won’t write so much this year about my method of keeping track. Suffice to say, it’s a “manual” collection, so obviously it has its flaws.

First, the numbers.

  • unique game titles: 352
  • days I logged at least one game played: 365
  • game titles logged only once: 193
  • journal entries about specific games: 30

Top 10 games

(by number of days they show up in the log)

  1. Flow Free: Sudoku: 244 days
  2. Good Sudoku: 186 days
  3. Picross s7: 144 days
  4. Picross s8: 83 days
  5. Picross s genesis: 67 days
  6. 7 wonders architects: 55 days
  7. New Frontiers: 49 days
  8. Jump Drive: 49 days
  9. Innovation: 49 days
  10. Azul: 41 days

Top 10 games, including platform, without BGA games

(…and making a special check for days I played Picross.)

  1. Picross (Switch): 297 days
  2. Flow Free: Sudoku (iOS): 244 days
  3. Good Sudoku (iOS): 186 days
  4. Elden Ring (PS5): 35 days
  5. Cell to Singularity (iOS): 31 days
  6. Really Grass Cutting Incremental (web): 29 days
  7. Vampire Survivors (Steamdeck): 23 days
  8. Jetpack Joyride 2 (iOS): 18 days
  9. Borderlands 3 (PS5): 18 days
  10. Horizon Zero Dawn (PS5): 14 days


I stopped playing both Good Sudoku, and Flow Free: Sudoku after getting the “played for 365 days in a row” achievements. I don’t expect either of them to show up on next year’s list. Obviously this list has a lot of Picross in it, because I still mostly just play that when I’m doing my 20-40 minutes of cardio in front of the TV. I do let myself skip the workout on occasion, and it’s definitely more likely if I’m feeling sick. I think that explains most of the days I didn’t play it.

[Update/Addition on Jan 2nd]

My friend August asked “Do you have a favorite game this year and why is it Picross?” I realized that kind of analysis is maybe something this post was missing, so here is my response.

I do love Picross, but I’m not sure I’d even put it in a top 10 list. It’s my go-to workout game because it fires all the brain cylinders (meaning my workout passes without the clock-watching that ensues otherwise), and does that without any need for spacial awareness that can cause me to fall off the trampoline.

My favorite of the games I played in 2022 is probably Elden Ring (35 days, PS5)  just because of how sucked-in I became even as I lambasted it. I wrote several journal entries about it, and ended up loving it in the end, even as I reached a saturation point where I decided I never need to play it again.

I also loved Stray (9 days, PS5) and Horizon Zero Dawn (14 days, PS5), both of which I played to completion in 2022.

Probably my favorite indie game of the year was Tinykin (2 days, Xbox). Super interesting that my log only shows that I played Tinykin on two days! I definitely beat the game, and even remember stretching out my playtime by intentionally veering toward completionism toward the end. (I may have just forgotten to log it some days? Or maybe it really is that short.)

I also really liked Nobody Saves the World (10 days, xbox).

I did have a phase this year post-steamdeck where I got back into action puzzle games, and played a lot of those for a few weeks. Notable favorites are Lumines (8 days), Petal Crash (7 days), and Mixolumia (6 days). I only logged Tetris Effect on 5 days (probably during that same period). Note that none of those games were “new to me” in 2022 except for Petal Crash. Just like books, I tend not to return to games unless I remember really loving them, so those are all favorites.

Platforms by number of games

  1. BGA – 80 games on 231 days
  2. Playdate – 56 games on 54 days
  3. iOS – 53 games on 310 days
  4. Steamdeck – 46 games on 90 days
  5. Web – 30 games on 43 days
  6. Tabletop – 23 games on 31 days
  7. Xbox – 20 games on 69 days
  8. PS5 – 13 games on 84 days
  9. Pico-8 – 12 games on 8 days
  10. Switch – 11 games on 298 days
  11. Quest – 7 games on 7 days

Platforms by number of days

  1. iOS – 53 games on 310 days
  2. Switch – 11 games on 298 days
  3. BGA – 80 games on 231 days
  4. Steamdeck – 46 games on 90 days
  5. PS5 – 13 games on 84 days
  6. Xbox – 20 games on 69 days
  7. Playdate – 56 games on 54 days
  8. Web – 30 games on 43 days
  9. Tabletop – 23 games on 31 days
  10. Pico-8 – 12 games on 8 days
  11. Quest – 7 games on 7 days

Platform Observations

Poor VR. I never pay attention to it anymore. (I didn’t even preorder the PSVR2… I’ll buy it if it looks like any of the games are going to be amazing, or if they suddenly give it backward compatibility with all the OG PSVR games.)

I was really excited about the Playdate for a while there. I’ll talk a little more about that later. I’ll probably get back into it again if they release a Season 2 of games.

The Steamdeck is now my favorite gaming platform. I don’t have any free HDMI ports on my TV, or I’d be playing more of it there, probably, but in the mean time I do very much enjoy it as a handheld. It obviously helps that I have a library of over a thousand games to choose from on it. (Built up over years and years of bundles and various sales, but also I feel no qualms about paying “full price” for any game that I feel moderate confidence I’ll find the time to play.)


Board Game Arena was where I did the majority of games playing this year. My game log says 80 games (unique titles) played on 231 days, which is obviously wrong on both counts. I was initially surprised it wasn’t more days, but then I realized that’s definitely a consequence of how I’m doing my logging. I currently only log BGA games on the day they have been completed. This means if I play a single game (of Azul, for example), but the turns stretch out over a week, it would only get one entry, even though I played my turns every day. Last year I logged every day that I took any turns in that game, but it was too much logging, and I felt like it gave too much weight to async games.

For 2023, I’m definitely going to change it up again, but I’m not sure exactly how. I might actually just log that I played some turns on BGA, and not worry about what games. Or maybe I’ll try and just log any game that I’ve not yet logged that year, so I have a complete list.

It’s definitely less important, because BGA does a great job keeping track for me. You can see all my BGA stats at this link:

  • BGA “tables” (total number of games played): 614
  • Games won (victories): 328

BGA Most played games

  • 7 Wonders Architects: 77 games
  • Jump Drive: 62 games
  • Innovation: 55 games
  • New Frontiers: 51 games
  • Azul: 47 games
  • Splendor: 38 games
  • Stone Age: 22 games
  • Space Base: 18 games
  • Race for the Galaxy: 16 games
  • King of Tokyo: 15 games
  • 6 nimmt!: 15 games
  • Gizmos: 15 games
  • Nova Luna: 10 games
  • Oust: 10 games
  • Caverna: 9 games
  • Thrive: 9 games

Caverna and Gizmos get special shout-outs, because both showed up relatively late in the year. Gizmos is definitely in my top 10 games right now, and when it first showed up on BGA, I was playing so many games of it that I kind of burned out on it, and had to stop for a few weeks. Now I’m back to a regular game or two of it going at all times. Same with Caverna, though it’s not as high on my want to play list, it seems like it is for everyone else I play BGA games with on the regular.

I think 7 Wonders Architects and Jump Drive are only at the top because they’re very short games, and my friends Mike and Jason both like 7 Wonders a lot, so we have a continuous game going with the three of us, and we finish a game once or twice a week, I’m guessing.

My Game Design Journal in 2022

My game design journal had 40 new entries in 2022. (Sadly there were 4 months with only one entry, including December. And 5 months with only 2 or 3 entries.)

Of those entries –

  • 2 were from dreams (providing some evidence my subconscious is still thinking about new game ideas, even when my conscious mind can’t be bothered)
  • 11 were continuations – additional thoughts or implementation notes related to previous ideas

And the most disappointing stat:

  • only 1 entry resulted in a new (digital) prototype

There were a few entries that could have been flushed out into new physical game prototypes, but my guess is that I played physical games much less this year than in the past. (Although 31 days doesn’t seem like that few, tbh.) Anyway, I think a significant percent of my interest in designing physical games has waned with the realization that I just don’t play games physically that often anymore. This is a bit weird, because I play digital versions of physical games literally every day, but it’s something I’m pretty sure my brain is doing.

Game Development

My current work schedule allows for somewhere between 3 and 12 hours spent working on games per week. When motivation is low (as it has been most of this year), it’s usually on the lower-end of that range.

Mostly, I spent this entire year working on a digital version of Blither, an abstract strategy board game I designed a couple of years back. I’m happy with Blither’s design, and a few times I’ve considered trying to hand it off to publishers. I think it could work particularly well with some kind of animal/nature theme, but so far at least, the digital version is just all geometric shapes.

Swift for Game Development

A significant amount of the effort that I’m counting toward Blither’s development has actually been spent less on the game itself, and more on the toolchain for writing games in Swift. I spent several weeks – maybe as much as a month of my development efforts – just exploring cross-platform strategies for Swift and game development. The primary take-away is that it is relatively “easy” to write a swift “wrapper” for projects written in C, so there are many. Of interest, both Raylib and SDL (both of which exist in the cross-platform game development “space”) each have at least a few of these projects on GitHub. Unfortunately, while it is easy to write these wrappers, getting them to a state where they are easy to use requires more effort, and in my estimation, that narrows the selection considerably. “Easy to use” might be assumed to include “well documented”, but sadly it does not, and none of the projects I found would qualify there. Furthermore, lack of documentation definitely means lack of instructions for how to actually publish a project using any of these libraries across various platforms and OS targets. For a while, this was definitely my objective. Pick a lib, write a simple game, and document the hell out of getting it running on at least: MacOS, Windows, iOS, and Android, using the same codebase.

Unfortunately, of the aforementioned Raylib and SDL library wrappers, Raylib itself doesn’t support iOS (at least without plugins/modifications), and SDL is slightly more difficult to use, and possibly as a consequence, in general the wrappers I found for it were not as far along, or anyway, not as easy to use.

Another related project is re-writing my generic game library in Swift. There was never all that much code to GGM, so the actual rewrite was never the hard part. The original GGM used UIKit for rendering, so there is a Swift version that does that, but also now there is a version that uses SpriteKit, and a (not-quite-flushed-out-yet) version written in “pure Swift” without any rendering included. Ideally, I’d use that version to write “plugins” for platform-specific rendering engines, and this could be another path to writing cross-platform games. That last version, while unfinished, is already significantly more code than the others, and I got a bit hung up on what its internal API should look like. The other versions don’t really concern themselves with non-game UI, but this one would have to, and that’s a big old can of worms that I’ve barely opened.


Speaking of GGM, the original library supported hexagonal grids – it was used for the Catchup app – but the way it implemented them was very specific to the Catchup codebase, and felt a bit tacked-on. So when I went to add that detail to GGMSwfit, I got sidetracked a bit on what hexagonal grid coordinate types to support, and how many hexagonal grid shapes to make it easy to create. I dug around a bit, and ended up playing a bunch with a “pure Swift” library called Hex-Grid ( that does pretty much all of the hexagon-specific stuff that I wanted GGM to do, and I contributed to that library a bit. Mostly, I wrote a demo app that uses SpriteKit and allows you to visualize grids of arbitrary size and shape and swap out their coordinate types on the fly. (This also helped expose a few bugs in the lib.)

The current app version of Blither doesn’t use any flavor of GGM, instead it uses this Hex-Grid library, and it is also using SpriteKit for drawing. This means it can only target platforms where SpriteKit exists. (iOS, iPadOS, and MacOS, I believe. But – so far at least – I would need to make some not insignificant changes to make Mac Desktop work.) I’m still toying with the idea of making an abstraction layer for the SpriteKit-specific code, so code could be shared with other platforms.


Another project I worked on this year was a match-4 game for the Playdate called Matching Machine ( I “released” a version on the Playdate developer forums and then promptly lost interest in finishing it up. This year’s MinneBar happened while I was working on it, and it was the first time I’d been to an in-person conference in a few years. I gave a talk there about Playdate development in general.

Non-Game Development


MinneBar was great (as usual), and while my family is under no illusions that the COVID-19 pandemic is over, I still ended up going to two other in-person conferences this year: Eyeo and FOSS-XR. Eyeo has been one of my favorite conferences whenever I attend, and this year’s conference came with the sad announcement that it will probably not continue – at least in its previous form – going forward. I somewhat regret not making more contacts and acquaintances while attending over the years, but it’s an intimidating crowd full of amazing digital artists and creative coders. I brought Thrive to one of the evening events this year, and introduced it to lots of new players, so it’s not like I was entirely invisible.

Foss-XR was a surprise to me, having found out the week before that it was going to be held only blocks from my apartment in downtown Minneapolis. I didn’t know what to expect, and after a rocky start with poor AV, ended up really enjoying the experience. I also reported on it a couple of weeks later at the only in-person MNVR&HCI meeting I attended this year.


I haven’t done any REAL web development since around 2011 or so, but I still host a half-dozen or so websites (including this blog). Many of those are using WordPress, and I’d love to move those to Jekyll, or (maybe ideally) something similar to Jekyll but written in Swift. (Publish is the only one of those I know about, but I haven’t done any due diligence yet.) I guess I’m officially stating this as a goal for 2023. I did already export some blog content, and then import it into Jekyll at some point in 2022, but I would probably have to do that again if I were going to migrate “for real”. (I helped out with a transition of this sort when the IGDATC website moved from WordPress to Jekyll, but I didn’t personally handle the export/import.)

I also got really into reading about ActivityPub after moving from Twitter to Mastodon in 2022, (my mastodon account is and I thought seriously about starting a project to support ActivityPub/Mastodon interop from Vapor. I have played with Vapor a few times since I found out about it, and did so again for an afternoon when I was thinking about this. It’s more likely that I’ll just create some static files to point a domain or two to various Mastodon accounts, but I haven’t even done that yet, so it’s obviously not a huge priority for me. I do think federated social networks are here to stay, and I hope the trend of user-owned content creation continues. I will help it along if I can.


Like everyone else, I was gobsmacked this year by text-to-image AI. I spent a not-insignificant amount of time reading about the technology, and even went so far as to install Stable Diffusion on my M1 MacBook Pro. Initially I wanted to use it as a pipeline for making game art, but the many important discussions happening around the ethical implications have me cooling my jets a bit. I did also use Midjourney to generate character portraits for a D&D campaign, and that was an easy win. I will definitely continue to keep my eye on the developments related to this technology going forward.


A few years back (even before the pandemic) I realized that working on games professionally left me without interest in working on my own games, so I re-focused my contract work back on native iOS. I am still waiting patiently for Apple to release a headset, and hope to find some crossover contract work when that happens, but until then, my bread-and-butter is mostly won with plain old iOS app development. I’m very happy with my current contract, and it should take me at least partly through 2023. There is other work on the horizon (they would like me sooner than later – and I appreciate their patience), but for now I’m trying to focus mostly on one contract at a time.

Something I haven’t talked about publicly in a while is how much time I’m devoting to contract work versus my own game development. But to talk about that, I need to first talk about how much time I spend working. Period. It’s a hard number to pin down, because there are several contributing factors. How many hours do I work each day? And how many days? How many of those are billable?

In general I aim to bill my clients for 20 hours per week. Ideally I would be working a 40 hour week, and that would leave 20 hours for gamedev, but it’s hard to say whether that’s actually the case. It’s only possible if you include hours outside of my normal workday, because for the last few years those tend to only be 6 or 7 hours long. Previous to this year, I’d have said it was very common for me to put in some extra hours in the evening after the rest of my family has gone to sleep. This year, I would say that’s definitely been the rare exception rather than the norm. So my guess is that I’m putting in a work week that’s more in the order of 30 hours than 40. However, there have been a lot of saturdays and sundays that were essentially a normal workday for me, (but always devoted entirely to gamedev), so maybe it averages out. Again, it’s really hard to say, because I don’t track the time that isn’t billable.

Generally on days when I get started working on a game project, it’s rare that I will want to stop working on it and go back to contract work, so that day is usually then relegated entirely to gamedev. For this reason, I usually try and always start my work day with contract work. Then if I’m itching to do some gamedev, I’ll switch to it later. But I don’t give myself that restriction if I’ve already billed 20 hours that week. That used to mean that most of the time Fridays were days for gamedev, but pretty regularly (this year anyway), I’ll be in the middle of some client task, and want to keep working on it more than I want to switch tasks and work on a game project. So usually my gamedev is on the weekends, with the occasional Friday afternoon thrown in for good measure.

Contracting gives me the freedom to turn off the clock whenever I want, and take an hour or an afternoon off just to run some errands or even unplug or play some video games. It’s relatively rare that I take a whole day away from “work”, but it’s very common for me to take an hour here and there, which has the consequence that it’s very often Friday morning and I haven’t yet hit my 20 hour mark. But I really do enjoy what I do. I can’t really count the number of times in the last 3 years I’ve remarked that my job is one of the things that’s keeping me sane. I find programming to be a much-needed catharsis when the rest of the world is an assault of illogical thinking and frustrating politics. I get to solve puzzles all day, and that’s not an exaggeration. And as anyone who knows me will attest: I do love puzzles.

Book notes

I’ve been keeping a log of books I read much longer than the log of games. The first iteration of this was just a text file that followed me from computer to computer from sometime in high school until several years after college, when unfortunately I fell out of the habit. Then I used LibraryThing for a couple of years, and then Goodreads for at least the last 10 years or so. (I’d really like to switch to Bookwyrm, and I have an account at, but I haven’t fully transitioned yet because their importer has been turned off due to overwhelming demand on resources. I did try to convince a friend to set up a new instance for us, but that hasn’t happened yet.)

Last year I marked 64 books read on GoodReads. Mostly I just read science fiction (and fantasy, and graphic novels, which I’ll admit are such easy reads that they make me look like a more voracious reader than I probably am), but a few days ago, I wrote a thread on Mastodon about some of the game-related books in my library that I recommend, and I thought I could link to that thread here.

Notably, the last book included in the thread is one I haven’t marked as “read” on goodreads yet. I’m still working my way slowly through Ben Orlin’s book Math Games with Bad Drawings, which I’ve been meaning to recommend here.


I wish everyone reading this a wonderful new year in 2023!

Foss XR 2022

Around the beginning of October, I found out that there was going to be an open source XR conference (called FOSS XR) in my neighborhood. I attended, and took some notes. I posted some of my notes in the MSPGameDev slack, and Zach, who runs our local VR & HCI meeting, asked if I would give a short recap of my impressions. I put some slides together, which I’ll embed below the video. There were some technical difficulties getting started, so the beginning of the video is actually as I’m getting into my second or third slide.

A play date for Playdate owners, or Getting Started with Playdate development

I signed up to host what I’d hoped would be a kind of Playdate user group at this year’s MinneBar, but I also prepared what I imagined to be a ten-minute talk on the various ways to get started making games for the cute little device. My ten minutes easily stretched to 42. (Apologies about how hard it is to hear the Q portions of the Q&A.)

You can watch it on Youtube:

What have I been up to lately?

Writing some Lua

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.

Prototyping Snake Shapes

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 ( 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 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

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.


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.


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.


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

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.)


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

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.

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.

I hope you enjoy it!