Before the Fall semester fades away into memory, I wanted to capture a few of my thoughts about its CS315 Game Programming course. Interested readers can examine the course plan as well as my summertime blog post describing the plan's construction. What I will do here is start by addressing the major points that I brought up in the other post.
More Small, Structured Projects
This went well, having four two-week projects that increased in technical complexity. I prevented people from choosing the same partners for the first three, which I think was also successful in both building community and sharing knowledge. Curiously, it was not entirely successful in helping some students avoid unproductive team members in the final project, but at that point, the onus was on them, and so it was their learning opportunity.
Some students wanted even more fine-grained assignments and closed-form assignments. An example might be to take a skeletal project and add a new actor or component to produce a desired behavior. This suggestion seemed to have influence with students who had middling performance, and this makes it worth considering. Those students who are still on the road to learning how to learn may need more fine-grained scaffolding. On the other hand, I was always available to help them move forward on the projects, and so it's not completely obvious that they simply weren't being responsible with their time.
Specifications Grading
This was, by and large, a great success. The students knew what they had to do to earn the grade they wanted, and there were very few questions about ambiguous criteria. I did end up giving each student a "Quick Save" which allowed them to fix one criterion and resubmit, addressing the concerns I expressed in my September post. I regret that I didn't think to call them "Save Points", since that's what they do.
A good addition to the specifications grading approach was to require a project report in which students told me what grade they earned. This made my evaluation into a verification rather than a bug-hunt. I like how this forced the students to go back and look at what they had done and follow a checklist of critical ideas. Some students had what I consider unreasonable trouble with Markdown, but at least they learned a new skill along the way. I am thinking of incorporating specifications grading into my HCI class in the Spring, and I will definitely take this approach to fostering students' reflections on their work.
During one of our class meetings after the first iteration of the final project, I asked the students what they thought about the specifications of the final project, and in particular whether they would make any additions to A- or B-level criteria. The one A-level that came up was profiling—a great idea that I had not considered at all. One of the teams used a Post-Processing Volume, and we agreed that this could be a good B-level criteria. A more insightful and critical student pointed out that it would be useful to distinguish between "bare use" and "proficient use." A good example here is Behavior Trees. The grade criteria was simply to "use Behavior Trees," but this could be done with a one-node tree that is just awkwardly recreating what could be done in a simple call to UE4's AI Move To. This is an area that I can try to clean up in the future.
Another area that was surprising to me was how many students had trouble with the criteria to document the licenses under which they used third-party assets. I know this is something that I bring up when I teach CS222, although few people there use third-party assets. In this class, everybody used some textures, models, sound effects, or music that was created by somebody else. I'm not sure if I need to have more documentation about this, plan an early-semester lecture about it, or give more examples. Very few students did it right the first time, and many more made mistakes more than once, which is a bit mind-boggling to me. That is to say, I do not understand which part of the process they do not understand.
Perforce Helix
A lot of students struggled with Perforce Helix, as I expected. However, it did serve its pedagogic and practical purposes: the students got to see a different model of version control from GitHub, and it ensured that all the projects were in one place. I have little sympathy for the one or two students who still could not use P4V at the end of the semester: at some point, they must have given up trying, because everyone else got used to it. I need to review my video tutorials on this topic before next Fall, because I think I may be able to tighten them or get more targeted at the kinds of problems students had.
Simple Achievements
I was surprised that a very small number of students pursued the achievements I set before them. I really thought that there was low-hanging fruit here for course credit: learn basically anything about UE4, talk about it for five minutes in class, get credit. There certainly were interesting things learned that I had not planned on, including post-processing volumes and custom animations via bone rotation in Blend Spaces. Perhaps this extra step was not necessary, since when teams demonstrated their work, their classmates would always ask at something interesting, "How did you do that?"
I don't have much to say about the Decorum and Diversity portions of my original planning essay, so I will move on to...
Conclusions
I think it was a great semester. I was really impressed with the students' projects. I expect to teach the call again next Fall, and I will make some minor modifications. If we are able to replace the lab machines with UE4-capable rigs, that would be even better, since then we could do more "lab" exercises. I also learned a lot this semester, manifest in my new video tutorials and my Heroic Uncertainty National Game Design Month project. My department has been on this strange pattern of offering HCI every semester (including summers!) when it used to be a once a year course, and as much as I like that course, this one is much more where my mind is these days. Perhaps I need to talk to the department about trying a Spring section of this course next year.
No comments:
Post a Comment