In the first part we moved the rules of the digital game straight to the tabletop and ran into a jungle of problems. In this second part we take down all these beasts one by one, creating a truly working tabletop game. If you missed the first part you can find it here. The first thing however, is to take a peek at our thoughts on hybrid games that has become an obsession of ours.

Hybrid considerations

With severe problems in our board game we started to look for answers from a discipline we’re familiar with - computer science. Big media companies are building their hybrid gimmicks that combine the digital games with appealing toys, with big success. They have a vision that the hybrid applications are the great future, and so we tried too to come up with that killer app where the physical part is more than an external character selection menu.

Like proper geeks we got consumed by the research. Moving between the digital and physical naturally inspired us to find ways to combine the best of both worlds - which turned out to be a tough nut to crack. The solutions we came up with usually had a ridiculous price tag and in some cases technology just isn’t there yet. Most of the time, after thinking through the ideas further they just ended up being clumsy board games or harder to use digital games. The following, most obvious line of thought was one of them:

We researched cards embedded with NFC technology and a board that can detect the locations of the cards on it. Paired with Bluetooth and Extended Reality the unit statuses can be seen on the smartphone screen when pointing its camera at the board.

Using a projector or OLED board would enable special effects and status updates to be displayed on board. This would further enable resources, domination etc. to be calculated automatically and displayed on the board as well. If connected to the web the board would use the player’s online collection and let them be used as virtual cards. And finally we could enable multiplayer games over the web.

But then again, there’s already Cabals: Magic & Battle Cards, the multiplatform online game that you can play with your friends, so why add costly technology if the functionality already exists?

There were many paths we explored, each of which had a dead end or vanished into the ridiculousness. We got a couple of good ideas but unfortunately awesomeness sometimes comes with a price tag and we had to archive the blueprints for now.

Moving away from the original

After a year of slow development on the tabletop version and adventuring in hybrid worlds we admitted that we need to make dramatic changes to the game. Around the same time Juha Salmijärvi of Revision Games joined our ranks and brought some serious board game design knowledge to our company.

Relics

First thing we threw out were the small tokens that displayed the tile control. The moving of a single unit had too many steps, as one control token was removed from the board and a new one was added to the tile. Moving several units was cumbersome and took more time than making actual gameplay decisions.

My line of thinking is that the amount of mechanical work should be reduced and the amount of decisions affecting gameplay should be increased. Updating the control tokens was a mechanical task that works in the same way every time, and therefore it’s best left for computers. We replaced this with the optional placement of a Relic, being a gameplay decision makes it a relevant and interesting action. If at the start of a player's turn, that player has more Relics on the board than the opponent, a Victory Point is gained. Five Victory Points is enough for winning the game.

Introducing the Relics changed the time and effort spent on the Domination phase. In the digital game, a player gains one Domination point for each special location under control. On tabletop this mechanism was very clumsy. Counting the income each round, adding it to the dice that we used to mark the amount of Domination and constantly forgetting to count them in first place was too much hassle. We managed to reduce all this to a simple comparison that has much smaller cognitive load, making the phase more pleasant and fluent.

The game still has the Resources that need to be calculated at the beginning of every round but being such a central element of the game, we think that it’s ok to leave as it is.

Health concerns

Next in our list of problems was the piling loads of +1, damage and other miscellaneous tokens loaded on the cards.

To reduce the amount tokens we researched the pros and cons of a wound mechanism. This mechanism removed the traditional health and used solely the power to determine battle outcomes. The basic rule was that once receiving two wounds the creature is destroyed. Attack from a creature of higher power also might destroy weaker units with a single blow. The results could be checked from the ingenious list at the side of the card.

With this change we reduced the amount of damage tokens considerably. It took two wounds to destroy a unit, so there was never more than a single wound token on a card. The drawbacks were obvious; boosting units made the comparisons difficult and it took a unit of equal or stronger power to destroy an opposing unit. This made small units obsolete after a couple of rounds, making the game a race for the biggest creature.

So we had to put the wound mechanics to the box labeled ‘Nice idea but not for this game’ and return to the old health -based combat. After the foray into wound mechanics, we decided on a change that is also going to be in the upcoming Steam version; a separate number for power and health. The current digital version uses only one number, sometimes this is very confusing. The decision of using only one number comes from the thinking that most of the creatures have the same power and health and showing it with a single number made cards simpler.

Result of this is that the boosts and damage becomes a nightmare. I mean, what should I think of a unit that has ‘3 -1’? We separated the two values for easier reading and with this change we could drop the stamina mechanics of the digital game - we just added those points to the health and the effect was the same.

We still wanted to streamline the gameplay further and did a short detour examining the armor mechanism. This was a third value on cards that effectively reduced the received damage in the same way that toughness does in the current version. We reduced the health of all creatures considerably and buffed up the armor values. At the same time we got rid of Toughness and added it to the armor. This gave us three values for balancing the gameplay and giving us something that worked between the Wound mechanism and the Health mechanism. And little by little the armor value started to move back to the health value, ending up to the very position we started. The conclusion was to forget the Armor value altogether and revert to the previous version.

Hero Powers

There were also considerations of increasing the power of heroes. Heroes are exceptional individuals and when a hero power is used it should be an epic intervention. At that time we used to flip the hero card upon using its power so we remember that it’s already used, so it was natural to add a secondary hero power to the other side. In the end we had heroes that had powerful primary powers on one side and weak secondary powers on the other side. Each of the powers had ‘FLIP this Hero’ -text, so one could use the secondary power to make the primary power available again. This gave interesting new building blocks for overall tactics, and players were given a choice of which side of the Hero is active at the start of the game.

We added passive powers to Hero cards to emphasise the differences of Heroes even further. These powers acted like global enhancements, but unfortunately they were difficult to remember and reduced the fluency of the gameplay.

Flipping heroes were considered too powerful and led to serious balancing issues. We still like the mechanism and the possibilities it brings to the game - most probably we will visit it in later expansions.

Game Board

Our relentless reworking and reassembling didn’t exclude the game board. The game board was created from the single tiles and was very configurable, but unfortunately it kept falling apart. Puzzle pieces came first into our minds and they would give the same flexibility to the board building. However we decided against it. What we hated was the long setup time of the game and we were looking for a quick way to get the game running.

One thing we considered was to have folding game board containing a 5x5 grid and a few sheets of removable stickers. It was an ok idea but we wanted the game board to be extendable beyond the 5x5 grid to make it suitable for some multiplayer formats. Then it just came from nowhere, pieces that contain more than one tile! Bigger pieces stay in place better. After a short experimentation we felt that using board pieces that had three and six tiles in a formation of 1x3 and 2x3 gave the best results.

Units with Activated Abilities

Next on our modification list was the activated abilities of units. We needed to get rid of the once-per-game and once-per-turn abilities that caused extra bookkeeping or were easily forgotten.

In Cabals there are a couple of cards that have once-per-game abilities without resource cost, like Assassin and Thieving Faeries. They both deal 1 damage to the target unit, Thieving Faeries having a restriction in its skill. In the games we’ve played, those skills were most often used immediately after deploying the unit, so it was natural to change these skills to ‘When deployed’ -skills. The power of these cards lays in the element of surprise after all and the rule of thumb is that if you don’t use the power immediately, you’re playing it wrong.

Skills with resource costs don’t work with ‘When deployed’ -wording and we started making up new keywords. One of them was Boost. Cards with the Boost keyword have an extra resource cost that can be paid when deploying the unit for extra benefit. For example Liquid Servant has a Boost cost of 1 Resource and if chosen to pay, the player draws one card. There are similar mechanics in other card games that give the player the opportunity to spend more for extra effect. The Boost has its problems too. Every card that has boost also had a cost that is ridiculously low compared to the effect. The Liquid Servant is probably the best example of this - draw one card for one resource! This effectively changes the purpose of the Boost from ‘if-there’s-extra’ to ‘every-time-unless-in-deep-trouble’. But no matter which way you think it, it’s a good mechanism and increasing the Boost cost would render it unusable.

Some of the skills with resource costs didn’t work well with Boost, and we created the Upgrade keyword. These skills are different from Boost in a way that Boost generally affects players and Upgrades affect units themselves. In addition, Upgrades have higher Resource costs than Boosts.

Upgrades can be used any time during the Unit’s controller’s turn, but we needed to make sure that this was somehow restricted. We didn’t want to have special tokens showing that the unit has used its ability. What if the very tokens that the skill grants were used as indicator? The example skill text of Possessed Junker became to be as follows: Upgrade 2 Resources (You may use this ability if this unit does not have any enhancements): Gain 2 Health. Then we just needed to define Power, Toughness, Health and Changed tokens to be enhancements.

In the case of Possessed Junker the ability turned out to be stronger than originally thought; As damage tokens aren’t considered as enhancements, the unit can actually regain health points once the ones gained from Upgrade are removed by damage.

Units with Triggered and Passive Abilities

The change from the Domination of the digital game to the Relic mechanics also affected a number of triggered abilities. The digital game has several ways for units to speed up the collection of Domination, all of which we had to replace with a Relic -related functionality

First is the triggered abilities that let players count the unit as a Relic in the next Domination step. We had to consider these abilities carefully, since they are very powerful. Each player has three Relics in use and getting that fourth on the board would mean an automatic Victory Point - and it takes five of them to win the game. When handling such small quantities even slight increases have big effects and offering them too easily will break the game.

Another way to increase the amount of Relics is Homunculus that doubles the amount of relics on the tile it is located at. While having slow strike the unit is easily destroyed but if located smartly it can stay the whole game unharmed. This effect is also very powerful and it can be triggered easily. The balancing drawback here is the requirement of the Relic. If Homunculus is located on a remote tile rarely passed it also means that one of three Relics is kept on that location too, leaving only two relics to secure the more strategic locations on the board.

Our aim was to have “Domination win” decks viable in the tabletop game, and even when it was tricky at some points I feel that we did a good job there.

Finally there was that last mechanism that we kept avoiding - the ‘When Conquers’ wording of the digital game. We were facing two options; either leave the mechanic out of the game or live with the fact that the ability will be much weaker. Our decision was to keep the ability in the game, even when it’s a bit weaker than in the digital game as it is still usable. The alternative of leaving a number of cards from the core set or creating new skills for them just wasn’t reasonable and would deviate the tabletop version too far from the digital game.

So, there’s the iterations and thinking processes we went through when reassembling the game to fit the tabletop environment. We rejected many ideas and mechanics, not because they were bad but because we wanted to preserve the gameplay, metagame and tactics we have in the digital game. And we succeeded. When moving from digital to tabletop and vice versa, the player gets the feeling of familiarity - the two versions work the same, despite the minor rules differences.

The third part is to follow. In that I’ll go through the design principles we followed and show how badly the tabletop version would work on digital, making these two realms very hard to connect conveniently. But there’s also things that work on both versions, be sure to follow us to find out what they are and why.