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!