*And then you need to find a way to remove them.

When you’re making a new game, whether it’s a board game or a TCG, don’t wait until you think it’s perfect to test its systems. Use barrels.

A little over a month ago, I started really digging into a new design for a Trading Card Game. I had an overall concept for what I wanted it to do; what the central measure of forward momentum should be. Players would take turns attempting to score points by making their character cards (redacted), and at some point, one player could trigger the end of the game. Whomever had the most points would win.

As a designer and a player of games, I enjoy games where the increments that players gain points at can vary from strategy to strategy or deck to deck. I like models where players have some control over when the game ends. I also like the idea that even if a player triggers the end-game condition while they have a lead, the other player or players have a chance to mount an exciting comeback.

My new TCG had the first part. The goals set out for the players to achieve had variance in their value. A player could intentionally play a lot of things that would score a small number of points each, they could aim at a smaller number of high-value goals, and they could mix-and-match for something in between (or, as the gamers often call it, “mid-range”). It allowed different styles of play and player agency in building and selecting decks. This is a hallmark of a good TCG.

The game was missing the second part — a variable, player-controlled end trigger — and by cascading effect, no reliable way to deliver the third (exciting comebacks).

Back in my days at The Op Games, I’d designed a board game called Disney Sorcerer’s Arena: Epic Alliances. It had the kind of structure I’m talking about here, where players built a team of characters battling in an arena. Each character had a different Victory Point value that the opponent earned when they were knocked out. A character’s impact in the arena and durability were generally tied to their VP value. This meant you had ways to balance your strategy against the victory points you were willing to “expose ” to your opponent. This covered the “variance in value/strategies” goal.

Characters respawned after they were knocked out, giving players the opportunity to take down the same character over and over for points. When either player scored their 20th point, the end-of-game process was triggered. It wasn’t a matter of just scoring 20 points to win, it was about scoring your 20th point, and then holding that lead for the remainder of the round, which could be as many as five turns away. This was my “player-controlled end trigger”.

The fact that I could get to 20 points at a time in the game that gave you opportunities to pass my score? That’s exactly what the opportunity for an exciting comeback comes from. DSA: Epic Alliances met all three of the benchmarks I look to bake into most of the games I create.

So what does this have to do with barrels?

My new TCG design had what I believed to be a sound method for scoring points at varied intervals, but lacked a solid way to determine when the game should end. I didn’t want to just say “score 15 points first”, as we’ve seen loads of games do that or something very similar. I wanted something a little more distinct and unique. I just had no plan for what exactly that should be.

I still needed to test the parts I did have, just to verify the model could work. I hate burning time trying to build around a central pillar, just to learn later that that pillar wasn’t worth trying to elaborate on. So I (figuratively) wadded up whatever ideas I had for end game trigger into a makeshift plug, jammed it into the hole in the game’s design, and slapped the crappiest looking bandage I had over it all just to keep it all together for some really rough testing.

I called the makeshift system “flags” at first. The player who took the first turn got two flags, and the player who went second got three. Rather than just scoring points, you had to take out all the flags your opponent controlled in order to end the game. At that point, whoever had the most victory points won the game.

There was a balance and tension between taking the lead and holding it while you spent turns and resources taking out the flags. I could build a deck that scored a few points really fast, then focused on eliminating flags as fast as possible. That could get you a win, but it could also open the door to an opponent that put all their effort into scoring more points than you while you were busy effectively ending the game for them.

The flags were enough of a structure to give the game a flow that could test the primary point-scoring process. They were hardly elegant though, and I knew they would never make it to the final build. But they were there, and they allowed me to get the game in front of other players to see if the stuff I thought wasn’t garbage was, well, also garbage.

The client for the project was based in New Zealand. This meant that I needed to make a digital prototype in Tabletop Simulator (TTS) in order for us to try it all out. I built my decks in Component Studio 3 (see my previous post about that particular tool here), then imported them into TTS. When I got to TTS though, I realized I didn’t know how to make a custom object on the virtual tabletop that looked like a flag. So I grabbed the first pre-loaded game piece that sort of felt like a flag.

It was a barrel.

And that’s all it was. A piece on the table that represented everything I knew was not working with the game, but that temporarily plugged a leak so I could test the rest of the build. A stupid digital barrel, but one I needed, even if just for the moment.

When I played the very first test game with the client, I told him up front that there was an element I knew needed to be cut and replaced eventually, but I didn’t tell him which element that was. We played the game, and when we finished, I asked him for the High/Low/Buffalo review.

His High was the core scoring structure. His Buffalo was how well that core piece and cards reflected the IP we were building around.

His low was — prepare to be shocked — THE BARRELS.

Are you surprised? I know I wasn’t surprised. Nobody here should be surprised. The barrels were a massive, ugly lampshade hung over something we all knew didn’t work. But they held things together enough that we could see everything else we needed to, and the client was able to see the parts that were good. He immediately gave me the go-ahead to keep moving forward with the core process.

A few days later, I showed Dave (my design partner on the project) the game, still using the barrels. His initial reaction was much the same as the client’s, though Dave was able to look at it through the lenses of a seasoned designer.

“Obviously, they don’t belong here. I think though that if you take (redacted) and push the player to (redacted), you don’t need the barrels or anything like them at all”. Dave saw exactly what I needed to keep, what I needed to toss, and what needed to happen in between, in part because there was a glowing red light/barrel that worked like a signpost that unashamedly said “I know this part doesn’t work. Help me find the solution.”

We’ve since tried out Dave’s suggestion, and it led to some other happy discoveries about the game. And some more newer barrels.

Not long after the adjustments, I put together a fairly structured/themed deck to play using the 30-ish cards I’d designed so far. It did what it needed to do — you could shuffle up, draw a hand, play out resources, pay to play cards with those resources, and do all the things the game was supposed to let you do. There was only one deck though, so when we tested, both players used their own copy of the same deck. This is widely known as a “mirror match”, and while it’s technically a playable game, it lacks nearly all the texture that these kinds of games thrive on. When your strategy game is about having a multitude of different strategies, mirror matches don’t really demonstrate the end goals of the product.

The client and Dave played one of these mirror matches, and the client immediately noted, “It works, I enjoy the flow, but I feel like I’m not getting the full picture that there could be here.”

“That’s because this version serves the role of testing the flow, not the bigger picture of what kinds of decks we can build with a deeper pool of cards. This is a minimum viable object for testing. The second deck is the barrels.”

He and Dave immediately understood what I meant. We’ve since joked that “the barrels” is going to become an inside shorthand for project elements we know we don’t have a fully working solution for, but plan to solve soon with help from the rest of the team.

I’ve since doubled the number of cards designed for the game, and can build upwards of six different archetypal decks with what I have. There’s still overlap between the decks, but not so much that the games ever feel like pure mirror matches. Currently my barrel count is at zero, but I know that I’m far from putting the jargon to rest. There will be more progress on the game, and there will be things that I find half-solutions to, and that’s when the barrels will roll out again.

On that note, I want to share a completely unrelated trick with you. It’s an old one, but maybe you’ve managed to not see it until now.

Go to Google.

Type in the words “do a barrel roll”.

Hit return/enter.

Enjoy.

———

One more little thing I want to put into the universe today, and that’s some self-marketing. These days I earn my living by picking up game design, development, and testing contracts. If you are a publisher — or are working on a self-published game with a budget — and have been enjoying and finding interesting insights here on DiscoCandybar.com, please reach out to me so we can talk about opportunities to work together. I’m currently open to part-time and full-time contracts (remote or local to the Seattle area), as well as full-time employment if you have a role to fill. Check out my resume and qualifications on LinkedIn. Thanks!

---