Tuesday, December 10, 2019

Reflecting on the Fall 2019 CS315 Game Programming course

My students are currently taking their final exam, so this seems like a good time to start my end-of-semester blog post about CS315 Game Programming. This was my third Fall semester teaching this upper-level elective course using Unreal Engine 4. The semester ended up consisting of four "mini-projects", each about two weeks, and one six-week final project, which was completed in two iterations. By and large, I am happy with how the semester went: students learned how to work with some contemporary tools, including Perforce Helix for centralized version control, and they made interesting final projects. What I want to document here are some of the struggles, because it will do me more good when planning next year's class than focusing on the successes.

It turns out that almost all of my frustrations from the semester stem from my decision to use Specifications Grading again. For people who are not familiar, you can easily hop over to the course plan's projects page to see what they are. Briefly, I laid out all the criteria for which student work would be evaluated ahead of time, and like last year, I asked students to submit self-evaluations in which they graded their own work.

This leads quickly into the first problem: students did not seem to understand how to use checklists. It feels so strange to even type that, but it's true. As part of their submission, the students had to complete a checklist, and then based on what was satisfied, they could know—and had to say—what their grade would be. However, more often than not, I would read through the student's submission and have to point out that they didn't actually satisfy some criteria. I designed a little leniency for students who legitimately did not understand a criterion or two, but what I didn't expect was that several students made the same mistakes again and again and again. I forced the students to rotate partners during the Mini-Projects, thinking that this would ensure that mistakes would be caught by the partner; instead, what I saw was that the misunderstanding (not the understanding!) spread to new partners.

I suspect that a major reason for the checklist problem is that students are so deeply brainwashed into the "turn this in and hope for points" model that they cannot conceive of an alternative. Certainly, in my years of teaching, I've had plenty of push-back on unconventional things I do. (I continue to do unconventional things, partially because I want students to learn to question conventions.) I can work on clarifying the language around the specifications themselves of course, but I feel like this is treating a symptom rather than a cause.

There is one place where my instantiation of specifications grading contrasts, as I recall, against the presentation in Nilson's well-known work. She describes making a choice between more hurdles and higher hurdles, but my version of specifications grading is both more hurdles and higher hurdles: students have to do more and better work to earn higher grades. This is sensible to me, but I wanted to mention it here because it is a lever that I could pull in an experimental assignment or section.

Another problem I encountered with the specifications grading this semester was that a minority of students were able to follow the specifications I provided to earn relatively high marks but, in my professional opinion, without really meeting the learning objectives. For example, I had a B-level criterion which was, basically, that the project should have all the parts of a conventional video game: a title screen, gameplay, an ending, and the ability to play again. An alarming number of teams did not handle mouse input controls properly, so that once you click in the game, the mouse is captured and the cursor made invisible. This means that technically you can still navigate a UI menu, but without being able to see the cursor, it's awfully difficult. Their conventional solution seemed to be to use Ctrl-F1 to release the cursor so they could see it again: an editor kludge for a runtime problem. Did such teams satisfy the criterion? Well, yes, but also no. I liberally allowed it, leaving notes in my review that they should fix this, which almost nobody did. I could, of course, add text to the already-wordy criterion to say "If you are developing for a Desktop application, and you are using mouse navigation, make sure etc." That's just one special case of a particular environment, though. What I think I'm really running in to is the problem if specifications grading in the face of creative, wide-open projects.

Several students took my examples wholesale, brought them into their projects, and then submitted them as satisfying the relevant criteria. For example, I showed C++ code to count how many shots a character fired; student teams put this into their game and then checked the box saying that they included C++ code. Technically yes, but without any semblance of understanding. Another student took my dynamic material instance example wholesale and put it into his final project. Again, no indication of understanding the pieces, just copying and pasting it into his project and claiming that he included dynamic material instances. Yes, they're in there; no, there's no evidence of understanding. Some of this could, in theory, be cleaned up by changing the specifications, but then it gets into the same kind of problem as measuring productivity in programming. Exactly how different from my example does a student's work have to be to demonstrate that they understand the comments? "Exactly" is the key word here if the specifications are going to be objective.

I'm left with this sinking feeling that specifications grading are not worth the effort and that I should return to my tried and true minority opinion on grading: use triage grading for everything. This allows me freedom to say something like this: "Use dynamic material instances in your project in a way that shows you understand them." Then, I can fall back on saying that a student's work either clearly shows this (3/3 points), clearly doesn't (1/3 points), or is somewhere in between (2/3) points. This clear and coarse-grained numeric feedback can be combined with precise and crystal-clear written feedback to show students where they need more work, which appeals to me much more than my grimacing at the student's submitted checklist, then at the student's code, and then saying, "Yeah, I guess."

Sunday, December 1, 2019

Typesetting music with mup after a 20-year hiatus

Back around 1999-2002, I was composing and performing music pretty regularly as a stress-relief from graduate studies. This got me looking into creating printer-friendly versions of a few of my songs. I came across mup—a tool that takes plain text sheet music descriptions and creates snazzy postscript output. Mup supported Linux, where I was doing all of my serious work, and it allowed for a LaTeX-style separation of document content from document format. It was not free software, but I was happy to pay for a license to this excellent tool.

Fast-forward to today, when I was struck by the desire to typeset "Istanbul (Not Constantinople)" for my kids. I introduced them to this song via the classic video some time in November, and of course they loved it. I picked out the chords on the piano, and it's become a fun song for me to sit at the piano and sing with them. Three of my boys are taking piano lessons, and so I thought it might be fun for them to see it written out. It's much more syncopated than what they are playing in their lessons, but I thought the oldest in particular might enjoy the rhythmic challenge.

I did a little Googling and found what appeared to be viable options, but I stopped when I saw that mup is still around. Not only that: the authors made it free software back in 2012! Right on, gentlemen!

It was fun to re-learn mup's syntax after twenty years or so. Here's a quick example from the bridge:

1: 4c#;;;8;8~;
rom chord above 1: 1 "A";
lyrics 1: "Why they changed it, I_";
bar

1: 8c;8~;8;8~;2;
lyrics 1: "can't say.";
bar

The lines starting with "1:" are specifying the notes to go on the first staff—in my case, the first and only one. The "4c#;" means quarter note C#, and each empty semicolon after means to repeat that note. The "8" switches to an eighth note without changing the pitch, and the tilde is a tie to the next measure. The "rom chord above" is placing a chord above the staff at that location. The real killer feature, in my opinion, is the typesetting of the lyrics: the lyrics are automatically bound to the rhythm of the line.

The resulting typeset music looks like this:
I've put my whole arrangement up as a gist on GitHub in case you want to see all the source, and I've put the resulting PDF online as well.

Thanks to John and Bill at Arkkra Enterprises for this amazing piece of software. On the project's main page, they introduce themselves as "musicians and computer programmers," and mup is a great example of how computational thinking can lead to productive tools. It's a shade of the same point I made in my reflection about my November game design project, and it echoes my recent frustrations at work with having to use Box, Microsoft Word, and emailing files around for collaboration when LaTeX and GitHub would have been the perfect tools. In any case, if you're a programmer and a musician, make sure you at least take a look at mup.

Wednesday, November 27, 2019

My sons' reflective essays for NaGaDeMon 2019

Yesterday, I wrote about my experience participating in this year's National Game Design Month (NaGaDeMon), but I was not the only one in my household to participate. My 12-year-old and 9-year-old sons each created their own projects as well. Following the Create-Play-Talk structure of NaGaDeMon, I am pleased to share their reflective essays as guest posts here on my blog.

Both of their games can be played online: #1 and #2.

Here is the reflective essay from #1 Son:
For NaGaDeMon, I made a dungeon exploration game with Construct 2. I used Construct because it is the platform I am most familiar with. Construct is a drag-and-drop system, and events are Construct’s way of structuring actions. 
I am glad that I was able to add an avatar creation system where you click on arrows to cycle through different colors of clothes and hair. To do that I had to learn how to use the modulus operator to cycle through a list. Modulus is when you divide a number and take the remainder, so one divided by five has a remainder of one. The cool part about this is that when you divide six by five, the remainder is still one! You can use that to go through a list using only one click. The way I did it before was using a double-click for when you reached the last item in the list so that it wouldn’t loop around and skip a color. 
I am quite happy with the outcome, although the free version of Construct that I am using has a 100-event limit. Originally, I had the player unlock a new weapon with each level, which worked well. The biggest problem I had was getting all of the enemies and bosses in, because the free version has no way to group all of the enemies into one class, so I had to make a different event for each weapon and enemy. Since that took me way over 100 events, I had to take that feature out and replace it with one weapon that got more powerful with each dungeon. I still wasn’t able to add everything that I wanted, but I was able to get all the different enemies in.
Here is the reflective essay from #2 Son:
I have always liked programming. My first programming system was Kodu. I made this in Construct 2 because in Construct 2 I can draw my own sprites. 
I was inspired by my brother’s game about a wizard exploring dungeons. To make it I had to learn how to make more than one layout. I feel like I spent more time than necessary drawing, but with all the left over time I think it was worth it. 
I think I am happy with how it went. I accomplished what I wanted, but what I wanted could have been put in a better game
It was fun to have these guys participate in the fun of NaGaDeMon. I gave them a little coaching in how to write a reflective essay, showing them one of my favorite forms that I use with my college students: What went well? What did you learn? What would you do differently? What still puzzles you? I offered to let them read my reflection as well, which #2 Son did after writing a rough draft of his own. I sat individually with each of them to give them feedback on their handwritten drafts, and  we reviewed them again after they typed them up. Changes were made both times, and I think the results are quite strong. With #1 Son, I encouraged him to expand why the modulus was important to him and how the 100-event technical limitation affected his process. With #2 Son, I encouraged him to expand on why he chose Construct and how to articulate a bit better what "I think I am happy with it" means.

Thanks for reading! I'll be happy to relay any comments you have to the boys, whether they are about the games or the reflections.

Tuesday, November 26, 2019

KAPOW! NaGaDeMon 2019 Project Reflection

As I mentioned in my previous post, my 2019 National Game Design Month (NaGaDeMon) project is KAPOW! The Campy Superhero Role-Playing Game. Earlier today, I published the rules and all the sources on GitHub. The game is free to download, play, and modify, with all the resources provided under the CC BY-NC-SA 4.0 International license. NaGaDeMon has simple rules: Create, Play, and Talk. I created the game was able to play two full sessions, and this post is crafted to satisfy the third rule.

Inspiration

In my formative years, I used to play a lot of Dungeons and Dragons as well as some Shadowrun. I also crafted and playtested some of my own systems, the notes and sites for which have long since disappeared. For the curious, the two that I actually got as far as testing included a time-traveling system in which you roll boatloads of dice and, on the opposite end of the spectrum, a completely diceless fantasy system. These days, I read many more rulebooks than I have a chance to play. The Clay That Woke and Apocalypse World are two amazing systems that I supported on Kickstarter and for which I have read the rules, but which I have never actually played.

One of my scholarly activities in Spring 2019 that I have not mentioned before is that I had two students in a CS499 Independent Study experience. We each were working on our own game design projects, mine being Race to the Moon. One of the students was Austin Tinkel—whom I will mention by name here because I want to link to his work—who developed a pulp action tabletop RPG called That Belongs in a Museum! He gave an excellent presentation about this at the 2019 Symposium on Games, where he talked about how it transitioned from an abstract idea about action momentum into an Indiana Jones-style adventure with PbtA mechanisms. (That is, it drew upon design ideas established in Apocalypse World.)

Working with Austin inspired me to re-read Apocalypse World and reinvigorated my interest in narrative-first tabletop role-playing. I don't know what made me connect this to 1960s Batman, but my family and I have been slowly working through the series since I got myself the box set for Christmas in 2017. We're on the final season, and in fact, we just watched the famous "Bat Shark Repellent" episode, which I have to say—as a fan of campy superhero stories—is one of the worst pieces of television I have ever seen. In any case, the idea tickled my fancy to try to combine campy superhero stories with a PbtA ruleset. This seemed like a good hook for trying to get my head into the PbtA space.

I sketched no more than a page of ideas in the intervening months until around September or October, when I started thinking about whether I should participate in NaGaDeMon again. I had some professional and personal obligations looming (including the aforementioned Symposium), so I decided ahead of time not to pursue a programming project: the odds of getting caught in a debugging death spiral was too high. My mind drifted back to the idea of marrying 1960s Batman sensibilities with ideas and systems from Apocalypse World. This seemed like the kind of thing that would fit into the time I could afford, and I'm glad I made this choice.

The Tech Stack

I started by writing my notes on paper, and then I transcribed them roughly into Markdown. However, I knew that I didn't want to compose the whole thing in Markdown because of its lack of expressiveness for structure. Consider the concrete case of defining the basic moves. At the time I was writing, I wasn't exactly sure what all the basic moves would be, but I knew that I didn't want to have to redundantly define them in a rulebook and in a handout. This would be a DRY violation—anathema to my personal idiom.

Choosing the best method to compose my rules required me to make a decision about how to disseminate the final product. On one hand, I considered a Web-first writing approach using lit-html. I have significant experience with lit-html since I have used it for my course sites such as this semester's CS315 class as well as some side projects such as my Call to Adventure scorecard. I knew that I could do some tricks with JSON-formatted data and html templates in order to separate, for example, the basic moves' definitions from their representation in the rulebook or in handouts. On the other hand, I considered using LaTeX for a print-first writing approach. This would let me easily generate PDFs and niceties like a table of contents and an index. However, I have never done anything like a "model-view separation" in order to keep my writing DRY in LaTeX; it has simply never come up.

I decided to go Web-first, which seemed like a very well-considered and contemporary choice. I wrote this way for really only a few hours before I ran into a significant problem: how exactly was I going to produce the kinds of handouts that players would want to have at the table? Playbooks are a standard technique in PbtA games, and lists of basic moves and narrator moves seemed like a good idea. I started tinkering with using different CSS styles for screen and print media, and very quickly realized that this was basically an instance of the "debugging deathtrap" that I had wanted to avoid by making a tabletop game.

I turned instead to LaTeX and immediately started to consider how I could separate my basic moves' definition from their explanation in the rulebook and their summary on a handout. It dawned on me that I could do something akin to concrete data structure like JSON by having different documents interpret environments in different ways. The narrator moves provide a good example. The project has a file narratormoves.tex which contains several narratormove definitions, like this:

\begin{narratormove}{Separate them}
{
  Use this move to separate the members of the team or to separate
  the team from their objective.
}
\end{narratormove}

Notice that the custom narratormove environment has two arguments, the first of which is the move's name and the second of which is the explanation. Then, in the rulebook, I can define the narratormove environment before importing the source file like this, which will print each move as an unnumbered subsection with its explanation:

\newenvironment{narratormove}[2]
{\subsection*{#1} #2}
{}
\input{narratormoves}

Meanwhile, in the Narrator handout, I can define it in such a way that it produces only the moves' names in an itemized list:

\newenvironment{narratormove}[2]
{\item #1}
{}
\begin{itemize}\itemsep0px
  \input{narratormoves}
\end{itemize}

Not too shabby! I'm happy with this approach, which is used throughout the project. It reminds me that, somewhere in my courses, I should be showing my students this kind of thing to break them from their trained dependence on Microsoft Word—to show them how thinking like a Computer Scientist lets you solve complex problems in more interesting ways.

The Unexpected

There were a few unexpected twists in the design of this game. I wrote about several of them in my playtesting notes post, and the most important of these was really that I was coming in green to the PbtA scene. I had read Apocalypse World several times and recently also read Dungeon World, but the only exposure I had to playing a PbtA game was Austin's That Belongs in a Museum—and that was pretty early in testing. I have been playing ICRPG again with my boys using a traditional fantasy setting, but the kinds of DungeonMastering advice that I listen to on YouTube is very much aligned with D&D-style systems, not PbtA. That said, I do feel like this project met my design goal of helping me put my head into the PbtA space a little better. Each time I tried to either talk through a scenario myself or run a session with playtesters, I got a little better at thinking within the balance of hero moves and Narrator moves.

The 1960s Batman stories, and my dad's 1960s CCA-approved superhero comics that I grew up reading, are almost always mysteries: the hero needs to figure out the who, what, why, and where of the problem before the Villain gets away with it. This stands in stark contrast to the character-driven harsh open world of Apocalypse World or high-school melodrama of Monsterhearts. Dungeon World is somewhere in between, in that it tries to take the traditional D&D approach and wrap it up in PbtA clothing. KAPOW ends up looking more like Dungeon World than Monsterhearts, where parts of the system really sing while other parts are strung loosely together.

The principles section of the rulebook was one of the last things that I wrote, and it represents my current thoughts about how to reconcile these different pieces. I challenged myself to think about the Narrator's ground rules: what would help them creatively tie together the Villain's scheme with the player's agency? I think I did a fair job of articulating these, but I think it's the sort of thing that can only really be tested by another gamesmaster trying to run the game from what I have articulated. Unfortunately, that was out of scope for this November, but I'm eager to hear from anyone who tries. After all, with a CC BY-NC-SA license and GitHub's collaboration tools, there's always an opportunity for improvement.

Conclusions

This was a great creative exercise. It allowed me to explore an idea that has been on my mind in a rigorous, timeboxed way, with the additional help of a supportive community. I think the resulting game rules provide a fun setting, and I legitimately enjoyed all of my playtesting sessions. If other people can also get some joy out of it, then that's all the better for it. In the meantime, I feel like I was able to strengthen my writing muscles while learning some new perspectives on design. 

Given unbounded resources, I know of a few places where I would shore up the current design. Obviously, the rulebook and the handouts would be greatly enhanced with some genre-appropriate art and graphic design. A brilliant idea from Apocalypse World is providing sample answers to open-ended questions in the playbooks. For KAPOW, I would like to give players a list of choices for hero name, real name, appearance, occupation, and contacts, but this was both too onerous to implement and would have broken the one-page design of the character creation sheets, such as it is. Having such options would greatly speed up play, especially in my testing sessions: I was able to confirm that many players enjoyed the open-ended questions and creativity of making characters, but this was also fundamentally individual-creativity time rather than collective storytelling time. Finally, I think it would be helpful to new Narrators to have an appendix of sample villains and schemes. Many of the examples that are provided in the game come from the simple designs I put together for playtesting, but an easier on-ramp could be provided for new players by giving them something more clearly canned.

Thanks for reading! Feel free to post here if you have any questions, and feel free to share the link to KAPOW to any of your tabletop roleplaying or campy superhero friends.

Saturday, November 16, 2019

Playtesting notes for my NaGaDeMon 2019 project: KAPOW!

Last year was the first time I participated in National Game Design Month (NaGaDeMon). I used the month to chase down a game design idea that had been tickling my curiosity for a long time, and the result was Heroic Uncertainty. This year, I decided to participate again but with a very different mode of game design this time around. Since last year, I have been intrigued by the "Powered by the Apocalypse" movement in tabletop role-playing game design. I have also wondered whether this kind of narrative-forward game design would work well with something else my boys and I have been enjoying: the 1960s Batman television show. Hence, I'm glad to announce here—publicly for the first time—that my 2019 NaGaDeMon project is KAPOW: The Campy Superhero RPG.  The project is on GitHub, but I have not made it public yet because I have not yet written the introductory fluff to establish exactly what the game is about: I don't want someone to trip across it and misunderstand the design space.

Yesterday, I was able to gather five volunteers for my first full playtesting session. My primary objective for the session was to test whether the systems were adequately supporting the "caper" tropes that come up in every Batman episode: a Villain sets up an unnecessarily complicated plot for fame or fortune, and the heroes need to unravel it to lead up to an epic showdown. Everyone had a great time, and I was overall pleased with how the story and systems worked together.

I know that for you, dear readers, the rest of this post will appear like I have my cart in front of my horse, because what I wanted to write up this morning are some of my concrete playtesting notes. I want to capture my main observations and provide a little bit of context while they are fresh in my head. It will also give me something concrete to reference when I write up my summary post at the end of November.

Without further ado, then, here are some notes and action items for myself.

  • Each hero has a contact, but the articulation of how they know each other is not clear. Also, I did not include in the playbooks that the contacts had to be introduced, but during the introduction phase, the Narrator really needs those names. Perhaps one way to deal with this is for each playbook to also have a "secrets" sheet that is filled out and shared only with the Narrator.
  • Having stock options for real names, occupations, and contact options would speed up character creation, especially for those who are new to or uncomfortable with tabletop RPGs. This may take a significant amount of my time to assemble, but could be worth it, especially for one-offs.
  • A player pointed out that secret identity names should be alliterative. Yes, they should, unless they are both first names. This should go into the rules.
  • The Enigma playbook could instruct them not to share their real name at all to make them a mystery to the players, or it could acknowledge that the camera knows their real name, and so the players do also, even though their characters do not.
  • I definitely do need some kind of "undercover" rules for exposing secret identities, since this was one of the first disagreements the players had. This would keep with the Batman-style genre. An alternative is to let the players choose this in the Team intro: do they have secret identities (Batman) or are they simply known as who they are (Johnny Quest)? I need to be careful here that the number of rules does not snowball out of control, since this is a one-month design project!
  • At the last minute, I changed Nimble to Focused, and this change worked well. However, the earlier change from Charming to Amazing didn't go so well. The players wondered why Amazing was used for influencing people and why it was not used for a heroic feat. "Amazing" is too metaphorical; I should return to something like "Charming" that implies social savvy. Hm, "Savvy" is a nice word.
  • The Second Wind ability on the Tough may be redundant since he already has so much Endurance.
  • At the end of the session, they pointed out that the Investigate move, although described as being for "situations or locations", is really more for locations. We discussed having a selection such as "What is out of the ordinary here?" or "What is an important clue?" They really wanted an option like "Where should we go next?" but the problem I had with this—which they understood when I explained—is that this could too easily remove the mystery of the villain's caper. I need to consider the balance here; there may be a role for Contacts.
  • Most players did not use their Contacts, but one player used the Contact almost too much, to the point where the Contact was basically a member of the team. I should consider making the Contact option only usable once per session, or risk losing them as a contact.
  • I forgot for half the game to tell them to mark Experience when failing a roll, so I probably need some kind of visible reminder on the character sheet about this. 
  • Similar to the above, I should add reminders on the character sheet about which attribute goes with which basic action, like Apocalypse World does, so that they don't have to scan the whole Basic Moves sheet so often.
  • Also, I forgot to tell them about the new "use the scenery" and "onomatopoeia" options for brawling, which need to be on the basic moves overview sheet and not just in the rulebook. However, brawling was also one of the least interesting parts of the game, although this could have been because of the lack of those rules. (Also, we went over time, so the big battle at the end turned slightly perfunctory.)
  • One of the impediments to the story was my own discomfort with PbtA-style gamesmastering. I had never done this before, so I was learning along with them. I struggled with the idea of what Apocalypse World calls "announcing off-screen badness." In fact, I think one of the reasons Apocalypse World caught my attention is that this concept is something I didn't understand when I DMed regularly (decades ago) and still struggle with occasionally in my handful of gamesmastering opportunities per year. One of my players was very familiar with PbtA, and he encouraged thinking of it like a movie, quickly describing a scene for the players that their characters know nothing about, but that moves the action forward, such as "A car door slams and the car speeds away from the hotel." I do not know if I need to more prescriptive in the rules about this, practice it myself, or both.
And now, hopefully, a quiet Saturday with lots of work on the rulebook.

Monday, November 11, 2019

Department Vision and the Reflecting, Brainstorming and Imagining Worksheet

My department recently concluded a self-study that included a visit from two external evaluators. We are now beginning discussions about what to do in light of our self-study and the evaluators' recommendations. This comes at a time of organizational change within the university, since we have relatively new administration, a new strategic plan, and a new financial model.

In preparation for an upcoming departmental meeting, the department chair emailed the faculty a "Reflecting, Brainstorming, Imagining Worksheet" that was provided by the office in charge of institutional assessment. I took some time to write up answers to the five questions on the worksheet, and I am sharing them below. I am not sure that these are my best answers, but I've used up the timebox that I gave this exercise. I'm happy to take any feedback or questions about the responses, as I expect to refine them later.

1. What is the purpose of Computer Science to you? To you, what does Computer Science endeavor to accomplish?

Computer Science is the study of the social and technical processes around computing systems, including their inception, development, and maintenance. It is a "science" in the sense of developing falsifiable theories that are supported by principles and rigor. It is distinct from information technology and information systems, which applies extant systems to problem domains, and computer engineering, which seeks to more efficiently or effectively manufacture hardware. "Software engineering" is a common application of Computer Science.

Computer Science drives us to a better understanding of computing systems which, in turn, leads to the development of improvements in those systems.

2. What is the purpose of BSU Computer Science? What is at the core of our work?

The purpose of the department is, primarily, to educate the next generation of practicing computer scientists. This implies a focus on contemporary methods of software development, as incorporated into the broader goals of a liberal education.

At the core of our work is a shared desire for our students to live a good life: to be successful, to be productive, to contribute to their communities, and to reflect on what is good and beautiful.

3. What are three strengths of the BSU Department of Computer Science? 

  • Small class sizes allows students to work closely with faculty.
  • Students have significant opportunities for high-impact educational experiences, including the capstone, immersive learning, community-engaged projects, and research.
  • Faculty are engaged with research that informs and strengthens the courses they teach.

4. What are three weaknesses of the BSU Department of Computer Science?

  • Little shared vision about program outcomes and, hence, course and curriculum design.
  • Little sense of community among the faculty, students, and alumni.
  • No clear communication channels to reach students or alumni.

5. When students (undergraduate and graduate) graduate from our department, what do we want them to know? What do we want students to be able to do? What do we want students to value?

We want them to know:

  • Fundamental concepts of programming, including: sequencing, selection, and iteration; data structures such as lists and hash tables, with an intuition for their implications on performance; integration of systems such as clients, networks, and databases
  • How to work effectively on a team, including: articulating measurable goals; giving status reports; and suggesting improvements.
We want them to be able to:

  • Think critically
  • Act respectfully
  • Ask clear questions
  • Engage in reflective practice
  • Learn to use new programming languages, computing systems, or APIs
  • Work on a team to design, develop, improve, or maintain computing systems.
We want them to value:

  • The responsibility they have to their team, their employer, and their community
  • The dignity of the individual
  • Lifetime learning

Wednesday, October 30, 2019

Lenses in game design and curriculum design

Yesterday, my game design students completed an assignment that had three optional paths. One path involved reading Richard Bartle's excellent summary of the Hero's Journey (1, 2), which includes not just an overview of the concept but also helpful pointers about what students often get wrong. During the class meeting yesterday, a student gave a masterful presentation showing how the The Last of Us maps to the Hero's Journey. Before his presentation, I gave a short lecture about what I've learned about lenses. My point here was to get out in front of issues around the masculine and feminine roles of the Hero's Journey, and I think students got my point.

One of the examples I like to give in this kind of discussion is the ludology vs. narratology wars in game design, which were dying down right around the time I joined the games scholarship community. As I understand it, scholars like Henry Jenkins applied a literary analysis lens to games and, from there, concluded that games are stories. My criticism is that if you hold up any lens, the thing you look at looks like the lens. Using the lens of literary analysis to look at games will always make them look like stories, in the same way that using a Marxist lens to analyze games makes them look like class struggle, or a systems analysis lens makes them look like systems. I made a little joke here and pointed out that we need lenses—if I take mine off, the students turn blurry—but we have to recognize their strengths and weaknesses.

Knowing that my class is mostly Computer Science students, I pointed out that Computer Science curricula still suffer from the fact that many of the discipline's founders were mathematicians. They looked at this new idea through the lens of mathematics and determined that, of course, Computer Science is basically mathematics, and that mathematics is the way to understand this thing that we called "Computer Science." Why, I asked, do we require calculus—which we almost never use in practice—and not philosophy or psychology, which we use multiple times a day?

In truth, I meant it as more of a good-natured jab, but that observation has been haunting me the last 24 hours. The lens of mathematics has undoubtedly done good things for the discipline, as lenses can often do, but it also makes the subject look like the lens. My own department is in the "natural sciences" division of the College of Sciences and Humanities, and that forces the administration to look at us from a particular lens as well.

The old joke goes like this: Ask five Computer Scientists to define "Computer Science" and you get seven different answers. I see the rise of interest in both computer science and in programming for K-12 education, but there's also infighting between the two camps. I heard at a conference the other day, "Logic is the science of Computer Science!" Meanwhile, adults who go to coding bootcamps are taking the jobs that my graduates would otherwise go for: why hire someone green and immature when you can get someone hungry for a challenge and capable of "adulting"? Why, when I try to push the old lenses out of the way, do my colleagues desperately reach out and pull it back like a comfortable blanket on a cold day?