Friday, July 6, 2018

Summer Course Revisions 2018: Game Programming

This morning, I pushed up the revised course site for my Fall 2018 CS315 Game Programming class. I would like to record here the major changes I made to the course, as I did with describing the revisions to my game design course. Keep in mind that last summer, I made the major change of converting from PlayN to Unreal Engine 4, and I wrote an extensive reflection on the Fall 2017 offering. I believe the revisions have captured most of the ideas from that reflection.

More Small, Structured Projects

Last year, I gave the students one short, structured project, and then we moved fairly quickly into a larger one. Many students felt left behind, and they responded positively to closing the semester with another short, themed assignment. For this year, I have written up specifications for two "mini-projects," each expected to take about two weeks. The first is the same as the one I used last year—an introduction to UE4 Blueprints and physics simulation using a simple cannon. I will follow that with a second mini-project, which will be creating a minimal shoot-'em-up game in classic, top-down arcade fashion. This will introduce the students to issues of input management, more robust state management, and dealing with enemy pawns. I have a third project in mind but not fully articulated on the course site: it will likely involve creating a simple first-person shooter, modifying one of the starter projects. I want to hold off on the articulation of this until I can see how the first two go.

From there, I am not sure if we'll do a small project related to C++ integrations or move right into the final project; if the latter, I can make C++ integrations a requirement for a certain grade. It's something I want everyone to try, at least, to build some understanding of the layered nature of game architectures.

I plan on having a meeting with the class halfway through the semester where we collaboratively develop the criteria for the final project. I expect we will end up with some loose specifications and a menu of potential features to explore, such as AI or multiplayer.

Specifications Grading

The MacGuffins system I used last Fall was too coarse grained. I adopted it in part because it was relatively forgiving to a massive change in the course, but I knew that as I refined the course I would want higher fidelity. This Fall, for at least the mini-projects, I will be using specifications grading. This is a trendy "new" approach; in fact, I used a variation on it years ago in CS222, before the idea had new branding. The details on the first two mini-projects lay out what features or functionality must be present to earn a D, C, B, or A, with the higher levels assuming the lower ones. I am interested to see if students strive for A—with some failing to reach it—or if they pick the grade they want and simply work at that level. 

I have added a project report requirement to the conventional specifications grading approach. Each individual or team needs to state, in their report, which grade they have earned, with what is essentially a checklist of features. I intend this to serve two purposes: the first is to foster metacognition, and the second is to help students catch their mistakes. 

Perforce Helix

My Spring 2018 Game Studio team learned Perforce Helix, which proved much more fit for purpose than Git for UE4 game development. The good folks at Perforce were kind enough to grant us an academic license that allows me to continue using their software for Fall's game programming course. There will be a bit of manual administration on my part, creating all the requisite users and depots, but I think it will be worth the hassle of having integrated asset locking support. Nothing's worse than divergent binary assets.

Simple Achievements

I was tempted to abandon Achievements for this course, in the name of simplicity. However, more than that, I wanted an incentive for students to share independent findings through in-class presentations. Some of the most memorable meetings from last Fall were the student-led tutorials on Blender and on Godot Engine. I decided on a very simple system whereby students can earn a single achievement that counts for 5% of their final grade. That amount was chosen because it allows a student who earns on A on everything else to earn an A in the course. I've only provided three options: attending a games-related conference; participating in a game jam; and giving an in-class presentation. I don't really expect anyone to chose the first, but if they do, I want to reward the effort. The growth of itch.io makes participating in a game jam much easier than it used to be.

Decorum

I've copied over the decorum section of the Game Design course plan over to this one, with some modifications made around the appropriate use of portable electronics. I have traditionally not had the kinds of problems in Game Programming as I wrote about in my Human-Computer Interaction class, but I figure there's no harm in it.

Diversity

Two years ago, the Faculty Senate (or somebody like them) passed a resolution that requires all course plans to include an official Statement on Diversity, chosen from one of two official options. The primary difference between them is that one includes contact information for the Bias Response Team, and the other does not. This mandate made me uncomfortable at the time, but it has taken some time for me to articulate the root causes.

Here's a good story that I have not told here before. At the end of my HCI course in the Spring, I asked the students to reflect on the most important things they learned during the semester. One of the responses surprised me, in part because it came from a student who had not shared much during the semester; he said that he learned that everyone is biased. That's true, of course, and I asked him how it had come up in the course. He reminded me that I shared my thoughts about this as my reaction to the Statement on Diversity in the very first class. You never know what's going to stick.

The version I chose to include on my course plans is the one that does not encourage students to report to the Bias Response Team:
Ball State University aspires to be a university that attracts and retains a diverse faculty, staff, and student body. We are committed to ensuring that all members of the community are welcome, through valuing the various experiences and worldviews represented at Ball State and among those we serve. We promote a culture of respect and civil discourse as expressed in our Beneficence Pledge and through university resources found at http://cms.bsu.edu/campuslife/multiculturalcenter.
I asked my chair earlier this Summer to help me find the actual mandate regarding this statement in the university or faculty handbook. Turns out it's a resolution, but it has not been recorded anywhere else. This by itself strikes me as problematic: where is one supposed to go to find the rules one is supposed to follow? Wading through all the minutes of all the Faculty Senate meetings for all of the institution's history.

Procedural matters aside, my email conversation with my chair helped me to better articulate what bothered me about this statement. The short answer is that it is a lie, and I have no tolerance for lies. To be clear, the Beneficence Pledge is pretty good, although it has a few problems. Given that I've never heard any student or faculty member reference it, I don't think it's actually part of university culture, not like honor codes are at some institutions. Also, people who recite it honestly and live by its values are the same people who don't need it in the first place; it's like preaching to the choir.

I decided to include not only the Statement on Diversity but also the fact that I am required to include it. I then ask them to consider three questions:

  • Who speaks for Ball State University and its aspirations?
  • What philosophies espouse mandated statements of aspiration?
  • Is it appropriate to value all worldviews?
I might riff on these a bit in the first week of the semester, or I might leave them for students to consider. I thought about adding a fourth one, "Who benefits from this mandate?" For now, I'm sticking with three. Here are short answers for the interested reader:
  • Not the person being mandated to include this on their course plans, that's for sure.
  • Totalitarianism, at least.
  • Clearly not.
These answers beg another question, "Does the Statement on Diversity do anything to advance diversity?" It might be like the Beneficence Pledge if it simply maintained neutrality, except that in being mandated, it speaks volumes. Maybe it's a good time to bring back my tradition of making my students recite the Bene Gesserit Litany Against Fear.

I may copy these reflection questions over to the Game Design course plan to see if the Honors Students react any differently to it, but I haven't decided yet.

Wrapping up

I'm eager to teach the Game Programming course again with this incremental yet significant revision on last year's plans. I think I can get my students involved in a colleague's research project on specifications grading with very little extra effort. Even though there are some unknowns yet for this course, such as the number of mini-projects and exact nature of the final project, I feel good about having the revisions in place. I think I am in a good position to move on to my third summer course revision, although that's going to require a bit of networking over the next two weeks. Tune in later to see how it all turns out.

As always, thanks for reading, and feel free to share your thoughts in the comments.

1 comment:

  1. Hey Great job did by you. You Know what? I read a lot of blog post and I never see content like this. I Love This Information You made about




    Assignment Writing Help

    ReplyDelete