Tuesday, January 26, 2016

Spring 2016 Studio: Goals and Early Design

This semester's Spring Game Studio is off to a good start. We are exploring narrative-rich games in collaboration with Connection Corner in Muncie. The first week was primarily an orientation, during which we played Buffalo, Tales of the Arabian Nights, and Two Rooms and a Boom, and I introduced the team to fundamentals of serious game design, including MDA analysis. The team also met Rebecca Parker, our contact at Connection Corner. From these discussions, the team was able to agree on the following primary goals for our work this semester:

  • Create a game that promotes cultural literacy
  • Incorporate narrative as the driving factor in gameplay
  • Include a technology component (digital or hybrid game design)
Articulating and building consensus around the goals went much easier than I expected. I asked them to reflect on the conversations of the first week and to write out all the various goals and constraints we could adopt, and to prioritize these. In a team meeting, I asked them to read out their highest-priority goals, and I put these on sticky notes and posted them to the board. Then, I left the room and asked them to sort the sticky notes. I came back after a few minutes, and they had actually completed the exercise quite well, identifying high, medium, and low priorities, and starring the three aforementioned goals as being the most important. 

Result of the team's deliberations on design goals
Our next step was to settle on fundamental game design ideas. I introduced the team to Tim Ryan's format for concept documents, which I like for several reasons. I invited the team to consider contributing in any one of the following ways before our next meeting:
  • Identify game design elements that support our shared goals
  • Write a game concept document
  • Identify and justify a context for exploring cultural literacy, such that it could be taken as the theme of our game
  • Create a poster that articulates clearly our three main goals for the project this semester
  • Bring donuts
Sadly, no one brought donuts. I dug up two concept documents from my cybersecurity education game project (which, perhaps, I still have not blogged about) and posted those as examples. I then wrote up two concept documents to frame my own thoughts about the project. Only one other student created a concept document by the imposed deadline. A lot of the discussion centered on the ideas I had brought. I felt a little self-conscious about it, as I did not want to force my designs on them, but one student even said explicitly, "I think we should just go with Dr. G's design" (which, from the conversation, I inferred to mean "because he has already done the most thinking about this and has the most experience.")

We were then able to have a focused discussion about the game's theme. Several were proposed, but again the team quickly came to consensus: we will be using monsters from different cultures as a theme for the game. We had talked about how Tales of the Arabian Nights is successful in part because it is a big game about one culture, and that it may be too ambitious to expect similar results from a shorter game about world cultures. Theming around monsters allows to ask interesting questions, such as "How does culture inform what is considered monstrous?" Our background work and discussion leads us to believe that this theme will be attractive to our target audience, which is roughly 10-12 year-olds—a challenging group to engage with narrative-heavy games, and all the more reason to pick a theme that should excite them!

The team was once again challenged to approach the game design via concept documents, and I wrote up two myself—variations on the original two, based explicitly on monsters, and incorporating some further thoughts about the design space. This time, no one else brought any concept documents, but one student explained that one of my designs already captured his ideas. This is reasonable, since my own designs, and much of our discourse, has been inspired by Tales of the Arabian Nights.

I have been using Scrum for years now, but several forces have led me to seek out alternatives. After watching Allen Holub's DevWeek Keynote on #NoEstimates, I was inspired to try story mapping. Yesterday, with our concept laid out, we tried creating a story map, but it felt rather awkward. I think the main problem was that we still did not have the game design ideas well articulated: the concept document was necessarily brief on details. I told the students that I would start a game design log to help express the game design reflected in the selected concept document. As I re-read Daniel Cook's essay on game design logs, I was reminded that the game is the primary artifact, and that all design documentation is secondary—and so one should aim for building a minimal working prototype as quickly as possible. This inspired me to take on some creative and managerial challenges today: I spent about three hours this morning laying out the core game design in a design log, and later today, I am going to revise our draft story map into one that is aimed at an aggressive schedule of building a minimum viable product. 
First attempt at a story map
Incidentally, I didn't realize until after the meeting how very confusing this was to the non-CS people in the room. The CS majors and minors have all had CS222 with me, and so they are intimately familiar with the concept of "user stories," but I fear I did not frame this well enough for the others. One of them pointed out his confusion after the fact: how could one not be confused when we're making a story-based game and also talking about the stories of users?

This post started as a simple post to Facebook, something along the lines of "I am grateful for the creative freedom I have in my job, as I spent the last three hours working on a game design specification." I did not post that, however, because that's only part of the story. Sometimes I regret not blogging more of the mundane details about my teaching experiences, since the overall result is emergent from these moment-to-moment decisions. Hence, this post, which I hope you enjoyed reading, and maybe you have something to contribute in the comments, but if nothing else, it's something that Future Me can read to remember how we got to wherever we end up.

Monday, January 18, 2016

Design questions inspired by playing Witcher 3

Last night, I finished playing Witcher 3. I enjoyed it, and I think it offers quite a bit to think about. This morning, I want to share some of the design questions that it made me consider. Many of the formal elements of Witcher 3 are staples for its genre, but as my previous post intimates, I've been thinking more about the concept of genre lately and how it's not well applied in games. My wife described Witcher 3 as "my kind of game," which is traditionally true: I love a good CRPG fantasy simulator. However, I am also approaching this as a father, playing a game whose story is fundamentally about fatherhood—aware that the game that takes an enormous amount of time and attention that could otherwise be spent on actual fatherhood.

Without further ado, then, here are some design questions that came to mind while playing Witcher 3.

What if time-sensitive tasks were actually time-sensitive? It's conventional design in CRPGs to tell the player about some important and imminent event, but then give them a functionally infinite amount of time to proceed with it. There's a monster killing everything in the swamp, your daughter is being chased by the Wild Hunt, there's a guy waiting for you at dusk by the docks... but you can faff about for days and there's no in-game impact. The reason for this is really that the rest of the systems are not tuned to time being an important part of the system.

What if crafting took time? As long as I have a diagram, any talented smith can do any number of complex operations instantaneously. That is convenient because the game preferences incremental numeric increases over story. What if that was inverted?

What if gear were not limited by level? Geralt is a mutated fighting machine, a master of swords and violence, yet more than once, I found a club that he couldn't figure out how to swing at enemies until he gained levels.

What if herb-collecting were not a drudgery? For example, what if you could mark patches of different herbs and then, like fast-travel, do a fast-collect operation? Or what if you could hire a local kid to go do it for you for a gold coin or two? Making it a manual process is like eliminating fast-travel: it just fritters away player time without contributing to other goals.

What if you felt heroic from the start? Geralt was a veteran witcher before the series even started, yet common wolves posed a serious threat at the start of the game. The idea that players and monsters have levels, and player levels escalate, is a trope of CRPG design: what if we got rid of it?

What if you had a reasonably limited inventory? I was carrying a veritable armory for most of the game. Lax realism of inventory is a prerequisite to avoid frustration when the game privileges stats and stuff-collection over story. What if that wasn't the case?

For a game with such an impressive and thoughtful story, the design actually privileges loot-hunting stat-boosting over story every time. I suspect that if you start breaking these constraints, you would very quickly fall out of the conventional Fantasy CRPG space—but really, I am tired of that game. Couldn't we have an even better Witcher experience if they allowed the story to define the gameplay experience, rather than inhibit the story by tropes of Fantasy CRPG design?

I heard a designer from Bethesda talk about the Elder Scrolls series at a conference a few years ago, and the question came up about how little design or story innovation there was across the series: each one is fundamentally the same, a child-of-prophecy story. The answer was economic: these games have enormous budgets, and there's always a new generation of 14-year-olds for whom [Daggerfall/Morrowind/Oblivion/Skyrim] is their first Fantasy CRPG epic, and so they keep the formula the same. (It helps that nostalgic older gamers will pay for the new installment and memories of that first time as well.) Witcher probably falls into this morass as well: to craft such a beautiful and engaging world takes millions of dollars, and they don't want to risk alienating an audience.

I believe that there is plenty of room for innovation in game design, but after playing Witcher 3 and Dragon Age: Inquisition in the last nine months—and never having finished Skyrim out of boredom a few years ago—I am tired of the tropes. Although I enjoyed playing Witcher 3, I feel like its story was made the worse for the conflict between the narrative and the formal systems.

Sunday, January 3, 2016

Characterizing a genre

The Spring semester starts in about a week, and with it, my most recent immersive learning project. Ball State's immersive learning program has allowed me to offer several Spring Game Development Studio experiences, but this Spring the project is a little different. The following video describes my motivation for the project:

In the video, I describe Tales of the Arabian Nights and Agents of SMERSH as "narrative-rich games," but the term is not rigorously defined—and I'm not sure it's the best choice of terms either. It was what I came up with last summer, when I originally gave that presentation at THATCamp Indiana 2015. As I began working on a formal course plan for the Spring, I realized I needed to more rigirously define this genre. This will help us to focus our efforts as well as communicate our findings.

I have identified the following necessary characteristics:
  1. Take place in a believable fictional setting. The world of Tales of the Arabian Nights may be unfamiliar to the player, but everything in it is representative of the source material, even if there are contradictions. Agents of SMERSH is similar with its cold war secret agent theme.
  2. Use narrative as the primary feedback mechanism. Raph Koster wrote about how narrative is a feedback mechanism in game design. In Tales of the Arabian Nights, player's reaction choice has two forms of feedback: first, the narrative that describes the outcome, and then any changes to the player's game state (story or destiny points, location, status, wealth level, and treasures). Tales gives the narrative first, and the state change is secondary to it.
  3. Have measurable goals. That is, there is a winning condition: this is a game after all and not just cooperative storytelling. 
  4. Incorporate endogenously meaningful ambiguous decision-making. Along with the previous point, I am borrowing from Keith Burgun's philosophy of games, and his taxonomy of interactive forms in particular. The player in these games must make decisions that are important but without total knowledge, and these decisions have an effect on the game world. To me, one of the most bizarre properties of Tales is how little agency a player really has: decisions are made on very little information, but these decisions are critical to the player's success. This leads to the next characteristic:
  5. Reward players for decision-making that reflects cultural understanding. The knowledge that a player brings to bear on decisions is not just knowledge of in-game systems. If you are playing Tales and you face an Angry Ifrit, and you don't have the Combat skill, and you choose to Fight, it is probably not going to end well. This prediction is not based on my having memorized the Book of Tales, nor knowing how many hit dice an Ifrit has. Rather, I am drawing upon my understanding of Anger, Spirits, Fighting, and probably more. I would like to add that I don't mean the game should set up "right" and "wrong" answers to problems, and there should be unexpected twists, but by and large, the story remains logically consistent—or as logically consistent as you can be when you are allowed to respond to a sudden squall with the "Drink" or "Enter" option. 
There are some characteristics which I have not yet determined to be necessary, beneficial, or merely accidental. Principle among these is whether the game needs to involve multiple players. My inspiration for this project comes from multiplayer games, but perhaps the goals of the project could also be met in a single-player experience. This is an important consideration since building digital prototypes of single-player experiences is generally much easier than supporting multiple players. A few potentially important characteristics follow from the adoption of a multiplayer requirement:
  1. Take place in an explicit, represented virtual space. In both Tales and SMERSH, the fact that the game takes place in space is critical to the gameplay. Originally, I thought this was a necessary characteristic, but consider the Choose Your Own Adventure style of single-player experience. These take place in an implicit viritual space, expressed only in text, yet a player may feel immersed in the environment without maps or tokens. If there are multiple players, an explicit virtual space makes it easier to see (and believe?) that each character is on their own journey, in a way that is unnecessary for single-player experiences. Note that text adventure games have an explicit virtual space, although it may be obfuscated through the user-interface, and we see in classical MUDs that this space was critical for maintaining a sense of space to players.
  2. Players orate narration to each other. Having players read narrative to each other is, in part, a game design trick to keep players involved while it is not their turn, but I think it has a deeper significance here. Oral storytelling is an ancient tradition, and my understanding of the literature (although it's outside my area) is that hearing stories leads to different comprehension than reading stories. Having players read the tales to each other feels practomimetic, subtly turning the players into bards and elders, changing the social and power dynamics. However, I also know of games of Tales of the Arabian Nights being ruined by having low-literacy players—players with poor vocabulary skills who read the narrative poorly or incorrectly, impeding the listeners' understanding of the story.
Taken together, I think we can agree that "narrative-rich game" is not a very expressive moniker for this genre. I am open to suggestions for a new name, and perhaps I will give this as a challenge to the team in the Spring. In any case, these are the characteristics I have identified so far, to set some boundaries around the kind of games we will be investigating in the Spring. I am looking forward to this project, although I admit I am not entirely sure how this will all play out. There are a lot of unknowns, but that's always the case with a research project. Regardless of what we find and how it turns out, I am sure the team and I will have a great learning experience, if nothing else.

Wednesday, December 30, 2015

Painting Runebound Third Edition

The second edition of Runebound was one of the earlier games I bought after starting my job at Ball State. It's a fantasy romp, with heroes trekking over a map, collecting gold, fighting monsters, and facing assorted trials. We had some good afternoons and evenings with this game before kids, and my oldest son has been able to play it with me for at least a year. There were some parts of it that were quite frustrating, however, including the facts that losing combat was devastating, allies were required but hard to come by, and healing was terribly expensive. After getting back into painting miniatures, I looked at the second edition hero figures with an eye toward painting them, but the game had become a bit stale for me. The miniatures were also on the small side and not very detailed.

Second Edition Box Art: None of those characters is actually in the game.
When I heard the announcement that there would be a new third edition, I was honestly a bit embarrassed over my giddiness. Could the designers at Fantasy Flight Games pull off a revision that keeps the good parts of the second edition but clean up the rough edges? I ordered my copy shortly after it was released, having just completed my Fury of Dracula miniatures, and I was pleased that the miniatures were much improved over the second edition's.

Third Edition Box Art: This character is also not in the game
I decided to paint the figures before playing the game, as has been my recent norm, still remembering the disappointment of painting the Legend of Drizzt miniatures (Part 1, Part 2) after already being kind of burned out on the game. I will present them here in the order they were completed. For this set, I tried to focus on increasing the contrast in my painting, particularly by increasing the level of highlights. The color schemes were all taken from the card art.



This is Corbin. There are a couple of details here that I am really happy with: the slightly brassy tint on his buckler and lower armor; the ruddy complexion; and the worn leather. This was the first figure on which I used my new Vallejo Air Metallic paints, after hearing Dr. Faust rave about how well they work off the brush. I had been using Vallejo Metallic Gold, Silver, and Gunmetal paints, so I picked up Gold, Steel, and Gun, from the Air Metallics line. Sure enough, the Steel and Gun are super smooth with fantastic flow. The gold is weird, though: it has a similar consistency, but the carrier (binder? medium? the liquid part) has a funny tint to it. Once the paint is dry, it has a good gold color, but it's kind of unpleasant to paint on because it's so far from what one would expect. This also meant it couldn't really mix well either since you cannot really tell what it would look like dry from what you have on the palette.

I put some of these pictures on Facebook, where I felt like I had to remind my non-painting friends that this little fantasy dwarf is smaller than a quarter. The pictures are much bigger than reality: looking at the real miniature, he looks better than the zoomed-in photos.

Each Runebound character has a thematic color, and Corbin's is pale green, which really only shows up on his shoulders and helmet. The grassy base helps bring it out a little bit.




Here's Laurel of Bloodwood, a vision in red and brown. I had a hard time figuring out how much to highlight the brown and red of the cloak, and I think the result is just OK. The quiver at her hip turned out nicely, all done by hand without washes. For her, and the rest of the set, I returned to my usual Gold paint. I was very nervous painting the forehead tattoo, in part because this was what I did last, several days after having done the rest of the skin. It looks OK, and it built in me some confidence for later freehand work in this set.

See the big leaves at her feet? These are from the seed pods of a white birch. I had read about how some folks use them for basing miniatures, so about a year ago, I collected many from a tree in my neighborhood, and my son and I separated out the seeds. This was the first time I actually used the on the base, together with the cork rock in order to give a sort of New England forest look.




Elder Mok is one of my favorite paint jobs. I think his drum turned out quite well, looking like warn canvas. For the ends, I freehanded the game's spirit icon. I was very nervous, but I think it turned out well, although if I could do it again, I would not have given it the same orientation on each side. The purples on the skull were fun to paint, and he has a soft OSL effect on the skull and his own eyes. I am happy with the skin tone and shading here too, all done by building up layers from a shade to highlights.

This was my first piece using my new magenta paint. I have known for a while about the difference between light primaries and pigment primaries, and I like to use complementary colors to darken and mix browns, but I've only been doing it with light primaries. Magenta paint was easy to find, but Vallejo doesn't have a color called "cyan." Some hunting in the usual places told me that their Deep Sky Blue was practically cyan, so that's what I've been using—we'll see more of it in a few figures. In some of the later figures, I did do some mixing with CMY, but I found myself sticking mostly with familiar recipes.




Lyssa's background narrative describes her as "half-katjie," which I assume is some kind of cat creature. It's a great miniature except I thought the pose was a little awkward, so I added the fallen log to the base to give more context to it.

I struggled with matching her flesh tone, and she's showing so much of it that earlier mistakes could not be overlooked. I ended up doing her skin differently than most of the others: instead of building up layers, I gave her a good base coat, then I used washes to add shades, then put the highlights on top of that.

Her tattoos represent the most intricate freehand work of the set, and certainly the most intricate freehand work that I have done. I did a bit of reading ahead of time, finding the consensus to be: always mix at least some of the flesh color into the tattoo color; and start with a very faint mix to give yourself an outline, and build up from there. As with Laurel, the tattoos were the last step and I couldn't exactly remix the flesh color, but it was close enough. I was so pleased that I hadn't ruined the miniature with the tattoos that I took it downstairs to show my wife. Showing her, I realized it was still not dark enough: they were only clear under my painting lamp. Fortunately, I hadn't cleaned up yet and the paint was still wet, so one more layer did the trick.

I think her abdominal area turned out quite nice. There's hardly any texture on the model, but the paint gives her the look of powerful abs. I could not think of anything very clever to do with her claw-like right hand, so I just left it all flesh colored. It's not shown in the card art, and I didn't want to add comical fingernails that were not sculpted into the model.

After all the varnish was dry, I decided to add some static grass. My usual application method left way too much on the base--it suddenly turned from an early brown into too much green. I tried to pull the grass out with my wet paintbrush, and as a happy accident, some was left sparsely on the base. I think it looks good, like the thin but long grass in the woods.




Lord Hawthorne is the brightest of the bunch, and here is where my new "cyan" paint really shines. It provides the base color for his robes and a great contrast to the orange of his gloves, boots, and hair. His skin was done like Lyssa's, trying to match the card art's base tone, then using washes for shades followed by manual highlights. There's a light brown underneath his armor that is clearly on the card art but almost imperceptible in the photographs. Still, I am happy I spent the time to add it. It was the first layer on the upper armor, with the steel added around it, followed by P3 Armor Wash for shade.

My only regret here is that I based all the figures on the same dark brown rubble, but this guy would probably look great if he had been done on something grey, like cobblestone or shale. The rock on the base picks up some of the grey, and the brown is reflected in his belt and satchel, so it's not all bad.




The last of the set is Master Thorn, who made me wonder, "Did the designers notice that there's a Master THORN and a Lord HawTHORNe?" Perhaps I am sensitive to it because I've been reading Bone with my two older boys, and they feature a character named "Thorn" as well.

In any case, for his skin, I went back to layering, and I'm really happy with how it looks. He's a muscular old coot, and I like the shadows that accent his figure. The card art gives him a snow white beard, but I decided to make it more grey, in part to get nicer shadows and contrast. As simple a detail as it is, I am really happy with the wooden part of the staff, and it turns out this was a sort of accident: I have a size 0 brush that I rarely use because the bristles don't all line up, but it turns out it's really useful for making lines of irregular width! It sure worked well here.

The thing at the top of his staff was not very well molded, and I probably could have spent more time adding manual shadows to make it more visually interesting, but by this point I was ready to be done. In fact, twice I thought I had finished the figure, only to realize something was missing: the first time it was the strap under his left elbow (which you cannot really see in the picture) and the second it was his head tattoo. That tattoo turned out very nicely, and on this one I was able to use another trick from my research, which was to use flesh colors to subtract from the tattoo. The initial "V" shape was much thicker, but I cut away from it with very small bits of flesh tone, and the result is much more visually interesting while also matching the card art.


And there they are, all together!

But, you ask, how's the game?


My son and I played this morning, me as Laurel of Bloodwood, him as Elder Mok. As with any first-run, there were a lot of pauses to look up rules, and there were a few things I messed up. Putting that aside, we had a great time. I really like the revised adventure system, where you can choose between combat, exploration, and social adventures. The market, healing, and defeat revisions are also greatly appreciated, as they make the game smoother, more interesting, and more fun. Laurel ended up defeating Dragon Lord Margath with one health remaining, but it really was just a learning game: I look forward to playing again now that we have a better understanding of the game system.

All of the event cards present you with an option, and several of them that we faced really made us think about the decision. The most interesting one was one I faced, where Laurel saw that bandits were going to attack a village, and so I could either (a) set a trap for them and have a small chance of succeeding, ending up with a trophy, or (b) letting the bandits raid the town, then swooping in to loot what remains, which would let me take a free item from any market. The latter was obviously much better reward, given that the Twin Daggers were in a market and looked like they were designed for my character, but I found myself really torn: do I do the evil thing and get rewards, or the "right" thing and maybe get nothing? Well, we decided that it wasn't me doing these things, it was Laurel, and she was an angry and bitter elf. I got the Daggers, and later on I killed the Dragon High Lord using them. It's a good story, and it's not the kind of thing we ever had happen in second edition.

Combat Tokens: Image from FFG
I like the token-tossing combat more than I thought I would. It was previously unfamiliar to me, but I wonder if we'll some other designers picking it up and running with it. At first, I thought it would just be a weaker version of dice, but the chips can do one thing much better than dice: unambiguously flip over. The fact that the chips show what's on their reverse side is clever and leads to some fun tactical considerations. Second edition combat was mostly an exercise in repeated dice rolling; the only real significant decision was which character would take the blow. This did lead to some very funny cases of throwing allies under the bus, but it was mostly tedious.

There's also an aesthetic to tossing the tokens that I cannot quite place, how they fall and roll in a way quite different from dice. I'm still unsure how this makes up for the fact that "rolling" them in your had is a little tricky. I am also a little worried about the chips getting dinged up, but I see FFG is selling spare sets for just $5. We have only played once, but I certainly like them better than the second edition's dice so far.

Winter break has been a great opportunity for me to catch up one some blogging and some painting, but it has also been very productive for my current research project. In fact, this afternoon I closed the last issue in the "finish before the new year" milestone on GitHub. Come to think of it, I haven't blogged about that project at all, nor Spring's upcoming immersive learning class. The next week and half will involve a lot of planning for the next semester, so perhaps I will find some time to share those stories in the coming days.

Tuesday, December 22, 2015

Painting Fury of Dracula

I had been aware of Fury of Dracula as a hard-to-find hidden movement game, and when I watched the Shut Up & Sit Down Review of Specter Ops, I was sure we'd see another printing. I have seen SU&SD reviews drive common retailers out of stock on hot games more than once, and so if Paul Dean opines about its elegance and beauty, Fantasy Flight would be fools not to reprint it.

I picked up a copy of the third edition from my FLGS, Wizard's Keep, and got to painting. The miniatures are decent but not great. With this set, I tried to be more deliberate about contrast. Regular readers may remember my work on the heroes of Shadows of Brimstone, particularly the Marshal, where I added another highlight layer after I thought I was done, and that really made the model pop.


Lord Godalming was the first out of the gate. I had some fun with his lantern, doing the OSL in a slightly different style than before. Instead of painting the whole figure normally and then trying to add the lights, I built up highlights around where the lantern shines, and then tinted and brightened at the end with a series of glazes. It worked well, and I am happier with this than my last attempt. After having played the game, I realized I could have taken the lantern light up much brighter: it looks OK in this close-up, but on the table, it doesn't register.


Next is Van Helsing, looking dapper in his spats. I'll point out how much brighter I took the highlights on his face than I normally do, an effect that I think works well on him.


Mina Harker was fairly plain in her black dress: a few layers of dark grey, and that was done. The scarf probably could have been brighter, just for more visual interest, although the faded orange matches the card art fairly well.


Here's Dracula himself, looking ... well, maybe not so good. The card art depicts him with grey, lifeless skin. I think I captured that here, like his dark purple suit. Once again, it matches the card art, but it's not much to look at. I'm unsure whether I would have been better off diverging from the card art, increasing the contrast of the highlights, brightening up the tone, or what. It's not like he's a dark menace on the game board, since figures like Mina Harker are practically as dark as he is. I'm no sculptor, but I would have gone for a more regal or powerful vampire sculpture rather than the almost comical monster-movie mouth-agape pose.


Last is Dr. John Seward, another hero in a monochromatic scheme. These gothic characters like their dark tones. The subtly different shades on his cloak, vest, and coat are nice in the picture, but on the table it's hard to tell it's there.

So far, I've only played once, and we had one critical rule backward. The heroes have turns called "day" and "night", and between these are "dawn" and "dusk." Combat happens between day and night, but several of Dracula's cards change behavior depending on whether it is night or not. That's a serious design problem, because there's already a thing called "night", and combat doesn't happen then. Does dusk count as day or night? We made a judgement call and got it backward: dawn counts as night, but dusk counts as day. Anyway, the result is that once they heroes got on my trail, it was just a matter of chasing me down and beating me up---I really had no way out, not without better combat cards. I'm eager to play again, especially with the advanced rules. For the heroes, the only difference is that they pick their starting cities, but Dracula gets a host of new powers with the Advanced rules, including several I could have used to get out of my jam earlier. (I was cornered in Eastern Europe with nowhere to go, but Wolf Form would have let me pass through a hero into Central Europe, where I would have more options.)

The figures were fun to paint despite the fairly low detail of the scultps, at least compared to other stuff I've been working on. I'm currently painting the heroes from the new Runebound edition, and so these are also boardgame-quality miniatures, but they are much nicer. It wasn't clear that painting the Fury of Dracula miniatures was worth it from an aesthetic point-of-view: they felt abstract to me, in a different way than the painted Ashardalon figures really bring the dungeon to life. Whether it's because of the game rules, or the fact I was Dracula, or the drab colors, I am not sure. Anyway, if you want to come by and play, let me know—I'd love to give it another play, but I get the sense that you really need exactly five players to get the full experience.

Monday, December 21, 2015

What we learned in CS222, Fall 2015 edition

Another semester, another "What We Learned" post!

Once again, my CS222 students made lists of what they learned in the past semester and voted on the most important items. I taught two sections, and their top items are similar; I'm listing the item as well as the vote count.

10AM Section:

  • Single Responsibility Principle (9)
  • Test-Driven Development (9)
  • Team development (6)
  • Refactoring (6)
  • GitHub (6)


Noon Section:
  • Learning from failure (13)
  • Clean Code (11)
  • Single Responsibility Principle (8)
  • Test-Driven Development (8)
  • Group programming  / team-oriented development*
* There's no vote count on this item because these two were combined after voting.

"Failure" came up as an item in the 10AM section, but it received few votes. Someone in the noon section articulated the same phenomenon as "Learning from Failure," and it got the most votes of any single item. Indeed, learning from failure came up in many final essays from both sections, and it is always a strong theme in the course.

Another interesting note about the final exam: for the first time, I heard about a student who read my blog to try to figure out what to expect on the final.

As I wrote about earlier, I introduced a few changes this semester. One of the most significant was that I replaced the overall grading scheme: previously, I took a grade as a maximum across several categories, but I switched to a model where everything contributed. I like the philosophy of the max-based grading: you're only as strong as your weakest category. However, this did cause students to lose heart when they fell behind in one category, after having spent a lot of effort on a different. This semester I used a more conventional scheme, like this:
  • Final Project (50%)
  • Final Exam (5%)
  • Assignments (25%)
  • Achievements (20%)
Those numbers are not arbitrary: I based them off of imaginary worst-case scenarios. (It may be helpful for this discussion to remember that I am using triage grading, not the arbitrary historical accident that is the 90=A, 80=B, etc..) If a student did everything perfectly except achievements, they would earn at most a B. Similarly, no assignments results in a max of B-, and no final project is D+. I didn't perceive the problem of student frustration as with the max-based system, but I still feel uneasy about this other model. I'm not sure how to combine the two models except with something more like contract-based grading. That is, I could set up a series of rules, such as capping the grade at B+ if you do no achievements, or capping the grade at D if you do not get satisfactory scores on each assignment.

The switch to GitHub went fairly well, although I am sure I can clean up a few loose ends. I plan to record a few extra instructional videos about recommended workflows as well as how to deal with merge conflicts. It was definitely less flaky than using our departmental-hosted Redmine server, and the difference between git and Mercurial was nominal for the students. I still prefer the Mercurial command line, but I am growing accustomed to git's, and I've come to really like the ease of interactive rebasing to clean project history.

Since I have been using IntelliJ IDEA Community Edition in my personal work since summer, I am seriously considering having students use this instead of Eclipse in the Spring. They barely know Eclipse coming out of the prerequisite course, so I am not too worried about cognitive load. This will make it easier for students to pick up Android Studio if they want to, and I really prefer the git integrations of IntelliJ. The only real downside is that IntelliJ's compiler warning reporting is much easier to overlook compared to Eclipse's, and it's already hard to get students to recognize that these warnings need to be addressed.

I have been using a model of assignments inspired by mastery learning: I give three assignments—one during each of the first three weeks of the semester—and students can resubmit them up to once per week until they get full marks. Again, I like the philosophy of this model, but the execution is still troublesome. The problem is not so much in the submission/resubmission policy but in the breadth of the assignments. Each has a similar form: go find some source code and apply a subset of Clean Code rules to it. I think what's happening is that stronger students already have the ability to read a difficult text, parse it out into manageable pieces, and then apply those pieces to a new context. They usually get it wrong here and there, and with some guidance, show that they have learned it. The academically weaker students struggle in many more ways, though: in addition to the inherent difficulty of the material, they also have difficulty reading complex texts, analyzing artifacts, and having a sense of focus. It has made me wonder if I should move to portfolios instead of assignments. That is, rather than proverbially throw students into the deep end to sort out Clean Code rules, what if I made a list of criteria, such as, "Refactor a variable name" and "Refactor to extract smaller methods from a long method." This could potentially help scaffold the weaker students: they would have these criteria at the time of reading Clean Code, and this could help guide their attention. When they are looking at code, they would not have to try to remember all the relevant Clean Code rules in their heads, but could instead look just for items that matched the criteria. 

I am excited about the idea of portfolios in CS222, but there is no clear best technological platform to support this. I am tempted to try to do it on GitHub using MarkDown since that would eliminate any problems with students using bad document formatting. I am leaning toward a solution like what I use for achievement submissions: make a form on Google Drive that sends data to a spreadsheet that students can see, with students submitting links to portfolio documents; record my evaluations in that sheet; use a pivot table to summarize how many "portfolio points" a student has earned. This would be completely outside of Blackboard, so I would have to copy the scores at the end of the semester, and students would have to go to the sheet to see their current tally, but I think these are fairly small costs.

I didn't do quite as much blogging this past semester as I had hoped to, but I am happy with the other work I got done. I have not made the opportunity to write about how I got involved in the Interactive Learning Space initiative, but suffice it to say that I'll be able to teach CS222 in an interesting new space in the Spring. The room has easily movable chairs and tables, multiple projection surfaces, and—really strange for my building—natural light!

That's it for this end-of-semester report. I'm still having a lot of fun with CS222, a course that is working really well despite my constant tweaking. 

Saturday, November 28, 2015

Two kinds of equality: Thinking about Java's equals method

My planning document for this coming Monday's CS222 class read something like, "Do something with equals/hashcode/toString." I took some time this morning to flesh that out into a real lesson plan, and I came across some interesting tidbits along the way. This started as a Facebook post, but I realized I wanted something more archival, so I've upgraded to the blog.

StackOverflow led me to EqualsVerifier, a recent open-source project to automate testing of the contract between equals and hashcode in Java. It looks interesting, although I have not plumbed into its documented possible false-positives. The same post led me to EqualsTester, which has been part of Guava for quite some time, although I never came across it before. I use Guava in practically every Java project, and so it looks like EqualsTester is going to have to go into my back of tricks. Writing tests for equals is kind of a drag and—in retrospect—clearly automatable, although I never really thought about automating it before, so I never looked for library support.

The most fascinating thing I came across, however, is this 2009 article by Odersky et al., which I understand to be an updated extract from Programming in Scala. The article describes four common pitfalls when writing equality-testing methods in Java, and as they point out, three of the four are covered in Bloch's classic Effective Java. That fourth one, though, hit me hard, forcing me to recognize that I had been conflating two distinct concepts in my Java programs. The first I will call content equality, which is when two objects should be considered equal because they represent the same concept in the problem domain. The second I will awkwardly call JRE equality, because it's the kind of equality that the equals method contract really specifies.

It's easy to illustrate this with an example. Ignoring all other design considerations for a moment, we can create a class like this:

public class Achievement {

    private String name;
    
    public Achievement(String name) {
        this.name=name;
    }
    
    public void setName(String name) {
        this.name=name;
    }
    
}


It might be reasonable then to expect a test like this to pass:
@Test
    public void testEquals() {
        Achievement a1 = new Achievement("Blogging");
        Achievement a2 = new Achievement("Blogging");
        assertTrue(a1.equals(a2));
    }

If you've been doing Java for a while, you know this will fail with the default equals() implementation. Let's take the same approach that most of my students tend toward: let Eclipse generate the equals and hashcode methods for us!
public class Achievement {

    private String name;
    
    public Achievement(String name) {
        this.name=name;
    }
    
    public void setName(String name) {
        this.name=name;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((name == null) ? 0 : name.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        Achievement other = (Achievement) obj;
        if (name == null) {
            if (other.name != null)
                return false;
        } else if (!name.equals(other.name))
            return false;
        return true;
    }
    
}

OK, now the test passes, so we are happy, right? Well, maybe not. What if we add this test?
@Test
    public void testCollectionsIntegration() {
        Set<Achievement> set = new HashSet<>();
        Achievement a = new Achievement("Blogging");
        set.add(a);
        a.setName("Writing");
        assertTrue(set.contains(a));
    }

This test fails, because we've hit what Odersky et al. list as Common Equality Pitfall #3: Define equals in terms of mutable fields. By changing the name of the achievement object, we alter its hash code, which means it "disappeared" from the set.

At the surface, it looks like there's no way out: you cannot make both tests pass. This makes it a beautiful error! The problem was never in the code, it's in how we think about the problem. The word "equals" is overloaded, as any student of programming languages knows, but that doesn't mean we can walk away from our fuzzy English understanding of the concept. The problem is that the seemingly innocuous unit test I introduced first assumes that Java's equals method should represent content equality, but that's not true. That is, the method is not about our tacit understanding of "equality": it's about making a complex runtime environment work in predictable ways.

It is fascinating that modern IDEs like Eclipse make it so incredibly easy to write these methods incorrectly. Indeed, the format of the equals method provided by Eclipse looks a lot like the template the Bloch himself provides in Effective Java. 

The solution suggested by Odersky et al. is simple and elegant: because there are distinct concepts for equals, have two implementations. The equals method inherited from Object will continue to do what it needs to do, and we introduce a new method to represent content equality. Following their example, we might introduce a method called equalContents, which we could test using code almost identical to our earlier misconceived test:

    @Test
    public void testEqualContent() {
        Achievement a1 = new Achievement("Blogging");
        Achievement a2 = new Achievement("Blogging");
        assertTrue(a1.equalsContent(a2));
    }

This leads to a simple implementation of our domain class:

public class Achievement {

    private String name;
    
    public Achievement(String name) {
        this.name=name;
    }
    
    public void setName(String name) {
        this.name=name;
    }
    
    public boolean equalsContent(Achievement other) {
        if (other==null) return false;
        if (other==this) return true;
        return this.name.equals(other.name);
    }
    
}

Nice and clean, without all that crufty tool-generated code to boot, and both testEqualContent and testCollectionsIntegration pass.

I know I cannot bring a cohort of sophomores with me on this adventure on Monday, so they will only be dipping their toes into it.