Over the years I've found that my general process for building games has gotten a little faster and more efficient with each game. But, last week I had a big breakthrough with how I use InDesign's Data Merge and I wanted to share what I've found. (1/x) #oathboardgame
I like going into the weeds with my general design process, but I usually don't talk too much about the back end of my graphics and data mostly because it's technical and because smarter people than I do it much better. But, what the hell, let's get into it.
So the game I'm working on now has a lot of cards. Lots. Like two or three times as many as Pamir. What's more, all of those cards are unique and can do lots of different things. Normally, I'd rely on a data merge with a lot of frames and linked images like this one for Pamir: 
This is a pretty strong template and Pamir's final graphics were more-or-less built straight from a data merge, by my goodness was the data a mess.
There were two reasons. First, a single image (say the Betray action) could be placed in frame, so I needed a column for each frame. Second, a data merge csv needs full file paths. As you might imagine, headaches ensue.
To deal with this, I build a set of secondary documents like pivot tables and little scripts that would allow me to perform quick deck analytics to be able to see the big picture. But, a lot of the work was still done by hand and it wasn't easy.
And, if the cards in Pamir are complicated they are at least uniform. This sort of system more or less breaks down if their are cards with different formats. Then you need a whole set of secondary tools and it gets even harder to manage everything.
If you can't see the full picture, it can be hard to design and develop intelligently. There tends to be a lot more shooting from the hip and wasted time. I knew Pamir's core system really well and, with ~100 unique cards, it was still possible to hold everything in my head.
So, that brings me to the current project, Oath (oh hey, we decided on a name!). As I mentioned Oath has a complicated card base. Right now it looks like this: 7 suits, ~3 card types, something like 250-300 unique cards, and lots of icons.
This all could be done in a traditional data merge or any number of other methods, but, after Pamir, I wanted to make sure I maintained the ability to easily and quickly edit large quantities of cards in a way that was thoughtful. I didn't want to get lost in my own project.
To this this, I had to keep the data and the data merge template simple and find better ways of dealing with two old problems: card types and graphical icons.
The classic way to differentiate card types is to use frames of different colors/textures for the card text (think Root's parchment vs. stone cards). But that method creates weird spacing issues because the frames are static--they don't adjust to more or less text.
Indesign has a lovely borders and shading feature built into its paragraph styles but it's hard to capitalize on in data merge because if a data point is empty the data merge will still give it a goofy empty frame. When I first saw that white box I wanted to scream.
Thankfully I've got some history with adobe scripts and I wrote one that cleared empty frames. Easy--eh, not so much. Turns out those "empty" boxes weren't empty. See that black bracket? That's an xml tag.
After trawling around on the adobe forums for a couple hours I found some code that cleared xml tags and then coupled it with my script. Whew!
Okay, now let's talk about the icons. This was a big problem for the reasons I talked about earlier. In an idea world, I would just drop illustrator files into a paragraph style so they could be center justified, have adaptable borders/shading, etc.
This is technically possible in InDesign but it doesn't work in data merges. Many dozens of hours of time over the past few years have been lost trying to make something work. Then, out of the blue, I remembered that Adobe started supporting color fonts awhile back.
Fonts are basically packs of vectors. If they could take a color, then they would more or less be the same type of graphic that we use to make our game icons.
The solution in retrospect was obvious. If I couldn't get my images to behave like text, then I could just turn my text into images.
The first step here was building a proper color font. Here I used @fontself 's tool. It wasn't too expensive ~$50, and worked like a charm. It's built to work as an extension in Illustrator and I think it took me about 10 minutes to build the full font.
Basically each of these icons overrode a traditional glyph (so it would be supported by my data merge csv). In addition, some glyphs in the new font were "modifiers" which I could make by having them offset so they float above the previous symbol (eg. the dagger on meeple)
This essentially allows me to create compound icons that can be edited as a single string of text. That may not sound like a big deal, but I whooped aloud with joy when I figured it out.
All of this was good and my data was dramatically simpler than a usual data merge. Currently I had built the data so that each card had a few attributes: suit, name, image. In addition, I needed three columns for the three different types of cards abilities.
The different card abilities needed to be separate columns so I could style the paragraphs differently. Then my handily little script would delete the empty text boxes after the data merge was complete. So all of this was good, but there was a significant problem left, icons.
The icons were built into a different font, which I had made into a character style within indesign, but I needed a way to switch fonts mid paragraph. Here a little used but super powerful feature of inDesign came in handy: GREP queries.
Basically, GREP can be used to search all of the text in a paragraph style for certain flags (there are a bunch) and then you can take that found text and give it character style.
Here's what it looked like. The query "\^." here looks for the carat and the character after it. then applies Oath Characters (my custom font) to it. So if a capital A was an Arcane meeple in my font, if I typed "^A" the little wizard meeple would appear (the "^" prints as blank)
GREP queries can be a little funky. I was very thankful to stumble upon @EricaGamet 's wonderful little pdf guide. ericagamet.com/wp-content/upl…
Alright, so that's it. Now here's the payoff. This isn't the full spreadsheet, but it's so much more digestible, and--if you can believe it--it actually contains more information than the Pamir spreadsheet. And that data merge template on the right is so simple!
With this current setup I can edit dozens of cards at once and then produce a full art play-testing kit pdf in the space of a few minutes. And, as the project grows, I should be able to stay on top of the data, which makes big ambitious projects like this game possible.
I'm still a little way off from talking about the mechanisms in greater detail, but this process adjustment has already saved me oodles of time and I wanted to share it with anyone who might find it useful.
