In terms of the scale of its card design, Oath is much more easily compared to something like one of the card games produced by Fantasy Flight Games rather than something like Dominion. While Oath has fewer cards in it's pool than the first set of KeyForge, it's quite comparable to something like Netrunner plus a few expansions. Remember, I'm talking about unique card design. Obviously a game like Dominion has more raw cards than Oath. But Dominion only contains 25 different kingdom card piles—the vast bulk of the game is duplicates.
Most games with a large number of unique cards demand such robust card lists because they need deck variety. Each card is a little tool that the players might use to build a strategy around or supplement an existing strategy. The card list is essentially where the game and all of it's various strategic potentials exists.
Oath isn't quite like that. In Oath all cards sit on top of the game's strategic and tactical framework. You could play game after game of oath with just a suited deck without abilities and the design would work just fine. In fact, for many months of development, this is exactly what I did.
Don't get me wrong here, the cards are not extraneous to the design. In fact, they are essential. As I worked on the primary systems of the game, I did my best to create a place for literary hundreds of unique powers and cards. The cards were going to be critical for the game's storytelling framework and critical for how the game grows and changes.
The ability of the game to adapt from play to play was the primary driver in determining the game's shape and the demands of its card list. I wrote about that at length in
I had worked with large card lists before. Pamir has around 100 unique game cards, and I learned a lot working on Pamir's card list. Oath would put those lessons to the test.
The key problem is figuring out how to think about large card lists so that you can work in a purposeful way without getting lost in the weeds. It's a little like painting a mural. Though you might use many of the same materials and skills to paint a mural on the side of a building as painting a small piece, the method of production is completely different. You have to adjust your procedure to be able to quickly go between thinking big and thinking small. I'll stop the painterly comparison here before I get into too much trouble with Kyle.
Let me give you another example. When I build proof-of-concept playtesting kits, I try to get the entire game down to around 5 pages. I build these pages as artboards in Adobe Illustrator not because it's the right program to work in, but because I can work quickly and can easily zoom out and see the entire project all at once. I'll usually use small versions of the cards and a tiny version of the board that fits in a single 8.5x11 sheet of paper. Such a kit is easily edited and allows me to rapidly iterate during the early stages of a design.:strip_icc()/pic5177683.jpg)
A Root kit from September 2017, about a month before launch. As you can see, my graphic design work is sloppy, but the basic framework is easy to iterate on the fly.
Oath was initially quite helpful in this regard. The game only uses about 20-25 cards per game and it was easy to build a representative deck. However, as soon as the design started taking off I was faced with the prospect of wrangling a truly massive card list. It was clear that I needed to adjust my methods.
The first thing I did was establish some core archetypes to each of the game's six suits. These wouldn't be hard and fast rules. Instead, they were guidelines that should inform the general attitude of each suit. Next, I created a list of different “roles” that cards could play in the game. I knew I wanted some portion of the game's cards to be battle plans and another portion to have one time when-played effects.
With these general principles in mind I laid out all of the cards in a kind of atlas and broke each suit up into little chunks. Now, I could go into each chunk with some big picture ideas in mind before I started getting deep into their design. Here's what one version of that atlas looked like back when I was still calling the game Saga:/pic5177695.jpg)
Funnily enough, though everything else from that iteration sank like a brick, this way of tackling Oath's larger-than-life card list stuck. This is one reason why the various terms and symbols in the image above might not make any sense to those of you who have already developed some familiarity with the game.
As I iterated the game, I began to get more comfortable thinking on the macro level and started to create some basic guidelines that would inform the design of each set of cards. Here, I decided to imagine that the different suits in the game would have certain natural affinities and antipathies. The basic idea was that the deeper you got into a suit in the archive, the more you would start to see abilities bleed into the domains of the other suits. (Sidenote: by reversing this “wheel” of relationships, I was able to come up with the natural combat counters in that suit's battle plans.):strip_icc()/pic5177692.jpg)
I could then put this affinity into a revised card atlas./pic5177710.jpg)
In this atlas, each square is a card. The black squares represent core card types associated with that suit. Then any block matching that color will be associated with that suit's abilities. So, a gray "Order" block in a hearth row is going to be a Hearth card that has some affinity with the Order type, perhaps it's a battle plan. Then, using the affinity/hostility wheels above, I could create a "Captain" type card that would be good against beast cards.
Again, none of these things are hard and fast rules. The main purpose of the exercise was just to provide a general framework so that I could easily shift my focus from small scale card design to the larger picture.
You'll soon see some of these dynamics work out in practice when I take you through the first two suits in our tour through the starting deck later this week.
- Cole Wehrle
Find the original post and discussion on Board Game Geek!