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.