A lot of strategy games use a core design that basically boils down to rock-paper-scissors.
If you have three types of units, A, B and C –
– A beats B
– B beats C
– and C in turn beats A.
A, B and C might be called Knights, Cavalry and Archers in your game, but this simple relationship is often the core of the mechanics.
Of course, it’s usually more complicated than this simple ternary relationship, with elaborations like “hard” vs “soft” counters, different costs for different units, tech trees, special abilities and multi-unit type relationships, but this is still a foundational, and fun, way to approach it.
So I thought it would work well in System Crash, being a strategy game in card form, after all. Turns out I was wrong.
This was how I approached the idea of hacking in my cyberpunk CCG, you see. I already had the core gameplay mechanic where you and your opponent would field agents to challenge each other, with unchallenged agents seizing objective points. There are a range of cards to help you dominate in agent-vs-agent combat, cards which strengthen your agents while weakening or eliminating your opponent’s.
So with hacking, I thought it would be cool to create a set of cards which achieve victory by a different route. Hacking cards, I decided, would circumvent agent combat entirely. Fits the theme, right? A hacker fights in cyberspace, not ‘meatspace’.
But, how to balance it? If you can simply circumvent agent combat, why would you ever not? Well, I decided, the hacking cards are less efficient at scoring points than unchallenged agents are, for the same price. That way, if you decided to forego agents to load your deck with hacking cards, you’d lose the race to victory to someone who pumped out agents. Hacking is powerful, yes, but you need to do something to handle those pesky agents or you’ll never get to complete your hacking run.
So I added in cards that are basically delaying tactics for hacker decks. Smoke grenades and electronets, cheap blocker agents that you could clog lanes with while your viruses tunnel into the enemy corp’s servers.
It worked perfectly. Hacking by itself isn’t that strong, the agents with the hacking ability are universally weaker than the other agents of their cost tier, so going pure hacking doesn’t win you the game. But combining hacking and the delaying cards? That was an extremely powerful combination. If a combat-agent deck was scissors, the hackers-with-cover deck was rock.
Ok, so that worked as intended…but then how to prevent hacking from being an optimal strategy? In a strategy game, you really want to avoid there being a “best” strategy or build, as it kills the fun of gameplay once discovered.
So I decided to add a paper to hacking’s rock. A counter-hacking cardset, one which shuts hacking down hard. Thematically, this would represent corporate firewalls and ICE (Intrusion Countermeasures Electronics, in the Gibsonesque parlance), stuff specifically designed to keep hackers out.
Most of these defences would be passive, a virtual wall in cyberspace. Since the hacking deck’s delaying tactics tended to be short-term, a temporary wall erected against hacking would give a defender enough time for those delaying tactics to run out of juice and leave play, after which the defender’s stronger combat agents could rush in an mop up the hacker’s OP.
And that worked out well. Counter-hacking decks shut down hacking tactics handily and stomped on the frail hacker agents without much trouble. It helped that, for the price, counter-hacking cards were just slightly more efficient than the hacking cards.
But…now the problem with this design (at least for a CCG) came to the fore.
In an RTS, the rock-paper-scissors design works because you and your opponent can both adjust your strategies after every skirmish, and the entire course of the war isn’t (most of the time) determined by a decision made before you’ve even made contact with the enemy. Your base structures also often provide a hard-counter to early tech units, giving you a place of safety to retreat to and recover/adjust. For a skilled player who scouts and harasses, this is enough to prevent a single bad build decision from dooming you.
You also have the ability to directly choose which units to produce and, more importantly, when to produce them in an RTS. If the enemy approaches with cavalry, then and only then can you decide to start cranking out the pikemen to counter this tactic.
In a CCG, you have to ‘front-load’ that kind of decision making to the deck-building phase. Committing to hard-counter cards mean that if the enemy doesn’t field the type of units you’ve chosen to counter your hand is bloated with useless cards.
Which in turn means that when designing AI encounters, I either have to give the AI counter-hacking cards which make it less effective vs the player who doesn’t build a deck around hacking, or I don’t give them those cards and they get roflstomped by hacking decks every time.
I ended up going for half-measures. Putting in a few anti-hacking cards which sometimes, if the AI is lucky on the draw, helps it out vs hacking, but also don’t bloat their deck with too many useless cards if the player isn’t a hacker.
For the player, this is less of a problem. The player, you see, can treat the entire campaign as a learning experience, a series of skirmishes. Fail a mission because your enemy has certain card types? No problem, build a different deck to counter that, try again. The poor AI doesn’t have that option. It’s a static challenge.
If there were multiplayer in the game (I’d like to add it in an expansion), the rock-paper-scissors design would again be problematic. You don’t want people playing blind against a random opponent and realizing that said opponent has a rock to their deck’s scissors, and quitting prematurely.
The solution, then, was to go back to the drawing board. The rock-paper-scissors design was the problem, that relationship needed to be changed, or at least diluted a bit.
Turns out hacking itself isn’t broken, once the delaying tactic cards were made a bit less powerful. Counter-hacking cards, they were more of a problem, their focus too narrow, too circumstantial. The solution then was to broaden that scope.
In the next build, the ICE cards no longer just block direct hacks from scoring points, they now also block the point scoring of unblocked agents in combat. This makes sense, thematically. The idea there is that unblocked agents are attempting to access corporate servers via internal terminals, bypassing some of the server’s security. ICE cards, then, are locking down those servers against unauthorized intrusions in general, whether from an internal subnet or an external source in cyberspace (hackers).
DotNuke also had its scope broadened, where previously it was a hard-counter against software tactics only, now it is a hard-counter to any tactic card, just as Assassinate is a hard-counter to any non-mech agent. This makes it a useful addition to just about any deck.
The results of these changes, from my playtests, are pretty positive. You can still focus on one of the types of strategies, but doing so isn’t as much of an “all or nothing” scenario as it was before.
This is all just one example of how one design decision leads to another, and another, in a chain that can take you places you didn’t plan on going. Places which are non-obvious just from your design documents. Some aspects of your gameplay mechanics’ interactions are revealed only by directly play. They must be experienced, and at a deeper level, felt.
That’s why it’s important to iterate, iterate, iterate.