I Don't Understand Domain Cards in Daggerheart

The design choice I still don't get. Also announcing a small change to Drolleries.

I’ve ran 6 sessions of Daggerheart by now (not counting the 3 sessions I ran during the beta playtest), and I generally love the system.

I love the core roll of 2d12 with either hope or fear. It means that every roll has an interesting outcome and consequences. Because every roll generates these currencies, every roll is elevated in importance and stakes.

I love the GM resource of fear, as I wrote about last week of course.

I love experiences, the freeform way in which players create their own skills and justify their use. It prompts players to roleplay more, but because of the cost to use it, it doesn’t require the GM to rules-lawyer the players about when they might apply.

I love how combat is quick and simple to run. Most enemies go down in 1-3 hits, but you can still have bosses that take many rounds to defeat. Because of fear, combat is rarely a slog.

I love countdowns and how rolls with hope or fear have different impacts on the countdowns. It’s like a skill challenge or montage test, but with more weight to each roll and more flexibility to be used elsewhere.

Now that I’ve got that out of my system, you have context for my following critiques. I generally loved my time with the game, and I hope to play it again soon. So without further ado, here are some things about Daggerheart I just didn’t understand.

---

I’m Colin, and I’m a professional video game designer. This is Drolleries, where I write about d&d, ttrpgs, and game design.

---

Cards are Just Better

Okay, I lied. Give me another paragraph or two to gush.

I love that the players’ abilities are on cards. It made it very easy for players to choose their abilities and arrange them visually in front of them. It’s much better than referencing a thick hardcover book that we’d all have to share or copying down an ability word-for-word into their character sheet. Is there even enough room on your character sheet for that? What if they swap out the ability? Cards are just a superior form factor for self-contained abilities with complex and specific wording that can be swapped out on a level-up.

My group had two players who were new to not just Daggerheart, but tabletop rpgs in general, and they loved the cards. Because they were tactile and visual, it helped them remember their abilities and keep track of their options.

So I loved the card part of domain cards, but I didn’t understand the domain part.

One Class, Two Domains

In Daggerheart, each class is comprised of two domains, and when you pick new abilities, you pick from the set of abilities of your two domains. Each ability belongs to a domain, not a class.

A big consequence of this is that players’ domains can overlap.

The ranger picks from the Sage and Bone domains, while the warrior picks from the Bone and Blade domains. But why? What’s the purpose of this overlap?

At my table, this only let to disappointment. It made each class feel more generic because their abilities were less specific to their class’ fantasy, and it eroded the niches of each class. If a player had an overlapping domain with another player, it meant they each had fewer options to choose from.

It looks all neat and nice in a diagram like this. But for what purpose?

In order to avoid this and keep their characters unique, my players tried to communicate to each other what kinds of abilities from each domain they would pick. They further narrowed the types of things their character would be good at, just to avoid stepping on each other’s toes.

But this just meant they had fewer cool abilities to choose from. And it didn’t feel natural, it felt forced. I can think of many ways in which a ranger could be different from a warrior. But in Daggerheart, they share the Bone domain, which means that they feel very similar to play. The uniqueness of each class was watered-down by the domain-sharing system.

This was especially obvious because one player of mine that didn’t share any domains with anyone else at the table was the bard. And because her abilities were unique to her, it made everyone oooh and aaah at her character’s powers. The bard felt more special. But only because everyone else felt so same-y.

I don’t understand the design goal of the domain system.

Why doesn’t each class have their own set of abilities that players can choose from?

It can’t be for a lack of imagination; I can imagine dozens of abilities for a ranger class or a warrior class that don’t overlap, and I’m sure you can too. It’s not like fantasy is a niche genre within tabletop gaming.

The Purpose of Classes

The purpose of a class-based system is to have a self-contained package of benefits that reinforces a specific fantasy and can be balanced within itself. But the classes in Daggerheart are not that.

People say that the domain system enables people to easily design new classes that combine other domains together, but that raises a major question in my design brain. Are all the domains balanced with each other in mind? Has the team already made sure that every domain can be combined with every other domain without breaking the game?

If the answer is no, then I think this domain system actually makes it harder to design new classes. Because then you’d have to design a new domain, and decide which other domains it could combine with. You’d have to pre-commit to how many classes this domain could be used in, and future-proof your design.

But if the answer is yes, then why does Daggerheart have classes in the first place? If every domain can be combined with every other domain, then I’d rather have a system where players get maximal flexibility in character creation and therefore can avoid overlap. It would encourage players to be creative. How does their character have both the Bone domain and the Codex domain?

But unfortunately, I don’t think Daggerheart was designed with an answer to this question. And without a clear design goal and clear expectations for how classes and domains work together, I think it actually makes it harder to live in this system and design new content for it as a GM.

---

A Small Change to Drolleries

First of all, thank you so much to all of you who read my articles. When I started writing Drolleries, I had no expectation anyone would actually read it. It was just my journal of the thoughts I’d accumulated over years of playing tabletop games and discussing them with my game design friends.

I committed myself to a weekly schedule, and I’m proud that I’ve stuck to it. I’ve written a lot over the last couple months, and I’ve written all kinds of articles, short and long. But the articles I’m most proud of were the ones where I had time to go into depth about a specific mechanic or system and present my own take on it.

But those articles take time to write, and most importantly, time to actually play the games I’m writing about and formulate my own design. So going forward, I want to focus on writing fewer articles that are longer and more thoughtful.

Basically, I want to write at the speed I play and design new games. Drolleries will continue to be a journal of my game design experience. I’ll be analyzing games I play that inspire me, critiquing games I love, and discussing my process in designing new games.

With that goal, I’m aiming to publish about one article a month. They’ll be more extensive, more in-depth, and many will include more of my own design.

I hope you’ll come along with me. Until next time.