Thursday, April 27, 2017

Roundtable course evaluation in CS222

This is the final full week of classes at Ball State, with one more regular class meeting on Monday before final exams Tuesday through Friday. I had planned out everything that needed planning in CS222, but this past Monday had a hole. It would have been easiest for me to schedule a "studio day," where I show up to class and help teams out with their final projects, but I decided I wanted to do something different: I held a roundtable discussion with my students about their experience this past semester. The decision was motivated in part this semester's abysmal attendance, but as I got to reflecting on it, I realized I had many more questions about the students' experience that perhaps an open discussion would address.

I announced the plan for the week to Blackboard, and I came into Monday with a fairly simple plan. My idea was to talk through four prompts: What were the highlights of the semester? What were the stressors and low points of the semester? Why was the attendance so poor all semester? What advice would you give for next year's students?

I was surprised to see a great turn out on Monday, although it was less clear to me if they had actually read the announcement of what we would be doing that day. We pushed some tables out of the way and circled the chairs for the discussion, and I opened with the first question listed above. From here, there were never really any dead spots for the 45 minutes or so we had; the conversation flowed from one topic to another. As time went by, I did occasionally steer the group to get at those four issues above, but it was much more organic than I imagined it would be.

The notes I took are mostly chronological, but I'm not sure that it makes sense to share the results in that order. My goal here is not to recreate the conversation but to provide enough notes that others—including Future Me—can use these observations to make course planning decisions. I should mention that not every student spoke up, probably about half, with some saying more than others, as these things tend to go. I don't present these notes as representative of the whole class, but as a record of what was shared.

The highlights reported by the students included "story time", which I took to mean my sharing of relevant (or not?) anecdotes to support the themes of the course. Students responded positively to the self-driven format of the course, with several stating that they had never had a class like this. One student pointed out specifically that he loved the format, even though he didn't take the most advantage of it; he would do it differently a second time, if he could. When I asked whether there was anything that could be frontloaded to encourage the kind of behavior he described, the group didn't really come up with anything. The class examples from the first third of the semester were also cited as highlights, with the observation that the examples in Clean Code tended to be abstract, but the things we built were real applications. This was interesting since our examples were, in my opinion, ridiculously small, but to the students this was still more valuable than the incomplete examples (that is, they are only portions of systems) given in the book.

A student suggested that he would like to have an example of perfect Clean Code—a project that he could look at for exemplars of all the ideas he needed to know. Several students nodded in agreement that this would be useful. I decided to play devil's advocate, and I asked them if they thought there was a poem that they could read that would show them everything they needed to know about poetry, or if there was a novel that was clearly The Best Novel in English. They realized quickly of course that this was ludicrous, and it seemed they quickly made the association back to code. I acknowledged that the desire for such a thing is not bad, but that I doubted that such a thing existed, or that it could exist. Instead, I encouraged them to think about what they would want out of this desire, and how they would get it in different ways. (When I posted a version of this story on Facebook, a friend and alumnus coined the term "Clean Code Unicorn," which I quite like.)

The discussion veered a little bit from this concept, but as part of it, students expressed a desire for more examples of high-quality code, including specific examples of Model-View-Controller architecture. The speaker acknowledged that I had, in fact, provided reference to some, such as Guava, and that Robert Martin has some wonderful lectures on YouTube. Acknowledging the authenticity of the desire for more examples, I asked what would actually motivate students to study those examples. One student said his two-week project grade was motivation enough, and another called for "points".

One student expressed a frustration that not everyone in the class knew how to learn from the book. He himself had read the book when it was assigned and studied it rigorously, but he was working on a team with students who had not done this, and so they had no concept of what they were doing wrong. It was refreshing to hear a student express this concern that so often I hear faculty discussing! Several suggestions were made to ameliorate the problem, including making a guide on how to use examples from the book, doing more whole-class work sessions to solve refactoring problems, and homework assignments with canned bad code examples. The most innovative recommendation was to have a Challenge of the Week, like a sudoku or crossword puzzle, where the class would be given some code to refactor toward cleanliness in exchange for some kind of course credit.

Another student suggested that I provide more guidance about naming conventions in general. Clean Code talks about the importance of good naming, but it doesn't get into cultural norms such as "a method should not be called setX unless it is a mutator that takes an X as a parameter," "a boolean method should be named isX for ease of reading conditionals," or "methods that make other things are often called createX methods." This student was reacting to some feedback I had given on that team's previous submission, where I gave pointers like these (maybe exactly those, actually). That is how I usually handle these cases: as students come across common problems—which will manifest differently for each team—I will provide guidance on them. After the discussion, it got me wondering if the student mistakenly thought that the team "lost points" for this kind of thing; it may be an easy mistake to make since my guidance on naming might be interleaved with more serious Clean Code violations. Since it's not clear to me that I can frontload all of the cultural naming rules in a way that students will be able to internalize, maybe what this student really wanted was clarity in which parts of my feedback were formative vs summative.

We talked about attendance a bit, but I prefaced the discussion by saying that I understood that few people really enjoyed 8AM classes: we couldn't control the scheduling, so I wondered if there was anything else contributing to low attendance. For those who don't know, I don't record student attendance or grade participation, but I won't go into my philosophical and pedagogic argument for that here—that's for another blog post. However, because I don't give "points" for attendance, one student framed it as, "People don't come to class because you don't care if they come or not." I pushed back a bit, and he backpedaled on the "don't care" part, but this idiomatic expression belies the mental model. I would argue that I don't take attendance because I do care, but it's very easy for students to misconstrue this. As in many cases, it's the students who are least capable of drawing this conclusion who are in the direst situations from missing it.

The other factor impacting attendance, according to the students, was that some of their peers have the perception that what we do in class doesn't matter: because it is not directly graded, they can simply skip class and ask their peers for a high-level view later. This is not surprising to me, since during the nine weeks of the final project, I use class time on activities that are designed to foster students' success in their projects: code reviews, philosophical discussions, UI design techniques, teamwork skills, and so on. These are not directly graded, but they are carefully designed to complement what students are doing. The ones who skip because these things "are not important" tend to be the cocky ones who can sling a bit of code, but who reject the idea that they are unprofessional in their techniques. Again, tragically, these students miss discussions of concepts such as second-order ignorance, and because they miss the discussion, they miss the point. It does make me wonder if more students would be impacted by changing some of my assessments in the course to directly bring in these concepts,  although I worry that this is a slippery slope leading way from authentic project work. As it is now, students either take my advice or not, and those who do tend to succeed, and those who do not, do not. Some of my best experiences have been with students who rejected feedback in one semester and then enrolled in my class a second time and really nailed it—these are cases where I truly believe I have made a lifelong impact on a student.

Looking over my notes on attendance and participation notes, I jotted in the margin that I could use my course's achievement system for participation somehow. This system has provided a good mechanism for rewarding the various kinds of virtuous behaviors I want students to practice. It would be very easy to add one with criteria such as, "Write a reflective essay about three in-class activities in which you participated, relating it to your final project." That's probably what I'll do for Fall.

In the last few minutes of our discussion, we focused on the advice that this semester's students would give to those taking the course in the Fall. Here's what came out of the discussion:

  • Do the assignments in the first three weeks. Students can resubmit assignments throughout the semester, one per week. Some students make the mistake then of not working on these right away. As a result, they quickly fall behind, since then they're being graded in projects on concepts they have not yet wrestled with at all.
  • Go through the book, which I interpreted to mean, actually do the assigned reading when it is assigned, so you know when you need it later.
  • Pick an easier project. I joked about this being like Hofstadter's Law: pick an easy project, then pick an easier project.
  • Name correctly. Students mentioned again that the idea of naming correctly is almost trivial, but the implications of actually naming correctly are profound.
  • Talk to other students outside class. They mentioned the programming club, Code Smash, as a good source, and just generally talking to upperclassmen, as ways to get more feedback.
  • Watch out for StackOverflow and tutorials. They are often abstract and don't follow best practices of Clean Code.
  • Keep up to date, in particular with platforms like Android, where advice from five years ago may very well not be applicable today.
I think it took me longer to type this up than the discussion itself, but I'm glad I took the time to do it. I hope that you might find something interesting in here for yourself, dear reader. As always, feel free to leave a comment about your own experience, advice, or teaching practices.

Tuesday, April 25, 2017

Ludum Dare 38: Subpar Melee

TL;DR

I made a thing! Download links to Linux, Windows, and HTML5 builds are on the game's Ludum Dare 38 page, and you can play in the browser right now (keyboard required).

A two-player space combat game

Background

Ludum Dare 38 was the 15th anniversary celebration of one of the world's largest game development events, and this alone was enough to encourage me to participate. I did some digging and was a little surprised to see that the last one I participated in was with Summoned, way back in LD29 (blogged about it here). I know I've followed the themes and done a few sketches since then, but it wasn't until LD38 that I made a full submission. Ludum Dare comes every four months, which means it aligns with the end of the Spring semester, the start of the Fall semester, and the end of the Fall semester—an epic trilogy of bad timing for students and faculty alike. Still, I love the event: it encourages anybody with some spare time and interest to make a thing and make it public. It's the spirit of this blog and of my immersive learning projects to make in public.

LD38 provided another important opportunity for me. A few weeks into the Fall 2016 semester, I decided to invest a significant amount of time learning Unreal Engine, a decision I wrote about in December. Well, it's practically final exam season here at Ball State, so why not give myself a final exam as well: could I make a game in 48 hours for LD38 using what I've learned in Unreal Engine? In some ways, it's like the final exam I gave to my Game Programming students back in 2011, to make a game about Beneficence to demonstrate what they learned, except I had 48 hours, and the theme would come from the Ludum Dare community.

Before the event, I participated in two rounds of community theme voting. At 9PM on Friday, I popped over to ldjam.com and saw the announcement that the theme was "A Small World." Of course, that terrible Disney song was the first thing to come to mind, particularly the rendition from the old 45 I had as a kid. I thought about games taking place on small worlds, and I thought about the board game Small World, but nothing really jumped out at me. That late at night is awfully late for me to start being creative, anyway. After stepping away, I got to thinking about games I've played that have small worlds in them, and my thoughts came to Star Control 2 and it's classic Super Melee space combat.


A friend gave me a copy of Star Control 2 when I was in high school or college, and it quickly became one of my favorites. For those who don't know, the game is now available for free as Ur-Quan Masters. It's an epic space opera taking place over a whole galaxy, complete with planet-roving and resource-gathering long before Mass Effect—and they did it better, too! My goodness, don't get me started on the ridiculous tedium and carpal-tunnel-inducing stress of Mass Effect 2's planet scanning.

But I digress. I decided to make a simple two-player space combat game along the lines of Star Control 2 Super Melee. I also decided to do it primarily in 2D, since I'm gearing up for a 2D reimplementation of Collaboration Station starting this summer—but more on that in another post.

Making Subpar Melee

Saturday morning, I drew a quick red spaceship in Gimp and implemented the fundamental inputs for one player to fly around the screen. I made two planning decisions that morning: to use the Unreal Engine naming conventions and to follow its framework of separating pawn, controller, game state, and game mode. As I worked, I found the former to be a bit troublesome: not every kind of asset I was dealing with had a naming convention, and not every gameplay element had a clear place in the folder-structure taxonomy. It's still not entirely clear to me how conventional these conventions really are, since I have not read enough high-quality code to build an intuition for it. From the tutorials I've seen, I think my next project will take a more emergent approach—when there's a structural problem, refactor, but keep it lean until then. I'll come back to the gameplay framework decision in a little while.

The first major hurdle I encountered was that I wanted to set walls around the play area, such that a player would bounce off of them and take some damage. I watched a Pong tutorial last semester where the developer simply placed boxes around the play area off camera, and that seemed elegant to me. However, I kept passing right through the boxes, despite the physics settings. I don't know how long I was stuck on this, but at one point I was adding spheres into the board with gravity enabled, and watching them fall and pass right through the walls, scratching my head, when I was inspired to fiddle with the box size. See, I had decided to make these boxes look like walls, so I had taken their width to zero... and it turns out that even though the wall will render, a zero-width box will not generate collisions. A silly mistake, but one I won't make again! Setting the walls' width to 0.1 was enough for it all to work brilliantly.

Next I added the planet in the center of the screen and gave it gravity. A quick search confirmed that you cannot set a point source gravity using the canned physics settings, but it was no trouble to give the planet the behavior of pulling every ship instance toward itself, and then to modify the algorithm to make this value inversely proportional to the square of the distance.

With the edges and the center collisions working, I added a damage system, and then I began to add support for exploding when health reaches zero. This is where everything took a turn for the worse, early Saturday afternoon: Unreal Engine suddenly became unreasonably unstable. I couldn't work for a minute without it crashing and restarting. I narrowed the problem down to involving the details panel, especially when dealing with a flipbook animation. I sent about a million crash reports to Epic, so hopefully they find something in there, but I was stymied. I had been working in Windows, since several weeks ago I began learning C++, and the Visual Studio bindings are clearly more robust than the Linux ones I tinkered with. For LD38, I wanted to test my ability to get something up and running quickly, and so I was only using Blueprints—UE4's visual scripting language, which is much faster to iterate with than C++. Since I was not using C++ for this project, though, I thought perhaps I could switch over to Linux... except that the version of UE4 I had installed on my Linux partition was 4.14.x, and this project was already started in 4.15.1. With the wind out of my sails, I rebooted into Linux and started the lengthy clone, dependency download, and build process. I was able to finish painting some miniatures and go out and run some errands, and when the build was complete, I was rewarded with a perfectly stable UE4 running in my preferred operating system. Success!

The next major hurdle was adding the second ship for local multiplayer. At this point, I had a PlayerShip blueprint to represent the ship, and I had written a custom PlayerController to handle transforming the input events into ship events. I had also separated the ship's health and damage into a separate GameState object. It seemed like a good idea at the time, but I had no luck getting local multiplayer working. I thought gamepads would be fun, but UE4 didn't recognize my gamepads. I spent a lot of time just trying to get my old Logitech pads recognized as XBox360 controllers in Linux so that they would be accessible in UE4. Incidentally, this is done through xboxdrv, but it took a lot of reading and fiddling to make any progress. Even when I had the controllers recognized, I had no luck getting the second player to properly be assigned a PlayerController and possess the second ship. Again, I didn't keep track of exactly how much time I whittled away here, but clearly I was not making headway. I'd still like to know what I was doing wrong, although many of the signs point to the fact that custom C++ integrations are needed to do what I wanted to do. I cut my losses and moved forward with a different input scheme: I could get away with using the keyboard for both players if I eliminated the idea of using UE4's built-in multiplayer systems and instead just faked it. I wiped out my custom PlayerController and GameState and put the keyboard events for both players directly into my map, which had references to the red and blue ships. This was straightforward to set up and had me up and testing multiple ships in short order. Remember, kids: the player cannot see your engineering.

Moving into Sunday midafternoon, I finally added the ability to shoot. I spent too long on this, since I started with the Projectile Movement component, which was fine except that I had drawn my sprites aligned to the Y-axis instead of the X-axis. This is a newbie mistake and made me have to manually rotate a few vectors to get projectiles moving the right direction. Then, I decided to tinker with having the projectiles also affected by the planet's gravity, but this required then undoing all the work with Projectile Movement, since I needed a physics object whose velocity I could manually "pull" on. I got that working, but it wasn't really noticeable or fun, and I ended up going back to the original approach.

By Sunday late afternoon I had put in the end screen and title screen, and I kicked back to look at it. My ship drawings were meant to be placeholders, but the comic badness of them had become endearing, so I decided it wasn't worth the time to futz with them. Drawing isn't my strong hand, but it also isn't my interest in this kind of work. The lack of music, on the other hand, was really noticeable. This, combined with the fact that I had never done any audio in Unreal Engine, made me think that this would be the best use of my last push. Of course, the spirit of Ludum Dare compo is that you create a game from scratch, including the music, but at this point I didn't feel like re-learning enough composition software to make a bad custom soundtrack. Instead, I turned to the reliable and amazing Kevin MacLeod (Incompetech.com), who has a browsable collection of CC-BY-licensed tunes appropriate for games. It was a little choppy figuring out how to bring the audio into the game, but no more so than I expected, never having done it before. I grabbed an explosion sound effect from the Unreal Engine Starter Kit and a laser blast from a public domain sounds site.

The last step was to create the shippable executables, which I had also never done before. The build process is slow, and at first it didn't have the window size that I wanted. I discovered that the best way to work with this was by manually editing some .ini configuration files, and once I had that right, it worked fine. I uploaded the Linux binaries, rebooted to Windows, pulled from the project's repository, and built and uploaded the Windows executables. At 8:15PM, with 45 minutes to spare, I posted to Facebook that I was done and went downstairs for a celebratory drink.

A friend with a Mac was interested in trying the game, but of course you cannot build Mac executables without a Mac. (Of course. Because reasons. And thinking different!) On Monday, I built an HTML5 version and uploaded that one too.

There is one "bug" in the game that my son and I noticed when playing together: if both players explode, then red wins. I know exactly where that is in the code, and what to do to fix it, but I decided that I'd just leave the game as-is, in the spirit of the jam. The workaround is to make sure that you get to be red.

What it all means

As I mentioned above, this was a sort of final exam to myself, and I definitely passed. I navigated through the pieces of UE4 that I had been studying and practicing, I troubleshooted a few problems by working with other engine features, and I was able to quickly learn and integrate new features. I'm still not sure how I will teach others to use this engine, but course planning is for another time.

This very modest game took me approximately 16 hours of work. If this were a three credit-hour course like my CS315 Game Programming course, that would be roughly two weeks of effort—except, of course, it's actually much more, because you'd also have to account for the extremely high cost of context switching. I heard a heuristic for designing exams that says that you should give students three times as much time as it takes you to take the exam. Let's assume that this is a good rough estimate, and we can say that my three-week project would then equate to a nine-week project by an inexperienced undergraduate. Now the amount of time I spent learning Unreal Engine the past eight months or so definitely exceeds a single course, and I have a wealth of background knowledge to draw upon. I'm afraid all of this leads me to the unfortunate conclusion that maybe something this simple is still beyond the scope of what I can expect from an average CS315 student in the Fall.

I know I've heard professors say that one of the advantages of using games as a motivating context is that students will put in more hours on them than normally required, but this feels unethical to me. Sure, some students may put in more than the expected nine effort-hours per week for a three-credit course, but the course design should not really encourage nor reward that: that's just encouraging crunch, in a field where we know it's destructive to individuals and families. I would not stop a student from learning, but I also want to be very careful to design a course that permits glorious success within the expected amount of time and effort, given the prerequisite knowledge.

I already received one pre-course complaint from a student whinging about how he doesn't like working in teams, but I think this experience shows me that teams will be necessary. My past experience with pair programming tells me that if I was learning UE4 with a friend or a cohort, I would be much further along now than I would be otherwise. Also, my time investment should help me bootstrap the students, so I can be the mentor for them that I didn't really have on my random walk through YouTube tutorials, documentation, forums, and samples.

Parting thoughts

This has become quite the epic post, but I think that's everything I wanted to record for future-me, when I'm trying to remember the kinds of mistakes I made and my thoughts about implications. I know it's easy to lose sight of how hard it is to learn something new after you've learned it. At last night's Computer Science spring banquet, an alumnus on the panel put it well, talking about programming problems: "None of us know how to do it until after we've done it." 

Two final thoughts about Ludum Dare. First, I was tickled to see a LD38 entry from an alumnus I worked with years ago, a creative and clever guy who enjoys the hobby of making little independent games. I'm so glad to see that he is finding joy in making games. Even better though is the second parting thought: one of my CS222 students was inspired by my course to make their first game this past weekend as well. With no other background besides sophomore-level computer science, this student learned Stencyl and made a fun little game from scratch, and shared it with the world as part of Ludum Dare. It doesn't get better than that!

Thanks for reading!

Thursday, April 6, 2017

Painting Runebound: The Mountains Rise

My son and I play quite a bit of Runebound. He received the The Guilded Blade expansion for his birthday a while ago, and we both really enjoyed the variety that the new cards brought to the game. He's still working on painting the miniature from that set, and it's looking pretty good. I picked up The Mountains Rise expansion so that we could get even more variety into our tabletop adventures. This expansion comes with Lothar of the Hill People Nanok of the Blade, a ridiculously wide miniature with herculean pecs.



I primarily used layering for the other Runebound heroes, but I took a different approach with Nanok, something more like I am currently doing with my Descent heroes. For the cape, I drybrushed highlights over a base color, applied a reddish-brown wash, and then brushed on slightly orange highlights. It's nothing fancy, but I like how the hint of orange adds visual interest, though it's not really evident in the pictures. The rest of him was done rather quickly with base coat, wash, highlight sequences. I mixed some blues into the metallic paints for the axe heads, inspired by the card art, and I think this gives them a nice contrast to the warm colors of the rest of the figure. The horns on his helmet needed a little attention, so I did some manual shading on them with sepia ink; similarly, the bracers/gloves are similar in hue to the flesh, so I deepened the shadows with some brownlining there as well. For the face, I brought in a technique I've seen Sorastro use on figures like Han Solo, but something that I've never tried myself: a blue glaze over the face to give the appearance of a 5 o'clock shadow. It's subtle and hard to see in the picture, in part because I was afraid to take it too far, but I'm pleased with it. Sorastro frequently uses complementary glazes to add visual interest to his models, and it's something that I would like to bring in to more of my pieces in the future.

Saturday, March 25, 2017

Adapting the retrospective format for a struggling team

My Spring Game Studio team has been having a bit of trouble hitting stride. We just finished our fourth sprint on Friday, but it was the fourth failed sprint in a row, with fundamental work incomplete and the executable release inadequate for end-user testing. I saw this coming late Thursday night, when I had a few minutes to manually test the build, and so the failure during the Sprint Review meeting didn't surprise me as it did some of the team members. It may be worth noting that I did post to Slack right away that I had discovered a defect, but several team members didn't see the message. In any case, I kept turning this over in my head as I tried to sleep Thursday night. I don't remember the last time one of my teams had four failed sprints in a row: what should I do to help them come together? My default Sprint Retrospective format involves distributing sticky notes on which students write and then post submissions to these four questions: What did we do well? What did we learn? What should we do differently? What still puzzles us? That format has been generally useful, and it has been specifically useful at helping me design interventions around specific needs. Given that the team has had three previous retrospectives, where the same issues kept coming up but were never really addressed, I began to think that a change in retrospective format was in order.

In the morning, I flipped through Patrick Kua's The Retrospective Handbook for inspiration. I think I had come across a reference to this book on Martin Fowler's bliki, but it had been some time since I read it. Kua describes a format called "Solution-Focused Goal-Driven Retrospectives," which he credits to Jason Yip—in fact, Kua's presentations is just a copy of Yip's blog post, so if you read that, you've got the idea. Two things struck me about this format, making me think that it would be useful for my purposes. First, by starting with "the miracle question," you can help the team think about observable properties of desirable end states. This does seem like it would lead to the identification of shared goals better than my traditional retrospective format. Second, it still results in measurable actions to do in the coming iteration to incrementally improve.

I rolled this out on Friday right after our Sprint Review meeting. We primed with the Retrospective Prime Directive, and I pointed out—honestly, hopefully not too judgmentally—that the team had four failed sprints in a row, and that I was changing the retrospective format to help them identify shared goals. I wrote the Miracle Question on the board: "Imagine that a miracle occurred and all our problems have been solved. How could you tell? What would be different?" There was a palpable sense of surprise and shock in the room. A few students gasped, some said things like, "Whoah... I don't know" as they started turning the question over in their minds. One even claimed that he did not like the question, but this was clearly said in way that indicated he did like the question: he didn't like the fact that it was so hard for him to answer!

When I use my traditional retrospective approach, I invite the students to organically form clusters as they post their notes, but the clustering is usually pretty loose. Themes that are distributed across multiple columns cannot be clustered at all. Most students get up, post their notes, then sit down, so it's really just the last few who are making clusters. For this exercise, we moved all the tables back so that everyone would have room to reach the board at once. Three or four students still retreated to the small gap behind the table, but I called them out on this and made them join the group at the front—and I'm glad I did, despite a little whinging from them. As they formed clusters around goals, I asked them to articulate the goals. This also was much more active than my usual approach, with students passing markers around, dividing big clusters, and revising each others' articulations of the goals.
The finished board with 13 shared goals
When I asked them to rank the team on a 0-10 scale in terms of meeting these goals, the first estimates were in the 4-5 range. Then someone suggested the team should look at how many of the goals they have actually met, and the estimates dropped to 2-3. It was an interesting moment of realization, that the team really did want to meet these goals, but they recognized that they still had a lot of trouble. This set up the third step of the retrospective perfectly: to bring the team back up by pointing out that 3 is still not zero! We listed off the practices we were following that were leading us toward our goals, with a team member serving as scribe on a side board.

This led nicely into a discussion of what specific practices we wanted to adopt to take our 3 to a 4 over the next short sprint. Most of the suggestions were clear and came to quick consensus. There was one that had some contention, though, as we tried to sort out the root of the problem. It started with a suggestion to clarify the conditions of satisfaction on the user stories, but when I looked at the conditions of satisfaction, I couldn't see that they were unclear. Of course, I acknowledged that I had written them, and so the root problem could have been that I was assuming domain knowledge that the team didn't have. The discussion raised a bigger problem, though, which I think was the real root: team members had focused myopically on completing the tasks that we had identified during sprint planning, but they never actually went back and read the story name and conditions of satisfaction as they considered validation. Hence, individual tasks were deemed to be validated when considered atomically, in a way that they would never have done if they had been held to the conditions of satisfaction criteria. The result of this was that the tasks were all complete but the story was not satisfied. We never did settle on a concrete action item to solve this, although we agreed that the discussion would make us more sensitive to the articulation of both tasks and conditions of satisfaction in the coming planning meeting. As I look back on it, this may have been a good opportunity to deploy Five Whys to try to get to root causes, but the truth is we were also fighting the clock at this point.

I think this format helped my team to articulate and discuss critical team issues that they had not been confronting before. Whether or not it makes an observable impact in the coming sprint will have to wait for a future blog post. I will need to think about adding this format to my tool belt. I am not sure if I want to replace it as my go-to structure, but I would like to try deploying it earlier with a team to see if it helps with the identification of shared goals.

Wednesday, March 8, 2017

Game design book recommendations

Sometimes people ask me, "What game design book would you recommend?" I received the question today, and in the spirit of sharing knowledge and making the most of each keystroke, I figured I'd make a short blog post about it.

My number one recommendation, with no hesitation, is Ian Schreiber's Game Design Concepts. It's not technically a book—it was a free online course offered through a blog before the "MOOC" term rose and fell in popularity—but it still has everything you want. Schreiber provides twenty chapters of escalating difficulty, exercises to challenge your knowledge, and plenty of references for those who want more on any particular topic. I participated in the Game Design Concepts project individually when it first came on the scene, treating it as an independent study rather than a community exercise. If you were interested, you could certainly find a cohort to read through it and review each others' work. Huge kudos to Schreiber for keeping the site open and free for so many years.

If you really wanted a book in the traditional sense, then I don't think you can really go wrong with Tracy Fullerton's Game Design Workshop. It is thoughtfully composed and contains many interesting anecdotes to go along with the more formal text. The numerous exercises are also quite good, and they are easily adaptable to individual or group implementation (as I recall). My only criticism of this book is that it too often falls into making generalized claims without acknowledging the underlying philosophy, presenting items as definitive without admitting that these definitions are subjective and arbitrary. If you wanted to illustrate this point—for example, in a game design course—you could easily pull up "MDA: A Formal Approach to Game Design and Game Research" by Hunicke et al. It presents a different formalist notion of what constitutes a game, definitions that conflict with Fullerton's, and this can lead to a healthy recognition of how little is established in the field. (You should read that article anyway, really, if you're interested in teaching or learning game design.)

My next recommendation may be a little controversial, but I really enjoyed reading Keith Burgun's Clockwork Game Design. In contrast to most other game design theorists, Burgun is unabashedly specific about what he means when he says "game." In particular, he is talking about interactive contests of ambiguous decision-making, where the decisions are endogenously meaningful, and there is a quantifiable outcome. So, if you're interested in writing interactive fiction or adventure games, this is probably not your next stop; however, if you are interested in reading a zealot's perspective of how to approach strategy game design, I think it's a thought-provoking piece.

There are several other books that I have read and could comment on, but those are the top three that I recommend. Schreiber is #1 for being comprehensive, thoughtful, and free. Fullerton is #2 for being accessible and action-oriented. Burgun is #3 for being focused and for challenging assumptions.

Tuesday, March 7, 2017

Painting Descent, Part 1: The Villains

I picked up a second-hand copy of Descent a long time ago while traveling to a conference, but I had it on the back burner while I finished other painting projects. I just finished up painting the villains, but I have not done anything but prep and prime the heroes.

I usually take some pictures of the miniatures as I finish them and post them up to Facebook. My normal approach is to drop a heavy white piece of paper behind them, drop my painting lamp close to the mini, and then take some shots. The white balance is almost always wrong, and as I have written about before, I will use a tool like Snapseed to adjust the white balance and brightness. The result tends to be a photograph that looks good, but the colors are not always true. I have seen some instructions on how to build a lightbox, but I don't have the table space to keep something intricate set up all the time. I searched online a bit and ended up ordering one for about $12 from Amazon. It is collapsible and has a built-in LED light, with black or white backdrops. Here's what it looks like on my rather messy desk (to be cleaned over Spring Break, for real this time).


Here are two images of one of the new batch of villains, the first taken in my usual approach and the second in the lightbox.


As you can see, the old approach looks positively yellow by comparison. The colors on the bottom one are much more "true," meaning that what I see here looks a lot like the critters beside me on my desk. Without the intense painting lamp pulled in front of them, the fronts of the minis are a bit shaded, but again, they do look authentic at least. So, for the rest of this post, I'm going to use the lightbox images. I will continue to tinker with the lights around the lightbox to see if I can improve the photos further.

For this whole set, like the Myth monsters, I was going for speed. I wanted them to look nice of course, but I didn't want to spend inordinate time on them. I have been inspired lately by Sorastro's painting (who isn't?): he usually uses a simple formula of base color, wash, highlight, but he does it with such grace that it looks amazing at the end. I didn't do this for each figure, but the spirit is there.

A goblin archer
A gaggle of goblins

The goblin archers were not very inspiring. I found the sculpt to be rather poor. For example, the arrow is not separate from the chest: it's extruded back. This can be hidden with clever paint, but combined with the featureless limbs and helmet, they were just kind of dull. Starting with these made me reflect on how Descent was a precursor, or perhaps a herald, of the miniature gaming renaissance. Now, there are more miniature-heavy board games on Kickstarter than anybody has time and money for, and they all look amazing. I bet if Fantasy Flight released a third edition of Descent, it would pick up on this trend, since they understand the market and have the pockets for it. However, Descent is an entire ecosystem, and as I understand it, the cooperative mode app has really helped their sales. It would be folly to jump to a third edition right away, with all the money that people continue to invest in this series.

Each monster group had one that was cast in red, to represent a leader unit of some kind. I haven't carefully read the rules, but folks tell me it's important that this one be visually distinct from the rest. I thought it would be fun to incorporate some red into one of the models, so here, we can see that one goblin has a red loincloth, where the others are grey.

One of the things that this new photography setup tells me is that I should really take those highlights even higher. Like I said, they really do look like this on the table, but they should probably be brighter. It's something I continue to work on. It might be a side-effect of the fact that I paint under a very bright light, or maybe I just need to keep the "more contrast" mantra in mind.

Standard spider

Marked spider

A squad of spiders
The spiders were just a quick base, drybrush, wash, highlight job. Again, they were not very inspiring, so I just wanted them to look OK on the table. The leader unit has red markings on the back, similar to what is shown on the card art. The red markings don't really "pop" and probably could have used more edging to increase the contrast, but it should be sufficient for the table.

I'll mention here that I'm doing some very simple basing on these miniatures. I used my usual mix of model train ballast, about 8:4:1 fine, medium, and coarse. This is painted black, which always takes more than one coat to get into the nooks and crannies. Drybrush this with brown craft paints for a generic earthy surface. I'm using a 50/50 mix of green and black tea leaves from bagged teas as flock to give some organic material.

A zombie

A zumba of zombies
Another quick-and-sufficient paint job here. I'm not sure why the first picture has such poor lighting but the other one looks more lit. It may have to do with where I placed the figure in the lightbox; this will require further experimentation. Clearly, this is a quick two-color paint job: base, wash, highlight. I spent a little more time with the highlighting here, and I think it helps. The sculpt is actually not so bad here, and they could have been given more character with more time (and, of course, a desire to spend more time on them).

A flesh moulder

A falafel of flesh moulders
I'll level with you, I have no idea what a "flesh moulder" is. I mean, it's these guys, but I'm still a little shaky on it. I spent a bit more time on these guys, in part because the sculpt required more brush dexterity. This was again a base, wash, highlight job, but I spent more time on it and I think it shows. For minions that exist only to be destroyed, they're pretty good. I copied the color scheme from the card art, so they were all already dressed in red-orange. To set off the captain, I gave him a red magic energy rather than the purple of his underlings. Again, they could have been gussied up with more variety in the colors or detailing on the robes, and when I have nothing else to paint, I could return to them. In the meantime, I'd like to see this game hit the table before the end of the semester.

A Shadow Dragon

Same Shadow Dragon, Different Angle

Another, higher-ranking Shadow Dragon
From here I moved on to some of the larger figures. There are two shadow dragons, which were painted almost identically. The game art shows them having pale green facial details, so I painted on that way and one with a pale orange, to bring in some redness for the captain. I decided to go with shades of grey and black strictly, given that they are shadow dragons. I mixed just a little purple in to add some interest to the tone. I basecoated the whole miniature and then used the large, plain surfaces to practice two-brush blending. It turned out great in some spaces and a little sloppy in others. I decided to keep the spines pitch black; you probably cannot tell from the photos, but the spines are all also gloss varnished, so although it lacks tonal variety, the figure has some visual interest.

This is also the first completed figure in the set where you can see my new basing bricks. This was a trick I learned from Atom Smasher at Tabletop Minions, using a rectangular hole punch on craft foam to get great cinder-block-sized bricks. I love it, especially on these big miniatures, where the bases need a little extra something so they're not just grit and leaves. You can also see that I've added some grass flock here, which is roughly a 50/50 mix of medium green fine turf and burnt grass fine turf. I don't think the grassy spots distract from the model, but they give a little bit more flavor to the base.

Merriod

Merriod

More Merriods
What's a merriod? About three hundred pounds.

These guys are pretty cool, really: some kind of land shark with crazy head tentacles. My brother somehow ended up with a spare one and gave it to one of my sons years ago, and he painted it up in red like a demon, which also worked. I decided to go more with the shark theme and card art. It took me a long time to mix a blue color that I really liked, but after several coats, I ended up with this, which I remember to be a mix of dark blue and green to make an aqua tone, then a bit of orange to bring it down. Although the concept of these miniatures is intriguing, the sculpt is basically an undetailed lump of plastic. I used the opportunity again to practice two-brush blending, and I think it turned out quite nice. The transitions on the chest muscles may be a little stark, but then again, contrast! You can't learn to increase contrast without breaking a few eggs, or some idiom like that. 

The higher-ranking of the two has red markings on his tentacles and tail, but like the spider, they don't "pop" so well. I did actually use several layers of paint to make the transition to red more intentional, but it still doesn't really stand out. I think it will be fine at the table, but I think it's a place where I likely needed to go with more intense contrast. I suppose I could even touch that up sometime when painting other things, if it turns out not to stand out at the table well enough.

Once again here, because the figure is hunched over, I think the lighting in the lightbox alone doesn't quite do it justice. Yes, it looks like this on the table, but it's hard to appreciate some of the details.

An Elemental

Same elemental, rear view
The two elementals were fun to paint, being so different from the rest of the set and quite different from classic D&D-style elementals. The bottom of the mini is supposed to represent water, which I transitions to a more grey shade in the tail to suggest wind. Once I drybrushed to pick out the highlights and washed to bring the tones together, the aqua-grey transition was a bit lost. It's subtle, and I think it's fine, although showing it to others they hadn't noticed it at all. Oh well, we paint for ourselves, right? The fire was fun to paint, though there is a lot of it: I don't have anything else for scale here, but this is a big miniature. 

I had finished it up and showed my son or my wife (I don't remember who), and they pointed out how stark the transition was between fire and water. Once they said that, I couldn't un-see it, so that's when I added the fading yellow you can see on the rear view, transitioning down into the water. Previously, the top half was fire and the bottom was water. This is much nicer, really. I don't think I have a good before picture for comparison though.

I couldn't think of any great way to distinguish between the two elementals, so one of them has red bricks on his base. We'll see if that works or not once we get to the table; I can always touch it up later.

Ettin
The two ettins were the the last of the large villains from this set, and I had a lot of fun painting them. I slowed down a little bit and gave these guys more time, though still taking shortcuts where prudent. The flesh was done with two-brush blending, and I am really happy with the transitions around the muscles and the bulging belly. The furry areas got a careful drybrush treatment. The only difference between the two ettins is that the rope that one has a red rope holding up his loincloth, and the other has more of a conventional brown rope color there.

Barghest

Barghest

Barghest Captain

A bevy of barghests
The last of the monsters is the barghests. Once again using simple techniques, I think these might be the best of the bunch. Base, drybrush, wash for the fur, but with slightly different colors for the mane and body. I also took the highlights up pretty high before toning them down with the wash, giving these more effective highlights than some of the others in the set. The gory side was done with a fleshy base color, more blood-hued wash, and then manual highlights. The bones were painted last. Honestly, some of the bones looked really good when they were just grey primer splattered with bits of paint and wash. Once I painted over them, they looked more stark, and I thought about taking them back to a bloody bone rather than a stripped bone look, but truly, these guys are kind of gross, and I had enough of looking at them. 

That's it for the core set villains. I have the heroes all ready to go, and I want to paint enough of them that we can try the game out while I'm painting the others. My brother also bought me a Heroes & Monsters expansion with some great new creatures, so I may move right into that after the heroes.

Tune in next time for the heroes, although you'll probably hear more about story mapping or board games in between. Thanks for reading!

Friday, March 3, 2017

In game design, religious equality is still a philosophy

Yesterday at GDC, Sid Meier and Bruce Shelley gave a classic game post mortem about the original Civilization. It was an interesting talk, with the two giving honest reflections on what went well and what didn't go well. One of the more interesting concrete data points was that the whole game was made for about $175,000, which is about what it would cost today to hire one good developer for one year.

During the Q&A, someone asked him to reflect on how they represent religion in the Civ games, and particularly, whether there was any real pushback on their design choices. Meier responded that they always tried to treat all religions basically the same, that they would all increase happiness in their own way, and that they avoided things like religious war.

It struck me that this idea—that all religions are basically the same just with slightly different mechanisms—is actually still a philosophy. Choosing this stance doesn't somehow make you neutral. In fact, stretching my understanding of political and philosophical ideology a bit, I think it makes you Marxist.

Can you imagine a variant of Civ where some religions are simply better than others? Christianity has the most followers worldwide according to my Google skills, so does that make them stronger? What if non-evangelizing religions could simply be wiped out? I do not advocate either choice for the representation of religion in games; my point is simply that these are not worse philosophies, even though they may be worse design decisions (e.g. to appeal to the mass market).

I am reminded of a case several years ago where a student in my game design class was modding Risk so that it was about religious influence rather than military might. He drafted some rules that had each player as a different major world religion, and they each had different strengths based on region and special abilities. Players would win the game by converting the most people to their religion. As you may have already guessed, he came from a Christian background. I asked him about his treatment of Jews, given that they don't seek out converts the way that, say, Christianity does. He simply hadn't thought of it. The design was abandoned shortly afterward because it had no teaching value, even though the game systems still ostensibly worked.

I still get students who get excited to make games that teach players about world religions, since a lot of my projects have involved educational games for kids. I tell them the story of the Risk adaptation as a cautionary tale, and this helps them realize how hard it really would be. Any design carries with it a philosophy, and knowing whether a design is good or not requires very careful identification of criteria for success.

Thursday, March 2, 2017

Learning that story maps are harder than they look

Some time last semester, my chair asked if I would teach a section of CS691, a new graduate course for my department's Masters of Science in Software Engineering program. The course is titled Software Requirements and Design, so right off the bat I was a little put off by the sheer waterfallness of it. I have been mostly uninvolved in the MSSE program, which struggles to get started for various reasons. Be that as it may, requirements and design are definitely concepts in my bailiwick, so I agreed to put together the best course I could. He told me to expect relatively low enrollment, given the low number of students in the program, but we had to offer it anyway because these students need it to graduate.

As I was procrastinating designing the course, I received a call from my friend Kate who is working with a local non-profit, ecoREHAB. She's leading a team of students who are revising the organization's marketing materials to help ecoREHAB better explain its mission and values. Working with their board, she had some ideas for potential software products to help. This aligned very well with the learning objectives of CS691, so we agreed to a collaboration. I didn't yet know how many students I would have or what their background was, but ecoREHAB was very understanding of this: though I couldn't promise a product, I was sure we could build a prototype, and that would be enough that we could see if it was worth pursuing to production or not.

This brings us to the point of the blog post: yes, once again, it's story maps! I decided to use this technique in CS691 to capture and track high-level requirements, and so I assigned Patton's book as required reading. With my plans in place, I awaited the start of the semester. Turns out, I only have three students in the course, two of whom need it to graduate and one who is taking it as an elective. During the first week of the semester, we read the first few chapters of Patton and completed his "morning routine" story map, where a team builds a story map of what they do in the mornings. The argument in the book is that people already know how to make story maps, they just need to learn how to do it in a disciplined and pragmatic way. This exercise went well, although the students pushed pretty heavily toward making a taxonomy rather than a map. That is, they wanted to classify and make categories rather than focus on discrete stories. I pointed this out, and we moved on. We made a second story map, based on a straightforward problem a friend of mine had last semester: he wanted to know which courses the faculty in his department wanted to teach or did not want to teach, and have that information readily available when scheduling. Here, too, I don't think what we came out qualified as a "story map" as defined in Patton's book, or at best, it was an awkward one. I pushed the students to think about this, but they believed it was satisfactory. We put these "starter" maps aside as we spent the rest of the month in a kind of race through background books, papers, and ideas. According to the schedule I had laid out, by early February, we would be returning to our community partnership; I figured we would come back to these issues then.

During our month working together, I came to truly respect my students. Part of it may be the small class size—there's nowhere to hide, and everyone gets to speak their piece. Regardless, these three are excellent students: they keep up with all the readings, they ask great questions, and they voice and justify their opinions. One has industry experience from overseas, one has local small-team experience, and one comes directly from undergrad and a masters in another discipline. I don't think I could have picked a better mix of students. I say all that in part to qualify my comments below: I have no doubt that these students are doing their very best.

I decided I wanted to give the reins to the students when we did our planning meeting with members of the ecoREHAB board. To bridge our background work to the project, I did another story mapping session. I'm working from memory now, and I don't quite remember the context I picked, but again, I felt like there were pieces that the students just weren't getting, like sliceability and the difference between an activity and a category.

This took us to our big meeting with the community partner. A student volunteer led the session, and he did an admirable job for a first-timer. It's easy to forget that this stuff is hard, just simple things like keeping people on track during a meeting, welcoming different perspectives while being mindful of the time. Also, we have no courses that help students with this kind of process; if I were to teach this course again, I would put some of this into the course description, since where else would students get the chance except when studying requirements gathering?

One of the team could not make this meeting, so we recorded it. This proved to be quite useful, since the team agreed that our one-hour meeting with ecoREHAB could not have possibly produced as rich a story map as we wanted. I challenged each student to make their own story map, reviewing the recorded video as needed, and we came together in our next meeting to share what we had found. I kept my Socratic composure as I pressed the students to evaluate their and their peers' maps. They had differences of course, yet they were still pretty confident... but I was not. In an inspired moment of which I am rather proud, I decided not to tell them what I thought was wrong; instead, I assigned them an essay, to return to Patton's book and then to think and write critically about what they know about story maps and how they know it. This was on a Friday, so I tried to put my own concerns on the back burner until we could get back together.

On Monday, the first student I met in the hallway shook his head and said something like, "That damned essay." He proceeded to tell me how much he disliked it because it forced him to realize how much he didn't know. I tried to turn that ship around and tell him that this means the essay worked! As I was doing this, the second student came in, muttering with half a smile, "That essay..." As you might guess, all three students came in a bit dejected, but I think much smarter than when they had left on Friday. All three wrote brilliant essays about what they thought they knew, and about how they realized that their assumptions were wrong. We had an excellent discussion about this, including trying to think of factors that led them to believe what they now had come to doubt. I was joyful to see them begin to dissect the differences between a story map and a hierarchy. We talked about sliceability not as a requirement of a map but as a property of a well-designed map. Perhaps most critically, a student voiced a real concern: if this technique was so hard to learn, was it worth it? For them, of course, it's an open question. For me, who had also made mistakes in my first attempt to learn the technique, I have already paid the cost of learning and reaped the benefits in my studio class. It will be interesting to see what happens to their skepticism as we move forward with our project.

That led us to the real problem: what do we do about this community partnership, given how much trouble they had already had? We agreed that I would make a story map to the best of my ability and we would start into the project using that one. This would give the team the opportunity to work with a reasonable map (I'm still learning too, of course) and reflect, particularly after an iteration is complete, on the impact of this technique. I made the map, with some student input, on this past Monday. We were sure to include conditions of satisfaction with each story, as I wrote about before. but then I headed out to a conference and, after that, Spring Break week. I expect to write about what happens in the back half of the semester later.

Thursday, February 16, 2017

Writing about writing about writing

I require some reflective writing in my CS222 class. Currently, I'm using two essays during the first three weeks to help students reflect about Pair Programming and Object-Oriented Programming, and I use reflective essays at the end of each of the three final project iterations. Many of the course achievements also involve writing essays. For several years, I found myself frustrated with the range of responses to my request for an "essay," with a few nice compositions buried under the weight of banality and formlessness. Because I subscribe to mastery learning, my students can almost always resubmit their work, but there's nothing more frustrating than responding to a poor composition and then receive another poor one in return.

I realized long ago that part of the problem was this word, "essay," which is used by different people for vastly different purposes. I found myself writing the same response to each student, and so I put together the following stock instructions. These have appeared on many course descriptions under the heading, "An etymological note."
Some assignments and achievements require the writing of an “essay.” I use this term in the classical sense, to describe a composition that represents an attempt to understand a complex idea. An essay is neither a summary nor a staid five-paragraph construction. As the course prerequisite implies, these essays should represent collegiate-level writing. You are encouraged to leverage our digital writing environment to compose multimodal pieces.
For the record, I believe I have had zero multimodal compositions submitted in response to essay prompts—not so much as a photograph or illustration. I like to keep this door open, though, since students are required to take a college composition course before CS222, a course which explores more than just traditional prose.

After putting this note into the course descriptions, it has made it a bit easier for me give feedback: instead of writing out belabored instructions about what I mean when I say "essay," I can just point back to the course description. Even in this case, however, revisions don't always show that students have read and understood these instructions. The instances that come to mind tend to be structural problems, where the first submission lacks paragraph structure, and the second submission does too. It's enough to make me wonder if the real problem is ignorance about fundamental structuring tools, but usually, eventually, we get to a point where a revision is acceptable, though never elegant. I always recommend the use of BSU's Writing Center, but I have no idea if my students are using it or not. (Turns out, writing this blog post pushed me to reach out to them, and they do collect some self-reported data from visitors; they're going to try to let me know what kind of visits they've had from CS222 over the past few years. Neat!)

This semester, after frustration and reflection about last semester's writing, I decided to change my instructions on the course description. It was during the winter break that I took some time to compose a piece about what it means to compose an essay. I suppose I went full-meta. Here's what appears on this semester's CS222 course description, under the new and simpler heading, "Essays":

Some assignments and achievements require the writing of an “essay.” I use this term in the classical sense, to describe a composition that represents an attempt to understand a complex idea. An essay needs to have a point—a theme, a thesis, a central question. This should be supported by evidence, with assumptions identified and claims justified or cited. As implied by this course's prerequisites, our essays should represent college-level writing. 
An essay, properly written, should hurt a bit. If you are truly writing to understand, then you have to be challenging yourself. If you are only summarizing something you have read or previously believed, it is not an “essay” by our definition. 
Writing in this way has implications for structure and form. One long rambling paragraph cannot be an essay: each paragraph should have a clear and coherent theme that supports the central argument, and you need more than one of these to support an argument worth forwarding. The fact that we are writing in a digital environment should not be overlooked: you can include images, video, sound, and hyperlinks, following the same judgement you would use to include any formal element. Even typefaces, colors, and margins are part of a digital composition. These have meaning, and because of that, you should not change them unless you are proficient in digital document design: the defaults are provided because of their generality, and they are likely appropriate for your compositions. 
The Elements of Style provides an excellent refresher on how to produce good, clear writing. It is a short, affordable book in its latest release, and the earliest printings are in the public domain (see archive.org, for example).
I'll point out a few pain points that were on my mind when I wrote this. First, a great many of the submissions don't have a point: no thesis, no theme, no conclusion. I wanted to get at that right from the beginning, because if they do nothing else, I would like them to at least have a point.

The second paragraph is about pain. I see a lot of students write in generalities, avoiding specifics, avoiding culpability, avoiding conclusions. I believe that learning should hurt a little, because it's forcing you to confront something you misunderstand. This may be a lofty goal for a 200-level course, but I wanted to see what happened if I put it out there. Looking at it now, maybe I should revise that paragraph to be more about discussing concrete details rather than throwing around abstractions and generalities.

The third paragraph reflects my continual bafflement at how bad students are at using modern writing technology. We're using Google Docs, so we're not just digital, we're connected. Yet, students practically never include the URLs to their sources, much less actual hyperlinks. What many students do, that I react to in the paragraph, is fart around with fonts and sizes, almost always in ways that distract from the readability of the document. I know that the prerequisite writing course covers a bit of visual design, but clearly, students are not coming through with the self-awareness that they are bad at it. That's understandable coming out of a freshman-level course (isn't that what being a "sophomore" is all about, after all?), but what bothers me is that it's not clear that they understood that these choices have meaning. That is, the choices I see appear arbitrary, not treated like the design decisions that they are.

The last paragraph is my way of sharing my excitement at finding out The Elements of Style first edition was in the public domain. I was required to buy a copy of this book (not the first edition, naturally) in my first semester of grad school, as part of a research seminar course in which faculty presented their research and new grad students wrote essay responses. I remember enjoying the book, not so much because of the structural concepts—I've always been a decent writer, after all—but because it helped me collect my reasons for good writing practice. Maybe it's too much to expect that a sophomore CS major would go fall in love with style, but a guy can dream.

That's the story behind my revised essay-on-essays. I see some parts that I will likely clean up between semesters. So far, it's not clear that it's made any difference at all, except again for the time it saves me: I have referred a handful of students to it after they turn in something completely unstructured or inappropriate.

Tuesday, February 7, 2017

Follow-up on Story Mapping: Sprint 2 Planning

My team had our Sprint 2 Planning meeting yesterday, and I started with the story map on the wall that I wrote about over the weekend. Most of the questions the team members had were covered in the conditions of satisfaction that I had written on the note card version of the stories. The team decided to migrate two stories below the cut point, pushing them to Sprint 3 instead. The first of these was the external authentic testing of the software system: since the team was committing to making a high-fidelity paper prototype, they were rightly wary of also trying to budget the time for authentic testing. Since we would focus on a paper prototype, we also pushed down the task of making a design guide to specify fonts, colors, and so on. This was also a prudent move, since if the paper prototype evaluation went poorly, we would need the time to clean that up before investing time in a design guide that would likely have to be done again.

Much of this conversation went as I predicted, but the task planning ended up with some interesting results. Several new stories were added to our map, most of them planned for the next iteration.


These new stories dealt primarily with user interactions that we could foresee only after talking through the extant map and considering the bounds of the stories we had committed to. The new stories include:

  • Continue uninterrupted if the page is reloaded
  • Install the game as an app (manifest.json)
  • Continue after pressing the browser's back button
  • Browse previously unlocked content
  • Clear previously unlocked content
  • Finish the story for Prairie Creek
That last one is not a user interaction, but simply our team noticing that we had neglected to include a story for the creative work of finishing our narratives! By the end of this sprint, we should have significantly reduced risk around our core game mechanics and theme, but there still will be necessary work in fleshing out the narrative.

Saturday, February 4, 2017

Another attempt at story mapping in the academic studio

About a year ago, I wrote about how my first attempt with story mapping did not go as well as I had hoped and that my team eventually abandoned them. Last semester, I decided to invest some time in building a better understanding of the technique, so I did what any reasonable contemporary developer would do: I bought and read Jeff Patton's book. One of the key insights I got from this book—perhaps something that's obvious to regular practitioners, but I didn't see at the time—is that story maps can replace one-dimensional backlogs but not Scrum-style task boards. That is, while the story map provides the big picture of the project plan, teams still need other modes for tracking smaller-grain tasks. Among other factors, this made me want to revisit story maps in Spring, and so I have.

This semester, I am once again leading a multidisciplinary undergraduate team in an immersive learning project. I wrote a bit about the project when I wrote about sustainability game design and the conclusion of my game design colloquium. This semester, my team is building a Web-based, geolocative, educational game to complement the educational themes of Camp Prairie Creek. We just wrapped up our first sprint, which resulted in the team building a proof-of-concept experience using Polymer while exploring various narrative themes. Before the sprint, I had laid out a story map based on my vision for the project, and the team had some input into the overall shape of it.

Sprint 1 Story Map

During sprint planning, the team decided where to slice it. We took the stories for this first experimental sprint and transcribed them onto new cards for the task board.

Task Board at the start of Sprint 1
The sprint ended this past Friday, and although not every task was complete, we deemed it a success: the team was able to learn the fundamentals of Polymer, including building fluency with command-line git; we have a technical artifact that shows how various pieces fit together; and we have a more coherent vision for a narrative structure and theme. However, throughout the sprint, I didn't see any students actually using the story map. They would congregate around the task board around the time of the stand-up meeting, using it to direct their communication and activities. The story map, which is physically far from the task board, did not seem to get any attention.

One of my responsibilities yesterday was to recreate the story map based on what we learned. The first pass looked reasonable.
First pass at revised story map
During Friday's Retrospective meeting, the team decided that their work would be improved by the inclusion of conditions of satisfaction for each story. Usually, when using Scrum, I write the names of stories (in Mike Cohn's format) on the front and the conditions of satisaction on the reverse. It was not clear to me if these fit with the story map format, so I had left them out in the name of simplicity. I have one returning team member who was in last Spring's studio, and this student was one who strongly recommended including the conditions of satisfaction. So, after creating that first pass at a story map, I sat down with my large-format index cards and starting re-writing the stories to them.

This process led me to consolidate several stories. This wasn't quite what I expected, but the new articulations were much cleaner, in my opinion: they were more encapsulated rather than spreading one action across multiple notes. For example, "See a map with location markers" and "See my own location on a map" became consolidated into "See annotated map," with conditions of satisfaction indicating that we want to see both our own position and marker positions. These could remain separate, but I was thinking about how they would migrate to the task board: the two small stories looked like they would take up more room than they were worth, whereas one story would just have a few extra rather small tasks. It may be worth noting that the team already has this mostly done in the tech demo, so much of the story will be revising how this feature is implemented within the revised visual design.
Revised story map
I've included below a photo of the task board cards that I expect the team to take in Monday's planning meeting. Of course they will be able to negotiate on what goes above and below the slice, but I suspect that we won't see much change here.
Stories with conditions of satisfaction, for the Task Board
[See follow-up post for more]