When I first prototyped A Battle of Dwarves, it wasn’t even a board game. As I mentioned in the first installment of this Dev Diary, the initial idea was to create a board game-flavored mobile game with asynchronous multiplayer. For various reasons related to development focus, it quickly became clear that A Battle of Dwarves wasn’t gonna happen – at least not in the format I first envisioned.

I was left with two facts: the certainty that I still wanted to develop the game in a more traditional fashion, and some residual mechanics that were suitable for mobile but not for a proper board game.

This requires some explanation: when you have a CPU at your disposal, you can take a lot of things for granted. For example, the player doesn’t have to keep count of tokens or account for special effects that only trigger at certain conditions, rounds, phases, etc. The CPU does it for you; all you need to do is devise a strategy and focus on your moves.

Traditional board games, however, require much more “player input”. For example, a mechanic where someone plays a card allowing a trap to be set up on an undisclosed tile might work for a mobile game (as the game keeps track of where the trap is located and its triggering conditions), but short of introducing stuff like jotting down notes and hiding them from the other player’s view, the same mechanic wouldn’t work as smoothly in a tabletop game.

So, after deciding that the game would have a bunch of Common cards and at least three different Class decks (now expanded to four), my priorities were 1) placing the cards developed during the prototyping phase in the appropriate deck, and 2) discarding any mechanic that was better suited for a CPU-aided game.

In all honesty, this process took a while. After the first round of revisions to eliminate the obvious culprits, I started some playtesting. It was only after several sessions that I realized more cleaning was needed, because over time I’d grown attached to some cards, and failed to see how their implementation in a tabletop environment was, at the very least, sub-optimal. Most of them still felt like a good idea. But, as a friend of mine often says, “The game is the boss, and we have to listen to it” -- so a bit reluctantly I accepted that some of my designs weren’t that great and shed the unusable cards.

You might be wondering: “What exactly is this game, then?” To which I would say, whoa, slow down! ☺ Let’s start with the basics: the game adds a layer of new mechanics over Chess, that most ancient of games. The way most of these mechanics are integrated is through the use of cards. Cards can be played when the player has collected enough Mana Crystals to sustain their “summon cost”.

I can already hear your next question: “All right, but what are the cards doing?” You’ll see some tease of that in this article’s accompanying images, and we’ll talk details in the next Dev Diary.

As I mentioned, when I started out I wanted to have a deck of Common cards (let’s say they include “neutral” effects and “counters” for now) and three main Class decks, from which each player chooses at the beginning of the game. At the time I called them the “Druid” deck, the “Warlock” deck, and the “Trickster” deck. Their names have since changed according to the setting we’ve developed for A Battle of Dwarves, but in principle their core features are intact: the Druid deck “heals” and “raises pieces from the dead”; the Warlock deck is centered on “aggression” and “retribution”; and the Trickster deck focuses on “deception” and “distraction”.

In the next episode, I’ll review the different card types and the reasoning behind deck four - the “Engineer” deck.

[To be continued!]