Backs to Fronts

I have a prototype production pipeline (inadvertent but pleasing - to me - alliteration there) that I use for a lot of projects, that involves data in a Google sheet, pulled in to a nanDECK script which sets up cards or tiles, and that script then outputs a PNG file with a grid of card images that I can import into Screentop for a digital prototype, as well as a PDF that I can print out for physical components. 

Some of the games I make have multiple decks (in this context I'm meaning groups of cards with a common back), which I generally build with the same script, and the sizes of those decks can change from time to time. In the case of Sympolis (formerly the City State Co-op Game), there is currently a set of eight starter cards, and two other decks with 20-odd cards each, the relative sizes of these two decks varying as I tweak the card sets.

When making the physical versions of the cards, I just put the cards into colour-backed sleeves according to which deck they are meant to be in. My data spreadsheet has a column in it for which deck a card belongs in and I use that information to adjust the front (e.g. using a coloured border or shaded background) to make it easy to spot how to divide the cards. 

In the case of my virtual prototypes on Screentop, I need to tweak a field for each card to indicate which of a set of possible card backs is required. I can do bulk updates, so this task isn't too onerous, but it is still a little fiddly and can lead to mistakes.

After doing this for, like, a couple of years, it occurred to me that I could get nanDECK to do this fiddly bit for me.

The way nanDECK generates cards is, if left to its own devices, it just reads through the data file and generates that many cards, which seems logical to me. If, however, you reference a card in the script beyond that "natural" range of cards, it loops back of the data. So, for instance, if you have data for 10 cards, but you ask nanDECK to output an image file of 20, the system will loop through the data twice.

With that in mind, and the fact that I have been working with sheets of 55 cards (generally ignoring the last slot in order to have a convenient 54 cards for printing, which is 6 sheets of 9), I had a plan. 

Bits of nanDECK code.
The first bit defines stuff that is useful later.
The second bit creates card backs and creates image files.

I defined two ranges, cards 1 to 55, and cards 56 to 110. Then for cards in the first range I defined layouts for the card faces, and for cards in the second range we have a distinctive coloured background and a character printed in the middle to reinforce the information, based on the contents of the "[Deck]" variable, which comes from a column in the spreadsheet. It's not a sexy, final version, but it is neat and clear enough for prototype usage. Then I used DISPLAY directives in my script to output the two files.

Not good enough resolution for you to really see what's going on,
but hopefully you'll get the gist

Then, all that I needed to do was upload the two image files to Screentop as assets and tell the card components to use the same index number for front and back and take their image from the correct asset. As long as I always update the two assets at the same time, the card fronts and backs will always stay in sync.

Of course, when all that is uploaded I still need to sort the cards into the correct files, but that's straightforward enough, especially as I have some "deck holder" containers to help with stuff like that - but that is another story.