Paul Gestwicki's Blog

Visual representations of team prototyping efforts

2012-02-05T10:28:00.000-05:00

The most important task for my VBC students during the first two-week sprint was game prototyping. We had six themes in which we worked: geology, biotechnology, collecting/museums, children making a difference, trains, and dinosaurs/paleontology. Rather than dictate specific targets for each theme, I decided to allow them to explore any themes they like, using their preferences to gauge where they are finding interest and inspiration. The best of these would be subject to analysis by the whole team, and we would choose a small subset of those to move forward into the next sprint.

One of the students suggested using a table to track progress, similar to the task board we are using as part of Scrum. Based on this sound advice, I used the day before the start of the sprint to draw the table shown below.

Prototype Development Board, version 1.0

The rows represent the themes, and the columns represent phases of design: planning, production, testing, and done. In this case, "done" meant ready for more careful evaluation by the whole team. The idea was that each student would write his or her name on a sticky note and march it across the board as it is developed. After a few days of prototyping, the board looked like this:

Prototype Development Board, version 1.1

Then the question arose: what to do with a game that, after testing, needed more work? I advised the student to simply move the sticky note to the appropriate column on the left, and that this was an expected part of the process. It hit me like a ton of bricks: the tabular format assumed a left-to-right progression that was wholly incompatible with a cyclic design process. I yanked all the sticky notes from the board and revised it into the following:

Prototype Development Board, version 2.0

Now, game concepts start in the upper-left ideate phase and progress clockwise through build and playtest. After testing, they either go back into ideate or, if they are abandoned, they end up in the graveyard. This presentation clearly captures the cyclic nature of design thinking. Topologically, it's still a table—you could cut it at any of the red lines and spread it into a conventional rows-and-columns approach—but the visualization of the data makes all the difference. Later, we added a shelf (as in "put it on the shelf") for those concepts that were complete enough for this first pass, those that could be evaluated by the team at the end of the sprint.

Prototype Development Board, version 2.1

At the end of the sprint, the 13 students had created 29 prototypes. We spent the afternoon before the end of the sprint playtesting thirteen candidate prototypes. In this case, a simple tabular view was used to list the games, their creators, the number of players, and whether or not any given student had tested it.

In the Sprint Review meeting, seven of these were discussed as fitting within our mission and scope. For the record, the discussion of each candidate should have been timeboxed: sitting in comfortable chairs around a fireplace can get people talking longer than necessary to make a decision. Be that as it may, for the first pass, each student was asked to mark which game was their first choice for moving forward.

With one exception, the students clustered around three ideas. The one outlier consented to abandoning her first choice, and so with just one iteration, we had selected our three to move forward. In the subsequent Sprint Planning meeting, we rearranged personnel so that each team had a mix of students from Computer Science and Arts & Humanities. As I write this post, we are midway through Sprint 2, and the students have explored many variations on the core mechanics of the three prototypes.

Agile, Commitment, and Interviews

2012-02-02T13:07:00.000-05:00

A few weeks ago, one of my VBC seminar students had a casual "pre-interview" with a human resources specialist. The conversation went well, and so they began discussing a time for a formal on-site interview. My student reported that almost any afternoon would work, but mornings were not ideal due to our Daily Scrums, and every other Monday and Friday were out because these were Sprint Review, Sprint Retrospective, and Sprint Planning meetings.

If I were a human resources specialist from an agile software development company, this would knock my socks off. Not only does this student know the principles of agile software development and Scrum, the student also recognizes the critical importance of these meetings to effective collaboration. When I heard this story, I swelled with pride; I hope the student is likewise rewarded with a good offer!

Auralboros and Global Game Jam 2012

2012-01-31T15:13:00.000-05:00

On January 27–29, six of my seminar students and I participated in Global Game Jam 2012. For those who don't know about the annual event, it is a 48-hour period during which people from around the world collaborate to make digital or analog games. All of the artifacts from the jam are made available under a Creative Commons BY-NC-SA-3.0 license. The closest location to us was in Indianapolis, but we decided to make the trip to Columbus. This was partially to avoid the congestion due to the start of the pre-SuperBowl parties but also to give us some geographical change: putting ourselves in a completely new place allowed us to treat the whole event as a kind of retreat.

After a fun pre-recorded keynote and some comments from game designer, author, and GGJ organizer Ian Schreiber, the theme was announced:

The GGJ2012 Theme

I love the fact that the theme is a picture with deep symbolic and historical meaning. This is, of course, an ouroboros, a word which I only know as a player of Betrayal at House on the Hill.

After everyone had a chance to think for a bit, people began pitching their game ideas. Some were closely tied to literal interpretations of the theme and others to the symbolic meaning of the theme. Many discussions began with the theme but then wandered away. I found the creative challenge to be in capturing the spirit of the theme in a game, especially with respect to the combination of endlessness across generations. Based on this, I pitched an idea for a game with rich audio experience. For the next 42 hours, I worked with Ryan Thompson on what would become known as Auralboros.

Auralboros Logo by Rebecca Austin

You can play the game on the Web, or you can go there indirectly through its GGJ entry. Note that it requires Unity Web Player, which is only available for Windows and Mac OS X, unfortunately. I encourage you to play the game before you read on, lest I give away some of its secrets. There are not many secrets, so you can understand why I'd want to keep them safe.

We decided to use Unity very early in the project. We knew that this would let us easily produce a game that could be hosted on the Web. We also figured that it would be easy to add pizzazz once the core mechanics were done. We invested several hours into the core gameplay sans audio, and it wasn't until midday on Saturday that we realized that Unity's audio API is practically non-existent. To be clear, you can very easily play back audio—including 3D audio—within Unity, but it does not support synthesis. In the end, after painful struggles with my laptop to try to get full-duplex audio to work, we ended up using MuseScore to drop notes onto the staff and then export WAV files. I had hoped to test the game with both chromatic and pentatonic scales, but we never got that far.

I had been looking for an excuse to practice some of the tips in Clean Code, but the truth is that I don't program anywhere near as much as I would like to. Working with Ryan provided a great opportunity. This was also my first time pair-programming. I've been having my students pair-programming for years, but I've always been forced into a "mentor" role rather than a "peer" role. For Auralboros, Ryan and I were simply working together as a team, and I'm happy with the results. He caught a few of my errors, and I caught a few of his. I definitely took the lead on some of the more abstract software design ideas, but none of them were so wild as to be outside of his understanding once we had them down.

We had the core game experience working by early Sunday, and so we turned our attention to beautification. I knew from early in the design that I wanted to have feedback based on a player's matching their own sounds. That is, Auralboros does not force you to do anything specific with it, but if you make yourself a rhythm game, then you get positive feedback. Our first attempt involved counting right and wrong notes, but after this failed, I realized that what we needed was a physics simulation. We created a "gravity" value as a constant downward acceleration. Each time you get a note right (i.e. you hit that key again when its cube is at the top of the screen), you get a boost to upward acceleration. This affects a velocity, which in turn affects a point. We map the point first through a series of greyscale values for the background, and then for increasing opacity on the two feedback orbs. After capping acceleration and velocity, this worked like a charm. Along the way, Rebecca Austin joined our efforts, designing our logo and textures on the two feedback orbs.

The Auralboros Team

For the most part, we kept to the headphones as we developed the game. It was always fun when someone would ask to see the latest build, leading to strange sounds and usually laughter filling the room, though I don't blame anyone for being a bit miffed at the distraction...

Josh's reaction to Auralboros during GGJ, as captured by Rebecca Austin

A few hours into development, Ryan and I started using Trello to manage our tasks. I had read about this tool and recommended it to others, although I had never quite found a use for it myself. This was a perfect application, and it helped that sharing between two Google Accounts was seamless. We had three sections to our board: defects, for those things that were broken; to do, for features we wanted to add but could live without; and paulish for ideas that would make the player experience more glossy. There was only one to do item that we didn't have time to add, and that was having the cube halos fade in and out based on distance to the apex. We finished our game about an hour before the deadline, so we may have been able to squeeze this in, but it would have meant re-exporting and uploading, and that was just not worth it. The GGJ servers were getting hit pretty hard.

I think it was good for all of us Ball State folks to have a classic R1 campus experience as well. We were at two different buildings for the event. On Friday, Parking was hard to find, and we walked around the building once due to poor signage. It happened to be a teaching building, and it was cluttered and musty. The classroom in which we met had grimy walls and inadequate blackboards. We did appreciate that we could lean back in the chair-desks, which would make it easier to rest during boring lectures. The next day, we were in the OSU Union—not a teaching space, but a place for events, meetings, and chats with alumni and benefactors. It was absolutely gorgeous, my favorite part being the totally gratuitous projector-that-descends-from-the-ceiling in our meeting room.

Special thanks goes out to Brian Orchosky, the site coordinator: if you see him, buy him a drink.

Site coordinator Brian Orchosky

Global Game Jam 2012 was the largest game jam ever, and it was great to be a part of it. You can check out all 2000+ games at the GGJ Web site. Note that you can search by site, so you might want to take a look at the other games created in Columbus or in a city near you.

The Ball State University contingent in Columbus at the end of GGJ 2012

It was a great event, and we all enjoyed the weekend together. Thanks to Phil and Kristen for stopping in to see us, even if you couldn't participate in the whole jam. The only real downer was that when I got directions to the Jeni's Splendid Ice Cream on our route home, it turned out to be the one in the North Market, which was closed by the time we got there. I suppose we'll just have to go back sometime.

135 Hours

2012-01-30T12:02:00.001-05:00

Last Friday marked three weeks at the Virginia B. Ball Center for Creative Inquiry. The students and I have been working together in roughly an 8–4 schedule. In the first week, I ran a workshop on games and learning, and the next two weeks were run as a Scrum-style sprint. At the end of these three weeks, the students have produced some good prototypes, sufficient for us to have chosen three to carry forward; more importantly for the learning process, they produced many, many more prototypes that are not being carried forward.

The students worked roughly nine hours a day for fifteen days. Given that a fifteen-week, three-credit course should involve nine effort-hours per week, the students' effort has been equivalent to a complete conventional three-credit course. Unlike a conventional course, my students have had practically limitless space, budget, and mentor availability. The only structural benefit that a longer class would have is more calendar days to consider the concepts, but I posit that the number of distractions that occur in a longer period far outweigh the benefits. Therefore, the result of my students' effort on Friday in terms of both understanding and artifact production can be considered the best one could possibly hope for in a three credit-hour course. Yet, we still feel like we have barely scratched the surface of the conceptual space: the prototypes we created are still very rough and will require significant iteration prior to engaging in final production.

This should not come as a surprise to anyone who understands game design and learning: it's only been three weeks! One would never expect that after a three-week intensive study, a novice would transform into a great painter, or be able to work as an architectural consultant, or to commercially compete in any creative design field. Three weeks of intensive study just gets you to the point where you can start to understand how far down the rabbit hole goes, how much there is to understand and how much practice you will need to advance.

This stands in stark contrast to the pressures of immersive learning, in which we faculty are asked to guide students through a process to create useful products for or with community partners. Keep in mind that I am an advocate of immersive learning, having written several papers and a book chapter on its benefits to Computer Science and interdisciplinary education. However, I also know that if we had taken any of these prototypes and started production halfway into our three weeks together, it would have been painfully premature. It's true that we could have made something by switching all our resources to production rather than understanding, but it certainly would not have resulted in anything academically substantial. We know that we can make a Bejewelled clone and slap a quiz on it, and many people will applaud this as "educational game design," but we're trying to do something much more significant.

I am eager to see how the team advances through this next sprint, as our focus narrows and we collaborate on three design. The goal is that two weeks from now, one of these will have risen to the top, and we can move into production, with executable releases every two weeks thereafter.

Moving in

2012-01-16T08:34:00.001-05:00

The week before the semester started, I moved into my temporary office in the Kitselman Center. I found a department systems administrator so that I could borrow a cart to haul my workstation, books, plants, and miscellany from the fourth floor down to my wife, waiting by the loading dock with our van. I took the cart from the third floor up the elevator to the fourth and loaded it up, and when I returned to the elevator, I found this.

Here's the whole scene.

Unsure of what to do, I walked downstairs to tell my wife we would be indefinitely delayed. On the ground floor, the elevator doors were open, and there was a technician standing atop the elevator car, tinkering with the system. He told me it would be quite some time before he was done, but he offered to help me if my need was urgent. In about fifteen minutes, he was able to bring the elevator up to four and back down for me. I've never had any interaction with Murphy Elevator Company technicians before, but this gentleman was helpful and polite, and we had a nice chat about elevator maintenance on the way down.

My wife helped me load the van, and we drove the ~2.5 miles to the Kitselman Center to unload. Here's a glimpse of my office for this semester.

Not too shabby. To the right is a gas fireplace. Yes, that's right. On Friday, I walked to work in the snow, and when I got there, took off my boots and set them by the fireplace. In my office.

Anticipating tomorrow

2012-01-08T09:05:00.003-05:00

This Spring semester, I am a fellow with the Virginia B. Ball Center for Creative Inquiry. Yesterday I made public a blog that my students and I will use to write about the experience, and my post there explains the context. In a draft of that post, I had two paragraphs about how I got here, but this topic seemed more appropriate for this blog. The VBC blog is for the project; this one is for me to reflect. So, without further ado, here's a reflection of how I got to this point as a Computer Science professor at Ball State.

My first Summer here, I led a graduate seminar on game engine programming. I have always been one to tinker with game development ideas, though at that point, I had not finished and published any game-related projects. I was and am still interested in object-oriented design, especially design patterns, and so I used the Summer to investigate the relationship between classic software design patterns and game development. Looking back, this was my first experience with pure project-based learning, although I would not have known to call it social constructivism at the time; my intuition told me that if I got a bunch of interested grad students together for a few weeks with an interesting topic, we would all learn something. And we did. In fact, it was this Summer that I developed the essential components of EEClone, my case study for design patterns in games.

I continued this line of inquiry with a group of undergraduates and my colleague, Fu-Shing Sun. Each of the students developed their own game based on the design patterns that I introduced. I am still proud of the systems that these students created. Although the game designs were primitive, the software architectures were beautiful. Of course, software architecture was the focus of the course, so this is to be expected.

The Honors College was supportive of our desire to investigate multidisciplinary game design and development. For two semesters, Fu-Shing and I team-taught a pair of courses, one on game design and one on game programming. The first semester, we were assisted by graduate student Ben Dean, and so we were able to create three small multidisciplinary teams, each mentored by one of us. The three games created out of this experiment were quite good, capable of being polished and released although none of the students were interested in continuing with them past the end of the semester. The other semester of this experiment, we created one larger team working in two parallel units: design and programming. This allowed us to focus each unit's attention on mastering their side, but the results were predictable in retrospect. Because the groups were working separately, there were several communication problems, and no amount of content expertise can overcome the challenges of bad communication patterns. It was a good learning experience for all involved, but the quality of the end result did not scale up with the number of people on the team.

These two semesters provided me with a great experience, and we took the opportunity to write a few papers about our experiences. My future direction for this line of inquiry was unclear, but I knew I wanted to be more involved in both the design and development sides of the class. It was around this time that I met History Professor Ronald Morris, who convinced me that there were ample opportunities in history education game development for elementary school students. This led to the Morgan's Raid project, which I have blogged about extensively; the postmortem is a good starting place if you're new here. As I've mentioned before, the Spring semester of Morgan's Raid—during which I led a team of ten students in a studio learning experience of finishing the game design and development—was the most rewarding activity of my professional career.

That's my reflective summary of how I got here. Many semesters, proposals, and research papers later, I feel as ready as I can be to mentor my team this Spring. I feel like all of these previous experiences have led me to the VBC, a dramatic next step for my teaching and my scholarship. My mild nervousness about an untested team is tempered by the fact that I know half of them quite well, and the rest have shown themselves to be bright, polite, and motivated students. I have planned a workshop on games, fun, and learning for the first week of the semester, and I am eager to see how the team engages with the readings, discussions, and activities. On Tuesday, we meet with our community partner, the Indianapolis Children's Museum, to sort out the details of the project with respect to schedules, expectations, and capabilities. This will help direct the discussions through the rest of the week, and after that, I switch from teacher to coach, handing the reins to the team of students.

Board games with young kids

2012-01-05T19:41:00.002-05:00

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

2012-01-05T10:19:00.001-05:00

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

2011-12-22T12:54:00.000-05:00

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

2011-12-22T11:28:00.000-05:00

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

2011-12-19T09:44:00.000-05:00

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.

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

2011-12-12T20:04:00.000-05:00

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

2011-12-09T15:06:00.001-05:00

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.

With great power comes great responsibility

2011-11-30T13:53:00.001-05:00

This was discovered in RB369, the Computer Science lab, and shared on the department's Facebook page.

I wonder if I can include this as a student evaluation in my promotion and tenure materials?

All the UML you need to know

2011-11-14T15:25:00.001-05:00

Each semester, when I teach CS222, I give a one-class lecture on UML class and sequence diagrams. It always goes the same: I introduce some ideas, then give the students some time to draw some diagrams, and I critique them. It works well, except for the lecturing part. That part is boring, for me and for the students.

This year I am trying something different. I have created a Web site off my BSU space called "All the UML You Need to Know." Actually, I've only half-created it. We already discussed sequence diagrams in class earlier this semester, so I didn't take the time to write that section yet.

I sent out the link to my students earlier today. Tomorrow, we'll talk about class diagrams, and I will direct them to this site as a resource as they play with the ideas. It took about eight times as long to write as it does for me to talk through it, which is actually not as bad as I had feared. Hopefully this will save me time in the long run, but more importantly, it will give the students accurate notes about the parts of UML I expect them to know.

Social networks, fairies, and Club 369

2011-11-11T10:59:00.001-05:00

One of the CS222 project teams is working on Club 369: The Game. "Club 369" is a reference to the Computer Science undergraduate lab, RB369, and the camaraderie that the space affords. The game is a Computer Science quiz constructed of multiple-choice questions.

On Thursday, the team gave their milestone presentation. Here's a screenshot of their executable release.

Club 369: The Game, Milestone #1

That guy on the bottom-right is "The Dr. G. Fairy". Let's take a closer look...

The Dr. G. Fairy

Clicking on him removes two of the incorrect choices, leaving the player with a 50/50 chance if they guess. Needless to say, this presentation got quite a reaction from the other students. When a student asked, incredulously, "Why?" a team member responded, "He's Dr. G. He helps you learn Computer Science." This is the nicest complement I've received in some time!

After class, one of the students posted the picture to the Ball State Computer Science Facebook Group, where it became a hit. It may seem a bit silly, but as I see it, it's a great success for the department. We created the Facebook group to help foster a sense of community among our students and alumni, and we've had some luck with members sharing informational links, job opportunities, and the like. The fact that students feel they can share this kind of fun content as well shows that we have succeeded in our goal. (I had to do a bit of legwork to understand the Butterfree and Hey! Listen! references in the comments, but this made it even more fun for me.)

Of course, I immediately changed my Facebook profile picture to the Dr. G. Fairy. This led some old friends to reminisce about the classic "Get Paul some shirts with color" Flash animation—a reference to my proclivity to wear black when playing at Higher Grounds Coffeehouse. I think we all assumed the animation was lost to the ages. My clever and creative friend Matt was able to find the old image and recreated the animation with a brand new feature.

Rubric-based self- and peer-evaluation on team programming projects

2011-11-11T09:20:00.001-05:00

I have written before about grading rubrics, and I am taking this opportunity to share some of my recent developments here. In my game programming class (CS315), I have eleven students working together on one project. We're using Scrum, and it's still going well. The early part of the semester was ungraded, formative, small-project work, and I found myself needing a way to assign grades to the students. It may be worth mentioning that I don't actually want to assign grades to them, but it is a requirement of the course, and so I must do it responsibly.

I happened to stumble across a rubric I created in 2008, before my blogging days, while I was cleaning up my Web space. As I recall, this was an amalgam of several other rubrics I had found on the Web with an ounce of invention. This was my inspiration to create the following rubric:

	3	2	1	0
Commitment	Attended all scheduled team meetings or notified the team of absence.	Missed team meetings, with notifications, with enough regularity to be problematic.	Missed one or more team meetings without notifying the team.	Regularly missed team meetings without notifying the team.
Participation	Contributed to sprint planning, sprint review, and sprint retrospective meetings.	Did not contribute to one of the following: sprint planning, sprint review, or sprint retrospective meetings.	Did not contribute to two of sprint planning, sprint review, and sprint retrospective meetings.	Did not contribute to any of sprint planning, sprint review, and sprint retrospective meetings.
Communication	Clear standup reports on what was accomplished, what is planned, and identification of impediments, to allow the team to continue to make progress.	Some unclear standup reports that inhibit team progress.	Regularly unclear standup reports that inhibit team progress.	Did not give standup reports.
Technical contributions	High quality technical contributions that facilitate success of the team.	High quality technical contributions that do not directly facilitate the team's success.	Low quality technical contributions that frequently require redress by other team members.	Low quality technical contributions that inhibit success.
Attitude and Leadership	Listens to, shares with, and supports efforts of others, and actively tries to keep the team together.	Listens to, shares with, and supports the efforts of others.	Frequently fails to listen, share, or support teammates.	Displays an antagonism that inhibits team success.

I created this after the team's first sprint, and parts of it are reactions to problems the team was having. For example, in the team's first sprint retrospective, they identified that many had spent inordinate time on aesthetic issues that were unrelated to the user stories. Hence, there is a distinction between those technical contributions that facilitate success and those that do not. Note that the numbers across the top relate to my triage grading approach; some day I will write a blog post about my experiences with it, but for the time being, suffice it to say A=3, C=2, D=1, F=0.

I shared this rubric with the team during Sprint 2, and at the end of the Sprint, I asked each person to do a personal evaluation. This was designed as a formative evaluation for the student as well as a trial run of the rubric. From reading the students' self-evaluations, I think the instrument worked as intended, and we're going to do self- and peer-evaluations at the end of this sprint.

In my other course (CS222), students are working in teams of four on six-week projects of their own design. They just finished their mid-project milestone presentations, and I've modified and distributed the rubric to this other group as well. I've highlighted those cells that have changed.

	3	2	1	0
Commitment	Attended all scheduled team meetings or notified the team of absence.	Missed team meetings, with notifications, with enough regularity to be problematic.	Missed one or more team meetings without notifying the team.	Regularly missed team meetings without notifying the team.
Participation	Contributed to project planning, implementation, testing, and milestone presentations.	Did not contribute to one of the following: project planning, implementation, testing, and milestone presentations.	Did not contribute to two of the following: planning, implementation, testing, presentation.	Did not contribute to three or more of the following: planning, implementation, testing, presentation.
Communication	Clear reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress.	Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress.	Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress.	Communication patterns directly disrupt team progress.
Technical contributions	High quality technical contributions that facilitate success of the team.	High quality technical contributions that do not directly facilitate the team's success.	Low quality technical contributions that frequently require redress by other team members.	Low quality technical contributions that inhibit success.
Attitude and Leadership	Listens to, shares with, and supports efforts of others, and actively tries to keep the team together.	Listens to, shares with, and supports the efforts of others.	Frequently fails to listen, share, or support teammates.	Displays an antagonism that inhibits team success.

These students are not using and are not familiar with Scrum, and so the Scrum-specific references needed to change. I am not that happy with the articulation of participation above, in part because we invested a lot of time on test-driven development, and I fear the students will be confused about separation of testing and implementation. The "communication" entry is clearly influenced by the idea of the Daily Scrum, but I have not previously suggested this particular reporting strategy to the students. My hope is that by asking them to conduct rubric-based self- and peer-assessments, they will gain some insight into better ways to organize themselves. As with the game programming students, I am using this first pass as a formative assessment, and also as an instrument to help me identify teams that are having problems with team members—an unfortunate but oft-inevitable situation.

The students in CS222 had their first group experience with rubric-based evaluations this week when they evaluated each others' milestone presentations using this instrument:

Presentation requirement	Satisfactory (3)	Probationary (2)	Unsatisfactory (1)	Unacceptable (0)
Executable release	Stable and appropriate demo of executable release	Unclear demonstration of stable executable release	Unstable executable release	No demo
Milestone #1 Estimate	Clearly met milestone estimates	Clearly met a reasonable subset of milestone estimates	Did not meet an adequate subset of milestone estimates	Progress on initial estimates was not addressed
Milestone #2 Estimate	Clear presentation of well-articulated estimates for next milestone	Clear presentation of poorly-articulated estimates for next milestone	Unclear presentation of poorly-articulated estimates for next milestone	Milestone #2 estimates not addressed
Software architecture	Good presentation of reasonable software architecture	Decent presentation of reasonable software architecture	Unclear or awkward software architecture	No presentation of software architecture

I printed these on small slips of paper. On Tuesday, we had four presentations, so I instructed the students to pick up four slips as I talked through the structure and purpose of the rubric. On Thursday, we had five presentations, so I left the slips in the same place in the back of the room and I put on some mood music.

I was a little disappointed that none of them stopped to tell me how incredibly clever this was.

Morgan's Raid on CD

2011-11-06T20:58:00.001-05:00

We recently received a request to make Morgan's Raid available to a school that has blocked Internet connections from its lab machines. Morgan's Raid was built for distribution via Java Web Start (JWS), which simplifies the process of dealing with native libraries. However, as the name implies, the technology was designed for computers with Web connections. Distributing as an executable jar is not possible because they do not adequately handle native libraries.

The JNLP file contains all of the configuration information for JWS. This includes codebase, through which JWS determines where to find referenced resources. The Morgan's Raid codebase points to the server that hosts the jar files, for example. Turns out that if you leave out the codebase, it will default to the same path as the JNLP file itself.

My next step, then, was to revise the Morgan's Raid JNLP file for local files. I created a CD containing all the requisite jar files and the revised JNLP file. Running the JNLP file off of the CD almost solves the problem. The game runs, and it creates a desktop and start menu shortcut in the process. However, it also records the fact that the jar files came from the optical drive. As a result, the game will then only run with the CD in the drive, even though all the jars have been copied to Java's cache: JWS still tries to check the codebase to see if there's any changes to the files or configuration.

The problem is easily solved by having the user copy the CD contents to any folder on their hard drives and running the JNLP from there. Now it's this path that is recorded by JWS, so using the desktop shortcut or start menu shortcut will happily run the application locally. This gets the desired result that I can hand someone a CD, and they can put it on as many machines as desired, without my having to fiddle with installation software beyond JWS. (I guess that changing the location of those files would break the installation, in the same way that removing the CD did before, but I did not verify this.)

With my CD experiments successfully concluded, and after a little help from my department's friendly system administrators, the result looks like this:

I found it deeply satisfying to hold this disc. Physical media doesn't change the existential state of the software system, but there's something about holding this disc in my hands that made the software more real.

As I was printing the CD, a sysadmin asked, "Does it have to be on CD?" Her reason for asking was that she had blank white DVDs, on which the printed label would be more crisp, but I thought she meant, "Can't it be on something other than a disc, like a thumb drive?" I laughed aloud when I realized that I had never considered anything but an optical disc for this project, because, you know, software comes on discs!

Chasing Dragons

2011-10-31T21:46:00.001-04:00

A few days ago, my wife and I watched Get Lamp, a documentary on the rise and fall of text adventures and the persisting genre of interactive fiction. I had heard about it on Richard Bartle's blog and have been eager to watch it. I grew up playing text adventures on my C64. Although I spent a lot of time reading Byte and Compute magazines—mostly typing in BASIC programs and reading advertisements for games, as I recall—I did not have a larger context to understand the industry and the personalities behind it.

I found the documentary fascinating, but I'm not sure how strongly I can recommend it to those who didn't cut their teeth on text adventures. The documentary assumes a certain amount of tacit knowledge: how could a viewer appreciate the discussion of mapping if they had never been in a maze of twisty little passages, all the same? I'll definitely bring it up for a potential movie night next semester when I'm at the Virginia Ball Center for Creative Inquiry.

The documentary consists almost exclusively of interviews, and one of the interviewees was Chris Crawford. I had previously only known him by reputation as a respected game designer and as the author of The Art of Computer Game Design. I enjoyed his interview in the documentary as well as the extended interview in the DVD extras, so I decided to read more about him.

Of course, I turned to Wikipedia, on whose page there is a section devoted to Crawford's Dragon Speech. Wikipedia's summary piqued my curiosity. Thanks to the wonder of the Internet, this 1992 speech is available on YouTube, despite its having been given a year before Mosaic ushered in the World Wide Web revolution. I've embedded part one here; parts two through five should come up as recommended links after.

This goes immediately into my list of great presentations (which someday needs to migrate from my old blog to this one). Crawford is clearly a master of the topic and has carefully crafted the presentation. I could go on about the specifics, but really, you should just take some time to watch it. I am envious of the opportunity he had to study under another one of my heroes, Alan Kay. I'd love to have a day to shadow either of these visionaries, to get a better sense of how they see the world and of what drives them.

Crawford is passionate about his work, and it's his well-calculated passion that helped me to understand that this presentation isn't really about games at all. It's about dreams. It's about working to identify what it is that you really want, and then consciously and intentionally deciding to pursue it, even if it means making painful decisions.

Presentations like this make me uncomfortable, but that's a good thing. They induce introspection, resulting in an honest evaluation of what I am doing and where it is leading. I feel like I am in Crawford's six years at Atari: I'm working diligently on what seems right for now, but every now and then I see the shadow of the dragon.

Notes from the Indiana Video Game Developers' Business/Game Design Panel

2011-10-23T20:06:00.001-04:00

Yesterday, I went down to Indianapolis for the Indiana Video Game Developers Business/Game Design Panel, hosted by the Independent Video Game Developers Association and the Indianapolis Chapter of the International Game Developers Association. The bios of each of the panelists are available online, so I won't summarize who they are here, but it is noteworthy that there was a great mix of expertise, including those interested in corporate branding, serious games, independent self-funded development, and even an IP lawyer. One of my students was there with me, but it was a great discussion and I wish more could have come. I will use this post to share some of my notes, both for my own use and to share with those who could not be there.

The topic of iterative design came up several times, with the folks from Studio Cypher especially advocating for physical prototyping. Most of the panelists strongly advocated for focus groups throughout the development of a game. I was tempted to ask about specific methodologies: no one mentioned "agile" by name, but the spirit of it was strong. I ended up holding my question, in hopes that I could follow up with some of the panelists at a later date to discuss their methodologies more closely, perhaps even in a research context.

A few panelists mentioned making games for children and using children in their focus groups, so I asked how they went about recruiting children, especially since some were adamant about needing NDAs for focus groups. Two out of the three suggestions were the same approaches I have used: friends/family and schools. The other group they mentioned was the Girl Scouts, which I had not considered. They also mentioned that research firms could be hired, at a high price, to do these things for you. That's another one I had not thought of, but all agreed that this was likely not worth the price.

There were a few questions about how to choose technology for projects, and the panelists answered with a predictable and appropriate, "it depends." The panelists observed that all programmers want to write their own game engine, but that this is impractical unless it is one of the team's core competencies. This matches advice I've heard elsewhere, but I get the impression that the younger members of the audience had not thought about the issue before. When it came down to what technology was being used, there was glowing praise for Unity—even the teams that weren't using it seemed to wish they were. This made me feel good about getting my own game programming students this semester exposed to it.

While there was a lot of love for Unity, the relationship between HTML5 and Flash was mixed among the panelists. The consensus seemed to be that some clients had started asking for HTML5 games, but not all. While most current Web-based games were still in Flash, there was an expectation that HTML5 would be escalating quickly due to its being backed by such large corporations.

The highlight of the panel, for me, was actually something shared by a non-panelist. It was a question I was going to ask as well, but Andy Harris beat me to it. It sounds like he's in the same boat as I am, where he is constantly asked by middle and high school students what they should do to become a "game designer." When I am posed this question by prospective students, I explain, verbosely, the relationship between video game design and programming, the history of the two, and the transfer of skills among them. Andy had a much more memorable and clever explanation that, if you want to be a game designer, you write the code or you write the check. All the panelists agreed. This was great to hear, but I couldn't help but feel a little bad for the handful of young aspiring artists in the room who clearly had not done their homework along these lines.

The importance of a portfolio was mentioned, and after a question from the crowd, the panelists clarified that a portfolio is as important for programmers as for artists. One panelist recommend grabbing a library like Flixel or FlashPunk, then creating ten games with them, each one exploring a different aspect of game design such as pathfinding or AI. This would provide you, as a programmer, with evidence that you have the range of skills required. This sounds like a great break project to me!

The panel had been advertised as running from 1:00 to 3:30, but at 3:30, it was only an intermission to be followed by some other activities. Looking over the handouts, it looks like one of the activities was to be drinks at MacNiven's to talk about the IGDA, which would have been fantastic. Alas, I already had plans to return home for dinner, and so I had to step away. I am glad I was able to attend the panel, and it was great to see some of my colleagues whom I don't see very often. Next time, I'll try to keep time for a pint in my schedule!

DeMillo wrote this post for me already

2011-10-19T09:24:00.000-04:00

I have been reading and enjoying Rich DeMillo's new book, Abelard to Apple: The Fate of American Colleges and Universities. I am planning to read the final chapter tonight and had intended to post a summary afterward. However, on his innovate-edu blog today, DeMillo posted his comments to the Joint Education Subcommittee of the Georgia Senate, and these provide an excellent summary of the book. This link will get you there.

Computer Science: It's not just for dead women

2011-10-07T11:12:00.000-04:00

How ironic that today is Ada Lovelace Day, as I just took a picture of her out of a Computer Science Department display case this morning.

Since I came to Ball State, we had a display case that showed four images of women in computing. I did not snap a picture of the display case, but here are the four individual images.

On one hand, one could argue that these images show that women can succeed in computing. On the other hand, I think there's a good chance that a modern young woman who walks by these will come to the conclusions that women could succeed in computing, ... back before color photography and pants. That's not very relevant to a generation that has grown up with the Internet, social media, games, and service learning, four factors that have been identified that get girls interested in pursuing Computer Science.

I got the blessing from my department to update the display case, which now looks like this:

The plaques on the left and right are awards from the 2008 and 2011 CCSC:Midwest Programming Competitions, in which teams from Ball State placed second and third, respectively. In the middle is a research poster put together by the students who were involved in both the Morgan's Raid and the Digital Archaeology project. The poster describes how we used Scrum and principles of agile software development and the lessons learned in the process.

One wouldn't know to look at the plaques, but both teams comprised of two men and one woman. The genders of these students was irrelevant: their success speaks for itself. Taking a closer look at the poster, you can see that although the teams have a male majority, there are women there too.

This is not as flashy as the University of Washington's excellent Why CSE page, which overtly demonstrates how underrepresented groups can and do succeed in Computer Science and Engineering. However, it does show that—right here and now—women are integral parts of successful research and development projects. Whenever I meet with a prospective CS major, we walk by this display case. I am glad that now I can point to these pictures of some of our most successful majors and show how they are working hard, together, and that they are proud of their work.

After all, Computer Science is not just for dead women.

A new team's first Daily Scrum

2011-10-07T10:31:00.000-04:00

We spent the first several weeks in my game programming class covering the basics and exploring two platforms for game development, Slick and Unity. On Monday, the eleven students decided that for their semester project, they would like to work on one big team to try porting Morgan's Raid to Unity. I decided to mentor the team using Scrum, since that has worked so well for me in the past. For Wednesday, I put together a product backlog and the team had its first spring planning meeting. While I had recommended that the students read The Scrum Primer, I got the distinct impression that the vast majority had not done so; in their defense, I had emailed the link Tuesday night.

The planning meeting went well, although fifty minutes was awfully tight to introduce the fundamentals of Scrum and to do the planning. I used my Scrum diagram as a reference to talk through the process. We were missing three of the eleven team members, but we were still able to get a reasonable number of stories committed for the first Sprint.

Today was the team's first "daily scrum." At 8am sharp, everyone was present. I told them to get into a circle and report what they had done since last time, what they had planned for next time, and what were the impediments. They got up and moved to the open area in the front of the classroom, while I stood behind the teaching station.

Here's where the team really surprised me. In using Scrum with students many times in the past, I have found that they find it challenging to report to each other, that they prefer to report to me. I wrote about how my Summer team was able to leverage the physical space to have productive Daily Scrums, but that team was half comprised of people experienced with Scrum, so their team-facing attitude was to be expected. This team of eleven had one student with Scrum experience (Tom), and the rest had none. They formed the circle and showed a few signs of anxiety, but Tom started right in with his daily status. He passed it on to the teammate by his side, and the whole stand-up meeting went as smoothly as one could hope.

There are four differences between this team and those from my past experiences, and I suspect that each is a contributor to this team's success. First and foremost, I learned a lot about managing a Scrum team through my experiences last academic year, and so I was more careful to separate myself from the stand-up meeting. Second, there was the issue of physical obstacles between me and the team: as with the Summer team, the furniture provided a convenient separation. Third, there was exactly one team member who had Scrum experience, and he showed no hesitation in starting the meeting and reporting progress to the team. Whether he meant to or not, his example provided the perfect template from which the other students intuited the expected social behavior. Fourth, all save one of these students have taken previous courses with me in which we repeatedly applied principles of agile development. We did not use Scrum in particular, but we discussed the philosophy and the implications as well as learning the practice through a six-week project in two deliverables.

I wish I had more data to support that last point. I would love to be able to claim that the students' experience in CS222 is a contributing factor to their ability to work in teams in upper-level courses, since that's one of the explicit goals of CS222. Unfortunately, the assessment data is not that rich. I mentioned three other contributing factors, and there are undoubtedly more. Still, it's anecdotal evidence that some combination of my teaching and the curriculum are working in tandem to improve student learning experiences.

UI classes should not implement event listener interfaces

2011-10-06T16:47:00.002-04:00

When one does a rudimentary search for Swing tutorials, one finds approximately a zillion examples that recommend writing code like this:

import java.awt.Container;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public class PressMeFrame extends JFrame implements ActionListener {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        PressMeFrame frame = new PressMeFrame();
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMeFrame() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(this);

        Container contentPane = getContentPane();
        contentPane.setLayout(new BoxLayout(contentPane, BoxLayout.Y_AXIS));
        contentPane.add(button);
        contentPane.add(outputField);
    }

    @Override
    public void actionPerformed(ActionEvent arg0) {
        outputField.setText("Thank you.");
    }

}

The problem I want to focus in on is that PressMeFrame implements ActionListener, but in truth, I can't stand looking at a class that extends JFrame when it doesn't have to. Do I really want to bind myself to JFrame right now? Not when I can just as easily make a reusable component that can be stuck into other things.Let me start this again...


import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public class PressMePanel extends JPanel implements ActionListener {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(this);

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }

    @Override
    public void actionPerformed(ActionEvent arg0) {
        outputField.setText("Thank you.");
    }

}

That's a little better, and if you followed the first, you can follow the second.Now, to the heart of the matter. While this works, I argue that it is not right. When we say that PressMePanel implements ActionListener, we are making a bold statement: we are saying that every PressMePanel instance is designed to listen for action events. For example, we could make another class that uses PressMePanel, like this:


import javax.swing.BoxLayout;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A panel for text entry.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public class TextEntryPanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setContentPane(new TextEntryPanel());
        frame.pack();
        frame.setVisible(true);
    }

    public TextEntryPanel() {
        setLayout(new BoxLayout(this, BoxLayout.X_AXIS));

        PressMePanel pressMePanel = new PressMePanel();
        JTextField textField = new JTextField(10);
        textField.addActionListener(pressMePanel);

        add(textField);
        add(pressMePanel);
    }

}

That "works," in that when we press enter in the text field—which fires an ActionEvent—the message comes up in the PressMePanel. However, it doesn't really make sense. The interaction logic of PressMePanel is internal. It's simply not designed to be used in this way, but because it implemented ActionListener, this is perfectly legal.Defensive coding practice dictates that we should prevent this kind of abuse if we can. We get much better encapsulation if, instead of having PressMePanel implement ActionListener, it creates its own delegate listeners. One easy way to do this is to create inner classes to handle it:


import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public final class PressMePanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(new MyButtonListener());

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }

    /**
     * Listens for action events, posting a message to the {@link #outputField}
     * when this happens.
     * 
     * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
     */
    private final class MyButtonListener implements ActionListener {
        @Override
        public void actionPerformed(ActionEvent arg0) {
            outputField.setText("Thank you.");
        }
    }

}

I've added a private inner class, MyButtonListener, which has one job: listen for action events and update the message in outputField when that happens. This is nicely encapsulated, and by making the class private, I'm not exporting it for potential abuse by other parts of the system. (Notice that I've also made both classes final. In the spirit of defensive programming, if I'm not designing for extension, I should prevent it.)There's another design improvement to be made. By defining the MyButtonListener as a class, I can now make as many instances of it as I want. Yet, my semantic model is that there is really only one, and it's attached to the button. Notice that this is implied by the naming of the class. Let's use anonymous inner classes instead:


import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public final class PressMePanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent arg0) {
                outputField.setText("Thank you.");
            }
        });

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }
}

Now, there is no doubt that this specific behavior is tied to the button. Of course, if I had a need to replicate this behavior, I could make a named class or an Action object, but we can cross that bridge when we get there. Better to solve the problem at hand than one that may or may not come up later.Moving to an anonymous inner class provides with another interesting refactoring opportunity. I like to have as few fields in my objects as I can. Now that the text field is only ever accessed or manipulated from the constructor, I can pull it into a local variable rather than an instance variable. The only piece of Java magic required for this is that we have to make the field final so that it can be read from the inner class:


import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public final class PressMePanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        final JTextField outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent arg0) {
                outputField.setText("Thank you.");
            }
        });

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }
}

Nice and tidy, but more importantly, our PressMePanel is well-encapsulated.

Now, textbook and tutorial authors, you can stop making every class under the sun implement listener interfaces.

You're welcome.

Students' reactions to the XP Episode

2011-09-29T18:28:00.001-04:00

After giving them a brief introduction and experience with pair programming, I had my students read Engineer Notebook: An Extreme Programming Episode and write an essay response. I found a few of their comments particularly insightful, and so I'd like to share them here.

"I felt that most of the things my partner and I were doing was making statements, but the two Bobs thrive on asking questions."

"As students we tend to be focused entirely on what we know and what we can do that we don't sit down and realize that most of the people in our class can do the exact same thing."

"Respect is key to pair programming."

The words faculty use to describe their activities

2011-09-28T14:44:00.001-04:00

I am on the university strategic planning committee. Over the course of the last several weeks, we have held many information gathering sessions with stakeholder groups, including faculty, students, parents, employers, and staff. Right now, my subcommittee is analyzing the data from two specific questions asked at the information gathering sessions:

What did you learn about BSU over the last five years that you did not know before?
If you could choose one area of focus that will have the greatest positive impact on the university, what would it be?

A few minutes ago, I finished my first pass through the responses, and this was my first attempt at open coding. Most of the data came from faculty sessions, and I was struck by how often the word "teaching" was used. Practically absent from their responses was any discussion of learning. The words faculty used to describe themselves and their activity matched exactly those words most commonly seen in promotion and tenure guidelines and annual reports: professors are obligated to do some amount "teaching."

Maybe I am reading too much into this, but it seems to belie a teacher-centric rather than learning-centric philosophy. I am reminded again of the advice of my colleagues, David Concepcion and Mahesh Daas: that the role of a professor is designer of learning experiences, and that to be a good teacher, one must be a humble learner.

The dean of my college, Michael Maggiotto, has been encouraging a transition from "teaching, research, and service" to "learning, scholarship, and engagement," as long as I have been here. At first, I dismissed this as simple alpha equivalence, and as potentially dangerous as it eschews the relationships among Boyer's four scholarships. However, reflecting on this in light of the data I just waded through, Maggiotto's approach may be a step in the right direction. The words we use shape the thoughts we think.

As an aside, I can't help but hope that I'm the first person to reference grounded theory and lambda calculus in the same post.

The Design Thinking Game

2011-09-26T09:38:00.001-04:00

This morning in my game programming class, we started a short unit on game design. I brought in some prototyping materials and gave the students ten minutes to whip up a board game in the roll-and-move genre. This was inspired by Ian Schreiber's Game Design Concepts Level 1 activity and its primary purpose is to get students over the invisible barrier, "what if I cannot make a game?"

To explain what "design" is, I had started with a brief presentation of design thinking. Once I got the students started with the activity, I decided to sketch out a game as well. Glancing at the chalkboard, it struck me that the design thinking cycle could be modeled as a board game, so I made this:

The captions on the boxes are:

Empathy: an audience
Identify: a problem
Ideate: a solution
Build: a prototype
Test: a strategy

Each player starts at Empathy. Each turn, you roll a die and move that many spaces along the cycle. Grab a blank card and write down something that happens in that phase, using the caption to guide you. For example, my first turn, I rolled a three, and ended up on Build, so I made a build card, "Sketch." Then I rolled a two, putting me on Empathy, so I made an empathy card called, "Elderly." As soon as there is at least one card for each category, that player takes one card at random from each category and has to make narrative that explains how these five things fit together. I didn't get far enough in my own design process to decide on an initial scoring or elimination process, but I imagined that the other players would somehow score the story, and there would be a time or point threshold to trigger the end of the game.

That's it. A ten-minute game, most obviously inspired by design thinking, 1000 Blank White Cards, and Dixit. Is it fun? No, not really. You fly around the board and are forced to invent artifacts separated from any context, so you can only be very generic. Is it good? No, not really. It completely misses the point of design thinking, that you have to go through each phase to get to the next. So, why write it up here? It was actually a fun thought experiment. I used this ten-minute design exercise at the AIM conference a week ago, but I did not actually participate, I just observed. It was much more fun to actually get in and do it. I also enabled me then to present my flawed game design first, demonstrating the importance of metacognition, specifically learning from the process rather than judging the artifact too harshly.

Guest Post at Play the Past

2011-09-06T12:48:00.000-04:00

My guest post at Play the Past is now online. It provides a birds-eye view of the design and development of Morgan's Raid, which I have written about extensively here.

Peer evaluation rubric

2011-08-29T20:33:00.000-04:00

I read through a portion of Computer Science Project Work. If found some of the book to be difficult to read because it is written for the UK higher educational system, whose structures I do not fully comprehend. It makes matters worse when the authors throw around terms that I can only assume are equivalent to AP, credit-hours, FTE's, and such in the United States. Ignoring the specifics of the implementations, I did find some good tips that I can adapt to my own practice. In fact, one of their key contributions is a studied observation that transfer expects transformation. That is, the transformation that one applies to found scholarship is an indicator of transfer of practice.

Most of my notes from reading the book fit handily into one of my notebooks, but there is one piece I would like to share and archive here: a sample peer- and self-evaluation form from pages 250-251. It is presented as part of bundle 8.6, "Moderation Using Student Input." The form is in two parts: management characteristics and technical contribution. Both use a seven-point Likert-type scale, but while the first part uses distinct semantic labels for each end-point,
the second simply uses "well above average," "average," and "well below average" for all categories.

These are the categories and scale labels for the management skills portion.

Category	High-end	Low-end
time management	highly organized	unreliable
responsiveness to others	respects views	domineering
coping with stress	always calm	panics easily
cooperation	always cooperates	goes own way
self-confidence	able to take criticism	can't take criticism
leadership	takes initiative	follows others
problem analysis	incisive	woolly
project management	best practice	activity lacks coordination
project evaluation	systematic and objective	casual and subjective

The categories for the technical contribution portion are

Task Analysis
Conceptual Design
VDM
Manager's Meetings
Team Meetings
Low Level Design
Coding
Testing
Documentation
Demonstration

Both forms provide room for open-ended comments as well.

VDM? I have no idea. Unfortunately, while the book acknowledges that portions are written by different authors, it does not identify who wrote this part, nor whether or not is based on existing scholarship. I would like to see an evaluation of this instrument in particular, since it seems to be the only recommendation in the book that is provided in such specificity—despite knowing and withing acknowledging that it should be transformed to be transferred!

On first glance, I was impressed by the custom labels. I love the use of words like "incisive" and "woolly" to describe how a student interacted with a learning experience, and I think it's good for students to think about the capacity to take criticism as an indicator of self-confidence. As I looked closer, I noticed scales like "leadership," which here is measured in terms of taking initiative versus following. I'm not sure I like that dichotomy, but again, that's where I would like to read a formal evaluation of this instrument in particular. The more I read about using this instrument (which was less than one page), the less I liked it, as the author suggested using a fairly straightforward scoring mechanism: average students' self-assessment with their peer assessments, sprinkle with up to 5% secret sauce, and call your work done. Once again I have to admit my ignorance of the grading environment in which this scheme was designed, but I would be unhappy with this in an A/B/C/D/F scheme. Specifically, where would one cut off, say, "A=Excellent" with such an approach?

In any case, there are some interesting categories here for student self- and peer-assessment, and I can see the value in handing out a form like this at the start of a project to get students thinking about how their contributions may be classified. No one wants to be woolly.

Allergies

2011-08-27T09:59:00.001-04:00

Regular readers of my blog may wish to know that, as of this week, I am back on my allergy medicine. Also, I was not spontaneously promoted.

My morning in pictures

2011-08-22T09:26:00.002-04:00

Ah, the first day of the Fall semester. My game programming class meets at 8am. Let me tell you about the morning so far.

I came into the Math lounge to put my lunch into the refrigerator. I pulled it out of my backpack and slung my backpack up onto my shoulder. Not having latched my bag shut, my favorite mug fell from it and shattered into a million pieces on the ground.

Favorite mug, before the accident

I picked up the bigger pieces, cutting my finger in the process, then asked the receptionist in the Math department to call custodial to get the rest of the shards.

Returning to my office, I realized I still had my lunch bag in my hand, so then I went back and put it in the 'fridge.

I poured my coffee from my travel mug into the back-up mug in my office, my good-old ACM mug.

Old Faithful

A bit of background on my morning coffee: Last night, I noticed that both of my french presses were in the dishwasher, which was nigh full, and I expected that the dishwasher would be run overnight. Of course, I did not actually run it, and so in the morning, I was left without a clean press. My backup plan was already in place: use my cold-brew coffee concentrate! I mixed it with some boiling water and half-and-half, and that's what I brought to the office with me. The result was that when I tested the coffee, it was not quite as hot as I would have liked.

Problem easily solved. I went into the CS conference room to put my coffee in the microwave...

Conference room microwave, outside

and when I opened the door, I saw this:

Conference room microwave, inside

Well, ick. The red sludge looks like jam to me, like someone tried to microwave a peanut butter and jelly sandwich, realized it was a bad idea, and left the detritus behind. By this point, it was already about 7:55, and I didn't want to dally—I just wanted hot coffee. I went ahead and put my mug in for 30 seconds, hoping it wouldn't come out tasting of smoked jam. When I opened the door after thirty seconds, a little flying insect came out of the microwave. Can that even happen?

I took the coffee out of the microwave and headed down to my classroom, a cozy little room we call RB104. It's a conventional "smart classroom," meaning there's a projector, dongles for attaching a laptop, and a badly designed teaching kiosk. Some of the students were waiting outside the door, so I proceeded to unlock the door with my key. In fact, I locked the door, which I only discovered after unsuccessfully trying to open it; it had been unlocked from the beginning. Properly unlocking the door and flipping on the lights, here's what I saw when I came in:

The land that custodians forgot

This is 8AM on the first day of classes for the semester, and there's a pile of crap on the desk! Notice that there are two unclaimed notebooks from at least the Summer session, though I think it might be from last Spring, since they looked familiar. Let's take a closer look at that pile on the near side of the table.

"Stuff"

The mess of cables is normal for the room. There's cabling for the mouse, ethernet, and video. They are sitting on top of a discarded notebook, beside the room's nonfunctional remote control. On the left is a chunk of chalk, an uneaten but ratty-looking Ricola, and a small leaf.

The real winner, however, is this thing, from the middle of the table.

What is that thing?

I moved the mouse next to it for scale. I'll say it again: What is that thing? At first I thought it was a wad of candle wax that had been handled by someone with soot-covered fingers. It looks kind of like a big ugly toenail. I really have no idea. I did not touch it.

After cleaning up the desk, I plugged in my laptop to the projector and found that the autofocus was not working. A friendly student adjusted it manually from the middle of the room.

The good news is that everything got better from here. I talked to my students about how I got interested and involved in game development, showed them some of my and past students' work, and talked about the goals for the semester. They seem a good sort, and despite a rocky start, I think it will be a good semester.

Good morning!

The Escape

2011-08-21T17:38:00.002-04:00

When a student reminded me that the next Ludum Dare competition would be this weekend, at first I was excited about using it as a creative way to ring in the new semester. My plan was to learn more of the toolchain involved in making a simple game in Unity in order to leverage that experience in teaching Game Programming this semester. I spent some time this past week tinkering with Blender for the first time, watching tutorials and making some very simple models. As the weekend drew closer and the real stresses of starting the semester began to rear their heads, I realized that my time would probably best be spent in a combination of last-minute planning and spending quality time with the family.

Ludum Dare announced their theme for the 48-hour game development competition Friday evening: "Escape." After sleeping on the theme, I was inspired Saturday morning to make an entry. So, for your gaming pleasure, I present to you The Escape.

Windows version: Extract the zip file and run the enclosed exe.
Mac OS X version: Unzip it and it should magically work.

You could call it a puzzle game.

I'll write more about the development in a later post.

Continuing Academically Adrift

2011-08-15T08:37:00.000-04:00

I was excited to read the final chapter of Academically Adrift, entitled "A Mandate for Reform." Although I enjoyed reading it, the final chapter was neither as revolutionary nor as specific as I hoped. The authors discuss several inhibitors to change, the most daunting of which is the lack of demand for learning, which I wrote about a few days ago. Their suggestions match much of what my own Future of Education Task Force concluded: we need a greater focus on student learning. This support must take the form of both respect and rewards, since as long as teaching is institutionally considered a lesser responsibility to research, then there will be no change.

Let me be clear that I enjoyed reading the book and consider it a significant contribution to the field. Perhaps it was unfair of me to expect that their conclusions would be more immediately actionable, since their stated goal was research, not reform. Consider, for example, the authors' suggestion that effective reform needs to happen from within the current system, allowing actors to innovate within the existing space of higher education. This compares to my Future of Education Task Force recommendation for what we called "The University Sandbox," an initiative that would be authorized to work within the university while ignoring conventional assumptions of higher education. Our recommendation was not codified to the point of being immediately implementable, but I was hoping that Academically Adrift would provide more examples of how institutions might consider approaching the problem of fostering educational innovation.

In the final chapter, the authors to begin to fall into the social science trap of claiming their results are broader than what they actually found. Their study used the Collegiate Learning Assessment (CLA) to look specifically at critical thinking, complex reasoning, and writing, measuring a cohort as they entered college and as they finished their sophomore year. They found that individual studying improved students' scores while group study did not, and the last chapter begins to conflate CLA achievement with learning in general. This matches my experience and intuition: a student's ability to individually write an essay should only be improved by that individual practicing writing essays. However, they neglect to mention that CLA-measured skills are not the only skills that need to be learned. For example, there is a body of research in Computer Science education that has shown that pair programming—undeniable a form of group study—improves learning and retention. The authors clear bias for individualized rigor could have been balanced with a caveat that there are disciplinary idiosyncrasies.

The final chapter's message could be summarized as, "Be deliberate about fostering student learning in higher education." The criticism of cargo-cult active learning was refreshing, given how many papers I have reviewed and presentations I have heard where the researcher has not demonstrated any significant understanding of the fundamental tenets of learning. I also appreciate their argument for more widespread teacher-training within doctoral programs. The crux of their argument is that for the foreseeable future, many more Ph.D.s will be adjunct faculty or in teaching roles than tenure-track at research-intensive schools.

There is one immediately actionable recommendation for faculty that the authors return to time and again: be rigorous. Their own study and several related studies have shown that rigorous coursework improves student academic achievement. This may seem obvious to those outside the ivory tower, but those of us on the inside have seen how easy it is to trade away rigor for easier teaching. This comes back to the delicate equilibrium I wrote about the other day, in which learning is generally not considered worth institutional sacrifice. The good news is that students are hungry for it.

Despite any nitpicking, I do strongly recommend the book, especially to anyone who is just starting to dip their feet into higher education reform. It is probably best read in conjunction with a book more specifically about learning, such as How People Learn, How Learning Works, or, for like-minded technocrats, Pragmatic Thinking and Learning. (NB: I have not yet read the second book mentioned above, but I have heard good things about it.)

Academically Adrift and the Status Quo

2011-08-11T09:08:00.001-04:00

I am nearly finished reading Academically Adrift: Limited Learning on College Campuses. In case you are not familiar with the book, here's the short version. The authors studied 2000+ students from 24 four-year institutions of higher education, giving them tests that measure general (as opposed to discipline-specific) skills that practically all colleges claim to enhance: critical thinking, complex reasoning, and writing. The tests were given before starting college and halfway through the sophomore year, and so they were focusing on the effects of common core curriculum experiences. The results were dismal, with the average gain being very low and about 45% of students showing no improvement.

The fifth chapter is entitled "A mandate for reform," and it makes an important point about higher education: there is no crisis. There is no crisis because there is nothing that, right now, is threatening the existence of higher education as an institution. All of the stakeholders are in good position to maintain the status quo. Parents grumble about tuition but continue to pay it in exchange for credentials for their children. Students readily seek out courses that provide little challenge, require minimal work, and allow for plenty of time for social activities, while still maintaining progress towards credentials. Professors minimize interaction with students, exchanging unchallenging courses for high course evaluations and therefore more pay, while also gaining more time for other scholarship—which also leads to more pay. Administrators keep students happy in order to improve recruitment and retention, focusing on revenue streams. Legislators and other politicians gain a credentialed citizenry, improving metrics against competing states, nations, etc.

This gives me another perspective on why it has been so challenging to try to push for learning reform within higher education: "learning" is completely absent from the status quo. There is nothing about the current balance of powers that supports, rewards, or encourages undergraduate learning, and in fact, to do so would upset the balance.

From page 127, "Many higher-education administrators and faculty today have largely turned away from earlier conceptions of their roles that recognized that providing support for student academic and social development was a moral imperative worth sacrificing for personally, professionally, and institutionally." There were some on the Future of Education Task Force who were willing to bring up the concept of institutional sacrifice, but I have yet to see this manifest on the Strategic Planning Task Force.

Looking at it positively, this book gives me more ammunition to support what I believe is the moral imperative to fundamentally improve the higher educational system. The book is well-written and contains plenty of references to supporting literature.

Having an impact across campus

2011-07-22T15:52:00.001-04:00

Following up on yesterday's post about stand-up meetings, I heard a great story today about an impact that the Morgan's Raid team has had in a distant corner of Ball State University campus.

Towards the end of the Spring semester, James Mitchell from the Career Center gave a one-hour workshop called "How to Market Your Immersive Learning Experience." This was in the middle of the sprint, so he observed the team hold one of their stand-up meetings before the workshop. This is the short meeting at the start of each work day in which each team member shares what they have done since yesterday, what they plan to have done for tomorrow, and what impediments are in the way.

Today is the last day of the Digital Archaeology Project, and James joined us to give the workshop to this group of students. He told me that he was so impressed by the Morgan's Raid team's stand-up meeting that he has pushed the staff of the Career Center to do something similar, with the hope of improving communication and camaraderie.

Score one for agile philosophy!

Forced proximity and stand-up dynamics

2011-07-21T12:00:00.000-04:00

I noticed something interesting when acting as Scrum Master for the Digital Archaeology Project. Our main meeting room is the Anthropology Department's conference room, which has tables set up in a U-shape.

While some of the students knew each other before the start of the project, many did not. When we started our first stand-up meeting, it was clear that the students wanted to stand around the outside of the tables, where they had sat down upon arrival. I shepherded the team towards the center of the tables in order to have their stand-up meeting.

There were three professors in the room, and we were all seated on the outside of the U during the stand-up meeting. I think this is significant, since from the very start of Sprint 1 to today, our last stand-up meeting, the students never turned and reported their progress to us, the Product Owners and Scrum Master. Every meeting, the team exemplified the agile best practice of reporting to their teammates. Even though there was clear line of sight among everyone in the room, the tables provided a psychological barrier that allowed the team to carve out its own private space in the middle of the room, without losing the benefit of having the Scrum Master listening in to determine how to remove impediments.

The cost of the room configuration was paid in Sprint Planning meetings. We used a portion of the wall for our task board, which comprised of colored index cards, tape, and yarn.

The cards are standard 3x5, and so to write user stories or tasks on them requires one to write relatively small, around 22 points. During the Sprint Planning meetings, however, the team would sit within the U in two rows. The close row, about eight feet from the wall, could see and read all the tasks, modulo handwriting issues. The next row, probably three times as far, could not make out a thing written on the cards. There wasn't really a way to get everyone close enough to read and still be comfortable, not without moving tables around. In retrospect, perhaps we should have just moved tables around for these meetings. Also, the complications of the space were exacerbated by the fact that we skipped the product planning meetings in which the team would discuss story points per user story: because of our very tight timeline, I assigned story points based on intuition.

There's not enough time in four one-week sprints to react to all the complications that can arise. It would have been nice to have more time in this space to see how to optimally use it. Next semester, I'll be back in my usual Computer Science classrooms, which come with their own issues.

Manager's Guilt

2011-07-19T14:53:00.000-04:00

We're in the final week of the Digital Archaeology Project, and the students have really hit stride in terms of productivity. The content team has developed a working understanding of iterative design, and they are dealing with the technical challenge of XML-as-a-DSL. (NB: Not ideal, but in a five-week timeframe, nigh inevitable.) The technical team has shown remarkable growth in working with Unity: as I watch and listen to them work, I observe most of the conversation is about the problems of the domain, not problems with the technology.

Yesterday I started reading Clean Code, by Robert C. Martin. I've been enjoying it and am considering using it for Fall's CS222 class, but as I read it, I was forced to acknowledge the dual roles I have been playing on the digital archaeology project—or perhaps, the dual roles I'm not playing.

Early in the book, on page 6, Martin describes the tension between managers and developers, specifically with respect to a manager's need to meet production goals and a developer's need to keep code clean.

"But wait!" you say. "If I don't do what my manager says, I'll be fired." Probably not. Most managers want the truth, even when they don't act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that's their job. It's your job to defend the code with equal passion.

I had a discussion (moderated by Google+) with the technology team just yesterday in which they pointed out that our methodology had been ad hoc and that formal code reviews would probably have helped our progress. It forced me to realize that I had been acting only as a project manager, trying to push this ambitious project into its five-week timeframe without stopping to consider the needs of the developers to write clean code. More specifically, I fear that I did not uphold my duty as an instructor to help the students learn how to do these code reviews, how to write usable code. David's recent post on the team blog highlights a symptom of this problem: we both saw that some of his code was unclean, but I fear I did not adequately authorize him to be able to tell me that he needed the time to clean it up. That is, if I only criticized it but did not impart on him the authority to deal with the criticism, then it was a learning opportunity forever lost.

Not that this has all been bad, by any means. Watching the team learn .NET with almost no prior introduction to it was great, and as I mentioned above, their savvy with Unity is laudable, especially after such little calendar-time working on it. Several times, we have been able to reflect on our lessons from Morgan's Raid and apply them to this new context, for both technical design and experience design issues.

But, as this is my place for reflective practice, I feel it is important for me to reflect on the feeling of guilt that washed over me as I read Martin's book. The challenge for me, moving forward, is to me cognizant of my two roles. This is significant for project-oriented, inquiry-based learning. For me to be a facilitator of learning, it's not enough to be a project manager: I need to be aware of those times that the schedule needs to be adjusted in order to help the team to understand the "principles, patterns, practices, and heuristics" that then they can "grind... into your fingers, eyes, and gut by working hard and practicing." (Martin, Clean Code, p.xxvi)

Digital Archaeology Project Blog

2011-06-25T15:56:00.000-04:00

I have mentioned this Summer's digital archaeology simulation project in other posts. We started the project last Monday, and the team has set up a blog where we are sharing some reflections. Check it out at http://digitalarchaeologyproject.blogspot.com/.

The posts there are being used to foster reflective practice and metacognition. They are relatively unstructured, the students having no real guidelines or requirements for posting other than using it to share their thoughts and feelings. There have been some interesting bits shared there so far, and we've asked each of our eight undergraduates to post there about once a week.

Relying on technology

2011-06-19T11:11:00.000-04:00

From USA Today:

A five-hour computer outage that virtually shut down United Airlines Friday night and early Saturday is a stark reminder of how dependent airlines have become on technology.

Airplanes, for example.

A Ruby DSL for creating entity system components in Java

2011-06-16T08:50:00.000-04:00

Have you ever been working with entity system architectures in Java and wished for a quicker way to prototype components? Well, you've come to the right place.

After working with entity systems for about year, I have an idiosyncratic way of defining any of my components. Keep in mind that components are just dumb data objects, not proper OO-objects, and I'm roughly following Adam Martin's approach. Here's the way I would define a position component for two-dimensional floating-point space:


public class Position {

    private float x;
    private float y;
    
    public float x() { return x; }
    public float y() { return y; }
    
    public Position x(float x) { this.x=x; return this; }
    public Position y(float y) { this.y=y; return this; }
    
}

I've skipped documentation for the sake of brevity. I like to keep my data private, even though it's exposed through accessors and mutators—I just can't bring myself to make public instance fields in Java. The naming convention for accessors and mutators is a Smalltalk approach, using the same name for both accessor and mutator, which can lean designs towards fluent API design instead of pushbutton (see Fowler's DSL book for more on this). The mutator returns code to promote fluent API design as well, to permit code like the following.


Position p = new Position().x(10).y(15);

Now if I'm feeling really spiffy, I'll use a builder:

Position p = new Position.Builder().x(10).y(15).build();

but that's not my point.

My point is that this is almost all boilerplate code. All I really want to say is that there's a component called Position and it has two floats, x and y. So maybe what I really want to be able to write is something like this:

Component.build :Position do
  float :x
  float :y
end

The title of the post gives it away, but this is a little Ruby DSL that I hacked together this afternoon, just to see if I could. I've been meaning to learn Ruby for some time. I have read quite a bit about Ruby and its use in DSLs, but never actually created one. This time around, I used Jonathan Magen's tutorial as a reference.

The Component module is the starting point, and it uses what I take to be a fairly standard approach, sending blocks of code from the context to be executed within the object context:

module Component
  def self.build(name, &block)
    builder = ComponentBuilder.new(name)
    builder.instance_eval(&block)
    builder.build()
    return builder
  end
end

The one custom piece is the build method on the ComponentBuilder. What this does (perhaps not clearly indicated by the name, in retrospect) is tell the constructed object to dump out a Java source file based on the content of the block. The ComponentBuilder looks like this:

class ComponentBuilder 
  def initialize(name)
    @name = name
    @floats = []
  end

  def float(x)
    @floats << x
  end

  def build
    File.open(@name.to_s + ".java", "w") do |theFile|
      theFile.syswrite("public class #{@name.to_s} implements Component {\n")
      unless @floats.nil? 
        @floats.each do |var|
          theFile.syswrite <<BLOCK
    private float #{var};
    public float #{var}() { return #{var}; }
    public #{@name.to_s} #{var}(float #{var}) {
        this.#{var} = #{var};
        return this;
    }
BLOCK
        end
      end
      theFile.syswrite("}")
    end
  end

end

Here's a very quick walkthrough for those readers who do not know Ruby. The initialize method is the constructor, and it's setting the instance variable @name to the argument's value and initializing an empty array for @floats. The next method is called float, which is not a reserved word in Ruby, and it appends its argument to the @floats array. The build method opens the appropriately-named file, writes the class declaration, and then iterates through the @floats field, dumping out the field, accessor, and mutator definition for each one.

There were two specific pieces of Ruby syntax that I had to learn to make this work: here documents and expression substitution in strings. The oddly named "here documents" are multiline string literals. In my program, they run from <<BLOCK to the recurrence of BLOCK. This is a really useful feature for a program that is essentially filling templates and dumping them out. C# has something similar, but Java—my usual production language— does not. Note that you can do it with Groovy, though it appears the proposal to put this in 1.7 hasn't been approved. Regardless, expression substitution in strings is simple and elegant: within a string literal, put an expression within #{...}, and it is evaluated and interpolated into the string at runtime.

In order to make my program a bit more robust, I added configuration information to control the Java package and path to the destination as well as per-class and per-field embedded Javadoc, passed as optional parameters (via variable-length argument lists). The biggest problem I had with this was creating directories automatically from relative paths, but in the end, I pulled it off with a little custom method shown below.

def defensive_makedir(dir) 
  array = dir.split('/')
  accum = '.'
  array.each do |partial| 
    accum = accum + "/" + partial
    unless File.directory? accum
      Dir.mkdir accum
    end
  end
end

To integrate this into Eclipse, I wrote a simple ant build script. Honestly, I wrote this very early in the experiment, but the process of debugging Ruby through Eclipse and Ant was quite cumbersome, and once I hopped over to a console and emacs, I was able to iterate much faster. To incorporate this into the build process in Eclipse, hop over to your project preferences and check out the "Builders" section. This requires the JRuby jar to be on the build path.


<project name="FunWithComponents" default="make_components">
    
    <property name="lib" location="${basedir}/vendor/lib"/>
    <property name="jruby.jar" location="${lib}/jruby.jar"/>
    <property name="ruby.src" location="${basedir}/ruby"/>
    <property name="generated.src" location="${basedir}/gen"/>
    
    <target name="make_components">
        <java jar="${jruby.jar}" fork="true" dir="${ruby.src}">
            <arg value="${ruby.src}/make_components.rb"/>
        </java>
    </target>
        
</project>

I enjoyed working on this and learned a bit about Ruby, both in terms of the language and how to express myself within it. I acknowledge that I do so much work in Java, it can be hard to switch paradigms or idioms, and so it's good to actually make something useful from time to time. However, it also makes me wonder if all that trouble is actually worth it when I can immediately imagine how to support a Java-based solution like the following.

 public static void main(String[] args) {
    ComponentFactory.instance().build("Position")//
        .withFloat("x")//
        .withFloat("y")//
        .build();
    }

Morgan's Raid Postmortem

2011-06-13T09:49:00.000-04:00

Morgan's Raid enjoyed its public release at the Conner Prairie Educator Event last Thursday. With that event, the project is essentially "done," modulo the inevitable maintenance. For the past few weeks I've been sketching out notes for a postmortem in the style of Game Developer magazine, and now I'd like to share these with you. In truth, I vary a bit from their style, looking more at structural elements of the team than technological decisions, but this is natural given the dual nature of the project, which was designed to create something significant while also meeting learning objectives for the developers. (As I think about this, it would be interesting to write one in their style too, but that's a task for another day.)

What went well

Scrum

The application of Scrum was excellent, especially as we refined our process in the Spring. The students and I appreciated the public nature of the task board, and they healthily struggled with what it meant for a team (not an individual) to commit to a task. The impact of the burndown charts was evident in how students discussed their work and our progress, and the sprint renegotiation process was relatively smooth. The sprint reviews and retrospectives gave the team a chance to analyze and discuss the product and the processes, and their empowerment helped fuel their continued motivation.

Our modifications to Scrum were relatively minor. Because the team only met three times per week, we did not have daily stand-ups, but our "once-per-workday" stand-ups were sufficient. One aspect that we completely dropped was the product burndown chart. With our already low number of collaborative, collocated working hours, I decided against adopting formal planning poker sessions. In the Fall, I made up story points based on my experience as a developer and a teacher, and in the Spring, we skipped these entirely. I do not doubt that they would have been an academically interesting feature to keep, but aside from academic intrigue, I think I made the right call to slim Scrum down a bit.

Due to scheduling issues we could not control, our artist could not meet with the developers in the Fall. As a result, his work was rather undirected and his contributions relatively few. In the Spring, he was able to meet with the developers, creating a real cross-functional team. The results were amazing, and I need to be sure to promote cross-functional teams in future experiences. This is not directly related, but I'm sure that our separation of "designers" and "developers" in the Scourge of Orion project was a major contributor to its lack of productivity.

Playtesting

Our external playtesting experiences were fundamental to the success of the game, and I express again my gratitude to those teachers and schools who shared their time with us. I know that I learned a lot by seeing how the end users interacted with our various prototypes, but more importantly, I could see how it helped the developers build empathy for the end users.

It was especially useful to playtest with different demographics. "Indiana fourth grade students" encompasses a wide variety of skills and dispositions, and even in our relatively limited playtesting, we were able to witness this range. I suspect that this perspective not only helped the team to design the game but also to develop empathy for the challenges of the elementary school system.

Every child who played Morgan's Raid gave us some feedback, and often they had feature requests. Some were clearly outside of our scope, such as adding multiplayer support and leaderboards. Many others were based on the students' experiences with school and educational software. At some point later, I plan to write a more detailed piece on why there are no quizzes in Morgan's Raid, despite this suggestion being proffered by many playtesters. What was more salient to this post is that some of the team members jumped on these recommendations, an unspoken assumption being that we should provide what the intended end users wanted. There's a deeper anthropological lesson here that I tried to explain to the team, that while the users are always right, they also aren't experts. This brings us back to the design issue mentioned earlier, that experience design is difficult, and it's important that someone have the power to veto.

Development methodology: Entity system architecture and Mercurial

I have written before about the entity system architecture, and I list it here as one of the great successes of the project. Adopting this architecture allowed us to separate tasks rather seamlessly, certainly better than I had experienced before in working with teams of undergraduates.

The fact that this was a team of amateurs is significant. The ideals of proper object-orientation can and should lead to modular, robust, scalable software systems. However, because the students lack experience, perspective, and technical understanding, it is insufficient to give them a software design task and expect production-quality results. Even with the entity system architecture, there are parts of the code that are ugly to behold, unnecessarily coupled across disparate systems. That said, the fundamental idea of the architecture—decoupling behaviors into components, which are acted upon by systems, and combining components into entities—was simple enough that it could be explained with a few examples and then applied by the team.

Maybe I'm cheating by putting two in one here, since the version control system is orthogonal to the software architecture, but I'm going to mention it here anyway. This was my first time using a distributed version control system, and Mercurial more than proved itself. The students were able to learn it quickly and became quite savvy with the workflow. It was a little distressing that even at the end of development, some team members were mad at Mercurial for making them merge, where I would have liked them to adopt the more enlightened perspective that merging is a necessary part of teamwork, and Mercurial made it infinitely easier than doing it by hand.

Spring Space

The use of a dedicated space in Spring was fantastic. This is not easy to come by in a university setting, and on behalf of the entire team and our stakeholders, I am grateful to my department for granting us the use of the room. Everything one would expect to improve was improved. While the Google Docs approach to managing the Scrum artifacts was reasonably effective when working with the 25-member team in Fall, it pales in comparison to the power of three giant whiteboards and piles of sticky notes in the Spring.

The incredibly impact of dedicated space has made me an evangelist for more responsible use of university resources. It got to the point where, on the Future of Education Task Force, people would just put "space" down for me in any list of things we need to change. Space is a deeply political issue on any college campus, but one important lesson I learned is that I should pay more attention to it during the planning stage of any future activity. If I can find any partner who is wiling to pony up space as part of a grant proposal, for example, I'll jump on it.

Team formation

It was great to see how the team gelled, especially the smaller group in the Spring. They really were a functional independent game development team in every way that matters. There was some work that I did to try to foster this sense of team, such as adopting agile methodologies, bringing goodies for Sprint Review and Retrospective meetings, and hosting board game sessions. These definitely helped, but I also could tell that the students were hungry to make something important, to do something that mattered beyond a credited learning experience. Even if we all had our own idiosyncratic views of what Morgan's Raid should be, we shared this vision of being able to work together to make something significant that none could do on his or her own.

The only distressing part about this success is that the team is now gone. Usually, at the end of fifteen weeks, I am ready to push my students out to face their next challenges. With this team, a part of me wishes I could keep them here so that we can continue to face challenges together. I build an emotional bond with these undergraduates. They were my teammates and coworkers, my partners in a difficult endeavor, my colleagues, and my friends, and I will miss them.

What didn't go well

Code reviews were not in our methodology

We did not have formal code reviews, and in retrospect, our code quality suffered because of it. It is easy at the time to ignore reviews in favor of "productivity," but I think this was a classic managerial blunder. I am not certain what methodology we could have used in the Fall to promote this, but we certainly could have inserted some more formal code reviews in the Spring. This would have directly helped us meet some learning objectives while improving the code base, since as I and others have said before, software development is a learning process.

Because of the generally poor code quality from Fall, I made sure to introduce a formal verification step into the task approval process. When I had the time and energy, this meant that I would not just check that the task was working, but that the underlying implementation was reasonable; however, working under our significant time pressure, I often did not have the time and energy.

In truth, I do not have much experience with code reviews. Sure, I've graded countless assignments, but these have primarily been summative assessments, not formative assessments. This is not an excuse but rather an opportunity for me to include code reviews into a future experience, so that my students and I can learn together how best to use them in our environment.

No technical specification

I invested a significant amount of time in Summer 2010 working the results of the Spring design colloquium into a functional design specification. This took the form of a wiki on Google Sites, and it was shared with all the team members and product owners. This was a colossal effort, since the output from Spring was nowhere near the quality we expected, and so really I was redesigning the whole game from disparate prototypes—and even then, what I wrote up was not that good and ended up being significantly changed before shipping. This does not mean it was wasted effort: it was still a necessary step along the way. However, because this took all of my spare cycles in Summer 2010, I was out of time when it came to the technical specification. I wrote up a few notes about methodology (inspired by Cockburn's excellent book that I read the same Summer), but for the most part, the software architecture was only in my head.

I suspect that the lack of a technical specification was a major factor in the relatively low productivity of the Fall semester. I believe that the productivity of Spring would not have been possible without the learning of Fall, but at the same time, and as pointed out by a team member the other day, much of the Fall was undirected learning. That is, the students were learning, but they didn't always know where they were going with this. Being able to rely on, for example, a software architecture specification, could have helped them see how their little piece was actually going to make a big difference.

Undergraduates, by and large, do not have the perspective necessary to design large software systems. After all, having wide perspectives and the ability to integrate across disciplines is an outcome of higher education, not an input. I'm sure a technical specification would not have improved Fall's productivity by an order of magnitude, but it would have helped a little. Most importantly, it would have helped the students see, from early in the process, the value of documentation. About two-thirds through the Fall semester, we did a massive architectural overhaul, and to get this done, I turned to de facto standard UML. Once the students understood how this language was part of my bigger process, they could see the value in it and showed interest in learning it. I suspect this transformative experience could have been brought about earlier through more formal technical specification.

IP

Dealing with the university's intellectual property policies has been an exercise in frustration. I suspect that mine is like a lot of other institutions of higher education, where tight budgets are causing the administration to jump on the commercialization bandwagon, and yet the staff has little or no experience dealing with software innovations. As a point in case, I have yet to meet anyone at the university who seems to understand software licensing, and all of the forms and procedures are aligned with physical invention.

In the university's defense, I put off dealing with IP until we were 90% done with the project. I just didn't want to deal with it, because I knew it would be a quagmire. Sure enough, it was, and still is, since some of our issues are still not sorted out: I was told that I would receive official written documentation on some issues over a month ago that I has still not arrived. I suppose I should have started the internal processes earlier.

On the positive side, all of the programmers have agreed to license their code under an OSI-approved license, and so I hope to make a source release of the game and announce official licensing policy by the end of the month.

The takeaway on the IP front is that, in future projects, I should deal with it earlier on, ideally during the proposal process. This would lead to a traceable paper trail and explicit acknowledgement of the funding agency of the intended licensing strategy, and we would only have to go through the current headaches if things changed.

Undergraduate game designers

I hesitate to mention this here since several of my undergraduates may read this, but understand that I write this with respect and affection.

We put too much faith in undergraduate designers. Game design is hard, and I posit that legitimate educational game design is even harder. I think what we asked of our Spring design colloquium class may have been impossible for students at that level of experience. Not only were they lacking game design knowledge specifically, they had essentially no prior experience with design thinking at all.

I recently took the time to reflect on the game designs I have come up with during my lifetime. I've always been a hobbyist, and specifically, I remember writing up rules for a tabletop RPG that got some playtesting when I was an undergraduate, and I sketched out at least one CCG rulebook that was circulated among my friends in grad school. When I look back at these, I made classic amateur mistakes, prioritizing the wrong elements and trying to do big design up front rather than incremental and iterative design. That is, I knew nothing formally of design thinking. As I reflect on what my students designed, in the design colloquium and during the evolutionary design of the development process, I see the same kinds of amateur mistakes.

For those who were on the team for more than one semester, I'm sure that they saw how I made changes to cope with these observations. The design colloquium was very open-ended, but in the Fall and Spring, I positioned myself as the design authority. While anyone could pitch any idea to me—and indeed the great design successes of the game are primarily student-generated—I was the gatekeeper, and there were many directions that I forced to be shut down. As benevolent dictator, I needed to ensure that energy was being spent fruitfully, even if it was perceived as less glamorous by the team.

Trying again to look forward, I think this will have to be the perspective I take in future endeavors. We were probably not critical enough in the Spring, and there wasn't enough time in a three-credit course for the students to develop healthy levels of design self-criticism.

Attention management

In the Spring, we had an excellent space in RB368, and I am sure that the success of the project rested in having access to the space. That being said, I'm not sure that I managed it correctly. As I have read more about agile software development spaces, I realize that we did not have a good management system in place for dealing with distraction. Our shared workspace was regularly interrupted by both related and unrelated events. I know there were several times where I was in the zone and then got broken out of it by well-intended interruptions.

For many students (at least it is said), working in a high-distraction environment is their modus operandi. The sad result is that they have no idea how much productivity they are losing, since they are not intentionally managing their attention. This would have been a good learning opportunity for them to see what being productive really felt like. Next time around, such as next Spring's VBC seminar, I will be more explicit about working conditions. I am confident that this can be done without negatively impacting the social bonds of the team, and in fact, I suspect it will lead to an increase in mutual respect.

State Design Pattern in Unity with C#

2011-06-12T20:17:00.000-04:00

Following up on my initial investigation into game engines, I decided that the best way to get to know Unity would be to build something with it. A few years ago, I wrote a clone of Every Extend called EEClone, which is described in this JERIC paper (ACM DL). I figured a new spin on EEClone would give me a good point of comparison, so I set out to recreate it in Unity.

As I mentioned earlier, one of the strengths of Unity is that it supports a variety of scripting languages, including C#. This intrigued me the more I thought about it, since it meant that it should be straightforward for me to apply my knowledge of Java design patterns in Unity with just a few syntactic changes. Specifically, I decided to dive into the state design pattern, which time and again I have found to be useful in practice. Just as with Java, a quick search of the Web for advice on how to implement state machines in Unity comes up with the classic procedural approach. The costs and benefits of the OO and procedural approaches are documented in the aforementioned paper; for this post, I will focus on the mechanics rather than justification.

Without further ado, this is what the game looks like. The video shows two player-initiated explosions followed by one obstacle collision.

The goal was to explore how the pattern is reified within Unity and C#, not to faithfully recreate EEClone, and so I went with a slightly simpler state diagram than in the Java version:

The astute reader will sure notice where I have cut corners. For example, PlayingState transitions directly to AwaitingRespawnState after the player sets off the bomb, without waiting for the explosion chain to terminate. Clever handling of explosion chains and scoring was beyond the scope of this example.

The state diagram can be converted into an implementation following the Gang of Four approach, yielding this structure:

Within Unity, this entire structure (modulo the external MonoBehavior) is contained in one source file, StatefulPlayer.cs. The class diagram reveals the two defining characteristics of the state design pattern:

Each state is represented as an object. In this case, each is defined as a unique class, with an abstract class holding common behaviors and implementations, the result of refactoring.
States are responsible for their own transitions.

To illustrate these points, consider AwaitingRespawnState, the point of which is simply to wait for three seconds to elapse before going back to SpawningState:

class AwaitingRespawnState : AbstractState {
    public AwaitingRespawnState(StatefulPlayer p) : base(p) {}
    
    private float elapsedTime;
    
    public override void Update() {
        elapsedTime += Time.deltaTime;
        if (elapsedTime > 3) {
            player.transform.renderer.enabled = true;
            player.EnterState(new SpawningState(player));
        }
    }
    
    public override void OnEnter() {
        elapsedTime=0;
    }
}

The constructor passes its argument to the superclass' constructor, where that reference is kept in a protected field, player. The Update method overrides the default empty implementation from AbstractState and is responsible for keeping track of elapsed time. You can clearly see that when this accumulated time exceeds three seconds, we go back to a new SpawningState.

There is one point where I had to "cheat" a bit, and that is with animation termination. The transition from SpawningState to PlayingState should be triggered by the end of the spawn-in animation. However, I could not find a way in Unity for a general-purpose end-of-animation observer. I could have set a timer and hardcoded it to go off at the same time as the animation, but this would clearly be fragile to change. My solution was to manually insert an event at the end of the animation, and to have this event call the AnimationFinished method of the player—indeed, that is its raison d'être. This method is also used at the end of the death animation, as shown in the state diagram above.

It is laudable that Unity promotes rapid prototyping with its asset-centric development model, which allows you to go in and fiddle with values with very few restriction. Yet, I find it frustrating to have to deal with literals rather than expressions: without such abstraction, one is left thirsty for more refactoring. My approach for handling animation termination is effective, but it does mean that the entire state model has a dependency on two animations, a dependency that cannot be determined by static analysis of the C# code itself. This is an architectural weakness, but it is the cost one pays for using tools like Unity that prevent one from having to hand-code each and every animation.

Books that influenced my teaching practice

2011-06-11T09:23:00.000-04:00

I've been thinking these last two days about the books I have read in my six years as a professor, and how these books have affected my practice. When I started at Ball State University, I was like a lot of freshly-minted Ph.D.s: I had spent the last several years focused on research with just a little bit of teaching experience, and I had never really been mentored in effective teaching practices, not beyond some TA training just before starting grad school.

Hindsight is imperfect, but if a new CS faculty member were to ask me today what to read in order to develop a better understanding of teaching, here's what I would say. They're listed in the order I read them.

Holub on Patterns. This is one of my favorite books on patterns. It takes the Gang of Four patterns and presents them in the context of two case studies, and these come after two of the best chapters on the philosophy object-oriented design that I have ever read. The fact that the patterns are shown in collaboration is significant: one of my lessons from grad school was that it was very hard to teach or learn the patterns in isolation, because that's not how they emerge in practice. While his book is not explicitly about teaching, the idea of holistic education arises every time I design a learning experience. I think I read it at a very influential time as well: as I was finishing my doctorate and thinking about what kind of professor I wanted to be.

Scholarship Reconsidered and Scholarship Assessed. I read the Boyer and Glassick et al. books when serving as chair of my department's Promotion and Tenure Committee. These should be required reading for anyone going interested in becoming a professor, and university administration should be required to re-read them every three years. Boyer famously describes a taxonomy for scholarship, but I think it's Glassick's book that forced me to think about the extent to which my teaching was scholarly activity.

The Pragmatic Programmer. I wish I could say, "'Nuff said" and be done with it, but I that is insufficient. All computer science professors who have not read this book should do so now, especially if involved in curriculum design and outcomes assessment. Reading this book is as close as you can get to having an expert advise the practice / applications side of the curriculum.

Disrupting Class got me me seriously thinking about the educational complex more than any other book. It's easy to find flaws in the system, but rather than dwell on these, the book addresses fundamental concepts innovation and growth. It raises the important point that organizations protect themselves at all costs, and that disruption can only be achieved by making a market where there was not one before. Several of the ideas from this book influenced my concept of the university sandbox, a place to foster the reimagining of higher education, as documented in the Future of Education Task Force report.

Pragmatic Thinking and Learning is a brilliant presentation on how people learn, focusing on software developers in particular. I would love to know what a non-developer thinks of the book. I found it to be general enough to extract several pieces into completely unrelated teaching experiences, but I also have the benefit of sharing a jargon and mindset with the author and the intended audience.

How People Learn. By the time I read this book earlier this year, I knew most of the big ideas already, having come across them in other readings or through SIGCSE and CCSC:MW. The piece of the puzzle I had not previously considered was the role of culture in learning and the vast, undocumented differences that can exist within superficially homogenous groups. I have always known that my game-related examples in CS120, for example, appeal to subcultures in the class, and so I would try to balance them against other examples, such as economics or sports-related. However, before reading this book, I hadn't considered the deeper issues of how people communicate and express understanding.

This is far from an annotated bibliography, but after reading Spinuzzi's eight-year anniversary blog post, it got me thinking that I should be sharing more about the books I read, and providing more critical evaluations of them. If nothing else, it will help me remember how I've grown and changed through reflective practice, and hopefully it will also help provide a corpus of related work as I continue to document my research.

Predator and Pray

2011-06-10T08:01:00.001-04:00

A funny thing happened at the Conner Prairie Educator Event. I was there with some of the Morgan's Raid team to show off the game to elementary school teachers. The six of us were standing at our table a little before the event was to begin, when an attractive 40-ish woman and her presumed husband approached our group and asked if any of us were suffering from chronic pain or allergies. Needless to say, we were a little dumbfounded. The mind cannot help but wonder why someone would ask such a thing. The amazing automatic pattern-matching machine in my head figured she was a masseuse with healing crystals or otherwise had some snake oil to sell.

She was quite insistent, and no one in my group was biting. Never one to back away from the unusual, I laughed and said she should see me in the Fall, when my allergies act up. She smiled and told us that she had felt that there was some pain among us, and then she asked if she could pray for me.

This was not quite what I expected, but assuming they were not worshipers of some deranged devil-god, I figured it wouldn't hurt, so I said yes. Their follow-up question, whether they could lay on hands, was the obvious next step.

She proceeded to invoke the Holy Spirit, asking for it to cleanse me of my allergies so that I might never have to take Claritin again, because God had created our bodies to enjoy nature and not to fight against it. Then, the Holy Spirit told her that I was also going have a promotion soon, and she asked for God's grace in this as well. Before and after the clearly spoken part of the blessing, the man and woman whispered what I could not hear but I assume to have been speaking in tongues. At some point, the third in their party---who I assume to be the mother of one or the other of these two---took a photograph, which made me wonder if I'd show up on candid camera.

They were pleased with themselves, and I thanked them for the blessing. They were clearly fervent in their beliefs and felt that they had done a Very Good Thing (tm). Since I'm not opposed to the power of prayer, I then asked them to pray for a friend of mine in need, which they promised to do, and off they went.

This was an interesting experience, which of course got some chuckles from the Morgan's Raid team. As for my allergies, I'll admit that they're annoying, but I would not pray to have them removed. I just don't think that's how prayer works. Allergies are part of the human condition. Everybody has their own problems, not because we're bad or sinful, but because we're here. How about prayers of thanks for modern science, from which comes Zyrtec? It didn't bother me that they were so cocksure that my allergies would never bother me again, although I would not be surprised if I spend 1/4 of the year on antihistamines because I have been for over ten years.

The addition of a promise of promotion, though, was too much. Assuming I stay a professor, I will probably get exactly one more promotion in the rest of my career, and it will only come if I chase it. Given that I haven't considered applying for promotion, I find it very unlikely that the Provost is currently writing a memorandum of spontaneous promotion for me. This kind of unsubstantiated, faith-based claim is not only demonstrably wrong, it is manipulative. I'm cynical enough to be relatively unaffected by it (aside from the inspiration to write about it here), but this kind of behavior can wreak havoc on people with low wisdom, as we gamers might say. Maybe, at this point, I should have called them out, let them know that this "Holy Spirit thinking I will be promoted" was BS. What would it have gained? As it is, I held my tongue and gave myself time to consider and reflect on the experience. I'm not sure which is worse: benevolent charlatanism or cowardice in the face of the same.

I'll be sure to post a follow-up once it's ragweed season to let you know how it turns out.

An afternoon with game engines

2011-06-04T19:38:00.000-04:00

After an exciting morning at the XFC, I had an iced coffee and decided to dig into a few game engines. I am looking for technology to support up to three upcoming activities: the digital archaeology simulation mentioned a few days ago, my Fall game programming class (which so far has no plan), and my Spring VBC seminar. This is an informal story about my afternoon explorations, more about impressions than any deep review.

Unity

I started by working with Unity. I had looked at it briefly before, but had not really done anything with it. I was immediately infuriated (yes, infuriated) by this:

I keep my Windows start menu at the top of the screen, where it belongs despite its not being the default position. Unity slams all of the dialog boxes to the top of the screen, and they come up under the taskbar, where I cannot move or close them. Ugh. You know, in Linux I just alt-drag to move any window. For this, I temporarily had to set the taskbar to autohide just to tinker with Unity.

The documentation was high quality, and it didn't take me long to make this:

You can run the "game" and use the keyboard to move the grey box around the blue field. Not too shabby. Note that the scripting language is JavaScript, which is nice since I have passing familiarity with it, and there's a high likelihood that students will have at least seen it before. If not, it's close enough to Java or C# to make progress fairly quickly.

With this impressive start, I started looking at version control, because you should always use version control Unity's own product page lays it out for you: to use external (i.e. third-party) version control systems, you need to get the $1500 Unity Pro (as opposed to the $0 free version), and for an extra $500 per seat you can use their Asset Server. The difference between $1500 per seat and $0 per seat is pretty steep. There are workarounds on various forums, but the long and short of it seems to be that you need the Pro version to make this work.

Torque 2D / Game Builder

Next I decided to look up Torque, which despite having contacted their friendly customer support people and glanced through one of their books, I had never actually used. The main reason for this is that there's a timed 30-day trial, and I never really had set up serious time to evaluate it. My first impression was very good, especially because I am keen on 2D games: that's one less D required for art resources, and my teams are almost always heavy on coders and low on artists.

I started the Fish tutorial, and as soon as I had to start tinkering with scripts, I got worried. First, despite this being an official and apparently-popular tutorial, the scripts and folder structure in the tool were completely different from those in the tutorial: names, directories, functions---all different. I struggled through to a point where it appeared I could start doing some OO scripting, and the tutorial diverged too far from the tool for me to care to go any further. The scripting language was significantly different from what I and my students are used to. Just as an example, functions require "%this" to be sent as the first parameter, and yet they can be invoked via dot-notation on objects:

// Definition
function FishClass::setSpeed(%this) 
{
   %this.speed = getRandom(%this.minSpeed, %this.maxSpeed);
}

// Invocation
%this.setSpeed();

This is not a deal-breaker, but it is quite ugly, and I found the quality of documentation generally to be inferior to Unity's. I will mention that there was an excellent feature in the Torque tutorial in which each step was followed by a link of the form, "If you don't know how to do that, click here." Clicking that would expand a frame containing step-by-step details on how to access the corresponding feature.

I need the documentation to be in sync with the tool if I'm going to throw this at students, especially on a short time-frame project. A good experiment, but time to move on to...

UDK

The mac daddy of readily-available commercial-quality game engines, with incredible university-friendly licensing terms for non-commercial use: basically, no cost. The only real cost with UDK is that it's a bit complicated. After tinkering with Unity and Torque, and glancing again at good old GameMaker (which I taught to kids in grades 2-8 a few Summers ago), UDK is clearly a different kind of beast. I had played with it a little many months ago, and opening it back up, I thought maybe I could recreate the jolly good "move the box with the keyboard" game. No such luck. In fact, I couldn't seem to intuit how to do anything at all. This was late in the day, and at this point I had had enough interruptions to wreck my flow. I brought up some videos and tutorials that I'm pretty sure I had read before, and I remembered bits and pieces of how it works. I also remembered my initial response to UDK the first time I had used it: clearly this is a powerful tool that we could use to build something very tight, but throwing this at a team of undergraduates with no background in any of these ideas would be very dangerous.

Also, I remembered having seen some really high-quality tutorials, including great video tutorials. All these links on the UDK documentation pages are dead. I'll have to come back to it when I'm feeling inspired and the Web site is fixed. I love the idea of using UDK, but I'm afraid of the learning curve.

Slick

I can't shake the feeling that we could always just do it in Slick. The biggest problem with Slick that we had in Morgan's Raid was that it was hard to gain momentum, since we had to do so much ourselves. However, I will have nearly half the Morgan's Raid Spring team on the two big projects (digital archaeology and VBC), and it's tempting to just build off of what we had. The complication with this, which I will discuss in an upcoming post mortem on the project, is that students don't have the experience to do software architecture, and so leaving core engine decisions up to them can have further productivity-impacting consequences.

Something like conclusions

It was a great afternoon of tinkering, though not without frustrations. However, it is good to be reminded of what it feels like to be thrown into an overwhelming interface: this maintains sympathy with the experiences of the undergraduate computer science student.

Working without version control is practically a non-starter for any significant development effort. Spending ten grand on software licenses is definitely a non-starter. This is a shame, since Unity seems to have pulled ahead in the engine wars for projects the scale I am considering. I may have to invest more time into trying some of the version control workarounds that folks have posted so that we can get away with the free version, since there's literally nothing else in the Pro version that I expect I would need.

As always, I am open to your suggestions.

Morgan's Raid Extravaganza

2011-06-02T10:29:00.000-04:00

I uploaded the beta version of Morgan's Raid the other day and did some work to beautify the Web site. Play the beta or find out more at https://sites.google.com/site/morgansraidgame/

The latest Emerging Media Update includes a feature on Morgan's Raid. Find out more at http://emergingmediainitiative.com/updates/may-2011/. The Update includes the following video in which I talk about the project and make a push for broader changes in higher education to promote this kind of work.

What they think they learned, Spring 2011 edition

2011-05-30T10:40:00.001-04:00

After two weeks of frantic activity and a week of relative relaxation, I arrive at Memorial Day with an interest in wrapping up some reflections about the Spring semester.

I ran the final meeting of Spring's CS222: Advanced Programming class similarly to Fall's, which I wrote about back in December. First, the students brainstormed a list of the 80 things they thought they learned through the course. Then, each student was given three votes, and we voted on the most significant items. It should be noted that the students had freedom to choose how they determined what it meant for learning to be related to the class, and so not all of the items fall directly from in-class interactions; similarly, the students could choose any heuristic for voting. The top earners with their total vote tally are shown below.

Item	Votes
Object-oriented design	6
Test-driven development	5
Professional tips	4
Time management	3
Model-view separation	3
Refactoring	3
Mercurial	3

These are all self-explanatory except perhaps "professional tips." We spent a good deal of time in the course practicing and reflecting on how we learn the best practices for a language and environment. I used Java as a language of instruction, and everyone had a copy of Joshua Bloch's Effective Java, second edition. Early in the semester, I gave carefully-constructed assignments in which the students would read portions of Effective Java and apply them. As the semester went on, I loosed the reins, and by the end of the semester, I had the students searching through the book to find tips to apply in their six-week projects. I hope and believe that this kind of inversion of control was useful in helping the students learn how to be better learners.

"Time management" may be worth another mention, since my approach to this was pragmatic. There were few directed exercises that were related to time management, the most prominent being requiring projects to be completed in multiple deliverables. Students, as a subset of humans, procrastinate. Making someone take an incremental and iterative approach can have a huge impact in how they think about their own work, especially when it's the first time having to do this in a software development environment.

After this convergent thinking activity, we returned to divergent thinking as I asked the students to brainstorm on how they learned these things. As in Fall's class, the students seemed to have a harder time answering this question, and I don't think it's just because they were tired. I suspect that, despite all my efforts to foster reflective practice, the students spend most of their cognitive energy on content rather than learning processes. I need to try to find more ways to help students make the leap to metacognition, although I acknowledge that I am limited in what I can do in this sophomore-level course. Regardless, here are the only three of the 22 that earned any votes when each student was given one vote:

Item	Votes
Practice / Doing	7
Working in a group	5
Failing usefully / learning from mistakes	2

Clearly, all three of these are closely related, and they all deal with learning-by-doing, as I expected. Of course, the course was framed around constructionist and studio-based learning principles, and so it's no surprise that students would say they learned from these activities—it's practically all they did!

Here's the part that surprised me: in the list of 22 items, reflective writing did not come up. The students did a lot of reflective writing. The most prominent example was the learning objectives document, which I wrote about in April. In a nutshell, this collaboratively-written document was the medium by which the students' learning was to be communicated with me, and it was explicitly designed for reflective practice. Yet, even at the end of the semester when thinking about their own learning processes, and even when I was trying to steer their thinking towards this while moderating the brainstorming session, no one even mentioned this reflective writing. Far from meaning that this writing was unnecessary, I think this echoes my earlier point, that (generally) the students were not savvy at moving between multiple levels of cognition, from the content, to the thinking about the content, to metacognition.

The good news is that this was an experimental class, part of a research study on how collaborative writing impacts learning in STEM. My co-PI and I have a large amount of data to analyze, and hopefully we can gain insight into what the students experienced and how they made sense out of it.

A Day with Autobeans (or, JSON vs XML for data representation in GWT, Part 2)

2011-05-27T09:24:00.002-04:00

I spent much of the day yesterday tinkering with AutoBeans, a technology that I stumbled across while trying to find a solution to the problems described in yesterday's post. (Thanks, StackOverflow!) The tagline on the AutoBeans describes exactly what I desire: structure, not boilerplate. The problem I always have with XML is that it takes so much plumbing to get the data into the domain model. Keep in mind that I am going to have content experts creating the data files manually, and so ORM tools, Hibernate, etc. won't solve my problem.

Structure

AutoBeans provide a mechanism for automagically reading JSON data into domain objects. I put together a functionally-equivalent demo akin to the XML demo. Specifically, I have a data file that contains the definition for an image and a "hotspot," a region of the image that generates a message when moused over. The data file looks like this:

{
    'image':'Jellyfish.jpg',
    'hotspots': [
        {
            'bounds': { 'left':10, 'right':50, 'top':10, 'bottom':50 },
             'message': 'You found it!'
        }
    ]
}

As before, this file sits right alongside my client source code and is referenced in a clientBundle, to wit:

public interface JsonResources extends ClientBundle {
    
    static final JsonResources INSTANCE = GWT.create(JsonResources.class);

    @Source("demo.json")
    TextResource place();
}

Setting up domain objects using AutoBeans is as simple as it should be: create interfaces using the traditional Java beans naming conventions. My three domain interfaces are shown below.

Compare these to the JSON above, and you can see that there's a strong parallelism: they are essentially two representations of the same semantic model.

The Hotspot and Place are "simple" interfaces, using the nomenclature of AutoBeans. They only contain bean-style accessor and mutator methods, and so they can immediately be deserialized from JSON. The Rectangle class is not simple since it has the contains method. The AutoBean documentation describes how to deal with this: create a "category" that provides an implementation of the interface's instance method as a static method with an extra parameter, as demonstrated below.

public class RectangleCategory {
    public static boolean contains(AutoBean<Rectangle> instance, int x, int y) {
        Rectangle r = instance.as();
        return r.getLeft() <= x //
                && r.getRight() >= x //
                && r.getTop() <= y //
                && r.getBottom() >= y;
    }
}

The last piece of the architecture is the AutoBean factory that wires Rectangle objects into their category. The critical piece for Rectangle is the @Category annotation.


@Category(RectangleCategory.class)
public interface MyAutoBeanFactory extends AutoBeanFactory {
    AutoBean<Rectangle> rectangle();

    AutoBean<Place> place();

    AutoBean<Hotspot> hotspot();
}

This completes the model and serialization framework. The only other critical piece is the UI, which is done with a custom Composite that uses constructor injection to receive its model, a Place. Hence, the whole system is contained in the following class diagram.

I modified my EntryPoint class to use this rather than my SimpleMessage approach, and it is short and sweet:

public class JSTest implements EntryPoint {

    private MyAutoBeanFactory factory = GWT.create(MyAutoBeanFactory.class);

    @Override
    public void onModuleLoad() {
        AutoBean<Place> placeBean = AutoBeanCodex.decode(factory, Place.class,
                JsonResources.INSTANCE.place().getText());
        PlaceWidget widget = new PlaceWidget(placeBean.as());
        RootPanel.get().add(widget);
    }
}

Analysis

One of the problems of dealing with GWT is that there can be a lot of silent errors. There's a sense in which mixing statically- and dynamically-typed code gives you the worst of both worlds. Then again, it might be my own blinders from dealing almost exclusively with statically-typed systems. For example, when I first wrote out the JSON, I called the bounding area 'rect', but when I wrote the domain object, I decided to be more explicit with my semantics and called the accessor getBounds. The AutoBeans system happily chugged along and gave me no warning that I was trying to access a field that was not there, because Javascript doesn't care about that.

The more aggravating error arose from a misconception about JSON. I was in a situation where my rectangles were being loaded, but with the wrong values: (0,0,0,0) instead of my JSON-specified values. I set it aside and played some Witcher 2, which you should buy DRM-free from the good people at gog.com, and then I decided to try writing unit tests to capture the error. The test is very simple, but I'll post it here for the sake of discussion:


public class RectangleTest extends GWTTestCase {

    @Override
    public String getModuleName() {
        return "com.example.archaeology_adventures";
    }

    public void testDeserialize() {
        MyAutoBeanFactory factory = GWT.create(MyAutoBeanFactory.class);
        
        AutoBean<Rectangle> rectBean = AutoBeanCodex.decode(factory,
                Rectangle.class,
                "{'left':10,'right':11,'top':12,'bottom':13}");
        Rectangle r = rectBean.as();
        assertNotNull(r);
        assertEquals(10, r.getLeft());
        assertEquals(11, r.getRight());
        assertEquals(12, r.getTop());
        assertEquals(13, r.getBottom());
    }

}

This test passes, but origially I was specifying the JSON literal thus:

"{'left':'10','right':'11','top':'12','bottom':'13'}"

I thought that all JSON objects were string:string pairs, just because that was my recollection from last Summer's Wave API experimentation. It turns out that if you deserialize that second JSON literal using AutoBeans, it will interpret strings as having the numeric value zero, and hence, give rectangle (0,0,0,0). Again, because this is dynamically typed, there is no warning or error about this conversion: you, the developer, just have to know that this is part of the language semantics. I assumed that there would be some kind of implicit conversion that doesn't happen. Removing the erroneous apostrophes solved this unit test's problem, and removing them from my experimental code fixed the problem there as well.

Conclusions

I am pleased that this technology provides a nigh-seamless way to go from a data representation to domain objects. Because there is little boilerplate code, it should permit rapid iteration much more than hand-parsed XML. It's possible that there's an analogous tool for XML of course, and if you know of one, please share it.

Coming back to the original problem, these data files will be created by non-programmer content-experts, although they will be collocated with the development team. Hence, one of the outstanding problems in the JSON/XML consideration is which of the following is more sensible to non-programmers:

{
    'image':'Jellyfish.jpg',
    'hotspots': [
        {
            'bounds': { 'left':10, 'right':50, 'top':10, 'bottom':50 },
             'message': 'You found it!'
        }
    ]
}

<place>
    <img src="Jellyfish.jpg"/>
    <hotspot>
        <rect x1='10' y1='10' x2='50' y2='50'/>
        <text>You found it!</text>
    </hotspot>
</place>

As always, I welcome your comments.

JSON vs XML for data representation in GWT

2011-05-26T10:14:00.007-04:00

(This is Part 1 of a series. See also Part 2.)

In a few weeks, I will be working with my Morgan's Raid collaborator Ron Morris (History), Mark Groover from Anthropology, and about ten undergraduate students to develop a prototypical digital archaeology simulation. The intent of the project is to create a technological tool to teach 4th-graders about historical archaeology, that it is a scientific process and more than just a dig. I will not dwell on the project design here, but rather I would like to share some of my experimentations with JSON, XML, and GWT.

We want to have the widest possible adoption, and since the expected interactions are fairly simple, making this a Web application seemed best. GWT stands out as an excellent candidate technology since it handles cross-browser issues better than any of our team can. Flash would be a contender, of course, but I ruled it out early since I don't know enough Flash/Actionscript to be confident in leading the team in an appropriate software architecture.

We will only have five weeks to develop the prototype, and the team will include a technical team (mostly Computer Science majors and minors) and a content team (mostly Anthropology and History majors). Unlike Morgan's Raid, in which we could create content directly in Java since the designers were also developers, this project would benefit from an intermediary domain-specific language that the designers can use. An architecture I had kicked around in my head involved using Ruby to define an internal DSL that would be processed in GWT. However, it's not possible to put JRuby into a GWT project since the GWT compiler would try to transform the whole kit and kaboodle into Javascript, and that's not possible or even sensible. I'll just have to find another project in which to experiment with Ruby DSLs; for now it's off the table.

Javascript

Considering a data representation layer, I started by considering how Javascript could be used directly for configuration-based programming. That is, the technical team could write an interpreter on top of Javascript data created by the content team. I played with JSON last Summer when working with the Wave API, and it seemed like a nice way to represent domain objects. Overlay types provide a well-documented approach for using JSON to represent domain objects in GWT. As a proof of concept, I whipped up a simple message wrapper. The interface looks like this:


@SingleJsoImpl(LittleMessageImpl.class)
public interface LittleMessage {

    /**
     * Get the text of this message.
     * 
     * @return message text
     */
    public String text();
}

The annotation references another class that is shown below. Note that Google's documentation, as of this writing, does not make this relationship clear, but a little tinkering with the annotation value revealed the proper approach.


public class LittleMessageImpl extends JavaScriptObject { 

    /**
     * Create a {@link LittleMessageImpl} from JSON text.
     * @param json the JSON string
     * @return new message object
     */
    public static final native LittleMessageImpl buildMessageFromJSON(String json) /*-{
        return eval('(' + json + ')');
    }-*/;
    
    // Required for the GWT compilation process
    protected LittleMessageImpl() {}
    
    /**
     * @return the text of this message
     */
    public final native String text() /*-{
        return $wnd.checkNotNull(this.text);
    }-*/;

}

The two important bits are the factory method, which uses native Javascript to evaluate a JSON string into an object, and the Javascript native implementation of the text() method.

In debugging this program, I encountered a problem where I had called the field by two different names, and of course because Javascript is dynamically typed, I had no compiler support to detect this. To ease debugging, I wrote a nigh-trivial Javascript method, checkNotNull, that behaves like Preconditions.checkNotNull from Guava: if the argument is not null, it is returned, and if it is null, it bombs out. I put this method into a file called preconditions.js that lives in the "public" folder of my project. Making this work took some trial and error, but the crux of it is this: if your application's root package is com.example, then you can put a folder under com/example/public and put resources there, and these resources will be loaded prior to your GWT applications' execution. This is defined in the documentation, although I had a hard time extracting the previous sentence's meaning from what was given.

Coming back to LittleMessageImpl, the json itself sits right in the application: it is not the result of a request to a server, as JSON is frequently used. I made a file message.json that sits in my com.example.client package, and it is referenced as a text resource in my JsonResources class:

public interface JsonResources extends ClientBundle {
    
    static final JsonResources INSTANCE = GWT.create(JsonResources.class);
    
    @Source("message.json")
    TextResource message();

}

Now, to create my LittleMessage, I need only do this:

LittleMessageImpl message = LittleMessageImpl
                .buildMessageFromJSON(JsonResources.INSTANCE.message()
                        .getText());

Like many things, it's easy once you know how.

This was a helpful process for learning how GWT works, but I encountered a problem soon afterwards that perhaps I should have foreseen. One of the actual problems I want to solve with GWT is to have an image that has "hotspots" where, when they are moused over, something happens. This is trivially done in GWT using Image and MouseMoveHandler. The problem, however, is granularity of representation. I would like to be able to represent the image as a composite of hotspots that define geometric regions and actions. I could structure the whole thing as a JSON object, but in Java, I want it broken down into pieces, an InteractiveImage holding zero or more Hotspots, for example. This is where my knowledge of Javascript breaks down. It's not clear to me how I could take a JSON string and, with the same kind of elegance as simply evaling it, end up with a beautiful composite object. Two-pass parsing is of course an option, where the first pass makes a "dumb" Java representation that is then converted into a better domain model, but then you lose the elegance of the overlay types.

From here, I considered diving into Javascript, JSON, and GWT a bit more deeply, but I decided instead to go on a tangent. It's all experimentation, after all. Why not try that nasty old de facto standard for Web application data representation, XML?

XML

GWT has good XML support. It has to. Plus, the XML parser looks exactly like Java's XML parser that I've used a good many times. I had built some confidence from my Javascript experiments and decided to try to solve a real problem this time. My data representation in XML looks like this:

<place>
    <img src="Jellyfish.jpg" />
    <hotspot>
        <rect x1="10" x2="50" y1="10" y2="50">
        <text>You found it!</text>
    </rect></hotspot>
</place>
</code>

I happened to be on Windows when writing this, so I opened up my sample pictures folder and found a nice jellyfish image to use. (Why was I in Windows? To minimize time between experiments and Witcher 2.) Like message.json, I put this file—demo.xml—right in my com.example.client folder, and I load it as a text resource analogously.

Without overlay types, I need to do my own XML parsing. I took what I consider to be a standard approach, making a domain object called MouseablePlace that extends Composite and gave it a public static parseXML(Document) method. This then does rather mundane building of a MouseablePlace from the configuration data, but the result is a beautiful MouseablePlace which contains a series of Hotspot objects, each of which contains a Rect, and these are pulled from the XML via ad hoc recursive descent parsing. To the MouseablePlace is attached a MouseMoveHandler that checks whether the mouse is in any of the Hotspots, and if so, the Hotspot's message is shown in a status label on the screen.

Next steps

Both XML and JSON are contenders to represent the domain objects in this application. For that matter, we could also use an internal DSL in Java, but I would rather keep the learning curve as low as possible for the content team. Whether XML or JSON is more sensible to non-programmers, I have no idea. If we had nore time, we would wrap the whole thing in an editor, but we do not have that luxury.

If you have any experience or suggestions, please feel free to share them in the comments.

[ADDENDUM]
Go to Part 2, which covers my experimentation with AutoBeans.

Inquiry

2011-04-20T08:00:00.001-04:00

"Conventional wisdom holds that different people learn in different ways. Something is missing from that idea, however, so we offer a corollary: Different people, when presented with exactly the same information in exactly the same way, will learn different things. Most models of education and learning have almost no tolerance for this kind of thing. As a result, teaching tends to focus on eliminating the source of the problem: the student's imagination."

Douglas Thomas and John Seely Brown, A New Culture of Learning, 2011, p79.

Education and Industry

2011-04-20T07:55:00.000-04:00

Developing software is the process of learning how to develop that piece of software. As in any craft, there are similarities among projects, yet each one is different and each one enriches the creator.

If learning is an explicit goal of software development as well as the means to its end, then what is the difference between industry and education?

The best hypothesis I have is that there's a value-oriented ordering of goals. In business, shipping a product has preference over improving the team; in the academy, improving the individual has preference over completing a project.

As we transition higher education toward a more enlightened, learning-centric model, I think that it will become increasingly important for us to address these issues—especially considering decreasing public support and the administrative desire for additional revenue streams. Are my students more or less than my apprentices?

No answers, just more questions.

Teaching Assessment Culture to Undergraduates

2011-04-14T13:49:00.000-04:00

My CS222 students are in the middle of their six-week projects, in which they just finished the first of two required iterations. There are three teams, with 4–5 members per team. Last time I taught the course (which was also the first time the course was taught, by me or anyone else), I continued to give rigorous assignments throughout the six week project. This time, I decided to try turning the accountability structure on its head and making the students think about how they would achieve the learning objectives of the project. This inversion of control was designed to foster reflective practice and metacognition.

At the beginning of the project, the students were told that they would have to display competency in the following concepts and technologies through their six-week projects:

Requirements analysis
Unit testing
Acceptance testing
UML: sequence diagrams, class diagrams
Design patterns
Architecture: model-view separation with MVC or Holub-style model-view-presenter
Logging
OOP: encapsulation, polymorphism
Iterative and incremental development
Distributed version control with Mercurial
User-centered design
Programming conventions
Application of expert tips (e.g. Effective Java, Pragmatic Programmer)
Estimation of time to complete tasks, including feedback for improvement
Effective team communication
Technical presentation
Reflective practice

Several of these had been discussed in the preceding eight weeks of the semester, but many had not.

Each team had to create a "learning objectives document" and share it with me via Google Docs. The document was required to express how the students intended to show competency in each of these areas. They were instructed that this would be a living document: throughout the semester, the teams should come back to the document and consider how they would demonstrate competency.

For the first three-week iteration, the documents were rarely updated by the teams. I was using in-class meetings to introduce topics from the list that the students had not yet seen, scaffolding these with some light readings while the students focused on getting their first milestone delivered. Immediately following the milestone deliverable, the students were given the assignment to update their learning objectives document, ensuring that all items have clear and explicit plans for how the team intended to demonstrate competence.

As I looked over their submissions, at first I was disappointed that there was so little of substance. For example, under the topic of "effective team communication," most of the teams said something like, "we get together at regular times to work as a team." In my comments on their work, I suggested that they had missed the target: working together is a requirement, but learning to work together effectively is a learning objective. To show the latter requires evidence.

I believe it was that particular case—though certainly not in isolation—that made me realize a connection between what I was asking the students to do and what I myself have to do in terms of assessment. I will give some background in order to explain the case.

It was about three years ago, while serving as chair of my department's Promotion and Tenure Committee and therefore also representing the department to the College of Sciences and Humanities Promotion and Tenure Committee, that I read Scholarship Reconsidered and Scholarship Assessed. I loved these books, finding in them clear articulations of my intuition. I have used the framework from Scholarship Assessed within much of my work with undergraduates, following the principle that if the point of higher education is to be exposed to scholars and scholarship, then having students become scholars themselves is the best way for them to understand it. These books also made me very cold on the devious connotations of "research," as used throughout the institution of higher education.

Since last year, I have been departmental assessment coordinator. My university, like most others, is attempting a cultural shift towards more regular, formal, and fruitful assessment. In fact, the Future of Education Task Force suggested that we become obsessed with assessment and continuous self-improvement. This is a good thing, and I wholeheartedly agree with the mission. The downside is that I have had to attend umpteen workshops and meetings that re-introduce the fundamentals of assessment, presented to dubious or antagonistic faculty (who, I can only presume, have good intentions but see no incentive to change decades of practice). I have also served on the College of Sciences and Humanities Curriculum Committee, which means I have read tens of assessment plans for new and revised courses. Suffice it to say that I've been bumping into assessment pretty much everywhere I go.

Now, when I look at the task I gave my students, it was clearly an assessment task—yet, as it was in the guise of teaching rather than service or research, I had not consciously connected it to my past experience. Looking at how the students tried to approach the task, I see the same kinds of confusion that is common among faculty and staff who have not adopted a mindset of incremental and iterative development, a perspective that views problem-solving as a form of model building that requires positive feedback loops.

This insight made it easier for me to evaluate their work as novice assessors. I do not think that I adequately addressed how assessment works—that is, how initiating and fostering a feedback loop of self-improvement will pay off in pragmatic terms. The students' learning objective documents did not adequately provide evidence, but without seeing the bigger picture, they had no reason to believe that evidence was worth gathering. This might be best exemplified in a student's response to a note I left in the document asking for more evidence: the student modified the corresponding part of the document and then asked, "Does this satisfy your requirements?" My Socratic response was, "Does it help you demonstrate whether you have met the learning objective?"

While there have been some stumbling blocks in this approach, I am happy with the overall shape of it. Part of my current research is an investigation into the role of writing in STEM classrooms, and this CS222 happens to be part of the experiment. I will be teaching the class again in the Fall, and I am now considering how such a learning objectives document might be introduced earlier in the semester. This should help students get the idea that they are responsible for their learning, putting them on the path of reflective practice as early as possible.

"Object-oriented"

2011-04-04T18:41:00.001-04:00

Reviewing papers for an upcoming conference reminded me how difficult it is to communicate when technical terms lose their meaning. "Object-oriented" is frequently thrown around without so much as a wink or a nod—much less a citation to indicate what someone actually means.

In CS222: Advanced Programming, I have my students read a segment from the first chapter of Holub on Patterns: Learning Design Patterns by Looking at Code. This is one of my favorite books on design patterns and on design in general. Holub adopts a pedagogically sound perspective: rather than present the patterns in isolation as in the Gang of Four book (a manner in which they never occur "in the wild"), he demonstrates the patterns as collaborating parts of a system design. Additionally, the first two chapters of the book provide an excellent introduction to the field of patterns and object-oriented design. On pages 13-14, Holub provides a set of heuristics that can be used to determine if a system is, in fact, object-oriented at all. Directly quoting:

Objects are defined by "contract." They don't violate their contracts.
All data is private. Period. (This rule applies to all implementation details, not just the data.)
It must be possible to make any change to the way an object is implemented, no matter how significant that change, by modifying the single class that defines that object.
"Get" and "set" functions are evil when used blindly (when they're just elaborate ways to make the data public).

Note that he does not say that these are sufficient for good object-oriented design, but rather that a design that does not satisfy all of these is not an object-oriented design. Holub asserts very clearly that this is not a value judgement: OO is not better than procedural. His point is that when he says "object-oriented," he wants to make it very clear what he is talking about. By his definition, almost all ostensibly object-oriented systems that I have seen are actually hybrid designs.

I find Holub's zeal appealing because he leaves no room for guesswork. You can agree with him or disagree with him, but there is no ambiguity in his statement, and it is sufficient foundation for him to build the remainder of the book. Let's not forget the lesson of Humpty Dumpty in Through the Looking Glass:

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'

A memory for knights

2011-04-02T09:11:00.002-04:00

Although this is primarily a place for reflective practice in teaching, sometimes I cannot help but share stories about the intersection of games, learning, and parenthood.

Last night, my son and I went down to The Wizard's Keep, the local game shop, to pick up a special order. We went after dinner as a father-son adventure since he loves to see all the minis and box art. The last time we were there, before Christmas, he was mostly interested in what looked flashy. This time, he was much more interested in what the games were about. For the last few weeks, he has been spending almost all his free time drawing sharks, naval warfare, dinosaurs, knights, and Jedi. Any game featuring such art caught his attention, and so I encouraged him to look for inspiration, to consider drawing some of these scenes later.

When we got home, he produced the drawing below. Note that the parts in blue were pre-existing sketches on this sheet of paper; my son loves to pack as many images as possible into one page.

When I looked at it, I realized he had reconstructed from memory the box art of Runebound: Mists of Zanaga.

We looked at a lot of box art last night, but clearly this one made an impression. I remember pointing out to him that the monster had four arms, which I thought was interesting. In his drawing, he has: a four-armed horned demon-creature; a knight in the foreground with the iconic sword and shield; a hammer-wielding warrior in the clutches of the monster; and a third hero grasping onto the monster's arm.

That he remembered all these details, amid all the other boxes, amazes me. The captured warrior is wielding a hammer. Incredible!

The day my son subtracted

2011-03-21T19:49:00.001-04:00

Alex is four years old. For his birthday, we got him Flea Circus, a fun little card game by Reiner Knizia whose main appeal may be the little plastic dogs and cats that are included. They are the scoring mechanism for the game: dogs are worth two points and cats are worth one. At the beginning of the game, they are grouped in the middle of the table, and as you get acts for your flea circus, you take your points from the middle or sometimes from other players.

The first time we played the game, we explained to Alex how the scoring worked. Points are earned in the 1-4 range, and every time Alex earned points, he would take the appropriate number of cats. Once the cats were all gone, he was visibly confused over the value of the dogs, and we had to "make change" for him.

We put the game away for several weeks, wondering if perhaps the mathematics of the scoring was just a bit over his head. The manufacturer's suggested age is 6+ after all, and the BGG suggested age range is 5–12. When we got it back out and played a few times, Alex did not make a run on cats. He seemed to notice the patterns in how my wife and I scored our points: one was a cat; two was a dog; three was a cat and a dog; and four was two dogs. It was great to see that he had gotten the pattern, partially because it meant there was less fiddling with those awkward, easily-tipped cats. However, his was not a functional arithmetic abstraction, as once we were out of dogs, he was confused about how to count out three points again.

Flea Circus is a fine game, but it's not as much fun as Kinder Bunnies, which we got Alex for Christmas and is his go-to game. We play this game a lot. In fact, we made a scorecard of which is the magic carrot each game since we started playing:

As you can see, we have played 46 times, and Gilligan has proven himself most often to be the magic carrot. (As in Killer Bunnies, the premise of the game is that you acquire carrots, not knowing until the end of the game which is the magic, game-winning one.)

Some of the Kinder Bunnies cards are Bunny Bucks. These are used to activate some other cards, although usually you just hoard them since ten will buy a carrot. Bunny bucks come in different denominations: 1, 2, 5, and 10.

One of the cards allows you to spend five bucks to retrieve and play any card from the discard pile—especially useful when the coveted Take Two Carrots card has been played! Alex had never previously shown any savvy for arithmetic with Bunny Bucks, although he could recognize that the "5" card was enough to use the buyback, and that the "10" card could be used to buy a carrot. Given mixed denominations, though, we always had to point out to him what he could do with it.

On Saturday, we were playing in a group of five with my wife's parents. Alex had four "1" Bunny Bucks in front of him, and he asked if he had enough to use the buyback card. I spread out his cards and pointed out that each was worth one, then asked him to count them, and he noted that he had four. "Oh, so I need one more," said he, nonchalantly. "Yes, that's right," I responded.

That was the day that my son subtracted.

Book Review: Little Wars

2011-03-21T11:39:00.000-04:00

A friend recently lent me H. G. Wells' Little Wars. The book was published in 1913—hence its free availability on Project Gutenberg). As one can tell from the summary on Wikipedia, Little Wars provides a set of rules for miniature wargaming using toy soldiers and model cannons.

What fascinated me about this book was that it contains all of the elements of modern game analysis. He begins by describing the history of the game design, including the inspiration and the evolution of early rule sets. The finalized rules are not presented as cut from whole cloth as in a modern rulebook, but rather as the reasoned and balanced product of a disciplined iterative and incremental design process. That is, although Wells does not use this language, it is clear that he used design thinking as a formula for creating a fun game. A detailed session report is provided, and the entirety is given in-character as a commanding officer rather than the game's inventor: Wells didn't just see the game as a simulation but as an opportunity for role-playing as well.

There are a few places in the book that address gender roles in the early 20th century. Not being a scholar of such things, I do not know if this reflects Wells' sexism or the dominance of traditional gender roles at the time, though I suspect it is the latter. For example, the subtitle of the book is "a game for boys from twelve years of age to one hundred and fifty and for that more intelligent sort of girl who likes boys' games and books." Is the "more intelligent sort of girl" the one who likes boys' games or the one who fights cultural stereotypes to pursue her interests?

I do not know how much other work there was on game design in the 1910s, but I'd wager it was much less than what one can find at the local bookstore today. As an academic and as a "gamer," I would love to see more game design treatments like Wells'. It has a much different flavor than contemporary post-mortems, which tend to deal with lessons learned rather than the human-powered creative processes.

If you have any interest in critical game analysis, I recommend that you flip through Little Wars. The price is right, and it's an entertaining read, both in its own right and as a piece of game design history.

Morgan's Raid Spring Team

2011-03-16T15:10:00.000-04:00

A photo of the Morgan's Raid Spring team, taken at the Ball State University Student History Conference.

Recruitment for the Virginia Ball Center, Spring 2012

2011-03-10T10:22:00.001-05:00

(My proposal to the Virginia Ball Center for Creative Inquiry was recently approved, and so begins recruitment. What follows is the statement I will be spreading around campus in order to recruit students into the project. I welcome your feedback on the announcement itself, and I encourage you to share the announcement with any BSU undergraduates who might be interested.)

In Spring 2012, I will be mentoring a team at the Virginia Ball Center for Creative Inquiry (VBC) in a seminar entitled "Games and Learning: The Underground Railroad." We will be exploring the intersection of play and learning within the challenging context of American slavery. The team will work together to design and develop a game based on the Underground Railroad, a game that is both fun and educational, whose playing and enjoyment will result in a deeper understanding of the theme.

This is an ambitious student-driven project, and its success requires a team of talented and dedicated students. Game development requires creativity and interdisciplinary collaboration. We will need artists, writers, programmers, editors, marketers, managers, musicians, and researchers. The input of historians and anthropologists will be as important as that of designers and technologists.

Our community partner for this project is Conner Prairie Interactive History Park. We will also be visiting the Indiana State Museum, the Levi Coffin House, and the National Underground Railroad Freedom Center.

The VBC provides a unique experience in undergraduate education. It is the ultimate immersive learning experience: students spend the entire semester working together on this one project, meeting in the beautiful Kitselman Center off the main BSU campus. Students earn fifteen credits for participating in the VBC seminar, and the VBC staff and I will work with your major and minor departments to ensure that you continue making progress in your studies through your participation.

The application process involves completing a form and providing two letters of recommendation, with interviews following. Application instructions can be found online .

About the faculty mentor: I am an associate professor in the Computer Science department, and I have been researching game design and development with BSU students since Summer 2006. Our most ambitious project to date has been Morgan's Raid, a history education game for Indiana 4th-graders developed over three semesters. I am interested in software development, board games, computer games, and the science of teaching and learning. Much of my recent scholarship has been on what people learn by creating games, and I am excited to work with an interdisciplinary team at the VBC.

Morgan's Raid in the Indy Star

2011-03-04T09:06:00.000-05:00

Yesterday's Indianapolis Star had a feature on our playtesting of Morgan's Raid at River Birch Elementary in Avon, Indiana.

Here's the link again, in case I was too subtle above. Don't make me write "Click me."

Unit testing Java's System.out output

2011-03-01T20:10:00.001-05:00

This topic came up in CS222, and the resulting legwork may of value to others. I posted a similar message privately to the course discussion forum.

The problem is that the students are writing console applications, but we're also learning about the value of test-driven development. You can unit test console apps much more easily than GUI, but it requires a bit of I/O sleight-of-hand. Your application writes to System.out by definition, and so you need to be able to capture the program's output somehow. There is a System.setOut method that can be used to change where System.out.print* writes. This method requires a PrintStream, and so one solution is to wrap a ByteArrayOutputStream in a PrintStream.

Consider the following example:



public class Exemplar {

    public static void main(String[] args) {
        System.out.println("Num args: " + args.length);
    }
    
}

This program simply will prints the number of arguments sent on the command line. In Eclipse, you can specify the arguments through the Run Configurations dialog.

The unit test for this looks like the following:


import static org.junit.Assert.assertEquals;

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.PrintStream;

import org.junit.Test;

public class ExemplarTest {
    @Test
    public void testMain() throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        System.setOut(new PrintStream(baos));
        Exemplar.main(new String[] { "foo" });
        baos.flush();
        String whatWasPrinted = new String(baos.toByteArray());
        String[] linesOfOutput = whatWasPrinted.split(//
                System.getProperty("line.separator"));
        assertEquals(1, linesOfOutput.length);
        assertEquals("Num args: 1", linesOfOutput[0]);
    }

}

There are three tricks here that may require elucidation.

It's possible for a buffered IO class to cache its result in memory before writing it to a stream. This is a good thing, since writing to a stream is expensive and writing to memory is cheap. However, this can mean that the results you're expecting to see in your stream may not show up when you go looking for them. The call to baos.flush will flush the buffers to the stream so you know the content will be there when we go reading for it. In my opinion, it's not worth remembering exactly which classes require flushing: it's polite to just flush anyway.
You can make a String out of a byte array. It's generally not a good idea due to character encoding complications. In this case, however, we know it's really character data in the array since we're putting it there ourselves via System.out.print commands.
We would like this to be cross-platform, but different operating systems handle end-of-line characters differently. Java gives us a system property for divining this information, and so we can use this to split the String into multiple lines.

STEM Major Production vs. Job Availability

2011-03-01T11:47:00.000-05:00

Later today, I am giving an invited talk on the value of programming to non-CS majors. As part of this, I am going to discuss the current and projected future landscapes for employment in Computer Science. I came across the following chart a few weeks ago in an insightful post by Mark Guzdial. He credits the chart itself to Eric Raymond and the data to 10-year trends published by the Bureau of Labor Statistics.

Refer to Guzdial's post for more discussion.

Save Dr. G

2011-02-28T22:25:00.002-05:00

Human Success and Failure Modes

2011-02-28T16:54:00.001-05:00

Cleaning my office after an unfortunate shelving disaster, I came across a cheat sheet from last semester's CS222 class on which I wrote a reminder to myself of Alistair Cockburn's Human Success and Failure Modes. It seems I can never find this when I want it, so I'm copying it here. Interested parties should read his excellent book on agile software development as a cooperative game. In his book, he presents these as considerations when developing a methodology: a methodology that relies on failure modes is less likely to be successful than one built on success modes.

HUMAN FAILURE MODES

making mistakes
preferring to fail conservatively
inventing rather than researching
being creatures of habit
being inconsistent

HUMAN SUCCESS MODES

being able to look around
being able to learn
being malleable
taking pride in work
taking pride in contributions
being good citizens
taking initiative

At some point, I would like to compare these results to the research on pedagogy and explore the correlation between his workplace-oriented perspective and what is know from the science of teaching and learning. For now, I need to finish cleaning the broken glass off my desk...

Current CS222 students: we'll be talking about this soon, probably once you start up your six-week projects.

See Morgan's Raid at the Student History Conference on Feb 25

2011-02-24T10:48:00.000-05:00

Tomorrow, February 25, my students will be demonstrating Morgan's Raid at the BSU Student History Conference. We will be in SC304, and sessions begin at 9:15, 1:15, and 2:45. Each session will have a short (~10 min) presentation about the ideas behind the game, and the rest of the time will be open to demos and feedback.

Morgans Raid: Sprint 10

2011-02-23T08:31:00.000-05:00

Last Friday was the end of Sprint 10 for the Morgan's Raid team. Here's the burndown:

In Sprint 10, the Sprint Planning meeting was held while I was away at the administrators' retreat, so the students had complete authority. There were a lot of small user stories this sprint, and there was confusion between me and the team regarding whether certain stories were committed but not on the sprint burndown, or whether they had brainstormed some tasks for non-committed user stories. I'm not sure that the burndown chart is accurate: the first dramatic dip may have been a miscalculation. The real lesson here, then, is one of communication: I don't think we talked about the phenomenon adequately until two weeks later at the Sprint Retrospective.

Speaking of the Retrospective, I think the team continues to do great work. I feel that there is a real team identity and that they trust each other. They're really a fun group to work with, and I am saddened when I am called away from them to work on mundane tasks such as committee meetings or advising.

Today, we're heading out to an Indianapolis-area elementary school to do some end-user testing with our current prototype. I'm quite excited about it, and word is that there will be press from both BSU and the Indy Star there. The only downside of the story comes from my efforts this morning to clean up just a few loose ends before the playtesting. There is still a lot of cruft in the codebase, things that should be embarassing but I fear the students still either (a) don't see as ugly or (b) don't consider it worth fixing. Here's an example: there are four different cinematics in the game and they are all driven completely by YAML configurations. Despite the fact that each only differs in which configuration is loaded and what follows the cinematic, folks last semester implemented four different classes for these features via copy-paste coding. In each one, mouse clicks were incorrectly handled by polling in the update method rather than by overriding mouseClicked. To fix the bug wherein mouse clicks were sometimes not recognized, I had to go change this in four places. Since we are literally hours away from end-user testing, the last thing I wanted to do was introduce any risks into the system, but you can bet that before the weekend, someone is going to fix this.

I was inspired by Martin Fowler's recent article on the Tradeable Quality Hypothesis, which can be summarized by the statement, "You cannot trade quality." In the Sprint 10 Retrospective, we talked briefly about how I felt that the students were developing some sense of programming aesthetics, a skill or perspective that I have been contemplating for some time. Working side-by-side with students on design, analysis, and development still seems to be the best way, although it does not scale, and my other job responsibilities are not always conducive to this end.

Brontosaurus and BDUF

2011-02-20T15:01:00.000-05:00

My 4-year-old son loves dinosaurs. He draws them, he pretends to be them, we read about them, we tell stories about them, and today we even we ate pancakes shaped like them. Many contemporary children's books on dinosaurs include types I'm sure I never saw as a child, such as carcharodontosaurus, deinonychus, and one of my favorites, therizinosaurus. My son could also tell you—since it comes up a lot—that there really is not such a thing as a brontosaurus. Turns out, what was called "brontosaurus" was really an apatosaurus, and since the latter name had historic precedent, it was the one that stuck.

Yet, in our family furor for all things dinosaur, we frequently find references to the brontosaurus. My first reaction to such occurrences is usually, "Why don't they know better?" A good follow-up question is, "How would they?" That is, why would the designer of, say, dinosaur-shaped pasta even think to investigate whether or not there really is such a thing as a brontosaurus? Second-order ignorance remains the malady of the ignorant.

My son's love of drawing recently blossomed, and it was initiated by a visit from my father—who, I should mention, is an excellent artist. My dad got my son into drawing, unlocking what must be an artistic skill and passion that skips generations. However, every time my dad drew a tyrannosaur, it was standing upright with its tail on the ground. These were fine drawings in their own right, but they also happened to be wrong. How would my father know that his archetypal dinosaur's posture is scientifically passé?

I was idly considering dinosaurs this morning when an analogy popped into my head: teaching children about brontosaurus is like teaching novice software developers to do Big Design Up Front (BDUF). For years, the status quo assumed software development was like manufacturing, and hence one can measure productivity in man-hours and lines-of-code. As long as you design it right from the beginning, all will go well. Of course, as far back as the 1970's, Fred Brooks was predicting agile methods. Despite the popularity of his essays, I have seen little evidence of their impact (q.v. the CHAOS report) until relatively recently, as "agile" is less frequently used as a profanity. From a modern perspective, we know that software development is the process of learning how to develop that software. By necessity, you know the most about a system when you have finished building it. This is why you always feel like you could do it better if you could do it again, or why you should always build one to throw away.

I look forward to a day when software engineers take a page out of modern children's dinosaur books: any time BDUF is mentioned, there's a an explanation that well-meaning people used to think it was a good idea, but now we realize that its really just a shadow of iterative and incremental design processes. The positive side is that I don't foresee BDUF-shaped pasta ever being included in Software Engineer Mac & Cheese.

Bloom meets Design Thinking

2011-02-17T17:36:00.001-05:00

I have been working on a book chapter the explores many of the themes on this blog, particularly those relating to the Morgan's Raid project. Here is a sketch that did not make it into the chapter: an exercise in comparing Bloom's Taxonomy of the Cognitive Domain to a design thinking process.

I think the idea is compelling, but I have not had the time yet to fully flesh it out. My initial analysis revealed what one might expect: most of the design thinking steps explicitly involve cognitive activity at the highest level of the cognitive domain. Maybe there's something more there, and maybe there isn't. In any case, it was fun to draw.

Scrum Diagram RFC

2011-02-10T14:15:00.001-05:00

I am working on a book chapter on the Morgan's Raid project, and I suspect that a visual representation of Scrum will be of value in explaining how it works. Specifically, I desire an information graphic that illustrates how we specifically have implemented Scrum. The diagram in The Scrum Primer is good but probably overly complex for the intended audience of my work. The CC-licensed one on Wikipedia is too general.

Here is my sketch (CC BY-NC-SA):

Grey boxes represent artifacts and data transformations. Blue boxes are meetings, and blue paths are "human paths". In a sense, I am trying to overlap a data flow diagram with a control flow diagram.

I welcome comments. I'll need to have something finalized within a week, and I'll plan on sharing the final result here, along with a summary of comments if they're received by email instead of posted.

UPDATE: Based on some of the comments, I made this alternative (also CC BY-NC-SA) that shows the data path from the Executable Release (nee Potentially Shippable Product) to the Sprint Review.

Winters at a Glance

2011-02-09T07:56:00.000-05:00

The Star Press of Muncie, IN. Sunday, February 6. Page 1A.

What happens when the temperature drops below 0 inches?

Morgan's Raid, Sprint 9

2011-02-09T07:50:00.000-05:00

Sprint 9 ended last Friday, and the team is doing great. Starting with the Spring semester, we are not using Google Docs for the Product and Sprint Backlogs, since now we have a persistent space in which to work. Since I don't have an electronic log of activity, then, it has become important that I archive a few of the details here.

In the burndown chart, green is steady progress and blue is actual progress. The bump around Monday and Wednesday coincides with the big ice storm, and the fact that we only had such a small bump is a testament to the team's commitment. A few team members were able to come to campus that Wednesday afternoon to hammer out the most ambitious part of the sprint: the implementation of the new raiding system. Others continued to work from home, using email and chat to keep in touch.

The team's total estimate of hours ended up being fairly accurate, although the specific allocation of estimated hours to tasks was off by quite a bit. The team recognized this and agreed to draw upon this experience in the Sprint 10 Planning Meeting. This meeting happened on Monday, but I still know nothing about it since I was at the strategic planning roundtable retreat. I left the team with a prioritized Product Backlog, and I'm eager to see how they chose user stories and broke them down into tasks.

A quick word about bowling

2011-02-07T21:32:00.002-05:00

I just finished the first day of the Strategic Planning Roundtable, which is part of the administrators' retreat here at BSU. I am there as a member of the nascent Strategic Planning Committee, not as an administrator. I hope to write more about this experience in the coming days, but for now I want to share briefly my experience at our end-of-day event. We all went down to Jillian's in downtown Indianapolis for dinner and "crazy bowling."

We were formed into teams, and each frame of the game had a different theme. The first round involved using your non-dominant hand; the next had us throwing the ball without using the fingerholes; and this pattern continued with breakdancing, ballerina, backwards-through-the-legs, and pirate bowling. (By the way, I have determined that this last one is physically dangerous. The constraint is that you hop up to the foul line on one foot and throw the ball, while holding one eye closed. If you are not used to hurling 10-16 pound objects, doing it while on one foot can lead to significant muscle strain. I'm glad I brought Aleve.)

After the game, scores were tallied. When we were told that there would be another round, there was an audible moan. We did then play another round, same as the first, and then the winners got some prizes.

Two things struck me about this experience. The first and less important is that it was not Fun. (I will remind the reader that there are important distinctions between the colloquial "fun" and the scholarly "Fun.") At least on my team, we would have rather just bowled. Big-F Fun emerges---at least in part---from the balance of challenge and skill. Doing these little one-off silly tasks did not give room for skill improvement. The challenge far exceeded our skill, and so we were all just frustrated, essentially relying on random chance for points. As an alternative, knowing that there were prizes at stake, there was always the option to cheat, too. There were some laughs and a few lucky shots, but at least on my team, the general feeling was one of malaise, a frustration at our inadequacy to meet any of our goals and expectations.

This leads me to my second and more pertinent point: we pull this kind of crap on students all the time. We put students into uncomfortable situations, where their abilities will be measured against their peers, and where they have little or no existing skills. They do not know why they are doing what we make them do, and we do not give them the time necessary to develop skills that escalate with the challenge. Some people will cheat, and usually they will get ahead for it. Then, we're off to a new topic or a new class or a new semester, which may seem to have as little to do with the previous one as ballerinas to pirates. "Ballerinas? Pirates? I came here to get better at bowling!"

Now if that was the real intended lesson of the administration in planning this activity, I will be duly impressed.

Aside: I don't mean to be overly critical of the retreat planners' goals: they wanted a nice team-building activity where no one had an unfair advantage. I will be the first to admit that "team-building activities" are not my forte, and the lack of them has probably had negative impact on some of the teams I've formed over the years. I have developed a preference for designing situation where the team feels good about themselves by actually accomplishing something. I try to bring this into my teaching and mentorship by following an early win design: setting up a team so that on the first iteration, they have readily achievable goals that they can feel good about. This has been recommended in several of the agile software development books I've read, notably Cockburn's and Keith's, if I recall correctly.

Sandwich

2011-02-01T14:22:00.001-05:00

When I conceptualize a sandwich, I generally think of it the same way that I perceive it, combined with memory of the flavors, textures, and emotional connotations. However, when I design a sandwich, I approach the problem from the inside out.

What is the feature of the sandwich? Roast beef. The point of this whole sandwich is that it is a roast beef delivery system. Now that I have decided on the feature with the most value, I can approach the rest of the design challenge as one of finding the best complements to the feature.

Cheese? Swiss. Roast beef and swiss just sounds right.

Veggies? Of course! Tomatoes, lettuce, some bell peppers, and for salty complement, a pickle on the side.

Condiments... horseradish sauce. Mmmm.

What's the best way to wrap this up? The bread is a key component, but it is a servant to the rest of the sandwich experience. Sure, sometimes the bread is the feature, like when my wife makes peanut butter and banana sandwiches on graham bread, but not this time.

Regardless of whether I was ordering this sandwich or building it myself, I would have to consider these ingredients in a different order. As a sandwich builder, I need to select my bread first, then spread the condiments, then stack up the fillings.

When you go to The Atrium at BSU and go to the deli sandwich counter, they have a touchscreen display for selecting what you want. It's screen-oriented, with the first (pertinent) screen showing breads, then meats, cheeses, vegetables, and condiments.

This sequence of screens is builder-centric. The order of selection is exactly the order that the staff behind the counter will use to build the sandwich. From each screen, you cannot see the options on the other screens, because they are not pertinent to the assembly-line approach to creating the sandwich.

The touch screen interface is less user-friendly than the paper-based system that preceded it. Previously, any number of clients could grab a sheet, check the meats, cheeses, breads, etc. that they want, put it in the bin, and wait for the sandwich. Now, you have to wait in line behind the single touchscreen station. I find that this pressure adds to my frustration, but I usually approach the counter without knowing what I want. That is, I use the sandwich design experience to explore both the design space and my own desires.

Also, they forgot my horseradish sauce.

Morgan's First Sprint of Spring

2011-01-25T19:42:00.000-05:00

Last Friday was the end of Sprint 8 on the Morgan's Raid project. This was the first sprint of the Spring semester. The "closers" are a team of eight CS majors and our one Honors Fellow from Art. The team were selected from among the 25 developers in Fall's CS315 class. These eight were among the top students in the Fall, and not all were from one team. I am not loaded for running the project this semester, and so I had to limit the number of students I could take on to what I could comfortably manage in my regular assigned research time.

During Sprint 8, we crossed the 1000th changeset, and as of this writing, we're at revision 1037. We had a pizza party at the end of the sprint to celebrate, and I promised the team we would do it again on every order of magnitude. I wonder if Papa John's will still be having their $10 large deal when we hit 10,000?

For Sprint 8, we budgeted 80 hours, assuming each student would work 10 hours per week and that most work would be done in pairs. Unfortunately, I had forgotten about Martin Luther King Day when we did the planning meeting, and so we were actually overcommitted when one considers that we lost a working day. Still, the sprint went quite well, and I think the team did a great job of estimating their tasks, including difficult design tasks such as revising the raiding system through multiple paper prototypes.

Since we have a dedicated space (hooray!), we moved off of Google Docs as a platform for managing the Product and Sprint Backlogs and are now using a whiteboard and Post-It notes. I think the only feature we miss from Google Docs is the automatic updating of the burndown chart based on updated estimates of effort remaining. (This also gives me an incentive every two weeks to post our burndown charts here, so that I don't lose my digital copies.)

The other major change we made was to modify the Sprint Backlog format. In the Fall, teams broke down user stories into tasks and then marked their estimates of hours remaining after each working unit. Whether a task was not yet started, in-progress, or finished was implicit in the numeric value and slope. One of the prominent weaknesses articulated by the team in last semester's retrospectives was the need for more formal validation, and so this sprint, we have a backlog in this format:

User story	Tasks not yet started	Tasks in progress	Requires validation	Done

Formalizing the need for validation helped in Sprint 8, although in the retrospective, we realized that we needed more careful articulation of whose validation was required. With multiple product owners and tasks of varying technical complication, it was not always clear who was the appropriate person to contact. However, I do think that losing Monday to MLK day was a major factor here.

Outlook usability fail

2011-01-19T11:29:00.000-05:00

I was sending out a meeting request through Microsoft Office Outlook today, and I got this warning message.

I used a comma to separate email addresses when I typed them. This is wrong, it is my fault, and I have to go back and fix it.

Outlook can clearly detect the problem, and the QA process revealed that people make this mistake often enough to warrant a specific warning. Yet, there is no way to make the tool actually fix this. Not only is there no "quick fix" button: you cannot find-and-replace within the "To:" field of the meeting request, so a user has to manually go in and replace the commas with semicolons. I guess that is the Microsoft Office usability engineers' way of training us to do things the Outlook Way (tm).

For the love of Morgan

2011-01-17T12:50:00.000-05:00

On Friday, I had to leave the Morgan's Raid team meeting early to join up with my colleagues on the Future of Education Task Force. I stopped in the office today to get some work done and found this note on my door.

I had been a little down on Friday, and I remember saying as much to the team. Lots of work to be done, including a wicked problem for the Task Force, a chapter to write, a course to plan, and the anniversary of a son's birth to celebrate. The team was listening. Good people, these.

Students and Simplicity

2011-01-13T11:16:00.001-05:00

I assigned my CS222 students to read the Manifesto for Agile Software Development and the Twelve Principles of Agile Software. They were to choose two of the twelve principles and reflect on how these are pertinent to them right now, as students of Computer Science. Most of the students selected this as one of their two.

Simplicity—the art of maximizing the amount of work not done—is essential.

From their responses, I got the impression that they know that their approaches from CS1 and CS2 are not the simplest ways to solve problems. However, it was not clear to me if they were searching for the maximum simplicity (as in, make everything as simple as possible but not simpler) or the delusional simplicity (as in, software development should be simpler). I will have to remember to ask them to reflect on this later in the semester, once they have learned refactoring and design techniques and gained experience working in groups on projects of more substantial size.

CS315: What We Learned

2010-12-30T14:26:00.000-05:00

During the "final exam" meeting for CS315, I conducted an exercise similar to the one at the end of CS222. I gave the team 30 minutes to list all of the significant things they learned during their 315 Studio experience, and this resulted in 78 items. The list of 78 were consolidated to 76 to remove redundancy. I gave each student three stickers which they used to vote on the items they thought were most significant. When we isolated the top 10% by votes, we ended up with this list:

Entity system architecture
State-based games
JUnit unit testing
Agile development
Coding for reuse
Scrum

Interestingly, only two of these—the top two—are explicit learning objectives in the course syllabus. The rest deal with the practice of developing a game. Just below these top vote getters were similarly useful tools: Mercurial, Javadoc, and shell scripting.

The surprising thing to me is that there were almost no items listed that dealt with team communication. At the end of each sprint, we held a Sprint Retrospective, during which time the team discussed what went well and what did not go well. Team communication (within teams and across teams) was listed every sprint as something that was going well, and so I assumed that given the opportunity, they would articulate team communication as a lesson learned. I mentioned my surprise in our debriefing after the exercise, and one of the students astutely observed that interpersonal communication was considered a "background" skill, something that was taken for granted. Given more time, I would have liked to have explored this theme, but we were already running late.

I am left with this question: what does it mean that students consider interpersonal communication to be different from other skills developed in the course of a project? Is this an artifact of the university infrastructure, an effect of this particular course design, or just human nature to consider it so? There were no explicit team-building or communication-enhancing activities: there was just the project, run through Scrum, and the associated reflective retrospectives. This might be enough to dismiss the point, since students were not explicitly exposed to interpersonal communication as a subject of study, except that "coding for reuse" was also not separately identified, and this made the top six.

Fall CS222 Redux

2010-12-30T09:48:00.000-05:00

I'm teaching CS222: Advanced Programming again in Spring. Fall was the first offering of the course, and in the grand scheme of things, I am happy with the results. However, I think think there are many opportunities for improvement. The course had two major components:

Daily writing assignments, many of which were based on readings of Effective Java, relating the lessons of that book to current and past programming tasks.
A few small individual programming assignments early, a two-week pair project at the early-middle, and a six-week team project delivered in two milestones.

In keeping with the "2" theme, there are two key observations I have upon reflecting on the course. The first is fairly simple: when we spent some time reflecting on how we learned, reading Effective Java did not come up. I spoke with some students after the meeting who admitted that for most of the class, they saw this as busywork, but towards the end, they could see more how it related to their work. Some students complained that the readings weren't tied to lecture and that they didn't like the "textbook," which betrays the fact that they didn't really get the point: it's not a "textbook," and it was supposed to affect practice, not waste time being reiterated in lecture.

The other observation is more confounding. In the six-week project, there was a milestone deliverable and presentation at week three. I explained to the class that it was purely a formative assessment: it would let them get feedback and see what their grade would be if they turned this in. In addition, the students were given a checklist of the features and ideas I expected to see in the project (such as automated unit tests and evidence of best practices a la Effective Java). Many of the milestone deliverables lacked required elements, and so their formative evaluation reflected this. I was explicit in my feedback about what was lacking. In the final deliverable, at the end of the semester, most projects still lacked those elements that were lacking at week three. That is, there is no evidence that any team actually used the formative evaluation to influence their practice!

In the final analysis, another interesting and perhaps predictable trend emerges: students' grades on the writing assignments were not significantly different from their grades on the programming assignments.

Here are some ideas I'm kicking around for revising the course. I welcome your comments.

More programming projects. They should be programming all the time.
Require programming projects to have accompanying technical reports that explicitly connect the artifact to theory.
Rather than provide goalposts for students to show competency in specific skills, provide a list of concepts and allow students to demonstrate competency in their own way. That is, provide them with a checklist of sorts that they keep throughout the semester, and that I check off when I believe they have shown adequate competency in an area. The course grade then would be directly and transparently derived from this document.
Rather than assign specific sections of Effective Java as I find them interesting, require students to browse the book and understand its structure, then require them to incorporate relevant areas into their programs throughout the semester. That is, replace assigned reading&writing assignments with student-directed inquiry.
Introduce Mercurial very early in the semester and require all projects to be hosted. This way, I can easily pull up any student's project during lecture to use as an example with fiddling with switching laptops or strange computer configurations.
Mandate some kind of individual accountability into team projects, such as modified Sprint Burndown charts. This would help students learn to identify tasks and estimate effort in addition to increasing the transparency of team operation.

The main problem for which I do not yet have a solution comes down to the teams' need for individualized consultation balanced against teams' dominant interests in their own projects. The students develop their own project ideas, and so each project is different. Hence, the concepts and tools that one team needs to succeed will be different from another. For example, I had one team in Fall who were using Android: they would have benefited from more time spent with me discussing how to architect Android applications, but this would probably not have been motivating to anyone other team. By itself this is not a problem, since I could add "work days" to the class schedule, during which time I would circulate among teams and provide more guidance. (Note that office hours inevitably do not coincide with student working hours: they're in class while I'm available to help, and when they're working, I'm at home.) There is an opportunity for students to share their individual findings through class presentations, but I have not yet found a good mechanism for adequately incentivising both presenters and the audience. I do not want to introduce inauthentic artifacts purely for assessment, such as graded quizzes or audience feedback, but I have a hard time conceiving of an authentic incentive that could be used.

For what it's worth, I'm still quite on the fence regarding adding "work days" to the course meeting schedule. The class does not have a scheduled lab component, but maybe it needs one. On this issue, I have a hard time separating my knowledge about teaching and learning, my intuition, and my own K-12 and undergraduate experience. Added into the mix, I am not sure how many of these problems are really due to structural issues beyond my control, namely the fact that this is one of several disconnected learning experiences that students are engaged in. However, this would certainly help with my sense that I was talking too much in class.

CS Ed Week

2010-12-11T08:34:00.000-05:00

Today marks the end of 2010 CS Education Week. I could enumerate all the reasons why this is significant, but it's certainly easier for you to just follow that link and see for yourself.

In honor of CS Education Week, I want to reflect a little on how the field of CS Education has impacted me personally and professionally. I have always had a penchant for teaching, possibly because both of my parents were trained to be teachers. (Not that it's the training that matters per se, but that they both had interest and aptitude in the pursuit.) I had several teaching experiences prior to entering graduate school, and I knew that it was something for which I had a passion. However, entry into the academy is not through a focus on teaching, but rather on the individual intellectual pursuits represented by the doctorate. I spent seven years at the University at Buffalo, first on my masters and then on my doctorate. Although I would occasionally talk with my advisor about my interest in teaching, he sagely recommended avoiding teaching until the doctorate was complete: both are at least full-time jobs, and one who begins a lectureship tends to have much more difficulty finishing the dissertation.

I taught a few courses while at UB, but it wasn't until I became an Assistant Professor at Ball State University that I could really focus in on what it meant to be a good teacher. I found it challenging to keep up with my work on JIVE, partially due to the distance from UB and partially due to the stresses of the new job, being as how BSU is not a research-focused institution: with no grad students to work under me, I was unable to keep the pace of research and development.

My interest in design patterns and games led me to explore the intersection of these ideas with students, and this led to my first CS education publication, "Computer Games as a Motivation for Design Patterns," which I presented at SIGCSE 2007. This was my first time attending the conference, but it was an eye-opening experience. I learned more about education research and realized how many more opportunities I could make for significant research, but most importantly, I was inspired by being surrounded by a thousand CS professors who care deeply about student learning. Most professors are good folks who want their students to learn, but the SIGCSE community is different: these are scholars who have devoted their lives to helping make computer science education better. I'm proud and humbled to be among their ranks.

I have also become involved in the Consortium for Computing Sciences in Colleges, Midwest Region. I think I first went to this conference in 2006, inspired primarily by the idea of bringing a team of undergraduates to the programming competition, even though I didn't know any of the three members of the team. Since then, this has become one of my favorite annual trips, gathering several of our high-achieving students and spending two days chatting about research, education, and life. The regional conference serves a role similar to the international SIGCSE conference: it brings together a vibrant community of dedicated faculty from around the Midwest, and it's always reinvigorating to spend time with them. In fact, this is now my second year as the publicity chair for the conference and my first year as an at-large member of the regional steering committee.

There is a lot of room for improvement in higher education, and so there is a lot of room for improvement in Computer Science education. Thank you to all the scholars who have gone before me and the ones who will come afterwards—this year is my sixth as a professor, and I am proud to have seeded two alumni into CS graduate school who I know will be excellent professors. Thank you to organizations like ACM and IEEE who promote computing. Thanks to CCSC for their support of regional conferences, especially with tight travel budgets being the new norm. Thanks to CSTA for their work in K-12, where there is the greatest need to help students see the value of computational thinking, regardless of their future careers. Thanks to you, dear reader, for considering the value of computing and computer science education.

CS222: What we learned and how we learned it

2010-12-09T14:46:00.000-05:00

I did something experimental today in our last meeting of CS222: Advanced Programming. Regular readers may recall that this was the first offering of the course, not just by me, but by the university; following the SIGCSE mailing lists, I think other departments are starting to see the need for such a course as well. I decided to devote most of our 75-minute meeting time today to a student-directed analysis of what we learned, inspired by the structure that Michael Goldsby used when he led our six-hour Future of Education Task Force meeting.

First, I asked the students to list anything that they learned during the semester that was incident upon the CS222 experience. I told them that it didn't have to be something that was explicitly listed in the syllabus or in our meetings, but anything that was somehow related. I recorded these on a large self-stick easel pad, and as we filled up each sheet, I had my undergraduate teaching assistant post it around the room. We filled eight sheets with 75 items (with one item on the ninth sheet) in just under 30 minutes.

After listing the 75 items, I distributed sticker sheets and asked each student to put a sticker by the three items that were the most important or valuable to them. I briefly explained that this was purely subjective—that they were free to define what "important" and "valuable" are themselves. Based on the distribution, we made the cut-off at four stars, giving us a consensus on the following items as most valuable:

Team programming
Test-driven development
Use of libraries (software)
Refactoring
UML
Design patterns

From these, I asked the students to consider how they learned these. It took a bit of prompting to construct this second list, but we ended up with 13 items. For example, the first item offered was, "by writing code." I asked for more information about the kind of situation the student meant, because many of our ideas are reified in code. He clarified that he meant, "by writing code that uses these ideas." I pushed a little harder into the kind of situation he was describing, and we ended up with, "by writing code that uses these ideas in the final project." Not all of these were articulated as well as I would have hoped, but this might reflect the most interesting part: that the students did not have the vocabulary to describe activities that they thought were useful to their learning.
Each student was given two stars for these sheets, and these four rose to the top:

Lecture-based example that was built upon in assignments
Looking at code as a group in class
By writing code that uses these ideas in the final project
Demonstrations of practice

Disturbingly missing from the entire list of thirteen is any mention of books or the Internet. It seems the focus of student's thinking about learning is classroom-based, despite the emphasis this semester on reflective practice, metacognition, and explicitly learning how to use external (i.e. non-self, non-university) resources. I do not want to jump to conclusions about this, since as mentioned above, the students clearly lacked a vocabulary for describing their learning experiences.

MythTV Upgrade

2010-12-08T20:41:00.000-05:00

I have just completed an upgrade to my MythTV box. I originally set it up in 2007, basing it on Mandriva 2007.1, and it's been running mostly seamlessly since then. I have had occasional problems with session management, in which multiple frontends would start upon boot, but after some tinkering this became a matter of routine maintenance. However, I've been more recently interested in leveraging the streaming options of my NetFlix subscription, and unfortunately, they do not support streaming to Linux. I understand that this must be due to contracts with the content providers, who insist upon DRM. I wish there were a better solution to this, but I honestly don't have one, and the more pragmatic issue was that I was disappointed with my inability to stream video to my family room TV.

A few days ago, I was browsing the Web and came across a mailing list post from earlier this year in which the author describes how he configured NetFlix streaming in MythTV by way of running Windows XP within VMWare Player. I usually use VirtualBox for all my virtualization needs, but the mythtv-users thread suggested that there are impassable audio barriers with VirtualBox that don't show up with VMWare Player. I have a spare Windows XP license, so I installed it on my myth box about two weeks ago. There is a sense in which it worked, but it was painfully slow: the machine only had 512MB RAM on a Sempron 3000, and trying to do anything with VMWare Player caused hard drive thrashing with swap access.

Poking around my closet of abandoned hardware, I found a case from my previous desktop machine and booted it up. Finding everything in working order, I picked up a 1TB drive on a Newegg Thanksgiving deal and proceeded to transfer the Myth hardware to the other box. This one had 2GB RAM and an Athlon 64 3700+, a vast improvement of memory and a significant improvement of processor.

Unfortunately, getting the new system installed was not as seamless as I hoped. I tried many different distributions and each one ended up with some kind of problem. The odd thing is that moving the old hard drive into the new shell worked just fine, and I was able to check that the hardware configuration was working. However, Mandriva 2007.1's ALSA drivers were too old to work with VMWare player, and so the audio was garbled when streaming video.

After quite a bit of tinkering, I started doing more diagnostics of the installation media themselves, and I found each to have an error. It appears that the burner on my workstation cannot accurately burn 700MB CDRoms. Who knew? When I took the ~700MB image and put it on a blank DVD instead of a blank CD (and swapped the graphics card, which may or may not have made a difference but definitely reduced noise), the installation went more smoothly. I still had to specify "nomodeset" as a kernel parameter in order to get to an installer, but now I have a nice shiny Mythbuntu 10.10 installation working great.

Two unexpected changes from the old installation: First, my USB wifi device worked automagically, without having to download any extra drivers or anything. Huzzah! Second, my StreamZap remote control was automatically recognized as a keyboard, but it was also configurable through the Mythbuntu control center. The odd result was that I was getting double input for the four arrow keys. After some digging online, I discovered that I could just comment out the arrow keys in the ~/.lirc/mythtv configuration file, and now it's working fine.

One of the nicest features I originally set up was for the machine to wake itself up to make a recording and then shut itself down afterwards. This way it doesn't have to be an always-on machine. On the Mandriva 2007.1 installation, this was enabled through nvram-wakeup, and because my motherboard was not in the database, this required a good deal of tinkering to get set up correctly. By switching to Mythbuntu and a newer motherboard, it is all done now with ACPI calls. Specifically, I followed the instructions for configuring ACPI wakeup on the mythtv wiki, and this worked like a charm.

Installing Windows on VMWare Player was not a problem, but hooking it up with the MythTV frontend was not as easy as described in the mailing list. I had an odd situation: if I opened a terminal through the desktop environment (XFCE), then I could run vmplayer with no trouble. It generated some warnings, but it started and run without issue. However, if I launched a terminal from mythwelcome or via the mythfrontend button, running vmplayer would generate the same error messages but then do nothing. After many fruitless attempts to fix this, I asked the resident Unix expert in the department, and he suggested I use printenv in both terminals and diff the results. I had been trying to do something similar but in a much more awkward way—always nice to learn a new *nix command! After a few failed attempts, I discovered that by unsetting GTK_PATH, I could start vmplayer consistently.

So there you have it! I have a machine that boots faster, runs quieter, and allows me to watch streaming Netflix movies from the comfort of my living room. It also has four times the hard drive space, so my son can record as many Dinosaur Train episodes as he wants without my wife's America's Test Kitchens needing to be deleted to make room. My original build four years ago was supposed to be built of spare parts, but it ended up costing me about $400 due to my hardware being faulty or having the wrong interfaces. This revision only required purchasing a bigger drive, and the rest was accomplished with existing hardware and elbow grease. Thanks to the Myth community for all the excellent software and resources, thanks to Spencer for the Unix help, and thanks to Paul for the TV tuner cards that allowed me to build it at all the first time.