Friday, September 28, 2012

Critical Analysis of Dominant Species

As mentioned before, I am teaching a game design course this semester in which my students are creating educational games for the Indiana State Museum. The students have chosen their topics and are beginning the prototyping process, and we noticed that several dealt with issues of biodiversity and the ice age. To this end, we added Dominant Species to our collection of reference games. I had a chance to play for the first time last night. This post is a combination analysis and critique of the game, looking at the game from the perspective of learning.

Given this perspective, it is important to note that the game is neither designed nor marketed as an educational tool. What we're doing in this class—and what I'm doing in my scholarship—is studying the various mechanics, dynamics, and aesthetics of games and relating these to learning objectives. The criticism I offer below is based on an attempt to understand how the game impacts the player-as-learner.

The end of a game of Dominant Species
(Photo by Janek S, CC-BY-SA)
Dominant Species is a competitive worker-placement game with area-control mechanics. Most of the board is dedicated to the placement of hexagonal tiles, each of which represents a different biome on Earth. The game is set during the dawn of the ice age, and over time, these fertile biomes are replaced by frozen tundra. On the intersections of hexes are placed elements—circular tiles that represent water, sun, grubs, seeds, meat, or grass. Each player has an animal class (such as insects or mammals) along with a supply of wooden cubes, each of which represents a species. For example, as the mammal player, each of my white cubes represented a species of mammal.

Along the side of the game board is a structured presentation of all available actions. The main game loop consists of two fundamental phases: assigning action pawns to reserve actions (worker placement) and then executing these on the Earth (area control). These actions result in such effects as: adding biomes; adding or removing elements; adding, removing, and moving species; and scoring victory points. As the name implies, one wins the game by earning the most victory points before the end of the game.

Having the most species on a tile can earn a significant number of points when scoring a tile, but having the most species is not the only way to progress: having your animal match the most elements on the tile grants "domination," and it is through this mechanic that one unlocks potentially-powerful, once-per-game special abilities, realized through Domination Cards. Hence, a primary tactical consideration involves balancing the need for quantity of species and the need to match elements on your animal card with those on tiles. The best situation for scoring is that you have both the most species and domination on a biome, but because scoring is done at the end of the round, it's easy for circumstances to change before points are computed. That is, a tile one dominates at the start of the round may be vastly different by the end of the game.

The balance of number of species and dominance is central to decision-making during the game. There are very few random elements in the game, and so much of one's consideration is devoted to seeking patterns in the game and predicting opponents' moves. No one at my table had played before, and so as one might predict, a major challenge was in simply seeing that there were opportunities to advance one's position—that is, in recognizing the patterns of the game. This speaks to the the primary learning outcome of any game: learning to play it. (See Jonas Linderoth's excellent DiGRA article on how game-based learning is always bound up in the affordances of the game.)

The available game actions and their resulting effects demonstrated notable alignment of theme and rules. Adaptation involves adding an element to one's animal card, meaning that you have a better chance of dominance in a biome that features that element. Wasteland eliminates elements from around tundra tiles. Migration moves species to new biomes—and this is an action in which birds excel. In our game, there was an early rush for adaptation as players grabbed diverse elements in an attempt to dominate their biomes. However, this adaptation  produces a concomitant dependency upon the elements. Later in the game, these elements began to disappear through a combination of glaciation and "depletion"---a player-initiated action to strategically snipe elements away from the board. These environmental changes produced significant shifts in power. The interested reader can refer to the rulebook for a full list of actions.

Element Discs
(Photo by Tony Bosca, CC-BY-NC-ND)
The alignment of theme and mechanic permits learning through metaphor: as migration works in the game, so migration works in reality. However, these metaphors are broken in interesting ways. In the presentation of the game pieces and the rulebook, a player appears to control a class of animals: for example, I "was" the mammals. However, much of the strategy comes from clever placement of new biome tiles (wanderlust) and replacement of existing biomes with tundra (glaciation). These are player-initiated and player-executed actions, but clearly, ice age mammals could not simply flip over new continents and migrate there. So, who is the player? I suggest that Dominant Species is actually a competitive "god game" in the vein of Populous, where one has control over creation and an investment in a particular population. This is not bad, but it is implicit, and it introduces dissonance.

Metaphoric misalignment can also be seen in the elements-matching mechanic. Sun and water are treated and distributed the same as grubs, meat, seeds, and grass, despite the fact that in reality, there is a clear dependency among these. The distribution of biomes and elements could lead to a sea without water or a desert without sun, and either could have animals thriving in it. Note that there are six elements and six animal classes, and each of the six classes has one type of element printed upon it: that is, for each animal class, there is one element type that it always matches. This mapping of elements to animals may be fair and balanced in a variable powers game, but it doesn't follow from the theme. For example, my mammals were always dependent upon meat but not always upon water.

Cubes represent species; cones represent dominance.
(Photo by Tony Bosca, CC-BY-NC-ND)
Our game was won by "tundra spiders." The player controlling the arachnids got early control of the tundra tiles, and by the time we realized the implications to his score—the bonus points for which rise geometrically with the number of controlled tundras—he had far exceeded anyone's ability to catch up. It is notable that the rest of the players tried in vain to cooperate to limit the arachnids control of the tundras. This doomed attempt at cooperation was fun for the players! However, looking at what a learner might take away from this, I'm afraid it's a mixed message at best.

It need to add that terminated the game after 3.5 hours rather than play it to the end, so there may have been more possibility for shifting scores later on. This brings up another important criticism of the game: in what might be described as beautiful and intentional irony, the game moves at a glacial pace. Even a seemingly simple action such as removing or adding an element has the potential of shifting dominance, which is tedious to compute. This thread describes some attempts to make this easier, and I may experiment with using dice to this end in my next play. Reflecting on the dynamics of the game, I think it needs to be as long as it is, so that it can realize the ice age theme and get the player through significant environmental changes.

Dominant Species' biggest strength is its representation of animal behavior in the face of resource dependence and a changing world. That this takes a significant amount of time may be necessary for this outcome: I suspect it would be harder to demonstrate this in a shorter game, since players would not have the time to acclimate to a situation before dealing with the change. The game is very well themed around ice age animal behavior, but some very enjoyable parts of the gameplay are misaligned with this metaphor. It would be an excellent challenge for someone interested in science education to modify the game to keep the best of what it has to offer, replacing player control of Earth with a neutral environment.

Dominant Species was designed by Chad Jensen and was published in 2010 by GMT Games, LLC.


Author's note: I play a lot of games, but I write about few of them. I've been telling myself for months (maybe years) that I should use the blog to write more of this sort of article. I also have a vague recollection of people telling me they liked my Deus Ex article. You may see more articles like this in the future. Even though the blog is primarily for reflective practice, I do also try to consider what both of my readers care about, so feel free to let me know what you think.

Thursday, September 27, 2012

A questionable user-interface design produces a powerful learning opportunity: A tale of teaching and user-centered design

My CS222 (Advanced Programming) students started their two-week project on Monday. It's essentially the same project I assigned last Fall: a Mad-Libs application to demonstrate model-view separation, test-driven development, pair programming, prioritizing tasks based on a provided user story analysis, and basic competency with a UI widget library.

My intention for Wednesday's meeting was to start by asking what questions or troubles they are having as they start, expecting to transition into a discussion about domain modeling via TDD. In fact, I said aloud, "My first question to you is going to be, 'What questions do you have for me?'" My intention was to take as many questions as they wanted to throw at me, and then transition into an introduction to user-centered design and design thinking.

As I was saying this, I brought up Blackboard, in order to show the list of user stories that describe the project's functional requirements. Here's a screenshot, reproduced on my desktop, although I was on my laptop at the time.


Note the significant are used by the "Ball State Blackboard" banner. I said, partially to myself but loud enough for all to hear, "Why is that there?" I paused for a moment, constructing a few plausible explanations, and I saw an opportunity, so while many of the students were still chuckling—knowing full well my dissatisfaction with Blackboard in general and accustomed to the occasional rant—I repeated, "No, seriously, why is that there?"

One student quickly mentioned university branding. This is a good answer, if a bit cynical, but I pointed out that neither the font nor the colors matched university branding efforts, and that this was enough to rule out the heavy hand of University Marketing and Communication. I moused around a bit and discovered that clicking on the "Ball State" part (but not the "Blackboard") part takes you back to the main university blackboard page. A student pointed this out, that it's a feature allowing you to get back to the main page.

What an opportunity! I turned the question back to the students, asking them to consider how people use blackboard. They answered, well and predictably, general use cases such as "checking to see if there's homework," "reading a discussion," and with a bit of leading from me, "a professor posting a new assignment."

I pointed out that these were all very general uses, and I led them into the creation of a persona. "John," they named him. John is a first-semester freshman taking History 150 (the general history course required in the core curriculum), and it's the fifth week of the semester. On Friday, from exactly 1:00PM to 1:05PM, he has to sign in to Blackboard and take an exam about underwater basket-weaving. After sketching this on the board, I introduced another persona, Jackie, a senior social work major who has to sign in to blackboard to submit a self-evaluation of her immersive learning capstone experience. We talked briefly about how John and Jackie have very different needs, and that by specifying these details about them, we got a better idea of how to design an experience for them.

Back to the banner. In what circumstances, I asked, do John or Jackie need to return to the main blackboard page? We concluded that there were none, or at least, no circumstance that required investing 1/8 of the screen to a feature more easily conducted through the browser's "back" button.

So, why was the banner there?

One student suggested that it's there because a superior told the designer to put it there. That's possible, of course, but it doesn't lead us to understanding the process by which this decision was made. Then we talked about the sales of systems like Blackboard. A salesperson sitting across from the Vice President of Information Technology is likely showing off Blackboard features on a snappy laptop or the VP's large-screen monitor. "We think you should buy this product. Look, it already says 'Ball State Blackboard' right on it!" However, what looks great on a large-screen monitor or even a relatively nice laptop does not scale well to classroom projectors that are locked into 1024x768 resolution!

Then a student brought up a very important point, that it was probably a template. I suggested that the more one works with a template, the less one sees it and the less one thinks critically about it. I badly paraphrased Edsger Dijkstra, which I quote here correctly: "The tools we use have a profound (and devious!) influence on our thinking habits and, therefore, on our thinking abilities." As Web developers and designers customized Blackboard for local implementation, they probably did not even think about that banner.

There was a consensus on this point: the banner that wasted about an eighth of my screen was there by accident. That means, by definition, a complete failure of human-centered design.

This segued into a more formal introduction to user-centered design, using Wikipedia's summary of the ISO standard as a springboard. I presented the students with a challenge: in fifteen minutes, design a physical prototype of the Mad-Libs application interface, following the principles of user-centered design. The results were fascinating: the students immediately began sketching designs, including details such as titlebars and platform window manipulation widgets, or annotating the UI with technical notes such as "JPanel" and "JTextField." These provided a perfect springboard to point out that no one had considered the user—not in a real, explicit, user-centered design sense. I think, or maybe I hope, that from this experience they realized how easy it is to say "user-centered design" but how it's a different issue entirely to integrate it into practice. Next time, we'll pick up the discussion by having them consider for whom they are designing.

And thus was a momentary frustration with a bad interface decision turned into an impromptu learning opportunity.


Author's note #1: It turns out that there's a bit more functionality in that banner than just "click to go home." On a wider screen, you get a few more options, as depicted below. However, that control panel on the right does not float with the window size, and it was completely hidden on my 1024x768-clamped projector display. Note in the previous screenshot that there's actually a scrollbar under the banner so that I can slide it to the right and get to those options. Ugh.



Author's note #2: I realize I'm not doing so well with my "reflective practice blog post once a week, or at most one every two weeks" goal this semester. I have several half-written posts that I've abandoned and a few research inquiries that are not quite ready for prime time. You probably don't care much about the periodicity of my posting, kind reader, but by putting this in writing I make myself feel a bit more accountable to my personal goal of reflective practice through blogging.

Thursday, September 13, 2012

Undergraduate Colloquium Presentation: Taking Pride in Students' Accomplishments

Yesterday, two undergraduates from the Computer Science Department delivered a departmental colloquium about the NSF Research Experience for Undergraduates program. Paige Rodeghero spent the summer at the University of Alabama, and Lyle Franklin spent his at UIUC; Lyle also reported on his Summer 2011 experience at Notre Dame.

Before I describe the colloquium presentation itself, it is worth explaining the background. Paige is in one of my courses this semester, and several times she alluded to the excellent summer experience. At the conclusion of one of our meetings, I reminded her that I would like to hear some details about it. Hearing her enthusiasm—along with a statement that all CS majors should be participating—I suggested an undergraduate colloquium presentation. She eagerly accepted. Even this part of the story, taken in isolation, is very inspiring to me: a student went out into the world and had a positive, research-oriented, potentially career-altering experience, and she embraced the opportunity to share it with her fellow undergraduates. Fantastic!

I met with both Paige and Lyle separately the week before the presentation to assist in planning. Both demonstrated laudable preparation skills, having thought not just about the content they wanted to share but also the best means for structuring and expressing it. I regret that we could not all meet at once, since I didn't realize that Paige and Lyle had not met before the day of the presentation!

The colloquium presentation started at 3PM. There were about fifteen people in attendance, mostly undergraduates. After my brief introduction and a few comments about the NSF REU program, Paige described her experience at the University of Alabama. She had many pictures of her collaborators and her work environment, and I am certain this was valuable to the audience. As I recall from my undergraduate days, it was hard to imagine the space in which graduate school happens. Her sharing these images demystified these aspects of a researcher's lifestyle. She made brief mention of being able to take graduate-level courses as well; if time permitted, I would have liked to have heard more about these experiences, since again, it can be hard for undergraduates to imagine. Paige emphasized the strong bonds formed with her cohort as they worked together, studied together, exercised together, and relaxed together.

Next, Lyle described his experiences at Notre Dame and UIUC. He made a very powerful point about personal responsibility: "Like anything, you get out of it what you put into it." He described how some of the REU participants seemed intent on avoiding work rather than embracing it, noting that there were no external repercussions for failure. In contrast, his dedication yielded first-place awards in research presentations, an accepted patch to NetBeans, and a submission to ICSE—the top conference in the field. That paper is still under review, so I won't say much about the particulars; rather, let me go in another direction and describe why I found this part of the presentation so powerful. 

Lyle had just finished talking about the "R&D" part of a systems research project: that stressful period where you try to build a software system to explore a research scenario and then evaluate it on voluminous test data, hoping it won't go down in flames. Once they were confident in their results, the team turned to "dissemination" mode. Lyle did not expect the intensity of research writing, and he and his collaborators put in an estimated 80 hours into the week before submission, uploading it just a few minutes before the 6AM deadline. The audience expressed audible surprise at this seemingly-herculean effort, and Lyle explained that he had the same reaction at first, but that his advisor and graduate student mentor both seemed to thrive on it—"It's what they lived for."

I inquired after the length of the paper, knowing the order of magnitude to expect. Lyle brought up the ten-page document and paged through it, showing some prose along with a few charts, data tables, and algorithm specifications. He explained how he had to learn LaTeX to do the writing, and he was glad he did. He also explained the process, which of course is familiar to academics: he and his partner would write a draft and take it to their advisor, who would cross out large sections and heavily mark up the rest, and thus the next iteration began.

Here, in this ten minute discussion, Lyle had laid out for his peers what it really meant to be a researcher. To many students, the lives of professors are invisible aside from three contact hours per week. Not just students: many legislators and voters seem to think the same way! Lyle described not just the process of creating new knowledge—the scholarship of discovery—but also the emotional highs and lows around the research career. Lyle clearly has the mettle for a top-tier graduate school, an I hope that through this presentation, even more of our students were inspired to strive for the same. If nothing else, I hope that they learned to empathize with the scholar's life.

Lyle's and Paige's presentations were wonderfully complementary. At the conclusion, they provided recommendations regarding how students can get involved in an REU next year. As I said when I introduced them, I am bursting with pride over their accomplishments and how well they represented Ball State Computer Science to the rest of the world. A great follow-up to this presentation would be a talk by those students who have done summer internships and Google Summer of Code—let me know if you're interested!