Blog

Throughout the campaign, I've received dozens of requests (mostly polite) for me to write about how Oath plays as a solo game and with two players. This is something that I would have loved to talk about earlier, but it's always felt too early to really dig into how the bot works. But, recently the design has started to settle down and it seemed like a good time to share it's general shape.

Over the past few months, I've spent a lot of time talking about design, but I haven't gotten into how we organize our development schedules. With the release of the public print-and-play kit later today, it seemed like a good time to talk about how game development works. At least, to say a few things about how we make games here.

Earlier this week I wrote a little about the rules that inform the game's card list. Today I'm going to chat a bit about some cards in the context of those rules.

When I tell folks about Oath, one thing I like to mention is that the game will have more than two-hundred unique cards. Today I want to talk a little about where that number comes from and walk you all through some of the design challenges that were associated with working on such a large scale.

After a lot of futzing around I found that the only essential structural element I needed in terms of the game's geography was to be able to handle the difference between core and periphery. Thankfully, that's an easy enough thing to collapse down to a single stack of cards, which is critical to how the game stores its map.

In Oath, one to six players guide the course of history in an ancient land. Players might take the role of agents bolstering the old order or scheme to bring the kingdom to ruin.

From the very first entry in these series, I hope it's been clear that Oath was always a game that was going to need cards. When I look back on very early proto-Oath designs from many years ago, it's clear to me that the roadblocks I encountered in that game's design existed mostly because I didn't have the proper tools to build the game.

I love closed and semi-closed economic systems in games. It's one reason why I was thrilled to see The Estates get wide distribution last year and one reason why Container beats out most other economic games on the market. A closed economic system is usually symptomatic of a interactive system. It's one of the few design elements that will almost always get me to give something a try, even if I have no other interest in the game.

I'm quite bad at building games around a single clever mechanism. I don't mean to present any false modesty here. I'm bad at it, and I wish I wasn't. While I'm working on a game, I tend generate a lot of little mechanical systems. Most of these are serviceable and will work just fine in whatever game I'm working on or will maybe work on some future project. But, every once in awhile I'll cook up something especially cute. That's when I know I'm in trouble.