# Designing tabletop games with open source
The print-on-demand industry is one of my favourite products of
technological innovation. It removes gatekeepers, and eliminates the
bottleneck of physical bulk production. It enables anybody with a good
idea and the drive to produce it a way to get their work out into the
world.
Print-on-demand combined with open source software is even more
powerful, letting independent publishers generate content at whatever
price we can afford at the time, or for nothing at all. And the tools
are a pleasure to use.
This month, I present self promotion, cleverly disguised as a case
study, of a group of game designers (me and my creative team) using a
fully open source stack to create, play test, and publish a tabletop
fantasy battle card game.
## Petition
I count among my hobbies tabletop gaming. I have designed adventures
for role playing games, I've designed gaming accessories like the
[Pocket Dice
Roller](https://opensource.com/life/16/11/make-your-own-unexpected-number-generator),
and I've developed homebrew rules for published games.
I spent the last year developing a game called **Petition**.
In **Petition**, players build a society consisting of citizens, each
of whom support some number of pillars: art, military, religion, and
industry. When a society grows strong enough, they naturally try to
spread their influence, dominating their other players. This happens
in the form of a good old fashioned card battle, with players sending
citizens in to battle to see which side is more influential. The
winner steals their enemy's cultural pillar, and the game continues,
until one society is devoid of its own cultural identity.
In other words, it's human nature, in the form of a frivolous fantasy game.
The central game mechanic, though, is the petitioning process, because
in order for any player to attack another, they must petition for the
favour of a god.
A player spends prayer beads and citizens to earn a god's
support. However, any other player has the option to challenge a
player's temple offering by bidding beads and citizens of their
own. The catch is inspired by the classic prisoner's dilemma: a
challenger can see how many beads have been offered, but the cards
remain secret until all bids are in. The combination of beads and
cards sway the gods in different ways, and the gods expect different
actions based on what has been bid. It's a dangerous process and one
that has thrown playtesters into chaos over the past year.
## Early development in NextCloud
There are lots of ways to develop a tabletop card game, and none of
them are wrong as long as you learn something from the
experience. Most of the early game development for my forthcoming
game, called **Petition**, happened in my head during my morning walk
to the film studio where I was working at the time. I kept the general
idea, a fantasy battle game hinged upon the mechanic of petitioning a
pantheon of gods for support, in the back of my mind, taking note of
particularly good ideas on my [NextCloud](https://nextcloud.com)
instance while at work so that I could work it out later at home.
Specifically, I found the **Notes** app very helpful. With it, I could
write notes about the game's mechanics, ideas about artwork,
modifications to rules, and anything else that came to mind, and store
the notes in a notebook-like file structure. The notebook was viewable
in a web browser, or on a mobile app, and NextCloud makes it easy to
share the notebook with my collaborator.
Once the rules were ironed out, I formalised them in a text document
using Emacs. It was too early to consider layout, so I kept the format
simple and just concentrated on getting the rules properly
structured.
The initial rules were written for 2 to 4 players. Sometimes I design
single-player first and then extend that out into multiple player
rules, but this game is inherently competitive, so I wanted to
concentrate on the battle mechanics. Since a key mechanic of the game
is the petitioning process, I especially wanted to concentrate on the
capriciousness of the players.
## Mock-up in GIMP
For the early mock-up of my game, I downloaded Creative Commons tarot
artwork because it looked appopriately fantasy-based. I also
downloaded some icons from http://openclipart.org. I did some quick
and dirty card design in GIMP.
The resulting deck of 108 cards weren't pretty, but they served their
purpose as the game deck for the subsequent year of play tests.
## Artwork with Krita
Once the game's ruleset had been put through its paces, I contacted
the Morevna Project, a group of filmmakers I support on Patreon, for a
recommendation of an open source illustrator. They referred to Nikolai
Mamashev, an excellent illustrator working in
[Krita](http://krita.org) on Linux. I told Nikolai a bit about the
game and left him to do what he does best: draw amazing pictures using
open source tools. We agreed on a price per image, and I purchased a
few initial cards from him.
## Kickstart video with Qtractor and Synfig
To pay for a full deck of 80 unique base cards, I decided to try my
hand at crowdfunding. Word on its success is still pending, since the
campaign has just now begun, but I knew that at the very least a good
campaign needed a video so people could get the executive summary
about the project quickly and with minimal investment of effort.
Since I wanted an animated video, the first step was the soundtrack. I
recorded a brief overview of the game into
[Audacity](http://audacityteam.org) and then cleaned up the audio
where necessary. I imported my vocal track into
[Qtractor](https://opensource.com/article/17/6/qtractor-audio) and
then started composing background music according to the vocal
queues.
When I compose, my method, mostly due to incompetence, is to
play my initial ideas straight into Qtractor, and then mouse what I
actually meant to play based on what was captured. The tune went from
a synth-heavy track to something acoustic back to synth, but
eventually I reached something I liked enough to use.
Next, I worked on the video in [Synfig](http://synfig.org). There are
several very good
[open](https://opensource.com/article/17/2/opentoonz-2d-animation-software)
source [animation](https://opensource.com/node/31866)
[applications](https://opensource.com/node/32511) available, but I
chose
[Synfig](https://opensource.com/article/16/12/synfig-studio-animation-software-tutorial)
because I know it well and it doesn't model itself as a digital cell
application, and I didn't plan on drawing anything myself. I just
needed a good application to handle the movement and manipulation of
sprites.
I animated mostly by frame count: I listened to my audio, made note of
important frame numbers, and then animated to hit those marks.
That took a few days, and when I was done I decided to insert a little
bit of modest foley work. I grabbed some sound samples, like the sound
of a magical burst and the sounds of cards being dealt, from
http://freesound.org. For precise placement, I could have counted
frames, but I decided to take the high tech route, using
[XJadeo](https://opensource.com/life/15/10/mixing-sound-qtractor-and-xjadeo)
to sync video playback with my soundtrack in Qtractor.
The finished video can be seen on the project's [Kickstart
campaign](http://link/to/kickstart/page/forthcoming) page.
## Card design with Inkscape
Although I don't yet have the funds for a full deck, I have enough
cards illustrated to design the final look of the game. In my head,
this game lives in the tradition of Magic: The Gathering, Munchkin,
Dominion, and other great fantasy card games, but in reality it's
probably more like fantasy [Texas
Holdem](https://www.partypoker.com/how-to-play/texas-holdem.html), so
I decided to keep the card design modest and simple.
In my original game, I had designed several "paragon" cards. These
were cards that the players were meant to capture from one
another. Each paragon also had a god associated with them, which was
why players had to petition the gods before moving in for an attack: a
god had to be persuaded by one paragon to attack another paragon who
followed the same god. It made sense storywise, but in the playtests
it just confused players because there were just too many human
elements: gods, paragons, and citizens, all vying to tap into the same
powers.
For the final design, I decided to reduce the paragons to icons. These
icons were placed on each god card and each citizen card so that
players could easily and quickly identify what card could aid in which
kind of battle.
I decided to use [Inkscape](http://inkscape.org) for the final card
layout because I knew that there would be a lot of extra vector work
on top of the art work.
I downloaded a card template from the print-on-demand service that I
had decided I'd most likely use. For each card type, I created one
Inkscape file with several layers. Each layer would hold one
card. Since I don't have all the art yet, most layers are
placeholders, but the name and attributes of each card is complete in
every layer.
## Rulebook with Scribus
Following my own advice about [writing documentation like a
board](https://opensource.com/life/16/11/software-documentation-tabletop-gaming),
I wanted to refine the rules of the game. I wanted the rules to enable
game play rather than be a barrier to it, so I decided to create a
friendly, nonthreatening rule book that would show people how to play
and then get out of the way. I didn't want players to have to take a
class in logic or game theory to understand my game.
I wanted my rules to have big, friendly pictures so that readers with
less than stellar reading comprehension could piece together the rules
if not only from the pictures, then from key words and pictures
combined. I wanted the text to be minimal so that even strong readers
wouldn't have to invest too much time getting through it, because
there's nothing less fun than announcing to your friends that you want
to introduce them to a cool new game you just bought and then spending
the next 30 minutes deciphering codex.
In a way, my inspiration was the excellent [Pathfinder Strategy
Guide](http://paizo.com/products/btpy99sk?Pathfinder-Roleplaying-Game-Strategy-Guide),
an excellent intro to RPG character building by Paizo Inc. It's the
friendliest book about how to get started with RPG I've ever read,
with lots of charts and pictures breaking down an impossibly complex
subject into digestible sections based on when you actually need to
know the information.
This principle changed everything, and Scribus made it easy to
rearrange graphic elements and text as I simplified the
delivery. Instead of explaining to the reader how to both petition and
deal with challenges to a petition all in one go, I broke it down into
sections that would apply conditionally based on what was actually
happening: the docs assume that all petitions are successful when the
mechanic is first introduced, and challenges are explained in a
dedicated section that can be read after the petition mechanic has
been internalised. This also makes referencing rules easier, because
all exceptions are explained independently of when they actually
happen; after all, a reader doesn't need to know why or when a
challenge happens, they just need to know when a challenge can be
made, and where to look when a challenge happens.
There was a small snag while designing the booklet. The Scribus
template provided by the print-on-demand service had the cut marks
incorrectly placed by about 8mm. This didn't become evident until the
proofing stage, so I had to go back into Scribus to account for the
template's error. Scribus, again, made it easy to make little
modifications to fudge the content inward without losing the overall
integrity of the design.
Scribus also has a surprisingly robust exporter. From previous
experience with printers, I had anticipated exporting to PDF, which I
knew Scribus did excellently. It turned out that this printer wanted
all pages as PNG files, instead. I anticipated exporting to PDF from
Scribus and then using Image Magick to convert to individual PNG
files, but Scribus ploasantly surprised me with all the relevant
options I could ever need for PNG export. It saved me a few steps, and
I appreciated it especially as I went back and forth from proofing to
adjusting.
## Crowdfunding commons
Since the entire project is licensed as Creative Commons, one of the
benefits of crowdfunding is that all the assets, from artwork to
design files, will belong as much to the funders as it does the
project. Since the project is being created with open source software,
all of those assets are accessible to everyone.
## Open source workflow
Open source software offers a full publishing workflow, from concept
to graphics to layout, and it's available to everyone. Don't let the
lack of a publisher get in your way: if you have an idea, create it.