Today we're releasing the second public print-and-play kit for Oath, and it seemed like a good time to bring everyone up to speed on the game's development since I wrote to you last in January. I also wanted to take this opportunity talk a little about game development generally and my own personal practices.
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.