Board games with young kids

I was discussing board games for kids with a colleague yesterday, and I sent her a list of recommendations. It struck me that this may be useful to others as well, so I've decided to provide the list here, with some extra details.

To give some context, these are played with my wife and nearly-five-year-old son, Alex. We have been playing some of these games since Christmas 2011, when he was in his late 3's. I have provided links to Board Game Geek, where you can find good summaries, discussions, reviews, and images of the games. Rather than repeat that information here, I've provided some tips on how we have modified the game to make it more fun for our family.

Kinder Bunnies

This is a kid-friendly version of Killer Bunnies and the Quest for the Magic Carrot. It comes with two decks, blue being the basic one and yellow adding a bit more complexity. This helped scaffold my son's learning, as he was able to get comfortable with the blue before getting into the yellow. He does not really read them; he knows the cards by their pictures.

We did make one significant change to the rules. The game contains Safety Hazard cards, analogous to weapons in Killer Bunnies. Each has a numeric value, ranging from 1 to 10, and the severity of the hazard clearly scales with this number. The rulebook recommends that to overcome a Safety Hazard, one should roll the five 10-sided dice and try to match the number. This means that all the Safety Hazards are mechanically equivalent, which is rather dull. We imported the mechanics from Killer Bunnies instead, rolling a 12-sided die and considering the hazard overcome if the roll exceeds the hazard's value. This is much more fun, though you will have to supply your own 12-sided die.

Carcassonne

This is a great game all around, and I was a little surprised at how well and quickly Alex learned the rules. His strategies are rather simple, and he frequently makes moves just to entertain himself rather than for points—but the point is to have fun, so it's no big deal. We also have the Princess and Dragon expansion, which he tends to like to use because it has an awesome red wooden dragon. However, we have noticed that with these added bits, he has a harder time focusing on the rules: I think it's more complexity than he has patience for. Still, he does love to eat meeples with that dragon, and can you blame him?

The Amazing Labyrinth

We have fun with this one, although my son sometimes has trouble picking out moves. There is still a good balance, however, as we let him use the "kids" rule (all six treasure cards face-up) while my wife and I use the "adult" rule (only one treasure face-up at a time).

Reiner Knizia's Amazing Flea Circus

We've been able to enjoy this game for some time, but I feel like more recently the strategies have become more apparent to Alex. As I wrote before, we put it away for a few months, but now he has no trouble counting the dogs as two points and the cats as one. Perhaps most importantly, you can use a plastic dog from this game when you play Betrayal at House on the Hill, and the cats too if it's the right haunt.

Survive!

This is a game from my wife's youth, and we have the 1982 printing. I have not played the 2011 re-release, but looking over the pics on Board Game Geek, it looks like the same game. When we play with Alex, we ignore the point values on the bottom of the guys and focus on getting them off the island. That is, we treat each person as one point. We have never actually tried to play the "full" game with him, but I suspect this would be frustrating.

Settlers of Catan
This one is the most recently added, a bit of a risk as we were looking through the cabinet for something Alex might enjoy. He requires a bit of coaching on effective road placement and initial settlement placement, but he really enjoys it, especially building new things. Since he is not a strong reader, we also have to help with development cards. We orient all of the number discs to face him, and this provides good practice at number recognition; he's known his numbers for some time but still gets confused between '6' and '9', as well as '11' and '12'. When Alex rolls the dice, he has to count all the pips to find the total, and I'm hoping that with repeated play he will start to see the patterns more easily. Despite the extra effort it takes us to help him play, we all tend to enjoy it.

Happy gaming!

La Fin du CS222: An Assessment in Three Acts

In December 2010, I wrote about an experimental approach for assessing a course's effectiveness, using convergent and divergent exercises and mind maps as a replacement for traditional written exams. Since then I have used this approach a few times, with only minor alterations.

For last Fall's CS222: Advanced Programming final, I was inspired by a recent purchase to present the assessment to my students as La Fin du CS222: An Assessment in Three Acts.

Act I, Scene I
Each student constructed a mind map on the topic of programming. They had done the same exercise on the very first day of the semester.

Act I, Scene II
In this scene, I distributed to the students their original mind maps back to them. The main source of conflict in this scene was that it was the final assessment of how well I had learned their names.

Act I, Scene III
Each student wrote an essay comparing and contrasting the two mind maps.

The essays were generally well-written and insightful, especially those where there was not much change. One student commented, "Now I know that this random assignment we did at the beginning of the year was not so much for you but for us." This is great evidence of metacognition, that the student has learned to think about the value of reflection to himself rather than to some arbitrary authority.


Act II, Scene I
I hung my giant, flip-chart-sized sticky notes and told the students that we were going to list, in twenty minutes, all of the things we learned this semester that were somehow connected to the course. I briefly explained that this was a divergent thinking exercise, meaning that anything could be listed and there would be no debate or criticism at this stage. We ended up with 119 items, which may be a new record.

Act II, Scene II
I asked the students whether there were any items on the list that should be consolidated. Many suggestions were made, though not all were chosen by the majority. After this process, we were left with 113 items.

Act II, Scene III
Each student was given four stickers, and they were asked to place these by the four items that they found most significant. It was made explicitly clear that significance was subjective.

Act II, Scene IV
We identified at the top elements by vote, which are given in the table below. I have provided clarifying links for the curious.

Item	Votes
Object-oriented design	19
Coding conventions	14
Agile Manifesto	14
Effective Java	11
Test-Driven Development	7
Stack Overflow	7
User Stories	6
Mercurial	6

Act II, Scene V
The students were challenged to write an essay about what they actually did to learn these items that the community had chosen as the most significant.

I believe that it is important to help students understand the connection between what they personally do and what they have learned. Last year, the first time I did an exercise like this, we did another round of divergence and convergence to determine what actions helped learning. I was not very happy with the results because they became too generic: I was hoping for more specifics than "the project," for example. Unfortunately, most of the essays were written in generalities rather than specifics. In part, I think this is human nature: if we write in specifics, we make statements for which we are accountable and that may be shown to be false. Writing in established generalities, such as "I learned a lot by working on a team," is certainly easier than identifying specific times, places, and situations with the team that led to learning about a particular topic. I realize now that, if I want the students to write about specifics, I need to provide more explicit guidance to this end. I also need to narrow the focus: taking the top ~10% of items is too many: even though students were told they could pick from among the eight listed above, many wrote vague statements about all eight or a majority of them, as if they would get points for coverage rather than quality.

Some of the essays did contain interesting insights. My favorite comment was on the hassles of merging in Mercurial. We had previously discussed in class how tool-supported merging could be frustrating, but that it was a necessary evil—and actually not evil at all compared to the manual, ad hoc alteratives. This student identified how the frustrations of merging made him focus on learning encapsulation, because he realized that the better encapsulated and more modular his team's system was, the fewer times they would have to merge. Excellent!


Act III, Scene I
Cinnamon Rolls, courtesy of my lovely wife.

CS315 Final Assessment: Games about Beneficence

For the last eight weeks of the Fall semester, the eleven students in my CS315 Game Programming class had been working as one team, following Scrum to complete a version of Morgan's Raid implemented entirely in Unity. The team worked very well together, as I have written about previously. At the end of the semester, they had produced a reasonable facsimile of the Morgan's Raid release, given our constraints.

Regardless of their collective accomplishments, I still have to assign individual grades to each student, and I take this responsibility seriously. We used self- and peer-assessments during our four two-week sprints, and these helped me approximate students' individual contributions to the project. However, I still felt that I was missing hard, individualized evidence, and so I presented my students with a novel form of final assessment that we called Mini Ludum Dare.

Ludum Dare is the Rapid Game Development Community, most well known for hosting regular 48-hour game development competitions. Each competition begins with the announcement of a theme, and all games must incorporate that theme. For our Mini Ludum Dare, I told the students to spend no more than four hours on digital prototypes, my rationale being that I wanted to see what they could get done in about a half-day's work. This seems like an appropriate assessment, that at the end of a game programming class, one can individually produce a proof-of-concept for an idea. Because I was grading strictly on technical issues, I also provided a "default" game design that students could use if they were not feeling inspired by the theme. They were allowed to complete the prototype in Unity or Slick, these being the two primary technologies of instruction for the semester.

The theme was "Beneficence." This can be interpreted in a few ways, the most obvious connection being to the statue who also graces Ball State University's logo.

During our university-assigned final exam slot, the students each had a few minutes to show off their creations. It was inspiring to see how creative our Computer Science majors could be! The Java-based solutions are a bit tricky to get online, but with some coaxing (and peer pressure from the community on the department's Facebook page), the Unity-based games are online. Here are some links:

• Jumpin' Beneficence by Jason Buie
• ZombBenny by Thomas Mast
• Beneficence: The Hunt for Knowledge by Phil Wingham
• Beneficence the Killa by Craig Bavender
• Whack-a-Benny by Matt Waters

A pretty amazing selection of game prototypes built in only a few hours each. Nice work, gentlemen!

Bloom's Taxonomy of the Cognitive Domain

Two nights ago, I gave a presentation at the 2011 IGDA Indianapolis Charity Toy Drive, a great event that I hope becomes an annual tradition. My presentation was entitled Fun, Learning, Games, and Responsible Design (in under 20 minutes). I gave an overview about the relationship between games and learning, and my core message was a rallying cry, asking designers to seriously consider what players learn by playing their games. My perspectives on this are heavily influenced by Raph Koster's work, and as I told the crowd, every designer should read Theory of Fun for Game Design.

I generally don't post slides from my talks because the slides don't stand alone: you could not reconstruct the message by only looking at the slides. I agree with Martin Fowler, that "slideuments" are flawed by definition. However, there was one slide from my talk that really seemed to resonate with the crowd. I based much of my presentation on applications of Bloom's Taxonomy of the Cognitive Domain toward gameplay experiences. Wikipedia has a nice, simple diagram that presents the taxonomy, and I have used this in presentations and handouts before---but this was always when using OpenOffice.org or LibreOffice directly. For the IGDA presentation, I needed a PDF, and something about the conversion to PDF left the diagram quite jaggy. To solve my problem, I made my own variant on the public domain image within LibreOffice, and it looks a little something like this:

This variation is CC-BY in case you want to insert it directly into your own presentations, papers, posters, etc. An ODG version is available as well. Full license terms below.

Bloom's Taxonomy of the Cognitive Domain by Paul Gestwicki is licensed under a Creative Commons Attribution 3.0 Unported License.

Based on a work at en.wikipedia.org.

Books for practitioners

At the end of the semester, a few students asked me for technical book recommendations. I have listed below the books that I tend to reference most often in my teaching and in my practice. Links to Amazon's listings are provided, not because I specifically endorse Amazon, but they sure are convenient.

• Alistair Cockburn. Agile Software Development: The Cooperative Game. Second edition. (Addison-Wesley, 2006).
• Allen Holub. Holub on Patterns: Learning Design Patterns by Looking at Code. (APress, 2004).
• Andrew Hunt. Pragmatic Thinking and Learning: Refactor your Wetware. (Pragmatic Bookshelf, 2008).
• Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. (Addison-Wesley, 1999).
• Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. (Prentice Hall, 2008).

All of these books are worth reading, but where you start depends on your interests. If you are interested specifically in object-oriented design, definitely start with Holub on Patterns. Clean Code and The Pragmatic Programmer are replete with bite-size tips that can immediately make you a better professional. Pragmatic Thinking and Learning is not about technology per se, but rather it is about how to be a more effective learner. Finally, Cockburn's book is the largest and most academic on the list, but it provides tremendous insight into how one can approach software development methodologies from a perspective that is both humanistic and scientific.

Thoughts on Deus Ex: Human Revolution

I've been playing Deus Ex: Human Revolution, and I had a few game design thoughts to share. This post contains minor spoilers. You have been warned.

A lot of people have commented on the incongruous "boss fights" in Human Revolution, and rightly so. They are quite embarrassing, really. They force the player out of the story, thrusting you through the fourth wall to realize that yes, this is a game, you just finished a level, and so there's a boss fight.

Not that I've scoured the Internet for reviews, but I have yet to see anyone else address the issue of the game's beginning sequences. In a game that prides itself on cleverness of storytelling, how am I supposed to believe that Adam Jensen is actually the head of security in a multinational biotech company? In the first level after the prelude, my boss—the man who runs the company—gives me a choice of exactly one weapon to take with me into an unknown situation. I take it for granted when I have dozens of inventory slots that I can probably carry more than just a short-range stun gun. We can let this one slide because it's a tutorial level, but notice that this is a foreshadowing of the narrative-jarring boss fights: this is a game that knows it's a game and won't let you forget it.

The next scene has Adam Jensen, Head of Security, back in his office building. Once I realized I had an office, I checked my email and found out that someone has been stealing office supplies. So, what's a Head of Security to do? Obviously, the answer is break into some offices and search for clues. Break into offices?! I'M THE HEAD OF SECURITY. I should be able to get into anyone's office, and I sure as hell shouldn't have to CRAWL THROUGH DUCTWORK to do so!

Aha, so the game wants me to learn about breaking and entering in a safe place, where there are no armed enemies. It felt wrong to crawl through ductwork in my own building, especially when every office has windows, through which you can see people chatting in the hallway. So in the spirit of "it's just a tutorial," we could let it go. However, there was one part of this scene that completely snapped me out of the game.

There was money everywhere.

It seems that in the future, people only use gift cards, and they leave them all over the place. It made me wonder, if I were to walk through my building (or crawl through its ample ductwork) and look at my coworker's desks, how many would have hundreds of dollars on their bookcases or in their desk drawers? But it wasn't just the presence of the money that bothered me: it was the gameness of it. I found myself staring at a credit chit, wondering if I should take it or not. More specifically, I wondered, Does this game have a karma system, and am I going to lose morale or reputation for taking this? See, this stuff wasn't credits or money at all—it's just a mcguffin that I can collect. And because it's there, I need to take it, because I know how the economics of these games is balanced: if you want to get the best goods, you need to be an explorer and take everything you can find. I'm not taking cash from my coworkers. I'm just collecting arbitrary units that I can use to get the bigger gun I know I'm going to need, because the only other thing I know about the game at this point is that there's going to be rough boss fights. (Thanks, Internet!)

I finish exploring every nook and cranny of the building that I can access without leveling up my hack skill. After all, I don't want to actually hack my own building's security system, I just want to explore its ductwork. The next mission has me leaving the building and getting out into the streets of Detroit. (The Assassin's Creed developers know how to make a city feel crowded; Human Revolution pays homage to the empty streets of the original Deus Ex.) One of the first places I visit is a weapons dealer in an abandoned gas station. I am Adam Jensen, Head of Security, and I'm buying a tranquilizer rifle with stolen money from a guy in an abandoned gas station. I cried a little and almost stopped playing, but at this point, I haven't seen one of those famous boss battles yet, so I felt obligated to carry on.

They did do a nice job allowing for multiple solutions to problems, and I did have fun playing the game. I'm going to jump ahead to the ending. The spoilers get more serious here, so be warned.

Ninety percent of the story involves Adam looking for Dr. Reed. Whether it's love or curiosity doesn't matter: it's Reed that he's after. You see her for a brief moment, right before going into the endgame. If you've read this far in my post, then you probably already know that the ending is determined solely by one decision at the very end of the game. This was the worst part of the original Deus Ex, that everything you did amounted to nothing except for your very last decision. Again, Human Revolution pays homage to the wrong part of the original. This one was even worse, though, since what screamed out to me as an obvious option was completely missing. All I wanted to do was stop the transmission. That's it. Stop the transmission, then go get picked up by Malik, go find Reed, and talk to her. I don't want to send Crazy Cripple Guy's message, or lie about terrorists, or something else I don't care about, and I certainly don't to kill myself and everyone else that I just painstakingly avoided killing.

The original Deus Ex ended with you having to chose one of three options, none of which were appealing, but all of which were inevitable. This one felt completely contrived, as though the designer just couldn't wait to show me B-roll of starving kids in Africa. I guess I am the sap. I actually empathized with Adam, and I actually wanted to know why he cared so much for Reed, and how she really felt for him. I thought they would come to some understanding about where Adam came from. The character development in this game was awfully shallow, but I fell for it, because I play these games for the RP part of RPG.

In conclusion, my recommendation is, after finishing Human Revolution, go play The Missing Link DLC. At first, I was upset to hear that some really good content was left of the game and released as DLC; I think this is a bad direction for games, especially for elements that happen chronologically in the middle of the main story. However, in this case, it was a blessing. The Missing Link was quite fun, with interesting levels and much more believable and interesting characters. When Missing Link ends, you can pretend that you don't actually know what happens next, and your imagination can then give you a satisfying conclusion.

CS Ed Week: Reflections on a busy week

Once again, we've reached the end of CSEdWeek, and I'm pushing to get this post in before it's over.

I attended two blogworthy public events this week. On Monday, I went to the Indiana Historical Society's Annual Founders Day Dinner and Awards celebration, along with my collaborator Ronald Morris and our Dean, Michael Maggiotto. The College of Sciences and Humanities at Ball State University was awarded the Outstanding Project of the Year award for Morgan's Raid.

Among the other recognized individuals and organizations were eight Centennial Businesses, Indiana companies celebrating 100 years of operation. Not surprisingly, none of these were software development companies. However, I'm willing to wager that all of them now rely upon software for their daily operations. In 2111, will they be looking back at 100-year-old software development shops?

Wednesday was the BSU Building Better Communities Project Showcase, where about twenty student teams showed how they worked with faculty mentors and community partners. Several of my students were there to demonstrate the Digital Archaeology Simulation project. A poster provided the background and rationale for the project, and the software is still under development by Emerging Technologies. A prototype was available, and while I didn't take the opportunity to run the latest build, several passers-by told me that they were quite impressed. Ball State University President Jo Ann Gora spent a few minutes with members of the team to talk to them about their work—a great opportunity for the students to show some of their best work (even if the photo is rather poor).

This week was also the final project presentations in CS222: Advanced Programming. Each team of four had to pitch a project and complete it in six weeks, with two three-week milestones. Several of the teams impressed me with their hard work and dedication, investing significant amounts of their own free time in order to create the most impressive systems they could.

Rather than make any grand conclusions, I think the best way to close this post is to say that I have a great job. My students rise to the challenges I set before them. They appreciate learning how to learn, and they respect the fact that I respect them. We all get a bit stressed this time of year, but it feels good at the end of a busy week to reflect on all the great learning experiences I have had with my students this year. Thanks to my students for sticking with me, for trusting me even when my methods are unconventional.

Happy CS Ed Week.