[GB] Tips for testing Card Interaction from BGG

[Eliahad]

I started a thread over on BGG to ask for tips on testing card interactions. I'm posting those notes here so others can see them.

My post:

My co-designer and I have been working on a game for the last year or so, and we've gotten it to a state where we can begin testing and iterating the card decks involved in the game. We have done some testing this way, and started the process of figuring it out, but there are so many possible combinations we thought we should reach out and see if anyone else has had this struggle and what to do about it. So...

Does anyone have any tips on how to test cards and combinations to figure out what does and what doesn't work together?


Background: The game's working title is Godball and is for 2-6 Players.

The Gods, bored with their usual machinations, appoint heroes to amuse them with a little game of rugby. The Godball is placed in the center of the arena and their appointed heroes must race to reach the Godball and return it to the goal area near the shrine to their deity. The Gods, meanwhile, use their power to influence their heroes, and the field of play, to tip the game in their favor.

Each player is playing both a hero and a god.

The god is represented by a deck of 30 cards containing their powers to affect the game. A player starts with a hand of 4 cards and replenishes that hand to 4 at the end of their turn. Typically a player will see 20-24 of those 30 cards in a 12 round game.

Gods can do things like create and destroy terrain, move or enhance heroes, react to other Gods and create board elements that can be used to hinder or help themselves or opponents. Each deck is themed to that particular God, so Poseidon has more terrain manipulation or Hera has more curses and subtle influences.

The hero is represented by a token on the field of play (a hex board) as well as a hero board which displays all the possible actions a hero may take. Actions are activated from an action point system, and a hero can take each action on their board once per turn...if they can afford the cost of those actions.

Thank you in advance! I've been following these boards for a while now, and the sheer wealth of information and expertise here is both inspiring and humbling.

[Eliahad]

From Lowenhigh:

I have a game in development that has about 200 cards that interact in varied ways. I have a few general rules:

1. Make sure cards "feel" overpowered. That means some of them will BE overpowered and out of balance. Now comes point 2...

2. Make sure none of the cards break the game. Certain effects, while powerful, might actually conflict with other mechanics. For example, I had a card that would allow you to re-order the "event deck" in my game, which in some cases can break the scripted parts of boss encounters. That effect had to go.

3. Have a simple plan for statistical organization of your cards to group them by power level, effect, etc. The way I do that is this...

- Organize my cards for each deck into 3 groups: underpowered, mid-power, and overpowered. I rate them a 1-3 based on power level. I want to be sure that decks have a relatively even power level overall while also maintaining that unique feel of each class.

- Take a look at the cards in the overpowered group, and make sure they don't break the game.

- Give sub-categories to the individual cards that notate their effects. For example, how many cards are in each deck that allow for drawing cards, apply status effects, deal damage, heal, etc. Those should be somewhat balanced, OR should be more heavily weighted toward one based on the deck's play style.

And finally...

4. Play test a LOT. If you're not play testing with outsiders, you'll never uncover the truth about things. Balance is a difficult thing to achieve, and it is my opinion that completely balancing things means homogenizing the game to the point where there is only 1 class. Don't strive for balance. Strive for "feeling overpowered" while also ensuring the game doesn't break.

[Eliahad]

From Antistone:

If your game has a lot of cards, you can't test all combinations one-at-a-time.

Some things you can try:


1 Do a lot of play-testing with different combinations of stuff, especially early in development. You'll probably never eliminate ALL problems from your game on a one-at-a-time basis, but seeing just a few random ones is still important because it teaches you about the failure modes of your game--the general kinds of ways that things might go off the rails. That might be things like "someone gets stuck and can't make progress" or "someone gets infinite actions and wins automatically" or "players get stuck in a loop where I always spend my turn undoing whatever you just did", etc.

This teaches you what sorts of things you should watch out for, and possibly how you can change your core rules to make them more resilient. (Sometimes a simple change to a basic rule can eliminate an entire category of problems.)

Secondarily, this helps you estimate the average level of brokenness in your game. If you try 40 things and 2 of them are broken, then you can guess that maybe 5% of everything in your game is broken. Be careful, because the error bars on that number are pretty big, but it's still better than nothing.


2 Look at individual cards. You can't test every combo, but you can test every card in isolation, and you can certainly think about every card in isolation. Try to think of ways that card could do something bad. Imagine what sorts of hypothetical effects could exist that would combine with it in bad ways. Be thorough.


3 Group your cards into categories based on the kinds of interactions they enable, and then look for combinations of categories that seem likely to cause problems. For instance, "cards that give you more gold" have higher odds of forming combos with "cards that let you spend gold to do extra stuff" than "cards that let you spend mana to do extra stuff".

By grouping cards together, you can reduce the number of potential combos you need to consider...or at least figure out the most profitable places to focus your efforts.

[Eliahad]

From russ:

https://en.wikipedia.org/wiki/All-pairs_testing

Also: try to at least consider each pair of cards and whether there are any rule ambiguities or other obvious problems in how they interact. (Some large sets of pairs can hopefully be trivially resolved as having no interaction needing analysis, without needing any further thought, e.g. all pairs where one card happens in the movement phase and the other card happens in the combat phase, etc.)

[Eliahad]

Corsaire:

I like to look for broken things by brainstorming worse case scenarios and trying to see if I can achieve those with the cards available. Like a player can never move again. Infinite combos. Unblockables wins.

Magic the Gathering players specialize in that. One thing you might do is explain the rules to some MtG competitive players and ask them to look for ways to abuse a deck.

[Eliahad]

[Eliahad]

David Horn:

Podcast episode of City Building Games with Ted Alspach, Ted talks about using Excel to keep track of all the tiles in Suburbia, and was able to know if any of the tweaks would make any one tile too strong. He doesn't really go into details in how to make the calculations though.

[Eliahad]

[Eliahad]

hseiken:

Im actually working on a card game myself and I know a little programmig so I actually am doing all my testing with QBasic. If you can learn a little bit of programming, it helps a lot with this sort of thing assuming that your cards follow universal rules or can be relatively easy to make interact with other cards.

The advantage of this, if your cards have managable and predictable range of possibilities is that you can experiment with the cards easily, for instance while developing the interactions, I didnt concentrate on the cards so much but their range, so i created a random card generator that makes 200 new cards each time I start up the program.

As such, I can have the game play itself and track statistics of various things about their interactions to get an idea of the balance I should look for once I decide on the final static set that will never change.

This solution wont work so well for very complex games like Magic The Gathering, where every card nearly adds its own rules, but for games that operate like a typical 52 card poker deck and similar up to a certain complexity, its quite useful. I suggest this as an option for most any game that focuses on simpler mechanics especially if it has a lot of pieces that need to be fabricated for each iteration...in my case it simply wasnt plausible to make 200 cards each with up to 13 different properties just to scrap them the next day. As a program, however, I can make 200 cards in less than a second, create decks for the players and test a whole game in about 2 minutes now that Ive mostly got the rules of interaction complete.

Theres plenty of tools that make this kind of simulation easy...QB64, Etoys(highly recommended, btw for all kinds of quick prototyping btw!!), BlitzBasic, etc...it helps a lot and reduces need for outside help during early game development since you can get feedback solo as well. It does take a little learning if youve never programmed, but these particular tools are easy to pick up and if youre not doing it for distribution, you dont need to even worry about how ugly it is or graphics at all...my current game dev program is all text mode on MSDOS but it does precisely what I need as far as testing and balancing.

Again, it might not be suitable for your project, but I would still keep the option on the table if you come up with an idea that might play to this kind of prototyping's strengths.

Good luck.

[Eliahad]

[Eliahad]

Certainly computer-automated testing can not replace testing with real human players; it just augments it (potentially very usefully, potentially more trouble than it's worth, depending on the specific game).

E.g. computer testing will be much less effective than human testing at determining whether a game seems fun.