Friday, October 13, 2017

A novice game designer's self-assessment instrument

Yesterday's meeting of my game design colloquium was where the students and I developed a schedule and expectations for the remainder of the semester. We have finished the foundational material of the first half of the semester, and we are shifting into final project mode. I might write more about that meeting later, but for now, I want to share a small piece of the meeting. Most of these students have no prior game design experience, and some seemed a bit nervous about the final project. Of course, I think the source of their nervousness was grades and not quality of outcome, but let's leave that alone for now.

One of the students posed a question to me that I don't remember being asked before. They wondered if I had some kind of self-assessment that they could use to determine if they are "moving in the right direction." I believe that was the phrasing, although it may have been "doing the right thing." In either case, there was a clear assumption that there is a right way to move forward in game design and, furthermore, that I could grant this.

My instinctual reaction was "No," but then I immediately thought, "Why not?" The students have spent most of their time reading Ian Schreiber's Game Design Concepts, along with some other of my favorite readings as listed on the course schedule. We have talked about design as a cyclic process—a feedback loop where testing results inform design modifications. However, in the student's defense, we have talked about a lot of things. It's easy to see how a novice could feel lost.

Here's what I came up with as a suggestion for a self-assessment the student could apply:

  • Is the goal clear?
  • Is there conflict that prevents you from meeting that goal?
  • Are the decisions meaningful?
I don't think that's too bad for an off-the-cuff response. A couple of things were floating through my head as I articulated this. One was the very first exercise I gave them, which was the 15-minute game design challenge from Schreiber Level 1. The challenge walks you through making a simple race-to-the-end board game, and he walks you through four steps: draw a path; come up with a theme or objective; define movement rules; add conflict. Another was Sid Meier's famous quotation, "Games are a series of interesting decisions," tempered with Keith Burgun's assertion that these decisions must be endogenously meaningful.

I offer this as a thought-piece and the draft of a tool. If you try using it in, let me know how it works out. 

What questions would you put onto a self-assessment for novice game designers?

Saturday, September 2, 2017

MDA, Cheating, and Levels of Analysis

One of the early-semester assignments I give my students is to read the Hunicke et al. paper on MDA analysis, and then to analyze a familiar game within this framework. This works best after I have introduced the concept in class with an example, usually Buffalo since that game is worth studying in its own right. Re-reading the classic paper reminds me that although it has had undeniable impact, being one of very few pieces to transcend the games research / games practice divide, it is not very rigorous. I think the core idea of it is quite brilliant: that we can, and should, consider the differences between what designers control and what players experience. Years of using this model have led me to internalize it with my own variant, which I explain to the students roughly thus:

  • Mechanics are all those elements that the designer directly controls.
  • Dynamics are what happens when the mechanics enter a play experience.
  • Aesthetics are the sensations that arise from the dynamics.
By this framework, which I believe resonates with the original paper, then we can see that the rules, story, art design, physical components, etc. are all mechanics—leaving alone for the time being whether these ought to be called "mechanics" or "mechanisms", though it's almost certainly the latter. The dynamics would include phenomena such as strategy, bluffing, and negotiation, and the aesthetics are all the sensations: fear, joy, shame, kvell, and the satisfying tick of a meeple hitting cardboard.

I have met with this year's game design class four times so far, and I have a good feeling about them, and about the changes I've made to the course structure. In their MDA analyses, several brought up cheating, which I honestly don't remember coming up before. It came up in three different manifestations, all of which were framed as "cheating" by the students. Two students brought it up in terms of card games, engaging in activity such as looking at opponents' hands. One mentioned stream sniping in online games, a phenomenon afforded by the trend toward modern gameplay technology and culture. One other student mentioned "glitches", referring to taking advantage of defects in software to take actions in computer games that were—presumably—not intended by the designer.

It is interesting to consider at what level cheating exists within MDA. Cheating is, by definition, a violation of the mechanics. However, I agree with Koster's assertion that if you change the rules of a game, you are playing a different game with the same pieces [although right now I cannot find his essay that states this, so if you do, hit me with the link so I can update this]. The classic example is that many people play Monopoly such that money accumulates on Free Parking and is gathered by players who land there—but this rule is, of course, not in the rules of Monopoly. Hence, we could consider them to be playing a Monopoly variant with the same pieces as Monopoly. From this perspective, then, cheating means you are playing a different game. I think that's an important observation that emerges from this kind of formal, ludological study of games. Note that it's different from a game that permits "cheating", such as the variant of Cosmic Encounter that says you can do anything not in the rulebook as long as you are not caught. From the formal perspective, though, what's really happened is that we've changed the rules of the game to include all possible activity as mechanics, most of them tagged with the caveat that if you are caught, you pay the price. That is, it is not cheating as such since it is actually part of the game variant's mechanics.

I have been listening to Jordan Peterson's lectures on personality, and it has been interesting to learn more about Piaget—a superstar of educational theorists, which is where I have previously seen his name and theories—from a personality psychology perspective. Piaget seems to have framed practically all interesting developmental human activity as a game, which certainly resonates with my experience and research. From Piaget via Peterson, I have been thinking about the game of being invited to play games, which for simplicity I will call the social game. Why do we say "It doesn't matter if you win or lose, it's how you play the game"? We do this because each game is instantiated within the social game. If you are ungracious in victory, if you are bitter in defeat—or if you cheat—you lose at the social game. Hence, we can assert that "cheating" is actually a mechanic of the social game: it is a move that is allowed, but it is almost always a losing move.

The idea that there are multiple levels of analysis has also come up several times this semester. For example, it has given us a way to think about the sometimes-toxic communities around online games: there is a poorly-regulated social game around these which was brilliantly skewered in Koster's most grave presentation, his GDC 2017 talk "Still Logged In". We applied a similar form of analysis to consider the game of competitive Magic: The Gathering, that there is the embedded game that is a round of MtG, but that is within the context of the gambling-and-trading-game of buying packs and chasing rares. Both are also simultaneously within the "meta", the game of knowing what decks are popular, locally or globally. Some of my students were surprised to consider these higher-order games as also being designed; they had previously considered that the designers made a game and that the community somehow made the rest. However, MDA gave us an important tool here too, to look at the mechanics of rarity, legal deck sizes, and distribution, and how these designer-specified mechanics led to dynamics such as chasing rares.

Peterson's lectures frequently bring up the concept of multiple levels of analysis, and this seems to be a critical concept in understanding personality psychology. I suspect that it was my studies here that have influenced my looking at games from this lens. I suppose this speaks again to the power of interdisciplinary, since I know that some of my best scholarship has arisen from my seeking out novel ideas and integrating them into my areas of specialization. Even studying games themselves, it was a journey from Summer 2006 that shaped how I think about all the work I do today. Seems Piaget had it right.

Wednesday, August 2, 2017

Painting Emergence Event and Emergence Event: The Awakening

And now for something completely different: Space Ships!

I didn't know much about Emergence Event when I backed the expansion on Kickstarter, but I have enjoyed Myth (painted), and so I was eager to support local game designers and publishers Megacon Games. The Kickstarter provided an option to get both the base set and The Awakening expansion, with an option to pay for shipping only once and receive both at the same time. Turns out, the base set still came a few days in advance of the expansion, so I was able to play it a few times before the expansion arrived. My son and I have enjoyed it, although it is a bit fiddly at times—there are a few things you just have to remember, because there is no visual representation of them on any of the bits.

I primed all the figures by brushing on Grey Vallejo Surface Primer after giving them a good scrub. The expansion add-on captains required an extra layer: something about the plastic repelled the primer more than the others. Overall, though, no major difficulties with the prep for the base set ships, with very few mold lines to clean up.

Masking tape: Not my greatest idea.
The base set ships all came pre-assembled on clear plastic bases. I didn't want to get paint on these bases, so I wrapped them in masking tape. Seems like a good idea, right? Turns out, it wasn't. The masking tape left some sticky residue all over the base. I posted a question about this on DM Scotty's Facebook group, and several people recommended either Goo Gone or isopropyl alcohol. I happened to have some 91% isopropyl alcohol at the hobby desk, and this worked fine for removing the residue, combined with an old brush and my dental scraper.

For all of the ships, I tried to match my color scheme to Keith Lowe's excellent character art with an emphasis on the captain's token color. I'll start with the base set ships.

Star Racer Vinh
Star Racer Vinh
My first ship was Star Racer Vinh, who uses faded green tokens. I also pulled in the complementary red that is featured in the character art. One of the decisions I had to make was how to light the models. Even though they are in space, I decided to go with a traditional overhead light source. I suppose one could think of them as hovering over a planet that is reflecting some light back up to the underside.

For almost all the ships, I used a two-brush blending approach. I have a wonderful Winsor & Newton Series 7 #1 that was the workhorse for the whole project, and it's kept a fine tip on it. For the second brush, I'm using my old WN Series 7 #2, which has lost its tip but not hooked. It's not ideal since it's so broad compared to the #1, but it's good enough for now. I've tried two-brush blending with synthetics as well, but I think the advice I read somewhere on the Internet is right, that natural fibers do feel better for this technique. 

On to more ships!

Commander of the Evolved 
Commander of the Evolved

The Commander of the Evolved was fun to paint, with its high contrast and focus on cool greyscale with a spot of brilliant blue. I used just a little bit of OSL to imply shining light, but I don't think it photographed very well here.

Ambassador Jolal

Ambassador Jolal
The other morning, I was up early and decided to base coat Ambassador Jolal's ship. This is the only organic ship of the set, and so I opted for some wet-blending to get smooth transitions across the bumpy surface. I was so happy with how that went that I just kept on mixing more colors, highlighting, and shading. I ended up finishing this ship in one sitting, and I'm happy with it. It is much stranger than the other ships, and I think the fact that I painted it a bit differently adds to its foreign appearance.

Matriarch Evans
Matriarch Evans

Matriarch Evans' ship is all greys offset by crimson. Reds are tricky to highlight, and I really didn't want to take this one toward orange or yellow. This happened to be the ship I photographed when I posted on DM Scotty's Facebook group about the sticky residue, so I have this picture of my original paint job:
Matriarch Evans, Before the Finishing Touches
Even with the slightly-blue panel in the front, it turned out to be all too similar in tone. I showed it and the character art to my wife, and we agreed that it needed a little something extra. I'm glad I took the time to add the bright banding and alter some of the grey tones around the front.

We move now to the four expansion captains. The Kickstarter campaign called for two captains in the expansion, with two extras available as add-ons. Never having played the game, I wasn't sure I wanted to throw another $20 at a pair of captains, so I opted against. After playing the base game a few times with my son, I kicked myself for not having splurged on the extra captains. This feeling was exacerbated by the current somewhat uncertain future of Megacon Games. They announced a while ago that they were under an NDA as the Myth IP was under negotiation for sale, and their recent post on the Myth: Journeyman Kickstarter confirms their somewhat shaky current state. This might mean that those two extra captains may never be available for retail sale, so I was out of luck.

Lo and behold, when I opened my Awakening expansion box, there are four captains—the two promised ones and the two add-ons! The guys from Megacon posted that they decided to simply add them to each box, which I'm sure greatly simplified production and packaging. Naturally, this led to some sour grapes from people who paid the extra $20 for add-on captains, in a weird twist of human psychology (they got what they paid for, after all). When I look at the comments on their Kickstarters, I cannot help but feel that a lot of people forget to read the clear statement that Kickstarter is not a store. Maybe guys like Megacon and Kickstarter-giant CMON give the wrong impression, by talking about orders and add-ons, but the fact remains, any Kickstarter can simply go south. That's how I approach it, anyway, and look, I got two free captains.

But I digress! Back to the ships.

The two add-on captains for Awakening were made of a different kind of plastic, and possibly probably a different scale than the other ships judging from how they did not fit neatly onto the pegs. Unfortunately, my ships were quite badly cast, particularly Xeron & Xoron.
Xeron & Xoron have seen better days
I wasn't quite sure what t o do about this much damage. I briefly considered requesting a replacement, but again, those guys from Megacon I think are dealing with enough right now. I ended up turning to my old standby, Milliput. I was able to press it into the deepest gaps and then try to smooth it over. I also thinned it out and tried brushing it over the rough areas, but I don't think that was particularly helpful.
Xeron & Xoron, patched up with Milliput
Here's what the back-end finally looked like painted. From across the table, I don't think you can see the anomalies.
Back-end of Xeron & Xoron
But more on them later, because it's really important to me that I post my miniatures in the order I tackled them.

Explorer Laris Latee
Explorer Laris Latee

Explorer Latis Latee was one of the add-on captains, and he has the smallest and sleekest of the ships. His character art also features cyan and yellow, which I know are everyone's favorite subtractive primary colors. The rounded features of this ship made it more interesting to shade than some of the other, more angular ones. It was also fairly quick to paint, given the relative lack of detail.

Hive Queen Zalex
Hive Queen Zalex

When I worked on Hive Queen Zalex, I pulled out what I thought were her character tokens, only to discover later that I had the wrong ones. The purple tokens went with San'Du, not Zalex—hers are grey. Turns out it wasn't a problem since I had featured both purple and grey on the paint job. Zalex is the only figure where I used an ink wash to make the shading a bit easier: those magenta stripes have finely sculpted vertical slats, which would have been a horror to paint by hand. Mixing a dark purple ink wash made it much easier to help them stand out a bit, although it's not very strong in the photos here.

Xeron & Xoron

Xeron & Xoron
Every captain in Emergence Event has two special abilities. I like this idea that Xeron & Xoron are a pair of captains, and so you have one Xeron power and one Xoron power. It's a small bit of fluff, but clever nonetheless. One is wearing an orange jumpsuit, the other a military green, and so I brought those colors in to the ship. The orange jumpsuit was a bit more faded than the orange tokens used by this captain (these captains?), and I opted to match the tokens so that it would be easier to tell who is who. The character art is barely visible during the game, after all.

San'Du, VP of Acquisitions

San'Du, VP of Acquisitions
The last one of the set is San'Du, VP of Acquisitions—the one that actually uses the purple player tokens. I wanted to make sure his purple ship was distinct from Hive Queen Zalex, so I brought the bright white to the fore. It's a little chalky, as whites can be, although this doesn't show in the photos so well. (See my Twin Shadows painting post for more about my frustrations with miniature photography and the black backgrounds in particular. Still, seemed right to use black here, because SPACE.) The slightly chalky white top and a few other spots could be touched up, but as I was wrapping this up, my Clank! expansion showed up in the mail, and I took that as a sign that it was fine to be done with this. (Another parenthetical: my 10-year-old, my 7-year-old, and I have been having a blast with Clank!, which followed nicely after the younger one was able to learn Star Realms and Dominion.)

Front row: Base Set. Back row: Expansion.
That's it for Emergence Event and Emergence Event: The Awakening. I'm looking forward to playing again with the painted miniatures instead of the wooden pawns we've been using as proxies while these have sat on my painting table.

Thanks for reading!

Friday, July 28, 2017

Summer 2017 Course Revisions: CS222 Advanced Programming

This is the last in my series of Summer 2017 course revision posts, turning to the course I teach every semester and revise every summer: CS222 Advanced Programming. The most significant changes to this course result from its finally returning to a twice-per-week meeting schedule. When I first offered the course, it was on a Tuesday/Thursday schedule. The extra 25 minutes in a meeting gives time for more sophisticated discussions and more hands-on practice. Also, with two meetings per week, I was able to give assignments every day and still turn them around rapidly. A few years ago it was moved to a MWF schedule, and I remember the meetings feeling very short. Also, I feared I wouldn't be able to keep up with three grading marathons per week, and so I switched at that point to my weekly assignment schedule. That very semester, I asked to return to the twice-weekly schedule, but this request was forgotten or not acted upon. Several friendly reminders later, I'm scheduled again for twice per week.

There have been a few changes over the years that mean I cannot simply pull back in my old course plans. The original incarnation of the course used Joshua Bloch's Effective Java as a text. In the intervening years, I switched over to Robert Martin's Clean Code, which gains generalizability over the Java-specific information in Bloch's text. I have been happy with that transition. Another significant change is in the structure of the course. I used to have about five weeks of introduction, a two-week project, and then a six-week project completed in two three-week iterations. Several semesters ago, I decided to cut the introduction short and add an extra three-week iteration to the final project. As with the change in texts, I think this was a very positive change.

I have decided for the Fall to bring back the "daily" assignments during the first three weeks of the course. I also plan to extend the assignments into the project portion of the course in order to help students stay on track. For example, I like to introduce design thinking each semester and have students consider a five-step design-thinking process and consider what it means to their team and their final project. This is usually isolated to class time, and I suspect most people don't carry this idea with them after the discussion. Giving a small essay assignment after the in-class exercise should both reinforce the material as well as incentivize attendance and participation.

I started the process of breaking down the weekly assignments into twice-per-week assignments, but I haven't quite finished that yet. I think I may just leave it as-is, though, and see how the first week of classes goes. I would like to leave the door open to allow myself to transition in-class discussions more smoothly into assignments, having students wrap up some examples or write responses to an idea, for example. This kind of spontaneity appeals to my just-in-time teaching philosophy, although I am a bit concerned about teaching three courses on Tuesdays and Thursdays with 90 minutes between each. I will need to safely guard the 90 minutes after CS222—the first course of the day—to give myself time to tweak the assignment for the next day and to prepare myself for the next class.

The rest of the course will stay pretty much the same. I will come up with a reasonable two-week project, likely reusing my Wikipedia Analyzer project but modifying it to use JSON rather than XML. One of my students pointed out in the Spring that Wikipedia's XML API is being deprecated, so I may as well get my students in CS222 doing some JSON parsing. The final project format will remain the same, except for the occasional assignment dropped in to keep students honest. I am keeping the achievements as well, although using the smaller number of creditable achievements that I tested in the Spring (four) rather than the larger number I had been using in the Fall and previously (six).

The current draft of the course description is online. I recreated my course site design based on the Polymer 2.0 release, and the sites for other two courses I wrote about earlier this week were derived from this one. The navigation no longer has to make use of hash paths, thanks to the service worker. This caused me a slight headache the other day when I loaded the page over HTTP and all the navigation broke. I was able to port the essential parts of the platinum-https-redirect element, which does not yet support Polymer 2.0, to force my course pages to load over HTTPS. I also tweaked the sw-precache configuration this morning for all the sites, hopefully in such a way that the static content is appropriately cached for offline access.

I feel good about getting most of my course redesigns done this week. I will be participating in my university's pilot of Canvas as an LMS, and I have spent some time tinkering with it as well. It seems like it will serve my needs well, and it has several features that are clearly superior to Blackboard. I am curious to hear what others in the pilot think, especially those who were more entrenched into the Blackboard ecosystem. I try to use the LMS as little as possible, since the tools of my trade live elsewhere on the Web.

Thanks for reading! As always, feel free to share your thoughts and suggestions in the comments.

Wednesday, July 26, 2017

Summer 2017 Course Revisions: Game Design

In case I have not mentioned it here before, I am grateful to have another internal grant to pursue an immersive learning opportunity—that's Ball State's brand of student-centered, faculty-mentored, product-oriented, community-connected learning experience. Over the next academic year, my students and I will be working with Minnetrista, which is a local museum and cultural center. In particular, we will be creating geolocative games that can be played on Minnetrista's beautiful grounds. This is a spiritual successor to last year's Spirits at Prairie Creek game (blog post here), which was my first foray into geolocative games. This year, we'll be using the spatial element along with more focused and educational narrative content. The grant allows me to teach my game design course at the Honors College, and so one of my summer tasks was to revise the course. It is offered as an honors colloquium, which means that it's only open to Honors juniors or seniors, who come from any department on campus; each Honors student has to take six credit-hours of colloquia, so it's sort of a captive audience of high-achieving students.

I have decided to make some changes to the course to try to improve the outcomes. The results can be found on the course description that I published yesterday afternoon. The overall structure will be the same, with a few weeks of theoretical foundations and exercises followed by focus on iterative production of final projects. The most obvious change is in the book selection. Many years ago, when I was using the Honors Colloquium as a team production environment, I had an achievement where students could read Koster's Theory of Fun for Game Design. This book was immensely influential on me: reading it was one of the factors that shifted my scholarship from information visualization to a focus on games and game design. Each time a student earned this achievement, I asked if they thought it was something everyone should read, and my recollection is that the answers were unanimously affirmative. A few years ago, then, I made this a central reading for the course. We spent a lot of time discussing the weighty and beautiful ideas Koster presents in his classic book. However, Koster's treatise is about why we make games, not how to make games, and given that my students generally have no background in game design—and almost all of them have precious little exposure to games beyond school sports and Monopoly—I started wondering if I was getting the cart before the horse. This year, I have designed the first several weeks around reading Schreiber's Game Design Concepts, which began life as a massive open online course in Summer 2009, before the "MOOC" acronym was popularized. It remains on the Web as, essentially, a free and high quality game design textbook. My students will be working through a rather aggressive schedule of readings and exercises as we go through the first ten levels of Schreiber's work. I hope that this will help prepare students more explicitly for game design work, familiarizing them with more of the nomenclature and processes of game design.

A related goal for the course is to increase the accountability of the learner. With any discussion-oriented class, one tends to have a mix of levels of engagement, but one maxim remains true, especially for Honors Students: if you grade it, you communicate to them the seriousness of it. I would rather have all my students engage through pure passion for the subject, but that's kind of a pipe dream: these students are pulled in so many different directions that even a passionate student needs to sacrifice their interests for more pragmatic issues. Hence, for the first time in my roughly twenty years of teaching, I am assigning participation credit. The course will only have 10–15 students, and so I hope that I can do this in a lightweight manner, with a simple sheet in my binder that I can mark as students share insight and critiques. You can be sure I'll let you know how it works out.

The course description lays out a high-fidelity schedule through October 12, at which point I expect to transition to production mode. Rather than specifying the precise final project requirements and schedule, I designed the grading scheme in such a way that the students and I can negotiate the requirements when we get closer to it. I think if the students work through all I am asking them up to that date, they will have a good sense of what they can expect from themselves moving forward.

I am excited to teach this course again, and I'm hoping for a positive mix of majors and interests. At some point I have to dig up some more icons to use for achievements, since I just dropped in a placeholder question mark yesterday. My next course redesign task might be my most ambitious one yet, though, as I have to reconsider my CS222 plans in light of moving back to a twice-per-week schedule. But first, breakfast!

Thanks for reading, and as always, feel free to share your thoughts in the comments.

Monday, July 24, 2017

Painting Imperial Assault: Twin Shadows

I found a good deal on Imperial Assault: Twin Shadows and decided it was time to get back to painting some Star Wars figures. Fantasy Flight Games announced several months ago that they would be making a cooperative app similar to Road to Legend for Imperial Assault. Knowing how the Visions of Dawn expansion (painting report 1 & 2) added quite a bit of enjoyment to my family's playing Descent (painting report 1 & 2), it seemed like Twin Shadows could be a worthwhile acquisition.

Caution: No Boba Fett contained within.
I started out with the Heavy Storm Troopers:

There are four of them, and I distinguished the elite from the regular units by the coloration of the backpacks: two in blue, two in red. I spray primed the whole set with white Krylon, which especially simplified these guys. A wash brought out the details, and a few layers of white to bring up the highlights. The gun and backpack were done in a mix of gunmetal and dark grey, with black ink wash for shading and a light touch of highlights. No real tricks, but there's something satisfying about the iconic contrast of Storm Troopers.

Next up were the Tusken Raiders:

Tusken Raiders are also called "Sand People," but I think I will call these guys "Sepia people." I mixed a few similar khaki tones for the various parts of cloth and did all the shading with a sepia ink wash. I focused the highlights on the headwraps. Adequate tabletop quality, I say. I decided to distinguish the elite units by painting the heads and spike of their gaffe sticks in bronze. If that doesn't scan well at the table, I can always go over the whole weapon that way.

Next up is Saska Teft, the engineer:

She was done in a similar straightforward style: base coat on everything, colored ink washes for the various regions, brushed on highlights. The face is not great, and though I hate to blame my tools, it wasn't until I was done that I realized I was not using my good brush. I have two brushes with similar handles, and I had accidentally grabbed the wrong one; at the time, I was disappointed that my good brush had already lost its tip, but it wasn't the right brush at all.

I used a light blue glaze for some OSL coming from the screen she's carrying. I don't do a lot of OSL, but one of the important tips I applied here—I think from one of Ghool's tutorials, though I cannot remember specifically now—was to highlight the lit areas normally first. That is, on her right side, I applied faint highlighting in the "natural" colors, as if there were a white light source on the side. Then, the glaze tinted those highlights to give them the right color. Whatever video I watched or article I read, the author was right about the error mode: some of my earlier OSL, I simply tinted the areas I wanted to look like they were glowing, but that's not really how light works. I think it's a nice effect, subtle but noticeable.

Last figure in the expansion is Biv Bodhrik, the vengeful guerrilla:

He took a bit longer than Saska Teft for a few reasons, one being that he has more different pieces and colors, another being that paint around that massive weapon was tricky. Keeping in mind that the figure was primed white, and much of his outfit is a sort of khaki, my first step was to mix some different washes to tint and shade those areas. I don't think I had tried this before, but I think I was expecting it to be more dramatic than it was; it clearly still needed significant highlighting, or for the detail-light kneepads, repainting. I decided to try some two-brush blending on some of the larger parts, so I mixed up some deeper shades for the jacket, shirt, and kneepads. Turns out for the jacket in particular, I didn't have the tone quite right, mismatched brown and green. However, after I looked at it, this really gave it a weathered look I hadn't intended. I moved forward with a bit of clean-up work but kept the tonal variation. I know I've written about the idea of doing more tonal variation before, so here's my first real result—arising from a complete accident!

I wet-blended the orange shoulderpad for what I consider a good highlight, and the two rebel insignia were freehanded. Up close one can see the imperfections, especially in the small one on the weapon, but at the table I think they look fine. Also, in case you're curious, the card art has the shoulder insignia tilted and off-center, too, and that's why I painted mine that way.

I have not painted many figures with his shade of skin tone. My painting has a reddish hue that is not found in the card art, but I had trouble matching that sort of dark-chocolate tone. It will give me something to work on.

This leads me to my other trouble, that old bugaboo that I've been fighting with for years now: photographing miniatures. In my original set of photos, I maxed out the whites in post-processing, as in my Descent heroes post, for example. However, I did this post-processing in the Google Photos app on my Nexus 5X. When I opened the Web app, the cropping was saved but not the color level changes. Also, the Storm Troopers in particular looked awkward with the whites cranked up. On a lark, I also tried shooting on black background. Here are some examples:

Neither of these were subject to any post-processing. The Storm Trooper looks pretty good here, except for a bit of a "glow" (there's probably a photography term for that). The skin tone on Biv Bodhrik is much more accurate to life than the other picture, capturing that reddish hue I mentioned. Look at Saska Teft's vest, though: the line details are gone due to the glow of the light color.

Unsatisfied with both, I took a different approach and, in the Google Photos Web app, turned the whites up to 75% on all the white-background images above. This "works," and it certainly is more predictable than my old "photograph in front of a relatively clean piece of paper" approach, but I still find myself wishing that my online logs here had more color and brightness verisimilitude with the real painted miniatures.

That's it for Twin Shadows. It's been two years since I played the core Imperial Assault campaign, so perhaps I'll try to grab some friends or teach my boys to play through the Twin Shadows mini-campaign. It has the problem that, as the Imperial player, I still don't really want the Imperial player to win: I cannot shake my enthusiasm for the Rebellion nor my DM-style rooting for the players. In the mean time, back to Fall course planning!

Thursday, July 20, 2017

Summer 2017 Course Revisions: Game Programming

I introduced the main ideas of my CS315 Game Programming course revision in my previous post. Since then, I have worked on the course design and come up with a plan that I think will work. I have posted the course description online in case anyone wants all the details; here, I want to document a few of the decisions and their rationale.

To get the students' hands dirty, I developed an assignment I've called "Flappy Whatever." The assignment specification is actually posted up on Ball State's Canvas instance. The university is conducting a pilot investigation of Canvas as an alternative to Blackboard; I am coming in on the second or third semester of the pilot, and I figured putting the assignment there would give me a chance to get to know the interface a bit. Short version: it's fine. More to the point, the assignment is for individuals or pairs to develop a minimally playable game in Unreal Engine 4 that meets the following requirements:

  • Includes firing a visible projectile in a parabolic trajectory, using UE4's physics engine
  • Include a scoring or end condition
  • Source code is posted to our class GitHub organization
  • Game title includes the word "Angry" modifying a noun
This is a riff on an assignment I gave one of the first semesters I taught CS315, where the students had a week to make a simple projectile-based demo. I fondly remember one of my students styling it as Homer Simpson throwing donuts. I've scheduled two class during which students are working on this, and I've added a requirement that students bring in questions about what they encounter. I hope that this will drive us quickly to the areas that are both important and misunderstood. We'll close up the assignment with a demo day, where students can show off what they came up with. I'll put together a demo of some kind using UE4's Paper2D system, since this will be something useful for the Collaboration Station revision, but I would be fine with students building something in 3D space for the assignment as well.

From there, I want to move rather quickly into incremental and iterative development. I will do one or two classes to introduce fundamentals of Scrum since there will be too many students for me to directly manage: I plan on using a Scrum-of-Scrums configuration, with students optionally rotating who is acting Scrum Master each iteration. I didn't put this in the course description, but I plan to grade each iteration the way I normally do for my game studio courses, with each student participating in a collective reflection and writing a personal, individual reflection. I intend on allowing students to shift between groups between iterations if they wish, and I am considering asking each team to identify its own OKRs based on the ones I wrote up before.

Careful readers may notice that I completely dropped the concept of my students making a public or private "How to learn UE4" site. As I imagined the structure and rhythm of the class, it seemed too far afield. I don't doubt that it could be interesting, but it would also necessarily distract the students from participating in the communities, forums, and wikis that are already out there. If some students express strong interest in it, I could bring it back as optional, but I don't think I'd really miss it if it were gone.

I am obligated to somehow interpret my students' project-based learning experience honestly into a grade, so I decided that the most clear and direct way to do this was to have them chase MacGuffins. Students earn MacGuffins for satisfactorily completing Angry Whatever and each project iteration that we endeavor. They can also earn a MacGuffin for completing an achievement, of which I currently have two: one is to participate in a game jam such as Ludum Dare; the other is to present at the 2017 Symposium on Games in Academia that my Serious Games Knowledge Group will be hosting in November. I will probably think of others as the Summer continues. If a student does all the expected work of the course satisfactorily and completes an achievement, they get an A. For each step down (or, equivalently, each MacGuffin they did not find), it knocks down one letter grade. This sounds fair to me: do only the in-class stuff, and you have done Very Good ("Well", natch). Skip an iteration, skip the intro assignment, or royally screw up someplace, you did Average. Anything less is Poor.

This plan leaves me with a bit of prep yet to do, such as designing the specifics of a Scrum tutorial and perhaps making some UE4 tutorial videos, but overall I think it is sound. Even if I simply left this alone until the semester started, it's enough to get everything rolling. That's good, because I think it's time for me to turn my attention to the revisions to CS222—which is moving to a Tuesday/Thursday schedule, affording some potentially significant changes—and retheming my game design colloquium around or upcoming project. More about that in later posts. Thanks for reading!

Tuesday, July 18, 2017

Background and preliminary planning for the Fall 2017 Game Programming Course

It's that time of year where I design my courses for the Fall and share my thoughts and plans on my blog. This year, however, I have been having some difficulties, and so in the spirit of reflective practice, I've decided to write about some of them instead.

In the Fall, I will be teaching Game Programming (CS315) again, the first time since 2015. Normally it would have been offered last year, but we had a teaching pinch as we were conducting three faculty searches simultaneously. Last time I taught the course, we used PlayN, which remains one of my favorite game-programming libraries. I even wrote an article in the Journal of Computing Sciences in Colleges about it. This year, however, change is afoot.

I have a grant from the Indiana Space Grant Consortium to enhance Collaboration Station, the educational game about the International Space Station that my team—Space Monkey Studio—developed in Spring 2015. You can read all about that in my post from the end of that semester. It's a small grant, but I figured I can supplement the scholarly production goals by dovetailing the project into my teaching. Hence, I will use the revision of Collaboration Station as a case study for this coming semester. I will recruit a small team to finish and publish it in the Spring, but I would like to see my CS315 students providing much of the creative production work during the Fall.

Two of the primary goals for the revision are cross-platform support and robust, cross-platform multiplayer support. When we started Collaboration Station in PlayN, I had hoped to use the cross-compilation feature to produce an iOS build; however, that was right around the time that licensing changes made that feature questionable. Additionally, the Bluetooth-based networking that we implemented on Android was not possible in iOS. During our production, we tactically dropped iOS support from our plans and successfully released the Android version, but this future work will revisit the issue.

I talked to several vendors and developers at GDC this year, and based on those conversations, I decided that Firebase could provide a perfect solution for networking, and that Unreal Engine (UE4) would provide a robust and learnable platform for development. Learnability is important: as much as I love PlayN, it was always challenging to teach with, since there are not many tutorials. The APIs are best explored by reading the source code and exploring GitHub repositories, which my students tend to have trouble with. It's a good skill to develop, of course, but it takes time! UE4 has myriad high-quality official and unofficial tutorials, videos, online courses, and assets, which means it should be easier to let students explore in their preferred mode. Also, in case you haven't seen it, UE4 contains an excellent graphical programming environment called "Blueprints". Here's an example from my UE4-based implementation of the Collaboration Station memory minigame:

The whole block is commented to describe its intention, as one would do with any source code comments. When this agent receives the "Play Grid Complete Effect" event (red, upper-left), it sets a 0.5-second timer, after which it fires—and handles—the "Delay Complete" event. After that, a new grid object (of class "BP_Grid") is spawned at the location of the previous one. After that, the old, finished grid is destroyed. Epic has put a massive amount of effort into making Blueprints easy to work with, but it's still very robust and powerful. I have heard some well-meaning evangelists claim you can use UE4 "without programming", but make no mistake: this is certainly programming! It's just visual programming rather than text-file-based programming. This gives it a much gentler syntax than C++ (which is the alternative in UE4). The Blueprints API is also completely searchable from withing the Blueprints editor itself, which means that once you learn some core terminology ("event", "actor", "pawn", "vector", etc.), you can often find what you need without having to leave the IDE.

Below is a quick, low-fidelity screencast showing the memory game in action. It starts with a short introduction, then shows the player flipping cards. After a few flips, he realizes that the "randomize" developer option was turned off and clears the board easily. This earns him a "Boost" that can be given to another player. This is one of the new gameplay features I have planned for revision, something to make the game feel more like a collaborative effort rather than disjoint individual minigames.

There has been no bridge between Firebase and UE4, however, and so I was excited to read about GameDNA's development of a Firebase Realtime Database plug-in. Unfortunately, its release has been mysteriously delayed, with no new release date announced. Before heading out for a family vacation, I developed a skeleton software architecture as demonstrated in the video above. I hoped the plug-in would be released while I was away so I could pick it up on my return, but no such luck. If it comes out in the next few weeks, I hope to be able to stub in the essential multiplayer architecture; if not, that will have to wait until after the semester starts, when it's much harder to carve out days for serious engineering efforts. My experience developing the original Collaboration Station was that the networking layer was too technically complicated for my students to handle themselves—the course does not have any networking prerequisites, and writing production code is not the time to make all the newbie mistakes.

I have had these plans swirling around my mind for some time now, but I have found it challenging to turn these ideas into a coherent course plan. As I wrote about after Ludum Dare 38, it took me months to make sense of UE4, and that's with a lot of background knowledge about programming in general and game development in particular. I am sure the path I took would not be optimal for my students, and so I am left uncertain about the pedagogic details. Very roughly, I imagine a structure like I use in all my project-oriented classes, with a few weeks of fundamentals followed by group projects. I plan to incentivise teams to develop minigames for the Collaboration Station revision, although I don't want to mandate that for fear of diminishing the motivation of teams who have another vision. I am not sure where that balance should be between the up-front instruction and the guided chaos of learning-by-doing.

The course design is complicated by the sheer scale of the class: last time I taught it, I had about 14 students, and I was able to keep track of their 4–5 teams without too much effort, but this time I have a full class of 32. Our existing lab machines don't have graphics cards that support UE4 development; the department has acquired one game development workstation and has budgeted for two more, but that's still ten students per workstation! I know that some of the students will have laptops that are capable of running UE4, but I have no way to know how many until I meet them. If only a handful have machines that can run UE4, then there's not much point in trying to use the classroom to do development work—honestly, I'm not sure what that would portend, and so I'm just hoping we hit at least the 50% mark so that pairs can work together during scheduled class time.

I know I want to grade them based on their process rather than their product, since I know first-hand that it took a lot of trial-and-error before I was able to confidently make something reasonable in UE4. A focus on process means that I can pull on my experience with Agile techniques such as Scrum. I don't think XP will work here since it's not clear to me that test-first is the best way to write experimental gameplay code, and I expect a lot of what my students will write will be shot-in-the-dark experimental code. Other concepts of Clean Code can still be applied of course, such as the importance of decomposition: hundreds of Blueprints on one screen are just as bad as any other monolothic design. (Actually, whether a visual language or a text-based language is worse for readability of badly-written code would be a great research project.)

A few days ago, I suddenly remembered reading about OKRs late last semester and thinking that they might contain something interesting for use in my Fall teaching. For those who don't know, OKR stands for "Objectives and Key Results," and it's a way of orienting an organization toward productive work. They are famously used at Google, among other places, and this Google Ventures presentation gives a comprehensive overview. One of the important features of OKRs is that they should not be used for employee evaluation—something I had forgotten until I got one or two hours into reviewing what they are and how they work. However, I was reminded of another important property of OKRs: they can be deployed at any level of the organization. I decided to try my hand at writing OKRs for Fall's Game Programming course, with an eye toward considering how articulating my objectives might help me develop appropriate student learning evaluations.

Without further ado, here are the objectives and their associated key results:
  • Produce a stable beta release of revised Collaboration Station by the end of the semester.
    • No gameplay crashes through ten routine plays
    • Released as beta on Google Play Store
    • All the sources are in the github repository
    • Include six minigames, including UE4-implementations of the original four
    • Document, in the repository, how to write and integrate new minigames
  • Implement revised multiplayer support via Firebase
    • Players can join game by keying in an ID
    • Firebase rules enforce structure
    • Include boost-generation and boost-consumption in each minigame
    • Gracefully handle, through narrative, player drop-out
  • Produce a public Web site designed to help CS majors learn UE4
    • Provide four introductory paths through available materials
    • Curate and critique ten or more UE4 videos
    • Compose two original tutorials in text, video, or multimodal
OKRs are supposed to be ambitious, perhaps even a little painful. One is not supposed to hit them all; a reasonable target is around 70%. Keep in mind that this is really my first effort at using this technique, and yet I feel like this was a useful exercise; I think these may help me articulate my expectations for my students and develop assessments, likely through an achievement-style system as I have used in CS222 for several semesters. 

The first objective is about the software production itself, and the key results are all clearly measurable. At first I didn't have the "through ten routine plays" clause, but I realized that without such a clarification, there was no bounds around the KR to keep it feasibly measurable. The second objective deals with the multiplayer aspect, with the possibly-pessimistic assumption that this is something my students and I are going to have to deal with during the semester rather than my sorting it out over the summer. That last objective is based on something I tried way back in 2010, when I was first learning Android and having my students join me in the process. We structured the whole course around a public site; I wrote a little about this back on my old wordpress blog. If my students can figure out how to learn UE4 within the context of our course, then expressing how they did this should help them crystallize their own understanding, and it will produce something of value for future students. This also could give the course a different flavor for a student who was more interested in, say, running summer camps for kids on game development rather than producing games themselves: it's a different yet valid way of knowing the domain. Then again, I could cut that last piece entirely so as not to dilute my students' focus. Clearly, I have not yet decided, but I would like to have a draft course plan complete by the end of the week. 

I believe that I have laid out all the major elements of the course. As always, I welcome your suggestions and comments. Expect a follow-up post later this month that ties some of the loose ends together.

Saturday, June 10, 2017

Painting Descent, Part 2: The Heroes

I am happy to report on the completion of my Descent: Journeys in the Dark, 2nd Edition miniature painting project—a project that spanned a few other painting projects in between! In this part, I report on the heroes, following up on my completion of the monsters back in March. For the heroes, I prioritized the painting of the three that we wanted to use as heroes first; the low priority of the rest is the main reason it took so long to finish the set.

Oblig. Box Art Photo. As per FFG/Runebound tradition, none of the pictured characters are in the box.
After trimming off mold lines, I decided to prime all the heroes using Vallejo Grey Surface Primer, applying by brush as per Ghool's video tutorial. I used two coats to get a good, clean layer of primer over the plastic. For my overall approach, I was inspired by Sorastro's painting techniques, where he generally uses a base coat, wash, and highlight. He pays great attention to detail to get a very high tabletop quality; I was more interested in getting decent results to the table quickly. That is, looking at it as a design problem, my fitness function was essentially "Is this model painted well enough that I can be proud of it when it hits the table, without spending inordinate effort?"

In Sorastro's newer videos, he has been using zenithal priming, which is a form of pre-shading. This involves priming the figure black, then laying down a layer of grey primer from about 45 degrees, and then a layer of white primer from above. This looks like a nice way to start a model, but from what I understand, it requires an airbrush, and that's an investment I have not been willing to make. One of the main reasons I have avoided thinking about this is that it would require me to clean the garage workbench to make room for a spray station. Before he got into zenithal priming, however, Sorastro mentioned a technique in his Jain Fairwood video where he primes in white and then applies a thin wash over the model. The result is similar in spirit to zenithal priming: it pre-shades the recesses. I tried this, using my homemade ink wash based on Lester Bursley's recipe, starting with Avric Albright. The result was immediately recognizable as a failure. The Vallejo Surface Primer, when brushed on, has strange hyrdophobic properties. It's a bit like painting Bones plastic, if you've ever had that experience: the paint pulls into pools on the base coat, requiring multiple layers just to achieve coverage. I asked Ghool about this online, and he confirmed that this is how it goes with brush-on, although the same product behaves differently when airbrushed on. So, what happened with the ink wash was that it beaded up rather than flowing into recesses. I don't have any photographs of what happened to the miniature because I immediately grabbed a big brush of water and cleaned the stuff off the miniature as best as I could. There were still some faint ink tide marks, but these were easily covered by the real base coat.

There was another surprise regarding this new priming technique. Based on my experience with the attempted pre-shade, I knew I had to use thicker paint than usual to get good coverage on the base coat because of the strange primer properties. I painted a few heroes and the results were fine. About halfway through is when I interrupted this set to work on some others, and I used the same priming approach except that I used only one coat instead of two. On those models, the paint behaved much more nicely, without so much beading. I am still not sure if I am seeing a property of having used two layers of primer or something else about the plastic or the environment. I returned to spray priming for my next painting project since the weather was just right for it, but hopefully I can figure out all the variables here sometime.

OK, that's all the background and context. Let's move on to the figures!
I started with Leoric of the Book, the character I intended to use for our Road to Legend tutorial campaign. I am quite happy with the results, and I think it's some of my better work. Priming in grey, instead of the black gesso I have been using, made it much easier to get bright whites on Leoric's robes and tassels. Miniature painters know that eyes are troublesome; I watched Sorastro's video for inspiration and noticed that he didn't paint the eyes at all. I decided to do the same, and I think it gives the figure a great haughty expression, with his head tilted back, as if he's looking down his nose at some measly goblin archer.

Next up is Avric Albright, the cleric. I think I did a nice job with his cloak, and the checkerboard detailing on it really helps sell it. I spent some time on the shield trying to emphasize how light reflects off of metals, but it's really too subtle to show up here; using metallic paints (TMM, True Metallic Metals), it didn't really matter as much as if I was doing it without (NMM, Non-Metallic Metals). For Avric also, I did not paint his eyes, obscured as they are behind his helmet, and I think that was fine. Longtime readers may recognize that this is uncharacteristic for me not to paint the eyes at all. It's a small thing, but it was something interesting for me to consider.

My son played Syndrael, the elf knight, for our campaign. Of these three, she was the most straightforward to paint, since she's mostly gold armor and green cloth. The hardest part was matching the tones, which for the armor was done by mixing metallic gold paint with nonmetallic yellows and beige. Once again, no eyes, but with a slightly different stories. I painted the eyes on Syndrael, and they came out kind of buggy. Putting her next to Avric and Leoric, the difference was noticeable, so I ended up painting over them with flesh colors, leaving her with a somewhat distant facial expression.

I will make a quick note about the basing here, in case I ever need to come back to my own notes and base additional Descent figures. The bases were all done with a mix of fine, medium, and coarse ballast, about 4:2:1 ratio. This was painted black and drybrushed up to medium or light brown. Flocking was done with a 50/50 blend of burnt grass and medium green fine turf. I like how the turf suggests a combination of low-growing greenery, and on top of this, I added static grass to most of the heroes. A mix of green and black tea leaves was used for the rest of the flock; these were taken from teabags, which are finely cut and contain a nice assortment of tones and shapes.
My son wasn't so happy with Syndrael, so the next one I painted was Grisbane the Thirsty, the other warrior from the base set. I am quite happy with the results here too. Like all the figures, I didn't pick the paint scheme; I just tried to match what was on the character art. Still, I think his mix of reds and browns turned out great, contrasting against the grey hair and metallic highlights. I spent more time on his face than any other, glazing on a reddish hue to his nose and cheeks.

The first of the scouts from the base set is Tomble Burrowell. His color scheme is a lot like Grisban's, with reds, browns, and bright accents. I mentioned this in my previous painting post about the Visions of Dawn expansion, but it was kind of hard to be motivated to paint the scouts. For three players, I'm inclined toward a party that includes Fighter, Healer, and Spellcaster, which leaves Rogues out of the mix as an optional fourth. Maybe once this current campaign is done we'll try a different mix; although the Road to Legend app allows for multiple campaigns at once, that does require tedious swapping of cards, a process that drained a lot of my energy for Imperial Assault back when I finished that and tried running two campaigns at once. Honestly, I don't know if these Scouts will ever hit the table if the Imperial Assault co-op app is released before our Descent campaign is finished, since I'm hopeful that it will breathe new life into IA and allow me to bring those minis back to the table.

Let me leave myself a quick note here about these photographs. These were all taken in the morning (which means without direct sunlight into my office, which has south and west windows) from my lightbox. I used the same postprocessing that I mentioned in the Visions of Dawn heroes post, namely, that I boosted the whites using the Google Photos "white" slider in their Web-based image editor. I believe that these photos are quite good representations of the actual miniature.
After finishing the Road to Legend mini-campaign, my wife and son were switching to characters from Visions of Dawn for the full campaign. I thought about keeping Leoric since I quite enjoyed him, and I was not so interested in the abilities of Master Thorn—the Mage from Visions of Dawn. Returning to the base set, I realized that Widow Tarha could be a fun character to play as a Runemaster, so I painted her up, and it's been a blast. Her re-roll ability is priceless, especially with the 1/6 chance of a miss that plagues Descent (and was cleverly shifted away to a defensive ability in Imperial Assault). I think the fiture turned out quite nice, with a lot of contrast between the colors. Perhaps I could have taken her skin highlights up higher, since it does look a bit dull compared to the rest of her. The fur headdress was painted bright white and then toned down with a series of washes. Again, in retrospect, I could have done something more elegant here by blending different base colors on the headdress and then using washes to unite the colors; I'm sure this perspective is influenced by some of Sorastro's latest videos where he uses this approach on classic Star Wars characters such as the Rancor and Jabba the Hutt.

Here is the other scout: Jain Fairwood. Despite my uncertainty about the future of these scouts, I do think that the result is good here. In retrospect, I could have probably taken the highlights on the cloak and hair even higher. I had a hard time with the part of her cloak that falls down over her back since it is rather flat. It took several layers of highlights and base color glazes to get something I deemed acceptable. The final effect is somewhat mottled, which is an artifact of having done an ad hoc mix of layering, wet blending, and feathering.

Finally, here's Ashrian, who I painted last, giving her the unenviable position of "I'm ready to be done" paint job. Her pose is quite dynamic and interesting, but the either the sculpt was sloppy or the casting was poor. She was covered in awkward, unreachable mold lines, including across the middle of her hair. I think I have mentioned before that I believe Descent can be credited with some of the growth of miniature board games and the painting hobby, leading to the massive success of Kickstarter projects like CMON's, It seemed to me like the average quality of the Visions of Dawn miniatures was much higher than the base set characters; is this a reflection of Fantasy Flight's recognition of the value of hobbyist painters, or perhaps market-driven improvements in miniature production technology? I don't know that anyone has a definitive public answer, and I know that FFG is generally very quiet about their products and production.

In any case, Ashrian turned out fine. I could have added a bit more detail, but the result is a fair interpretation. The hair on the card art is a bit more yellow than I have here. Who will ever play her, though, when we have Ispher? Still, she passes my fitness function.

Let's go journey in the dark!
I am happy with the result of this set, and they look good on the table. We have never played Descent by the classic rules, only playing with the co-op app. The game takes just slightly longer than I would like, but this is due to family constraints of trying to fit it between when the younger kids go to bed and before the oldest one does. My second son has shifted his bedtime in the last two few weeks as well, so I don't know quite what that means for our campaign.

I am glad I followed through with the idea of using the same fundamental technique for all the characters. I wasn't a zealot about it, using a bit of wet-blending or two-brush blending when it seemed appropriate. Base/wash/highlight worked well over the light grey primer. It's not clear that it saved me much time over working up from black primer except on those heroes with a lot of white showing, such as Leoric and Widow Tarha.

It's a good feeling to finish a set like this and know that I've created some interesting art that enhances my family's enjoyment of our boardgaming hobby. Thanks for reading!