Saturday, December 8, 2018

Reflecting with the Fall 2018 Human-Computer Interaction Class

The truth is that I had been a bit down on my HCI class. I set up what I thought would be a wonderfully inspirational cooperation with the David Owsley Museum of Art, and I gave them the challenge of prototyping real solutions to some of DOMA's problems. As with my Spring 2018 HCI class, I wanted these solutions to be firmly grounded both in human-centered research methods and in the general design theories we studied in the first half of the semester by reading Don Norman's The Design of Everyday Things. However, as we moved through the stages of the project, I was not seeing teams doing either of these. In the first iteration reports that they submitted before Thanksgiving, it was obvious that their designs were not really rooted in their research, nor were their designs intentionally applying the principles we discussed. This left a heaviness in my heart, both because I doubted the efficacy of the class and because we were going to be showing our results to DOMA at the end of the semester.

Our primary contact at DOMA was their Director of Education, Tania Said, who has been a gracious and kind partner in this endeavor. Due to the schedule of docent training, we scheduled our final presentations for Tuesday of last week, which was the penultimate day of class. I was impressed by how well my students presented their work and the effort they had put into revisions in the 1.5 weeks since Thanksgiving. It helped that Ms. Said has a grace and wisdom that made her questions uplifting to the students: her questions were fair and honest, yet always supportive and encouraging.

I think we would all call this meeting a success, yet there was one more meeting yet in the semester—Thursday, December 6, which was also the deadline for their projects. I had originally planned to have them present their final projects to each other, but this clearly would have been redundant after the meeting on Tuesday. I decided that my goal for the meeting would be to try to wrap up some of the loose ends, to share with them some of my joys and frustrations from the semester, and to prime their reflections to prepare for the final exam. To this end, I decided to present them with three questions and an activity: What went well this semester? What did not go well this semester? What still puzzles you? The activity would be to write final exam questions.

We pushed all the tables against the walls so we could sit in something like a circle, doing the best that the room permits. I opened the class with a few remarks about my perspectives, and I got them into groups of three or four students to answer the first question. Here is a transcription of the notes from the board after we openly shared our results, slightly expanded from my blackboard shorthand:

  • Project pride & satisfaction
  • Presentation to Tania Said
  • Getting class feedback
    • Using the Click-Share system from our seats promotes discussion 
  • Second round of paper prototyping helped clarify the difference between sketch and prototype
  • Museum visits
  • Connecting with a real place / real partner
  • Two-week warm-up project provided a trial run before working with the real partner
  • Relationship between design principles and Clean Code
  • Reading Design of Everyday Things
It gave me satisfaction to see them bring up many of the items that I too thought were our greatest successes of the semester. Of course, we didn't vote or rank these, so some may only be important to one or two students, but that's fine for our purposes. One of the biggest surprises came from the comment about the second round of prototyping. This was a particular exercise where everyone dropped the ball, so we agreed to reschedule literally the rest of the semester so that they could do this homework exercise again. At least the student who spoke up, this gave her the opportunity to really understand it, which is infinitely more valuable than just plowing forward. I was also glad to see students reflect positively on the two-week project warm-up rather than frame it as wasted time and effort.

The next question to cover was, "What did not go well this semester?" I had them get up and move around the room to sit with different people for this conversation—something I had warned them I would do in my introductory remarks. For many of the items, I asked a follow-up questions, whether the conversation included ideas about how to address the things that didn't go well. I used two markers for this: black for the original item, and green for the suggestions. Again, my notes are below, with the green parts offset in square braces.
  • Project reports
    • Balancing the need for functionality against the practical application of design principles
      • [Emphasize making high-fidelity executable paper prototypes]
    • Justifying designs as meeting the principles rather than intentionally applying them
    • Struggling against "just make it work" vs. a good report
      • The former is enforced by department culture
      • One commented that I am the only faculty who grades on anything besides whether the software "works"
      • [Focus on design (look, feel, operation) over implementation]
      • [More practice exercises to practice implementations]
    • "Two-class" phenomenon, where first half of the class focuses on DOET and second half on the project, without a clear bridge.
      • [Again, high-fidelity executable paper prototypes might help here]
      • There were more conversations in the first half than the second
      • [Sitting in a circle would have increased conversation quality]
      • [Use an Interactive Learning Space for this class]
  • Test-Driven Development
    • Still confused about types of testing (unit, integration), test-friendly architectures, and how to test first.
  • Time management and problem slicing
    • Other faculty do not emphasize Agile slicing approaches
  • Continuous communication with DOMA
    • We had to work around their schedules, which held us back on our tight timeline
  • The collection database we used was inconvenient
I will quickly add comments about those last two points. Regarding working around their schedules, I explained that this phenomenon was one of the reasons why the granddaddy agile methodology Extreme Programming calls for an on-site representative of the client, so that they are always there to answer questions and work alongside you. Regarding the database we had, I pointed out that our data was a smaller copy of a live system in use by the University Libraries. That is, it showed what a "real" database looks like, rather than a fabricated one for a class example. 

It was delightful for me to hear students sharing so candidly about their struggles during the semester. Again, they identified many of the elements that had been on my mind as well, but it was more powerful to hear it come from them. I was particularly pleased at their comments about how the architecture of the room was an impediment to our activity.

At this point, we only had about twenty minutes left in the meeting. I told them that I was cutting the third question but still wondered if there was anything that still puzzled them. One student posed a really interesting epistemological question: how do we know if Don Norman's rules are the right ones? This got us into a quick conversation about how his rules in DOET are like Robert Martin's rules in Clean Code: they are not universal rules, but they are frameworks that help us consider what the truth might look like. In retrospect, I should have spoken about shuhari here, but I was trying to push ahead and it didn't come to me in time.

I moved on to the last question, again shuffling the groups. Here are their ideas of what might be a good final exam question for the course.
  • What does good design mean to you?
  • What are five of the seven Universal Principles described in DOET?
  • What are the four stages of the Double Diamond?
  • What went well or what did not go well?
  • If you were to take this class again, what would you do differently?
  • Give examples and applications of the seven Universal Principles
  • How would you change the organization of this course?
  • Reflect on something valuable you learned and how you will use it in the future.
  • Reflect on the outcomes of the course.
When the first item was shared, I asked how the student would assess responses. I think they didn't expect this question, but I assured them it was a good question, and that I was trying to understand the nature of it. A few students suggested that it would be enough to see if the hypothetical test-taker could answer it coherently, to show that they had thought about it. 

The second and third questions really surprised me. Those are so unlike the kinds of questions I give. I wish I had noted at the time whether these were students who had ever taken a class with me before, but I didn't. By contrast, that fourth item is exactly the kind of question I like to ask on a final exam, and the student who suggested it pointed to our notes on the other boards and said, basically, "Just ask those. Those are good questions." 

I had been feeling a bit down in the dumps on Thursday morning for a variety of reasons. The way I put it on Facebook was, "I feel emotionally dead inside, and now I have coffee. I can be apathetic FASTER." At the middle of the day, though, my Game Programming students showed their final projects, and most of them did a great job. That lifted my spirits, but after this meaningful, honest conversation with my HCI students, I felt almost giddy. Of course, maybe it was sleep deprivation, but I'll give them the benefit of the doubt. Maybe I let myself grumble too much about those students earlier in the semester when I was feeling uncertain. They were really a good group, maybe an uncommon mix, but they were paying attention and they were learning.

My original plan was that I would work with DOMA to choose a project they really wanted to see polished up, and then use that in my premiere graduate-level course on Software Engineering. As I recently reported, however, those plans have gone up in smoke. Instead, I will be teaching another section of Human-Computer Interaction. This gives me a chance right away to incorporate some changes, although it has to be done in the all-too-short winter break. But first, I better actually write my final exams. Thanks for reading!

Friday, November 30, 2018

Heroic Uncertainty: A Project for 2018 National Game Design Month #NaGaDeMon

TL;DR: Heroic Uncertainty source and Windows 64-bit builds are on GitHub.

I've had a game design idea tickling my brain for several years. There is an established pattern in fantasy games and stories that a hero receives quests from the imperiled people of the kingdom, and the hero's mission is to go overcome those obstacles. What if the information about the quest could not be trusted? That is, what if, like a game of Telephone, information decayed by the time it got to the hero, who then had to not only decide whether to face the peril, but also how much of the rumor to believe?  Earlier this year, I happened to mention this idea to a meeting of the Ball State University Serious Games Knowledge Group, and everyone around the table thought it was an intriguing concept. This inspired me to keep my eyes open for an opportunity to pursue building a playable prototype.

November 2018 may be better known as National Novel Writing Month (NaNoWriMo), but it is also National Game Design Month (NaGaDeMon). I have been aware of this lesser-known online creative movement for some time, but it was only this past year that I tracked down Nathan Russell's partially-active Website about it and, from there, joined the Facebook group. This game concept struck me as having too much complexity to finish in a weekend jam, but a month-long effort seemed a better fit. I knew that in November, my three classes would have transitioned or be transitioning into group project mode, which shifts my role toward mentoring rather than direct instruction. I figured this would be the ideal time to see if I could get this idea playable—and I did.

I spent a bit of time early in the month considering whether I could build a paper prototype of the core mechanisms, but my mind kept turning to more interesting computational models. I decided to build a proof-of-concept in Unreal Engine 4.20, furthering my own understanding of that tool and its potential for helping me move from concept to prototype.

A Distraction-Free Title Screen!
Heroic Uncertainty is a game where you control three heroes who are protected the kingdom from peril. Every few days, a creature shows up somewhere in the map, which triggers a person from that map to start heading toward the Capital in the middle of the kingdom. When the person reaches the capital, they report on what they know about the peril, which can include its type, size, location, relative power, and whether it requires magical skills to defeat. Each of these pieces of information has a chance of being incorrect, and so the player has to choose how best to deploy their heroes against uncertain enemies. If a peril is unaddressed for too long, it will defile the region, and the game ends when three regions have been defiled.

For most of development, the game was called Split the Party, playing off of the classic bad advice from tabletop roleplaying. I was intrigued by the idea of having multiple heroes rather than one, so that a player has to tactically deploy heroes with different skills to different areas. These three roles became Knight, Bard, and Sage. The only one with a really unique ability is the Bard, who can determine what part of a rumor is false. I was hoping to add special talents to the other classes as well, but as time ran out, the one most related to the core mechanism seemed best to explore.

Instructions in Thrilling Text!
The more information I added to the reported rumors, the more opportunities there were for information degradation. This is a clear area where more work could be done, should someone wish to continue the project. The current relationships between items is mostly random: for example, a peasant has an equal chance to report a bandit as being a demon as being a wolf. I tinkered with similarity graphs, but this quickly got out of scope for getting the game up and running.

Do you believe Chauncy the Thatcher? I wouldn't.
I've been showing builds of the game to my Game Programming students. It's funny to me that each time I show it, someone suggests highlighting the areas where perils appear or showing how long they have until they are overrun. The point of the experimental game is, of course, to see what happens if exactly that information is hidden. There are only two places where I bent this rule. When a region is overrun by a peril, it changes to green, no matter where the heroes are. Given full graphic production, I imagine that this would be shown as the region being set ablaze or shrouded in mystical darkness—something visible from far off. The other exception is that the heroes receive word about rumors when a person reaches the capital, whether they are at the capital or not. If the heroes know where each other are on the map, they must have some kind of magical communication network with each other, so why not with the monarch as well? This could be folded into a narrative more convincingly, but I think what I have is good enough for this experiment.

Combat! Perils!
What's the verdict? Honestly, a week ago, I would have just said that it is not fun. As I added more polish and, particularly, more information that could be degraded, I did begin to enjoy my internal testing more. The game has not really been played aside from my mostly-technical testing. However, I have been talking to people about it during the month, and their responses are revealing. One of them responded, "Oh, you're making Fake News: The Game." Hm, yes I suppose there is some sense of art-imitates-life here. Another response was that I was trying to gamify bureaucracy. Yikes, maybe so. All in all, I'm left with an idea that my wife and I discussed many months ago as I was talking about this concept, which is that it might work as a subsystem in a larger game, but that larger game had better be really good to overcome the frustrations of this subsystem. I do not plan on continuing work on Heroic Uncertainty, but I am glad I built it. I can put the idea to rest and have learned a bit in the process.

Let me turn, then, to some of the specific interesting things I learned by building this game. I've talked some about the innovative game systems above, but here I want to focus on some technical issues.

First and foremost, I've never programmed a game on a hex grid before, and I really didn't know how to start it. I came across Red Blob Games amazing series about hexagonal grids, which both helped me understand the mathematics and gave me a basis for building my implementation. If nothing else, make sure you check out their animation from cube coordinates to hexagons.

The implementation makes use of UE4's Data Tables, which I had never used before. It's a technique I had read about and was curious about, and indeed I even put it on the list of possible A-grade distinctions for my Game Programming class' final project. I ended up using CSV files to store tables of possible peasant names and their occupations, as well as the statistics of the various monster types. To add more of any of these, one simply has to edit the CSV and reimport the data table. Smooth.

The 4.20 release of Unreal Engine included support for Rich Text, something that was sorely missing in the past. Indeed, it would have been an excellent addition for Fairy Trails. It takes a few steps to get it up and running, but the documentation is clear.

A majority of the implementation of Heroic Uncertainty is in C++, particularly the formal game systems, with Blueprints being used for mostly visual and interactive elements. Building games in UE4 with a hybrid of C++ and Blueprints reminds me of how I feel about Lisp. Sometimes, I will work in Lisp for a while, and all the pieces make sense, but those insights seem to fall away as time goes on. It's almost like a peasant with a rumor about an invading orc who cannot quite remember the details when he reaches the capital.

In the original implementation of hex choosing, I had a custom dynamic material instance that used a pixel offset to depress the clicked hex. This looked good, but it did not allow for multiple actions on each selected hex. I'm quite pleased with both the UI and the implementation of my solution, which is to highlight the available actions on the hexes where they are supported. This is done with a custom blueprint that I called an ActionDecal. It consists of a decal that is displayed on top of the hex, tinted in the color of the current hero. I had never used decals before, and I had some trouble with them until I realized they render in curious ways if rotated away from axis alignment. Each decal also has a cube with the same dimensions, and the cube is not rendered but it is hoverable and clickable. This is how I detect the mouse moving over a decal and then, using timelines, highlight the hovered one or detect a selection.

You may have noticed that the heroes and rumor markers are simply the cylinders and cones that come packaged with UE4. Did you take a close look at those hexagons, though? I modeled those myself. Yes, that's right, I made my own 3D model and imported it into UE4. Pretty nice. I also explored UV unwrapping and used that to make custom textures for the hexes before I settled on the ActionDecal approach to action selection. This content, like a little experiment with spline-based animation, did not end up in the release, but it was still a fun area for me to learn about.

In Stunning 3D!
I had hoped to build the game for HTML5 and put it online, but there's a defect in UE4 that is preventing that build from working. The closest information I can find is this thread about 4.15. The author reports that the trouble seems to come from UMG, but I have not made the opportunity to try detaching different widgets to see if one of them is the issue. I do wonder if it's the fact that I am building my own inheritance hierarchy of UMG dialog boxes so that I get consistent behavior from them. I built the Windows 64-bit version and deployed that to GitHub, the only trick to that being that I had to use a console command within the game mode blueprint to get a window of an appropriate size. Designing the game for multiple window resolutions was definitely out of scope!

I did not keep track of how many hours went into this project, but I think 60 is probably a good ballpark estimate. I worked on it on several of my non-teaching days, as well as some nights and weekend hours. The worst times were when I spent several hours on systems that had to be discarded because they were ill-conceived. Indeed, in consecutive days, I started building similarity graphs of enemy features before really having a place to test them. This was a bottom-up design failure that ended up throwing away some six hours of programming. However, even here I got a good story to share with my students, as they were at a point of planning their own final projects.

You can download all the UE4 source files or a Windows 64-bit build of the game from GitHub. Feel free to check it out and leave a comment below. Thanks for reading, and keep on making games!

Tuesday, November 27, 2018

Plans for a graduate-level course in Software Engineering that I will not be teaching

Several weeks ago, I was assigned to teach my department's graduate level Software Engineering course in the Spring. This is a bit of irony, since I agree with Alistair Cockburn that "software engineering" is a bad metaphor for what we do, as he explains in his classic book. Be that as it may, I was asked to teach the course, so I did what any honest professor would do and start preparing it as well as I can. Indeed, I even started setting up a community-engaged project based on some of the work that my students are doing now in my HCI class. Last week, however, I found out that there was only one student enrolled in the section, and the department decided to make some other kind of arrangement for that student. It's still not clear to me what I will be doing instead in the Spring, although it looks like I may pick up a section of HCI. I had already done a bit of planning, including reaching out to several alumni about their experiences in industry. Rather than let this languish in a few documents in my planning folders, I decided to compile a few of my notes here.

The SE course master syllabus is not very well constructed, which is amenable to my desire to take an agile approach rather than the clearly-presumed waterfall approach. The master syllabus only identifies one course objective: "The student will be able to carry out a reasonably sized software project from requirements specification through analysis, design, implementation and testing." On reading this, my imagination turned to all the interesting things we could do to lead to this outcome. Further down, however, I came across the "Course Content" section, which comprises the following paragraph:
Topics include an introduction to software engineering, the software life cycle, user requirements, structured specifications, risk analysis, system design, module development, testing methodologies, software metrics and models, software cost and effort estimation models, validation and verification of software, software quality assurance and software reliability.
This gets to sound more like the table of contents of a textbook rather than being about concepts of effective software development. What I decided to do was to map out the content listed in that paragraph into the kinds of activities that I hoped to do, both to make a skeletal course plan and to find the holes that needed filling. Below are essentially my planning notes that I had up to last week, with just a little bit of extra context given to the reader who is not already in my head.


  • Software lifecycle: 
    • Contrast waterfall, spiral, and agile approaches
  • User requirements:
    • Requirements capture via CRC cards
    • User stories, including Mike Cohn's format, Allen Holub's more narrative approach
    • Potentially Jeff Patton Story Maps, although maybe this is more appropriate for the follow-up course on requirements and design.
  • Structured specification
    • Conditions of Satisfaction and Acceptance Criteria as part of Agile planning
    • Behavior-Driven Development (BDD), as related to Test-Driven Development (TDD)
  • Risk analysis
    • Risk matrices from Microsoft Solutions Framework
  • System design
    • Robert Martin's Clean Code, SOLID, and Clean Architecture
    • Potentially Allen Holub's Design by Coding concept
  • Module development
    • Clean Architecture and SOLID
  • Testing methodologies
    • BDD & TDD
    • Integration testing / Continuous integration, potentially with jenkins or TravisCI
    • Acceptance testing and Usability testing, using Nielson's Five Users heuristic
  • Software Metrics and Models
  • Software cost and effort estimation models
    • Discussion of the #NoEstimates movement, including Holub's overview
    • PERT Analysis with wideband Delphi (Clean Coder chapter 10)
      • From here, estimate costs for a project using a helpful heuristic from a friendly alumnus: $75/hr junior developer, $125/hr senior developer, $150/hr architect, +20% for design work.
      • Another friendly alumnus told me about at his company, contract costs were more art than science, built from years of experience and reflection rather than formal models. This is also valuable to know!
    • Planning Poker
  • Validation and Verification
  • Software quality assurance
    • Contrast separate QA teams and cross-functional agile teams
  • Software reliability
    • Pair programming
    • Code review
    • Code standards
    • Automated style checkers
Writing it all out, it sounds like kind of a good course, doesn't it? Imagine exploring these ideas embedded in a community-connected project, getting feedback from people outside the class, discussing models and philosophies of development. I was actually getting kind of excited about it, even though at first I was taken aback. Well, at least the notes are here, and perhaps someone will find them of value in the future. Thanks again to those friendly alumni who pointed me in some useful directions for some of the areas here that I was unsure about, particularly cost estimation.

Monday, November 19, 2018

Presentation notes for a talk inspired by 1984 and Inevitable

Over the Summer, my colleague David Largent invited me to give a guest presentation in his Fall 2018 Honors Colloquium that is exploring George Orwell's 1984 and the ideas in Kevin Kelly's The Inevitable. At first, I balked at the invitation, unsure of what I could offer to such a discussion. I read 1984 in my undergraduate science fiction class, but I am not familiar with Kelly's work. I ruminated on the idea for a few days before accepting the invitation. My presentation is scheduled for this evening, so over the past two weeks or so, I've been trying to pull the pieces together. Not being a fan of single-purpose work, I decided to write up a few notes here.

The first topic that came to mind is Neil Postman's excellent Amusing Ourselves to Death, which seems situated right in the middle of the colloquium. This book was recommended to me by friend Charlie Ecenbarger when we were working together on The Bone Wars. Postman's thesis is essentially that we are at more danger of losing ourselves to entertainment as in Aldous Huxley's Brave New World than we are from the totalitarianism in 1984. I decided to make Postman's ideas a cornerstone of my presentation, briefly discussing McLuhan's "the medium is the message" is interpreted by Postman into "form excludes the content." I am hopeful that the students will have adequate grasp of history of communications to imagine a world transitioning with newspapers, telegraph, radio, television, and Internet. I am slightly fearful that they will not really understand a pre-Internet world, but I'm hoping a Socratic approach might help here.

As I was reviewing the helpful Wikipedia summary of Amusing Ourselves to Death, I was reminded of Postman's theory around "information-action ratio." This in turn reminded me of Tufte's data-ink ratio, which I find a useful heuristic for evaluating information visualizations. I decided to bring Tufte's example in to my slide deck as a way of trying to help students understand information-action ratio by metaphor. Both raise interesting qualitative questions: is one ratio better than another? If not, how are they different?

I'm currently in the middle of reading Dorothy Sayers' essay "The Lost Tools of Learning." In includes this relevant excerpt:
…The stock argument in favor of postponing the school-leaving age and prolonging the period of education generally is there is now so much more to learn than there was in the Middle Ages. This is partly true, but not wholly. The modern boy and girl are certainly taught more subjects--but does that always mean that they actually know more? 
Has it ever struck you as odd, or unfortunate, that today, when the proportion of literacy throughout Western Europe is higher than it has ever been, people should have become susceptible to the influence of advertisement and mass propaganda to an extent hitherto unheard of and unimagined? Do you put this down to the mere mechanical fact that the press and the radio and so on have made propaganda much easier to distribute over a wide area? Or do you sometimes have an uneasy suspicion that the product of modern educational methods is less good than he or she might be at disentangling fact from opinion and the proven from the plausible?
This struck a chord with me and resonated with my review of Postman's thesis. Reflecting on these relationships brought me back to John Taylor Gatto's essay "Against School," and so I decided to take my favorite part of that and include it in my slide deck as well: his explanation of the six functions of secondary education according to Alexander James Inglis. These are, briefly, the adjustive or adaptive function (obedience to authority), the integrating function (make people alike), the diagnostic or directive function (determine students' social roles), the differentiating function (sort and train students by their determined role), the selective function (improve the breeding stock), and the propaedeutic function (train the select few to lead the rest). I put the six principles' names onto a slide and prepared a handout with John Taylor Gatto's explanation of them.

It's possible that if this uses up my time, I will just stop here. Otherwise, I have a bit of a thematic shift in my planned remarks, which I have naturally identified in my slides with one that says, "Now, this!" I pulled some slides out from a regular guest presentation I give in my friend Dom Caristi's creativity seminar. In particular, I have a sequence wherein I introduce Subrata Dasgupta's Creativity in Invention and Design and its relationship to Margaret Boden's The Creative Mind. If there's time, I would like to have the students take Shelley Carson's Creative Achievement Questionnaire and to close with a point about the ubiquitous and scale-free nature of Price's Law. Part of my point here is not to question whether technological innovation is literally inevitable or not, but that we can see that those who drive at are those who have deep and broad technical knowledge. I wonder if there's something to tie into Douglas Rushkoff's Program or be Programmed as well, but I'm sure I'll be out of time by this point.

My 2PM appointment didn't show up today, so I was able to finish writing up these notes before my next appointment. I'll post a follow-up if there is anything surprising or unusual to report after the presentation.

EDIT: I ended up only getting up through the education slides, stopping short of the creativity discussion. Even here, I took up more time than I expected. The students were reasonably responsive, although I was challenging them pretty quickly with ideas they had never considered before. Perhaps the only story worth sharing here is that we talked about what the key cultural values are of oral culture, print culture, and television culture. They agreed that it was likely listening and interpreting for the first and close reading for the next. For television culture, a student suggested that the skill that allowed you to participate in culture was being able to distinguish good from bad information in the media. I think they were a bit surprised when I turned this on its head (as Postman does) and suggested it's the value of being entertained—the value of not carefully considering the information being presented.

Saturday, November 17, 2018

Painting Thunderstone Quest

My brother backed the original Kickstarter campaign for Thunderstone Quest, and he encouraged me to take a look at the follow-up campaign for the Barricades expansion. Hearing his praise for the game made me take the plunge, and I received my copy of the Thunderstone Quest base game several weeks ago. The game comes with six miniatures that are almost entirely superfluous to the gameplay. Each player needs to mark where they are going in the Village or where they are in the Dungeon, but this could just as well be done with tokens or meeples. Indeed, my boys and I just finished playing through the printed campaign book just using the pirate, ninja, and Scotsman meeples that my brother had previously sent as gifts.
While we played the campaign, I set to the painting table and painted the six miniatures for the game. These are the first miniatures I've painted since summer, since the intervening crafting time was taken up with Gaslands cars (part 1, part 2) and then the new X-Com 2 DLC. As you will see in the photographs below, the miniatures from Thunderstone Quest are weirdly varied. I saw a discussion online that jokingly referred to it as a set of three heroes and three children that you could throw into the dungeon. Unlike many of the miniatures I paint, these ones did not represent any specific characters from the game, so I had complete freedom to choose their color schemes. I was inspired by a Board Game Geek thread to theme them around the six colors of Guardian Keys from the game: yellow, green, blue, orange, red, and purple.

Speaking of basing, I decided to try something new on this set. I usually base with a mix of fine, medium, and coarse grit that was designed for model railroads. However, I recently watched Tabletop Minions' Atom Smasher talk about his baking soda technique, and how it produces a rough finish that is more in scale for common tabletop miniatures. Briefly, you coat the base with superglue and then sprinkle baking soda, which is a very fine powder and activates the glue. I also embedded some other grit of various sizes, cork pieces, and foam bricks into the glue for added scenery. Here's how they looked before priming:

I took them to the airbrush booth for zenithal priming, and then brought them to the painting table. I also decided to do some more fanciful basing than I've been doing in a while. I'll go through the minis with just a few brief notes in the order I painted them.

I saw on a forum someone refer to this figure as a satyr, which certainly would go with the pan pipes. However, I couldn't help but see the "horns" as being goggles, so that's the way I took him. Truly, it's kind of a terrible figure, with scant details and an uninteresting pose. He's my yellow champion, so I gave him a dandy yellow shirt and various warm browns for his pants, boost, and pack. I painted some birch seeds in autumnal colors and put them around the base, and I used the first little bit (I think) from my fall clump foliage, and I think these do a good job of bringing the colors together.


Here is my green champion, a curious little fairie perched or leaning on a log. The green "wings" called out to be a focal point here, so I gave her a similar toned green tunic and shorts. The yellow vest and orange-pink hair add nice accents. In this figure and the previous one, I also played with mixing other colors into my flesh tone base: brown in the kneeling guardian and red in this one. I added a small piece of lichen to the base in hopes it would imply a mystical forest setting.


The blue champion is in a more dynamic pose than the others, although the quality of the sculpt (or its manufacturing) don't quite meet the ambition of the artist. The dagger in her right hand is actually cutting right through her boot, for example. When I first planned out the colors for this rogue, I intended to keep the arms covered in a dark tunic, but I'm glad I made them bare instead, since this lends much-needed contrast between the flesh tone and the dark blue clothing. It may not be practical for sneaking around, but it adds better visuals. I am pleased with the little pile of rubble that it's front of her, which again I think implies that she's exploring a ruins or the slums but without being too overt.


The orange champion has a beard to be proud of, with lots of steel ringlets to add contrasting color and texture. This quality of this figure felt much higher than the previous three, except for some tricky bits where his arm passes over his beard. I thought about giving him more orange highlights in his clothing, but I'm glad I kept him in grey, muted colors, so that his hair and beard really become the focal point. I was going to keep his base just plain grey rubble with a slight bit of dull green flock. As I was putting my basing materials away, I noticed my bag of rooibos tea and decided to add some "sticks" to the ground, and I think this helps give it a bit more character.


The red champion towers above the rest in a wonderfully dynamic sculpt. Some of the details of the armor filligree are lost in the production, but I think the excitement of the figure makes up for it. This was the only one where I did no extra work to the base aside from painting it and adding a few spots of dull green flock. In my first pass through this miniature, I had all the filigree in red, which was bold and striking at first, but then I was worried it was not enough of a palette. I went back in with the yellow highlights to try to give him a warmer overall tone, and I'm pleased with the results. You cannot tell from the photo, or even perhaps from holding the miniature, but I also did some slight glazing of red over the metallics where it would reflect the cape, as well as on the sword. These are the kind of subtle touches that I sometimes see other painters I admire discuss online, but I always feel like I'm waiting for a real showpiece to paint before I want to spend that much time on it.

The final one in the set is this wizard, which like the knight above seems like she's from another aesthetic planet than the other four miniatures. As I looked over her and thought of how to make her the purple champion, I was reminded of Psylocke from Marvel's X-Men comics. I looked up some images of the classic Psylocke I remember from the 1990s and decided to try to capture that aesthetic, to make purple the focal color despite its not being the most used color. I think it worked. The silver is a nice neutral accent color here. In my first pass on this figure, I had her sleeves purple as well, but I realized the emphasis would probably work better if I kept it in the hair and the magic. I thought about doing all the magic orbs in silver, but I decided that little splashes of color were more in order. Each of the colors in the magic spiral shows up somewhere else on the figure, but some only barely: there are yellow, green, and cyan potions on her belt, and these are tied into the spell effect. This one certainly took me the longest, but it's also my favorite, both in terms of the figure and the painting. I kept the base fairly simple, just adding some tea leaves as leaf litter among the rocks.

Here they are all together, which helps you see the bizarre difference in scale. The miniatures came in a molded plastic tray, but I'm not sure if that will work for storage or if it will rub the paint off. I also don't know if it will be worth our using these rather than our meeples. Regardless, it was good to get paint to plastic again, and I'm glad I tackled them in order of increasing miniature quality.

As for the game, we've been loving it. Thunderstone Quest will certainly kick the original Thunderstone out of my collection, and likely Legendary as well. We've just started playing some random scenarios, and at some point I expect we'll try playing in one of the Epic modes.

Thanks for reading!

Thursday, November 8, 2018

Workshop on Gamification in Higher Education

Several months ago, I was asked by the Division of Online and Strategic Learning if I would be interested in leading a faculty workshop on gamification of higher education. They buttered me up by telling me that "several people" had suggested to have me give a workshop on this topic. I am dubious that such people exist, but I decided that this would be a good and appropriate form of professional service for me. I took some issue with the intended title, given that "gamification" has a negative connotation in many academic circles. However, I decided that if this is what people asked for, then this would be an appropriate title to use, and I could wrap whatever I really wanted to share within that heading.

I reached out to a few friends in person and online who have done similar work, and I was able to get some good ideas and feedback. I was hoping to share a draft on my blog and get some constructive criticism from these folks, but actually designing the workshop ended up taking priority over writing about it. The workshop was offered in two one-hour sessions at noon on October 29 and November 5. There is a third workshop in the series run by somebody else; that session will focus on how to do some gameful practices in Canvas, but I have really nothing to do with that part.

What I would like to do here is share the outline of what I covered, describe the activities I led, and share a bit about what worked. This way, if I am ever asked to do such a thing again, I can always come back and check my notes. Also, who knows, maybe this will even be useful to you, dear reader.

After spending a lot of time writing ideas on index cards and shuffling them into different stacks, I decided on an overall structure that would have Day 1 focused on the questions: What is play? What is a game? Why do people play games? Day 2 then focused on these questions: How do we design games? How do learners experience gameful designs? Finally, should we gamify higher education?

I created a deck of slides to help keep myself on track, and I've made them publicly viewable. In text, I will walk through the main points and activities that we engaged in.

We opened with introductions, in which I asked everyone to share their name, department, and—reusing a technique I use in my game design classes—a summary of their last great play experiences. As with students, many faculty conflated "play" and "game", but not all of them did. One participant explicitly drew upon the question to talk about renovating his bathroom, describing the visceral feeling of slamming a hammer through the wall, and he spoke of "playing" with the materials.

I briefly explained how "gamification," "playful learning," and other terms are used differently by different communities of practice, as I alluded to in the introduction of this post. I pointed out that higher education is already a game: there's a clear start and end, and we assign points and celebrate victory. This helped to establish that I was looking at games, play, and design as ideas that integrate into what we already do.

We got into the slides, and I started with the question, "What is play?" I drew upon Huizinga's Homo Ludens and then Caillois' Man, Play, and Games here. For the latter, I described the four categories of play he defined (being agôn, alea, mimicry, and ilinx) as well as the ludus-paidia spectrum. I put up a table of the four categories and the ludus-paidia axis, and I asked the participants to name activities we already use and to place them into this table. This activity had good participation. The biggest surprise to me was when a participant brought up public speaking requirements as an example of ilinx (vertigo). So many students are afraid of public speaking that our making them speak in front of the class is tantamount to our putting them in a state of vertigo.

From here, I moved on to the question, "What is a game?" I always like to invoke Wittgenstein here and his description of "game" as a word that we cannot define—but that hasn't stopped game design theorists from doing their best. I walked through a curated list of some of my favorite thought-provoking definitions, including those from Chris Crawford, Sid Meier, and Bernard Suits, before landing on my personal favorite from Raph Koster, "Games are just exceptionally tasty patterns to eat up." This allowed me to go on a brief aside about Koster's seminal Theory of Fun for Game Design and its observation that the "fun" in games is often because of learning.

The next question to cover was, "Why play games?" I explained that to a game designer, "fun" is too broad a term compared to other, more specific concepts such as fiero, schadenfreude, naches, and kvell. With those terms on the board, I asked the group to think of activities we do in class that invoke these different kinds of fun. This also led to a positive discussion, with examples mentioned of all four. One of the more interesting was sharing or discussing bad student work as something that invokes schadenfreude: if a professor mentions that many students made a particular mistake, it can give a bit of coldblooded "better you than me."

I brought up Bartle's Player Types: Acting-Interacting against Players-World, to get the quadrants of Achievers, Explorers, Socializers, and Killers. I made sure to point out that Bartle wrote an excellent chapter about how people have misused his taxonomy, but that I was pretty sure we were OK to move forward with our exercise. I asked the participants to consider the kinds of activities we use in class that favor different kinds of "players." My recollection is that they generally agreed that most of our work focused on Achiever types, and we talked briefly about what it might mean to explore other areas of this domain.

This wrapped up the first day, although I had originally planned to talk about Flow on the first day. I had just enough time to give them a handout with homework, which drew predictable groans. The handout lays out five different learning paths a participant could choose for next time:

  • Explorer: Play a new board game.
  • Reader: Read Paul Darvasi's exemplary chapter, "The Ward Game" (from Teacher Pioneers), in which he describes transforming his high school English class into an insane asylum to teach lessons from One Flew Over the Cuckoo's Nest.
  • Maker: Design your own game.
  • Analyzer: Analyze an activity you use in class using one of the lenses introduced in the first day of the workshop.
  • Sustainer: Bring delicious snacks for Day 2 of the workshop.
As we started Day 2, after brief introductions, I asked them to share their work along the learning paths. Two or three had played new games and shared that experience. Unfortunately, the Ward Game chapter had not been mailed out until that morning, so no one had even seen it yet. It gave me an opportunity to give a summary of the chapter, but it really deserves a thorough reading. One participant has been working on his own game for some time, and he was happy to say a little about it when I asked if anyone had done the Maker exercise. One person shared what they admitted was a shallow analysis of their in-class activities from a games perspective. Tragically, no one took up the Sustainer, although this gave me an opportunity to explain how I use compulsory treat-bringing as a punishment for being late to my studio courses. I think of all the stories that I told over the two hours of the workshop, this may have been the one where I had their attention most clearly.

All told, maybe half the participants shared anything during this period, so I think it's fair to say that the exercise was not taken seriously. However, I don't regret it, because the handout and discussion provided a concrete example of how one can design multiple, different, equally-valid paths to understanding an idea. We came back to this later on. 

We jumped back into the slides with my giving an overview of Flow. Only 25-30% of the participants had heard of Flow before, and I shared with them some quick bullet points about the properties of a Flow state and the conditions for getting into one. I showed the diagram that I tend to see come up in discussions of game design, which plots Skill against Challenge. I explained that my understanding of the psychological literature was that this wasn't actually quite right: it's not Skill against Challenge, it's Perceived Skill against Perceived Challenge. From a teaching point of view, there's an enormous difference between these two, particularly considering that there's essentially no correlation between students' self-efficacy and actual ability.

Then we did a little exercise that I thought would be more interesting than it turned out. The idea was to trace the path of a student (or a student persona) through the flow diagram. I had tried it myself and found it to be an interesting challenge. Here's the relevant example:
I explained that when I teach CS222, I frequently get a category of student who did well in the prerequisite courses because of their high school experience, and this gives them an inflated sense of their programming abilities—that is, high Perceived Skill. As the course continues, the challenge goes up and they start to see their skill as being lower (shown in green above), moving rapidly up into anxiety. I believe that with the right interventions in the course, I can help these students have the blue line experience instead, where their sense of their own skill "catches up" with the challenge to put them into a Flow experience. Note that the blue line starts and ends at about the same value of perceived skill, but by the end of the course, it's actually aligned more with their actual skill.

I wondered if this exercise would be interesting to the participants, and so I tested a variation on it in my game design class. I had them draw their own path in the diagram, considering the "game" of designing their final game project. I showed the students my path through a project, and then I asked them to share their stories. As they shared, we started looking for different kinds of shapes that they had drawn, looking for patterns and similarities in their stories. It was a great exercise for them I think. For the faculty in the workshop, though, I think only one person shared what they saw in their diagram. In his case, he observed that there was high anxiety but not because of what he had designed: it came from external factors, specifically the fact that he was teaching education majors the semester before their student teaching.

We moved on to another kind of analysis, this one inspired by one of my heroes, Dan Cook of Spry Fox. He wrote an essay a few years ago about arcs and loops as fundamental components of game design. I came across it when preparing for the workshop, and it inspired me to think about the loops and arcs in my course design. I drew up two examples, the first is from my CS222 Advanced Programming class.

The course has three arcs, which are the first three weeks of the class. It then goes into a series of loops, whose relative importance is depicted by their size. The two-week project is followed by three three-week iterations of the final project, each one with more weight and importance than the last. At the end, there's a little arc to represent the final exam.
The other example I gave was of my current semester CS315 Game Programming class. It is composed of a series of arcs of increasing weight, these comprising the two-week mini-projects that are designed to teach concepts of increasing complexity. At the end of the semester, students work in teams on a project in two iterations. The two iterations are the same size, so there's only one visible loop.

I pointed out that the loops were where students had the most opportunity to learn. I acknowledged that the nature of my material lends itself to loops, but that teaching programming is a bit like teaching writing: good work is done by iteration and feedback. I asked them to consider the loops and arcs in their own classes and to share their stories. One participant described how he has his students work in a portfolio, where each assignment is done once but the portfolio writing process is covered each time; we agreed that this might be a multidimensional drawing, with a loop spiraling up out of arcs. Another participant said that she teaches solely in arcs, but she was interested in considering how she might use loops to enhance students' learning.

I had one slide on Self-Determination Theory, but I neglected to ask how many were already familiar with it. For each of the categories of autonomy, competence, and relatedness, I called back to examples we had discussed before or shared new examples from my own work. I showed them how in CS222 I use achievements in order to foster different aspects of Self-Determination Theory, and they seemed interested in this approach. I also showed the specifications grading that I am trying in Game Programming this semester and explained this as an approach that helps with a sense of competence since it eliminates black-box grading. Unfortunately, I missed the opportunity here to gauge how many were already familiar with specifications grading. It would have been interesting to know for how many people this was an introduction to new ground vs. showing an application and contextualization of something they have encountered before.

We only had a few minutes left, so I had to make a judgement call between finishing up or opening the floor for questions and discussion. I decided to move forward, because this is something that's been on my mind—not to mention being in a half-written, still unpublished blog post. The last question to address, then, is the dangers of gamification.

I mentioned briefly that much of game design is based on extrinsic motivation: we give the player points, eye candy, and social experiences so that they will enjoy our games. However, we know that extrinsic rewards diminish intrinsic motivation. Is it worth adding extrinsic rewards to courses if it reduces students' desire to engage in these activities themselves? As far as I'm concerned, the jury is still out. There are not enough longitudinal studies on the effect of higher education. (This is one of the reasons we should abolish the core curriculum: we have no evidence that it meets its design goals. But I digress.)

The final point I made is the one that I've really been struggling with in my quiet moments the last few weeks. A friend recommended I read Make it Stick, and I don't want to spoil my future post, but there was something in that book that really rattled me: Immediate feedback is better for short-term retention and worse for long-term retention, but delayed feedback is worse for short-term retention and better for long-term retention. I think game-based learning takes it for granted that immediate feedback is good, but the research cited in the book doesn't match that. It seems to me that we, designers of educational experiences, can choose whether we want students to get a good grade now and forget the material later, or get a worse grade now and remember the material later. What, exactly, is the goal of higher education?

With that uplifting challenge, I thanked them for coming, reminded them about the third session that I was not involved with, and wished them a good day.

Overall, I am happy with the workshop. Some of the activities didn't go quite as well as I hoped, but it was hard to tell the difference between quiet contemplation, confusion, self-consciousness, and apathy. No one complained or threw rotten vegetables, so that's something anyway. Thanks again to my colleagues who shared their ideas and feedback with me, especially Scott Reinke, who kindly shared his experience and helped with a few ideas over email.

Tuesday, November 6, 2018

Throwing paper airplanes to learn agile methods

My game programming class has started their final project, which is to be completed in two iterations. My intention was that they would deploy what they learned in the Advanced Programming prerequisite to develop good user stories and plans, but many of them asked specifically for some kind of lesson or activity to get a better understanding of agile methods in general and Scrum in particular. I spent some time yesterday searching for best practices here, but none of the canned exercises I could find satisfied my goals. I wanted something that would teach the basic structure of Scrum and include the use of a task tracking board. I ended up making some modifications to ideas I found online and deployed them in class today.

To start, I had them play this online Battleship game that is used by some trainers to get people—especially management—to understand the fundamentals of agile approaches. In the game, you can choose how many shots to take at a time before you get feedback about whether or not they hit. I had half the class work in a 40-shot increment and the other half work in 10 shots. As one would predict, the half with shorter increments had much higher scores than the others. Not only that, they were also done faster: the 40-shot students were among the last done because they had to be so judicious with their resources. I asked the class the difference between the two groups, and they correctly identified feedback as the key. I quickly explained how this is a decision we make when choosing, say, a waterfall-based or an agile methodology, and then we moved on.

I had them count off by fours to make four teams who don't normally work together, and I put each one in one of the "alleys" between tables in RB355. I drew a template task board, with columns for Story, Not Yet Started, In Progress, and Done, and had they copy these to their boards. I gave an overview of what would happen: a three-minute planning meeting that would generate tasks on sticky notes, followed by three three-minute "days" of a Sprint, followed by a review and retrospective meeting, and then another series just like that. They had seen some aspects of this before, so we were able to get right to work, and at this point, they were very curious about the activity we were going to do. I handed out their user stories, which are transcribed below, and after giving them about two minutes to read the sheet, we got into the planning meetings.

Product Backlog

Fleet
Build a fleet of at least four paper airplanes that satisfy the following criteria:
  • A plane must be folded from 8.5”x5.5” paper only. No additional material may be added and no extra material may be removed.
  • The nose of the plane must be blunted to avoid accidental injury.
  • The plane must have crisp, clean folds. 
  • A plane that satisfies the above conditions must bear all team members’ initials. This marks the plane as part of the fleet. Once initialed, a plane may not be removed from the fleet.\
Branding
Each team has its own name and logo.
  • The logo must be publicly displayed by the team on their board.
  • The public display must have each team member’s initials to indicate their approval.
Hangar
I have a hangar that indicates the starting position of my fleet. The hangar satisfies the following conditions.
  • The hangar covers at least 11”x8.5” of the floor and be at least 1/2” off the ground.
  • The hangar features the team’s logo.
Flight
Maximize the number of planes from the fleet that can touch the far wall while still in flight.
  • The hangar is no more than two floor tiles from a wall.
  • The plane thrower’s feet must not be more than two floor tiles from the wall.
  • Sliding along the floor to the far wall does not satisfy the flight goal. The plane must strike the wall while still in the air.
  • A plane that has met the goal is placed next to the hangar. No other planes may be next to the hangar.
  • Earn points equal to the number of planes that pass the mark minus the number of planes in the fleet that do not.
This is a customization of the "agile paper plane game" that you can find in various places online, such as here. All versions of the game I came across shared the property that each member of the team had to make one fold in planes. I did not like that approach, since that's not generally how (my) agile teams work. They don't have every piece of work move through every person like an assembly line, but instead, they rely on clear communication of both serial and parallel work. I also took inspiration from Lego4Scrum, where the tasks look a lot more like real software development work. I don't have the budget to buy enough Lego kits and have them sent via expedited shipping, so I combined the two ideas.

I provided both whole and half sheets of paper for their use, as well as the sticky notes and, after they realized that some of the sticky notes were not very sticky, some adhesive tape. The students got right to work and stayed within the bounds of what activities belonged in which timeslice. They were clearly and intensely focused, which made it both rewarding when a plane soared straight to the far wall and comical when so many of them flipped and flitted about before nosediving into the ground.

I noticed as they worked that some teams were using 8.5"x11" sheets to fold their airplanes, but I didn't challenge them on it right away. Rather, at the end, I asked them to review the conditions of satisfaction and have a chance to come clean. One team had recognized at the end of the first sprint that they were in violation of the airplane acceptance rules—one of the emergent leaders pointed out that he only read "8.5x..." and assumed the rest would read "11" and not "5.5". They made tasks to deconstruct their hangar and planes and recreate them to satisfy the constraints and did so in the second sprint. Another team had not read the conditions carefully at all and only realized they were in paper size violation when the other team told their story.

I asked each team to share stories about what changed between the two Sprints, and the results were fascinating. One team discovered the value of cross-functional teams. In their first Sprint, they distributed tasks and as a result only had two different plane designs, neither of which were making it across the room; in the second Sprint, they all worked on each piece and made more progress. Another team pointed out that they jumped into the plane-folding task with gusto because they were excited about that, but that their excitement was not actually producing anything that satisfied the conditions. That team added a more explicit research step in the second Sprint, which helped them vary their designs and produce more useful planes. I pointed out that Scrum allows for "spikes" that are used for just such cases. I wish I had taken better notes, because the other two teams also made changes to their process in such a way that highlighted core agile practices and attitudes, but now I cannot remember them. It's like I tell my students regularly: "I will remember this" is the primary fallacy we tell ourselves.

At the end, I asked them to share their insights about what they learned from the exercise that could be applied to their final projects, and the results of this were excellent as well. Topics that were brought up include the importance of making estimates (and in particular, of making them large enough), giving adequate time to planning, articulating tasks in a clear and measurable fashion, and keeping everyone aware of your progress on your tasks.

I was really surprised by how well the exercise went, perhaps in part because it's so unlike the kinds of things I normally do in class. I generally prefer to do and reflect on authentic work rather than small simulations or throwaway work, but here I think it let the students focus on the process rather than the minutiae of programming. I was really impressed by their reflections on the process and its implications for their project. My own professional preparation with agile software development methods allowed me to hear their stories and contextualize them within more general principles and rules.

There were a few things that I would change for next time. It wasn't clear to me that having a "Stories" task on the board mattered at all, or that anyone used it the way I intended. The exercise would  have been fine without it. A couple parts of the handout can be clarified. I had two students come up to me with what I would call "pointy" planes and asked if they were "blunt enough." I started telling them to use their eyes to measure bluntness: if it fits in your eyeball, it's too sharp. This was maybe a bit challenging to interpret, so maybe another measurement of bluntness is appropriate. In my description of the hangar, I meant that it should have a volume of at least 11"x8.5"x0.5" and be sitting on the ground, and I should have just said it that way. Instead, I worded it as 1/2" off the ground, which some students interpreted as elevated, like on a chair or table. One team was also unclear about whether it was the front or the back of the hangar that should be within two tiles of the wall, although this was also the team that tried throwing their planes at the near wall instead of the far wall, so I think this was an intentional trying to game the system and not an honest mistake. (We did not come back to the point that this one group tried to interpret the rules in their favor rather than seek confirmation or favor value for the customer.) Almost every team ended up having one person write each other team members' initials on their planes and logo, rather than what I intended, which was that each person inspect the work and then initial it. I can make that more clear.

That's the story of my game programming class today, finished writing just in time to go to my next class of the day. As always, please feel free to leave a comment about your experience with agile training games or ask about the activities of the day. I expect I will reuse the exercise again in a future course.