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.

Thursday, October 25, 2018

Answering three student questions about Computer Science, Internships, and Industry Trends

One of my students sent me an email last week with three thoughtful questions in it. Following the principle of no-wasted-writing, I decided to share my answers here on my blog. The questions are in bold, and I did not edit them for posting here. I'm going to encourage the student to consider his own answers before reading mine, and you, dear reader, may try the same.

What really defines if a student successfully completes the undergraduate CS program at Ball State? I’m not talking about the program and university degree requirements, but rather if they got everything they are meant to out of the CS program. Is there a “tipping point”?

That's a great question, and there's a couple of different ways to answer it. I will start with the structural approach that is conventional in industrialized higher education.

For most of its history, the department operated with implicit objectives, but almost ten years ago, we formally agreed to a set of five. These were adapted from ABET's accreditation criteria, and they define what a student should be able to do after graduation. They are:
  1. Mathematical foundations, algorithmic principles and computing theory: Given a software task, the student will be able to choose an appropriate algorithm and the related data structures to efficiently implement that task. The student will be able to do an asymptotic analysis of the chosen algorithm to justify its time and space complexity. 
  2. Design and development skills: Given an appropriate set of software requirements, the student will be able to formulate a specification from which to design, implement and evaluate a computer-based system, process, component or program that satisfies the requirements. At a minimum, this must include the ability to design, implement and evaluate a software system using a high-level programming language, following the conventions for that language, and using good practices in software design to satisfy the given requirements.
  3. Ethics, professional conduct and lifelong learning: The student will behave consistently with the ACM Code of Ethics and Professional Conduct. This includes developing the capacity for lifelong learning in order to maintain professional competence.
  4. Communication skills: The student will be able to communicate effectively through oral presentations and written documentation, including well-organized presentation materials to explain software concepts to non-technically oriented clients, clearly written software specifications and requirements documents, design documents, and progress report.
  5. Teamwork skills: In order to contribute effectively and meaningfully to any team development effort, each team member must be able to think independently and arrive at creative and correct solutions to problems. This includes the ability to find and evaluate existing solutions to similar problems and adapt them to solve new problems. Each team member must be able to communicate ideas effectively to other team members and cooperate with them in integrating the solutions of subproblems to accomplish the team's common goal
In theory, then, a graduate should have all of these qualities, and our departmental assessment should tell us to what extent we are meeting our goals. We have done a fair job over the past several years of conducting mid-major assessment: after CS222 and CS224 (Advanced Programming and Algorithm Analysis), we use a formalized assessment process to determine if students appear to be making progress, particularly toward departmental objectives #1 and #2. For example, we were able to see no measurable difference in CS222 performance before and after our change in the intro course from a conventional CS1 approach in Java to a media-centric approach in Python, and we were able to push down some critical concepts earlier in the curriculum, like good naming and functional decomposition.

The upper division courses and capstone assessments have, unfortunately, been inadequate for any practical purpose. Put another way, the department agreed upon these objectives as guideposts, but we have not done due diligence to see if we are meeting them—much less making modifications to ease us toward better performance. I think a CS student in any program can look at this list and think of how conventional higher education privileges some aspects over others. Our own two-semester capstone course should be a proving ground for practically all of these, but we lack meaningful assessment data to draw defensible conclusions. Note that your particular question about a "tipping point" should be measurable if we had a clean mapping of these objectives to particular courses and curricular activities, but right now the best we have is anecdotes.

There's another, more holistic way to look at your question, and it tends to be the approach I favor despite its being arguably less measurable. Students who have taken my CS222 class should be familiar with the Dreyfus Model of Skill Acquisition. It is a descriptive model for any set of skills, where aptitude can be measured in categories of Novice, Advanced Beginner, Competent, Proficient, and Expert. Anyone can become a Novice with very little effort, and raising to Advanced Beginner generally takes some education and practice. However, a defining characteristic of Advanced Beginners is second-order ignorance. That is, they don't know what they don't know. This aligns with the psychological phenomenon of the Dunning-Kruger effect, where Advanced Beginners misclassify themselves as Experts. Overcoming second-order ignorance allows one to truly become Competent, which includes a measure of intellectual humility—a recognition of how much more there is to learn. That, then, is my shorter answer for what it means to earn a bachelors degree in Computer Science: students should have climbed the Peak of Mount Stupid and come back down to recognize the need for lifetime learning.

Incidentally, I learned about the Dreyfus Model by reading Andy Hunt's Pragmatic Thinking and Learning. He and I had an email exchange about it, and we agreed that, broadly speaking, we should expect a bachelor's degree to produce Competent skills, a master's degree to produce Proficient skills, and a doctoral degree to produce Expert skills. In practice, I don't think that higher education has assured that this is the case, but I think it's a worthy consideration if nothing else.


What makes an internship worthwhile?

This is another great question. Let the record show that I have never had the responsibility of deciding whether or not a student internship is worthy of course credit, so I am speaking from a position of educated opinion and not (as above) as an academic trying to do a competent job.

The conventional structure of higher education is one of analysis: the breaking down of complex wholes into manageable parts. You can see this from course and textbook organization all the way up to administrative organization. It is a convenient model for many reasons, although it falls into the fallacy that my analysis should work for you. All analyses are really design projects that have to be evaluated for fitness. Turns out, grouping academics by similarity of department works well for peer evaluation in conventional situations. It doesn't always work though, such as with interdisciplinary problems like the game design and development work that I do: some of that work looks like Computer Science, some looks like humanities, some looks like communications, education, art, etc. Who should evaluate whether or not I am fulfilling my scholarly role in such cases? The administrative structure imposed by the analysis becomes dysfunctional.

Let me bring this back to internships. Higher education structures are pretty well ossified. There are a few calls to enhance multidisciplinary education, such as our own campus' laudable immersive learning projects, but at the end of the day, it's the administrative structure that determines your budget, and it's the budget that allows you to operate. So, a good internship is one that exposes a student to a different analysis—a different way of breaking down a complex world into workable parts. In a way, it's like the idea of having two majors or picking up a minor that is different from your major: learn to see things in a different way.

There's a secondary goal of an internship, which is to engage in legitimate peripheral participation in a field where you would like to work. There can be enormous advantages to this, but I think a lot of them deal with the property I mentioned above: seeing people doing their practice teaches you about the culture of that practice. Students, by and large, are watching faculty do our practice, but our practice is really strange. There are relatively few people who do the work of higher education—especially in higher education. [rimshot]

Anyway, that's what entered my head when I read your question. Take it for what it's worth. If I had the chair's job of evaluating whether or not an internship was worth major credit, I would probably have to deal with things like authentic mentorship and learning objectives, but I think I can get away with my more epistemological stance for now.

What are your thoughts on AWS (Amazon Web Services). It seems like a lot of companies are transitioning to AWS, but do you think this is what we are transiting to as an industry or just the latest bandwagon a lot of people are jumping on?

This is not in my field of technical expertise, though I've read some and talked to alumni and friends doing this kind of work. It seems to me that there are great gains to be had by adopting microservice architectures, from a maintenance point of view in particular. Distributed processing can lead to significant performance gains. Also, there's a very high initial cost of setting up a proprietary, globally-distributed network of reliable servers. If someone else (Amazon, in this case) has already done that work for you, then it seems reasonable to rely on their expertise here. So, it appears to me to be a natural transition rather than simply a bandwagon. The people I know who are doing it are being very careful, from a business and technology point of view. Of course, there are implications for security and accountability as well.

As for me and my projects, we choose Firebase.

That's the end of my responses. I hope that sharing them here was of interest to my readers. Feel free to leave a comment to share your thoughts, as always.

Thursday, October 18, 2018

Gaslands crafting, Round 2: Cars and Templates

We had so much fun making our first round of Gaslands cars, we decided to do another round—and this time, even my wife joined in! A friend of hers responded to our request for spare Matchbox and Hot Wheels cars, and she generously gave us a huge bin of them. As before, almost all the modifications are based on 3D-printed weapons and bits from Fun Board Games.

We'll start with my cars, which I can tell you a little about, and then we'll run through some of the other family-crafted cars.

I started with a pair of cars intended to be used as a Miyazaki team, using the sample team from page 38 of the rulebook. This team is noticeably different from the rest in that it has no shooting weapons: all the cans are spent on driver perks and performance cars except for one dropping weapon. I wanted a clear team color scheme for this pair of cars, and I ended up going with simple racing stripes rather than more fanciful embellishments. The cars were originally going to be called "One-Stripe" and "Two-Stripe", but I decided to go with "Ichi" and "Ni" instead. (Also, now that I upload the photos, I see they are a bit warm. I don't think I want to re-shoot all the cars, so I'll just leave them as-is. It's only repainted toy cars, after all.)





 

Honestly, I'm not happy with them. While painting them, I was eager to see what I could do with the stripes, and so I did not pay enough attention to highlighting the blue. I also wanted them to look sleek and new, so I did not do any weathering on them. The result is just bland. This is a shame, since it turns out they are really fun to play as a team. The stripes make it hard to go back and touch up the blue, so I would have to really repaint the whole body to revise it.

My other two cars are not really designed to go together; they are just a pair that explore different things I wanted to try. I've read about modelers and miniature kit-bashers talk about using styrene to make custom pieces, and so I finally bought myself some styrene sheets and tubes. I built the mortar on this truck by cutting up two machine guns from my 3D-printed set, using the back of one as the back of the mortar and the front of the two others as struts. The barrel is a styrene tube with accents created from—you guessed it—a slightly larger styrene tube.

I didn't have much of an idea of how to paint it, so I figured I'd try camouflage. The tone isn't quite right, but I like to think the gearhead who was painting it didn't know any better anyway.


This last car of mine was just having some fun with styrene blade accents. The spikes on the wheels were from the set I bought, but the hood blades were hand-crafted. I also tricked out the exhaust a bit, after seeing how my son (below) had done his. All of our cars are much more tame than some of the post-apocalyptic stuff that hobbyists produce; it might be fun on my next set to do lots of armor plating and mesh, but for now, I'm happy making them look good and getting them to the table.


My wife decided to join in this round of car creation. Here are hers:




She was cautious about shades and weathering, but I think she did a fine job. The complementary orange and blue works really well on the white car in particular. Funny story: I saw a work-in-progress of the bottom car and told her I was excited to see someone do a white car. Turns out, it was just primer and she was planning to paint it a different color. My wife has only painted a handful of miniatures with me, such as Valeros for our Pathfinder Adventure Card Game campaign, but I think she has areal talent for it. Maybe we will do more couples' painting someday.

Next up are the cars by #1 Son (11), who had developed a Mishkin team and wanted them to have a uniform look.





In our first painting session, he had done the cars and the windshields in nigh-identical blacks, and I don't remember now if I commented on that or not. I think he did a great job bringing out the windshields, making them appear a different material from the rest of the car. He did ask me about lightning as he was getting into it, and I suggested a layer of white first, so that the blue would pop. I think he did a nice job with this, layering in multiple blues. Also, the edge highlighting on his cars is honestly better than my blue team.

The other funny story here is that I saw which cars he was working on, and he referred to them as "performance cars", which are a specific designation in Gaslands. I laughed and pointed out that these Matchbox cars were not sports cars, they were just sedans. He seemed to not really know the difference, but I thought about it, and it's not like we talk about cars. The rulebook doesn't have pictures. How else would someone infer what the rules were talking about? Anyway, I am not sure if it was in response to my comment or not, but he went in and added the extra exhaust pipes, making them out of nested styrene tubes similar to my mortar. I am pretty sure his idea for this technique came from my working on the mortar, but I ended up liking his exhaust pipes so much that I copied it on my orange car above (sans nested tubes).

Now we get to #2 Son (8), who was making a Slime team. He hasn't really read the rules, but he liked the idea of a team called Slime that focuses on causing chaos. His team is called "The Exploding Sharks," and here they are:





Notice the shark-tooth motif on the hoods. He was intentionally going for bold, crazy colors here. I do wonder what his cars might look like if he was trying to do a serious paint job. Sounds to me like we need to carve out more family painting time.

#3 Son (5) got involved as well, and I was really surprised that his cars were much less gun-encrusted than the first round.





It's kind of hard to look at them and make sense out of what he was trying to do, but it's all very deliberate. Indeed, it's interesting to watch him and his younger brother work with such attention and focus, yet not clearly without any plan. It is as if all the focus is going into an understanding of the materials as they are, rather than having any concern of the outcome-as-desired. Maybe I'm making that up or projecting, I don't know, but it makes me curious about children's art education philosophy.

Finally, #4 son (3) was happy to work with us to build and paint some cars as well.





Personally, I love the machine gun going sideways off the bus. We're putting machine guns on cars, so why not?

Here's a few pieces of terrain that I put together as well.

The top two are simply large templates cut from black craft foam and grey felt for oil slicks and smoke, respectively. The other two are mines and caltrops and required a bit more work. My wife picked up several small containers of beets at the grocery store, and the tops had a section of plain, clear plastic that looked just right for Gaslands' small template. The mines are buttons whose holes I filled with Milliput and then painted to look dirty and metallic. If you look closely, you can see that there's still some unfortunate putty texture to the top, and this was after I added several layers of gloss varnish to try to smooth out the surface. Good enough for tabletop work, but not as nice as I had hoped for.

The caltrops were the most labor intensive, but also the most fun. I took unused staples and clipped them in half with my wire cutters. This leaves two nice L-shaped bits, and so I glued these together with Goop. That was tedious, because I had to hold these tiny little asterisks still while the glue cured, but it was a good excuse to listen to a podcast. Once that was done, I decided that I wanted them to have a painted look rather than a raw metal look, so I primed them black and painted them a gunmetal color, with a wash to add grime and shade. Once that was done, my plan was to glue them to my small beet-top templates, but holding them next to the cars, I thought the scale looked wrong. I went back with my wire cutters and clipped off about a quarter of each leg. The resulting caltrops are what you see here, superglued to the templates.

The cars were actually completed sometime in early September or late August, judging from the dates on my photos. I started writing this post weeks ago, but despite my claim to the contrary, I was thinking about reshooting all the cars under better lighting condition. This means that the cars have been all over my painting desk since, and the semester has been beating me down, so I haven't done any painting since then. I have some pieces primed that I'm just not excited about, but I happened to receive a shipment earlier this week that is giving me some excitement to paint; watch this blog for future details.

My Miyazaki team has faced down my sons' Mishkin and Slime teams in two rounds of a planned three-round escalating tournament. So far, Mishkin has won each time, so the scores are 10-6-2. Essentially, Mishkin's tournament victory is a fait accompli, but we're still having fun. The escalating part of the season—where you add ten cans to each team between games—is the least interesting part to me, but I like the tournament format with random scenario selection. Turns out Mishkin can really crank out the points in Saturday Night Live.

Thanks for reading. As I said, the semester has been wearing me down, but I think we're transitioning into a quieter period, with all my conferences behind me and students switching into project mode. I have a research protocol that a colleague and I are working on that still needs to be submitted to IRB, and there's still plenty of work to do on our curriculum. I also just found out that I'll be teaching a new course next semester: our graduate-level introduction to software engineering. It's not what I would have chosen for myself, but I'll do my best to make it good. Expect a tilt toward agility.

Sunday, October 14, 2018

Notes from Meaningful Play 2018

One of many effective learning techniques that my students don't use is transcribing their notes. I was reminded of this when I took many pages of notes at the 2018 Meaningful Play conference. I decided it might be fun to share my list of odds and ends here. Perhaps there will be something here that the interested reader might learn from, or at the very least, it gives me a chance to create a digital archive that I can return to.

Tracy Fullerton mentioned a book called Wanderlust: A History of Walking. That could be interesting.

She also mentioned a Situational Game Design, whose abstract claims that it is about analyzing games as player experiences rather than systems. This could also be good, and it makes me wonder how it compares to Chris Bateman's writings about games as being constituted of player practices and with the systems approaches that I tend to like from folks like Koster, Cook, and Burgun.

Fullerton was making a case that games should be about interesting situations, and that this should include meditative play. She gave an example of a meditation-reward system in Walden: having Thoreau pause and look over a scenic setting rewarded the player with a little narration. To me, this raises the question: who is meditating, the player or the character? She gave several examples of games that included this kind of mechanism, but there weren't any compelling counterexamples given. It left me with a sense that maybe I didn't understand her, or maybe she assumed the listeners were already on the same wavelength. A particular call was made to move "beyond mechanics, beyond systems" and toward "a series of meaningful situations" in game design. The problem I have with this is that having Thoreau narrate his meditative experiences is system design. I didn't have these thoughts fully assembled in time for the Q&A, and I did not have a chance to talk with her later in the conference. I appreciate her sharing her work-in-progress ideas about where to take game design. That is, after all, a lot of what I do here.

Well Played has a CFP about intergenerational gameplay, and the idea is for the intergenerational players also coauthor an article about the experience. I'm thinking of trying this with my sons, probably the oldest one.

Ann Arbor is known as a fairy town, with little hidden fairy doors throughout the city. People geocache with these doors too. I need to tell my colleagues at Minnetrista about this, in case they don't know about it already.

The city of Brussels has a tour based on comic art. I need to send this to Easel Monster.

Is reading Finnegan's Wake worth it? Paul Darvasi says so, and he's one of the coolest scholars I know. He also said you can't "read" it, but rather you "study" it, time and time again. It sounds fascinating, maybe it's like the English literature version of Godel Escher Bach.

I heard someone refer to "gamification" as "punish by reward", referring to how it uses extrinsic motivations to diminish actual learning results. I need to keep that in mind for this workshop I've been asked to run at BSU about game-based learning.

Eric Zimmerman seemed to me to be separating games, systems, and play in his keynote. Part of what gave this away was a slide with those three words on it, and that he talked about them as separate. I had a hard time with this, since I see them as not just interconnected, but essentially the same—at least when done well. I asked Darvasi about this and he pointed me to Zimmerman's Ludic Century manifesto, which covers the same ground and, fortunately, is shorter than Finnegan's Wake. As with my earlier notes, I don't have all my ducks quite in a row here yet, but let me share the gist of it. This is informed, without a doubt, by Cockburn's Heart of Agile philosophy. There are systems in nature that are studied by natural scientists. Other systems arise from human behavior, and the intentional ones are studied by the sciences of the artificial. A good designer must recognize that the system they design fits into a bigger system, and that people have experiences before and after, and sort of parallel to, their systems. These systems are like software: we design them as specifications, but they have dynamic behaviors. We design them statically, we hope for the dynamic behavior we want. To design intentionally for humans requires accounting for human nature, which is playful; put another way, if you design for humans and you don't account for their playfulness, you are not doing good design. I think this is the right idea but I need to work on the articulation. I am very grateful to Andrew Peterson for listening to me as I tried to sort out my thoughts about this, and who constructively disagreed with me, and Mars Ashton, who said essentially, "Yes, it's all just design."

One of the best presentations I saw was by Sandra Danilovic. She organized a game jam for people with a variety of disabilities and welcomed them to make games about their disabilities if they desired, and she conducted a qualitative study around the event. One of her findings she called logopoiesis, which was essentially about the healing power of computational thinking (as I understand it from the presentation). I asked her if this particular factor was tied into the fact that these people were making games versus, say, film or poetry. Turns out she herself had background in a variety of arts, and she said two particular cases in her study dealt with the challenges of problem solving through programming and with the meditative act of arranging pixel art. These things she found in her analysis to be separable from the other characteristics. I thought this was fascinating: there is a lot of rhetoric about the power of computational thinking (more rhetoric than empiricism, but maybe that's unavoidable), and I have said for years that computing is really a new liberal art. This was the first time, though, that I have come across the therapeutic value of it, as related to its poesis (the making of a thing that did not exist before—a definition I had to check because it's not in my usual lexicon).

I learned about the game Night in the Woods, which sounded quite interesting. The more I heard about it, though, it also started sounding more and more nihilistic. I'm not sure if it should go on my to-play list or not. The speaker also recommended Wandersong, which I also didn't know much about. I seem to be behind the times on trendy indie games. Heck, I just finished Bard's Tale IV, a sequel to a game from thirty years ago, so "behind the times" may actually be generous.

Someone recommended I check out Mark Rosewater's Ten Things Every Game Needs. They said it was a good summary of ideas, well articulated though not groundbreaking. I did not write down who made this recommendation and cannot remember now. I just scrolled through, and it looks reasonable.

I had a great conversation with Andrew Peterson during a "dinner break" when neither of us felt like going and getting dinner. He shared with me several interesting ideas he uses in his game design class. First, he has completely "flipped" the class. They do readings and preparation on their own, and class sessions are almost entirely devoted to teams working on their prototypes. The teams are randomly assigned themes from a brainstormed list. His students have a week 12 ship date, at which point they have to have their materials sent off to Game Crafter. The physical prototype that arrives is what he then grades. This front-loads the work into the earlier part of the semester and allows for more slack time for the students in the last three weeks, when their other classes tend to build to fever pitch. Peterson also mentioned that as an instructional designer and game designer, what he likes to do is ask faculty what they don't like to teach from a course: identify the variables, determine which can be turned into a game. This also might be useful for me as I start prepping for my own campus presentation on games in learning.

I met Chris Totten, who said the most perfect and quotable thing over breakfast: Games should be good. He is clearly a like-minded individual.

Kate Edwards supposedly has an excellent talk about imposter syndrome. I think this must be it. I was at a table with some very talented people, all of whom had stories about how they themselves had been touched by imposter syndrome and how they knew some of their heroes also did. This is interesting by itself, but one also mentioned how he teaches his game design students about imposter syndrome and the Dunning-Kruger effect. He has them do a short jam of sorts to show off their skills to their cohort, after which it is easy for people to feel outclassed. He introduces these topics then, and he reminded our table that students generally are unaware of these phenomena. It made me think, I should do something like this in many of my classes as well.

Henry Petroski has a book about the pencil. That sounds amazing.

The Death and Life of Great American Cities sounds like a great book about urban planning. Some colleagues were very excited about this work, enough to make me think it could be worth looking into.

A friend told me about a talk that Jesse Schell gave at GDC about grant funding in which he set a $50 bill ablaze. I was able to reach out to him for the link, and I look forward to watching it later.

A speaker happened to mention that he uses one-page design documents successfully in an upper-division game design and development class for Computer Science majors. This surprised me, since the times I've tried it, I've found the assignment confounded by my students' lack of visual communications and document design skills. It sounds like they are doing the designs on whiteboards, but they're also iterating on them during the semester. I sent out an email asking for more information last night, and this morning—as I continue this lengthy post—I have already received a response. They have their students start with whiteboard designs and make them progressively more refined during the semester. I also see that I think we were using different terms for the same thing. They are drawing upon David Osorio's style, where a "one-page" is more of a pitch document, whereas I use the term drawing upon Stone Librande's, where it replaces a design document. What they're doing in Osorio's style, which incorporates images and two-dimensional design, I have my students do using Tim Ryan's concept document format, which privileges text.

One of the best talks I saw, both in terms of content and form, was by Jessica Hammer. Her work was inspired by research findings that students don't get better at giving feedback during the semester if the skill is not taught. Hammer presented her EOTA model for helping students give feedback to their peers after playtesting. "EOTA" is an acronym that walks through the kinds of feedback that should be given in sequence, the expansion being: Experience (I thought..., I felt...), Observations (I saw...), Theories (Therefore...), and Advice (You might...). She described a learning experience where the designer had to remain silent during the whole feedback process, although she amended that to include that the designer could say "Thank you." I look forward to reading her whole paper once the proceedings are up, because I think this is the kind of thing I can bring into many of my classes to help students learn how to give and receive feedback.

Another wonderful pedagogic structure she described was to have students write down their favorite snacks on a survey at the start of the semester. Then, when a team does really well, she can bring in those students' favorite treats in honor of their accomplishments. This is very clever, since it doesn't put anyone on the spot: the students who did well know it was them, and everyone gets to enjoy the treats. I need to keep this in mind as I'm planning next semester's courses, although maybe this will have to wait until Fall 2019 just due to the teaching I expect to be assigned for Spring.

A keynote speaker mentioned the concept design fixation, which is when one gets caught thinking of an object only for its conventional purpose. I jot this down here just because it's a useful term that I'm not sure I would have thought of, had I been looking for it.

I met Derek Hansen who is teaching cybersecurity and using games, so I just sent him some info about Social Startup Game, which Kaleb Stumbaugh and I created as a research and design project a few years ago. I had to look up where we presented our findings besides the S2ERC Showcase, and it turns out that was Meaningful Play 2016. Unfortunately, when you look for the proceedings of this conference, they are nowhere. I have emailed the conference organizers a few times over the past two years to ask about it, in part because I am so happy with the evaluation that Kaleb and I conducted. Still, however, no paper in the proceedings. A copy of the paper is available on the project site, however, so interested readers can check that out. (I forgot it was there, so in fact I just rebuilt the paper from LaTeX sources to send to Hansen. Oh well.)

A speaker strongly recommended Kurt Vonnegut's Player Piano, which I am sure I've never read. Maybe that would be a good piece of fiction to offset all the non-fiction building up in my reading list.

A keynote was given by Katherine Isbister, whose work on wearable technology was not previously known to me. I am sending her name to some friends studying HCI.

A speaker brought up the idea that karaoke-style games can help people learn to pitch correct. It made me wonder if there are good ones that my kids can use. Some of them clearly love to sing, but I find it hard to teach them to hear where the notes go.

Sissy's Magical Ponycorn Adventure. Gunman Taco Truck. Ian Schreiber has been kind enough to talk to me quite a bit about "fam-jams", or family game-jams, and these two games are great inspirations. I think I already wrote about how my oldest son made two complete games at the last Global Game Jam, whereas mine barely worked. It inspires me to find opportunities to do some more creative collaboration with my kids. Chief among his tips are that when working with your children, you should do what they say—not necessarily what they want, but what they say. Watch this blog for details.

I overheard a friend mention a book called something like "Just Keep Writing," and he said that although the book was about creative writing, it could just as easily be applied to games. I am not sure what the specific book was, but I'm sure he's right. It brings up a thought that came up all during the conference for me: I should make more.

In her keynote address Saturday morning, Diana Hughes from Age of Learning brought up mastery learning. This is the idea that students may not move forward in the curriculum until they have shown that they have mastered antecedent work. It struck me that this is essentially a tech tree or a skill tree in games: you cannot build the next thing until you build its predecessors.

I attended a workshop about The Agile Teacher. It is a game created to help teachers—particularly new teachers—to explore active learning techniques. The game presented each group with a context, ours being a mathematics seminar with 10 or more students. Each group presented their findings to the rest of the room. By design, groups were supposed to have a context in which no one at the table was an expert. The designers explained that they had seen cases where the one person at the table who is from that area would tend to dominate the conversation. That makes sense. However, I also noticed (and shared with the designers) a fascinating phenomenon: without pedagogical content knowledge, every group designed activities that represented stereotypical understandings of the domain. The groups that had drawn Math as their domain reverted to a high-school understanding of math as essentially computation. The groups that drew Science worked on techniques to help students memorize taxonomies. Computation and taxonomies are both parts of math and science, but they are ancillary. It's not exactly a flaw with their game, since it was doing what it was designed to do (namely, foster conversation), but it was an interesting phenomenon nonetheless. It made me think about how I have seen people at my institution pigeonhole other faculty because they think they understand the others' domain. Maybe it's an instance of good old, "You're a Computer Science Professor? Can you help me with my printer?"

The final session I attended was another workshop, this one given by the aforementioned Andrew Peterson about his game, enRolled. The game is designed for new college students, to get them thinking about the impacts of their decisions as students. His motivation was excellent: as an adjunct, he was handed a course where he was supposed to lecture new students about how to succeed, and he realized that lecturing about these topics was of limited value. Peterson then worked with his students to design the first incarnation of a game to convey similar ideas. The difference was that student would engage in meaningful and authentic discussion around how to codify things like drinking and studying as game mechanisms, whereas they were hesitant to do so in a dry lecture. Very clever. He said a few times, "The game sucks," pointing to its dependence on random events and lack of balance. However, he was also clear that it does what it was designed to do: foster important conversations. This is an interesting dovetailing into my previous notes, reflections, and conversations around what design really is. In this case, Peterson has a playful conversation generator that happens to be a game, and so its fitness function is not about balance but about authenticity of emergent conversation. The game can be purchased one-off from The Game Crafter, but he also mentioned that he hopes to run a Kickstarter to print many copies at once and therefore reduce the price.

There was one particular story that Andrew shared with me that I want to capture here, so that I can re-tell it to my game design students. I hope that he doesn't mind my doing so. When he was working with this students on enRolled, the task was to determine the relative negative points of drinking and drugs. Andrew started with the idea that drugs would be worth -10 and alcohol, -2. His students, however, disagreed, justified by the prevalence of alcohol abuse. Very few of them knew someone who dropped out of school because of drugs; they all knew several who had dropped out due to alcohol. What a great example of how game design gave rise to new insights and conversations!

That's the end of my notes. I've shared here almost everything within my pocket notebook, just skipping some of my notes about questions to ask presenters that turned out to be not worth sharing here. Other interesting things happened during the conference as well, but my goal here was not to write a conference report but only to assemble the thoughts that I wrote in my pocket notebook. (Variations on these notebooks have always been in my pocket since reading Pragmatic Thinking and Learning, by the way.) I am tired out from the conference and feeling a little apprehension at the coming week, knowing that I now have to catch up on a backlog of tasks. If you have made it this far through my notes, know that I'm happy to discuss any of these ideas with you in the comments or future communications. Many thanks to the organizers of the conference for such an inspiring event, and thanks to those attendees who shared their knowledge, wisdom, stories, and advice.