First week at the VBC, eleven weeks later

Going into the VBC, I hoped to write blog posts about once a week about the experience. The truth is that we work like crazy while we're there, and by the end of the day or the weekend, I find that a good mental rest is in order. Point in case, I was just looking over a few draft posts on my blog—articles I started but never published. Here's one I started in January, in its entirety:

The best explanation I have come up with for my fellowship with the Virginia B. Ball Center for Creative Inquiry is that it's like a sabbatical except that I get to bring students with me. Just over a week ago, I wrote about my anticipation for the start of the semester; now I'd like to share how things actually went.

So much for that.

The inquisitive reader may wonder, "What is it that you do for nine hours a day if it was only yesterday that you were programming?" Here's a glimpse, in no particular order.


We do stand-up meetings every morning at 8:15. Each person reports on what they did since the previous meeting, what they have planned for the day, and what impediments prevent progress. I listen especially for the impediments, though often the ones I hear are not exactly what the students say. I then do whatever is necessary to remove the impediment. This may involve calling meetings, consultations, finding appropriate readings and tutorials, checking the budget, shopping for supplies, and other administrative or managerial tasks.

The team is divided into two bins which we call "The CS Group" and "The Arts & Humanities Group." Each group meets fortnightly to discuss readings, the CS group favoring common readings and the Humanities group individual ones. I sit in on both groups and follow the common reading with the CS students.

I read several blogs and feeds related to the project, and I share the highlights with the team. Some of the sources I've found most helpful are Raph Koster's blog, Daniel Cook's Google+ stream, and Dinofarm Games blog.

I coordinate Thursday Team Lunches. Each Thursday, we all eat lunch together in the dining room and have a topic for conversation, frequently featuring an outside speaker. This is the kind of task that someone who loves event planning could do quickly and easily, but I probably spend too much time agonizing over catering decisions and hoping everyone is happy.

Our Scrum board has four columns: Not Yet Started, In Progress, Requires Validation, and Done. I am frequently used for task validation. For source code, this involves a formal code review. Validation of other tasks is contextual but essentially the same: it is an opportunity for me to look at what the students have done and offer feedback and suggestions.

I try to be available to the team during the day for informal evaluations. Sometimes this is motivated by overhearing conversations from my office, which has no door connecting it to our largest work room. Informal evaluation is done more effectively, however, when I wander through the work areas to see what the team is doing. Quite often, students will pull me in to the discussion to explain something to me or seek my assistance. As with formal validations, I try to use these moments to share what I know as well as help steer the team towards fruitful collaboration.

Occasionally, I directly intervene in game design and interface design issues. Both of these are extremely difficult crafts in which the students are engaged, and it's good for them to have the opportunity to iterate on designs. Because of my own experiences in these areas (read: because I have failed at them and learned from these failures already) I will sometimes see trouble on the horizon and force the students to put on the brakes and re-evaluate.

As Scrum Master, I run the Sprint Planning, Sprint Review, and Sprint Retrospective meetings that happen every other week. I also serve as Product Owner, organizing and prioritizing the Product Backlog—the list of user stories that guide the team towards successful project completion.

Several of my VBC students are searching for jobs and internships, as are some of my best students who I could not bring with me. I've written letters of recommendation and provided references for many of them, and I'm glad to say that the effort has been mostly fruitful. I hope those who are still looking for employment and internships get some good news soon!

Since we've been building digital prototypes, I help with quality assurance. I run the game and try to break it or look for usability flaws. There is a defect board in the main work room on which we record such issues, and the team is pretty quick to fix them.

I make the coffee almost every morning. Earlier in the semester, I noticed a disturbing trend wherein people would arrive very close to 8:15—the time of our daily stand-up meeting—but still try to make coffee before coming to the meeting. They would end up coming into the stand-up late, though happily carrying a fresh cup. I realized that I could circumvent this problem by showing up a bit earlier myself and starting the coffee, even though I bring my own from home. This is a nice example of proactive removal of unarticulated impediments.

My non-VBC responsibilities still exist too, of course. I have had a paper accepted at FDG 2012, and I had to spend some time revising it for publication. I consult with my advisees over email or by appointment. The Mira Award nomination that Ronald Morris and I recently earned was the result of writing thousands of words on the Morgan's Raid project as well as a formal presentation. I talk to my department chair a bit over email about important issues such as curriculum and assessment. I also served on a search committee for the first time this year, and I'm excited to have a new colleague joining the department in the Fall. Early in the semester, I continued to serve on the Strategic Planning Committee.


So there you have it: a quick sketch of what has occupied almost all my waking hours since January. It has been an incredible experience. Since the very beginning, I have had a deep sense that, professionally, it is where I belong. I try not to think about the fact that I'll be going back to the regular grind of higher education in a few weeks, but that's the topic of another post.

The Frisbee Analogy

I have spent a lot of time looking over the source code for the VBC project, both informally and through formal code reviews, but yesterday was the first time I personally contributed code. One of the non-CS students was working on revising the game's introduction, putting in some placeholder stills in preparation for a meeting with our community partner. She was looking for a way to easily advance through the images as in a slideshow, and so I offered to whip up a script to do this, which I did. I reported the activity during this morning's stand-up meeting, and I used the opportunity to remind the team that I was available for this kind of help. I ended up spending about six hours today in the trenches, working on my own code as well as helping others to write or refactor theirs. It was much more hands-on than the kinds of reviews the students tend to request. I really enjoy working side-by-side with the students, and it makes me feel immediately and undeniably useful. The teaching moments percolate up from the problem domain as well as the problems introduced by novice developers.

We have had an informal tradition of after-lunch Frisbee at the VBC, a tradition that is greatly enjoyed by all participants. We postponed today's to end-of-day Frisbee, which gave us the opportunity to finish all of our milestones for the day, which we did. As we were playing, one of the students pointed out that without bad throws, there cannot be great catches. By extension, if everyone threw perfectly, there could be no stellar catchers. Another student—one with whom I worked on several pieces during the day—pointed out that this was like their relationship to me. Their programming is far from perfect, but they know that I'm a seasoned catcher who can keep the bad throws from ruining the game. It may be one of those analogies that one has to take at face value, but I'm impressed by the capacity for analogical thinking and honored to have been part of it. After all, my programming skill is clearly greater than my Frisbee skill.

The Components and Systems of Morgan's Raid

I've written before about the entity system architecture of Morgan's Raid. I am just now polishing a paper on the topic which I will present at the FDG conference in May. I contacted Adam Martin to get his feedback on the paper, and he was very helpful. He made a few suggestions that I simply did not have space to address in the eight-page conference paper, but since Blogger has no page limit, I would like to address one of them here: what are the actual components and systems of Morgan's Raid?

By way of simple introduction, an entity system architecture is a software architecture in which game object data is stored in simple objects called "components" and these are processed by "systems." Game objects then are simply unique identifiers that aggregate components. This approach favors delegation over inheritance. It proves useful in game development due to the highly experimental nature of such systems: the domain model itself is subject to dramatic change during practically every stage of development. For further discussion, check out the entity systems project wiki.

Numbers of components and systems during development

The figure above shows the growth of the number of systems and components during the development of Morgan's Raid. This figure appears in the paper with a brief interpretation. I provided the small initial set to help bootstrap the students, but most of the rest were written by them—the 25 developers who worked in Fall 2010 and eight who worked in the Spring 2011. I am very proud of the team, don't confuse my pride in their achievement with any claims of elegance and beauty. Indeed, there are quite a few smells in our implementation.

Without further ado, tearing into the source code of Morgan's Raid, we can see how the systems and components are related. (It appears that Blogger automatically scales large images down. You can grab a full-size PDF here.)

System-Component Dependencies

The systems are on the left and components on the right, with edges showing system-component dependencies. As evidenced by the diagram, there are a few components which are heavily used throughout the implementation. OnScreenBoundingBox, for example, is used by anything that involves bounding boxes. (This was originally called Position, but that caused serious confusion when dealing with world vs. screen coordinates. After refactoring, we ended up with OnScreenBoundingBox and GPSPosition, the latter because world coordinates were actual GPS coordinates.) There are a few systems that have no out-edges because they use no components at all. For example, FadingSystem handles the fading of the screen based on time of day, but it does not deal with a component explicitly: it is passed a long integer that represents the current time of day and performs its computation from that.

Several of the components have no in-edges. A handful of them are, sadly, rotten code that was never removed. In fact, some are added to game objects and never accessed by anything else. Others of these disconnected nodes are used directly by the non-system game code. The Morgan's Raid implementation reifies the state design pattern, and there are many places where critical game logic was done directly within these classes rather than delegating to explicitly named and tested systems. This is not ideal, and I ascribe it to the novice level of many of the developers. Ask anyone on the team what they think about the 1700-line behemoth InGameState and they will cringe and tell you it should have been done better, but at the time, they did not know how to actually make it better.

In the diagram above, I have hidden the inter-system and inter-component dependencies for one very good reason. When they are shown, the diagram becomes a bit of a mess. Check it out (or full-size PDF here).

System-System, System-Component, and Component-Component Dependencies in Morgan's Raid

Ignoring for the moment the fact that you cannot discern the system-component dependencies, this diagram does show that the number of system-system and component-component dependencies is relatively low. However, if I were to throw InGameState into the mix, it would have its fingers in practically everything.

The diagrams were generated with dot, and you can download the graph file here. (Note that Google Docs thinks this is some kind of Microsoft file due to naive handling of file extensions. Just download the original and open in your favorite plain-text editor.) I created that file manually by inspecting the Morgan's Raid source code, and so it may contain minor errors.

For your reading convenience, here's a simple tabular view of the systems and components as well.

Systems

Components

BackgroundTileSystem CityNameSystem DestinationSystem FadingSystem GPSToScreenSystem HoverableSystem ImageRenderingSystem IntInterpolationSystem MinimumSleepTimeSystem MorganLocationSystem NightRenderingSystem OnClickMoveHereSystem OnScreenBoundingBoxSystem RaidSoundSystem RailwaySystem ReputationSystem RevealingTextSystem SpeedSystem StepwisePositionInterpolationSystem SunSystem TimePassingSystem TimeTriggeredSystem TownArrivalSystem TownArrowSystem TownUnderSiegeSystem

AnimationRenderable ArrivesAtTownIndex BackgroundTile BeenRaided CentersOnGPS CityData CityImages CityName CityPopulation CityTargets CommandPoint Destination DoesCityHaveMilitia DoesCityLoseGame DoesCityWinGame GPSPosition GPSPositionList HasMorganGPS Hoverable ImageRenderable ImageRenderLayer InGameTime IntInterpolated MinimumSleepTimeOverride Morgan MorganLocation MovesOnClick OnClickMoveHere OnScreenBoundingBox OnScreenBoundingBoxList PositionInterpolated Raidable Raider Railway Reputation ReputationValue RevealingText Road RoadsToCity RouteTaken Speed Sun Terrain TimeToRaid TimeTriggeredEvent TownAdjacency TownArrow TownUnderSeige

Family Gaming Retrospective: Shadows Over Camelot and Inching Along

My son, Alex, is five years old, and he loves to play board games with us. I have written before about some of the games we like to play together, his memory for box art, and how games revealed his ability to subtract. I want to take a moment now to share an odd juxtaposition of gameplay experiences: playing Shadows Over Camelot followed a few days later by Inching Along.

The Games

Shadows Over Camelot

Shadows Over Camelot is a cooperative board game, famous for its use of a traitor mechanic within an Arthurian setting. It was released in 2005 by Days of Wonder and designed by Bruno Cathala and Serge Laget. I bought a copy for my VBC seminar, specifically for the traitor mechanic. Some of the students tried it, but I had not played it at all until bringing it home over Spring break this week. It supports 3–7 players, and I was hesitant to suggest it for family play with Alex given the publisher's minimum recommended age of 10 (also 10 at BGG). However, once Alex saw the box, he asked if it was something he could try. The boy does love swords and shields. Having reviewed the rulebook, I figured there'd be little harm in it, so the next day we set it up to play—Alex, my wife, and I.

The main gameplay of Shadows Over Camelot involves collecting Fight cards, which range in numeric value from one to five. Different quests require different combinations of cards: two pair, a five-card straight, full house, etc. To prepare Alex to play the game, I asked if he knew what a "pair" or "three-of-a-kind" meant. He was unsure, so I taught him a simplified version of five-card draw. A few days later—after having tried Shadows Over Camelot—he suggested we play poker again, so it seems that also caught his interest.

Alex is just learning to read, and so he needs help interpreting many of the special, non-Fight cards. After three games, he was able to recognize a few words, such as "Pict" and "Mercenaries." These are good words to know in any context, to be sure.

Moving between quests is an expensive proposition in Shadows Over Camelot since it requires spending a whole turn, and that's a turn during which the knights are not making measurable progress towards victory. As a result, at least with our three-player games, we found that it was often more advantageous for an individual with the right cards to jump on a quest opportunity rather than go in squads. Alex picked up on this rather quickly. We had a few disagreements about what strategies were best, and sometimes he listened to our advice, while other times he went his own way. This was a strength of the game, that the rules of the game encourage discussion while each player retains agency.

Our third game of Shadows Over Camelot

We won our first game, though we had accidentally bent the rules in our favor. The second game was a rather quick loss, as our early acquisition of the Holy Grail, Lancelot's Armor, and Excalibur led to the accumulation of twelve siege engines outside Camelot—a loss condition. The third game was very close, and it looked like we were heading to loss even after sacrificing Excalibur. Then we realized that we had one chance at victory, and that was for Sir Percival (Alex) to sacrifice himself, dropping his health to zero to prevent loss by siege engines, after which I, as Sir Gawain, could play the final Fight card to complete a quest and win the game. We explained this to Alex, and he was happy to do so. We congratulated him on his self-sacrifice that allowed our side to collectively win the game. Indeed, the rules clearly state that everyone shared the victory, even the departed knights. At this point, my younger son awoke, and Alex ran upstairs, nearly shouting to his brother, "Guess what? We won the game, because my guy defeated himself! Isn't that strange? How can a guy defeat himself?" So, I am not completely sure what he learned from the experience, but he definitely seemed to grasp that he had given his side a chance to win by making a difficult decision.

Inching Along

That leads us to Inching Along, a board game by Kathy Harding published by Educational Insights. Since the game has no entry on Board Game Geek, I will take a moment to explain it. It is a competitive board game in which each player has a character that is moved along a track that is numbered 1 to 75. There are also eight straight lines scattered across the board, labeled "A" through "H". On your turn, you flip over a card, which will tell you how far to move forward or backward. These are expressed in terms of the lengths of the lines, so if you flipped over "Move Ahead A + D", then you would measure line "A" and line "D", add those values together, and move forward that many spaces.

Inching Along

Playing this game involves no decision-making. It plays very much like Candy Land except with a ruler and arithmetic instead of colors. Without having had the experience of playing it, I would have dismissed it as homework dressed up to look like a game. However, the fact remains that Alex seems to really like it. Unlike my wife and me, he has not decoded the mechanics to realize that there's no challenge here. It's much like Raph Koster's example of tic-tac-toe in Theory of Fun for Game Design: it's fun until you figure it out, and then it isn't. The mechanics of the game are not dressed up at all: flip a card, measure, move. There is no narrative and no pretension. This makes it less painful to play than The Tick: Hip Deep in Evil, which Alex frequently asks to play, but which similarly provides no meaningful decisions.

Detail from the Inching Along box

The box for Inching Along proudly proclaims that it was "invented by a 1st grade teacher." The publisher is in the business of making resources for teaching, so this is an important bit of marketing for them. I can't help but wonder what other games would look like if the designer's professional background was prominently displayed on the box. Every Reiner Knizia game should say, "Invented by a former banking analyst!"

The Metagame

I enjoyed Shadows Over Camelot as a cooperative board game, and I certainly prefer it over Inching Along. Reflecting on the experience of playing both of them with my son, I realize that both provided the opportunity to play an interesting metagame: the game of teaching the game. To help Alex make sense out of Shadows Over Camelot, I introduced poker. That is, I used the game of poker explicitly as a learning tool, knowing that by playing poker, a player learns certain patterns. If my memory is correct, I learned to play card games like poker, blackjack, and cribbage long before I played any interesting board games. When faced with the immediate challenge of teaching Alex about these patterns, I fell back on the game I used to learn them. One might argue that learning these patterns for Shadows Over Camelot might have been more effectively done by simply using the Shadows Over Camelot cards, and one would probably be right!

We have been trying to find ways to motivate Alex toward reading, and it appears that playing Shadows Over Camelot reinforced the utility of literacy. By the third game, he was able to mostly keep his cards secret, although he often would announce what he drew when he drew it. The pride in his voice as he recognized the cards was worth sacrificing the secrecy of his cards. When it comes to matters of cooperation and sacrifice for the greater good, I dare not make any grand claims, but I will say that it has already given us  a spike in the ground when talking about such complex issues.

The metagame of Inching Along is thinking of clever ways to embed mathematical lessons into the gameplay. At five years old, Alex has shown some facility for mental arithmetic with small numbers, but being asked to move forward the sum of 11 and 12 is more than he can manage in his mind. In the foreground of the photo above are some blue glass beads that we use as manipulatives to illustrate addition and subtraction. We had tried an abacus as a simple way to move beads around. I personally found this much more difficult due to  the arrangement of beads on rows, when I wanted to cluster them in more intentional ways not afforded by the rack structure.

We also had a pad of paper where we showed how two-digit numbers can be added by adding their digits separately. I don't think this algorithm stuck with him, but it did provide practice at talking about rows and columns while practicing properly holding a pencil and drawing digits. Even just the practice of using a ruler was certainly good for him, since from time to time he would try to count from the "12" end instead of "0".

Parting thoughts

At about this point in the post, I feel compelled to add a "Conclusions and Future Work" section, for which I can blame the brainwashing of my profession. I'm eager to try Shadows Over Camelot with some people who are a bit older than my own kids so that I can see the traitor mechanic in action. With three players, there is very little room for mistakes, and I suspect (and have heard) that the traitor is very powerful. I have also heard that Battlestar Galactica has an even better implementation of a traitor mechanic, but I feel like I should not play that until I've watched the series for fear of spoilers. Along these lines, I have been seriously wondering whether I should withhold my various Lord of the Rings games from my kids until they read the books.

I have no great desire to play Inching Along again until my younger son is old enough to measure, but I am glad to know that I can talk to my elder son about adding, subtracting, and measuring... but I can't shake the feeling that it's cooler to be able to talk about Picts and mercenaries.

Four happy stories

Here are four happy, short stories from the last few days.

1- I came into my office the other day  and found a bag of freshly-roasted coffee beans along with a note. They were left by an alumnus from several years ago for whom I recently wrote a letter of recommendation. I'm drinking a cup of this coffee now, and as I sip it, I remember the great experiences this alumnus and I had during his undergraduate studies and think of all the great things he will do during his career.

2- A more recent alumnus recently contacted me to ask if he could have access to the assignments he did in one of my courses. He wants to use them to hone his skills as he continues his job search. It's great to see these assignments find utility beyond the initial constructed learning experience.

3- Yet another alumnus just announced that he got into the doctoral program of his dreams. I had worked closely with him in his undergraduate years and have great faith in his potential, as I mentioned in my letter of recommendation.

4- In the morning, a team working in Unity3D described a software design problem that—unbeknownst to them—is perfectly solved by the state design pattern. I pointed them to my blog post on the topic, and after they read it, I provided a bit of design help. By the end of the day, they had developed an understanding of both the state and observer patterns by incorporating them into the project.

There are a lot of places to read about the problems in higher education. I know—I've spent a lot of time reading them. For today, though, I want to share these more uplifting stories. These kinds of stories make me proud to be a professor.

Visual representations of team prototyping efforts

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

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!