Lenses in game design and curriculum design

Yesterday, my game design students completed an assignment that had three optional paths. One path involved reading Richard Bartle's excellent summary of the Hero's Journey (1, 2), which includes not just an overview of the concept but also helpful pointers about what students often get wrong. During the class meeting yesterday, a student gave a masterful presentation showing how the The Last of Us maps to the Hero's Journey. Before his presentation, I gave a short lecture about what I've learned about lenses. My point here was to get out in front of issues around the masculine and feminine roles of the Hero's Journey, and I think students got my point.

One of the examples I like to give in this kind of discussion is the ludology vs. narratology wars in game design, which were dying down right around the time I joined the games scholarship community. As I understand it, scholars like Henry Jenkins applied a literary analysis lens to games and, from there, concluded that games are stories. My criticism is that if you hold up any lens, the thing you look at looks like the lens. Using the lens of literary analysis to look at games will always make them look like stories, in the same way that using a Marxist lens to analyze games makes them look like class struggle, or a systems analysis lens makes them look like systems. I made a little joke here and pointed out that we need lenses—if I take mine off, the students turn blurry—but we have to recognize their strengths and weaknesses.

Knowing that my class is mostly Computer Science students, I pointed out that Computer Science curricula still suffer from the fact that many of the discipline's founders were mathematicians. They looked at this new idea through the lens of mathematics and determined that, of course, Computer Science is basically mathematics, and that mathematics is the way to understand this thing that we called "Computer Science." Why, I asked, do we require calculus—which we almost never use in practice—and not philosophy or psychology, which we use multiple times a day?

In truth, I meant it as more of a good-natured jab, but that observation has been haunting me the last 24 hours. The lens of mathematics has undoubtedly done good things for the discipline, as lenses can often do, but it also makes the subject look like the lens. My own department is in the "natural sciences" division of the College of Sciences and Humanities, and that forces the administration to look at us from a particular lens as well.

The old joke goes like this: Ask five Computer Scientists to define "Computer Science" and you get seven different answers. I see the rise of interest in both computer science and in programming for K-12 education, but there's also infighting between the two camps. I heard at a conference the other day, "Logic is the science of Computer Science!" Meanwhile, adults who go to coding bootcamps are taking the jobs that my graduates would otherwise go for: why hire someone green and immature when you can get someone hungry for a challenge and capable of "adulting"? Why, when I try to push the old lenses out of the way, do my colleagues desperately reach out and pull it back like a comfortable blanket on a cold day?

The Fantasy Item Shop Trope

Two games I have recently been enjoying are Bargain Quest and Lord of the Rings: Journeys in Middle Earth (JiME). Juxtaposing these in a semester when I'm teaching game design got me thinking about the role of tropes in game design. In particular, I've been thinking about the ubiquity of the item shop.

Bargain Quest goes all in on the trope of the fantasy item shop. In this game, you are the proprietor of such a shop. You cleverly play your item cards to lure fantasy heroes into your shop so that you can sell them gear. Then, the heroes go off on their adventure.You earn victory points if they are successful, which raises the reputation of the shop that outfitted them. On the other hand, you also earn victory points by making them spend as much money as they can—even if you're selling them overpriced garbage. Once you've lured them to your shop, you can make them buy as much as you like. This clever spin on the item shop is infused throughout the design: Bargain Quest is entirely about the idea that you run a fantasy item shop, and this idea is executed superbly.

JiME follows in the design steps of Descent and Star Wars: Imperial Assault, all being tabletop adventure games that have app-supported cooperative campaigns. I have played both Descent and Imperial Assault, and they have a familiar rhythm: play a scenario, gain treasure, spend treasure at an item shop, repeat until victorious. This pattern is ubiquitous in CRPGs and has a strong presence in popular tabletop RPGs. The system is implied by the oldest Dungeons & Dragons rulebooks that I have seen: given that killing monsters gets you gold and items in the shop have a gold cost associated with them, then the feedback loop practically designs itself. The item shop is merely the narrative mechanism by which gold becomes power.

Bilbo, Legolas, and Gimli fighting off a hungry warg

Last night, two of my sons and I finished the fourth scenario in JiME. One of them, being familiar with both Descent and Imperial Assault, said, "I wonder when will we get to buy new items." I was the one who had read the rules, set up the game, and been responsible for understanding the basics, so I had passively noticed before that items did not have gold costs, but I had not pointed this out to my boys. When he mentioned his expectation of an item shop, I pointed out to him that there must not be one because there was no currency or costs. This got me thinking about it more critically. Why isn't there an item shop?

It is worth returning to the source material—the inspiration for the game, Lord of the Rings. Tolkien's stories of Middle Earth don't mention item shops. There must certainly have been places where Bilbo could buy a new waistcoat, but that's hardly the stuff of legend. When a character in the novels does gain an item, it's crucial to the story, whether its cram or lembas, Sting or the One Ring itself. Gaining items is an interesting part of the story; one is never so crude as to try to purchase an elven cloak. While Dungeons & Dragons drew clear inspiration from Tolkien's world, in some ways it threw away his storytelling in favor of maintaining the quantified spirit of tabletop wargaming: a mithril coat could not be part of the game without having a weight, an armor class, and a cost. That's practical and simulationist, but it's not particularly Tolkienian.

Kudos to the designers of JiME then, for eschewing the trope in favor of designing within the source material. They were not only fighting the trope but also inertia, given that the same company produced the Descent and Imperial Assault systems. I would have liked to be in the design meetings when these decisions were made. Was it more a desire to be true to the source material or a dissatisfaction with their existing systems that led to this interesting design decision?

(By the way, here are links to my painting posts for games mentioned above, in case you want to check them out: Descent 1, 2, 3, 4; Imperial Assault 1, 2, 3; JiME 1.)

Reflecting on my activities at CCSC:MW 2019

This past weekend, I attended the annual conference of the Consortium for Computing Sciences in Colleges, Midwest. I have been involved with this organization for many years, and I wanted to take a moment to share an overview of how I was involved at this conference.

Student Showcase

I am in charge of the Student Showcase. Many years ago, it was a Student Poster Competition, but it felt to me that this format gave inordinate status to the scholarship of discovery. When I took it over, I revised the format to have two tracks inspired by Boyer's Scholarship model: traditional "research" goes into the Discovery track, and interesting applications of computing goes into the Applications track. This year, we had six Applications track presentations and three Discovery track.

There are practically always Ball State students in the Showcase, and so rather than judge the event myself, I organize volunteer judges. The students are told ahead of time that they will be judged on the same six categories recommended by Glassick et al.; specifically, they are told they will be evaluated on the following:

• Clear Goals (“What is the goal of this work? What problem are you solving?”)
• Adequate Preparation (“How did you get ready to do this work?”)
• Appropriate Methods (“How did you solve your problem? Why did you approach the problem in this way?”)
• Significant Results (“What was the result of this work? Who is affected by this work?”)
• Effective Presentation (“How well does this poster or demonstration communicate what is important about this work?”)
• Reflective Critique (“What would you do differently? What does this mean for you and your career?”)

Over the years, I have fiddled with the judging form with varying degrees of success. This year, I asked each judge to rate presenters on a 1-5 scale for each presentation and each category, and there were no hitches. The scale I provided was Poor (1), Below Average (2), Satisfactory (3), Good (4), and Excellent (5). I have also put the actual judging form online, in case anyone would like to see it.

To determine the winners, I simply take the medians across the six categories and sum them. This led to a clear winner in Discovery and Application tracks as well as a clear Honorable Mention (the third highest overall score), so those are the prizes we awarded. I am proud that my own Canning Heroes team presented and won the Applications track award this year.

Tutorial: Unreal Engine 4 for Computer Scientists

Since getting into Unreal Engine 4 a few years ago, I have noticed many interesting manifestations of Computer Science concepts. I decided to run a tutorial session this year at CCSC:MW to show these to the attendees. However, it did not go as well as I had hoped. I did not have machines that could run UE4, nor could I expect attendees to have adequate laptops, so I designed the tutorial as a sort of Show and Tell. Then I was scheduled for 8:30AM on Saturday, which meant that attendees would be tired and very few students would be there. The room we were given was really awkward: it was a lab, which meant everybody was behind monitors where I could not make eye contact. To make it worse, there was no station where I could stand and work at my laptop, so I was seated and, because of HDMI cabling, facing away from the attendees. To top it all off, I was traveling with family, and my son got sick that morning at the hotel, so I was distracted and unfocused.

Suffice it to say, I would not be surprised if the session were poorly reviewed. Heck, I would poorly review it. I would like to do something like this again, but in a more controlled environment. Perhaps I will move forward with writing up an actual paper about some of the interesting manifestations, and then be able to give a shorter show-and-tell in a future year.

On a positive note, preparing for the tutorial gave me several new ideas for video tutorials. In fact, I could take my tutorial outline, chop it up, and have a pretty good series. Now, it's a matter of determining which ideas have sufficient weight to merit the time required to do the video. (For those who don't know, I have a YouTube playlist of game programming tutorial videos. In fact, I have written up this blog post while rendering my latest video in Blender.)

WIP: Mapping Game Design Learning Outcomes to CS2013

I presented in the Works-in-Progress session what I have shared here on my blog about mapping game design learning outcomes to the ACM/IEEE CS Body of Knowledge. I think it was well received. I have made the slides available online for anyone who wishes to see them, but as usual, my slides do not make a lot of sense without the stories to go with them.

I think the audience assembled for the WIP session was happy to hear my story, and they seemed to understand my frustration. I think they appreciated seeing how one becomes more critical of CS2013 as one digs deeper into the recommendations. One mentioned that his institution had given up on CS2013 and simply used instructor consensus. Ball State is really the largest school in the region that regularly participates in CCSC:MW though, and most of the attendees were in very small departments at private liberal arts schools. 

Learning objectives for introductory game design: Continuing comparison against CS2013

I am giving a presentation in the Works-In-Progress session of the upcoming CCSC:Midwest conference. This short talk is connected to my post from April about mapping learning outcomes of game design to learning outcomes of Computer Science. Conversation on Facebook led me to understand that I had not fully explained my goals in that post, in large part because I had skipped the first part of the mapping: the learning objectives of introductory game design.

As far as I know, there is no standards body or recognized formal recommendations for game design curricula as there are with Computer Science, where we have the ACM/IEEE CS2013 curriculum recommendations. However, if you look at all the various introductory texts on game design, you will find significant overlap, although these are by their nature written along the lines of content rather than objectives. Each time I have taught game design as an Honors Colloquium or a Computer Science seminar, I have had to articulate the learning outcomes of the course; what I did this morning is reflect on this process in an attempt to pull out my current thoughts about what a student should learn from an introductory course. Here is my proposal:

After taking my introductory course in game design, a successful student will be able to:

• Apply common analytical tools to existing games, examples being MDA (Hunicke), Formal vs Dramatic elements (Fullerton), and Interactive Forms (Burgun).
• Identify positive and negative feedback loops in a game.
• Critically analyze existing games in order to understand their component parts and describe their interactions, including such components as rules, theme, and narrative
• Describe, apply, and justify iterative prototyping models to produce an original game.
• Describe and apply formal techniques of playtesting.
• Compose and present status reports.

I think this is a good number and granularity of items for how I like to introduce game design. Furthermore, having taught such courses for years, I think it's a good representation of the skills that students develop.

As I reflected on this list, though, I realized that there's another layer to the learning objectives. There are objectives that are implicit—objectives that are hiding in the cracks and in the details. Here's what I came up with as the shadow objectives:

A successful student will be able to

• Read, understand, and critique book chapters, essays, and articles on game design.
• Articulate specific, measurable design goals from ambiguous constraints and inspiration.
• Incorporate feedback to improve a prototype and reflect on that process.
• Incorporate feedback to improve analytical, compositional, and creative skills and reflect on that process.

The first one here is not to be overlooked. When I look at the design and goals of introductory computer science, learning how to read does not come up at all. I believe it also to be completely absent from CS2013. However, this is a crucial skill for someone who wants to be a lifetime learner.

The second is, perhaps, the most important skill that someone can learn in this class, and its transferable to any other creative domain. By "creative domain" here, I mean any that require creativity in the technical sense—the development of new ideas—so we can include all the sciences, engineering, and education along with the arts and humanities. More specifically, it is exactly this skill I want to see strengthened for nascent software developers and computer scientists: every day we have to manage ambiguity, transforming it into measurable goals and progress. Again, however, CS2013 has very little to say about this except for a couple of hours of requirements engineering. It may simply be a case that CS2013 is too deep into the weeds, but that's kind of my point: stepping back from the weeds, managing ambiguity and turning into concrete communications is something that a computer scientist does daily, but it's also something that is often ignored in curriculum and assessement, in my experience.

The third item is a clarification of the objective to apply playtesting techniques, but as above, there is something more potent here than just playtesting: it's about closing feedback loops to improve a product. Reflecting on this led me to compose the fourth bullet point, that it's not just about the feedback loops of the game but the feedback loops of the person. Maybe you might just call this "learning", yet I think there's not enough of this going on across our campus. For example, for a course to be considered a writing intensive course here has required that a student complete at least one draft-feedback-revise cycle. In my department, there are a few places where we practice this explicitly, and all of these are places that I have touched, which would not have this otherwise.

My next step in preparing for the presentation is to take this list, look back at my earlier post, and turn again to CS2013 to make sure that my points are clear. Right now, I have a feeling like the things I want to be emphasized by CS2013 are simply not in it at all, or at least not explicitly. It will be interesting to see the reactions of the generally-conventional conference attendees.

Revisiting the state analysis of Every Extend

Back in 2007, my first Computer Science education research paper was published in the proceedings of SIGCSE. The paper provides an overview of how game programming can be used as a motivating context for learning design patterns. One of the examples in the paper, which I have used for years, is the behavior of the player-controlled bombs in the inimitable Every Extend, which can be used to explain the State Design Pattern. In the paper, I argue that the player's pawn can be described by a state machine like the following.

In yesterday's meeting with my CS315 Game Programming students, I was inspired to create a UE4 tutorial video about using state machines for state management. In particular, I wanted to show how an enumeration can be used to define the possible states, and then behavior can be switched depending on the current state. This is not, of course, the State Design Pattern, but it's a heck of a lot better than an ad hoc collection of Boolean variables. It also follows from Michael Allar's Gamemakin' UE4 Style Guide that is mandatory for my students, which says:

Do not use booleans to represent complex and/or dependent states. This makes state adding and removing complex and no longer easily readable. Use an enumeration instead.

To prepare for the video, I have spent a few hours the last two days building a simple playable framework similar to Every Extend. Over a decade ago, I did a similar exercise in Java to produce EEClone. This time, I did it in UE4. (A bit of an aside: Every Extend is like my kata for new game programming frameworks. I use the essential gameplay of it as a case study to understand how game engine functions. Of course, then, when I first started learning UE4, I tried making an Every Extend clone, but it went quite poorly. After a few years of working with UE4, it's become a lot easier to get the game up and running!)

With my gameplay framework in place, I started working on the diagram shown above to use in my series of game programming tutorial videos. However, as I looked at the diagram, I realized I had a rather fundamental problem: these are not the states of the player bomb. It's true that these are, abstractly, states of the game, but they are not the states of a single stateful object. Instead, what I had programmed was leading into the following state model:

That is, a player bomb is created, which has it play a spawning animation. When that is completed, then the player becomes vulnerable to collisions but can also press Space to explode. However, unlike in the initial analysis, there are no other states after this. If the player presses Space or is hit by an obstacle, the player's bomb is destroyed: that actor—that object—no longer exists. It is the game mode that either counts down to respawn or waits until a chain of explosions is complete and then counts down to respawn. These states are not part of the player pawn.

This observation shoots a hole in my plan to make a video using the Every Extend example. I still want to make a video about state analysis, but I need to find a better example—one where a single actor's state is interesting enough to be modeled but simple enough to fit into a tutorial video. Please feel free to share your suggestions in the comments.

Muncie DevFest 2019

I was invited to speak at DevFest Muncie 2019, an event hosted by my friend and colleague Chris Turvey, who runs the Muncie Google Developer Group. I've known about DevFest for a few years, but this was the first time I had the chance to attend. My oldest son and I went together, and it was fun to share the day with him. The morning speakers included talks about playing music over a 300-baud modem on a C128, how to design custom circuit boards, smart cities, developing experimental audio systems using Javascript and Firebase, along with my own humble contribution, a brief discussion of Kaiju Kaboom.

One of the reasons I'm writing this post is simply to share a link to my slides. Like most of my presentations, the slides will not make a whole lot of sense without the stories to support them, but I want to make them available nonetheless. The slide showing my sales got a hearty applause when I explained that there is no animation or anything—that's just the chart.

In the afternoon, my son and I joined a workshop introducing Particle products and services. It was the first time I have gotten my hands dirty with IoT technology or, really, with anything in that hardware hacker space. The integration of their technology is really amazing to me, since I understand at least the theory of how each part works. And yet, despite this, it took us over an hour to get an LED to blink on a board. As for me, I think I'll stay in softwareland, but it does seem that my son's interest was piqued. Thanks to the sponsorship of Particle, we were able to take the boards home with us, so as soon as I get them rigged up to my home Wi-Fi network, he should be able to tinker some more.

Thanks to Chris and the rest of his co-organizers, as well as the MadJax staff and the other sponsors. It was a nice day to share with developers of all experience levels from the region.

Painting Lord of the Rings Journeys in Middle Earth

My brother got me excited enough about Lord of the Rings: Journeys in Middle Earth (JiME) that I pre-ordered it not long before it was scheduled to be released. The idea at the time was that it would make a great summer painting project, and that my sons and I could get into the campaign in those quiet summer evenings. Turns out, I did not get as much painting done this summer as I hoped to. Instead, almost all my creative energy went into Kaiju Kaboom. It wasn't until today that I finally finished painting the JiME miniatures.

Box Art

Several of the techniques and color palettes that I used were taken from Sorastro's series. For most of the mob characters, I took a new approach to try to speed them up. I zenithally primed them via airbrush and then used thin paints in single coats followed by a wash to darken the recesses. This allowed me to let the zenithal highlights show through the paint. One thing I learned using this approach is that one has to be much more careful with the individual layers than I normally am with the first coat. When taking more time with each layer, it actually matters less if the first one or two run into each other, since it will be touched up. However, with this approach, a little slip of the brush can lead to a contamination of one area with the wrong color. There were some parts of the following figures where I added manual highlights and shades, but they were primarily done with single thin coats and washes.

Ruffians

Goblin Scouts

Orc Marauders

Orc Archers

Getting through all these was pretty quick. The results are certainly adequate though a bit unsaturated or washed-out looking. You can probably tell by a quick glance here that I had some fun mixing different flesh tones for both the humans and the goblins & orcs.

I painted the wargs in a similar way, just spending a bit more time on some of the highlights. I also added glowing red eyes. Now that I look at the eyes, I'm a bit ambivalent about it as a visual effect. It seems to be a common design in illustrations of the wargs. I spent a few minutes trying to determine if it was canonical or not, but it's still inconclusive.

Wargs

The wights were mostly one color, and I gave them a little more attention than the orcs and goblins, though still working rather rapidly. These were the only ones in the set where I added some weathering, namely, mud on the cloaks. I did this with drybrushing, although in retrospect, I wonder if I should have just painted it on more boldly. I still struggle with weathering. I love watching painters make figures look like they are part of their environment, but I personally feel lost somewhere between not being good at it and not wanting to risk ruining an otherwise good paint job.

Wights

You cannot actually see the weathering so well from the front, so here's a rear view.

Wight, Back

You cannot see it so much there either—hence my comment about drybrushing perhaps being the wrong path here. That said, I am pretty happy with the weathering on the sword and armor: they look old and corroded.

The last of the villains is the Big Bad of this set: the Hill Troll. I like the way it turned out. I used wet blending to get nice transitions between its two skin tones, and some purple glazes add nice color variation around the face and neck.

Hill Troll, Front

Hill Troll, Back

With the villains out of the way, I moved on to the heroes. I'll show them in the order I painted them, starting with the elves.

Legolas, Front

Legolas, Back

Elena, Front

Elena, Back

Legolas and Elena both use essentially the same palette since I figured they probably have the same tailor. For basically all the heroes, my standard approach was to use basecoat, wash, and highlight for everything but the cloaks. The cloaks were basecoated, then the shadows and highlights painted in using two-brush blending.

Given Tolkein's elven names like Legolas, Glorfindel, Elladan, and Luthien, I wonder who at FFG decided that a great name for an extended universe elf would be "Elena?" So mysterious! So otherworldly!

Berevor, Front 

Berevor, Back

I started Berevor and Aragorn at the same time, giving them the same base skin tone. I intended to do a similar palette-sharing as with Legolas and Elena. However, as I started working with Berevor, I found I was content to just buckle down and work on this one figure. I think she turned out quite nicely. Although she is not an original Tolkein character, I have a special fondness for her as she is the ranger in Middle Earth Quest, which I finished painting earlier this year. It's interesting to compare the figures to see how Fantasy Flight Games' philosophy regarding miniatures has changed to match popular demand. The MEQ figure is fine for what it is, but the JiME one is much more interesting. It also benefits from being a larger scale, about a head taller.

Aragorn, Front

Aragorn, Back

I tried to make Aragorn look a little more mature, his hair starting to grey. I think I have conceived of Aragorn as progressively older as I have gotten older. It's been over a decade (maybe two) since I've read Lord of the Rings. So many things to read and so little time. Anyway, I was partially inspired by watching Ghool's Quick Tip video on painting graying hair. I didn't follow his approach, but the video did get me thinking about trying to get that aesthetic.

I will mention here that all the heroes above have very similar earthy tones, being almost entirely greens and browns. I kept each one internally consistent so that the same colors are used, and I think this helps them look coherent without being too bland. I dressed up Aragorn a bit by painting the trim on his leather accessories in multiple colors, which may draw too much attention when rangering around Bree-land. I figure that for his sculpture, he wore his dress leathers.

Bilbo, Front

Bilbo, Back

Bilbo's red vest and gold buttons gave a much-needed reprieve from the greens and browns of his companions. I should mention that I still haven't played the game, and I find myself quite curious how their story will get Bilbo Baggins—only three feet tall!—to do any adventuring after his experiences in The Hobbit.

Gimli, Front

Gimli, Back

Dwarves. I swear, there must be some kind of curse upon them, or maybe sculptors just really don't like sculpting them. The card art for Gimli has him wearing a very reasonable chainmail jerkin with leather bracers and belt. The miniature, on the other hand, has... well, I guess it's a leather shirt over chainmail jammies, and a plate mail belt, with massive steel pauldrons and bracers. On his right arm, you can even see that the sculptor had to run the bracer and pauldron together, which just goes to show how unreasonable this would be in combat. I understand that sculpting to scale must be really hard, but look at the size of his hands! It's all very strange. Yet, I have a suspicion one my sons will be very excited to play an axe-swinging goblin-smiter, so I'll have to get used to seeing him on the table.

For the many metallic parts of this figure, I busted out my P3 Armor Wash, which really is like magic for this kind of figure. The highlights on the hair are just zenithal highlights showing through thinned paint. I thought about darkening his hair, but basically all the other heroes have such dark hair that I wanted someone besides Bilbo to have different colored locks.

I based all the figures in this set using the same technique. I prepared some rocks by cutting pieces off of a cork trivet that I saved from the trash many years ago; these pieces I painted a neutral grey and set on a corner of my painting desk. I started basing with an application of Vallejo Brown Earth basing paste, embedding some rocks into it. had ordered the basing paste after watching Sorastro's Star Wars Legion painting series. When I first applied it to one of the ruffians, I was shocked and disappointed in how red it appeared. I decided to work with it to see what I could do. After drybrushing the rocks, I mixed a wash using black and sepia inks, and this served to tone it down a bit. Then I applied flock using my usual approach: dab some glue, sprinkle some flock, wait for it to dry, repeat with a different material. After finishing my test model, I wondered what would happen if I just mixed all my flocking material together, so I did.

Mixed Flock

That container holds a mix of black tea, burnt grass fine turf, and medium green fine turf. I sprinkled this on to the other figures over dabs of thinned white glue—except for the wights, which used a less green mixture—and it saved me a bit of time and mess. After varnishing, I then added the green static grass. The results were pretty quick and look fine for a wilderness setting. At least, I think they will; I will find out for sure when we finally get the game to the table.

Here's a picture to help compare the size difference of the Hill Troll and the other characters. The Big Bad here is not as big as some of them I have painted, yet I think he's plenty big to be intimidating.

Aragorn and the Hill Troll

Finally, here are some group shots.

Fellowship of the Fanfic Prequel

A Medley of Villainy

Thanks for reading!