The Bone Wars Project Retrospective

Edit: It seems many of my pictures were eaten by a grue. I'm not quite sure what happened. Maybe someday I will find them again. Sorry.

This past semester, I was the mentor for a six credit-hour immersive learning course in which my students developed an original educational video game,  The Bone Wars, based on the historic feud of 19th-century paleontologists O. C. Marsh and E. D. Cope. The team consisted of eleven students (ten undergraduate and one graduate), and like last year, we had a dedicated studio space in which to work. We were working with colleagues at The Children's Museum of Indianapolis.

I did not write much publicly about the project during the semester, and this rather lengthy post is my project retrospective. In this post, I start by giving a little background, and then I go into more details on some of the themes of the semester. These reflect concepts that arose throughout the semester, in my own reflection, in conversations, in essays, and in formal team retrospectives. My primary goal in writing this essay is to better understand the past semester so that I can design better experiences in the future. Like any team, we had successes and we had failures. I may dwell more on the failures because these are places where I may be able to do things better in the future. I will also pepper in some pictures, so that if you don't want to read the whole thing (and I don't blame you), you can at least enjoy the pictures.

The original game logo, now a banner on the team's blog.

Background

This project was internally funded by the university's initiative for immersive learning. I have led many immersive learning experiences, but the most ambitious and most successful one was undoubtedly my semester at the Virginia Ball Center for Creative Inquiry, where I worked with fourteen students for an entire semester on a dedicated project. That was in Spring 2012, and since then, I have had two "Spring Studio" courses—six-credit immersive experiences designed explicitly to bring ideas from the VBC to the main campus. I have recently received approval to offer another in Spring 2015, and hence my desire to deeply reflect on the past semester's experience.

Immersive learning, by definition, is to be "student-centered and faculty-mentored." This creates a tension in my participation: I want plans, ideas, and goals to emerge from the students with my guidance. Yet, college students generally have had very little leadership experience or real authority. Indeed, most of them have spent the last fifteen years in an educational system that minimizes agency, that is designed to produce obedient workers rather than ambitious creatives. This can result in a leadership vacuum on immersive learning projects,  which then manifests as a stressful pedagogic question, "Do I step in and fix this for them, or do I let them fail and hope they learn from it?" I mention this here because this tension will emerge as a theme in other parts of the essay. Despite having led many immersive learning projects, I still struggle with this.

The illustration from the game's loading screen subtly establishes that Marsh is brown and on the left, while Cope is blue and on the right.

Prototyping

We started the semester with a few themes from The Children's Museum. After the first week's introduction to educational game design, each of us wrote a concept document for a game, choosing from among the set of themes. The choice to go with The Bone Wars was unanimous.

Once we decided on the theme, I asked each student to choose a concept document and create a physical prototype of the game. I made one also, in part so that I could model the process. The students had the option of presenting theirs to the team as contenders for the final game, and about half chose to do so. However, none of these that were presented were actually prototypes at all: they were ideas or sketches, but they were not playable, and hence they could not be evaluated on their own merits. It seemed that, despite the team having read a few articles on rapid prototyping (including the classic How to Prototype a Game in Under 7 Days) and game design, they had not really understood what it meant—or, at least, those who presented their ideas as contenders did not understand this.

This opens up a puzzle that I have not been able to solve. Half of the team did not present their designs as contenders. Were theirs actually prototypes? Did the other half of the class understand the readings, make playable prototypes, evaluate them, and then throw them away because they were not great? I hope that this is true, because then it was simply my failure to make then show me what they had, so I could explain to them that the first prototype is always thrown away. If not, however, then maybe the whole team did not understand, from the beginning, that game design is hard.


In any case, my prototype—which was created just to show them how it could be done—was the only one that was really a prototype at all. Half of the team members wanted to do another round of open prototyping, while the other half argued for moving forward into production with my prototype. My recollection is that the people in the former group were the ones who presented non-prototypes as contenders, but this could be wrong. Many in the latter group were coming from my game programming class in the Fall, where they barely got games working in a three credit-hour experience. I think it was on the strength of their argument that the team voted to move forward with my prototype.

A prototype in the studio, task board in the back.

This ended pre-production, and moving into our first three-week sprint, the team divided into two squads: one would iterate on the paper prototype and the other would build a digital version. However, at the end of the sprint, the game was fundamentally unchanged, and the digital prototype was nowhere near playable. This was not wholly unexpected, however, as the first sprint is always a struggle. To be clear, success was possible, but failure was fine as long as the team learned from it. The team agreed that, moving into the second sprint, they would create divergent prototypes based on the original one, while a few people took a more disciplined approach to the digital version as well. However, about two weeks in, I looked a bit closer and saw trouble.

As they had in the first iteration, the team had continued to report progress and claim late night design sessions. I had been distracted by the digital prototyping team, helping with difficult software architecture issues, and so I had taken it on faith that they had made progress. However, when I finally sat down with them and asked to see what there was, it was practically nothing. There had been a little incremental refinement, but nothing near the divergent prototyping that was required. Checking the clock, I gave them a fifteen-minute design challenge: take an idea that had been discussed, modify the existing prototype with this, and have it ready to test. The educational goal behind this intervention was not to produce quality design artifacts, of course, but to have them get a feel for rapid prototyping, to understand what it means to fail fast. My intention was to work alongside them, show them how in fifteen minutes I could make something, evaluate it, and determine what to do with it. I think I had two words written on an index card when I was called away by the digital prototyping squad with a legitimate software design problem. When I returned to the other squad almost twenty minutes later and asked to see what they had, they had nothing. They had chatted about game design ideas—again—rather than making anything that could be evaluated.

Two thoughts blazed through my mind. The first was, these students simply do not understand prototyping. The second was, if we don't fix this game design, we're up a creek. I gave them the challenge to make divergent prototypes and have them ready to evaluate within the next 24 hours. I got out my trusty index cards and spent an hour designing a different set of rules around some of the same game ideas—in part, again, to model the process, but also with the thought that we could have something decent if nobody else had anything. At the next meeting, I presented my new prototype. I explained how I had taken the ideas from the first prototype, as well as the playtesting results, research notes, and team ideas, and turned these into something new. The team seemed to like it, and I had hoped this would inspire them, create a spark of understanding for their own prototypes. However, they liked my revision so much, it became "the divergent prototype," and that's basically what you see in our final product. Note that their use of "divergent" here indicates that there was still a fundamental misunderstanding of the rapid prototyping process, but at this point, I internally declared it a lost cause: there was about a semester's worth of work to do and about half a semester to do it.

The game we built over the course of the next six weeks was essentially unchanged from the prototype I whipped up on some index cards: a two-player worker-placement game. It could have used some refinement, but there was no time for it.

An interesting shot of our whiteboard, with UI design ideas sitting on top of sprint retrospective notes.

Integration

One of the most important successes of the semester was getting our artists onto the version control system. With previous teams, we had awkward manual workflows for getting art and music assets into the game. This semester, however, we were able to teach one of the artists how to use TortoiseHg to mediate the pull-update-commit-merge-push process. Now, when a request came in to clean up an asset, or if there was something he saw that needed change, he could just make it happen. There was one morning session where he and I worked together on the fossil widgets, and it was smooth as silk to have me laying down code while he was cleaning up and producing assets. As great a success as this was, I cannot help but wonder, if we had this kind of workflow earlier, could we have showcased more of the artists' work?

The artists weren't just good at drawing, they were both quite witty. Sadly, the final game only offers hints of both.

Unfortunately, the audio assets did not have the same success. The composer had something wrong with his computer that prevented us from getting a Mercurial client to work (something systemic—it wasn't the only thing broken, and I suspect he needed a complete wipe). The quality of the music is undeniable, but up until the week before we shipped, there was only one song and a handful of sound effects in the game. Right before the end the of the project, the composer worked with a programmer, and they put all of his songs into the game, about 30 minutes of music for a ten-minute game. This is the main reason the game takes so long to download: some of the pop-up dialog boxes have 3-minute soundtracks! The root problem was the failure to rapidly integrate and test. If the music had been integrated even a few days before shipping, we would have noticed the spike in project size and remixed the short-lived songs and re-record some of the inarticulate voicework. While the visual assets underwent significant change and improvement during the last six weeks of production, the audio missed this opportunity. 

Our software architecture involved model-view separation, with the model written using Test-Driven Development. TDD has been a boon to some of my other projects for dealing with the intricacies of game logic. After the first two sprints, however, we had a mess on our hands: the testing code was cumbersome, and bits of logic had been leaked into the view. After the second sprint, when we completely overhauled the core gameplay, it was an opportunity to throw away all that we had and start again—and that's what we did. The revised architecture made more prudent use of the functional-reactive paradigm via the React library, and I took the reins on the UI code, laying the groundwork for that layer.

However, the team continued to develop both the model and the view in separate, parallel layers, rather than rapidly integrating across the two. Integration was difficult and therefore not done. I paired up with some students to demonstrate a more effective model: picking a feature, then writing just enough of the model that I could add a piece to the UI—a vertical slice through the system, rather than parallel development of separate layers. I wanted this to be a major learning outcome for the students, particularly the Computer Science majors, but I doubt that most of them understood this. Even at the time, I recognized that I did a lot of the typing, when I could have stepped back and let them build an understanding by taking small steps. However, I also felt like I knew how much more work there was to be done, and they did not, and so I chose the path that built momentum toward completion.

I believe that these decisions were justified. Part of my design for the semester was inspired by research on situated learning and communities of practice, which show that apprentices learn best in a community when they are centered on the practices of master. By working with the students on some of these challenging design and development problems, I wanted to model not just a solution, but a mindset. However, I observed that the students seemed to bifurcate into two groups: a group who watched intently, asked questions, and copied what I did; and those who daydreamed, wandered away, and ended up contributing almost nothing to the project.

When a student was trying to fill up the poster, he asked what else to include. I suggested, "Game development is hard." It was meant as a joke, but it looks pretty good there.

One place where I saw a great success of integration was in the addition of cheat codes. I had explained to the team that these "cheat codes" were really tools of quality assurance, allowing testers to create specific game scenarios and verify expected behavior. This idea was bandied about for a few days without any activity, either because they didn't feel the need for it yet or they didn't know how to move forward. After I added a cheat-code-listener to manipulate a player's funds, I showed a few students how it worked. Fairly quickly, they became adept at adding new codes to test features. When it worked best, this showed how they understood how to break down a feature into vertical slices, embracing the behavior that I had modeled for them.

A final perspective on the theme of integration. One of the lessons learned from the Spring 2013 Studio was that I needed to schedule formal meeting times. Hence, this semester, everyone had to be available MWF at 9AM for stand-up meetings. This got around one of the problems from last year, where we had "the morning group" and "the afternoon group," which of course led to communication problems and trust breakdowns. Our three collocated hours a week were still not enough, and I never expected them to be. The plan was to use these hours as a seed and then find additional collocated times to meet; however, what happened was that those three hours became the only time each week that everyone was together.

I think the team set up bad habits from the first week of the semester, when we were doing reading and design exercises together. I asked them to do these in the studio, so they could talk about them, share results, compare analyses, and playtest each others' designs. However, I don't think this happened: they scattered to the winds, as if this was any other course rather than a collaborative studio. Then, when we were in production, I reminded them of the need to prioritize collocated studio time over extracurricular obligations. However, these mandates (which indeed they were, from the ground rules to which everyone agreed) were treated as casual requests. It was worse than falling on deaf ears—it was insubordination. This damaged not just the team's communication and collaboration patterns, but it also damaged my trust in them.

I hosted a few social events for the team, but there was very little participation. Some team members brought up the need for more teambuilding and social events during retrospectives, but no one else seemed to act on these ideas. As a result, I think the most significant failure was that the team itself did not integrate.

A partial wireframe for the final game UI.

Usability

The game, as delivered, is almost completely unlearnable: if you downloaded it, it would be very unlikely that you would figure out how to play, much less how to play well. What fascinates me is that the team didn't seem to recognize this. I understand that when you are close to a project, it can be difficult to step outside oneself and see it critically, as an outsider would. Perhaps I took it for granted that my students generally understood that some games had good experience design and some had bad, and how feedback in particular is a hallmark of good design.

Here is an anecdote to demonstrate this lesson. For weeks, I pointed out to the team that there was no indication of whose turn it is. The team knew the rules for whose turn it was: Marsh goes first on odd rounds, players alternate turns. However, there was literally nothing in the game to reflect this. The inaction regarding this defect started making me wonder if the team was ignoring it or if they disagreed that it was a problem. Then, I was in the studio one day when a student turned to me excitedly and told me how he was testing a feature and had to look away from his screen. When he looked back, he could not tell whose turn it was. It was just as I had said, he confirmed, and we should do something about it. When I pressed him to reflect on why it took him so long to realize that this was a problem, he responded that he was too close to the project, he wasn't in the habit of looking at it from the player's point of view.

This defect was addressed, albeit inelegantly, but the game still suffers from a woeful lack of both feedback and feedforward. Before taking actions, it's not clear what they will do; after taking actions, it's not always clear they did. This leads us to the next theme...

The "Fossil Hunter" dialog box, which I designed, is one of the most often misunderstood screens in the game.

Finishing

In our final meeting, it was clear that the students were proud of themselves for having completed a potentially shippable product. However, this had been the goal every sprint: produce a potentially shippable product that we can show to stakeholders and playtest with the target audience. Yes, the team deserved some pride for having finished one, but it's not clear to me that the team, as a whole, recognized that the game itself was essentially unfinished. The ideal situation was that they would have completed a potentially shippable product each sprint and learned to critically analyze it, and the next sprint would be spent improving it. The real situation is that they felt a bit of joy, and relief, at having completed a big-bang integration after fifteen weeks of effort.

I am sad about this because it is another educational opportunity lost. I am not confident that the students can look at the product they completed and clearly articulate where it is strong and where it is weak, or develop any kind of coherent plan for finishing it. Perhaps in another sprint, this could have been accomplished, and there's definitely at least three weeks of work that could be done polishing the game. However, that's not a sprint we have. I am hopeful that some team members recognize this, but it's only hope.

Community

For the first time, I had a team member dedicated to community outreach. This is something I had always wanted since working on immersive learning projects, but I had not previously been able to recruit one. His work resulted in the team blog as well as the Twitter handle. He also put together a series of podcasts for the blog that tell some of the history of Marsh and Cope. 

His contributions were excellent, and it gives me some ideas for how I might work with such a student in the future. It would be worth investing more effort in getting the attention of serious games networks, because this could result in both dissemination and free expert evaluation. Despite having the blog and Twitter accounts, the game was really developed behind closed doors. Indeed, much of this is due to the failure of integration, but if we got over that hurdle in a future semester, we could be much more bold in promoting the potentially shippable products themselves. Similarly, although we ostensibly worked with The Children's Museum, this didn't manifest in our outreach efforts.

This student—like many others—also pigeonholed himself into his comfort zone, but that's contrary to the values of agile software development. The team saw him as an "other," and he didn't appear at home in the studio space after the physical prototyping ended. He produced the podcasts in part because the game did not capture the historical narrative of The Bone Wars well, and so they were designed as ancillary artifacts. What if, instead, he had worked more closely with the team to explore these in still screens or animatics? As mentioned above, it was very common for students to wall themselves in by their disciplinary background, but when engaged in interdisciplinary activity, I believe it is necessary to break down these walls. I had never worked with a student with these communication production skills before, and so I think I did not recognize what his walls would look like. I am hopeful that, from his positive experience and contributions, I can continue to recruit one or two similar team members for future projects.

Our visit from Muncie Mayor Dennis Tyler was due to the efforts of our social media manager.

Accountability

In the Spring 2013 Studio, I used a student assessment model borrowed from industry: a mid-semester performance evaluation, and an end-of-semester performance evaluation. Basically, the model was, "Do honest work, and trust me to give you a fair grade." While this worked well in most cases, it was not perfect. One student had contributed almost nothing all semester, but because of the collaborative nature of the studio, I felt that I could not give him as low a grade as he deserved. If it he had been appealed, I would have had very little evidence. To guard against this, and to encourage academic reflection, I used more formal evaluations this semester. At the end of each sprint, I was to assign students participation scores (0-3 points) based on how well they kept their commitments. Each student also wrote an individual reflection essay (0-3 points). However, this system may have proved to be worse—for me, anyway.

In the pre-production sprint, I gave everybody full credit and some formative feedback because I thought that they had all kept their commitments. Now, I am not so sure. It seems to me that if the team had really read and thought about the readings assigned that first week, some of those ideas would have shown up in the rest of the semester, but they didn't—not in reflections, not in essays, not in conversations, and not in practice. I noted this in the first production sprint, and so I changed the format slightly from my assigning participation scores into a survey question: did you keep your time commitment to the project? This is where things really broke down for me. Many students claimed to have kept all their commitments, putting in their 18 hours per week of meaningful effort into the project—and I did not believe them. I think they lied to me, willingly and knowingly, to get a good grade. The survey was conducted via Blackboard, and in my responses, I said as much to them. I told them what I thought their participation was, and what grade I was recording for them... and nobody pushed back. Nobody justified their original response, nobody provided evidence. This silence has to be taken as admission of guilt.

And it didn't just happen the first sprint.

This experience left a very bad taste in my mouth. That metaphor is not quite right... it left a weight on my heart. It's hard to listen to a stand-up report, knowing that several members of the team are content to lie to you as long as they don't get caught. I don't know if these students recognized what a burden it was on me. I don't know if they have any experience, any guilt, that would indicate to them how hard it is to regain trust. I suspect not, because as far as I could tell, no one seemed to try. Some did ramp up their efforts, but only to the minimum level to which they were originally committed, and some not even that much.

This leaves me with a difficult design problem: do I return to ad hoc assessment, knowing that some people may sneak by me, or do I use more rigorous assessment, and open myself to the heartache of having students lie to me for something as inconsequential as a grade?

Incidentally, I laid some of this on the table for the students in our final meeting, which was the last day of finals week. I'm afraid I may have been a bit of a downer, but I wanted them to understand that betraying my trust was not just a professional blunder, but that it actually hurt me personally. No one really responded to this, and there weren't any more reflection essays. I wonder what they think, and I hope they learned from it. The team's risks are academic, not economic. I realize that my risks tend to be emotional.

One of our few historical event cards.

Closing Thoughts

I am faced with a conundrum: what happens to The Bone Wars next? I feel a great sense of ownership over the project: it is my design, and I wrote a large portion of the code. As it is, however, it's almost unplayable because of the lack of user experience design. It would only take a few days to polish it, and it would not require any new assets. This would make it ready for presentation at conferences and competitions, and it would make it a piece that I personally can be proud of. If I did this, however, would it still be the result of a "student-centered and faculty-mentored" experience? Does that matter, once the semester is over and credit is assigned? I am honestly not sure, but the truth is that I have already made some modifications. Version 0.4, released by the team, contained some embarrassing typographic errors, again due to a failure to integrate early. I quickly patched it and re-released it as 0.5. I also have a version 0.6 that I've been tinkering with, a bit with a student but mostly by myself. This version is already much nicer than 0.5, but I am not certain what its future is.

The team had very little interaction with our community partner. We had one meeting with them, toward the end of the semester. It was extremely useful and provided a lot of direction, but only three team members were able to attend. I had positioned myself as a liaison between the team and The Children's Museum for two reasons: first, I knew that they were dealing with serious production stress so I did not want to bother them unnecessarily; second, I have seen students flub these community relationships, and I didn't want to damage ours. I need to consider whether or not this was a mistake. The easier fix, however, would be to arrange meetings ahead of time, far enough in advance that the team feels the pressure of having something playable to show them.

I know I need to do something more intentional with the scheduling. The past two years, I have given preference to getting the best people even if we don't have the best schedule. Now, I think this was a mistake. If the best people are getting together at odd times—or not getting together at all—then their efforts will be fruitless. If I was dealing only with Computer Science majors, it would be easy, since I know and can even influence our course schedule. However, every other major added to the mix increases the complexity. The most difficult to work with are the artists, who have significant studio obligations, but they are also the most critical for the kind of games that interest me. Right now, it's still an open problem, although I certainly need to have something more formal in place for next Spring.

The game design and UI design issues are tricky ones, but again, I think the past two years point me in the right direction. I have tried to model these six-credit experiences after my 15-credit VBC experience, but even there, the students barely finished their project on time. Prefacing the production with a "crash course in game design" has not been fruitful: game design is too difficult for the students to do well with such a tight timetable. I think that next year, I will have to have the critical design elements done ahead of time. Right now, I am leaning toward doing the design myself, working with my partners at the Children's Museum, and using that as a case study in Fall's Serious Game Design colloquium and as a starter specification in the Spring. This would allow the next crop of Spring Studio students to focus more on the problems of production and, hopefully, get a better idea of what it means to make something really shippable.

In a hallway conversation with one of the students, I articulated a taxonomy that I used for personal, informal assessment of learning experience design. It looks something like this:

• What succeeded because of my designs?
• What succeeded despite my designs?
• What succeeded regardless of my designs?
• What failed because of my action or inaction?
• What failed despite my action or inaction?
• What failed regardless of my action or inaction?

I still don't have clear answers to many of these questions. The good news, however, is that this immersive learning experience was also the subject of a rigorous study by a doctoral candidate in the English department. He has been interviewing students and gathering evidence to understand the students' lived experience, focusing primarily on writing, activity theory, and genre research. I hope that the study will shed some light into the areas that were hidden from me, and that I can use this to design even better experiences.

I know that many of my Spring 2014 students had a rewarding learning experience, and I hope they carry the lessons with them for a long time. There is a subset of the team in whom I am very proud—students who learned what it meant to take initiative, to make meaningful contributions, to learn from mistakes, to recognize weaknesses, to see the value of collaboration. To those of you who read this, I hope that this essay helps you understand my perspective a bit more, and of course I welcome your comments. As I said in the introduction, the intended outcome of this essay is that I can design even better experiences in the future.

A year of achievement-oriented assessment in CS222

I conducted a formal research study as part of my experiments with achievement-oriented assessment in CS222. Although the semester is over, I have not yet opened my consent forms to determine whose data I can use in the formal study. First, I wanted to take some time to write out my informal thoughts about the past academic year.

For context, here are a few links:

• Revising Courses, Part III: Advanced Programming
• Tweaking Achievements and Reflections
• Fall and Spring course descriptions

My intention was to use the same format in the Fall and Spring, to get more consistent data for the study, but there was one piece that I felt I had to change between semesters: the tight binding of achievements and reflections. In the Fall, students' weekly writing assignments had to tie directly to their achievements. Late in the Fall, I realized  that this was an unnecessary restriction on the topic of their writing, and that what I really wanted was for them to be reflecting on any course experience, whether it was the achievements or not. The Spring reflection essays were more varied and much less formulaic. In fact, some delved into personal stories that were quite moving and inspiring. Of course, I cannot say more about that publicly, except to point out that it was the kind of moment that makes me proud to be a positive influence in a person's life.

There were still some hiccups with the reflective writing. There were three parts to each essay in the Spring—one less than Fall—but still students submitted without hitting each part. I can probably mitigate some of this by spending more time with Blackboard, copying the requirements from the course description to each assignment rather than referencing the course description. The programmer in me wants to simply reference the authoritative document, but experience has shown that students fail to check the reference.

I am also concerned about students' balance of attention between course activities. The achievements are mostly programming-related and are designed to integrate with the final projects. The best students saw this and leveraged it, but it feels like the capacity to recognize this dropped exponentially with students' effort or attention. Reflections, similarly, were supposed to tie all these experiences together, and the best students got this; many other students wrote trite, predictable, platitudinous, or probably-false reflections just as a way to earn course credit. I believe that anyone can learn from reflective writing, and I suspect many of my students did, but I also suspect that many more did not learn significantly from this activity, since they treated it as a box to be checked. This makes me wonder if the whole system of reflections should, itself, be an achievement, rather than required. More on this in a moment.

The achievement system led to students engaging in a wider variety of learning activities than I had seen before. Furthermore, much of this was self-directed: I gave criteria whereby achievements were earned, and students were responsible for finding the resources to earn them. Of course, I myself was a resource, but one could almost draw a line between high and low grades as to who recognized this. This is a common problem, not related to achievements I think, where "strong" students will talk to professors, ask questions, seek guidance, and "weak" students suffer from culturally-imposed fears that prevent this (fear of showing weakness, fear of authority figures, etc.).

All of the achievements were posted to a shared folder on Google Docs where students could see all that each other have posted. All of my evaluations were posted as comments on these shared documents. It is not clear to me the extent to which students read each others' posts and learned from them, but I know that it did happen at least sometimes. I am uncertain whether students read each others' posts for content or for form, but it seems to be a bit of each: from what I gather, ambitious students would scan others' posts and see where I left comments, and then try to avoid these pitfalls. As above, however, we see the weaker students making the same mistakes that their peers made just a few lines above them.

Several achievements dealt with what I called "production code," meaning that it had to be the students' final project code or parts of Open Source software. This definition, which seemed clear to me, caused students trouble in both semesters. Regularly, students would submit achievements that used code that did not fit this definition, sometimes the same students week after week. The confusion between current project code and old project code seems like a lack of attention to detail; however, some students confused public open source code with snippets on StackOverflow or tutorial sites. I need to clean up this definition in the future, making it clear that the point is to look at code that is part of a system, not didactic or decontextualized.

This leads to another unexpected oddity: in the final round of reflections and in the final exam, students used terms like "production code" as if they were universally meaningful, as opposed to only being meaningful in our class. I did not make it clear that this was a definition for us, and so I worry that students may go into interviews or other discussions and mistakenly express this as vocabulary. This was much worse with the achievements, in fact, many of which I tried to name in clever ways. For example, one achievement deals with Java's toString, equals, and hashCode methods, and I called the achievement, "Master of the Big Three." I didn't know what else to call it when I was writing it up, and that seemed like fun, so I called it that. However, then I overheard students talking about "The Big Three" as if that meant something in an absolute sense. Similarly, I had several achievements dealing with design patterns, and since I see patterns as a way-of-programming, I called these "Pattern Disciple" achievements. Then I heard students talking about "pattern discipline"—they didn't even get the word right, but they were still using these corny terms as if they were accepted jargon. I am not sure how to fix this aside from coming up with much drier names for the achievements, but the punster in me will likely find this impossible.

To get an 'A' in the class, students needed to earn "meta-achievements," which were coherent sets of related achievements. For example, the "Engineer" achievement required using UML and design patterns. (In retrospect, it may have made sense to call these "quests" instead, to better show the metaphor of an 'A' being at the end of the journey.) The members of one of the Spring teams did earn this achievement, although because of how I articulated the achievements, they had to incorporate the Decorator pattern where it really had no place. When I saw this, I was disheartened: what's the point of a pattern if it doesn't actually solve a problem in the domain, and would the students recognize the difference? When I expressed this doubt to the team, one of them actually defended my policies, saying that he was happy to have an excuse to study the pattern and use it, regardless of whether it "fit" the project. At least this guy saw the balance of pragmatic and academic here, and the result was positive for us both; however, I think I can circumvent this in the future by articulating quests in a way that ensures the activity is still motivated by the project context. Most students have difficulty finding the kind of intrinsic motivation that this one had!

Right at the end of the semester, I had an enlightening conversation with a student regarding the entire metaphor of achievements. I asked why he had not been more active in pursuing achievements when they were clearly tied to the course grade. His answer may have been an excuse, but it's interesting nonetheless. As a gamer, he conceptualized "achievement" as they are often treated in game design: as ancillary rewards, secondary to the primary gameplay. The discourse around the semester focused on the nine-week final project, and I can certainly see how students would see that as "the point of the course." From a game design perspective, these weren't really "achievements," then, as used in contemporary game design: they were essential, as missions or quests, waypoints or progress markers. Another student put it another way, saying that they weren't achievements at all, they were just a set of optional assignments. This is valuable feedback, and I see two ways out of this situation: re-name the achievements to reflect their essentially-mandatory nature; or actually make them optional, perhaps as gatekeepers to tiers of grades ('B' and 'A', for instance).

Achievement submissions were organized by topic, so all the "Master of the Big Three" achievements were on one page, for example. This was convenient for students to see what their peers had been working on, and what kind of feedback I had given to them. The resulting course document structure was like a wiki, then, with content organized by topic. I wonder how different the learner's experience would be if we took a portfolio approach, organizing the content by contributor. This, I think, would make it easier for individuals to see and think about what they did all semester. On the other hand, it would work against the goal of helping students see themselves as part of a community, and I suspect it would be less likely that students would look at each others' work, since one would not know whether a particular student earned a particular achievement or not. Also, it might lead to many mid-level students honing their sites on the portfolios of a small number of strong students; this would be problematic since, from my reading of the literature, students learn better from people at similar skill levels. This leads me to think that the wiki-structure approach is superior to the portfolio-structure approach, and now that it's on my blog, maybe I will remember this point as I consider what ideas to incorporate into my summer course revisions.

When I first imagined the achievement system, I envisioned the contribution of high-quality content on which I could provide meaningful, thoughtful responses. In fact, in my original design, I would not evaluate the achievement submissions at all, since each one had crisply-defined requirements, but I added a professor-review before the start of the Fall semester. In practice, there were many submissions that were not up to snuff. On one hand, this is predictable: if students will often submit assignment submissions without actually fulfilling their requirements, why wouldn't they do the same with achievement submissions? On the other hand, why would they do this? The achievements were not graded on some archaic percentage scale. There were only three grades: incorrect, acceptable, and correct-with-distinction (coded as 1, 2, and 3). The best I can figure is that students uploaded incorrect submissions because schooling culture encourages "submit and hope for points" as the dominant idiom, rather than "consider whether or not this is correct." (This is just one of many soapbox issues for me, where I point my finger squarely at... well, pretty much all the rest of formal education, which is difficulty because I have pretty small fingers. I could go on about how the dominant schooling culture discourages reflection, accountability, creativity, and deep learning while encouraging risk-averseness, but this parenthetical phrase is long enough.) I wonder, perhaps, if the numeric coding itself brought to mind students' conventional experience with points. Indeed, one student told me that he really wanted to get those '3's, even though, from a grading perspective, they were equal to '2': the only difference was one of pride. If I keep this aspect of achievements, I will try turning these into symbols, perhaps thumbs-down, thumbs-up, and ... I don't know, maybe Chuck Norris.

As a preliminary conclusion, I call the achievement-based grading system a success for this course. Students were able to focus on their nine-week projects and engage in meaningful content-oriented and reflective activity, with freedom to choose activities that aligned with their interests. At a minimum, I want to redesign some achievements to align more clearly and obviously with the projects, but I will hold off on major redesigns until I take some time to read my study data.

Summoned: A Victorian RPG in the tradition of H. P. Lovecraft

I first downloaded and installed Steam when Portal came out, and I subscribed to the Steam RSS feed shortly thereafter. It used to be a thrill, to see what the latest release was that was available on Steam. Publishers slowly moved onto the platform, and it seems it quickly became the de facto standard for PC game software. Steam promoted the Indie Revolution by making it cheap and easy for small studios to release to practically every gamer running Windows—cheap and easy compared to shipping things in boxes, anyway. We started seeing more and more frequent releases that looked, well, less and less interesting. Now, it seems that there's two or three indie games released each day that nobody cares about. I still subscribe to the RSS feed, but these days, I mostly close the release articles without reading them.

A few weeks ago, a game released that claimed to be an RPG in the style of H. P. Lovecraft. This caught my eye, and I posted on Facebook to see if anyone knew much about it. An alumnus responded that the game was decent, but fairly quickly it turned into blasting shoggoths with shotguns, or something equally ridiculous. Playing games like Elder Sign or Arkham Horror, you would get the idea that this is what "Lovecraftian" means—and indeed, pop culture may have co-opted the term for exactly that purpose. However, I read an anthology of Lovecraft's stories a few years ago, and that's not what I remember from it: I remember these stories being about the inexplicable, the infinite, and the insane. (NB: I have not played Call of Cthulhu, but I understand it to be a better vehicle for Lovecraftian themes than the others I mention.)

The semester is wrapping up here, and there was plenty to do this past weekend. Knowing it was Ludum Dare weekend, however, I dropped in Saturday morning to see what the theme was. "Beneath the surface." Well, immediately my mind turned to "Dagon," the first Lovecraft short story that I read and one of the first that Lovecraft wrote as a mature writer—a story whose themes would return in some of his famous later works as well. I could not let this opportunity pass me by, and so I created my submission to Ludum Dare 29: Summoned—a Victorian RPG in the tradition of H. P. Lovecraft. (Click here or the picture to play online.)

I have submitted a few Ludum Dare entries before, they have always been simple, action-oriented games. This was my first time creating a story-driven game, a piece of interactive fiction. It is designed to be an entertaining experience while also being a criticism of "Lovecraftian" games, and RPGs more broadly, although of course it was designed under considerable resource constraints. One of the positive effects of creating this game is that I was reminded how hard it is to write a good story. I mostly write academic pieces these days, not fiction. I'm sure the minimal story in Summoned could still be strengthened with some revision and editing, but for a weekend project in a handful of hours, I think it's passable.

The game was written using PlayN, my favorite tool for producing HTML5 games. I pulled the images from searches for Victorian-era photographs, which should all be in the public domain. The typeface is IM Fell DW Pica from Google Fonts. It took quite a bit of fruitless searching for music before I came across musopen, a site dedicated to improving access and exposure to music in part by releasing recordings for public use. The piece in the game is Prelude in G#m Opus 32 Number 12 by Sergei Rachmaninoff. I discovered the piece in this discussion thread about scary classical music. (I was going to use Piano Concerto no. 2 in Cm, Op. 18 as well, but there was a problem with the playback of the Mp3 file in Java, although it worked in the HTML build.)

Here are a few spoilers, in white text on a white background: highlight the text to view them.

Spoiler [after you have played two or three times]: It may seem that the game is always the same. Try fiddling with your character's attributes, particularly in extremes.

Bigger spoiler: The game always ends with the insanity scene. It's proper Lovecraft, after all.

GDG Muncie Slides on Serious Game Development with Java

On Friday, I gave a talk to the Muncie Google Developers' Group on the topic of serious game development with Java. It is a refinement of the talk I gave at the IndyJUG in Summer 2013. The notes from that presentation are still appropriate, and I promised I would post the slides as well, so here they are (PDF).

In retrospect, I probably could have split the presentation half, focusing on some interesting technical aspects of Morgan's Raid or Equations Squared and saving the other for another presentation. It's relatively easy to design a presentation for a group with similar experience and ability, such as an undergraduate course, compared to the variety at a public meeting such as a GDG or JUG. Something to consider, anyway. After having been giving public talks on game design recently, it was nice to give a talk on the more technical side.

Thanks to Chris, the Muncie GDG organizer, for the invitation to speak, as well as the nifty new mug. Here it is in its inaugural use, Monday morning before my 8AM class, a light roast of Papua New Guinea beans from Compulsion Coffee.

Add caption

The Validity of the CS222 Final Project

Grant Wiggins most recent blog post shares a practical test of validity for assignments. When he was asked whether a given assignment was valid, he posed two questions in response:

• Could the students do a great job on the task, but not meet the goal of the assessment?
• Could the students do a poor job on the task but still provide lots of evidence that they can otherwise meet the goal of the assessment?

If the answer to either is "yes," then the assessment is likely invalid for its goal.

This made me think about the final project in CS222. (I used to call it "the six-week project," but since expanding it to nine weeks, I have not found a catchy name for it. "The nine-week project" doesn't have the same ring to it.) Briefly, work in teams of three or four to pitch an original software development project, and this project becomes their focus for most of the semester. In theory, this project is supposed to serve as a context for students to explore course content, such as refactoring, Clean Code, design patterns, and human-centered design. These elements are emphasized in the rubric by which the three project milestones are evaluated. However, despite the rubric's being public, most of the teams inevitably miss points across all elements of the project—in all three milestones! Having the project delivered in three milestones is, in part, scaffolding: the feedback on the first two milestones is primarily formative. Could the problem be that the project is not valid for my goals?

Let's look at this semester. My course description is public, and the department's syllabus specifies the following student learning outcomes for the course:

Upon completion of this course, a student will be able to:

1. Explain and apply pair programming
2. Explain and apply test-driven development
3. Use the interactive debugger in an integrated development environment
4. Apply code review techniques to identify design and implementation defects
5. Apply principles of object-oriented design to create and analyze domain models
6. Explain and apply model-view separation
7. Apply user-centered philosophy to design simple graphical user interfaces, justify usability considerations, and implement the user-interface in a high-level programming language.
8. Plan, manage, present, and evaluate multi-week programming projects—including software feature estimation and milestone reporting—created by small teams
9. Demonstrate reflective practice for professional improvement

The final project is designed to permit students to demonstrate mastery in all of these outcomes. However, since Pair Programming is required in a two-week warm-up project, it is not mandated in the final project, and so outcome #1 can be dropped from discussion. The final project description shows the rubric for milestone presentations, and the milestone evaluation rubric—which is available to the students via Blackboard—breaks down as follows:

• Clean Code, structural principles: 6 points
• Clean Code, process principles: 6 points
• Version control: 3 points
• Project configuration: 3 points

The Clean Code principles address objectives #2, #5, and #6. I use in-class activities to enforce #3 and #4, and the milestone presentations have to address #7. Clean Code together with version control and project configuration address #8, and if students haven't hit #9 through reflective essays, they certainly encounter this in the final exam. 

With the facts established, we return to Wiggins' Socratic questions.

Could the students do a great job on the task, but not meet the goal of the assessment?

Answering this requires consideration of what "the task" is. I have discovered that teams will frequently focus only on the functional correctness of the application: given their first for-credit opportunity to make anything, they want to invest energy into making that thing work! Students seem to perceive the task to be "make this thing work," despite my explicit and repeated admonition to follow the requirements. It frustrates me that students don't perceive the relationship between the two: they don't see the "content" of CS222 as being something that can help them make their projects work, but rather as isolated knowledge. That is, their collective action belies devaluation of these ideas.

It seems that teams try to do a great job on the task they have defined, and some indeed do, but this comes at the cost of doing a poor job on the task I have defined—which, of course, is the task that is evaluated by the rubric. Hence, students cannot do a great job on the task without meeting the goal of the assessment as measured by the rubric.

Could the students do a poor job on the task but still provide lots of evidence that they can otherwise meet the goal of the assessment?

I have no existence proof that this can happen. In about three years of teaching this course, I have never had a team show me well-factored, well-designed code that did not also meet their own functional requirements. Could it happen? I suspect not. All the tools and techniques that we discuss in CS222 are included specifically because they help people make software, and teams that have used these techniques also make good software. If such a team ever encountered a case where they could not meet the self-imposed functional requirements, they could simply modify these requirements as part of a milestone presentation re-estimation.

Conclusions

This analysis shows that the project is valid for its objectives, but student actions are not aligned with the explicit goals of the project. This leads to two questions: Why do students—who are normally grade-driven—reject the framing of the project? How do I encourage them to move in more fruitful paths?

I received useful feedback through course evaluations about an earlier, structural course problem: I used to talk about requirements analysis tools while the teams were in their first iterations. Since switching to the achievements-based approach last Fall, I have been more careful to introduce CRC cards, risk matrices, and user stories before the first iteration. Now, I can lean on teams to use these tools to drive their early efforts. Unfortunately, there is still little evidence that they do: when left to their own devices, the teams devolve into undisciplined ad hoc development. That is, they use hope-driven development, a term I have coined for the process where you write a bunch of code, turn it in, and hope you get points. I have tried explaining to teams that this is foolish when the rubric is published before the assignment is even given, but somewhere, there's a breakdown.

I will note here that  I don't require one particular approach in any iteration. That is, I don't force teams to use CRC cards, risk matrices, or user stories. If they do, they earn an achievement, which helps earn a high grade in the class, but I intentionally give them the option to fail. I just wish fewer students took that option. I have considered moving back to a model where I institute formal assignments and require students to try these tools, but I would rather do something more studio-based. Take CRC cards for example: right now, we spend a day on them, each team building up CRC cards for the two-week project, and then we talk about similarities and differences among these. This is a good use of a class period, but few students ever touch the CRC cards again. We could spend another class period having each team do a CRC analysis of their final projects and share these. I won't know if this helps until I try it, and at this point, that means next Fall.

Painting Drizzt, Part 1: Technical Experiments

In this rather lengthy post, I tell the tale of how I continue to enjoy learning how to paint miniatures. Here's the TL;DR version: I painted some figures and learned a few things about painting, miniatures, and myself.

Following up on my painting the Mice and Mystics miniatures, I began painting the miniatures from The Legend of Drizzt. A student had told me he enjoyed it, and so when I saw it on a post-holiday sale last year for about 75% off MSRP, I picked it up. My oldest son and I enjoy playing this cooperative adventure game. Although the systems are relatively simple, we have had some fun emergent story, such as the time that Bruenor Battlehammer defeated a swarm of spiders by headbutting them, or when Wulfgar popped a feral troll with a killer bear hug.

The game comes with 42 unpainted plastic miniatures in a variety of shapes and sizes, and so I decided that this would be a good place to continue experimenting with painting techniques. As I mentioned in my previous painting-related post, I relied heavily on Jerry Hawthorne's Painting Guide to get through the Mice and Mystics figures. Since then, I have spent a lot of time reading and watching videos to learn more about the fundamental techniques of miniature painting. I have particularly enjoyed Dr. Faust's Painting Clinic's Web site and Basics video series as well as the articles at how-to-paint-miniatures.com. I browsed the Web for some ideas on how to approach the Drizzt figures, and I was particularly impressed by the images in a thread at WOTC; the picture at the top is nice, but it badocter's replies that I found most inspirational.

My son and I have played the game about a dozen times, and I had remembered the figures' being fairly nice. In fact, when you look at them with an eye toward painting, they cut a lot of corners... or rather, did not cut the corners. Check out Artemis Entreri's leg, for example:

This is not a significant impediment to my painting, of course, since I still very much feel that I'm learning the basics. These aren't supposed to be show-quality pieces. What is interesting about this, however, is that I didn't notice modeling shortcuts like this until I looked at them from a painter's perspective: I'm still learning how to see what's really there rather than what my brain assumes is there.

I started with the spider swarms, considering them to be the roach-equivalent figures of this game. My intention was to make them shiny, glossy red on a black field. I started by priming them in white, which turned out to be a bit of a waste of time: the first thing I had to do was to wash heavily them in black to get all the crevices to be shaded.

Next, I tried getting some red on top, using a glaze... or with drybrushing... or just glomming it on... No matter what I tried, I got grimy purple. This was humbling: my first simple figure, moving forward without a painting guide, and I couldn't even get red paint on a black spider. I took a series of pictures of the various attempts, the intention being to note which turned out best, but at this point, all I had was an album of frustration. Here is a selection:

I was pretty worn out, but I decided to put on one more coat of flat red before throwing in the towel on these spiders... and finally, I was getting somewhere. It was kind of like magic: this time, this coat, I was seeing results. A few days later, I read about how red is notoriously hard to paint, and unless it's put onto a white base coat, it takes many layers to bring it out. The more you know. Here's the final result (sans basing and varnish), which I think is decent—simple yet passable, calling out for a headbutt.

Next up were the goblins—those ubiquitous subterranean low-level minions evil, higher only than rats and kobolds on the villainous food chain. When I was painting Mice and Mystics, I pre-shaded the figures according to the painting guide, but it was hard for me to see the effect it had on the final figures. Having three identical goblin cutters, I thought it would be fun to pre-shade them differently, but then paint them the same.

For these and the next several models, my explicit goal was to practice the combination of basecoats, using washes for shades, and using drybrushing for highlights. Here are the goblin cutters with their flesh basecoat:

When I mixed this basecoat under my working lamp, I was confident that it was a good brightness. Looking at it later, I thought it might be too dark. I kept this flesh tone through all my goblins, though, so they are all a bit dark, but at least they are consistent. Also, the flat yellow highlight on top of the head really helps. The goblin cutters were the first minis on which I painted the eyes. I used the "The Easy Way" from The Painting Clinic tutorial: shading the socket, painting the whole eye black, then dropping in grey dots on either side.

At this point, I cannot tell the difference between the three minis with respect to the pre-shading. A careful reader will notice that I marked the base of the most heavily pre-shaded one. In bright natural light, I still see no difference. This doesn't mean the technique is worthless, of course—it just means it's not worth it for me to worry about at this point in my practice.

I followed the goblin cutters with the three goblin archers and the goblin champion. Here they are as part of the continued pre-shading experiment.

And here they are finished. Champion's a bit out of focus, but that's because he's coming to get you.

I was doing a lot of reading and watching video tutorials throughout the goblin-painting process, and it was around this time that I decided it would be fun to base my figures—that is, to do something with the bases besides just painting them. Indeed, one of my impediments in understanding some articles earlier was that it wasn't clear to me what "basing" was, as a verb, since it looks like a synonym for "basecoating." Also, I'm not confident that "basecoat" is a verb, but I suppose I can wordify it.

I made a trip to the downtown hobby shop and picked up some model train ballast in three sizes: coarse, medium, and fine. I got three different colors, knowing that I would be painting over them, so that I could see how they behave when mixed together. Based on some unexpected advice, I also added some ground cumin for a very fine texture. My friend Barb put it best when she said that cumin is "the only thing that smells both like a food and a locker room." My blend used even proportions of each, and I affixed it to the base using thinned white glue, dipping the figures into a small plastic container.

The next step was the paint the bases. At this point, I wouldn't be able to distinguish my different pre-shaded figures, but this was no longer important to me.

Finally, a black wash and grey drybrushing to bring out the shadows and highlights. The camera doesn't do justice to the difference between the pictures above and below: the highlights you see above are all from the light, while the ones below are painted on and, in person, much richer.

All the goblins were done in the same way, then hit with a layer of dullcote to take off the shine. Here's the happy goblin family.

The goblin champion's chainmail armor was painted using the technique described at how-to-paint-miniatures.com: black wash to get into the cracks, then successively lighter and brighter drybrushed mixes of black and silver. That was my first chainmail, and I think it turned out quite nice.

If you search long enough, you will find someone advocating for every sequential combination of base, prime, and paint. I found it awkward and stressful to do the basing last: drybrushing the rocks around the goblins' legs, using a crummy brush, I had to be very careful not to dust boots or feet. For the three hunting drakes, I primed first, then did all the basing work. The little bits of grey that landed on the drakes' legs were easily covered later in their basecoat. I followed this sequence for the rest of the figures in this post.

The texture of these drakes made them a good candidate for practicing basecoats, washing, and drybrushing. I decided to give them a yellow-green basecoat, and I used multiple layers of drybrushing on the scales. The washing proceeded in a few phases: dark green was used to emphasize the scales, while black was used on the undersides and for pin shading the spines, frill, and limb joints.

Legend of Drizzt comes with six translucent blue figures—the only like this I have ever seen. Three are hypnotic spirits and three are water elementals. I decided to copy the style from the thread I mentioned above, painting the models without priming them to keep them looking otherworldly.

It wasn't clear to me how to achieve the effect I wanted with the water elementals. The middle one was the first I painted, where I used dark blue paint on the edges, followed by light blue, followed by almost-white. It turned out OK, but the lines are a bit too chunky, too stark. On the two flanking elementals, I used drybrushing on those areas, again in successively lighter colors. This looks less stark, but the effect is almost too subtle: without a before-painting shot, it can be hard to see where I've spent any effort. In the end, I decided to leave these as-is, in part because it's such a bizarre corner case for painting.

These hypnotic spirits were done in three slightly different ways. I did the middle one first, with a purple wash followed by grey drybrush. The wash beaded up on the model; in retrospect, I realize this was a problem of surface tension, likely exacerbated by the lack of primer. I used the brush to push it around, but it still dried splotchy. It took significant, heavy drybrushing to cover or hide the splotchiness, and that figure is much darker than I would have liked. The one on the left was next, and it's a grey drybrush followed by a purple wash. It turned out much nicer, though perhaps too light. Finally, the one on the far right is the baby bear: it turned out just right. For that one, I used a wash again, but where my previous mix was about 4:1 water to Future polish—yup, floor polish—this one was closer to 1:1. It sunk into the cracks perfectly, and I was able to drybrush exactly how much I wanted to on top, rather than having to cover my tracks.

Next, I decided to tackle the drow duelists and wizard. The purple figures that came with my box were quite badly warped. I understand this to be an artifact of hasty casting, wherein releasing them from the mold too early causes shock to the plastic. The publisher was expedient and friendly in replacing the purple set, but unfortunately, the new set was also warped, although less so. They were good enough to play with, and so that is what we had been using. To paint them, however, I wanted to get them straightened out. A thread on BoardGameGeek has a good overview of the problem and potential solutions, so I moved forward with a mug of almost-boiling water and an adjacent mug of ice water. Here are the minis before intervention:

I held the bent part of each in the hot water, and sure enough, it straightens out as if by magic. Only one required a bit of manual shifting. Moving them into the ice water hardens the plastic again, yielding a much nicer result:

The duelists are wearing full-body armor, and again, I directly followed the tips at how-to-paint-miniatures.com, although I read several other articles on painting armor as well. In my first pass, I painted metallic armor all around the duelists, but upon closer inspection, the backs of their legs looked like they might be intended as leather, with the metal plates strapped to the front. I went back over the metal with near-black leather, and although this darkened the figure considerably, I decided I liked it. What good have drow of bright colors in the Underdark, after all? I got frustrated with the very small eyes on the duelists and decided to leave them without pupils. I used P3 Armor Wash on the plates, and I was happy with the results—as a random stranger at Wizard's Keep assured me I would be when I bought it.

The wizard was my first experiment in a split-complementary color scheme. My wife handed me a pocket color wheel that we had in the kids' craft area, and this was great for imagining different color combinations. I decided to do a purple robe with orange highlights and a green cloak. The green inspired me to match the wizard's cloak to the hunting drakes—my drow are eco-friendly and use all the parts of their animals. I was quite happy with the result, until I posted this picture on Facebook and an alumnus commented on the wizard's "bubble-gum wand."

Aw nuts, it does look like bubble gum. I have been mixing purple without trouble, but I find orange very difficult to concoct. I ordered a bottle of each secondary color since then, in hopes that I can save some time and get more consistent hues. I went back to the wizard and re-painted his wand, taking the opportunity to brighten up the talismans on his chest as well. The wand is a bit out of focus in the picture: only the tip is pure white, with the rest blending yellow.

The keen reader will notice that I followed an orthodox description of the drow, giving them jet black skin. This experience helped me to understand why D&D artists have interpreted them as greys or browns instead. Once you have black, you cannot go down from there: there's just no shading jet black.

I did Dinin about the same time, and he is also very black. There's grey drybrushing on his back, and the armor offers some metallic shine, but he's mostly dark grey. Way deep down, he has white primer, which was tedious to cover entirely in black—black primer would have been appropriate here for sure. If I could do it again, I would brighten up the whole model a little, but I'm satisfied with the result here. There is a purple spider emblazoned on his chest that, in retrospect, perhaps I should have given another coat, since it gets lost with low contrast.

At this point, I decided I wanted to move on to one more new technique: layering. From the videos I watched and tutorials I read, my favorite was a somewhat lengthy one from Dr. Faust's Painting Clinic. He starts with a black-primed figure and builds it up, layer upon layer. Others, such as BrushThralls, recommend starting with a basecoat and adding shade and highlights, but I decided to try Dr. Faust's method. How can you not listen to a guy who uses the MST3K Love Theme to introduce his videos?

I started with Jarlaxle, a figure we have only used once. I know very little of the Forgotten Realms fiction, and so I assumed he would be wearing dark colors, as the other drow. Reading up on the character, it seems that he favors the flashy and gaudy, which made this a good opportunity to get away from all that black. His blue shirt is the first layering I did, using two shades, a basecoat of flat blue, and two highlights. I was a bit perplexed by some of the ruffles and creases in his right arm, but I think it turned out well for a first timer.

Next, I painted the cape yellow, starting at light brown and going up to near-white, and after this, the green pants. The metal bits were done using the same technique as the drow duelists: black-silver base, silver highlight, and a touch of armor wash.

His belt, boots, bracers, eyepatch, and hat were done in leather brown. I thought the red sash, purple feather, and brass hilts add a nice visual flourish. I used a little pin shading to highlight the shadows in the sabre's basket hilt. Here's the finished model, front and back. The shadows on the back of the cloak could probably be brought out more, as it looks a bit washed out. Still, I'm rather proud of it.

Right after doing Jarlaxle's shirt, I did Yvonnel Baenre's skirt. This makes it my second layering project, and my work on these two figures continued in an interleaved fashion.

At first, I was quite happy with this, but then I read a commentary on contrast: how the details on tabletop minis need to stand out from a few feet away, not just up close. Despite the nice layering on the skirt, it wasn't as crisp as I wanted—not enough contrast. I used a black wash in the creases to darken the shadows, and the result was a bit tighter. Here's the finished version.

The purple spider on her armor has more pop than the drider's, although still a bit low contrast. The hair was layered in very light grey. I was afraid to use too much contrast here, for fear of taking away the starkness of the white against the dark armor and skirt. I contemplated mixing in a little blue or purple for a "cool white" feel, but I was unwilling to take such a risk after spending so long on the rest of her.

As I was finishing these two, I continued practicing layering with a figure that has never hit the table: Methil El-Viddenvelp. I envisioned a triadic color scheme of purple-grey flesh, orange robe, brown cape, and blue robe, and I started with the robe. I built it up from dark blue, meticulously painting each little square on the front panel. As I started putting on a light blue highlight, I panicked: it looked much too bright! I gritted my teeth and continued painting, but when I was done, I was convinced I had wrecked it.

It wasn't until the next day that I realized the real problem: I am afraid of bright colors. When I showed the figure to my wife, her first reaction was, "It's all one color," which I interpret as a complement to the layering. She looked more critically as I explained that I had been worried about the brightness of the highlight, and she asserted it could have even been brighter. I think she was right, and this was an important realization for me.

Although I had spent significant effort layering each of the squares on the front panel, I ended up repainting that portion in metallics. Working the layers of tan onto the cloak took a long time, and I am quite happy with the result. The cloak's stitching is done in two layers of brown, only highlighted in those areas where the cloak itself is highlighted. The skin was the penultimate step, but after my first pass, I didn't like it: I had imagined a purple-grey, but what I ended up with was too close to the robe's color—not enough contrast.

The highlights on the head and hands help give the illusion of wetness, but I figured if I did it once, I could do it again. I mixed the shade of grey I wanted, then tinted that with purple, and the result was just what I wanted. I used the usual armor wash on the plates of his upper body, and a localized black wash accented the junctions of the hands and robe, cloak and robe, and head and cloak; the rest was done exclusively with layering. Here is the final result.

As I moved into my layering project, I switched from using a small ceramic tile as a palette to a 10-well plastic palette, and this keeps my paint wet and in one place. This was extremely useful when layering, as I was able to keep my desired basecoat wet while I mixed shades and highlights. I started using some slightly nicer brushes, which do perform better, as well as brush-on acrylic primer, which does not stink. Also, I will share a picture of the cup I use for water, because it is inspirational.

That's it for this installment of my painting stories. These figures provided an excellent opportunity for me to try some different techniques, work on my technical chops, and explore new color schemes. I imagine I will post again when the rest of the set is done, though likely with less detail as I spend more time on refinement and less on discovery. Still, it's fun to share some pictures here and reflect on what I learned through the process, so time will tell. Here's a sneak preview: the battle of the primer colors!

Thanks for reading!

[[Jump to Part 2]]