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.
Today I want to wrap up this series of posts on Oath's victory condition. I'll be talking a little about the end-game and offer some more specifics on how the four different path of victory work.
If there's a common thread that connects the designs I've worked on over the last several years, it's that they are preoccupied with “bad marriages” between players where one or more members must simultaneously work together and against their partners. A victory is never earned alone—the trick is figuring out how to get others to help you win.
Back when I was working on Root, I was often asked what victory meant in terms of the game. Partly this was the design's fault. Root uses generic victory points. The first player to 30 points wins. This metric is pretty convenient and also allows players to easily understand the current game state at a glance. But, it also hid some of the game's thematic framework. What was a victory point supposed to actually mean?
In the first diary I posted, I mentioned the centrality of cards to the design of Oath. Most of my games feature cares prominently, but none are anything like Oath.
Last week I mentioned how I didn't want to first build a game and then bolt on a suite of legacy mechanisms. If I was going to build a robust game that changed based on the decisions of the players, the game design needed to be built from the ground up to adapt to those choices.
When I started to build Oath, I had a very limited sense of what I wanted the game to be like. I really can't overstate this point. Most of my other projects brim with specificity, even early in the design. Oath was different. I knew that I wanted a game to tell something like a multi-generational story and I wanted that story guided by the decisions of the players.
Last week I mentioned how the origins of Oath were complicated, spanning many years and many influences. In fact, for a long time it wasn't clear that my work on this material would even coalesce into a game