Blog
Filter By
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.
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.
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.