Designing The Perfect Card Game

Written by: Jesse Bergman

On an almost daily basis, I am reading a post on Reddit, or a post on a Facebook group regarding card game design. It's not hard to understand why people want to design card games, ever since Magic The Gathering released in the early '90s. Strategy card games, in particular, have captured the imagination of players everywhere. In the case of Magic, we felt like we were dueling in a D&D world. Strategy Card Games, or SCG's as I like to call them, are a genre over 25 years old now. In this blog series, I intend to breakdown the process that was used to make our game Battle for Sularia: The Card Game. I won't go into the Publishing end of the game, and I won't go into how to set up and run a Kickstarter. There are many resources from folks like Jamie Stegmaier and James Mathe that will help you on those fronts.

Distribution

Now I know you are all shouting at your monitors "Jesse!! I thought you weren't going to talk about Publishing!" That's true, and I must apologize, but I also believe that knowing what kind of card game you are going to make has a drastic impact on how you go about designing your game. You should be making a conscious decision as to whether you are going the Trading Card Game or Expandable Card Game route.

Trading Card Game

At this point, if you are reading this and don't know what a trading card game is, I'd suggest taking a step back and playing some TCG's before you dive into making your own Strategy Card Game. Like seriously, play them in all of their different modes, draft, sealed, constructed, etc. They have nearly limitless play possibilities.

Here are some of the Pro's and Con's of a TCG

Expandable Card Game

Expandable Card Games are LCG's or Living Card Games. But, another established company has trademarked the LCG term, which means that only that company can use the term. For the rest of us we have to use the term Expandable Card Game or even the term Strategy Card Game. However, there is some confusion around what exactly a Strategy Card Game is in the marketplace. While that's a whole other blog post, for the scope of this article, know that these games use a fixed distribution model. ECG players do not have to purchase random packs to play the game. On the surface this seems to be the perfect model for card games, but ECGs have their own issues in the marketplace.

That's a lot of information about what should be a simple decision, but it's not so simple. Let me also state that unless you have a huge marketing budget and ties to an organized play circuit, I would strongly advise against making a trading card game.

The Core Gameplay Loop

For many first time designers, the core gameplay loop is a particularly tricky point of entry. I would venture to guess that a fair number skip over this step entirely on their first designs to jump right into card design. I mean the cards are where all the fun is right? Not so fast, my friend, your game loop is the backbone for the game. While cards will drive the single game the core gameplay loop is critical to the overall experience of a design.

So let's break down Battle for Sularia's Core Gameplay loop, on screen, it looks rather complicated, but in actuality, it's quite simple.

While there are 7 phases, each has a specific purpose and structure that is part of the core gameplay experience. But before I could design those phases, I had to think about how I wanted players to experience the game. As a designer I choose to design games from an experience stand point vs a mechanical standpoint. Neither methodology is wrong and if you prefer to design game mechanics first go for it. For me, I try to envision the gameplay, and then I try to consider how I will achieve that vision with mechanical solutions.

So what did I envision for Sularia? Well, two things bothered me about the Card Game market at the time of design. First Android Netrunner was the runaway leader in the ECG market. I played Netrunner, but it didn't feel like a card game to me, it felt more like an area control board game. So upon playing Netrunner, I didn't feel it scratched my TCG card game itch. I needed a game that felt like the old VS. System and MtG. I wanted to scratch players itches for those games first and foremost.

Secondly, I loved RTS games back then. I played them to a near cult-like religion. For those of you that have spent time trying to climb the competitive ladder of an RTS, you know that those games have particular play patterns that when missed by even .5 seconds at the highest levels can result in disaster for that player.

The challenge was, how do I capture that feeling and experience in an analog game. I felt there were four core things about the experience, it would need to have two manageable resources, and two it would need to have some element of base construction, it would need a tech tree. Finally it would need to simulate the precision of timing that RTS games have at a high level.

So by understanding these things I could start crafting the core loop steps you saw above. The specific rules I set out on the initial framework changed drastically based on failures in achieving that core experience. But that is to be expected. Without that core experience in my mind, and on paper I'd have no way of knowing what we were trying to achieve.

I believe some core principles need to be understood when designing a core game loop for a card game.

1. K.I.S.S. methodology is best

Keep It Simple Stupid; means don't over complicate the process. In an initial framework, each site on Sularia had specific placement needs, and they even had requirements that a past "site" was in play to build a future one. By imposing tight restrictions on the gameplay, we could not see how the more in-depth strategy could evolve because the rules and game loop restricted it. Open up your rules, keep an open mind on the initial framework using your vision for the experience as a way to drive the "ruleset" based on early prototype feedback.

2. Forget Game Balance

Wait what? Yup you heard it here first. Game Balance is part of the individual cards fitting together cohesively. It has nothing to do the game loop. The game loop is just the restrictions on how your cards will behave when in play. So worry only about whether the game breaks because playing cards in a specific sequence would do that.

For example in an early playtest of Sularia, players could utilize their Influence also to play combatants. In the final design, only Sularium will pay for combatants. Why? Because early playtests had players forgoing sites altogether or minimizing sites to flood the battlefield with combatants. Removing sites from decks strictly went against the core vision for the game without that vision that may have been a rule that would have stuck around. So don't focus at this stage on win/loss or balance focus on whether the game plays as you envisioned.

3. Make Changes Quickly

You don't need 25 - 30 playtests to realize at this stage that the game is or isn't adhering to your overall vision. If you play it and don't like a core loop component. Try something different, remember, our target is your vision for the game.

4. Don't be scared to throw away a part of your loop

As you develop the loop don't be afraid to throw away a part that seems to break the fluidity of the loop. We had many reviewers in our first campaign comment on how "silky smooth" Battle for Sularia played. Those were their words, not ours. The experience was only possible by cutting the excess garbage away to create a logical sequence.

5. Use Logic to help build your loop.

If you are not familiar with computer logic or how computers operate things like "while loops" or "if-then clauses" I would suggest taking some time to do a basic programming course. Remember that a game loop is the backbone of our game, and considering how a computer would handle these steps, helps us build a seamless loop. If you cannot adequately explain your loop with logic, then your game loop will not feel transparent to the player.

For example, if I was right my game loop in computer code, and again this is not operational, it's just a framework understanding of how the game operates.

Player 1 Turn  Check Activated Cards - > Set to state Reset  Check Exhausted Cards -> Set to state Activated  Draw Two Cards  Player Input - > Influence Card Played  Action window -> Player Input (Play/Pass)  Calculate Influence Generation -> Count Face Up/Face Down Cards in Influence Zone  Set Influence Pool -> Equals Influence Generation  Player Input -> Play Site  Do While -> Next Played Card is a Site  Play Site          "Open Action Window"      Else "Action Window"  Calculate Sularium Generation -> Count Each Card in Play on the Battlefield  Set Sularium Pool -> Equals Sularium Generation  Player Input -> Play Combatant  Do While -> Next Played Card is a Combatant  Play Combatant          "Open Action Window"      Else "Action Window"  Declare Attackers -> Player Input Select all attackers  Open Action Window  Declare Defenders -> Player 2 Input Select all Defenders  Open Action Window  Resolve Attacking Alpha Strike Combatants  Resolve Defending Alpha Strike Sites  Resolve Attacking Combatants  Resolve Defending Sites  Remove Defeated Cards  Action Window  Check Player 1 more than seven cards in Hand Zone  Yes - > Discard down to seven cards  No - > Reset Defense Value of cards in play to their base value +/- any modifiers.  Repeat for Player 2

While obviously, my coding skills would not land me a job as a programmer, it helps to understand that conditional clause and trees that have to occur to move onto the next steps of the game.

6. Study current card game design trends

Understanding current design trends is a crucial step, much of modern card game design has forgone the collection of resources for the sake of action economies, or some other methodology that doesn't require the collection of resources. I love these games a lot, but for Sularia a game inspired by RTS games it didn't fit with the core vision of what the experience was supposed to be. In an RTS game, you collect resources. If your game doesn't need resources, great, think of other unique ways to limit a players turn to keep the core loop in balance.

Get to a Prototype Fast

At this stage, you need to get to a prototype fast. Make a quick set of cards to test the loop. Don't worry about Balance or uniqueness or abilities or any of that stuff; we will get to it later. Instead, build something you can play with right now, and check the loop to see if it is functioning. If not, then its time to iterate on the loop until it does.

In the next article, we will discuss the high-level card and "color" design.

Do you like what you read here? Give us a heart or if you want to discuss this article in our community join us on discord!

Discord+Logo.png