(NOTE: This is a mirror of an article I posted to my blog on October 18, 2022.)

What is this?

Enmity Engine is a 2-player fighting card game that adapts the battle system of the Pokemon video games to tabletop. Both players have 3 Fighters and a deck of Poker cards, which are used to activate their Fighters’ moves with the goal of defeating their opponent’s Fighters. It is now available for purchase via DriveThruCards.

Check out its page on this site for more info, rules PDF, and free print & play!

To celebrate Enmity Engine’s release today, I thought I’d put up a design diary detailing how I went about adapting Pokemon to work as a physical, analog card game. For the most part, I’m going to assume that anyone reading this is at least somewhat familiar with Pokemon’s battle mechanics, but if not I recommend giving at least one of the games a go. They’re pretty fun.

Nailing down basic gameplay

I realized early on that fighting card games like Yomi, BattleCON, and Exceed are pretty similar to the Pokemon video games. Each card represents a move, you have a hand of said cards, you pick one and put one face-down, your opponent does the same, and when both players are ready you both flip your cards to reveal your moves. Whenever I’d recommend one of these games to someone looking for a Pokemon-esque board game, they’d kinda shrug off the suggestion or not believe that my recommendation is even applicable, which is partially what inspired me to make this game.

Every once in a while, I’ll run into someone online that’s also making a Pokemon-esque game, and they’ll usually come to the same conclusion about how move selection should be handled. Players get a team of ‘mons, each ‘mon has a list of moves indexed 1-4, each benched ‘mon also has an index, and players will get a hand of cards corresponding to each of these indices. Players put one of these cards face-down, then reveal to activate a move/switch to a benched ‘mon. After a player uses a card, it goes back to their hand. Functional, but kinda boring. At minimum, I wanted my game to have some kind of hand management element to it, or anything that leverages the fact that it’s a physical card game. While the goal was to make something that feels like Pokemon, the actual Pokemon games are still there, and nothing’s stopping people from just playing those. It needed something to differentiate itself as a distinct experience that’s worth playing as opposed to being just "Pokemon but kinda tedious and worse".

Image: Solis Game Studio

Enmity Engine has gone through multiple iterations as I tried to figure this out. I tried things like a Pocket Paragons-style system (or Concordia/Century: Spice Road if you’re a boardgamer), where players have a hand of cards that get discarded on use but also have a “get all your discarded cards back” card, or a Smash Up-style system, where players choose x creatures and mash their cards into a deck. At the same time, I wanted to add some kind of move customization. I was pretty enamored with Sakura Arms at the time, because of the way setup worked in that game: Both players pick 2 characters, which come with their own pools of cards. After looking at their opponent’s picks, they make a 7-card deck from their own character’s pools in response to their opponent’s probable game plan. It’s a pretty clean system, and I wanted that kind of counterplay in my game.

I spent way too much time bashing my head against the wall to make any kind of character customization work. The Sakura Arms system wasn’t working playing well with this game, neither was just having normal constructed decks (a la Magic the Gathering). I even tried adding a deckbuilding engine (a la Dominion or Star Realms), which would’ve allowed players to adjust their move pools on the fly. Eventually, I had a moment of clarity where I remembered that I personally don’t like deck customization because it’s incredibly tedious and requires a lot of prep work, which is less time spent actually playing. One of the reasons why I love playing fighting card games like Exceed and Yomi is how little time it takes between pulling the game out of your bag/shelf and playing the game, so I decided to minimize the amount of customization to just picking your team of Fighters.

Another issue I ran into was what to do with move cards from Fighters that have been defeated. If the Fighter that corresponds to a move card isn’t around to use it anymore, it’s kinda just sitting there being dead. Worse, in systems where players have draw decks, losing a Fighter means that you’re also suddenly at a resource disadvantage, which can cascade and cause you to lose even more, making even one loss fatal. I experimented with various ways Fighters can make use of their defeated allies’ cards, none of which felt good, and I didn’t want to do a “oh I drew a card that belongs to a thing that died so I’m gonna remove it from the deck and draw another card” type deal, because that can get incredibly tedious. At this rate, it looked like I was gonna end up defaulting to the same system that all the other designers landed on.

Image: Algernon Product

My main breakthrough happened when I learned about a little Japanese game called Trick Gear. I won’t go into too much detail on how the game works, but each player gets a Poker deck and controls a character that has a menu of effects that are activated by discarding cards of specific Poker suits. There are 4 suits in a Poker deck. Pokemon has 4 moves per ‘mon. This was what I was looking for. I could assign a move to each suit, and have the higher ranks (J, Q, K, A) be used to allow players to Switch. Since players now have a deck of cards to draw and discard cards from, I can add all kinds of resource management mechanics for a richer play experience. I also happen to have a small collection of Poker cards, so the idea was particularly appealing to me.

Ironing out the details

Something that’s easily overlooked about Pokemon by casual players is that it’s inherently a game about controlling the flow of information. Each Pokemon has various stats that can be configured in various ways. You don’t know whose ‘mon is faster, you don’t know if they’ve allocated their EV points into their offenses or defenses, you don’t know which 4 moves they have, etc. There are probable options for each Pokemon, but going into a match you won’t have 100% information on what they have. You just have to play through the match to find out. This is a huge source of tension, as you’re operating on a deficit of information, and have to make decisions based on what are essentially guesses until you can suss out some solid information. Fighters in Enmity Engine on the other hand have all their statistics out in the open.

Enmity Engine retains this tension despite the near complete removal of fog of war by taking a page out of fighting card games. Instead of having stats be coupled with the Fighters themselves, the stats are coupled with their attacks. In Pokemon, a faster Pokemon will always act first, regardless of which move they use or how powerful said move is, or a tanky Pokemon will always have high defenses, again regardless of their move choice (yes, I know about priority moves and defensive moves like Protect, but you get the idea), but in Enmity Engine you’re faced with the uncertainty of whether or not your opponent is using a fast attack, or a defensive attack, or a high-powered attack, etc.

Another advantage to this is that it makes evaluating matchups more accessible. Effect-heavy card games have a tendency to feel very random and luck-based to first-timers because they don’t know enough about what’s in any given deck to make informed choices, especially to prepare for or counter their opponent’s big, splashy plays. Some games like Twilight Struggle even have a reputation for being unwinnable for new players against even slightly experienced players because of this. By having all of both players’ effects out in the open, even new players can engage in the kind of strategic decision-making that you’d find in high-level play. This does unfortunately come at the cost of front-loading a lot of data, which some players may find overwhelming, but I personally feel that it’s a worthy tradeoff.

Resource Management Systems

Pokemon doesn’t really have a resource system to speak of. It does have several little ones, like PP (wow, you only get to use that move… 15 times) or once-per-game mechanics (eg: Mega Evolution/Dynamax/Z-Moves) but nothing that really has its roots stuck into every other aspect of the game. For the most part, Pokemon doesn’t really want you to worry about managing these things.

Enmity Engine on the other hand is a card game, and I think people that play card games generally like thinking about managing resources so I wanted to lean into this aspect. Since the game runs on a deck-based system, I can play around with having players draw and discard cards in various ways, and since players use Poker decks, I could play around with effects that look for specific formations of cards.

The resource system as-is came off a bit limp and it felt like it wanted some kind of secondary resource mechanic. One of my friends told me that she wished that the cards did something else after they were used as moves, instead of just being discarded, and there was a fighting card game that did just that: Exceed. In Exceed, whenever a player successfully hits their opponent with an Attack, their Attack card goes into a specific zone, where it can later be spent on higher-powered actions. I thought it was a good fit for Enmity Engine, so I threw it in, so now Attacks generate Insight when they deal damage.

With this addition, two mechanics were added: Awakened Forms, which come into play when a player spends Insight to upgrade their Fighter's abilities, and Signature Moves, powerful finisher moves that require Insight to be spent to activate. These were admittedly also lifted from Exceed. I hesitated to do this because I wanted to avoid just copying huge chunks of another card game, but they ended up being such a perfect analog to Pokemon’s Mega Evolution and Z-Move mechanics, and flowed so well with the rest of the game that I couldn’t justify removing them after testing them.

Pokemon is balanced around Mega Evolutions and Z-Moves (and, now, Dynamax) being used only once per battle, but with the addition of a high-friction resource system, I can justify allowing Enmity Engine’s analogs to be used multiple times, with varying costs depending on their strength. Mega Evolutions were generally well-received by the competitive Pokemon community, but Z-Moves less so. Z-Moves are very poorly telegraphed, and their only real restriction is that they can only be fired off once. They can happen at any moment, even the first turn, and blindside the player on the receiving end, but on the other hand having them whiff or be successfully parried (often by accident) can be devastating for the user, because they don’t get another chance to use it. Enmity Engine meanwhile allows Signature Moves to be used multiple times per game, so there’s much less riding on successfully landing a single move, and since they require some amount of Insight to activate, they’re much better telegraphed.

RNG

Pokemon has a bunch of uncertainty mechanics embedded in its battle system. Porting over a lot of these elements is out of the question. Having the players pause the game so they can roll a die or something to check if their attack hits or to see how much damage they do can severely bog down the game and be a source of frustration, especially since Enmity Engine is a game about trying to make accurate reads/predictions. It wouldn’t feel good if you took a huge gamble to act on a narrow read and have the opponent make the exact play you thought they would, only for it to fail because your attack had like a 5% chance to miss.

That said, I felt that randomness is an essential part of Pokemon’s core identity, but player randomness and luck of the draw only accomplish so much in injecting the same kind of tension. I wanted there to be a few “Ok, if I make the correct read here, will I get the outcome I want?” situations here and there, so I thought of a way to incorporate a “luck check” mechanic: Concentrate effects. When a Concentrate effect is activated, it names a Rank or a set of Suits (recall that players are using Poker decks in this game). Then the player discards the top card of their deck. If that card’s Rank is greater than or equal to the named Rank or its Suit matches one of the named Suits, the effect successfully resolves. For example, flipping a ♠3 off of a Concentrate♠♥♦ effect results in a success.

This ended up testing well. It doesn’t require extra components or a whole lot of extra steps. You just flip a card over and see if thing happen. More importantly, it doesn’t feel crushingly bad when it misfires, since for the most part the mechanic affects whether or not an effect activates, a bonus. You won’t be seeing a whole lot of “my Attack missed this one time so now I can’t win” situations.

Types

Image: Wikimedia Commons

Pokemon has a system of elemental Types, where Attacks of any given type will be strong (Super Effective) against ‘mons of some type, and Not Very Effective against some others, and neutral against the rest. Since there are 18 Types, they form a fairly complex web of interactions.

Whenever I see someone working on a Pokemon clone, the first thing they seem to do to try to “fix” the game is by simplifying the number of these Types, usually down to around 3. I tried to do the same for Enmity Engine, with 8 Types, but it ended up being pretty boring. When you have a small number of Types, if you want there to be a RPS relationship between them, those relations end up dominating most Type interactions. The reason why Super Effective and Not Very Effective attacks are interesting is that they happen a fraction of the time, in contrast to the majority of Type interactions being Neutral. If you look at the Type chart above, you’ll see that there are more neutral interactions (white squares) than all others combined, around twice as many in fact. These Super Effective/Not Very Effective relations give accent to the overall topography of the landscape of type interactions.

A core part of what makes Pokemon’s battles so dynamic and interesting is the complex RPS relationship between its 18 Types. That said, 18 Types is kind of a lot, so I ended up trimming things and switching stuff around and adding things until I ended up with 14, which is still a lot, but I didn’t feel that having a few Types was an option when the goal is to reproduce the feel of the video games. If you only have a few, you’ll run into a lot of one-sided matchups and it gets difficult trying to dance around giving the ‘mons in your game complete Type coverage (ie: having at least 1 move that’s Super Effective against any given Type). Types having overlapping Weaknesses/Resistances plays a huge role in the Pokemon system’s emergent depth, and you can’t have both that and mostly neutral Type interactions without having a bunch of them around.

Anyway, the reason why a lot of these designers want to simplify Types so much is because it’s difficult to memorize all the ways they interact. As a compromise for having so many of the things in Enmity Engine, I’ve designed the Fighter cards so that they all have a reference listing all the types that they’re weak and resistant to. Not a perfect solution, but it has been effective in preventing playtesters from having to memorize a 14x14 matrix to play the game.

I also changed the amount of damage Super Effective/Resistant moves did. Making players do multiplication/division is out of the question, so I had them give a flat +3 Power bonus/-3 Power penalty. As for dual-types, I just got rid of them. It’s a lot of extra math to process for an analog game, and I’m not a fan of the swinginess of 2x Effective Attacks, and Enmity Engine’s Life and Damage values aren’t granular enough to justify 2x Resistances.

Closing Thoughts

It’s pretty tempting at first to think that converting Pokemon into a tabletop game is an easy task. After all, it is a game made for actual children, but a closer look reveals a rich and deep game with intricate systems and sub-systems, not all of which translate well to analog games. In fact, I ended up having to split this post because its scope was getting out of hand as I tried to write down every change that I thought was interesting enough to write about. That said, I hope you enjoyed reading this, and keep an eye out for Part 2.

(NOTE: I ended up writing pt2 soon after I wrote this but I showed it to a couple friends and they told me that it sucked and was boring to read so I ended up scrapping it.)

Get a copy here!