Prototyping Pipeline

Besides designing games, I have designed and built a sophisticated prototype production pipeline: a set of custom scripts and tooling are used to generate all the prototype files. This makes it easy to generate files suitable for multiple uses from a single set of art files and scripts: print-at-home and digital assets for playtesting, or commercial printing of custom game components.

My first game prototypes were entirely hand-built; I used LibreOffice Draw (initially OpenOffice, then migrated to the fork) to produce the art files and had to literally copy and paste the contents of cards onto a grid for printing 9 poker-sized cards on Letter-sized paper. I spent more time getting the prototypes ready to print than I did designing the changes; any time I needed to make changes for game design reasons, the extra friction of redoing all the ready-for-print layout work caused me to resist making those changes.

I quickly realized this needed some automation. As a veteran of the software world, I was ready to take that on. I chose Makefiles (GNU Make) as the backbone, and that runs ImageMagick utilities and shell scripts to produce the final result. That was good enough to serve my needs for the COVID lockdown era online playtests, once I figured out how to “montage” all my cards/tiles into a single file for uploading.

Over the years I incrementally improved the build flow, eliminating more and more manual steps. And then I discovered Claude Code. With Claude’s help I’ve added lots of powerful features including color substitution, parameterization for text and icon insertion, automatic packaging of art (cards, tiles, etc.) of any size onto a page so that it can be easily printed and cut out, and more.

How I use AI in my game design process:

• Software: I use Claude Code to generate the code for my build pipeline, but I monitor and supervise the work closely.
• Writing: I also use Claude to generate early drafts for some writing (including this page) but edit them heavily to make sure they are my own original writing, not AI slop.
• Game Development: I may consult Claude on design points including analyzing playtest feedback, but the decisions, mechanics, and content (art/text) are my own original output.
• Not Artwork: I do not use AI for any artwork generation
• Overall, my use of AI is carefully controlled to ensure that the designs I create are truly human-authored.

Prototype Forms

The same build pipeline generates three types of prototype outputs:

Print-at-home Prototypes

My build pipeline produces files suitable for printing at home. Cards and tiles are packed tightly together on 8.5×11 (US Letter size) paper: 3×3 grid for poker cards, or 8×10 grid for 1″ tiles, or a densely packed tessellation for tiles of various shapes. Then I print them and turn them into playable prototypes:

• Cards, in card sleeves: I fill them with a poker card for stiffness and a piece of ordinary white paper with the card art printed on it.
• Boards: I print on sticky-back paper and adhere to chipboard; my print pipeline automatically divides larger art files up into equal sized pieces for printing on 8.5×11 paper.
• Tiles and printed chips: I print on sticky-back paper, stick to chipboard or plywood, then cut out.

Online Prototypes

In 2020-2022 I built games on Tabletop Simulator and participated actively in several online playtesting groups (Virtual Playtest, Remote Playtest, Philadelphia Game Makers, Playtest Northwest, Weird Raptor Games, Protospiel Online, and others). At the time my build pipeline was oriented towards generating the assets for Tabletop Simulator and I automated the process of pushing a new version there.

Since 2022 I’ve used screentop.gg and more recently AirBoardGame as my playtesting platform of choice. I have a self-hosted AirBoardGame instance wired into my build platform now, so changes to my art and configuration files are directly pushed onto that for immediate availability to playtest or demo.

Manufactured Prototypes

After sufficient playtesting when it’s time to create a nicer looking prototype, my build pipeline also generates files in a format compatible with The Game Crafter‘s upload requirements, for a seamless professional-looking prototype production workflow. The 1/4″ bleed required by TGC is automatically included in the files.

How it Works

With this system in place, it’s trivial to make massive changes just by editing an art file here, a json configuration there, etc. and then running “make” to spit out a new set of files ready to print and cut out for an in-person playtest, or test online with its built-in upload. That lets me focus on honing what makes the game work, and iterating the game as quickly as possible without copying and pasting to lay out changes or reformatting things by hand.

LibreOffice Draw is still my graphic editing tool of choice, but now instead of manually updating each and every card in the deck, or whatever asset needs changing, I change it in just one place. Before, I had full copies of every card in the deck or tile in the bag; now, I just have one template that takes care of layout and style, and a json file that contains the text, colors to change, or names of icons to insert. I’ve even added a “draft” mode where the art colors are replaced with outlines, lines are thinned, anything white-on-black is inverted, etc.; all to use less ink when printing a rough draft out.

Every game on this site is built by this pipeline, and the build process is unique to how I work so it isn’t published as a whole, but as pieces of it mature into something generally useful, I’ll be carving them out and releasing them as open-source tools. Watch my GitHub account for updates.

Case studies coming soon. Engineering deep-dives on the tessellation engine, the ODG parameterization templates, color-sentinel recoloring, and the AI-assisted-engineering methodology behind the codebase are in progress.

Need prototype production for your game? Get in touch.