Design Diary: Party Fowl

After feeling overwhelmed trying to design a larger card game that I mentioned in last weeks post, I decided to go back to something smaller. That led me back to an unnamed game, which has been through a number of iterations already.
The game originated form the idea hiring an adventuring party in a fantasy universe. Imaging going to a pub and hiring some knights, rangers, and wizards. The composition of the party awards you points, and the player with the most points after a few rounds would win. My friend suggested having all the characters be birds and then call it Party Fowl. Admittedly an excellent pun, that has already been turned into a video game.
The first version of this game played like a micro 18 card Fantasy Realms or Red Rising where players simply add cards with synergies to their tableau. The cards were overloaded—with five or six different properties on each card to analyze. It was way too much information packed into a tiny space. Trying to math out the best combinations was exhausting.

Unfortunately the original cards I designed are lost so I cannot show any pictures of them. Both the physical cards and whatever digital record I had of them have disappeared. It's always worth having a good workflow to store your work and versions it so you can see your changes over time. As the saying goes, "Do as I say, not as I do."
From Points to Pattern Matching
In the next iteration, I ditched points altogether. Players would try to build a specific party formation—like Knight, Mage, Mage, Knight, and Rogue in that order. When played, cards would trigger effects like shifting positions or swapping with opponents.
This version actually kind of worked. It was fun, to a degree. But the game often ended in just a few turns, and it became obvious who was going to win almost immediately. It wasn't ideal but it was an improvement.

Inherent Bias
One of the most helpful pieces of feedback I got was from my partner. She’s not really into fantasy, and more importantly, she didn’t have the built-in assumptions I did. She didn’t automatically intuit that rogues are usually sneaky or knights typically defend their group from attacks.
This is obvious when stated outright. Yet, looking around at fantasy games, this shorthand of fantasy theming and gameplay archetypes permeates so many of them. It’s worth considering whether a fantasy theme is worthwhile. It can easily capture an audience that already enjoys fantasy—which is a sizable—but may turn away others who aren’t bought into the standard Tolkien fantasy tropes.

This felt like a space I could continue to iterate. I gave some thought to removing the fantasy theming. In the meantime maybe I could replace the fantasy theme with some abstract concepts. Simple colors or gems as placeholders. As the gameplay evolved, moving away form card synergies the fantasy theme also became less important.
One place I do struggle is overlapping gameplay and theme. I often think of the theme first and how gameplay mechanics can represent the actions within the theme. I think successful games find interesting core mechanics that are quite abstract and don't thematically make much sense but are fun. A great example of this is Red Cathedral, where players build a cathedral together which requires collecting resources by moving dice around a circular board. What these dice represent I have no idea, but working around them is what makes the game fun.

Although having a theme and trying to build gameplay from that can be helpful, switching to a more abstract theme using just random symbols or colors makes it easier for me to build fun gameplay without being constrained to the theme. The hard part will be working my way back into a theme that is interesting or eye catching.