This is the first of my traditional reflection blog posts, in which I share some of the successes, failures, and mysteries of teaching. The good news is that all three my courses went surprisingly well, given the unprecedented constraints that we were under.
As I shared in my planning post, the game programming class switched to Godot Engine this semester. This ended up working quite well. While I enjoy working with Unreal Engine 4, it is fiddly in ways that trip up novices, and I need to seriously consider whether Godot Engine is a good permanent replacement for UE4 in CS315.
The students had the usual confusion around intellectual property licensing, and it's not clear to me how much I need to get out in front of it vs. respond to their misconceptions. I fear that time I spent trying to explain this up-front would be wasted, as so many students would still get it wrong that I would repeat it all anyway.
The checklist approach to grading projects continues to work well, and I think that this clarity of expectations was especially useful in the absence of shared lab time. I have gotten better at documenting these, which also helps. One question that remains in the back of my mind is the distinction that Nilson makes between more hurdles and higher hurdles. She suggests one or the other, while I continue to do both. I wonder if there is an alternative model for game programming projects that would take the "more hurdles" approach, although it also seems to me that then you're just doing regular points-based grading where only a subset of points is required.
In the manifestation this semester, I played some more with the idea of "stars" at the A-level, so that students could see some of the variety of actions that could be rewarded. Unfortunately, most students clearly settled on the ones that required the least effort, which makes the endeavor seem like a presentation of false choices. Next time around, I could spend some time reconsidering this, although I do not think it's that bad to leave it as it is. A few students were able to be rewarded for doing some unconventional things, and that is the main point after all.
The heartbreaking moment this semester came when in grading the final iteration of the final project. This spanned the two weeks after Thanksgiving break, when the university shifted entirely to asynchronous online instruction. In my mind, this should have been the great push, where students bring together everything they learned and make some really interesting projects. What actually happened is that almost everyone made zero progress for most of those two weeks. Almost all the activity on the projects took place in the 72 hours before the deadline. Some students basically lied about their efforts, though the git logs gave away their true patterns, while others humbly acknowledged not having done adequate work: both groups earned the same grades, but I am proud of the latter while bitter about the former.
I sympathize with the students' bad situation. I have some confidential messages that provide more evidence for my suspicion that a lot of faculty did not handle this semester well. Some students will always complain about end-of-semester workload, but when essentially all of them do, one has to wonder if there is a systemic problem. My defense to my students was that we had the same pattern of expected behavior all semester, and indeed, some students have thanked me for that; however, this doesn't change the other stressors in their lives, or the potential of uneven distribution of labor expected from other faculty who appear not to consider the consequences.
Despite the expectation that my students maintain steady progress for each two-week iteration, I did not create any incentives for this behavior. It makes me wonder if, next time, I should incorporate something like labor logs, where students are graded based on self-reported time-on-task. I tried this approach in my game design class, which I will write about later in this series. This would give them positive feedback in the form of grades for those weeks where there is no deliverable. Another alternative would be to have weekly check-ins or status reports rather than biweekly deliverables. I will need to consider the costs and benefits of these approaches next time I teach the course, which I hope to be in Fall 2021.
Another puzzling factor in this class, and in both my other classes, was that many students stopped turning in material and yet did not withdraw. My intuition is that there were more of these students this semester than in the past. That is, there are always some, but I believe I had a higher proportion of them this semester. I wonder if this is because of the online asynchronous nature, if students deluded themselves into believing they could catch up, when all the evidence was that they did not have the conscientiousness to keep up. I will be interested to talk to my colleagues about this, including those outside my department and my university.
In summary then, it was overall a great experience in teaching game programming, and some of my students made some really great little games, for what they are. My favorite is the one that used the sprites from Tyrian, which ratcheted up the nostalgia for me. The experience was slightly soured by disappointments in the final iteration of the final project, but at least I have some ideas of how to mitigate this next time.
Note that the students are completing the final exams this week, so the course is not yet completely over. I will post an update if there's anything in the final exam responses that make me rethink anything I have shared here. Thanks for reading!
No comments:
Post a Comment