I extended that strategy to the game’s combat system as well. However, here I knew that some innovation would also be required. In general, my attitude about combat systems is that they need to get out of the way where possible. Even a fascinating combat system is never that interesting. Most of it’s value comes in its interaction with the rest of the game’s systems. For this reason, I think the design of Root’s combat system is some of my best design work. It’s clean and it gets out of the way, taking no more than a few seconds to resolve. Players can easily approximate odds and understand the wagers and counter-wagers they are making when they rush into battle.
With Arcs, I knew I was going to need something similar to Root. The core action system was very fast-paced and therefore very brittle in terms of game flow. Any disruptive combat system could quickly derail the game. It had to be short and sweet. Unfortunately, I knew that the combat system also needed to be much closer to Oath than Root. That is, while Root’s combat system is really just an attrition generator, Oath wraps up attrition, conquest objectives, and non-territorial objectives all in one system while interfacing with a huge number of combat cards. Arcs needed that sort of expressive range, but I had to figure out a way to do it without causing the kinds of slowdowns that Oath’s longer turns and slower tempo can tolerate.
My first instinct was to rely a single blind bid. Here I took my inspiration more from those tactics chit wargames like Empires in Arms than from games like Dune. The basic idea in those games is that players will calculate the fundamentals of the battle (how many soldiers, terrain, etc) and then secretly select a tactics chit. Both of the tactics chits would then be revealed and the combat would be modified by the result.
These systems have two great virtues. First, they were generally pretty fast. Or, at least, they could be fast if a lot of the extraneous modifiers were trimmed out. Second, I felt like they captured the proper feeling for warfare at an operational scale. By this, I mean that I wanted the player to be one step removed from combat. They would set the strategy, but exactly what happened would be up to a lower echelon of commanders. Maybe those commanders made some bad decisions and ran directly into an enemy’s ambush. Perhaps they would perform well despite bad orders. This distance from the action helped ground a player’s position as a leader juggling a lot of big problems and helped keep the game’s larger storytelling in crisp focus.
With that in mind, I came up with a pretty straightforward system. The attacker would have a number of tactical options. The defender would also have a number of options. Each player would secretly select one of those options and then they would be revealed and resolve themselves.
I did my best to keep things simple and rooted to the demands of the game’s design. I knew I needed attackers to basically have 3 options: they could perform a risky full frontal attack, they could attempt to steal something, incurring extra losses in the hopes of capturing a secondary objective, or they could attempt to dislodge the enemy, incurring extra losses to gain a positional advantage. The defender also had a number of strategies that would soften or even foil an attacker’s plan. For instance, if you went strike and the defender had evaded, the battle would be effectively nullified.
To illustrate this I whipped up a quick chart:
In this chart, the red squares were pitched battles, the green pluses were attacker advantages, and the gray Xs were defender advantages. Now, this chart doesn’t deserve too much close scrutiny. There were lots of places where my model of combat broke down. Shouldn’t evades have a chance of failing against a strike? Shouldn’t an attacker’s push be most effective against an evade? In almost all cases the answer was “good point!” or “maybe!” My desire for a more thematic and interesting combat system was running headlong into the game’s need for something simple and strong.
Still, I kept pushing with this system. I knew that I couldn’t insert a table into the game, because the time spent looking up values in a table would likely lead to the combat system being too clunky in play. My first instinct was actually to design a set of combat wheels. The idea was that each player would secretly select a strategy and then the combat wheels would be laid on top of each other and the icons that displayed would indicate what happened.
This system was far to clever for it’s own good and it was difficult to prototype, so I refactored it to a set of cards. The attacker and defender would each have a set of combat cards and would secretly bid one. Then, the results would be cross referenced.
We played with this system for a few months and I was generally happy with it. However, I found that it was really only interesting when players made mistakes. Once players knew the system well, it was pretty easy to outfox a weaker player, which lead to huge swings in fortune. This could be perfectly interesting in a different game, but it simply wasn’t meshing well with the game’s other systems. It was also taking up too much time. Here I realized I had made a huge error in my reasoning. I figured that I was only giving players 3 strategic choices each. Just pick the card that matched the thing you wanted! But because the cards interacted in a quasi-rock-paper-scissors game, players actually had to think about all 9 different outcomes. This was far too much to think about.
I don’t mind giving players a lot to think about, so long as it leads to an interesting interaction. But, I found that, with good players at the helm, some of the structural advantages I had given to the attacker more-or-less melted away. To put the problem bluntly, player’s were spending a lot of time playing a mini-game where the result of good play was that players were better off not playing in the first place.
Here I took a few steps back. What did the game actually need? Well, I needed a fast system that allowed the attacker to formulate and execute a battle plan. I also wanted the possibility that a defender could upset an attacker’s plans. Because the system was testing well-enough, I moved my focus elsewhere and decided to let combat simmer for awhile longer.
Then, one day, Patrick and I were playing around with a title he’s working on called tentatively called Dark (and formerly called Dungeon Fortress). We were playing around with its combat systems and how it handled long, drawn out conflicts. He wanted to design some kind of siege mechanism, and we were brain storming some different ways that it could be implemented. Something about that conversation forced me to rethink the fundamentals of combat in Arcs. Exactly what options did I want to give to the attacker?
Well, I knew I wanted the attacker to have the ability to force big, pitched battles that would obey a similar logic to Root in terms of attrition and action sinks. I also knew I needed some kind of raid system where players could steal resources from one another. This system would be especially important for a few critical plot lines I wanted to design in the campaign. The third strategy, dislodge (or push) had never really worked. As much as I wanted to design a game about maneuver, Arcs was clearly a bad match both in terms of gameplay and theme. I think that the overlap between pushing and raiding and assaulting muddied my thinking and caused me to miss the obvious third leg of my tactical stool: the siege.
I imagined my three strategies on a kind of continuum. On the one extreme you had raids. These were by far the most costly and dangerous strategies and players were rewarded by getting the chance to steal from the opponent. Assaults sat in the middle and had high losses for both sides but favored the attacker at margins similar to those found in Root. Lastly, there was sieging or, in space terms, bombarding. Here the attacker had no risk of damage to their own forces but could inflict only minor casualties.
I formalized these strategies into a number of outcomes that could be mapped onto a simple D6. I imagined that the attacker would choose their strategy and then roll a pool of dice equal to the size of their force. Every ship would equal one die. I love “buckets of dice” combat systems because they can flirt with a wicked probability spaces that put problems of diminishing returns and accepted risk profiles in sharp relief. Here’s what I mean. In John Company, players spend resources to roll dice and use only the best result. Early on, it’s worth a player’s time and money to add dice to the pool, because each die dramatically improves the chances of success. However, the increment of improvement diminishes with every purchase. By the 6th or 7th dice you’re only gaining very marginal returns. Yet, because failure is always possibility, players must decide how much risk they should tolerate.
Arcs uses a similar logic. Take a look, for instance, at the Raid die.
The “A” indicates an attacker hit, the “D” is a defender hit, and the diamond is a successful raid. If you have 3 ships and are attempting to raid an enemy fleet, how many dice should you roll? With just a single die, your chances are 50/50. Adding another die will increase your odds considerably. Even though the third die will not increase your odds as dramatically, it’s likely still worth adding in. However, with every die you’ll be increasing your chances that you’ll come out of the fight with a bloodied lip or worse.
With the bombard (top) and assault (bottom) dice, we added a “hollow” “A” which works like the hollow sword in Oath. You can see that these dice provide a lot more advantages to the attacker!
Once we had the dice in playtesting, it occurred to me that players should be able to freely mix and match dice pools as they saw fit. I can’t remember precisely what sparked that realization, it just seemed so obvious when all of the colored dice were out there sitting on the table. This really grounded the players and allowed them to attempt daring mixed strategies without adding any extra rules overhead. Players already had to know all of the rules around how dice could be used, they might as well have the ability to decide precisely how to use them. So a small attacking force could mix in in a single raid die on the off-chance they get lucky. Or, perhaps a bombard could be paired with a few strategic assaults. No matter the complexity of the battle plan, the thing would still be resolved with a single roll of the dice.
Well, what about the defender? Was there any room left for agency on their part? Initially we made a few alterations to try to reward strong defensive positions. For instance, you cannot roll any raid dice unless you control the system. This allowed players to protect their resources in some circumstances and play cautiously. We also found that the defender naturally benefited from the ebb and flow of actions in the game’s general action system. Consider, for instance, an attacker which leads a round with the Aggression 2.
This card has two actions. Because these actions can be used to move or attack, the attacker could use it to move a fleet in and then battle. However, if the defender has a higher attack card, they can immediately counter-attack and likely take the initiative! Even if they don’t have access to a higher aggression card, they could always play any card to copy the attack action, guaranteeing at least one roll of the dice. Because all units could sustain damage, battles in Arcs unfolded over many action rounds. This meant that the question of advantage was often settled by questions of tempo and force strength rather than some structural bias towards the attacker. On a personal note, as someone who has been playing wargames for 25 years, I cannot tell you how happy this made me. We so often take for granted the amount of assumptions we built into our combat models (or really models of any kind). It's a wonderful thing to see a system organically express both attacker and defender advantages without having to put in some rule about winning on ties (sorry, Risk).
---
At this point I think we’ve covered most of the basics of Arcs. Over the past several weeks, I’ve written about the game’s theoretical footing, it’s arguments, it's scope, and many of the actual mechanisms of play. There’s one more thing I want to talk about before the KS launches. A few weeks ago, I mentioned that we are splitting Arcs into two projects. A smaller-single session experience and a campaign system that is fully-modular and expandable. Next week, for our last designer diary, I’m going to take you behind the scenes and write about the design of Arcs as a product and how we came to this decision.
- Cole
Find the original post and discussion on Board Game Geek. Subscribe to the Arcs page to be notified of updates and more Designer Diaries!
Check out Arcs on our website, and find the Kickstarter Campaign here.