Emergents TCG requires its players to play a card each turn in order to build resources. You learn by doing.
This is made possible by the wildcard mechanic. Wildcarding means that you can play any of your cards on any of your turns, should you be so inclined.
That still leaves several problems.
Many of the things one does in a card game are inherently reactive, or depend on waiting for the right time. What happens if you have cards that kill characters, but there’s no one there to kill?
Also, as a mobile-ready game, it was imperative to minimize the number of interaction points in the game, without giving players free reign on their turn. There still needs to be the possibility of surprises.
Our solution to both these problems is to separate the playing of actions, when you pay their costs and use them to build resources, from deploying actions, when you use them to impact the game.
The Grand Plan
By default, when you play an action, nothing happens right away. The action remains facedown in play.
You could (in most cases) choose to deploy that action right away. Or you can hold onto it, and deploy it in the future, for free, at any time you can play actions. Our interface lets you drag the card either directly to the center of the screen, in which case you will play the action and then deploy it, or to the left of the screen, in which case you’ll play it but not deploy it until the time is right.
Your rival will know which faction the card is, and have an idea of how many resources you might have paid for it, but even in the initial set that will always leave multiple possibilities. We won’t tell your rival how much you spent, because we don’t want them to have too good an idea of what you have waiting for them.
The dynamics this creates are very different from the dynamics of other card games, especially for removal cards. Being able to play removal in advance, and then use it when the right target shows up or the time is right, is a big change. This in turn allows us to make our removal spells more expensive, while still making them cards worth playing.
This system also solves the problem of how to have interaction on the rival’s turn and create uncertainty within combat. Not all face down cards will sit patiently until you choose to turn them face up, or even wait until it is your turn to act. Some of them are traps.
If My Calculations Are Correct
Figuring out we wanted traps in Emergents was easy, even overdetermined. Getting traps right is tricky.
In games where cards supersede the rules and almost anything not only could happen but eventually will happen, few things are easy. Everything has to be precisely defined, in a simple way that fits onto cards that regular people can read, and that makes intuitive sense and doesn’t leave players feeling confused or cheated.
Let’s take the first trap that I tried to create. It’s likely the first trap that a lot of people would try to create: A combat trick. You’d like to make something like this:
Win The Fight
Trap: When your attacker would lose a fight, but deploying this would make you win the fight, your attacker gets +3 attack and +3 health until end of turn.
Actually, the first design was more ambitious than that, and included letting the player choose various definitions of win and lose, and whether they cared about saving their character, killing the rival’s character, or would wait until both, and potentially had other stuff going on. It’s good to have goals.
Then you tell this to Alan Comer, who is in charge of writing the rules engine so the game actually works, and he explains some of the ways that this absolutely will not work. A fun exercise would be to stop here, and see how many of them you can think of before proceeding.
First, he asks you to define what it means to ‘win’ or ‘lose’ a combat. This is not as easy a question as it sounds. Any definition that covers all corner cases is going to be paragraphs long with a lot of subclauses, and probably still miss something. Sometimes it’s going to give a non-intuitive answer. Players definitely aren’t going to fully understand it.
Second, that’s the easier problem. You can, if you want it enough, define what it means to have won a fight. I was trying to do something even trickier, which is define what it means when you’re going to win a fight. In the future.
You might think, as I initially did, that this wouldn’t be a substantially different problem. Run the game engine into the future without anyone doing anything, and see who wins the fight. Nope. Can’t do that. For technical reasons, it doesn’t work.
What you can ask are things like who has an attack value greater than or equal to something else’s health, but you can’t ask the rules to predict the future and act accordingly. It sounds like it should be easy, but it doesn’t technically work. So you have to fall back on simple, well-defined conditionals (like attack less than health) with the understanding that various abilities and effects will render your guess wrong sometimes.
Then there’s the question of what happens if there are multiple such fights happening at once. Which one do you choose? One answer is ‘it’s random’ which is simple but can also be unsatisfying and potentially enraging. Another answer is ‘the most important one’ but then you need to define what that means, and you’ll often get it wrong, and if you try to frequently get it right then your algorithm will be hard for players to properly predict in situations where the right answer isn’t obvious, and you’ll still sometimes get it wrong. Plus the more complex rules you add, and text you effectively add to the card that isn’t written on the card, the less the players understand about what’s going on, and they stop having all the fun.
Thus, after many hours, we still couldn’t figure out a satisfying way to make this simplest of all traps work. There were many solutions, but all of them fell short in one way or another. That doesn’t mean the game doesn’t include offensive combat tricks, but it does mean that we’ve given up on them being as elegant and satisfying as we’d like them to be.
What we did instead was make something that had a variety of interesting effects, understand it will often happen at “interesting” times, let that be part of the decision on when and whether to play it, and let the chips fall where they may. So presenting: Strength Training.
If you could choose exactly when Strength Training would and wouldn’t happen, including during combat, we wouldn’t be able to price it at 3 resources. Not giving you control has its upsides.
It’s a Trap
A rule that ensures a trap will trigger when you want it to, but not when you don’t want it to, threatens to balloon quickly. Whenever possible, we kept things simple, even when it wasn’t the exact thing you would most want, and adjusted the cost accordingly.
This could be considered the simplest possible trap with the maximal amount of the trap nature:
A card is a trap if and only if it has a trap trigger. Here it is simple – your rival deployed a card, any card. You’re not about to let that happen.
If your rival sniffs this out, they can answer it by deploying something cheap and/or irrelevant first, and get this out of the way. The ability to play actions first and deploy them later helps you sequence your cards to minimize the damage here.
Note that if you play two copies of Counter at the same time, you are going to be quite sad, because both will deploy at the same time and the second one will be wasted. Traps are not, by default, ‘intelligent’ enough to avoid such mistakes. Rather than treat this as a bug, and add a ton of complexity to fix this, we’ve embraced it as a feature. Part of the puzzle of traps is figuring out simple triggers that create interesting decisions for players, and part of the skill of traps is deciding how and when to use them to get as much value as possible.
Now contrast Counter, which can stop anything, with a card that in many other games would be much worse, but in our game might turn out to be better:
If you were choosing when to deploy or not deploy both cards, Counter would be much, much stronger than Recount. Recount only works when your rival has spent down all their resources, which they can often avoid doing, whereas Counter works every time. Counter happens when the card is deployed rather than played, so you have more time to get it ready. There’s no way these two cards would have almost the same resource cost.
However, in Emergents, Recount is likely to hit expensive cards and highly unlikely to hit cheap cards. You can play around it by holding onto one of your generic resources. In an ideal situation, you can spend most of your resources, then spend the last bit on something cheap and unimportant and see what happens. But what you often cannot do is run a quick check to see if Recount is there.
We’re still balancing our initial card set, so it’s possible one of these cards will end up costing more generic resources than the other. But I don’t have a strong favorite for which one it would be.
Between reactive cards that you can pay for now and use later, and other reactive cards that are traps and not entirely under your control, and all the resulting bluffs and other mind games, Emergents opens up a space that hasn’t been properly explored before. We look forward to seeing what it can do.