Thursday, December 31, 2020

The Games of 2020

What a year! I think it's fair to say it did not go the way anyone expected, and this had implications for my year in board gaming. There were many negatives: I didn't host any game nights for my students; I barely played any games with my friends in town; and a big family get-together was cancelled, which would have been an opportunity for both silly and strategic fun with family members. The biggest positive, though, is that my family loves games, and so we basically spent all year playing board games together. There were almost no interruptions! This was also the first year I tried any online board games, which in my case was mostly a handful of games of Scythe with my brother. It's not the same as sitting across the table from each other, but it's way better than nothing, and there are some fiddly bits that the digital implementation handles for you.

My records show that I played 101 different games in 2020, for a total of 525 unique plays. Once again, like last year, I am shocked to see the total number of plays decreased since the previous year. Whereas last year's numbers were even boosted by Bonk, this years were boosted by The Crew. We got Race for the Galaxy to the table a lot this year too, and that's one we usually play two or three times when it comes out, so I really expected total plays to be up. Maybe it's more related to the kids growing up than I gave it credit for, since where we used to sit and play several simpler games together, now it's more common to spend longer on crunchier titles. Well, it's not the quantity that counts, but the quality, and I feel like we had some great family gaming moments this past year. A few of the highlights to me have been playing Kingdomino with subsets of the whole family, finishing Clank Legacy, playing a lot of Journeys in Middle Earth and Arcadia Quest with my two older sons, getting the next son into Massive Darkness, and loads of family painting (1, 2, 3, 4). The two older boys and I also played a lot of Frostgrave this year, including a small campaign of random scenarios followed by new warbands in the Thaw of the Lich Lord campaign; now, I would call Frostgrave a miniatures skirmish game, but it's listed in the board game category on Board Game Geek, so it gets logged with the rest. More recently, we have been diving into some new Christmas games, most notably My City, which the three older boys and I have really enjoyed, and we four also just started an Imperial Assault 1 vs. All campaign.

Here are the games that I played at least ten times in 2020. As in the past, I have collapsed some different titles together, such as the various Arcadia Quest games or the variations on Clank.

  • Race for the Galaxy (33)
  • Clank! (23)
  • Just One (21)
  • Kingdomino (21)
  • The Quacks of Quedlinburg (21)
  • Arcadia Quest (18)
  • My City (18)
  • Codenames: Duet (17)
  • Lord of the Rings: Journeys in Middle Earth (16)
  • Frostgrave (15)
  • The Crew (11)
  • Medieval Academy (11)
  • BONK (10)
  • Machi Koro Legacy (10)
  • Thunderstone Quest (10)
This year's gaming took my h-index to 25, meaning that there are 25 games that I have played at least 25 times. This is automatically computed by my Board Game Geek app and does not take into account any of my collapsing of categories. I remember being excited when my board game h-index exceeded my academic one, but now I'm pretty sure there is no comparison. 

Let's take our annual look at my top-played games of all time—or at least since I started logging plays in 2016. We'll look at the "quarters" and higher, which are the games I have played at least 25 times
  • Clank! (All expansions and Legacy) (75)
  • Gloomhaven (66)
  • Kingdomino (62)
  • Crokinole (61)
  • Race for the Galaxy (58)
  • Animal Upon Animal (56)
  • Carcassonne (51)
  • Camel Up (47)
  • Thunderstone Quest (46)
  • Pathfinder Adventure Card Game (Core Set + Crimson Throne) (41)
  • Rhino Hero: Super Battle (40)
  • Quiddler (39)
  • Labyrinth (38)
  • Arcadia Quest (36)
  • Reiner Knizia's Amazing Flea Circus (34)
  • Runebound (Third Edition) (34)
  • Terror in Meeple City (30)
  • BONK (29)
  • Temple of Elemental Evil (28)
  • Lord of the Rings: Journeys in Middle Earth (28)
  • Go Nuts for Donuts (27)
  • Massive Darkness (27)
  • Stuffed Fables (27)
  • Champions of Midgard (26)
  • Obstacles (26)
  • Red7 (26)
  • Incan Gold (25)
  • Loot (25)
How about that? Clank took over Gloomhaven! Everybody here except the youngest loves Clank. I suspect he will love it, once he gains some more experience points in reading, mental math, and of course, mash shuffling.

I also engaged in a modicum of table-top role-playing games this year. I wrote in June about getting some friends together online to play Dungeon World, and during the year, I was able to run six more sessions of that with my family. I intended to write a bit more about that here, but the short version is that some games were not as good as others, and we made some characters we intended to pursue, but we tend to fall back on board games. (I also think I may have fallen into some of the mistakes Professor DungeonMaster mentions in his latest video.) We also played a few games of Fate, which was also fun and maybe more in keeping with some of the kids' interests in worldbuilding and improvisation. In any case, though, we run into the age-range problem: we haven't found one thing that all of us enjoy together just yet. Still, maybe there is some promise for more TTRPG fun in the new year.

Last year, I reported on books and video games. I had vague intentions of logging these again this year, but I was too lax in it to bother sharing anything quantitative here. I've taken up the challenge of reading more, which cuts into both painting and video game time, but I think it has been worth it. I have particularly enjoyed reading a collection of Flannery O'Conner stories, joining a discussion group on C.S. Lewis' The Abolition of Man, and, more recently, re-reading Frank Herbert's Dune series, which I originally read in the early 1990s. This last selection was not inspired by the upcoming movie but rather by coming across Matthew Colville's discussions of how much he loves the first novel. It spurred me also to pick up Dune: Imperium for Christmas, and we have already logged five plays of that since December 25. It was designed by Paul Dennen, who designed Clank!, so I guess that puts him right up there with Vlaada Chvátil and Isaac Childres for us.

Here are links to previous years' games reports in case you want to check them out:
Thanks for reading! Happy gaming in 2021!

Tuesday, December 22, 2020

Painting Journeys in Middle Earth: Shadowed Paths and Dwellers in Darkness

Hello, painters! It has been some time since my last painting post. The semester was of course a bit stressful, but I think the primary reason for the slowness has been that I've been trying to read more. I read a wonderful collection of Flannery O'Conner stories and letters, I'm currently rereading the Dune series that I first encountered back in the early '90s, and I wrote about how I took a deep dive into Robert E. Howard's Conan stories. In between these, I painted all the figures from the latest expansion to Journeys in Middle Earth: Shadowed Paths, including the Dwellers in Darkness villain pack

Regular readers may recall that I painted the base set and the first villain pack. The sculpts were in the same style, and I approached this set in a way that would keep the figures looking coherent. All the figures were zenithally primed from the airbrush as usual. I'll present the figures roughly in the order I painted them.

Shadow-Men

I approached these Shadow-men as an experiment. I had heard a few murmurs online about this trend of "sketch painting," where ink glazes are used over zenithal prime for quick paint jobs. I wanted these figures to look like the oathbreakers in the Paths of the Dead as represented in the Peter Jackson trilogy of movies, so I mixed up a glaze of green ink with a touch of yellow and painted it on. That's it. It is exactly what I wanted, and I think it gives these figures a haunting presence, distinct from the other figures.

A quick note about the basing may be in order. In the base game, I based all the figures using brown earth basing paste and a mix of flock. I used that approach on some of the figures in this set, but I also gave some a rocky base intended to be reminiscent of a cavern. I used a technique I have deployed before: a layer of superglue followed by a scattering of different sizes of grit, some larger cork rocks, and overall texture of baking soda. This is then painted using a combination of black ink wash and drybrushing.

Giant Spiders

I am happy with the color selection on the giant spiders. Keep in mind that, unlike a lot of my board game projects, there is no color game art for any of these figures. After some image searches, I found inspiration for these spiders in the spelungula cave spider.

Pit Goblins

For these pit goblins and the following orc taskmasters, I turned to the approach I first experimented with in the JiME base set: acrylic washes over zenithal priming to get large groups painted quickly at the expense of being a bit desaturated. I was a bit lazier with these, using basically the same skin tone and uniform for all of them. Getting these painted quickly allowed my boys and I to replay the Hunt for the Ember Crown campaign using the new minis and heroes, while I continued to work on the unique villains for our eventual delve into the newer campaigns.

Orc Taskmasters

As with the Pit Goblins, these were done fairly quickly, though they had more interesting details to pick out.

Nameless Things

If I left the caption off, would it be funnier? Anyway, these were fairly straightforward paint jobs, but I think the results are good. I used some two-brush blending to layer in the initial highlights and shadows, drybrushing to accentuate raised areas, and then more focused washes to bring more darkness into the depths. Looking at these makes me wonder if I would do a better job now on a rancor than I did two years ago. Reviewing that blog post, I am reminded that the photos were taken in the era when I could just not get good color balance on my camera: the real figures look very little like the photographs.

Cave Trolls

Cave Trolls

I am really happy with how the cave trolls turned out. I used a slight variation in skin tone between them and then different colors for their ... well, I don't know what those are. I think they show a good combination of techniques, including two-brush blending for the skin and washes with layered highlights for the ... well, the thingies. It's not how I imagined cave trolls but they were fun to paint and look good on the table.

Gandalf

Gandalf

What fun it was to paint Gandalf, the iconic wizard. Every blue-robed, white-bearded guy with staff is trying to be as cool as Gandalf. I'm looking at you, Elias from Massive Darkness. Taking some inspiration from Sorastro's video, I used variation in blue-grey mixes and tried to get some textural differences across the materials. For the staff, I ended up leaving the top without a base coat, glazing on yellow ink to make it look lit up. I used only subtle OSL here. I should mention that I'm wary of OSL ever since listening to Dr. Faust's fascinating editorial on the topic, which can be found starting at about 11:30 in this video about painting Darth Vader.

Elanor

Elanor

It's Elanor of Gondor, whom I first wrote about painting in last year's Middle Earth Quest post. This figure is probably twice the volume of the tiny MEQ one, and she was mostly straightforward to paint. However, where MEQ Elanor had the White Tree of Gondor engraved into the sculpt of her cloak, this one did not. I decided to freehand, which regular readers may recall is a struggle for me, and this was doubly so for being on a rippled cloth surface. The final image shown above is actually my second attempt, but I took some work-in-progress shots of the journey, so I will share those here.

Here she is back in October:

Here she is after the first pass at freehanding the White Tree:

The photo is actually not as bad as I remember the figure, but I was unhappy with a few things here. First, I thought the tree was too stocky, looking to thick. This was accentuated by what looks like a bad baseline on the bottom: it does not line up with the hem of the cloak. This is troublesome though because I think the cloak itself is not sculpted realistically: if you unfolded it and laid it out, it would not be a regular shape, which adds complication to attempts to paint anything on it. Finally, I did not like how the tree is too far down on the cloak, since it seems that if it were embroidered on the back, one would cover the whole canvas and not skip the part under the hood.

So, here it is after covering up the first approach and reapplying the cloak's highlights.

Finally, here it is after the repainting but before the basing and varnishing. 

On this pass, I was more careful to sketch the outline of the tree with very thin lines and to build up from these. There are still some things I like about the original approach, but overall, I am happier with the second take.

OK, enough of FFG's expanded universe characters, let's get back to the canon!

Arwen

Arwen

I am happy with the color scheme on Arwen. Even though her yellows and greens are muted, they offer more color than almost every other figure in the set. I think this is fitting for her character. 

Balin

Balin

All the way from The Hobbit comes Balin in his distinctive red cloak. Similar to Arwen's gentle forest colors, I like how Balin's red makes him stand out. I tried to balance the warmth of the red by using cold greys to paint the raven on his shoulder. One thing I like about the dwarves in this set is that they are physically distinct from the humans and elves (which are pretty much indistinguishable from each other). The dwarves are not just small stout humans but really wide and stocky. The thing I don't like, which I mentioned in my original comments about Gimli, is that what they are wearing makes no sense. I'm with you from the hood down to the padded armor, but what kind of shoes are those? Why are there vertical striations across them? Dwarves are supposed to be master smiths and craftsmen, but I don't see that in this interpretation.

Dis

Dis

Barely-mentioned in the books and of obvious representational intention comes Dis. I think the figure is fine, although what's much more interesting to me is the contrast between her inclusion and how I understand the dwarves of Trudvang. In Tolkien's world, the unspoken assumption seems to be that the dwarf men and women mate like humans do, but the women stay in the mountains rather than soldiering or adventuring around Middle Earth. In Trudvang, dwarves are very different and exotic; not only do you only see male dwarves, their own legends about the mythical presence of women dwarves is what I interpret as evidence that they are not even males. That is, the dwarves tell stories about females who live far underground because they witness in other creatures a binary of sexes, but these same legends seem to me to mean that the dwarves are generated by the Earth itself, meaning they are no more men than is the stone. Fascinating, but I digress.

I like how Dis turned out, although after reviewing the cover art of the expansion, I understand why other painters have put her in golden armor. Once again here, the stockiness is really interesting, but practically, I don't see how she can walk in those greaves, her hands are exposed, she has the same oddly striated metal boots, and it doesn't look like she could put both hands on that hammer's handle if she tried.

This is the point in the set where, with the heroes and non-unique heroes painted, my sons and I revisited the Hunt for the Ember Crown campaign. We had tried it months before but suffered a loss near the end, so we ran it again, this time using Gimli, Elanor, and Balin, employing three of the new skill decks. Meanwhile, I moved ahead with the unique villains from the expansion as well as the three from the villain pack.

Balrog

Balrog

We'll start with the Balrog. It sat primed on my painting desk for some time while I considered how to approach it. One one hand, I had Sorastro's video, with its intense OSL and sparks, and on the other, I had also discovered Barks' more enflamed wings. I'm still on the fence about whether the source material should be interpreted as Balrogs being winged in the way a dragon is winged, but the sculptor already made that choice for me. After a few missteps, I settled on an approach that tries to emphasize the inner fire of the creature. There is subtle OSL on the underside of the wings, and I did very little highlighting besides that. The unfortunate result of the attempt to make the figure look shadowed and glowing is that, in regular light, it looks just unlit. I had initially thought of the Balrog like the Rancor, as being the showpiece of the set, but in truth, I think the result is just OK.

Spawn of Ungoliant

Spawn of Ungoliant

The Spawn of Ungoliant is the other unique monster from the expansion set. I agree with Barks that it was a fiddly model to paint. I think the egg sacks on the base turned out to be the strongest part. Honestly, I lost steam on the rest of it. I kept it on my painting table, and I would alternate between thinking that I could add some more colors and hue variation, and then thinking that it really wasn't worth it for a figure that would barely hit the table and that I wasn't really enjoying.

Incidentally, I think part of my lack of enjoyment has been my tools. I realized when looking at my order history that I've been using my "good" workhorse brush--a #1 Winsor and Newton Series 7--for four years. It lost its tip ages ago. I picked up some cheap brushes just to beat on, and I had kind of forgotten how it changes things when you actually pick out small details. I've bought myself some new good brushes for Christmas, so I'll stash those in my stocking and act surprised on Friday morning.

Ursa

Ursa

Here is Ursa, who, I must emphasize, is not a bear. I painted this figure as I did the Shadow-men, although it was months later so I had to try to recreate the hue of the glaze from memory. It turns out it is not a perfect match, but it should suffice: they still clearly are the same idea even if the tone is a bit different. After the initial glaze, I added a few spot washes to bring out the contrast in this figure. It gives it a bit more visual interest without taking inordinate time. I thought about painting the hammer or crown as metallics, but I really do think the monochromatic approach is the right one for my imagination of these ghostly characters.

Ollie

Ollie

I think I spent the most time on Ollie, in part because I was unhappy with my first pass at the skin and had to repaint that. It was strange, but I think what happened was that I didn't have a solid coverage in my original base coat, which meant that some of the underlying zenithal priming was showing through. When I added a highlight, it actually made the highlights darker because they were more saturated. What was especially strange though was that when I looked at it in the natural sunlight coming through the window, it looked OK, but once the sun went down and I looked at it with my office's artificial illumination, it looked terrible. This prompted me to just give it a clean coat, and I think the results speak for themselves.

I believe this photo is of the original skin, which even in the photograph does not look bad, but I'm telling you, there was some weird lighting stuff going on.


In any case, as with the other cave trolls, I like how mixture of techniques produces a strong model. I did hardly any weathering on any of these models, but I did stipple in some rust on Ollie's manacles. It was a weird observation, though, that it made the manacles look better, but almost made the rest look worse for the lack of weathering. In the end, though, they are not showpieces, so a strong tabletop quality suits me fine. (Although it makes me wonder: what would be a good project to practice weathering, and would it bring me joy?)

Supplicant of Morgoth

Supplicant of Morgoth

I don't know what a Supplicant of Morgoth is, but I did paint one. I gave this goblin a more pale tone than the rest in the set, and I like how the red surplice contrasts with the cold black robe. His robe is also curiously tattered, with numerous stitches and irregularities, and I think it gives him a unique look. My first pass on the figure had the beads hanging from his belt as metallic, in an attempt to keep a restricted palette, but I'm glad I juiced it up with a few different simple colors. I admit to some curiosity about how this figure shows up in the campaign, though I don't know yet if the boys and I will start this now or wait until after the excitement of new Christmas boardgames.

That's the whole set! Thanks for reading. As always, feel free to leave a comment, unless you're one of those spam bots who drops one here every few days. Those guys should knock it off.

Find the Ornaments: Thoughts about the December 2020 Fam Jam

My family has continued to pick a day each month for a Fam Jam, although I have not written a blog post about it since June. Yesterday, we completed the December entry, Find the Ornaments. The ten-year-old was the Creative Director, and over breakfast he expressed his idea primarily in terms of mechanics: he wanted an endless runner with collectibles. His original sketch included sharks and water, but our discussion turned it into a more holiday-themed game. Whereas some of the more recent games have been fairly straightforward in their implementations, this one required my learning some new tricks, and so it seems like the right time to gather some learnings here on the blog.

We knew we wanted to do long jump or short jumps depending on how long the jump button was held down, but neither I nor my 13-year-old had ever programmed this before. We started by trying to simply puzzle it out from first principles, but when it become clear that this was trickier than we initially expected, we turned to the 2D Platformer Demo for inspiration. The code here is strange, as it contains what should be good ideas (like functional decomposition) but expressed in such a way that make it very hard to follow. For example, at one point, the instance variable _velocity is assigned the result of calling calculate_move_velocity, sending _velocity itself as a parameter. Within the implementation of that method, the formal parameter name becomes linear_velocity, while there is local variable velocity that is used to build a solution. So, we use the velocity to compute the move velocity by sending the velocity to the linear velocity which returns the velocity. Not ideal.

I was also puzzled by the fact that I could not figure out where gravity was being applied. Clearly, something had to be pulling downward on the kinematic body of the player character, but where was it? My son pointed out that it was in the superclass script: it had a one-line _physics_process implementation that adjusted _velocity.y downward by gravity * delta. I pointed out that this could not be the code that was doing it because the Player class' implementation of _physics_process was not calling the superclass implementation. He looked puzzled and repeated that the superclass implementation was doing it, and so that was doing it. After searching online, I discovered that this is explained in the documentation, at the end of the "Inheritance" section, but not with anything like enough of a caveat as a seasoned OO programmer would expect. It turns out that overriding a method has two different semantics depending on what is overridden: if the method is an engine callback, then all superclass' implementations are called automatically; if the method is a custom method, then superclass methods are not called unless invoked explicitly in the subclass using dot notation. That is weird. It boggles my mind to think that the GDScript designers thought this was a good idea. I also wonder what kind of expectations it builds in the minds of people like my son who program primarily in GDScript but who will likely explore other languages later.

Coming back to the problem of short and long jumps, once I got my head around the semantics and the awkward program structure, I was able to see the pattern in how the demo solved the problem. It is an interesting inversion of my expectations. In our first, from-scratch implementation, I had been thinking of the character as going up while the jump button is pressed, but to a determined zenith, such that releasing the jump button would result in the zenith's coming sooner. The demo's approach was rather to launch the player at a predetermined speed upward, and then if the jump button is released, to apply a one-time decay to the upward velocity. This approach is much simpler than what I had considered because it fits neatly into the idea that each actor manages its velocity, rather than trying to determine a target location and solving for the necessary velocity on each tick. We implemented this approach and it worked great.

In between programming tasks, I worked with another son on the soundtrack. My wife had encouraged him to try transcribing one of the Christmas songs from his piano book into LMMS rather than starting from scratch. He gave me a thumb drive with the result, and I had to laugh. I assumed he had made grievous errors in transcription, so I sidled up next to him and the laptop to review and help him see what he did wrong... but aside from lacking measure alignments, it looked correct! That is, the phrases drifted from the beginnings of measures, in part because of a discussion earlier that morning, when I encouraged him in his own compositions to think about pauses between phrases, but the pitches of "Jingle Bells" actually looked fine. Puzzled, we started a new project and put in the opening phrase using a different sample, and this worked fine. The problem turned out to be the e_piano_accord01 sample that he was using, not the transcription. Now that's unexpected! This morning, I searched a bit and found a discussion on the LMMS forums in which it is pointed out that several samples have the wrong pitches. This actually helps explain some of the other audio strangeness in his past compositions: he might not have the sensitivity to know when he doesn't have just dissonance but actual out-of-tune samples... and I'm pretty sure e_piano_accord01 has been one of his go-to samples. I am not sure the best way to help him out with this on future projects. I could print that discussion and ask him not to use those particular samples, or perhaps I could download for him a MIDI soundfont and encourage him to use that instead.

The next major programming challenge was to implement the generation of tiles for endless running. We had made an endless runner before, but it had a simple, continuous ground with randomly generated obstacles; that approach would not work when making sequences of ground tiles that can have holes in them. For yesterday's jam, my son started on the feature by implementing a timer that would dump out tiles at a fixed interval, but I did not care for this implementation because this interval would then have undocumented dependencies on the speed of the character and the difficulty of the level. He had a Zoom meeting to attend, so I took this over and redesigned it, but I stumbled onto some other missteps as well. These were rooted in the fact that, from the beginning, we decided to have the character static and the tiles move past him; the more I worked with this, the more troublesome it was, in part because the math was all based on trickery. That is, in the narrative of the game, the elf is running forward, but in the code, we had the world moving past him. The first major improvement I was able to make that I felt good about, then, was to change that around and have the elf move forward in game space. This allowed me to align generated tiles with specific, integer coordinates instead of pulling shenanigans with floats and deltas.

To generate tiles lazily, I remembered a technique from a UE4 Endless Runner tutorial series in which triggers were used on each tile to tell the game to generate a further tile. This is a nice approach since it should scale indefinitely, or at least until the representational limits of floating-point coordinates. It is the approach that I took then. The logic for handling passing these tile-triggers was also easily able to be repurposed for the generation of ornaments.

The next technical challenge I faced was to place the collected ornaments onto the Christmas tree at the end of the game. I drew the outline of the tree as an irregular quadrilateral using a hidden Polygon2D. Then, the problem was to generate a random point inside this polygon. I could neither find nor think of a clever way to do this, but a clear brute-force method appeared before me: generate random points anywhere on the screen until one happens to fall in the tree's bounds. This simplifies the problem to one of determining whether a given point is within a polygon. Surely, there is an easy way to do that in the engine, right? Every search I did took me to discussions like this one, where the answer was either to do an awkward snapshot of the physics engine state space or implement a complete raycasting algorithm. I was quite frustrated and shouted out more than once that we should just do something different and easier. Near the end of my rope, I did something like this at a time when my son, working nearby in my office, had finished his own train of thought, and he said, "There is a method to determine if there's a point in a triangle." My response was, I believe, "What." He insisted he had seen it, and once we looked together, we found the Geometry class, which contains the method point_is_inside_triangle and, more importantly, is_point_in_polygon. (Note again the awkwardness of inconsistent naming conventions!) Of course, these methods do exactly what I needed, so that the hour of working on this feature only actually took five minutes of meaningful effort. What really puzzles me, though, is why searching for any related combination of words fails to find any reference to these useful utility methods. Maybe I can break ten readers on this blog post and help some other poor folks who end up in my situation.

Those were all the interesting technical problems that arose in the development of Find the Ornaments yesterday. It is always frustrating to spend more time on a feature than one thinks it merits, but on the other hand, each such adventure leads to more tools on the toolbelt. For example, when working on the parallax scrolling yesterday, I started by just trying to remember the right combination of settings, but then it was much easier to just pull up The Flying Planes from two months ago and see how we did it. Incidentally, if you do take a look at that game and this game, and compare them to some of our older efforts, you'll see some of the amazing tricks my wife has learned in Inkscape to make beautiful vector graphics backgrounds.

Thanks for reading! I hope you enjoy the game. 

Friday, December 18, 2020

Reflecting on CS445/545 Human-Computer Interaction, Fall 2020

This is the third in my sequence of end-of-semester reflections [1,2], and today's topic is my Human-Computer Interaction class. This was the course that I ended up designing twice this past summer. The end result was a great experience. Out of my three different courses in Fall 2020, I think this is the one where I was most consistently impressed with students' dedication to tackling the ideas of the course. And how many ideas there were! With the removal of face-to-face discussions, and knowing the limitations of discussion boards, I presented a wider variety of ideas to the students this semester than in the past. I will proceed by giving some brief thoughts on these additions.

One of the most obvious, sustained additions was adding Open Mind Platform, which I wrote about in October. It went as I had hoped, with my seeing evidence that students learned from the content of Open Mind itself but also thought critically about its implications for HCI design. I have also been in touch with the team that manages the platform, and I have reviewed some revisions that they are making to further improve the teacher's experience. Their dedication to improving Open Mind excites me, and I am glad that I was able to play a part in it. In fact, I recently added Open Mind Platform as an Achievement in my sketch of CS222 plans for Spring 2021, which will be the topic for another day's blogging.

I think I made good use of Scott Klemmer's lectures, balancing them against several of my own lectures that gave my perspective on various HCI topics. Whereas Klemmer's presentations were generic, I was able to focus mine on the specific assignments and tasks that I had in mind for my students. I do not know when next I will be asked to teach this course, but I will need to consider how I might reuse some of this course design for face-to-face classes.

Another valuable addition was Nielsen's Usability Heuristics. Given the challenges of empirical testing in the face of a global pandemic, performing heuristic evaluation was much more practicable. Nielsen's approach combined well with the ideas in Norman's Design of Everyday Things, Gestalt principles, and the accessibility heuristics we explored, showing students that there were multiple valid and useful ways to evaluate a system.

I am pleased with how the final project went. I assigned them a challenge that I myself faced earlier this year: taking a traditionally in-person Student Showcase from the CCSC Midwest conference and making it an online asynchronous event. Rather than just throw them at the problem, I scaffolded a series of six weekly assignments that walked through a reasonable, human-centered process. Only two weeks out of the six were spent on building, which I think surprised many of the students. The technical artifact was not the primary outcome of the process but rather a secondary one: the primary outcome was the report that students built on week by week. In the end, these ranged from about 15 to 50 pages long, depending on students' use of images and their attention to detail. After reading their final project submissions, I recorded a response video in which I encouraged them to consider the extrinsic value of this document, given that it provides clear evidence to potential employers that they themselves can follow best practices of design—not just parrot a few definitions from a textbook.

The final project was not without problems. Some students fell behind, and there was little recourse for them. I provided verbal instruction on how to progress; for example, if someone was unable to get a build working, I told them to reach out to classmates and continue the project using someone else's build. However, no one did that: they either made something up or gave up on the project. It is worth noting that the view counts on my weekly feedback videos were noticeably less than the course enrollment, so I am not even sure that the students in trouble knew that I had given them instruction. 

The best of the reports explicitly compared their results to the one that I used. I did not require this, but I was surprised that only of the students thought to use my solution as a benchmark. I was a little disheartened to see how many students praised their solutions based on the limited understanding and testing, but most seemed to be honest about their strengths and shortcomings.

While planning for this semester, I went back and read my post about the Fall 2019 offering, which regular readers may recall was particularly challenging. Seeing the high quality work of these students, I wish I had them in a semester with a properly community-engaged project! The CCSC Midwest Student Showcase was a fine case study, but it was still primarily about my work as opposed to a community member's. Ah well, if my biggest regret is that I could not get these students working on something even more public, then I think that means it was a great semester.

Thursday, December 17, 2020

Reflecting on CS439 Introduction to Game Design, Fall 2020

As the Fall 2020 semester wraps up and the asynchronous online final exams are trickling in, it's a good time for me to continue my series of end-of-semester reflections. Today's topic is my Introduction to Game Design class, offered as CS439, the design of which I wrote about over the summer.

I finished grading their final projects yesterday, and they were fun to review. I had each student record a short video presentation and post it for the class. These worked well and I may keep this idea even after the pandemic. It's one thing to give an in-class presentation and yet another to have a video that can be any length or watched multiple times. 

It was interesting to review the final projects in light of the requirements. This year, for the first time, I added a clause prohibiting the creation of content-centric games. Here is how I explained it:

The project may not be content-driven in the sense that the majority of the work involves producing content. Examples of content-driven games include Apples to Apples and Magic: The Gathering; by excluding these, we ensure that you demonstrate an understanding of systemic interactions rather than asset production.

I admit that this is a vague specification. Looking at the students' projects, there are a few fantasy adventures that collapse under the weight of their content. In all these cases, the students either were hindered from iteration by the quantity of "things" they had made, or in one case, they could not complete the project adequately because of the weight of content. I am unsure how to make the proscription more clear, except perhaps to be more direct about it in my review of their concepts. Then again, I know I warned some of these students that, if they pursued their declared path, they would get caught up in making cards, items, tiles, and so on, but it is not clear to me that my warning made any impact. I am not fundamentally opposed to such games, but it's clear that these students get caught up in too much unfruitful content production work.

The other major structural change to the semester was the inclusion of labor logs. Students were to copy a spreadsheet on Google Docs and log their labors then report them via a Canvas quiz each week. The mapping of effort-hours to course credit was clearly established, and so I did not monitor these: it seemed like a good place for automation. It turns out, I should have! While writing this, I went back and audited the responses, which required students to share a link to their copy of the labor log. It turns out that a third of the students kept a design log, not a labor log. In their defense, most wrote down timestamps with the same level of granularity as the spreadsheet.

This brings up an interesting question: is the labor log any more or less effective than a design log with timestamps? I suppose students were confused because I had recommended the use of design logs in Dan Cook's style. Of course, that was a recommendation, while the instructions clearly spelled out the requirement of labor logs—I suppose there is no underestimating a student's capacity to do what they want rather than what you tell them. Unfortunately, I do not see a way to crack this nut given the data that I have. Looking at the composite data and who ever recorded less than full credit, there is no clear pattern.

This leads into the final point I want to make on grading students based on their hourly commitments, and that is the accuracy of self-reporting and granularity of data. I use triage grading throughout, which means that A-level work gets 3 points, C-level work gets 2 points, and D-level work gets 1 point. For the labor logs, then, given the expectation of nine effort-hours per week, I set the A-level as eight hours per week, C as 57, and D as 24. Looking at all the self-reported labor grades, and only considering those students who completed the final project, 11% of them report anything besides A-level. There are two potentially overlapping interpretations of these data. The optimistic one is that, 89% of the time, the mechanism of asking students to track and report their hours kept them motivated to slog through and get things done. There is anecdotal evidence to support this, since the students' projects were actually quite good and certainly more polished than in many other years, and I saw students push through to the end of the semester, unlike in CS315 Game Programming, where progress ground to a halt for a week or two. The alternative interpretation is that, because grades were attached to the work, and exacerbated by the significant difference between the A and C level grades, students dishonestly rounded their efforts up to the nearest A. As with the issue of design logs vs labor logs, there is no clear path to determining which is correct.

As usual, students' final projects were graded on process and not on objective quality. I used a different rubric this year, however, which explicitly included 10% of the points for blindtesting. This resulted in almost every completed project having been blindtested, and reading students' status reports, this was certainly worth it. All who conducted blindtesting credited it with significant and substantial improvements in the design.

One of the most interesting comments about testing in general was from a student who said that, before getting deep into the final project, he thought of playtesting as being like the proofreading one does before turning in a paper. After finishing the final project, he realized that it was an integral part of the design process—something you do to improve the design, not just to "check" it.

Those are the major findings from this semester. As I mentioned above, my students are still completing their final exams, and they have until Friday night to do so. If I see anything in the exams that should be mentioned here, I'll post an update. Otherwise, thanks for reading!

Wednesday, December 16, 2020

Reflecting on CS315 Game Programming, Fall 2020

This is the first of my traditional reflection blog posts, in which I share some of the successes, failures, and mysteries of teaching. The good news is that all three my courses went surprisingly well, given the unprecedented constraints that we were under. 

As I shared in my planning post, the game programming class switched to Godot Engine this semester. This ended up working quite well. While I enjoy working with Unreal Engine 4, it is fiddly in ways that trip up novices, and I need to seriously consider whether Godot Engine is a good permanent replacement for UE4 in CS315. 

The students had the usual confusion around intellectual property licensing, and it's not clear to me how much I need to get out in front of it vs. respond to their misconceptions. I fear that time I spent trying to explain this up-front would be wasted, as so many students would still get it wrong that I would repeat it all anyway.

The checklist approach to grading projects continues to work well, and I think that this clarity of expectations was especially useful in the absence of shared lab time. I have gotten better at documenting these, which also helps. One question that remains in the back of my mind is the distinction that Nilson makes between more hurdles and higher hurdles. She suggests one or the other, while I continue to do both. I wonder if there is an alternative model for game programming projects that would take the "more hurdles" approach, although it also seems to me that then you're just doing regular points-based grading where only a subset of points is required. 

In the manifestation this semester, I played some more with the idea of "stars" at the A-level, so that students could see some of the variety of actions that could be rewarded. Unfortunately, most students clearly settled on the ones that required the least effort, which makes the endeavor seem like a presentation of false choices. Next time around, I could spend some time reconsidering this, although I do not think it's that bad to leave it as it is. A few students were able to be rewarded for doing some unconventional things, and that is the main point after all.

The heartbreaking moment this semester came when in grading the final iteration of the final project. This spanned the two weeks after Thanksgiving break, when the university shifted entirely to asynchronous online instruction. In my mind, this should have been the great push, where students bring together everything they learned and make some really interesting projects. What actually happened is that almost everyone made zero progress for most of those two weeks. Almost all the activity on the projects took place in the 72 hours before the deadline. Some students basically lied about their efforts, though the git logs gave away their true patterns, while others humbly acknowledged not having done adequate work: both groups earned the same grades, but I am proud of the latter while bitter about the former.

I sympathize with the students' bad situation. I have some confidential messages that provide more evidence for my suspicion that a lot of faculty did not handle this semester well. Some students will always complain about end-of-semester workload, but when essentially all of them do, one has to wonder if there is a systemic problem. My defense to my students was that we had the same pattern of expected behavior all semester, and indeed, some students have thanked me for that; however, this doesn't change the other stressors in their lives, or the potential of uneven distribution of labor expected from other faculty who appear not to consider the consequences.

Despite the expectation that my students maintain steady progress for each two-week iteration, I did not create any incentives for this behavior. It makes me wonder if, next time, I should incorporate something like labor logs, where students are graded based on self-reported time-on-task. I tried this approach in my game design class, which I will write about later in this series. This would give them positive feedback in the form of grades for those weeks where there is no deliverable. Another alternative would be to have weekly check-ins or status reports rather than biweekly deliverables. I will need to consider the costs and benefits of these approaches next time I teach the course, which I hope to be in Fall 2021.

Another puzzling factor in this class, and in both my other classes, was that many students stopped turning in material and yet did not withdraw. My intuition is that there were more of these students this semester than in the past. That is, there are always some, but I believe I had a higher proportion of them this semester. I wonder if this is because of the online asynchronous nature, if students deluded themselves into believing they could catch up, when all the evidence was that they did not have the conscientiousness to keep up. I will be interested to talk to my colleagues about this, including those outside my department and my university.

In summary then, it was overall a great experience in teaching game programming, and some of my students made some really great little games, for what they are. My favorite is the one that used the sprites from Tyrian, which ratcheted up the nostalgia for me. The experience was slightly soured by disappointments in the final iteration of the final project, but at least I have some ideas of how to mitigate this next time. 

Note that the students are completing the final exams this week, so the course is not yet completely over. I will post an update if there's anything in the final exam responses that make me rethink anything I have shared here. Thanks for reading!

Tuesday, December 8, 2020

Ruminations on planning CS222 for Spring 2021

I am scheduled to teach two sections of CS222 next semester. The pandemic situation contributed to a strange turn of events where the college took over scheduling, rather than having it be done by departments. The outcome is that the course is scheduled Tuesday and Thursday in-person, but in rooms that cannot safely hold the whole class at once. The assumption then is that we would adopt Rotational Hyflex teaching, where the class is split and half are expected to attend each day. My protestations about logistics and pedagogy fell upon deaf ears, and the faculty have been told in no uncertain terms that we are expected to teach in the manner that the college dictated.

I started looking at Spring plans over a month ago, then I successfully put that off in favor of less stressful tasks. Today, I got back into it, and I saw the last timestamp on my plan sketch was in fact November 8—exactly one month ago. 

The primary source of stress comes from trying to determine how to satisfy what seems to be an impossible situation. How can I meet the educational needs of the course while also meeting the expectations of the administration? I have found myself throttling between different options and unhappy with all of them. This has led to my decision to write about it, in hopes that either I will discover something new, divine an appropriate decision, or gain some insight from my readership.

First, let me identify the major complicating factors, most of which arise from requirements for physical distancing.

  1. Students cannot pair program in person without Zoom screen sharing.
  2. I cannot sit with students or teams to debug their code without Zoom screen sharing.
  3. Students cannot go to the whiteboards to do collaborative design activities without using online simulated whiteboards.
As you can see, all the main activities of the class besides individual programming, writing, and discussion are better done online than in-person. Note that programming and writing can be done individually offline anyway and have no impact on contact hours, and I would argue that discussion is better mediated through Zoom, where you can see faces, than in-person, masked, and distanced.

Taking that into account, here are the options that I have identified:

Toe the line: Rotational Hyflex

The obvious problems here are the ones identified above: all the interactions I would do in person are better done online. Arguably, we could have some in-person discussions, but they would be hampered by an inability of students to show each others' code, or for me to see their code, in any kind of organic and realtime way.

This also puts a Tuesday/Thursday split into the class that has impacts on deadlines; to be equitable, one would need to balance deadlines based on whether it were a Tuesday or Thursday group. This would be a pain, keeping in mind that I would want to maintain my practice of regular assignments and allowance for resubmissions.

I cannot think of any advantage to taking this approach.

Rotated classroom meetings as recitations

One way to approach rotational hyflex would be as recitations for an online asynchronous class. That is, the main course content could be asynchronous online, and the in-person meetings could essentially be study or review sessions. This is a convenient metaphor perhaps, but it breaks down quickly in my mind. The review sessions would be hampered by the problems mentioned above, where I could not actually sit with a student to look at code or writing. Potentially worse, it would be throwing sophomore computer science majors, in a challenging course, into a fundamentally asynchronous online learning experience where small lapses in responsibility can lead to compounding deleterious effects. Of course, this inherits the Tuesday-Thursday deadline problem as well, although big research universities simply ignore this problem and let students struggle with the schedules they are given.

An advantage of this approach is that I could prepare the courses in a familiar way, given my experience teaching asynchronous online this semester. Students would have a consistent set of materials, assignments, and assessments regardless of their section.

Treat the course like four small sections with one meeting day per week

If I split the class, I can think of this as four classes rather than two split ones. I would repeat the same activities four times per week, using half the contact hours I normally would. This means pushing a lot of content into an asynchronous online modality and using the one meeting per week to pick up the pieces.

This would require fiddling with deadlines in a kludgy way as above so that students had the equivalent amounts of time between discussions and deadlines. I hate to imagine how messy Canvas would become!

The university introduced three "study days" during the semester, one of which is on a Tuesday. This means that, halfway through the semester, the sequencing of Tuesday and Thursday classes would swap, with Thursday leading and Tuesday trailing. This, too, will have a frustrating but not insurmountable impact on deadlines.

This still inherits all the problems of the straightforward recommended rotational hyflex approach: basically everything we would do in person is better done online.


Rebel: Teach entirely online synchronous

I could just do what my pedagogic sense is telling me to do: teach online synchronous regardless of what the college office cooked up. This would mean I get to see all my students at once and can maintain a regular pace of activities and assignments across them all. Discussions can be had via breakout rooms, and screens can be shared via Zoom. Meetings can even be recorded for students to review later in case they missed something in the presentation, for example, to see me walk through a technical or design process again.

There are some pieces here that are still a black box to me, though. This semester's online asynchronous classes actually went quite well. I'll have more to say about them in upcoming blog posts. I have never taught online synchronous, and so I am not sure about certain aspects of how it will go. Let's say for example that a student is in class, and we're dealing with source code. They would want to have Zoom and an IDE open, but the IDE really only works if it's fullscreen, and I know more students work on laptops than on two-headed displays. How could I possibly look out over the class and know if a discussion has hit home? Heck, they might just be on Instagram and not tuning in at all. 

Another conundrum I face is the relationship between online synchronous and my YouTube tutorials. It students just sit and listen to a demo, they may as well be watching a prerecorded session. Indeed, if it's recorded, I only have to do it once instead of twice! However, the important thing is that they ask questions to direct the demo. Will they be willing to do so in an online environment? I am hopeful that they will, but I don't know for sure. Again, I have blinders about what I will see in an online meeting, where students are supposed to essentially have two major things on their screens at once. Normally, in the classroom, I have something on the projector, stuff scattered around the whiteboards, and the ability to walk around, among, and behind students to see what they are doing and help keep them on track. That all seems to slip away when we're tethered only by the thread of one narrow shared window. Put another way, I am uncertain how affordances for learning are impacted by what aspects of the course get "flipped'.

So...

My inclination then is to take the last approach and accept the consequences. It's the only one that seems to actually use the available tools in a responsible way. I'm still really puzzled about how to facilitate learning in this modality. It may be the kind of thing that I can pick up as I go, but it may also be the kind of thing where the first time you do it, it's terrible. Perhaps I should reach out to my current students and solicit their feedback about what has worked well or poorly for them this past semester. They are probably all stressed with final projects now and unlikely to volunteer time for such an endeavor, and I cannot even offer Christmas cookies as compensation. 

I have some time to sort this out, of course, but I would like to get as much done in the next two weeks as I can. I gave up essentially my entire summer trying to create a good experience for my Fall students. I would rather not also give up my winter break so that Spring is passable. Tenure and promotion means that I need not panic if I don't get a grant or paper complete during the break, but I also feel a desire for some rejuvenation.

UPDATE (12/9)

I talked with a colleague about some of my planning conundrums, and he pointed out that the three complicating factors I mentioned in the opening are not quite right. The rule from the university is not that students must maintain six-foot social distancing at all times in the classroom, but rather that any closer contact be limited to less than fifteen minutes, as per CDC guidelines. This means that pair programming, debugging code, and whiteboard work are not necessarily out of the picture, but rather that they must be done with additional constraints. I am still mulling over the implications of this oversight in my original considerations, and I have reached out to those teaching on-campus this semester to try to get a sense of how comfortable or anxious students are around such in-class activities.

Thursday, December 3, 2020

Sharing three sons' NaGaDeMon experiences

This is my final post in my series (1, 2, 3) for National Game Design Month 2020. Like last year, I was not the only person in my family who was working on NaGaDeMon projects. My three older sons each worked on projects, and two of them saw these through to completion. I encouraged each to write a reflection about the experience and worked with them on the structure and form of a good reflection.

I am proud of their dedication, and I am pleased to share their reflections and project links below.

#1 Son (13) Project: Sprite


Reflection:

I wanted to make a multiplayer game that my brothers and I could play together over the Steam Link. I knew I wanted there to be spinning swords and the NaGaDeMon as the final boss. I also wanted to make the game in Godot.

This was the first project in which I used the Light2D node, and I think that it worked out quite nicely. The light node requires a texture as an emission shape, so I had to make a circular image that faded into oblivion at the edges. Initially, I tried using Gimp, but couldn't figure out how to make what I wanted. I went back to Piskel and made a suboptimal image there. Because Piskel is a pixel-based editor, I was only able to make concentric rings with the alpha value increasing towards the center instead of a smooth gradient. The bright side is that I learned how to make colors translucent in piskel, which is something I must have done accidentally before and didn’t know how to undo.

Because I wanted to be able to play my game over Steam, I had to export it to a Windows executable and then add it to the Steam interface, which were both new to me. I never got the casting to steam link to work quite right, but I think it was a problem with the steam link and not my code, because it works well on the computer directly. I had trouble with the enemies spawning inside of walls, so I learned how to make a raycast via accessing the game physics and get the collision point where I then could spawn the enemy.

I wasn’t able to make the sword spinning work perfectly until the very end of the month. I initially had it set up so that if you moved the stick right, the sword rotated counter-clockwise, and when you moved it left, it rotated clockwise. That worked well, but it was hard to control. Then I changed it to having the sword point in the direction the stick is pointing.

Many of my variable names were repetitive and/or vague and had inconsistent privacy (in Godot, an underscore in front of the variable name), which made it hard to tell at a glance what was going on and made it hard to remember which variables were which. I also used a lot of serial if statements, which are really hard to read when there is more than one condition or it’s inside of some other function. I did learn something else cool, which was how to typehint a function return (In Godot it is [-> variable type] at the end of the function before the colon).

If I were to do it again, I would ask how to make a better light image in Gimp instead of making something in Piskel. I should export more of my values to variables so that my code is more readable. I would also make the enemy-spawning lightning bolts extend to where the enemy is being spawned, rather than being a static length. I wanted to make the final boss have multiple lives and attack methods, but never got around to that.

I had a problem with my sword rotating towards the direction the stick is pointing. My code was basically “if value > current_value, rotate counterclockwise. Else, rotate clockwise.” Dad pointed out that if value = 360 and current_value = 1, the sword would rotate the 360 degrees counterclockwise instead of one degree clockwise because value is greater than current_value. Dad found a piece of code that was totally beyond my comprehension, but worked perfectly. I would like to learn more about radians for my next rotation project, because when we incorporated the code from the internet, we had some trouble with mixed degrees and radians.

I had a lot of fun making this game, and I learned some neat things as well. I look forward to incorporating them into other projects.

The code for the seamless rotation is here: https://godotengine.org/qa/41043/lerping-angle-while-going-trought-shortest-possible-distance

#2 Son (10) Project: The Magic Amulet

Reflection:
Hi! I am writing this reflection on The magic amulet, my NaGaDeMon game. I had four main goals going into this project: I wanted to make a backstory, I wanted the character to wield some kind of weapon that can spin, I wanted to make death animations, and I wanted the enemy spawners to go with the back story. I managed to incorporate all of those into my game.

I had a lot of fun creating the art for The magic amulet. The kobold knight was some thing I have been wanting to put into a game for a while now, and I like the animation I put on his cape. I had a lot of fun with the animation on the enemy chaos wisps.

This is my second NaGaDeMon project, my inspiration for this game actually came from another one of my construct games. The magic amulet is not finished because I got tired of working on it and decided I would like to start a new game. thank you for reading this reflection on my game.

#3 Son (8) Project: Keep


Reflection:
The layout went pretty well, But I had some trouble with the guy.

I learned some new coding techniques like: making two layouts use the same event sheet, making you pick up things, and making your money show up on the screen.

Next time I would make the enemy move on the screen.

Something I would do differently next time is: I would make the enemy move on the screen.
Dad's Note: This son had done a project last year too, but was interested neither in writing about it nor releasing it. This year, he was excited to be a full participant. To help with his reflection, I gave him the same kind of format I give my university students during sprint reviews: What went well? What did you learn? What would you do differently? What still puzzles you? You can see echoes of these questions in the structure of his response.

Tuesday, December 1, 2020

Intrigue: A Three-Player Print-and-Play Card Game made for National Game Design Month (NaGaDeMon 2020)

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.