(Metagame Archive) Design Vs. The Hidden Area

By Danny Mandel

By the time you read this, the entire Marvel Knights expansion will be spoiled. Many of you will have played in Sneak Preview tournaments around the world and gotten your first taste of concealed characters and the hidden area. (For those of you who haven’t yet gotten a chance to hold some of the new black-bordered characters in your hot little hands, well, be patient.) So this seems like a good time to explain how the concealed mechanic and hidden area came to be.

Dr. Humpherys and Mr. Hide

 

About a million years ago I wrote an article discussing a bunch of random design stuff. That article also included a section where Dave Humpherys (one of the Vs. Developers and an all-around crappy guy) explained how he designed the evasion mechanic, which debuted in the Web of Spider-Man expansion. In that passage, he said the following:

Evasion’s Twin Sister

 

When I first came up with evasion, I also had another mechanic in mind. The team liked the other one so much it went on to become the core mechanic of the fifth Vs. set. I hope Danny lets me guest-write in his article again when that set comes out. Danny is so awesome!

Well, I’m not going to let him guest-write this time (mostly because it wasn’t really him talking last time anyway), but I will give you the skinny on “evasion’s twin sister.” Can you guess what it is? Concealed? The hidden area? 

Stop! You’re both right!

When Humpherys designed evasion, he had also come up with another character power, then called “hide.” (Notice, hide is simply a keyword found on a character. The idea of a separate hidden area was not yet getting tossed around.)

Hide only had one simple rule:

1. A character with hide cannot be attacked.

The obvious problem was, what happened if a player controlled only characters with hide? Did that mean the player couldn’t be attacked? Well, that would be a Bad Thing®™. This led us to create a second rule:

2. If all of a player’s non-stunned characters have hide, that player can be attacked directly.

Of course we still needed to sort out what happened if you had a character with hide protecting another character. This led to rule #3:

3. A front row character with hide does not protect a character behind it in the support row.

At this point (and by “at this point” I mean “at some point,” because I can’t remember when exactly this took place), we took a step back and looked at the two mechanics we were considering for the Web of Spider-Man expansion.

Evasion (in case you forgot):

Stun this character >>> At the start of the recovery phase this turn, recover this character.

Hide

1. A character with hide cannot be attacked.

2. If all of a player’s non-stunned characters have hide, that player can be attacked directly.

3. A front row character with hide does not protect a character behind it in the support row.

Notice both mechanics share the underlying principle of allowing your characters to avoid getting attacked often at the expense of your endurance total. Evasion trades a stun now for a recovery later. Hide makes it much more likely that you’ll get attacked directly. Of course, there are game-play differences between them:

A character with hide simply cannot be attacked. Period. A character with evasion can be attacked, but partway through the combat, its controller can choose to have it evade. This gave the player more options and made evasion more versatile.

Using a character’s evasion usually means that character won’t be able to attack later this turn. On the other hand, a character with hide pretty much gets to attack every turn if you want.

A character with evasion is more versatile outside of combat. Unlike a character with hide, it can evade a Flame Trap or a blast from Gambit or Roy Harper.

There were other factors that weren’t related to gameplay that we considered when weighing the merits of the mechanics.

The primary weakness of evasion (at least in my opinion—this was hotly debated) is that it compresses a fairly complex payment power into a keyword. (Of course, this issue bleeds into the topic of reminder text—you know, the little parenthetical text that clears up possible rules questions or explains what a keyword means. I’ll go into keywords and reminder text at a future time.) 

Similarly, the primary weakness of hide (again, in my opinion) is that it’s got three separate rules that all have to be compressed into a single keyword.

Ultimately, we decided to go with evasion for three reasons. One, we felt it was easier to explain to players. Two, as I mentioned above, it felt more versatile during game play. Three, the idea of a character jumping out of the way just felt right for the Spider-Man set.

So what did we end up doing with hide? This is what.

Out of the Darkness: The Return of Hide

 

Brian Hacker and Dave “Killer Whale” Smith did most of the design work on the Marvel Knights expansion. One of the early mechanics they were using was called “enshrouded.” It represented how many of the characters in the set were vigilantes, hoodlums, or other denizens of darkness. Here’s how it worked:

1. A character with enshrouded cannot be attacked.

2. If all of a player’s non-stunned characters have enshrouded, that player can be attacked directly.

3. A front row character with enshrouded does not protect a character behind it in the support row.

Notice anything familiar? Now, I’m not sure if Brian and Dave knew about Humpherys’s hide mechanic when they came up with enshrouded (you see, they weren’t really around way back when Hump came up with hide) or if they came up with the idea all by themselves, you know, kinda like parallel evolution. What I do know is that they had been doing a lot of testing with it, and it was playing very well.

Before I go onto explain how enshrouded morphed into its final form, I think this seems like a good place to talk about some of the merits of enshrouded characters (or characters with hide).

 

Enshrouded keeps utility characters safe

The Vs. System is a “direct attack” game. By that I mean, it allows one unit to directly attack another unit. One the plus side this is thematic, as superheroes should be bashing supervillains into oblivion. But sometimes, direct attacks make it difficult for the designers to create undersized characters with cool powers. Basically, little utility dudes just get smacked around by their brawnier (though often less interesting) cousins. Enshrouded was a way to keep utility characters safe. This opened up a lot of design space to explore.

Enshrouded takes pressure off of the initiative

Many games of Vs. follow the rhythm of the initiative: I hit you, you hit me, and so on and so forth until one of us falls over. And “stealing” an opponent’s initiative via a Mystical Paralysis or blast from Roy Harper was insanely powerful. Enshrouded really shakes things up. Suddenly, you have characters that can smash every turn regardless of initiative. This enables some more aggressive rush strategies, which help combat the tendency for players to build on-curve decks.

Enshrouded speeds up games

For two reasons: One, with less characters “guarding” your endurance, there are more violent attacks, especially in a matchup involving enshrouded characters on both sides. Two, since you couldn’t attack enshrouded characters anyway, you had fewer attack options, which often sped up each player’s attack step.

 

Enshrouded was very flavorful

While the word “enshrouded” might not have been perfect, we were pretty happy with the way the mechanic felt on certain types of characters. We had dark vigilantes like Elektra, mentor figures that operate from behind the scenes like Stick or Professor X, crime bosses like the Kingpin, shadowy ninjas like the Hand, and of course, demons. Talk about a set that wants to represent hidden characters!

Enshrouded allows for new types of disruption

This one’s more of a given, in that whenever we create a new mechanic we get to introduce stuff to mess with that mechanic. For example, every card in the Superman set that involved kryptonite could remove cosmic counters. By having enshrouded characters, we could create cards that removed enshrouded from them (allowing them to be attacked) and cards that specifically allowed certain characters to attack enshrouded ones.

So yeah, enshrouded was working out, but over time and testing, some new issues came up. First of all, it turned out that allowing low-cost enshrouded characters to reinforce was pretty annoying. Often for the investment of one resource point, you had a Burn Rubber every turn if you wanted. This led to adding the text “(This character) cannot reinforce” to many enshrouded characters. 

Second, we realized that equipping a low-cost enshrouded characters could degenerate. Suddenly a Flamethrower’s drawback (if the equipped character becomes stunned, you lose the weapon) was easily ignored. This led to adding the text “(This character) cannot be equipped” to many enshrouded characters.

Because many of the enshrouded characters shared the same two restrictive lines of text (no reinforcement and no equipment), there was a long discussion about language compression and the role of keywords. In short, it went like this.

Some members of R&D felt that since almost all enshrouded characters should not be able to reinforce or use equipment, we should just add those two rules to the rules of enshrouded. This would mean the rules of enshrouded would now be:

1. A character with enshrouded cannot be attacked.

2. If all of a player’s non-stunned characters have enshrouded, that player can be attacked directly.

3. A front row character with enshrouded does not protect a character behind it in the support row.

4. A character with enshrouded cannot reinforce (we also added or be reinforced).

5. A character with enshrouded cannot be equipped.

The camp on the other side of this issue argued that, not only is that a lot of information to cram into one keyword, but while the first three rules all sort of went together (they all dealt with attacking), the last two functioned solely as a game balance and did not intuitively fit together with the other rules.

So we had two options, neither of which made us happy:

1. Take up tons of text box space with two restrictions on nearly every enshrouded character.

2. Cram a couple of non-intuitive rules into an already complex keyword.

Fortunately, in that very same meeting, we came to a solution. I’d mentioned that maybe enshrouded characters weren’t allowed to be in the same column as non-enshrouded ones. I figured this would make rule #3 less important, and it kind of helped with the reinforcement problem as you’d never have an enshrouded character directly behind a non-enshrouded one. I quickly dismissed the idea because it wouldn’t really help enough.

However, a few minutes later, Ben Rubin (another member of R+D—I like to think of him as the cool Humpherys) had an epiphany. He suggested we make it so enshrouded characters weren’t even on the same side of the board as non-enshrouded ones. We all sat there for a few moments . . . and then we started walking through the implications.

By having enshrouded characters in a separate area, they wouldn’t be adjacent to non-enshrouded ones, and therefore reinforcement would automatically be impossible. We’d have to make a rule that said you (normally) couldn’t have equipment in the enshrouded area, but that would be a rule about the area, not the character power (a subtle, but important point).

Also, the concept of a new area brought with it other happy things.

One of the problems with enshrouded characters (before we introduced the new area) was that sometimes you’d forget a character was enshrouded. You’d plan out your attacks, and then right in the middle you’d realize one the characters you planned on bashing was enshrouded. It was very annoying. Fortunately, with the enshrouded area, this was no longer a problem. The unattackables were clearly separated out.

As I mentioned above, the enshrouded mechanic opened up design space simply because we could make cards to mess with it. Now with an entire new area to play around in, we opened up even more design space. Before, we could pretty much just make cards that could give a character enshrouded, take away enshrouded, or pretend to take away enshrouded (by allowing characters to attack enshrouded ones). Now we could treat movement between the areas (which is similar to what gaining or losing enshrouded meant) as a cost, like on The Rose, Shadowy Lieutenant. Also, this made movement in general more interesting, as a card that read, “move a character you control to your visible area,” could act as a simple movement card by moving an already visible character, or it could act as a way to move a hidden character into a defensive posture in your visible area.

Viscerally, the enshrouded area just felt better than slapping the word on the characters. Now your demons and crime bosses were actually separate from the normal fighting. They could pick and choose their battles, or even spend the whole game in hiding.

One other positive thing the enshrouded area allowed was that we no longer had to compress a ton of rules onto a small keyword on individual characters. Don’t get me wrong, there’s still a lot for a player to learn about the hidden area, but once you get it, you’re gold.

There were still a few more details we had to nail down on the enshrouded area. First we had to come up with a better name—enshrouded just wasn’t cutting it. Eventually we settled on the austere “Hidden Area.” It may seem a little generic, but in truth that’s what we’re going for. First of all, making it a simple term (or pair of terms, hidden and visible) makes it easier for a player to understand. Second, by keeping the term broad, it allows us to use hidden in lots of different thematic avenues. For example, in the Marvel Knights expansion, the hidden area often represents the dark underbelly of society, but in a future set it could represent the Negative Zone or Asgard or the Anti-Matter Universe.

Once we moved enshrouded (or hidden) off of the character and onto an area, we then had to put a new keyword on characters to explain that they came into play in the hidden area. Eventually we settled on “concealed” and a very simple piece of reminder text to accompany it: (This character comes into play in the hidden area.) And notice Humpherys’s original mechanic (hide) has now been split into two mechanics: the hidden area and the concealed keyword.

Finally we had to decide if we wanted something special to visually remind a player which characters had concealed. We discussed a new icon, but once we saw the black-bordered characters, we were sold. The dark border had the added benefit of usually reminding players which area was hidden during gameplay as well (unless, of course, a concealed character got moved to the visible area or vice versa).

Okay, that’s all I got on the creation of the hidden area. Send questions or comments to dmandel@metagame.com.

And come back next week for a look at rewriting history.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: