Introduction
This is the third post in my series on National Game Design Month (NaGa DeMon) 2020. The other two covered:
I was able to pivot mid-November and get cracking on the second idea from my October post—a game about manipulating the relationships of other non-player characters to secure a political win. The game kept its working title, Intrigue. It's a print-and-play card game for three players, and you can download all the materials on the GitHub page. The remainder of this post gives some more details about the project's inspiration and execution.
Part of the inspiration for the game goes back to 2012's or 2014's Meaningful Play conference, when I first heard of the game Fiasco. This is a short-form RPG themed around movies in the Cohen brothers' style. I have a copy and have thought of picking up the new edition, despite my never having actually made the opportunity to play. Part of what intrigued me in this design is that the relationships between players are represented by cards that sit between them. This was the first time I saw this mechanism, and for some reason it seems to be very rare. It has some similarity to the idea from 7 Wonders in which your left and right neighbors are your closest competitors for resources, but it manifests it into a tangible game piece. I actually designed a game using this mechanism years ago, a small card game about evolutionary adaptation. I made it for a game design contest that was hosted on BGG or BGDF, although now it seems to be lost to vague memory.
Design Process
The original theme of my NaGa DeMon game stayed throughout development, although not without the occasional consideration of whether it should be changed. The king was dead, and three potential successors were vying for the throne. The players are advisors to these successors, and the point of the game is to ensure that your preferred candidate is the one who becomes the new monarch.
 |
| The first prototype of Intrigue |
The initial prototype was made fairly quickly using halved index cards. I grabbed a bag of pieces from my drawer o' bits and used these as tokens as I interrogated the core mechanism. The three characters were placed in the center of the table in a circle, these representing the potential successors to the throne. Players had hands of three kinds of cards: support cards that are played with a character to advance or inhibit their cause; action cards that have a one-time effect and are discarded; and relationship cards that are played between characters. I wanted the game to play fairly quickly but over multiple rounds, sort of like Red 7 or Love Letter in that an individual round may go badly, but you play out several short rounds to jockey for position. Hence, I kept the hand size small. I quickly landed on the idea that the round is over when any player is out of cards, and that the start player would rotate, with the game ending after as many rounds as there are players.
Working through the use of support cards made me think of the elegant subterfuge in Shadows Over Camelot, in which players benefit by drawing a card if they play their own face down, but that playing a card face down increases suspicion from the other players. I brought that in to my prototype for a similar reason, with the additional benefit that drawing that card stretches the game and increases options. A face-down support card might be real support or a feint, which then introduces a vector for action cards that manipulate face-down cards as an interesting secondary mechanism.
My own testing also demonstrated that simply earning points round to round was not devious enough to match the theme, so I pulled a trick from Camel Up. Each player now had a small hand of favor cards, which are a different size than the others. Each named one of the three characters, and players could play these face-down to the middle of the table to show their support. These are revealed only at the end of the game, with the player earning points if they favored the victorious character or losing them otherwise. The number of points earned diminishes with each successful gambit, and so there is an incentive for players to decide early who has their favor if they want the best reward.
After some testing, I realized that some of the support cards were a bit dull, so I revised the system so that every card had a support value at the bottom. Now, any card could be played as a support card or for its printed ability, as in the Focus values in one of my favorite CCGs, Legend of the Five Rings.
My original design had the board cleared after each round, but post-playtesting discussion raised the idea that relationships should stay on the board. This made relationships much more interesting because they were now static through the game, but that also meant that I could introduce mechanisms to remove or replace them. This is thematically appropriate as well, since it is possible that a savvy advisor could turn enmity into friendship as long as it benefit's the advisor's end.
With half the month spent on other prototypes and the week of Thanksgiving spent getting some much-needed R&R, I feel like there are some loose ends to the design. I wanted to spend some time seeing how the game scales to four or five players: would it make sense to keep three characters on the board, or should that match the number of players? If I needed more characters, I would have to actually design more. Right now, there are three different traits in the game (Nobility, Royalty, Religion), from which each character has two; this gives four unique combinations, and there are four characters available. It's a clear maneuver to add another trait and then get more variety in the characters, but I didn't have the opportunity to do this in November.
Production
With a solid, tested prototype, my next task was to determine how to prepare the game for print-and-play production. I have assigned this tasks to my students before, but while I had read some about it, I had never actually released a print-and-play game before. When my team produced Race to the Moon, I had all my card designs in a spreadsheet, and my graphic designer laid out the cards from that. Hers was a manual process, but you know the maxim of pragmatic computer scientists: if it can be automated, it should be automated.
After a bit of hunting, I settled on nanDECK. It is free (as in beer) Windows software for producing cards and tokens from scripted input. Once I decided it would be my tool of choice, I delved into making it run on Linux using WINE; the only hiccup was that I had to determine how to install Windows core fonts using winetricks. With that set up, I was able to learn how to write nanDECK scripts to produce my four different types of cards and tokens, including double-sided favor cards and drawing data from a LibreOffice spreadsheet.
 |
| Sample sheet of printable cards |
When I started using nanDECK, I used the visual editor to drag and drop layout elements. However, this quickly outlived its usefulness as I wanted to incorporate conditional elements. For example, arrows are shown on cards if and only if they are relationship cards, but it seems the visual editor is not robust to that kind of flow. I quickly transitioned to using percentage-based layouts. For example, laying out the type of the card is done with this command:
TEXTFONT=[all],[TYPE],0%,15%,100%,10%,CENTER,CENTER,0,100,Oxygen,14,I
That is, on all the cards, put the TYPE field from the spreadsheet into a box that is at X=0%, Y=15%, Width=100%, Height=10%, centered vertically and horizontally, with 0-degree rotation, completely opaque (alpha=100), in 14-point italic Oxygen font. At first, this looks like gobbledygook, but the more you work with it, it gets to be a really convenient shorthand. The nanDECK script editor provides hints along the bottom of the screen telling you what each command expects as arguments, and while they are sometimes arcane, they also provided me everything I needed for a quick transformation from spreadsheet to printable card.
I talked with a friend who does a lot of paper prototyping about tools, and he prefers Component Studio. I was turned off by it some years ago because, at the time, it seemed to suffer from serious vendor lock-in, so that you could not access your files unless you continued to pay a subscription fee. Maybe that has changed, I don't know. He is a UX designer, though, and we both agreed that nanDECK has an amazingly retro 1990s interface. It's like the bad old days, when there were essentially no standards and everyone making interfaces was just winging it. For example, nanDECK has idiosyncratic interpretations of left and right click: you might think left click is select and right click brings up a context menu, but you might be surprised at what you find. Still, like Blender, UE4, or Gimp, just a little usage starts to make the idiosyncrasies invisible, and you can start moving from idea to execution without the hurdle of interface interpretation.
A final note about nanDECK: if you try to learn it and start searching for help, you will quickly find that the creator is amazingly responsive on the nanDECK Users Guild on BoardGameGeek. I love that this person wanted a tool to automate something, made the tool, shared it with the community, and continues to improve it based on interest and feedback. Cheers, Nand!
The rulebook was written using LaTeX. It has always been my preferred document preparation software, although I did find myself wanting some of the terseness of Markdown while writing. I stuck with LaTeX, though, in part because I knew I could have control over image placement and document flow so that the output would be attractive when printed. In the end, there is only one figure in the three-page rulebook, and it's possible I might have saved time by doing it in a more lightweight language.
 |
| First page of the rulebook |
I wanted to set up automated builds using GitHub actions, but I ran into significant technical problems. The Linux images provided by GitHub do not include wine. I'm not savvy with docker, and so it wasn't clear to me if I should invest time in figuring out how to script the install and configuration via the GitHub action script, create an image and upload it somehow, or do something else entirely; furthermore, it wasn't clear that I could run nanDECK headlessly, since my experiments with automation still brought up the UI as part of the process. I learned that GitHub also provides Windows Server images for actions, but I don't know the scripting language there, so either way looked like headaches that were not integral to the project itself—an artificial rather than essential complication. Hence, although it pains my automated heart to say it, the builds are all done manually by me and then uploaded via push.
I turned back to the old standard for client-side build automation: GNU Make. I haven't written a makefile in ages, and it was kind of fun to get back into it. I used one makefile for each of the two project directories, with one master make file at the top level. I don't remember ever having done this before, but it worked like a charm. I'm still a bit hazy on the reason for phony targets, but I also don't expect this to be a problem for a one-off NaGa DeMon project.
The obviously missing piece of my digital files is any kind of intentional visual aesthetic. Reviewing my game design students' work, I noticed that one of my art-inclined students has a lovely palette for her work, and this gives it an enviable level of polish. It would not be too difficult to pick a few colors and splash them onto my files; I simply ran out of November. The only interesting bit of visual design I incorporated was separating the support value of cards from the rest in a half-rounded rectangle. I would like to return to a nanDECK-powered project some time when I have more ideas and time to execute more compelling visual design.
The makefiles and nanDECK scripts are all publicly available on my project's GitHub page, so feel free to go take a look. I would be particularly interested if any nanDECK hackers look at my scripts and see easier ways to use the tool to accomplish my goals.
Conclusions
This is my third NaGa DeMon project, and I enjoyed working on it. In retrospect, it's easy to say that I should have done more paper prototyping of my first two ideas before getting into the code. Both of those were, in a sense, code experiments, and I did learn a bit from them. The lesson here maybe is one of prudence: yes, I should do code experiments to learn new things, but no, I should not do it during a jam where I want to have something useful to show at the end.
 |
| Intrigue: NaGa DeMon 2020 Release |
This wraps up the discussion of my participation in NaGa DeMon, but I anticipate sharing with you one more post in this series in the coming days. I wasn't the only one in my household completing a project this November! Subscribe and hit the like button. Err, I mean, stick this blog in your RSS reader for part four.
No comments:
Post a Comment