Spring 2013 Game Studio: Modeling the first feature with UML and CRC Cards

Last week, the Spring 2013 Game Studio built physical prototypes to address specific questions about game dynamics. We tested these with our target age group on Monday, compiling and disseminating the results just in time for Tuesday morning's Sprint 2 planning meeting. Whereas the first sprint was all logistics, pre-production, and technological inquiry, the second sprint sees the team facing its first features. In particular, the first feature in the sprint backlog is, "As a player, I want to assign my villagers to farming."

The team identified the following tasks as necessary to complete this story:

• Design the user experience
• Implement the user interface
• Design the domain model in UML
• Implement the domain model with unit tests
• Bridge together the domain model and user interface

In this way, the team set up two roughly parallel tracks: user-facing and domain modeling. I was scheduled to meet with a group yesterday morning to mentor them through the initial domain modeling step, but we ended up postponing this for two reasons: team members encountered unexpected complications in the asset pipeline we wanted to use, and the user experience ideas were not yet sketched in sufficient detail to ensure that we were safe to move forward.

This morning, two of the technical team and I cleaned a large section of whiteboard and began our UML process. I suggested that we start with use case analysis. In our discussion, I discovered that both of these students are also in the department's Software Engineering class, where they had recently had an introduction to UML, so we did not need to start  from first principles. We sketched six use cases.

Use cases relevant to our feature

I explained that it was common to do dynamic modeling next, and that the static models would fall from this. They were both familiar with sequence diagrams and were eager to use them, but I explained that I prefer communication diagrams—especially when I'm not quite sure where I am going. We started with a Village object and began to talk through the use cases to determine the behaviors. We added an object, showed a message, removed the message, added another object, added a new message, removed it, and added another, ... and then I realized that this was the wrong tool for the job. Our conversations were good, but our notation was just getting in the way of the exploration.

It hit me that we needed CRC Cards.

One of the two students had taken Advanced Programming with me during a semester when we used CRC cards, but he was rusty; the other had never heard of them. I gave a primer and made a template to show  the class, responsibility, and collaborators sections and their purpose. We got a stack of orange index cards, put them in the middle of a mid-sized table, each grabbed a pen, and got to work. I showed how once again we could start with the concept of Village, and we marked that it maintained a list of idle villagers. From here emerged our Villager class, which we marked as having a status of "idle" or "farming."

Something seemed wrong, so I stopped the discussion there and looked over the cards. We were defining attributes, not responsibilities. Starting again from scratch, I explained that we wanted to focus on the messages that were passed among objects, not the internal representations. This led us to a nice small set of seven classes that fell out of our conversation.

CRC Cards for the first feature

We picked up the cards and moved back to the whiteboard, where we designed an initial class diagram. This is mostly their work, with my prodding them to consider only the public details for now. The most interesting interaction described in the cards is between Clock and Farm: a farm generates food based on elapsed time and the number of workers. As we talked about it, I pointed out that it sounded like the Observer design pattern: as the clock ticks, it notifies listeners, and they react as they need to. I showed them how to sketch that architecture and identify the pattern using collaboration notation, as I picked up from Holub on Patterns years ago.

UML Class Diagram derived from the CRC Cards

At the conclusion of the session, the two students expressed confidence that they could continue this process with the next feature on the backlog. Notably, they mentioned being confident that they could do it and that they could involve other members of the team. It's a sharp team, and I look forward to seeing how these "big ideas" get disseminated across the group.

Essential Questions of an Advanced Programming Course

I have been following Grant Wiggins' blog for a few months now and familiarizing myself with the fundamentals of Understanding by Design (UbD). It has not been a rigorous scholarly investigation, but I have enjoyed reading Wiggins' posts and thinking about how they connect with my experience and expertise. A fundamental tenet of UbD is what they call "backward design," which is the idea that you start by defining your outcomes and then build lessons and curricula to support that. While this may seem obvious to some, my experience resonates with the claim of Wiggins and McTighe, that many (or most) teachers start with the content and focus on how to cover it. This is certainly true in higher education, where the "covering content" is tends to dominate curriculum discussions, and "teaching a book" is an established part of our discourse.

Two days ago, Wiggins posted On geniune vs. bogus inquiry—using EQs correctly, the continuation of a series of posts, this one focusing on Essential Questions (EQs). I found the essay particularly thought provoking as I am currently looking over several syllabi in my department: Computer Science 1, Computer Science 2, Advanced Programming, Discrete Mathematics, and Introduction to Algorithms. The Foundations Curriculum Committee is looking over some assessment data to determine whether we need to shift emphasis in any of these courses or articulate their objectives more clearly.

The Advanced Programming course in particular falls under my purview. For those who don't know, this is a home-grown course designed around a specific set of problems: students coming from the intro courses (CS1–2) are generally ill-prepared for medium-scale collaborative project-work in the upper level of the curriculum. All students take a year-long project-based senior capstone course, in which they work in teams with a community partner, but this is at the end of the curriculum, so there's a gap in the middle where faculty who want to do project-based learning had been left in the lurch. Enter CS222: Advanced Programming. The syllabus for the course identifies learning objectives regarding interactive debugging, testing, build configurations, and projects of significant size; a revision proposed for next academic year includes more specific learning objectives regarding test-driven development, distributed version control, code review, object-oriented design, and model-view separation. We have been teaching this course for about three years, and I think the results have been positive. The major hurdle we face, internally, is educating the other faculty about how they can take advantage of what the students learn in this course, but I'm hoping to address that in a colloquium presentation this semester.

Reading Wiggins' essay made me reflect on the fact that the tools and techniques described in the syllabus answers. What are the essential questions of our Advanced Programming course? I was so inspired by this issue that I posted a link to the essay and some provocative questions for alumni to Facebook... on a Friday night, where it was quickly lost, and hence my migration to a longer form here.

In a bit of casual reflection, here are some essential questions that I am considering:

• How do small teams of developers coordinate activity?
• Is it sufficient for a program to be syntactically correct and meet functional requirements, or is there more to the definition of rightness?¹
• What does it mean to be "professional" in software development?
• How does a Computer Science professional use ubiquitous and chaotic information to be a lifetime learner?

This is my first time trying to articulate Essential Questions in the tradition of Understanding by Design. I would love to hear what students, alumni, and software development professionals think about these questions. If you have a contribution, please leave a comment!

---

¹ I chose not to use the word "correctness" because I'm dealing with practical development issues, not theoretic program correctness.

One and a half days of rules design

On Monday, the as-of-yet-unnamed Spring 2013 Game Development Studio approved a concept document   that will serve as a spike in the ground. Tuesday morning, we started with detailed rule design. Aside from a few afternoon meetings, I was able to spend the day with the team, from about 9:30 to 4:30, working on rules articulations. They kept on going in the early evening, and when I came in this morning, we picked up the process and finished the core rules articulation by around 2:00 P.M.

Game rules, one of four

I should be clear about who "we" are. The team has a shared space, thanks to the generosity of the Computer Science Department. However, we don't have a shared time that everyone is there. Rather, people come and work for a few hours when they can. Over the last few weeks, we've seen a "morning crew" and "afternoon crew" emerge, but that's a very rough description: many students come to parts of both, or even put in evening hours. As a result, much of what I do is help facilitate communication across these groups. A few times in the last two days, I've been the only person who was present in a morning conversation when a later group is looking at the rules.

Game rules, two of four

The team has done a laudable job. This is hard work, made logistically difficult by the lack of shared time, but I see that the team has grown to trust each other, and to evaluate design artifacts on their own merits. In a sense, there may be some value to the chronological distribution, since an artifact has to be evaluated by itself rather than defended in person. As the team worked on the rules, a cogent game design emerged. Several modifications and clarifications were made along the way, and some rather major revisions as design "holes" were found. There was a little bit of confrontation, but it was all very healthy and led to great outcomes in terms of both the design and the learning.

Game rules, three of four

Here are a few one-paragraph highlights:

Yesterday, we were dealing with the nature of warfare among the Middle Mississippians. In particular, we were looking for information on the palisades they built and the reasons they may have raided. At one point, I was in the room with four Computer Science Majors, and each one of them had his nose buried in an academic book—yes, a book—about archaeology, anthropology, and Middle Mississippian culture. I wish I had thought to take a picture. When I told my collaborator, History professor Ronald Morris, about this, I think it brought a tear to his eye.

Game rules, four of four

Mid-morning, we were trying to tackle the problem of the scale of the game world and the distribution of resources. I encouraged the team to use the whiteboard or one of the tables to physically lay out pieces, in such a way that they could be easily moved around. One of the students went almost-immediately to the "prototype" drawer of the file cabinet, pulled out another student's prototype that involved lots of paper chits, and dumped them on the table. This strikes me as significant evidence of learning and team work: the student remembered his teammate's prototype, realized it met our immediate need, knew where it was filed, and brought it to bear to solve the immediate design need. Another student went to the box o' stuff and pulled out a VGA cable, which became the river. In doing this, the team realized that while we had talked about having rivers on the map, we had never discussed the river with respect to villagers' travel. This opened an important new avenue for discussion, both of the Middle Mississippian culture and of game balance.

Sketch of the game world. The two named players, Stan and Barbara, are nascent user personas.

At the very beginning of the rules articulation, one of the students pulled out her laptop and began transcribing everything that was being written on the board. In retrospect, I should have stopped her, encouraging her instead to be completely present with the process at hand. It was a good instinct she had to want to capture the physical writing in a digital archive, but it was premature. In past projects, I have seen students get confused about conflicting information, especially regarding whether things in physical space or digital space are current and up-to-date. I have a strong preference for analog information radiators, which is the main reason I advised the team toward a physical task board over, say, a shared spreadsheet or digital project management software. I mention this here to help me remember, next time, to make sure everyone is fully present in what I consider to be the critical part of the task at hand, since I think the students are still learning to distinguish critical from ancillary.

As I walked to work Tuesday, I was reminded of how useful it was at the VBC to have concept and production art pasted all over the walls. We did this relatively late in the process, but that team identified it as a key element for both helping the atmosphere and facilitating communication between technical production and art production. So, I contacted the primary artist for this semester and asked her to post a few concept art pieces on the wall. I was pleased to see some excellent sketches, annotated with her commentary, right out of the sketchbook. When Ron came and hang out in the studio today for a bit, he had some questions about it, so I encouraged him to just put his questions right up on sticky notes, and they are captured in this picture as well.

Concept art is hung on the wall, with some author and team annotations

Today's last step was for the Wednesday Afternoon Crew to look over the rules, identify missing pieces, and then start striking anything that didn't contribute to the core game design. They ended up patching three holes in the design and cutting one feature that didn't clearly tie to the design objectives. Now, they are off and running with a few related tasks:

• Digitally prototyping the production/consumption rates in a spreadsheet to see if our mental math produces the balance and scarcity of resources desired.
• Physically prototyping the essential game rules so that we can playtest with upper-elementary school children to see if the dynamics we desire arise from the mechanics we defined.
• Craft a one-page design document that can be posted on the wall

Author's note: I realize as I am about to publish this that I never actually finished my post saying what we're doing this semester. I guess I'll have to get to that another time. To make a long story short, we're making a game for fourth-graders about the Middle Mississippians. You probably inferred that from the story above.

Global Game Jam 2013: WikiBeat

I spent last weekend at Global Game Jam. Last year I was at the VBC, and I took several students with me to Columbus, where we had a great time. This year, I brought two students from my game studio to the Indianapolis site, hosted at the Art Institute of Indianapolis. We arrived in plenty of time to chat with some of the other jammers, many of whom were students from the area, including one other Ball State student. Closer to 5pm, we moved over to the computer lab for the keynotes and theme announcement.

The theme—in case you didn't click the link before or haven't heard—was a heartbeat. It was announced with a bit too much melodrama, but I congratulate the organizers for identifying a universal theme. I want to say a bit about "theme" here, though. Last year's theme was the ouroboros, and while many game ideas explicitly included snakes and tails, there was a lot of discussion of metaphorical interpretation. This year, everything I heard had to do with hearts quite literally. This was disappointing. One of the primary reasons I took the team to Columbus last year was to meet up with Ian Schreiber, who is one of the GGJ organizers, and I remember him stopping in toward the end of the jam and saying something like, "There are so many damned snake games!" Clearly, as a member of the theme selection committee, he was hoping for metaphorical interpretation. I wonder what he thinks of all the heart games created this year?

There were a few reasons that I wanted to go to the Indianapolis site this year. It was organized by the Indianapolis IGDA, of which I am a member, although I don't make it to a lot of their events; this made it a good opportunity for me to go see some friends that I only see a few times a year. I have some other friends in the city that I was hoping to meet up with for lunch, but sadly that didn't come together due to a communication breakdown. I also have several alumni in Indianapolis, including folks I worked very closely with in 3:15 Studio and Root Beer Float Studio. Josh Hurst was the only one who came and participated in the jam, but I am glad he did, and we were both eager to work together again. (Here's his blog post about the weekend.)

When Josh and I heard the theme, our minds both went to the same place: hearts and babies.¹ We figured there would be a host of games about hearts and babies, and so we decided to draw inspiration from the diversifiers. We had both read through them before and were intrigued by this one:

The Truth is Out There
Some external real world element, such as weather, time of the day, etc, affects gameplay. It MUST affect gameplay and can’t be only a scenario element.

After the theme announcement, we started brainstorming data sources and gameplay elements. We liked the idea of a word game in which the player has to know what topics are currently in the news or trending, and with this inspiration, we started exploring available data sources. All the jammers were in one crowded room, so Josh and I went to one of the other rooms for our experiment. As a result, we missed some of the discussion and pitches, but we were already on a good course that we knew required some serious investigation.

We were really excited to try to get data out of Google Trends, my thought being that popularity and unpopularity are the oxygen and carbon dioxide of culture. Unfortunately, there's no public API for it, despite there being noise about a release as far back as 2007. Twitter required accounts that we didn't want to tinker with. Turns out, a project of mine had just recently been covered by the AP, and so I was inspired to see if they provide public RSS feeds, which they do. In fact, they're conveniently separated into eleven categories.

Plan A: AP RSS

We talked about doing multiplayer on mobile devices, but that felt both ambitious and limiting—although we both had Android devices, we decided we'd rather have the game be widely playable than customized to one mobile OS. We ended up with a sketch of a hotseat multiplayer design for the Web, with the plan to add simple networked multiplayer if we had time. We chose GWT, in part because I've really wanted to build and ship something with GWT for ages, and also because we knew it would simplify adding App Engine networking should we have time to add that.

At this point I will note, in case it's not already clear, that neither of us are Web developers, and we were victims of second-order ignorance, heading for a brick wall. We didn't know that at the time, of course, so we got to a happy place and headed home/hotel for a good night's rest. We both have infants at home and had just finished stressful weeks at work, so a good night's sleep was certainly in order.

The Pyramids, home of the AII, early in the morning

I got up early the next morning and was back at the AII by 7:30AM. Two bleary-eyed jammers were in the computer lab, and everyone else was asleep. You can't keep a morning-coder down, so I set up shop and got to work. Josh arrived a little later, and by midday, we had all of our RSS parsing logic done and had turned to prototyping the interface. We had been writing everything in Eclipse using TDD, and at this point Josh suggested that we should get the end-to-end prototype running in the browser. I told him I was not worried about it, but a moment later realized he was right, and so we slapped together a simple UI.

Maybe you've heard of the same origin policy. It's a security feature in the browser that prevents scripts from connecting to domains other than the one from which they were loaded. The implication for us was that our Javascript in the browser, loaded from our server, could not open a connection to the AP RSS feeds. It took us hours to realize the problem, and when we did, there was much forehead-slapping. We found some documentation about workarounds, but none seemed to work.

After a bit of investigation, we decided we'd try JSONP, which appears designed specifically to circumvent the same origin problem. It requires a server to support it, and the AP doesn't, so we began to look for similar kinds of data sources. We spent a few hours tinkering with different servers until we landed upon the MediaWiki API supported by Wikipedia. This API is fantastic. Everything you can do through the browser, you can do through the API. Based on the data we could get, we retooled our design so that the player would get points for identifying Wikipedia pages with the most edits in the last thirty days. It's not quite the same as "trending", but certainly, controversial and newsworthy topics see a lot of edits, so it's in the same spirit.

Plan B (or C, or something): Wikipedia Revisions

We set to work retooling the design and decided to abandon hotseat in favor of a local high score table, which was easily implemented with GWT's cookie support. A single player can play to beat their high score, and one can easily share this score with friends to get ad hoc multiplayer, without our having to implement multiplayer as a mechanic. This observation actually emerged from testing, where Josh and I informally challenged each other to beat scores when testing the API access.

Somewhere in the middle of the afternoon, we needed to go get some lunch, so we went down the street to Famous Dave's. I haven't been to a Famous Dave's since visiting my brother in Madison around fifteen years ago. Our waitress was fantastic, and I enjoyed a generous lunch platter along with a Wee Mac. It was so good that I took a picture.

Southside Rib Tips at Famous Dave's

By the end of the day on Saturday, we had and end-to-end prototype working in the browser, but in dire need of some beautification. We called it a night around 12:30am and headed back to the hotel for a few hours' sleep.

Here's an interesting phenomenon: If you have a newborn at home, and you worked all week, and you programmed from 7:30am until 12:30am, and you don't set an alarm, ... well, you can't really guarantee when you will wake up. I woke up a little groggy and looked at the clock, surprised to see that it was 9:30am. We missed the continental breakfast, but at least we were well rested! I grabbed a yogurt and coffee, and Josh ran out for bagels, and we were back at the jam by 10:00am.

Sunday, we officially named the project WikiBeat, and we worked primarily on the high score support and user experience. The best contribution was Josh's idea to turn each guess into a link to the relevant article. It's obvious when you take a step back, but the thought hadn't crossed my mind. We made one blunder with about two hours to go, where we decided to modify how the player's guesses were presented, which meant altering a core data structure that was also part of the presentation layer (yeah, I know). As a result, we discovered later that there is an error where after your first game, your score may or may not be computed correctly. Sorry about that.

Raised by a cup of coffee

After all the submission deadline, there was some time for demos to show results to the other local jammers. You can see all the other games that were created at the GGJ page for the AAI site. I'll point you directly toward the other two that my students created, aMAZEing Embolism and Distance Makes the Heart Grow Angrier. Both of these games were spearheaded by my students, who were able to form teams around them. I like to think the work we've done together on game design and game programming helped. As predicted, all the other games included hearts literally, and when I presented WikiBeat, one of the few questions was, "What does this have to do with the theme?" I briefly explained what I said above, about literal vs. metaphoric interpretation, but since I think Josh and I may have been the only ones who discussed metaphoric interpretation, I suspect this may have been lost on the rest. I suppose that's the flip side of my and Josh's separating ourselves from some of the rest of the pitch process, that our ideas were a bit insular.

I had a great conversation with my students on the way back to Muncie about game design, game development, and jamming. I think it was a good learning experience for them, and I know it was for me. It took me a week to start this post, and it took me most of the morning on a day off to write it. Regardless, I enjoy the process of pulling all the details back into my head and getting them into a coherent narrative. I am reminded of a comment that came up the week prior to GGJ: if game development were easy, people would do it all the time. Turns out, it's really hard, and that's what makes it such a rich intellectual activity.

Thanks to the Art Institute of Indianapolis for hosting and providing subs on Friday night, to Indiana Uploaded for the pizzas on Saturday, and to all the global partners and sponsors. Extra special thanks to Thomas Marshall (Puca Studios) and the Indianapolis IGDA for organizing the event.

Here are the GGJ page for our game and the playable version of the game. Global reported high score so far is David's 301 (in the comments below). Post if you can beat it!

---

¹ On the way home, I talked to my students about the design process. When I told them that Josh and I assumed there would be a lot of "baby" games, they had no idea what I was talking about. For those of you who don't have children (or maybe missed this experience), there is an amazing moment early in the pregnancy where you can hear the little person's heartbeat. It's well before all the sonograms and checkups are possible, and it's an amazing experience. Hearing a heartbeat makes me (and Josh, and probably lots of other fathers) think about that moment.