I had a break from teaching CS315 Game Programming last Fall while I was on sabbatical, and now I'm gearing up to get back into it. It's a fun course that has always had the same mission but has taken many different forms. I'm feeling pretty good now about my plans for Fall, and so I want to document some of the key points here. The draft course plan is already online. As with my CS222 course, there are still some areas where I want to rework the prose, and I have only posted activities for the first few weeks, but I feel like the structure is where I want it to be.
Grading
Three years ago was the last time I used checklist grading in CS315 in its original form. Two years ago, I switched to a different model inspired by a book I had read. I wrote about how it had some good qualities, but it caused friction with Canvas, and it also had me doing a lot of regrading. Thinking about my plans to kick Canvas to the curb, I figured I might get rid of the interface problems. Yet, the more I worked on my plans, the more I kept drifting back to checklist-based grading. I drafted the first four weeks of exercises this way while I tried to identify why I still felt unsettled.
At some point, it struck me that a completely different way to handle functional requirements articulation is through user stories. This is the way I do it in the prerequisite course (CS222), and it's also how I coach teams to do it in the CS315 final project. Why not deploy user stories in the weekly exercises as well, thereby also giving example of something I want students to do later? It seemed sensible, and so the only missing piece was to map this to grades. I decided to go with the same simple model I started using recently in some CS222 sections, where the grade is based on the number of completed stories.
I am happy with the articulations I have put up for Exercise 0 and the three increments of Exercise 1. The only piece that gives me some pause is that the grading scheme does make it seem like missing a story is punitive rather than that meeting stories is rewarded, but I think this is part of the systemic problems I have inherited. At least I don't think I'm reinforcing them, and I can explain to students that they still have the option to skip lower priority stories and earn a lower grade if their situation makes that prudent.
As part of my Canvas-kickery, I'll be using GitHub issues to give student feedback. This is a natural place to give feedback in the first half of the semester, when students are working individually on projects. I haven't thought much about the final project yet, but I suspect that once the semester is running, a path will open up for me. CS315 is not a course where we traditionally use Google Drive, but since I'm already collecting students' GitHub usernames, I can also collect Google Account names in order to set up a dashboard system like I described in my previous post.
Style
There are two major benefits to teaching students to have good style in this course. First, there is the intrinsic value to the student of learning to follow an established style guide. Second, it makes it much easier for me to read a lot of student projects if they follow the same structure. It is not so different from requiring a particular style in order to approve a pull request.
For some time, the exact style requirements have been distributed through the early semester exercises. This had the advantage that it allowed me to ramp up expectations as students became more comfortable with the game development ecosystem. The downside was that students had to build up knowledge piecemeal about the expectations, remember where to find reference material, and potentially build up bad habits until the right models were shown.
This year, I've done something I've wanted to do for several months: I constructed my own style guide. It has its own page on the course site, and all of it is required from the second week of the semester. It consolidates many aspects that previously were spread out across different grading levels in the checklists. It also puts almost everything in one place, which I hope will be useful. One place I could not easily bring into one site is the actual code style, for which I am simply having students follow Godot Engine's published conventions. For commit messages, I used to ask students to read Chris Beams' article on commit messages and follow his guidance, and this was frequently a source of frustration for students: some didn't understand version control well enough to follow his arguments, many skipped reading crucial parts of it, and some just had bad habits. Now, I have simply included his seven rules and linked to his article for more information.
Accessibility
The course site is built from the same Astro configuration as the CS222 one I referenced earlier. Writing and revising in Markdown is quick, and component-oriented design can be useful. One of the main reasons I want to use Markdown is that I want to easily include source code in the exercises. Unfortunately, the default Astro formatter violates WCAG 2.1 AA requirements that are now being required for all teaching material.
It took several hours to sort out a solution, and I ended up using the github-light-high-contrast Shiki theme in order for my code to pass muster. It does not have the aesthetics that I wanted, but at least WAVE says that it passes all the requisite checks.
No comments:
Post a Comment