Build-a-mechanic: Protect creature
Hello! Today i’ll be talking about custom mechanics with one that i created years ago and eventually scrapped. Disclaimer: all of these cards are quite old and i couldn’t find the artist for most of the images, so those won’t be going to the Multiverse gallery.
First it’s important to separate two concepts, keywords and mechanics. To put it simply, the keywords are what identify the mechanic but are not mechanics by themselves. As a straightforward example we have the keyword “Flying”, that represents the mechanic “Can’t be blocked except by creatures with flying or reach” (this particular one creates some neat recursion if you keep replacing the keyword; don’t think about it too much).
Often, but not always, the mechanic is what you see represented in reminder text. It may also not have a keyword at all and just be recurring rules text, like “When this deals damage to a player, draw a card.”
This distinction is important, because when i say i’m building a mechanic i’m not just creating a keyword for something that already exists. That’s not to say i don’t do that, though:
I don’t do many of these and sometimes end up discarding the ones i do make, but every now and then comes a recurring mechanic that i feel could be keyworded. Before lifelink came along i coined the term “lifetap” for the mechanic, for example, which in retrospect is rather flawed. Anyway, i digress. Let’s talk new mechanics. What i want to show you today is something i named Protect creature:
Can you already tell why i ended up scrapping it? This is the simplest french-vanilla common version of the mechanic, and its reminder text fills up the entire card. Not only that, having a name similar to an existing keyword (protection) would surely be confusing as well. Let’s see what we can scrap from it, though.
In simple terms, what i wanted to represent was a familiar, as shown by its supertype (note that having both a supertype and a keyword to represent a single mechanic is overkill). I wanted a creature that served another creature, be it as a guardian like the one above or as a mount:
The familiar is still a creature, however, and common rules apply. The flavor is that the creature is at the mercy of its master – the creature it attached to. It’s still a creature but can only attack when ordered – by tapping the master creature – and it blocks incoming attacks against its master by transferring combat damage to itself. Two major issues that i did not see upon creation are that, as the mechanic is written, both creatures need to tap for the familiar to attack, and both creatures need to be untapped for the familiar to block. What i intended upon design was having the master attack and leaving the familiar untapped to protect it, or sending it to attack while staying behind.
The second main feature of the mechanic was that often the familiar would grant some sort of bonus to its master. In the example above, Chocobo granted haste to the creature it attached to aside from protecting it. This raises another problem, which is one-sided abilities:
In the example above, the familiar has flying itself but does not grant flying to its master. Having some creatures be two-sided and some not is an easy way to bring about confusion and needless double-checking.
Does any of this sound familiar? The reason i’m showing these off today and not hiding them in my hall of shame somewhere is that two official mechanics that appeared later in the game actually share some aspects from this one: Totem Armor and Soulbond. I was surprised to discover this when looking at them recently, but the mechanic i tried to build is at its core a sort of mix of these two. Totem Armor is exactly the kind of protection i was trying to go for while Soulbond has the two-sided bonus granting and creature pairing. It’s awesome to see down the road that i wasn’t going in a completely dead direction.
Under this new light, let’s look again at all the flaws and see if i can remake the mechanic into something playable:
- Length: both mechanics are a bit long and slightly complex; joining them in one is not the best of ideas but there’s not much i can do to simplify them.
- Supertype and keyword: this one’s easy, just drop one of them. I feel that the supertype works better so Familiar Creature it is. The way this works is similar to the way Werewolves work: once you know the mechanic you can just skip the initial wall of text, since it’s the same for all of them.
- Dependancy of attacks: rather than the overly complex system of tapping one to tap the other and switching blocks, i’ll be taking Totem Armor’s simple route here: if damage were to be dealt to the master, it is dealt to the familiar instead. Other than that, the familiar is a perfectly normal creature.
- Bonus granting: here i’ll take a cue from Soulbond and have both creatures be affected by simple abilities. I believe i can expand on that, however, as long as i’m careful with the wording.
This is what i ended up with:
Here are illustrated the basic mechanic (still extremely long…) and the two-sided bonus granting. Note i mostly used the soulbond wording to make sure it worked. I want to clarify some rule jargon, that i believe to be correct, though:
- The familiar is paired with another creature as it enters the battlefield. However, since there is no “if you don’t” clause, it is legal for it to enter the battlefield unpaired. If it does, the “at any time it would become unpaired, sacrifice it” clause triggers and the familiar is sent to the graveyard. Abilities that note the entry of creatures to the battlefield, such as Soul Warden‘s, trigger, as do ones that note the death of creatures. I believed this to be the best route rather than having “sacrifice it” show up twice, first upon casting then while on the battlefield.
Finally, here are a couple of examples of single-sided abilities that i believe to be non-confusing:
Since the familiar cannot exist unpaired i can take its pair for granted, so i believe there is a lot of design space there.
At any rate, this is my mechanic. Whether i managed to redeem it or not is not for me to judge, but i’m quite fond of the journey it had. Until next time!