Thursday, December 22, 2011

CS315 Final Assessment: Games about Beneficence

For the last eight weeks of the Fall semester, the eleven students in my CS315 Game Programming class had been working as one team, following Scrum to complete a version of Morgan's Raid implemented entirely in Unity. The team worked very well together, as I have written about previously. At the end of the semester, they had produced a reasonable facsimile of the Morgan's Raid release, given our constraints.

Regardless of their collective accomplishments, I still have to assign individual grades to each student, and I take this responsibility seriously. We used self- and peer-assessments during our four two-week sprints, and these helped me approximate students' individual contributions to the project. However, I still felt that I was missing hard, individualized evidence, and so I presented my students with a novel form of final assessment that we called Mini Ludum Dare.

Ludum Dare is the Rapid Game Development Community, most well known for hosting regular 48-hour game development competitions. Each competition begins with the announcement of a theme, and all games must incorporate that theme. For our Mini Ludum Dare, I told the students to spend no more than four hours on digital prototypes, my rationale being that I wanted to see what they could get done in about a half-day's work. This seems like an appropriate assessment, that at the end of a game programming class, one can individually produce a proof-of-concept for an idea. Because I was grading strictly on technical issues, I also provided a "default" game design that students could use if they were not feeling inspired by the theme. They were allowed to complete the prototype in Unity or Slick, these being the two primary technologies of instruction for the semester.

The theme was "Beneficence." This can be interpreted in a few ways, the most obvious connection being to the statue who also graces Ball State University's logo.



During our university-assigned final exam slot, the students each had a few minutes to show off their creations. It was inspiring to see how creative our Computer Science majors could be! The Java-based solutions are a bit tricky to get online, but with some coaxing (and peer pressure from the community on the department's Facebook page), the Unity-based games are online. Here are some links:

A pretty amazing selection of game prototypes built in only a few hours each. Nice work, gentlemen!

Bloom's Taxonomy of the Cognitive Domain

Two nights ago, I gave a presentation at the 2011 IGDA Indianapolis Charity Toy Drive, a great event that I hope becomes an annual tradition. My presentation was entitled Fun, Learning, Games, and Responsible Design (in under 20 minutes). I gave an overview about the relationship between games and learning, and my core message was a rallying cry, asking designers to seriously consider what players learn by playing their games. My perspectives on this are heavily influenced by Raph Koster's work, and as I told the crowd, every designer should read Theory of Fun for Game Design.

I generally don't post slides from my talks because the slides don't stand alone: you could not reconstruct the message by only looking at the slides. I agree with Martin Fowler, that "slideuments" are flawed by definition. However, there was one slide from my talk that really seemed to resonate with the crowd. I based much of my presentation on applications of Bloom's Taxonomy of the Cognitive Domain toward gameplay experiences. Wikipedia has a nice, simple diagram that presents the taxonomy, and I have used this in presentations and handouts before---but this was always when using OpenOffice.org or LibreOffice directly. For the IGDA presentation, I needed a PDF, and something about the conversion to PDF left the diagram quite jaggy. To solve my problem, I made my own variant on the public domain image within LibreOffice, and it looks a little something like this:


This variation is CC-BY in case you want to insert it directly into your own presentations, papers, posters, etc. An ODG version is available as well. Full license terms below.

Creative Commons License
Bloom's Taxonomy of the Cognitive Domain by Paul Gestwicki is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at en.wikipedia.org.

Monday, December 19, 2011

Books for practitioners

At the end of the semester, a few students asked me for technical book recommendations. I have listed below the books that I tend to reference most often in my teaching and in my practice. Links to Amazon's listings are provided, not because I specifically endorse Amazon, but they sure are convenient.

All of these books are worth reading, but where you start depends on your interests. If you are interested specifically in object-oriented design, definitely start with Holub on Patterns. Clean Code and The Pragmatic Programmer are replete with bite-size tips that can immediately make you a better professional. Pragmatic Thinking and Learning is not about technology per se, but rather it is about how to be a more effective learner. Finally, Cockburn's book is the largest and most academic on the list, but it provides tremendous insight into how one can approach software development methodologies from a perspective that is both humanistic and scientific.

Monday, December 12, 2011

Thoughts on Deus Ex: Human Revolution

I've been playing Deus Ex: Human Revolution, and I had a few game design thoughts to share. This post contains minor spoilers. You have been warned.

A lot of people have commented on the incongruous "boss fights" in Human Revolution, and rightly so. They are quite embarrassing, really. They force the player out of the story, thrusting you through the fourth wall to realize that yes, this is a game, you just finished a level, and so there's a boss fight.

Not that I've scoured the Internet for reviews, but I have yet to see anyone else address the issue of the game's beginning sequences. In a game that prides itself on cleverness of storytelling, how am I supposed to believe that Adam Jensen is actually the head of security in a multinational biotech company? In the first level after the prelude, my boss—the man who runs the company—gives me a choice of exactly one weapon to take with me into an unknown situation. I take it for granted when I have dozens of inventory slots that I can probably carry more than just a short-range stun gun. We can let this one slide because it's a tutorial level, but notice that this is a foreshadowing of the narrative-jarring boss fights: this is a game that knows it's a game and won't let you forget it.

The next scene has Adam Jensen, Head of Security, back in his office building. Once I realized I had an office, I checked my email and found out that someone has been stealing office supplies. So, what's a Head of Security to do? Obviously, the answer is break into some offices and search for clues. Break into offices?! I'M THE HEAD OF SECURITY. I should be able to get into anyone's office, and I sure as hell shouldn't have to CRAWL THROUGH DUCTWORK to do so!

Aha, so the game wants me to learn about breaking and entering in a safe place, where there are no armed enemies. It felt wrong to crawl through ductwork in my own building, especially when every office has windows, through which you can see people chatting in the hallway. So in the spirit of "it's just a tutorial," we could let it go. However, there was one part of this scene that completely snapped me out of the game.

There was money everywhere.

It seems that in the future, people only use gift cards, and they leave them all over the place. It made me wonder, if I were to walk through my building (or crawl through its ample ductwork) and look at my coworker's desks, how many would have hundreds of dollars on their bookcases or in their desk drawers? But it wasn't just the presence of the money that bothered me: it was the gameness of it. I found myself staring at a credit chit, wondering if I should take it or not. More specifically, I wondered, Does this game have a karma system, and am I going to lose morale or reputation for taking this? See, this stuff wasn't credits or money at all—it's just a mcguffin that I can collect. And because it's there, I need to take it, because I know how the economics of these games is balanced: if you want to get the best goods, you need to be an explorer and take everything you can find. I'm not taking cash from my coworkers. I'm just collecting arbitrary units that I can use to get the bigger gun I know I'm going to need, because the only other thing I know about the game at this point is that there's going to be rough boss fights. (Thanks, Internet!)

I finish exploring every nook and cranny of the building that I can access without leveling up my hack skill. After all, I don't want to actually hack my own building's security system, I just want to explore its ductwork. The next mission has me leaving the building and getting out into the streets of Detroit. (The Assassin's Creed developers know how to make a city feel crowded; Human Revolution pays homage to the empty streets of the original Deus Ex.) One of the first places I visit is a weapons dealer in an abandoned gas station. I am Adam Jensen, Head of Security, and I'm buying a tranquilizer rifle with stolen money from a guy in an abandoned gas station. I cried a little and almost stopped playing, but at this point, I haven't seen one of those famous boss battles yet, so I felt obligated to carry on.

They did do a nice job allowing for multiple solutions to problems, and I did have fun playing the game. I'm going to jump ahead to the ending. The spoilers get more serious here, so be warned.

Ninety percent of the story involves Adam looking for Dr. Reed. Whether it's love or curiosity doesn't matter: it's Reed that he's after. You see her for a brief moment, right before going into the endgame. If you've read this far in my post, then you probably already know that the ending is determined solely by one decision at the very end of the game. This was the worst part of the original Deus Ex, that everything you did amounted to nothing except for your very last decision. Again, Human Revolution pays homage to the wrong part of the original. This one was even worse, though, since what screamed out to me as an obvious option was completely missing. All I wanted to do was stop the transmission. That's it. Stop the transmission, then go get picked up by Malik, go find Reed, and talk to her. I don't want to send Crazy Cripple Guy's message, or lie about terrorists, or something else I don't care about, and I certainly don't to kill myself and everyone else that I just painstakingly avoided killing.

The original Deus Ex ended with you having to chose one of three options, none of which were appealing, but all of which were inevitable. This one felt completely contrived, as though the designer just couldn't wait to show me B-roll of starving kids in Africa. I guess I am the sap. I actually empathized with Adam, and I actually wanted to know why he cared so much for Reed, and how she really felt for him. I thought they would come to some understanding about where Adam came from. The character development in this game was awfully shallow, but I fell for it, because I play these games for the RP part of RPG.

In conclusion, my recommendation is, after finishing Human Revolution, go play The Missing Link DLC. At first, I was upset to hear that some really good content was left of the game and released as DLC; I think this is a bad direction for games, especially for elements that happen chronologically in the middle of the main story. However, in this case, it was a blessing. The Missing Link was quite fun, with interesting levels and much more believable and interesting characters. When Missing Link ends, you can pretend that you don't actually know what happens next, and your imagination can then give you a satisfying conclusion.

Friday, December 9, 2011

CS Ed Week: Reflections on a busy week

Once again, we've reached the end of CSEdWeek, and I'm pushing to get this post in before it's over.

I attended two blogworthy public events this week. On Monday, I went to the Indiana Historical Society's Annual Founders Day Dinner and Awards celebration, along with my collaborator Ronald Morris and our Dean, Michael Maggiotto. The College of Sciences and Humanities at Ball State University was awarded the Outstanding Project of the Year award for Morgan's Raid.


Among the other recognized individuals and organizations were eight Centennial Businesses, Indiana companies celebrating 100 years of operation. Not surprisingly, none of these were software development companies. However, I'm willing to wager that all of them now rely upon software for their daily operations. In 2111, will they be looking back at 100-year-old software development shops?

Wednesday was the BSU Building Better Communities Project Showcase, where about twenty student teams showed how they worked with faculty mentors and community partners. Several of my students were there to demonstrate the Digital Archaeology Simulation project. A poster provided the background and rationale for the project, and the software is still under development by Emerging Technologies. A prototype was available, and while I didn't take the opportunity to run the latest build, several passers-by told me that they were quite impressed. Ball State University President Jo Ann Gora spent a few minutes with members of the team to talk to them about their work—a great opportunity for the students to show some of their best work (even if the photo is rather poor).

This week was also the final project presentations in CS222: Advanced Programming. Each team of four had to pitch a project and complete it in six weeks, with two three-week milestones. Several of the teams impressed me with their hard work and dedication, investing significant amounts of their own free time in order to create the most impressive systems they could.

Rather than make any grand conclusions, I think the best way to close this post is to say that I have a great job. My students rise to the challenges I set before them. They appreciate learning how to learn, and they respect the fact that I respect them. We all get a bit stressed this time of year, but it feels good at the end of a busy week to reflect on all the great learning experiences I have had with my students this year. Thanks to my students for sticking with me, for trusting me even when my methods are unconventional.

Happy CS Ed Week.

Wednesday, November 30, 2011

With great power comes great responsibility

This was discovered in RB369, the Computer Science lab, and shared on the department's Facebook page. 


I wonder if I can include this as a student evaluation in my promotion and tenure materials?

Monday, November 14, 2011

All the UML you need to know

Each semester, when I teach CS222, I give a one-class lecture on UML class and sequence diagrams. It always goes the same: I introduce some ideas, then give the students some time to draw some diagrams, and I critique them. It works well, except for the lecturing part. That part is boring, for me and for the students.

This year I am trying something different. I have created a Web site off my BSU space called "All the UML You Need to Know." Actually, I've only half-created it. We already discussed sequence diagrams in class earlier this semester, so I didn't take the time to write that section yet.

I sent out the link to my students earlier today. Tomorrow, we'll talk about class diagrams, and I will direct them to this site as a resource as they play with the ideas. It took about eight times as long to write as it does for me to talk through it, which is actually not as bad as I had feared. Hopefully this will save me time in the long run, but more importantly, it will give the students accurate notes about the parts of UML I expect them to know.

Friday, November 11, 2011

Social networks, fairies, and Club 369

One of the CS222 project teams is working on Club 369: The Game. "Club 369" is a reference to the Computer Science undergraduate lab, RB369, and the camaraderie that the space affords. The game is a Computer Science quiz constructed of multiple-choice questions.

On Thursday, the team gave their milestone presentation. Here's a screenshot of their executable release.

Club 369: The Game, Milestone #1
That guy on the bottom-right is "The Dr. G. Fairy". Let's take a closer look...

The Dr. G. Fairy
Clicking on him removes two of the incorrect choices, leaving the player with a 50/50 chance if they guess. Needless to say, this presentation got quite a reaction from the other students. When a student asked, incredulously, "Why?" a team member responded, "He's Dr. G. He helps you learn Computer Science." This is the nicest complement I've received in some time!

After class, one of the students posted the picture to the Ball State Computer Science Facebook Group, where it became a hit. It may seem a bit silly, but as I see it, it's a great success for the department. We created the Facebook group to help foster a sense of community among our students and alumni, and we've had some luck with members sharing informational links, job opportunities, and the like. The fact that students feel they can share this kind of fun content as well shows that we have succeeded in our goal. (I had to do a bit of legwork to understand the Butterfree and Hey! Listen! references in the comments, but this made it even more fun for me.)

Of course, I immediately changed my Facebook profile picture to the Dr. G. Fairy. This led some old friends to reminisce about the classic "Get Paul some shirts with color" Flash animation—a reference to my proclivity to wear black when playing at Higher Grounds Coffeehouse. I think we all assumed the animation was lost to the ages. My clever and creative friend Matt was able to find the old image and recreated the animation with a brand new feature.



Rubric-based self- and peer-evaluation on team programming projects

I have written before about grading rubrics, and I am taking this opportunity to share some of my recent developments here. In my game programming class (CS315), I have eleven students working together on one project. We're using Scrum, and it's still going well. The early part of the semester was ungraded, formative, small-project work, and I found myself needing a way to assign grades to the students. It may be worth mentioning that I don't actually want to assign grades to them, but it is a requirement of the course, and so I must do it responsibly.

I happened to stumble across a rubric I created in 2008, before my blogging days, while I was cleaning up my Web space. As I recall, this was an amalgam of several other rubrics I had found on the Web with an ounce of invention. This was my inspiration to create the following rubric:

3210
Commitment Attended all scheduled team meetings or notified the team of absence. Missed team meetings, with notifications, with enough regularity to be problematic. Missed one or more team meetings without notifying the team. Regularly missed team meetings without notifying the team.
Participation Contributed to sprint planning, sprint review, and sprint retrospective meetings. Did not contribute to one of the following: sprint planning, sprint review, or sprint retrospective meetings. Did not contribute to two of sprint planning, sprint review, and sprint retrospective meetings. Did not contribute to any of sprint planning, sprint review, and sprint retrospective meetings.
Communication Clear standup reports on what was accomplished, what is planned, and identification of impediments, to allow the team to continue to make progress. Some unclear standup reports that inhibit team progress. Regularly unclear standup reports that inhibit team progress. Did not give standup reports.
Technical contributions High quality technical contributions that facilitate success of the team. High quality technical contributions that do not directly facilitate the team's success. Low quality technical contributions that frequently require redress by other team members. Low quality technical contributions that inhibit success.
Attitude and Leadership Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. Listens to, shares with, and supports the efforts of others. Frequently fails to listen, share, or support teammates. Displays an antagonism that inhibits team success.

I created this after the team's first sprint, and parts of it are reactions to problems the team was having. For example, in the team's first sprint retrospective, they identified that many had spent inordinate time on aesthetic issues that were unrelated to the user stories. Hence, there is a distinction between those technical contributions that facilitate success and those that do not. Note that the numbers across the top relate to my triage grading approach; some day I will write a blog post about my experiences with it, but for the time being, suffice it to say A=3, C=2, D=1, F=0.

I shared this rubric with the team during Sprint 2, and at the end of the Sprint, I asked each person to do a personal evaluation. This was designed as a formative evaluation for the student as well as a trial run of the rubric. From reading the students' self-evaluations, I think the instrument worked as intended, and we're going to do self- and peer-evaluations at the end of this sprint.

In my other course (CS222), students are working in teams of four on six-week projects of their own design. They just finished their mid-project milestone presentations, and I've modified and distributed the rubric to this other group as well. I've highlighted those cells that have changed.

3210
Commitment Attended all scheduled team meetings or notified the team of absence. Missed team meetings, with notifications, with enough regularity to be problematic. Missed one or more team meetings without notifying the team. Regularly missed team meetings without notifying the team.
Participation Contributed to project planning, implementation, testing, and milestone presentations. Did not contribute to one of the following: project planning, implementation, testing, and milestone presentations. Did not contribute to two of the following: planning, implementation, testing, presentation. Did not contribute to three or more of the following: planning, implementation, testing, presentation.
Communication Clear reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress. Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress. Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress. Communication patterns directly disrupt team progress.
Technical contributions High quality technical contributions that facilitate success of the team. High quality technical contributions that do not directly facilitate the team's success. Low quality technical contributions that frequently require redress by other team members. Low quality technical contributions that inhibit success.
Attitude and Leadership Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. Listens to, shares with, and supports the efforts of others. Frequently fails to listen, share, or support teammates. Displays an antagonism that inhibits team success.

These students are not using and are not familiar with Scrum, and so the Scrum-specific references needed to change. I am not that happy with the articulation of participation above, in part because we invested a lot of time on test-driven development, and I fear the students will be confused about separation of testing and implementation. The "communication" entry is clearly influenced by the idea of the Daily Scrum, but I have not previously suggested this particular reporting strategy to the students.  My hope is that by asking them to conduct rubric-based self- and peer-assessments, they will gain some insight into better ways to organize themselves. As with the game programming students, I am using this first pass as a formative assessment, and also as an instrument to help me identify teams that are having problems with team members—an unfortunate but oft-inevitable situation.

The students in CS222 had their first group experience with rubric-based evaluations this week when they evaluated each others' milestone presentations using this instrument:

Presentation requirementSatisfactory (3)Probationary (2)Unsatisfactory (1)Unacceptable (0)
Executable release Stable and appropriate demo of executable release Unclear demonstration of stable executable release Unstable executable release No demo
Milestone #1 Estimate Clearly met milestone estimates Clearly met a reasonable subset of milestone estimates Did not meet an adequate subset of milestone estimates Progress on initial estimates was not addressed
Milestone #2 Estimate Clear presentation of well-articulated estimates for next milestone Clear presentation of poorly-articulated estimates for next milestone Unclear presentation of poorly-articulated estimates for next milestone Milestone #2 estimates not addressed
Software architecture Good presentation of reasonable software architecture Decent presentation of reasonable software architecture Unclear or awkward software architecture No presentation of software architecture

I printed these on small slips of paper. On Tuesday, we had four presentations, so I instructed the students to pick up four slips as I talked through the structure and purpose of the rubric. On Thursday, we had five presentations, so I left the slips in the same place in the back of the room and I put on some mood music.


I was a little disappointed that none of them stopped to tell me how incredibly clever this was.

Sunday, November 6, 2011

Morgan's Raid on CD

We recently received a request to make Morgan's Raid available to a school that has blocked Internet connections from its lab machines. Morgan's Raid was built for distribution via Java Web Start (JWS), which simplifies the process of dealing with native libraries. However, as the name implies, the technology was designed for computers with Web connections. Distributing as an executable jar is not possible because they do not adequately handle native libraries.

The JNLP file contains all of the configuration information for JWS. This includes codebase, through which JWS determines where to find referenced resources. The Morgan's Raid codebase points to the server that hosts the jar files, for example. Turns out that if you leave out the codebase, it will default to the same path as the JNLP file itself.

My next step, then, was to revise the Morgan's Raid JNLP file for local files. I created a CD containing all the requisite jar files and the revised JNLP file. Running the JNLP file off of the CD almost solves the problem. The game runs, and it creates a desktop and start menu shortcut in the process. However, it also records the fact that the jar files came from the optical drive. As a result, the game will then only run with the CD in the drive, even though all the jars have been copied to Java's cache: JWS still tries to check the codebase to see if there's any changes to the files or configuration.

The problem is easily solved by having the user copy the CD contents to any folder on their hard drives and running the JNLP from there. Now it's this path that is recorded by JWS, so using the desktop shortcut or start menu shortcut will happily run the application locally. This gets the desired result that I can hand someone a CD, and they can put it on as many machines as desired, without my having to fiddle with installation software beyond JWS. (I guess that changing the location of those files would break the installation, in the same way that removing the CD did before, but I did not verify this.)

With my CD experiments successfully concluded, and after a little help from my department's friendly system administrators, the result looks like this:


I found it deeply satisfying to hold this disc. Physical media doesn't change the existential state of the software system, but there's something about holding this disc in my hands that made the software more real.

As I was printing the CD, a sysadmin asked, "Does it have to be on CD?" Her reason for asking was that she had blank white DVDs, on which the printed label would be more crisp, but I thought she meant, "Can't it be on something other than a disc, like a thumb drive?" I laughed aloud when I realized that I had never considered anything but an optical disc for this project, because, you know, software comes on discs!

Monday, October 31, 2011

Chasing Dragons

A few days ago, my wife and I watched Get Lamp, a documentary on the rise and fall of text adventures and the persisting genre of interactive fiction. I had heard about it on Richard Bartle's blog and have been eager to watch it. I grew up playing text adventures on my C64. Although I spent a lot of time reading Byte and Compute magazines—mostly typing in BASIC programs and reading advertisements for games, as I recall—I did not have a larger context to understand the industry and the personalities behind it.

I found the documentary fascinating, but I'm not sure how strongly I can recommend it to those who didn't cut their teeth on text adventures. The documentary assumes a certain amount of tacit knowledge: how could a viewer appreciate the discussion of mapping if they had never been in a maze of twisty little passages, all the same? I'll definitely bring it up for a potential movie night next semester when I'm at the Virginia Ball Center for Creative Inquiry.

The documentary consists almost exclusively of interviews, and one of the interviewees was Chris Crawford. I had previously only known him by reputation as a respected game designer and as the author of The Art of Computer Game Design. I enjoyed his interview in the documentary as well as the extended interview in the DVD extras, so I decided to read more about him.

Of course, I turned to Wikipedia, on whose page there is a section devoted to Crawford's Dragon Speech.   Wikipedia's summary piqued my curiosity. Thanks to the wonder of the Internet, this 1992 speech is available on YouTube, despite its having been given a year before Mosaic ushered in the World Wide Web revolution. I've embedded part one here; parts two through five should come up as recommended links after.



This goes immediately into my list of great presentations (which someday needs to migrate from my old blog to this one). Crawford is clearly a master of the topic and has carefully crafted the presentation. I could go on about the specifics, but really, you should just take some time to watch it. I am envious of the opportunity he had to study under another one of my heroes, Alan Kay. I'd love to have a day to shadow either of these visionaries, to get a better sense of how they see the world and of what drives them.

Crawford is passionate about his work, and it's his well-calculated passion that helped me to understand that this presentation isn't really about games at all. It's about dreams. It's about working to identify what it is that you really want, and then consciously and intentionally deciding to pursue it, even if it means making painful decisions.

Presentations like this make me uncomfortable, but that's a good thing. They induce introspection, resulting in an honest evaluation of what I am doing and where it is leading. I feel like I am in Crawford's six years at Atari: I'm working diligently on what seems right for now, but every now and then I see the shadow of the dragon.

Sunday, October 23, 2011

Notes from the Indiana Video Game Developers' Business/Game Design Panel

Yesterday, I went down to Indianapolis for the Indiana Video Game Developers Business/Game Design Panel, hosted by the Independent Video Game Developers Association and the Indianapolis Chapter of the International Game Developers Association. The bios of each of the panelists are available online, so I won't  summarize who they are here, but it is noteworthy that there was a great mix of expertise, including those interested in corporate branding, serious games, independent self-funded development, and even an IP lawyer. One of my students was there with me, but it was a great discussion and I wish more could have come. I will use this post to share some of my notes, both for my own use and to share with those who could not be there.

The topic of iterative design came up several times, with the folks from Studio Cypher especially advocating for physical prototyping. Most of the panelists strongly advocated for focus groups throughout the development of a game. I was tempted to ask about specific methodologies: no one mentioned "agile" by name, but the spirit of it was strong. I ended up holding my question, in hopes that I could follow up with some of the panelists at a later date to discuss their methodologies more closely, perhaps even in a research context.

A few panelists mentioned making games for children and using children in their focus groups, so I asked how they went about recruiting children, especially since some were adamant about needing NDAs for focus groups. Two out of the three suggestions were the same approaches I have used: friends/family and schools. The other group they mentioned was the Girl Scouts, which I had not considered. They also mentioned that research firms could be hired, at a high price, to do these things for you. That's another one I had not thought of, but all agreed that this was likely not worth the price.

There were a few questions about how to choose technology for projects, and the panelists answered with a predictable and appropriate, "it depends." The panelists observed that all programmers want to write their own game engine, but that this is impractical unless it is one of the team's core competencies. This matches advice I've heard elsewhere, but I get the impression that the younger members of the audience had not thought about the issue before. When it came down to what technology was being used, there was glowing praise for Unity—even the teams that weren't using it seemed to wish they were. This made me feel good about getting my own game programming students this semester exposed to it.

While there was a lot of love for Unity, the relationship between HTML5 and Flash was mixed among the panelists. The consensus seemed to be that some clients had started asking for HTML5 games, but not all. While most current Web-based games were still in Flash, there was an expectation that HTML5 would be escalating quickly due to its being backed by such large corporations.

The highlight of the panel, for me, was actually something shared by a non-panelist. It was a question I was going to ask as well, but Andy Harris beat me to it. It sounds like he's in the same boat as I am, where he is constantly asked by middle and high school students what they should do to become a "game designer." When I am posed this question by prospective students, I explain, verbosely, the relationship between video game design and programming, the history of the two, and the transfer of skills among them. Andy had a much more memorable and clever explanation that, if you want to be a game designer, you write the code or you write the check. All the panelists agreed. This was great to hear, but I couldn't help but feel a little bad for the handful of young aspiring artists in the room who clearly had not done their homework along these lines.

The importance of a portfolio was mentioned, and after a question from the crowd, the panelists clarified that a portfolio is as important for programmers as for artists. One panelist recommend grabbing a library like Flixel or FlashPunk, then creating ten games with them, each one exploring a different aspect of game design such as pathfinding or AI. This would provide you, as a programmer, with evidence that you have the range of skills required. This sounds like a great break project to me!

The panel had been advertised as running from 1:00 to 3:30, but at 3:30, it was only an intermission to be followed by some other activities. Looking over the handouts, it looks like one of the activities was to be drinks at MacNiven's to talk about the IGDA, which would have been fantastic. Alas, I already had plans to return home for dinner, and so I had to step away. I am glad I was able to attend the panel, and it was great to see some of my colleagues whom I don't see very often. Next time, I'll try to keep time for a pint in my schedule!

Wednesday, October 19, 2011

DeMillo wrote this post for me already

I have been reading and enjoying Rich DeMillo's new book, Abelard to Apple: The Fate of American Colleges and Universities. I am planning to read the final chapter tonight and had intended to post a summary afterward. However, on his innovate-edu blog today, DeMillo posted his comments to the Joint Education Subcommittee of the Georgia Senate, and these provide an excellent summary of the book. This link will get you there.

Friday, October 7, 2011

Computer Science: It's not just for dead women

How ironic that today is Ada Lovelace Day, as I just took a picture of her out of a Computer Science Department display case this morning.

Since I came to Ball State, we had a display case that showed four images of women in computing. I did not snap a picture of the display case, but here are the four individual images.





On one hand, one could argue that these images show that women can succeed in computing. On the other hand, I think there's a good chance that a modern young woman who walks by these will come to the conclusions that women could succeed in computing, ... back before color photography and pants. That's not very relevant to a generation that has grown up with the Internet, social media, games, and service learning, four factors that have been identified that get girls interested in pursuing Computer Science.

I got the blessing from my department to update the display case, which now looks like this:

The plaques on the left and right are awards from the 2008 and 2011 CCSC:Midwest Programming Competitions, in which teams from Ball State placed second and third, respectively. In the middle is a research poster put together by the students who were involved in both the Morgan's Raid and the Digital Archaeology project. The poster describes how we used Scrum and principles of agile software development and the lessons learned in the process.

One wouldn't know to look at the plaques, but both teams comprised of two men and one woman. The genders of these students was irrelevant: their success speaks for itself. Taking a closer look at the poster, you can see that although the teams have a male majority, there are women there too.

This is not as flashy as the University of Washington's excellent Why CSE page, which overtly demonstrates how underrepresented groups can and do succeed in Computer Science and Engineering. However, it does show that—right here and now—women are integral parts of successful research and development projects. Whenever I meet with a prospective CS major, we walk by this display case. I am glad that now I can point to these pictures of some of our most successful majors and show how they are working hard, together, and that they are proud of their work.

After all, Computer Science is not just for dead women.

A new team's first Daily Scrum

We spent the first several weeks in my game programming class covering the basics and exploring two platforms for game development, Slick and Unity. On Monday, the eleven students decided that for their semester project, they would like to work on one big team to try porting Morgan's Raid to Unity. I decided to mentor the team using Scrum, since that has worked so well for me in the past. For Wednesday, I put together a product backlog and the team had its first spring planning meeting. While I had recommended that the students read The Scrum Primer, I got the distinct impression that the vast majority had not done so; in their defense, I had emailed the link Tuesday night.

The planning meeting went well, although fifty minutes was awfully tight to introduce the fundamentals of Scrum and to do the planning. I used my Scrum diagram as a reference to talk through the process. We were missing three of the eleven team members, but we were still able to get a reasonable number of stories committed for the first Sprint.

Today was the team's first "daily scrum." At 8am sharp, everyone was present. I told them to get into a circle and report what they had done since last time, what they had planned for next time, and what were the impediments. They got up and moved to the open area in the front of the classroom, while I stood behind the teaching station.

Here's where the team really surprised me. In using Scrum with students many times in the past, I have found that they find it challenging to report to each other, that they prefer to report to me. I wrote about how my Summer team was able to leverage the physical space to have productive Daily Scrums, but that team was half comprised of people experienced with Scrum, so their team-facing attitude was to be expected. This team of eleven had one student with Scrum experience (Tom), and the rest had none. They formed the circle and showed a few signs of anxiety, but Tom started right in with his daily status. He passed it on to the teammate by his side, and the whole stand-up meeting went as smoothly as one could hope.

There are four differences between this team and those from my past experiences, and I suspect that each is a contributor to this team's success. First and foremost, I learned a lot about managing a Scrum team through my experiences last academic year, and so I was more careful to separate myself from the stand-up meeting. Second, there was the issue of physical obstacles between me and the team: as with the Summer team, the furniture provided a convenient separation. Third, there was exactly one team member who had Scrum experience, and he showed no hesitation in starting the meeting and reporting progress to the team. Whether he meant to or not, his example provided the perfect template from which the other students intuited the expected social behavior. Fourth, all save one of these students have taken previous courses with me in which we repeatedly applied principles of agile development. We did not use Scrum in  particular, but we discussed the philosophy and the implications as well as learning the practice through a six-week project in two deliverables.

I wish I had more data to support that last point. I would love to be able to claim that the students' experience in CS222 is a contributing factor to their ability to work in teams in upper-level courses, since that's one of the explicit goals of CS222. Unfortunately, the assessment data is not that rich. I mentioned three other contributing factors, and there are undoubtedly more. Still, it's anecdotal evidence that some combination of my teaching and the curriculum are working in tandem to improve student learning experiences.

Thursday, October 6, 2011

UI classes should not implement event listener interfaces

When one does a rudimentary search for Swing tutorials, one finds approximately a zillion examples that recommend writing code like this:
import java.awt.Container;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public class PressMeFrame extends JFrame implements ActionListener {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        PressMeFrame frame = new PressMeFrame();
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMeFrame() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(this);

        Container contentPane = getContentPane();
        contentPane.setLayout(new BoxLayout(contentPane, BoxLayout.Y_AXIS));
        contentPane.add(button);
        contentPane.add(outputField);
    }

    @Override
    public void actionPerformed(ActionEvent arg0) {
        outputField.setText("Thank you.");
    }

}


The problem I want to focus in on is that PressMeFrame implements ActionListener, but in truth, I can't stand looking at a class that extends JFrame when it doesn't have to. Do I really want to bind myself to JFrame right now? Not when I can just as easily make a reusable component that can be stuck into other things. Let me start this again...

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public class PressMePanel extends JPanel implements ActionListener {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(this);

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }

    @Override
    public void actionPerformed(ActionEvent arg0) {
        outputField.setText("Thank you.");
    }

}


That's a little better, and if you followed the first, you can follow the second. Now, to the heart of the matter. While this works, I argue that it is not right. When we say that PressMePanel implements ActionListener, we are making a bold statement: we are saying that every PressMePanel instance is designed to listen for action events. For example, we could make another class that uses PressMePanel, like this:

import javax.swing.BoxLayout;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A panel for text entry.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public class TextEntryPanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setContentPane(new TextEntryPanel());
        frame.pack();
        frame.setVisible(true);
    }

    public TextEntryPanel() {
        setLayout(new BoxLayout(this, BoxLayout.X_AXIS));

        PressMePanel pressMePanel = new PressMePanel();
        JTextField textField = new JTextField(10);
        textField.addActionListener(pressMePanel);

        add(textField);
        add(pressMePanel);
    }

}


That "works," in that when we press enter in the text field—which fires an ActionEvent—the message comes up in the PressMePanel. However, it doesn't really make sense. The interaction logic of PressMePanel is internal. It's simply not designed to be used in this way, but because it implemented ActionListener, this is perfectly legal. Defensive coding practice dictates that we should prevent this kind of abuse if we can. We get much better encapsulation if, instead of having PressMePanel implement ActionListener, it creates its own delegate listeners. One easy way to do this is to create inner classes to handle it:

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public final class PressMePanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(new MyButtonListener());

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }

    /**
     * Listens for action events, posting a message to the {@link #outputField}
     * when this happens.
     * 
     * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
     */
    private final class MyButtonListener implements ActionListener {
        @Override
        public void actionPerformed(ActionEvent arg0) {
            outputField.setText("Thank you.");
        }
    }

}


I've added a private inner class, MyButtonListener, which has one job: listen for action events and update the message in outputField when that happens. This is nicely encapsulated, and by making the class private, I'm not exporting it for potential abuse by other parts of the system. (Notice that I've also made both classes final. In the spirit of defensive programming, if I'm not designing for extension, I should prevent it.) There's another design improvement to be made. By defining the MyButtonListener as a class, I can now make as many instances of it as I want. Yet, my semantic model is that there is really only one, and it's attached to the button. Notice that this is implied by the naming of the class. Let's use anonymous inner classes instead:

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public final class PressMePanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /** The uneditable text field into which we will put our output */
    private JTextField outputField;

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent arg0) {
                outputField.setText("Thank you.");
            }
        });

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }
}


Now, there is no doubt that this specific behavior is tied to the button. Of course, if I had a need to replicate this behavior, I could make a named class or an Action object, but we can cross that bridge when we get there. Better to solve the problem at hand than one that may or may not come up later. Moving to an anonymous inner class provides with another interesting refactoring opportunity. I like to have as few fields in my objects as I can. Now that the text field is only ever accessed or manipulated from the constructor, I can pull it into a local variable rather than an instance variable. The only piece of Java magic required for this is that we have to make the field final so that it can be read from the inner class:

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BoxLayout;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTextField;

/**
 * A frame that holds a button which really wants to be pressed.
 * 
 * @author <a href="http://paulgestwicki.blogspot.com">Paul Gestwicki</a>
 */
public final class PressMePanel extends JPanel {

    /**
     * Start the application.
     * 
     * @param args
     *            command-line arguments (ignored)
     */
    public static void main(String[] args) {
        JFrame frame = new JFrame();
        frame.getContentPane().add(new PressMePanel());
        frame.pack();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
    }

    /**
     * Create an instance of this class.
     */
    public PressMePanel() {
        final JTextField outputField = new JTextField(20);
        outputField.setEditable(false);

        JButton button = new JButton("Press me");
        button.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent arg0) {
                outputField.setText("Thank you.");
            }
        });

        setLayout(new BoxLayout(this, BoxLayout.Y_AXIS));
        add(button);
        add(outputField);
    }
}


Nice and tidy, but more importantly, our PressMePanel is well-encapsulated.

Now, textbook and tutorial authors, you can stop making every class under the sun implement listener interfaces.

You're welcome.

Thursday, September 29, 2011

Students' reactions to the XP Episode

After giving them a brief introduction and experience with pair programming, I had my students read Engineer Notebook: An Extreme Programming Episode and write an essay response. I found a few of their comments particularly insightful, and so I'd like to share them here.

"I felt that most of the things my partner and I were doing was making statements, but the two Bobs thrive on asking questions."

"As students we tend to be focused entirely on what we know and what we can do that we don't sit down and realize that most of the people in our class can do the exact same thing."

"Respect is key to pair programming."

Wednesday, September 28, 2011

The words faculty use to describe their activities

I am on the university strategic planning committee. Over the course of the last several weeks, we have held many information gathering sessions with stakeholder groups, including faculty, students, parents, employers, and staff. Right now, my subcommittee is analyzing the data from two specific questions asked at the information gathering sessions:

  • What did you learn about BSU over the last five years that you did not know before?
  • If you could choose one area of focus that will have the greatest positive impact on the university, what would it be?
A few minutes ago, I finished my first pass through the responses, and this was my first attempt at open coding. Most of the data came from faculty sessions, and I was struck by how often the word "teaching" was used. Practically absent from their responses was any discussion of learning. The words faculty used to describe themselves and their activity matched exactly those words most commonly seen in promotion and tenure guidelines and annual reports: professors are obligated to do some amount "teaching." 

Maybe I am reading too much into this, but it seems to belie a teacher-centric rather than learning-centric philosophy. I am reminded again of the advice of my colleagues, David Concepcion and Mahesh Daas: that the role of a professor is designer of learning experiences, and that to be a good teacher, one must be a humble learner.

The dean of my college, Michael Maggiotto, has been encouraging a transition from "teaching, research, and service" to "learning, scholarship, and engagement," as long as I have been here. At first, I dismissed this as simple alpha equivalence, and as potentially dangerous as it eschews the relationships among Boyer's four scholarships. However, reflecting on this in light of the data I just waded through, Maggiotto's approach may be a step in the right direction. The words we use shape the thoughts we think.

As an aside, I can't help but hope that I'm the first person to reference grounded theory and lambda calculus in the same post.

Monday, September 26, 2011

The Design Thinking Game

This morning in my game programming class, we started a short unit on game design. I brought in some prototyping materials and gave the students ten minutes to whip up a board game in the roll-and-move genre. This was inspired by Ian Schreiber's Game Design Concepts Level 1 activity and its primary purpose is to get students over the invisible barrier, "what if I cannot make a game?"

To explain what "design" is, I had started with a brief presentation of design thinking. Once I got the students started with the activity, I decided to sketch out a game as well. Glancing at the chalkboard, it struck me that the design thinking cycle could be modeled as a board game, so I made this:
The captions on the boxes are:

  • Empathy: an audience
  • Identify: a problem
  • Ideate: a solution
  • Build: a prototype
  • Test: a strategy

Each player starts at Empathy. Each turn, you roll a die and move that many spaces along the cycle. Grab a blank card and write down something that happens in that phase, using the caption to guide you. For example, my first turn, I rolled a three, and ended up on Build, so I made a build card, "Sketch." Then I rolled a two, putting me on Empathy, so I made an empathy card called, "Elderly." As soon as there is at least one card for each category, that player takes one card at random from each category and has to make narrative that explains how these five things fit together. I didn't get far enough in my own design process to decide on an initial scoring or elimination process, but I imagined that the other players would somehow score the story, and there would be a time or point threshold to trigger the end of the game.

That's it. A ten-minute game, most obviously inspired by design thinking, 1000 Blank White Cards, and Dixit. Is it fun? No, not really. You fly around the board and are forced to invent artifacts separated from any context, so you can only be very generic. Is it good? No, not really. It completely misses the point of design thinking, that you have to go through each phase to get to the next. So, why write it up here? It was actually a fun thought experiment. I used this ten-minute design exercise at the AIM conference a week ago, but I did not actually participate, I just observed. It was much more fun to actually get in and do it. I also enabled me then to present my flawed game design first, demonstrating the importance of metacognition, specifically learning from the process rather than judging the artifact too harshly.

Tuesday, September 6, 2011

Guest Post at Play the Past

My guest post at Play the Past is now online. It provides a birds-eye view of the design and development of Morgan's Raid, which I have written about extensively here.

Monday, August 29, 2011

Peer evaluation rubric

I read through a portion of Computer Science Project Work. If found some of the book to be difficult to read because it is written for the UK higher educational system, whose structures I do not fully comprehend. It makes matters worse when the authors throw around terms that I can only assume are equivalent to AP, credit-hours, FTE's, and such in the United States. Ignoring the specifics of the implementations, I did find some good tips that I can adapt to my own practice. In fact, one of their key contributions is a studied observation that transfer expects transformation. That is, the transformation that one applies to found scholarship is an indicator of transfer of practice.

Most of my notes from reading the book fit handily into one of my notebooks, but there is one piece I would like to share and archive here: a sample peer- and self-evaluation form from pages 250-251. It is presented as part of bundle 8.6, "Moderation Using Student Input." The form is in two parts: management characteristics and technical contribution. Both use a seven-point Likert-type scale, but while the first part uses distinct semantic labels for each end-point,
the second simply uses "well above average," "average," and "well below average" for all categories.

These are the categories and scale labels for the management skills portion.

CategoryHigh-endLow-end
time managementhighly organizedunreliable
responsiveness to othersrespects viewsdomineering
coping with stressalways calmpanics easily
cooperationalways cooperatesgoes own way
self-confidenceable to take criticismcan't take criticism
leadershiptakes initiativefollows others
problem analysisincisivewoolly
project managementbest practiceactivity lacks coordination
project evaluationsystematic and objectivecasual and subjective

The categories for the technical contribution portion are
  • Task Analysis
  • Conceptual Design
  • VDM
  • Manager's Meetings
  • Team Meetings
  • Low Level Design
  • Coding
  • Testing
  • Documentation
  • Demonstration
Both forms provide room for open-ended comments as well.

VDM? I have no idea. Unfortunately, while the book acknowledges that portions are written by different authors, it does not identify who wrote this part, nor whether or not is based on existing scholarship. I would like to see an evaluation of this instrument in particular, since it seems to be the only recommendation in the book that is provided in such specificity—despite knowing and withing acknowledging that it should be transformed to be transferred!

On first glance, I was impressed by the custom labels. I love the use of words like "incisive" and "woolly" to describe how a student interacted with a learning experience, and I think it's good for students to think about the capacity to take criticism as an indicator of self-confidence. As I looked closer, I noticed scales like "leadership," which here is measured in terms of taking initiative versus following. I'm not sure I like that dichotomy, but again, that's where I would like to read a formal evaluation of this instrument in particular. The more I read about using this instrument (which was less than one page), the less I liked it, as the author suggested using a fairly straightforward scoring mechanism: average students' self-assessment with their peer assessments, sprinkle with up to 5% secret sauce, and call your work done. Once again I have to admit my ignorance of the grading environment in which this scheme was designed, but I would be unhappy with this in an A/B/C/D/F scheme. Specifically, where would one cut off, say, "A=Excellent" with such an approach?

In any case, there are some interesting categories here for student self- and peer-assessment, and I can see the value in handing out a form like this at the start of a project to get students thinking about how their contributions may be classified. No one wants to be woolly.

Saturday, August 27, 2011

Allergies

Regular readers of my blog may wish to know that, as of this week, I am back on my allergy medicine. Also, I was not spontaneously promoted.

Monday, August 22, 2011

My morning in pictures

Ah, the first day of the Fall semester. My game programming class meets at 8am. Let me tell you about the morning so far.

I came into the Math lounge to put my lunch into the refrigerator. I pulled it out of my backpack and slung my backpack up onto my shoulder. Not having latched my bag shut, my favorite mug fell from it and shattered into a million pieces on the ground.

Favorite mug, before the accident
I picked up the bigger pieces, cutting my finger in the process, then asked the receptionist in the Math department to call custodial to get the rest of the shards.

Returning to my office, I realized I still had my lunch bag in my hand, so then I went back and put it in the 'fridge.

I poured my coffee from my travel mug into the back-up mug in my office, my good-old ACM mug.

Old Faithful
A bit of background on my morning coffee: Last night, I noticed that both of my french presses were in the dishwasher, which was nigh full, and I expected that the dishwasher would be run overnight. Of course, I did not actually run it, and so in the morning, I was left without a clean press. My backup plan was already in place: use my cold-brew coffee concentrate! I mixed it with some boiling water and half-and-half, and that's what I brought to the office with me. The result was that when I tested the coffee, it was not quite as hot as I would have liked.

Problem easily solved. I went into the CS conference room to put my coffee in the microwave...

Conference room microwave, outside

and when I opened the door, I saw this:

Conference room microwave, inside

Well, ick. The red sludge looks like jam to me, like someone tried to microwave a peanut butter and jelly sandwich, realized it was a bad idea, and left the detritus behind. By this point, it was already about 7:55,  and I didn't want to dally—I just wanted hot coffee. I went ahead and put my mug in for 30 seconds, hoping it wouldn't come out tasting of smoked jam. When I opened the door after thirty seconds, a little flying insect came out of the microwave. Can that even happen?

I took the coffee out of the microwave and headed down to my classroom, a cozy little room we call RB104. It's a conventional "smart classroom," meaning there's a projector, dongles for attaching a laptop, and a badly designed teaching kiosk. Some of the students were waiting outside the door, so I proceeded to unlock the door with my key. In fact, I locked the door, which I only discovered after unsuccessfully trying to open it; it had been unlocked from the beginning. Properly unlocking the door and flipping on the lights, here's what I saw when I came in:

The land that custodians forgot
This is 8AM on the first day of classes for the semester, and there's a pile of crap on the desk! Notice that there are two unclaimed notebooks from at least the Summer session, though I think it might be from last Spring, since they looked familiar. Let's take a closer look at that pile on the near side of the table.

"Stuff"
The mess of cables is normal for the room. There's cabling for the mouse, ethernet, and video. They are sitting on top of a discarded notebook, beside the room's nonfunctional remote control. On the left is a chunk of chalk, an uneaten but ratty-looking Ricola, and a small leaf.

The real winner, however, is this thing, from the middle of the table.

What is that thing?
I moved the mouse next to it for scale. I'll say it again: What is that thing? At first I thought it was a wad of candle wax that had been handled by someone with soot-covered fingers. It looks kind of like a big ugly toenail. I really have no idea. I did not touch it.

After cleaning up the desk, I plugged in my laptop to the projector and found that the autofocus was not working. A friendly student adjusted it manually from the middle of the room.

The good news is that everything got better from here. I talked to my students about how I got interested and involved in game development, showed them some of my and past students' work, and talked about the goals for the semester. They seem a good sort, and despite a rocky start, I think it will be a good semester.

Good morning!

Sunday, August 21, 2011

The Escape

When a student reminded me that the next Ludum Dare competition would be this weekend, at first I was excited about using it as a creative way to ring in the new semester. My plan was to learn more of the toolchain involved in making a simple game in Unity in order to leverage that experience in teaching Game Programming this semester. I spent some time this past week tinkering with Blender for the first time, watching tutorials and making some very simple models. As the weekend drew closer and the real stresses of starting the semester began to rear their heads, I realized that my time would probably best be spent in a combination of last-minute planning and spending quality time with the family.


Ludum Dare announced their theme for the 48-hour game development competition Friday evening: "Escape." After sleeping on the theme, I was inspired Saturday morning to make an entry. So, for your gaming pleasure, I present to you The Escape.


You could call it a puzzle game.

I'll write more about the development in a later post.

Monday, August 15, 2011

Continuing Academically Adrift

I was excited to read the final chapter of Academically Adrift, entitled "A Mandate for Reform." Although I enjoyed reading it, the final chapter was neither as revolutionary nor as specific as I hoped. The authors discuss several inhibitors to change, the most daunting of which is the lack of demand for learning, which I wrote about a few days ago. Their suggestions match much of what my own Future of Education Task Force concluded: we need a greater focus on student learning. This support must take the form of both respect and rewards, since as long as teaching is institutionally considered a lesser responsibility to research, then there will be no change.

Let me be clear that I enjoyed reading the book and consider it a significant contribution to the field. Perhaps it was unfair of me to expect that their conclusions would be more immediately actionable, since their stated goal was research, not reform. Consider, for example, the authors' suggestion that effective reform needs to happen from within the current system, allowing actors to innovate within the existing space of higher education. This compares to my Future of Education Task Force recommendation for what we called "The University Sandbox," an initiative that would be authorized to work within the university while ignoring conventional assumptions of higher education. Our recommendation was not codified to the point of being immediately implementable, but I was hoping that Academically Adrift would provide more examples of how institutions might consider approaching the problem of fostering educational innovation.

In the final chapter, the authors to begin to fall into the social science trap of claiming their results are broader than what they actually found. Their study used the Collegiate Learning Assessment (CLA) to look specifically at critical thinking, complex reasoning, and writing, measuring a cohort as they entered college and as they finished their sophomore year. They found that individual studying improved students' scores while group study did not, and the last chapter begins to conflate CLA achievement with learning in general. This matches my experience and intuition: a student's ability to individually write an essay should only be improved by that individual practicing writing essays. However, they neglect to mention that CLA-measured skills are not the only skills that need to be learned. For example, there is a body of research in Computer Science education that has shown that pair programming—undeniable a form of group study—improves learning and retention. The authors clear bias for individualized rigor could have been balanced with a caveat that there are disciplinary idiosyncrasies.

The final chapter's message could be summarized as, "Be deliberate about fostering student learning in higher education." The criticism of cargo-cult active learning was refreshing, given how many papers I have reviewed and presentations I have heard where the researcher has not demonstrated any significant understanding of the fundamental tenets of learning. I also appreciate their argument for more widespread teacher-training within doctoral programs. The crux of their argument is that for the foreseeable future, many more Ph.D.s will be adjunct faculty or in teaching roles than tenure-track at research-intensive schools.

There is one immediately actionable recommendation for faculty that the authors return to time and again: be rigorous. Their own study and several related studies have shown that rigorous coursework improves student academic achievement. This may seem obvious to those outside the ivory tower, but those of us on the inside have seen how easy it is to trade away rigor for easier teaching. This comes back to the delicate equilibrium I wrote about the other day, in which learning is generally not considered worth institutional sacrifice. The good news is that students are hungry for it.

Despite any nitpicking, I do strongly recommend the book, especially to anyone who is just starting to dip their feet into higher education reform. It is probably best read in conjunction with a book more specifically about learning, such as How People Learn, How Learning Works, or, for like-minded technocrats, Pragmatic Thinking and Learning. (NB: I have not yet read the second book mentioned above, but I have heard good things about it.)