I was working on a prototype of a board game for the contest on spielmaterial.de but got stuck. Still I like many single aspects of the game so far, but unfortunately it is not a complete game because some connecting elements are still missing. I won’t make it for the deadline so I decided to put the game aside for while. Kind of frustrating, but you can’t force creativity and ideas.

The good thing is, I’m now open for new game design ideas and the first steps on a new game tend to be the most fun. I’ll also try out some of the challenges of Brathwaite and Schreiber’s Challenges for Game Designers. Sounds like a good plan to start over again!


When prototyping card games one has to produce a large number of cards again and again. The same is true for certain board games. Every new prototype needs new values and sometimes the whole layout of the cards has to be changed. But we don’t want to invest too much time into a prototype because sometimes it only lives for a single test session.

To solve that problem, I had a look at what a programmer would do (naturally to me, as I am one). One key principle in software development is the separation of data, the thingies showing data and the workhorses altering data, mostly referred to as Model, View and Controller. As cards in a game are not changing during the game (besides getting sticky), there is no need for a controller. But what should be done, is separating Model and View, or in the case of cards: values and layout.

Values should be defined in a spreadsheet software, where most game designers are saving their data anyway. There you have the possibility to generate certain values randomly or based on a formula, calculate average values and so balance the game easily. You can identify the things that have to be localized and sum up the components needed for your game.

Then one master card layout should be done in a software that is capable of producing serial letters. That master layout contains all the labels and images that are common among all cards and defines form fields where the values of individual cards should be put. It defines fonts and text sizes as well as colors and the output resolution.

By then, there are no final cards, just values and a layout. The actual bulk of cards is only produced on demand – when you want them printed. During the output, a copy of the layout for every row in your spreadsheet is made and the form fields are filled with the values of that single row.

This first prototype is then ready to be played by you. After some testing you probably want to alter some values of your cards. You can do so by editing and saving your initial spreadsheet. If you also want to alter the layout a bit, you still can do on the original layout file and don’t have to do it for every single card. After all alterations you go printing again and all updated cards of the second prototype are produced in the new layout.

Of course there are some drawbacks. The more standardization you use, the more individualism has to be left behind. If you for example have one funny card in your game whose text should be printed upside down, you probably run into some problems and end in designing that card individually. However, that depends heavily on the kind of deviations from the norm your cards have and what the software you use is capable of.

This technique is not limited to classical cards. It is also useful for any kind of counters, tokens, tiles or other gaming pieces that differ in some properties as they share other. Some later posts will show how you best setup your workflow and how all this works in specific software.