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.

Activate the containment field

My current virtual tabletop of choice for prototype work is Screentop.gg, which provides a 2D environment that you can access from a browser, and do this for free (though paid-for premium is apparently on the way - and has been for a couple of years now!) without installing anything, and without melting your PC from the load. This works well for me and makes me happy. It is also under active development, and new features crop up periodically, generally without fanfare (unless you are paying close attention in their Discord server), which makes for occasional excitement or confusion.

Note: this post is likely to not make very much sense to a lot of people. If you're not interested in Screentop configuration, I really won't mind if you move along and do something else with your life. Anyway...

A relatively recent addition is grid "dropzones", which appear by default on "container" components (which are the type of component you use if you want to put something on top of or in it - like a board, say), which made a huge difference, allowing containers to have a simple and useful default behaviour without having to mess about with setting up anchors in precise locations.

Anyway, what I wanted to talk about here is how you can make anchors (lines or points where you can drop other components) interact on containers in order to make some neat and helpful behaviour with little effort.

The driver for this is making a virtual prototype of my "City State Co-op" game, which requires cards to be tucked behind a small player board, and overlapped so that the main information on each card is easily visible. Like in the following picture.

The way this works is with a set of dropzones on a "player zone" container that I created for arranging player components on, arranged in a particular way:

In this, it is the "Cards" and "PlayerBoard" dropzones that matter. Screentop arranges things in order, down the list, so in this case the player board is rendered after the cards, and thus appears on top of them. If I rearranged this so that the cards are after the player board (the 6 dots to the left of the names are handles that you can drag around to rearrange the order), the board would appear underneath.

The PlayerBoard dropzone just has a point anchor in the middle of the container and isn't interesting other than its presence. The Cards dropzone has a bit more going on with it though:

The highlighted line in the image is the "Challenges" anchor, which isn't massively interesting, as it is a place to dump cards that have not yet been dealt with in the game - this anchor ensures that the cards are face-up, and aligned vertically with respect to the player zone, and makes sure they are lined up neatly (unless you have way too many in play - in which case you have probably lost the game) which is cute, but that's about it.

The other two lines are, I think more interesting. They are effectively mirror images of each other, and ensure that the cards that need to be tucked line up the correct way.

The x coordinates of the line here run left to right and the cards are aligned to the end (the right) of the line, with a gap setting that overlaps by the right amount to show what I want of the card. The rotate makes sure that the card is on its side, in the correct direction, and the "open" and "up" settings ensure that the cards are face-up. (Actually, in this case the cards are modelled as containers, which allows some other handy behaviour not available to tiles, which would usually be a good choice for cards, and so only the "open" setting actually matters.)

The "Buildings-right" anchor differs in that the x coordinates (which are shifted to the other side of the component) run from right to left, so that the "end" alignment now hits the left, and the rotation is 270 to allow the cards to rotate neatly the other way.

And the upshot of all this is that I can basically drag a card to the general area of one of these anchors and let it go, and the card will flip, rotate and tuck appropriately without further assistance, making the game much smoother to play than it might otherwise have been.

I realise that this post is very dry and probably of interest to about two people, and they may never see it, but please do let me know if this sort of thing is helpful. 

Physical Artifice

So, The Artifact...

Of the projects I'm currently working on, this one is probably the one that has most consistently been developing over the last year and a half. It is a co-design with the inimitable Alex Cannon, who I got to know through a couple of Twitch streams in the first year of the pandemic, and who has an uncanny mind for puzzles. Since January 2021 we have been having an online meeting most weeks, usually working on or playing a virtual prototype we had built in Screentop.gg, and sometimes just chatting, partly about life and partly about the project.

Then a few days ago we managed to get together with a physical prototype and play the game on a real table. We sat in a coffee shop for a while, drank beverages, had a couple of plays through, and talked through some of the implications of what happened in the games we played.

A 2-player game (the blue meeples are replicants) coming close to an end.
Just off-camera to the left are project boards, which are the paths to victory.

Boy, I have missed this. While we have got this game a long way with essentially entirely online collaboration and testing, you can't beat moving components on a table, at least not when that is the intended playing format for the game.

The big headline is that the game felt pretty natural to the two of us to play, and took maybe half an hour or so per game. How it would feel to other people is unknown right now, but hopefully we'll find out sooner or later. The half hour of play felt pretty good -- a bit of brain crunch that might have been too much if sustained for a load longer -- but it occurs to me that maybe there are too many bits for a relatively short game. The setup and teardown is not exactly challenging, but... I dunno, it's just something in my head as I write this.

Just to catch you up, the central conceit of the game is that there is an alien artifact that has crashed to earth and we are corporations (or something) trying to research and exploit the technology contained within by assigning researchers to work on the expanding knowledge space that is represented by (mostly) domino-like tiles that get added on each player's turn. The game ends when one of the several project tracks off to the side is completed (each works a little differently with how they can be progressed and what benefits they provide, and there is a little interaction between them), and the completed project dictates the victory conditions for the game.

We've been tinkering with a new mechanism based on what we are labelling as alien slime (in this prototype it's to do with the yellow cubes and the black squares), which we think opens up some interesting possibilities, particularly adding more spacial elements to the game (which otherwise are less than you might think for a tile-placing game). The couple of variations on the mechanism we tried were underwhelming, but found some directions we could push in, and a later, virtual session experimented some more. Still a long way to go here, including considering whether we really should be using this. 

The Artifact has twisted and changed quite a lot in its 18 month history, with mechanisms added and removed along the way, but it has always revolved around the tile placement and use of workers/researchers to tap into knowledge resources on the tiles. We seem to have settled on a form of path to victory now, but in the last few months we have just been testing with the two of us while we made some major changes, so we don't have the important data from other people looking at what we have been tinkering with week in, week out, and that is potentially concerning. But I think we're getting to that point of going back to our friendly (but occasionally brutally honest) volunteers/friends and seeing what they think.

Researching The Artifact

So, another game design project I have ongoing at the moment, and another collaboration. This one is working with Alex Cannon, who says I am allowed to blog about the project as long as I make him look good. I will do my best!

This game came out of one of the fabulously intelligent and charismatic Alex's occasional Twitter threads of game ideas, after I responded to a short idea along the lines of "friendly worker placement", where players maybe get benefits in some way from nearby workers placed by other players.  I couldn't help thinking about scientific research where, while research groups can be intensely competitive, the whole field relies heavily on the output of others. You know, the whole standing on the shoulders of giants thing. Or at least standing on each others' chairs.

We had a chat and after bouncing various thoughts around, we got to the idea of teams of scientists working to investigate a big alien artifact; a crashed space ship or something. The idea is to find ways to exploit the various forms of technology found in the artifact and earn fame, fortune and victory points!

A first shot at manipulable components, even if it wasn't actually a playable game.

As we live something like 100 miles apart and have been pretty much locked down due to Covid-19 restrictions, we needed to collaborate online. Our method so far has been to make notes and write rules in a couple of Google documents, alongside a spreadsheet for component data, all of which we are both able to edit. I built a set of nanDECK scripts for the various components, and can run those quickly to generate files that can then be uploaded to a Screentop.gg project that we both have access to. It means that I currently have to take action any time we want updated components, but unless there is some structural change required, it takes only a few minutes from changing the spreadsheet to being able to play.

Over the early iterations (we have been having a discussion, and usually a play of whatever we have set up at the time), we homed in on a few concepts that we wanted to build around, and which we have pretty much stuck with even though a load of other things have changed...

• There are no victory points in the game; you win by being the first to achieve three objectives (in the form of "projects".
• There are no spendable resources to gain and then spend; instead you just have access to levels of knowledge according to the positioning of your researchers (workers) and the layout of the board tiles.
• On every turn, you add a tile to a central layout, with domino-like placement rules and can place or move one of your researcher tokens.
• Access to knowledge via your researchers on tiles allows you to play cards to a personal tableau, representing your personal developments and special resources and capabilities.

Mid-February. The round markers are movable player tokens
and the squares are knowledge "resources".

We almost immediately simplified the tiles so that the ones that get played every turn are essentially two-square dominoes, largely for simplicity's sake, but we haven't really felt the need to change this, apart from having big tiles to add to the array when you complete a "project" (one of the objectives). 

The main changes apart from that have been to evolve the development cards that you are playing along the way, gradually adding more variety, restricting the number of developments you can have in your tableau, introducing a mechanism for upgrading from one development to another, and adding special actions to most of the developments. All this now means that there are all sorts of additional actions you can do on your turn, and you will end up losing access to some of them as you change your priorities in upgrading and rebuilding.

Up-to-date, with a three-player game and a lot more going on.

There is still a very long way to go in developing the game, but it seems to be evolving its own character and challenge. Last week we hit a milestone in having our first test play that involved a third player. While this definitely revealed a few shortcomings, as would be expected, our big takeaway was that the game did not completely collapse when played by someone who didn't design it. 

One of the most interesting points made by our third-party tester was that the game felt strategic but not tactical, and it that maybe there should be a better balance between the two -- or at least we should think hard about whether we want a game like that.  The observation was that to a very large extent you could make a plan early in the game, and then execute that plan, and the challenge was to complete the plan as quickly as possible, with minimal concern for what the other players were doing.

This is all a matter of perspective, as while the other player was executing his plan, Alex and I were getting in each others' way a bit, but the point stands: there was a different experience for different players and, at the very least, we need to decide if we are OK with that. And if we are not (in general, wildly different experiences between players might indicate a problem), we'll need to think about how to address it.

Did I make the talented and likeable Alex look good enough in this post? I guess only he will be able to rule on this. 

From Spreadsheet to Screentop via nanDECK

 I have an old card game project that has been languishing without attention for a few years with the working title Monster Invasion, which was a solitaire game (which I could probably make into a cooperative multiplayer game) that I used to enjoy playing back in the day. I recently decided to give it a look again and see what I can do with it, which gives me a perfect opportunity for me to demonstrate my current workflow for building a virtual prototype on Screentop.gg, a 2D virtual tabletop that I am learning to love, with the wonderful nanDECK for creating the card graphics.

I'm not going to go into every detail of how this all works, but hopefully will give you a few pointers if you want to work in this way.

The state of the game as I got back to it was a nanDECK script taking data from a CSV file. This was last worked on in 2017, and I've developed my way of working quite a lot since then (even ignoring the shift to virtual prototypes), so my first task was to update the data source. nanDECK is capable of drawing data directly from a Google spreadsheet, as long as the spreadsheet has been shared appropriately (there are details of how to do this in the nanDECK documentation), so I imported the dats, made a couple of tweaks, and shared as appropriate.

My card data in a Google spreadsheet, all ready to go.

If you can see the image of the spreadsheet above, there are probably a couple of things to draw your attention to or at least explain. At the top right is the number 55; this is calculated as the sum of the values in the "Quantity" column, and I find it helpful to have something like that for my reference as I make changes. At the bottom is a line for a card back and a set of nine "blank" cards; this is to help me later build a card image for import to Screentop.gg later on. When I am working with physical cards it is convenient to work in multiples of nine, which is a good number to print on a single A4 page, and coincides nicely with a standard deck size for manufacturing purposes if we get that far. On Screentop I find it convenient to have sets of 55 cards in a five-by-eleven grid, which allows me that same number of cards plus a slot to use as a card back which, if I pad appropriately with blanks, I can make always appear in the last slot of the image.

As an aside, a similar strategy works well for Tabletop Simulator, though typically you use the final slot for a "blanked out" card face. Tabletopia required individual images, which are also easy to set up using the same tool chain, but I'm not doing that today.

As you may know, nanDECK is a system for building cards (and other game components) using a scripting language that allows you to have huge amounts of control if you want it. There is a "visual" mode to the system that I have never spent any real time trying to use, and I gather that works well for some people, but I can't offer advice on this. 

OK, so the nanDECK script. I'm not going to show you the whole thing here, but can show you some of the bits that are relevant...

The first part of my nanDECK script.

A few comments on this first part of the script, assuming you can see the image above...

The first few lines are there primarily for when I want to output a printable PDF document, but an important point here is line 3, which defines 'DPI=140'. This defines the resolution, and thus the file size of the output. Normally for printing purposes you might want to work with about 300 DPI (dots per inch) to get a high quality output, but for virtual prototypes you may have file size limitations, and so may need to reduce the resolution. In the case of Screentop, the limit is an image size of 4096x4096 pixels, and to fit within that constraint I need to either reduce the resolution to about 140 DPI as I have done here, or go for a slightly higher resolution and make the output image a more square shape than I have done.

Line 9 is the link to my spreadsheet. nanDECK is smart enough to recognise that this jumble of characters is a Google spreadsheet ID and acts accordingly.

Lines 11 to 20 define icon images to associate with the letters I am using in the "icons" columns of my spreadsheet. 

Lines 22 and 23 (and the earlier line 6) are a habit I got into long ago of printing a version number onto prototype cards so I can tell that I am using the set of cards that I mean to use -- and this can be important with a game that I am iterating over and revising rapidly.

Then at the bottom I start off the definitions of the actual cards, using an IF structure to select options according to the "CardType" column in the spreadsheet.

After skipping a few lines, here's the end of the nanDECK script.

Towards the end you can see the card back being made by drawing a coloured rectangle at line 55. I have got into the habit of using two-colour radial gradients like this (with various colour mixes) for place-holder card backs, sometimes with text over the top if that seems appropriate. I find them sufficiently pleasing for minimal effort.

Finally, line 60 is where the magic happens, outputting a single image file for cards 1 to 55 (i.e. all of them), arranged in a grid 11 cards wide. 

So, if I validate and build this script, I end up with a nice image of all my cards...

And here we have the output of my script: a big image ready for upload.

So, on to the next tool in the chain: Screentop.gg...

Screentop is a bit of a work-in-progress at the moment, but it is very useful as it stands and is being actively developed and supported. I like it because it does enough for most of the projects I am working on, and is far less demanding on computer resources than its 3D cousins, and just about anyone can join a game from their web browser if I send them a link. On the other hand, there are a few odd quirks to get past. One of these scares off a lot of people: rather than having intricate GUI elements, several of the tasks you may want to do will require using the "bulk editing" system, which uses a programming language and you need to type code into a window to make your changes. Back on the positives though, there is very useful documentation, which provides bits of code that you can just copy and paste as appropriate for most situations, and this makes it potentially rather less scary than the likes of nanDECK.

The Beginner's Tutorial for Screentop takes you through the steps of creating a deck of playing cards, and you can simply follow that, substituting your personal deck image (as I have just created) instead of the sample one they provide.  The tutorial only uses the necessary cards from the image, but I usually make cards for everything, including the blank cards, which allows for more flexibility and cleverness later, which I will go into shortly.

So, just a few minutes of work and I have a pile of cards, some of which are blank...

Cards now up on Screentop.gg - ready to go!

So the game is more or less playable now in it's present state, though I need some way of tracking two scores: power and threat. I can do that by adding some tokens, adding a little score board and a couple of tokens, or using one of the built-in component types, a counter. Or doing the tracking offline with physical components too, I suppose. I can leave that as an exercise to the reader, as I wanted to just show one little extra thing.

The way Screentop handles graphical assets is that you can upload an image and then divide it into a certain number of rows and columns, which are then indexable sub-assets. This is useful for handling entire decks of cards together or potentially other components like custom dice. (Tabletop Simulator is similar in this respect.) In this case, what this means is that once you have set up a deck of cards (or similar set of components), you can, with just a few clicks, upload a replacement for the graphical asset and it will instantly update the cards.

So, if I want to change the background colour of the boss cards, that's one line in the nanDECK script, and replace the blank cards with a pointless message, that's a quick edit of the spreadsheet. A couple of clicks in nanDECK regenerates the graphic, which I can then upload.

Uploading a fresh asset in Screentop is really quick and easy

And, ta-da!...

An updated version of the game in just a couple of minutes.

This updated version is actually the same session as the one in the previous screenshot, having refreshed the page a few times -- this behaviour is brilliant, but doesn't seem to always work first time. A fresh session would (and did) update the cards straight away.

Anyway, now we're all in place, I can start looking at the game and decide what I want to do with it. Card updates will be absolutely trivial with the basics now in place, so we'll see what inspiration comes. 

I'm not sure how interesting or useful this sort of post is, but I guess if you found it really boring you won't have got to this point anyway. Thanks for reading!

I Want To Play With My Ætheling*

So, that game idea I talked about a few weeks back with the hunting accidents and the like, well it has developed a bit and I have built a playable prototype on Tabletopia. Then I decided to get some practice on other technology and now I have an upgraded prototype on Screentop as well.

The idea has filled out a bit. We have three "locations" -- I need a better name for these, but essentially they are places with things that are going on that nobles might go to: a hunting party, a feast or banquet, and a war. As a player you have four (currently -- it could easily be a different number) members of your "family", and play cards that send members of your, or your opponents', families to and from these three functions, or cause unfortunate incidents to occur at the functions (often killing off attendees). In various situations (like surviving attendance of a function) your family may get prestige, which counts towards victory at the end of the game, as does the "rank" of any family members who survive.

This is on Screentop.gg - solo playtesting a multiplayer card game
is a bit fiddly, but a heck of a lot easier than with a physical prototype.

If all of your family members are killed, that's you out of the game... sort of. Well, actually it isn't. The idea is that if you are knocked out, you get a bonus character, the papal legate, and you get to (secretly) predict who will win the game. If you are correct in your prediction, then you share victory with that player. The game then ends when the next family has their last scion dispatched.

I am pretty sure this arrangement will work best with four or more players, but we will see.

I'm enjoying how this already drifting away from its original mechanical and structural inspiration, Family Business. Most of the cards in the game are analogues of those in the older game, but are now taking into account the multiple sources of peril for the characters. Initial testing suggests that it works at least a bit, but I am concerned that this diffusion of the game might make it more unwieldy. We will see how it works over a few playtests.  

One thing I have already discovered is that my current card mix doesn't give the right dynamic in the game, and play tends to result in almost all of the nobles being moved to locations before anything much else happens.  This may not actually be a bad thing, but it did feel a little dull as it stands. 

In Family Business, there is the concept of a "mob war", which is triggered in a number of ways, including there being a sufficiently large number of mobsters on the "hit list", and when this happens, at least one mobster will die on every player's turn until the war is over. This is a really effective way of driving the game forward, but I feel I don't want to do that in this game, partly because, while I am OK with creating a game that borrows/steals a lot from another game, I don't want it to be a rip-off, but also very much because that doesn't really fit thematically. 

I don't yet have a solid idea for how to address the pacing and arc of the game, but I'm sure something will come that will make the game feel more of a thing in its own right.

* If you didn't know, Ætheling is the Anglo-Saxon name for a member of a royal family who was considered a valid choice to become king, back in times before formal lines of succession were established and monarchs were effectively elected by a council of nobles.