It was a fun semester working with about 25 students in CS315 Game Programming. Last Fall, the course was online and asynchronous, and it was good to be back in the lab again. One particularly fond memory was at the end of the first project, when I had the students rank each other's projects for a Student Choice award. It was fun to watch them engage with each other's work, an when the votes were tallied, it came out to a tie. We had the two tied students come to the front of the room for an electric game of Rock Paper Scissors to see who would win. That's the kind of serious educational business that you just cannot replicate online.
On Tuesday, the students took their final exam, in which they wrote project reflections that featured three "What went well" entries and three "What went poorly" entries. I shall move forward in the same spirit.
Godot Engine. This was the second time I have taught CS315 using Godot Engine, and I am even more convinced now that it is a great choice for this class. Students can see how ideas they have learned in prerequisite courses manifest when writing games in GDScript, and the few students who have already completed the capstone can similar bring those lessons to bear. We only pursued 2D games, which may be considered a mild weakness if you consider 3D to be essential, but frankly, I don't. I am confident that an earnest student could easily learn the 3D-specific tools and techniques with the 2D fundamentals they learned this semester. The quality of some of the games the students made was really impressive considering their experience level and time constraints.
Personal Progress Reports. I have already written about the frustrations I had in the first iteration of the final project with respect to my traditional self- and peer-evaluation format. I switched to the Personal Progress Report format that I learned from Jason Wiser, in which students report on what they planned to do, what they accomplished, whom they helped and who helped them, and external resources used. I required this to be a multimodal document, including at least screenshots. The students completed three of these weekly reports. Many students struggled with the format initially, particularly the use of multimodal composition: several students simply dropped in images with no explanation, no context, no obvious connection to the narrative. Through repeated feedback, I was able to get pretty much everybody on board. Reading these took more time than expected, but it was a good glimpse into students' behavior. I also was able to clarify any doubts I had about teamwork and consistency of contribution. The few students who referenced Personal Progress Reports in their final exam reflections acknowledged that it was a bit of paperwork to do, but that they also enjoyed having to think about what actually happened during the week. Overall, then, I think it was a worthwhile change, and now I'm wondering if something like this should also be backported into CS222, where I often struggle to get an honest glimpse into what's happening on teams. Note, however, that I did not explore the idea of allocating a fixed amount of points across team members for grading purposes; I have still been unable to dig up any good research here.
Short Intro, Long Final Project. We started with just a few weeks of fundamentals, expressed in three projects and a one-week midsemester ex(j)am. I cut a week here from last year's plan, removing a project that dealt with 3D development. As usual, I gave the students a lot of freedom in designing their final project. Since the course doesn't really cover "game design" but only technical issues, students could pursue anything that would be reasonably in scope. Generally speaking, I was impressed by what the teams put together. I am eager to see if the quality of projects continue to improve as more students conceive of CS215 Game Design and CS315 Game Programming as a logical sequence.
Semi-Public Showcase. To celebrate the students' good work, we agreed to hold a semi-public showcase of their projects. I sent invitations via email to every CS faculty member and major, and I also invited a few other faculty friends. I bought a bunch of cookies, and my son baked two excellent homemade batches of cookies and brought them, too. We got the college social media person to come and take pictures. In the end, though, we only had about about five people from outside the class attend, including zero students. Now, I understand that everyone is busy and students in particular are inundated with so many invitations that they ignore basically all announcements. That said, I couldn't help but feel disappointed, in part because I had spent so many hours planning and in part because so few people were able to play these games, get inspired, and congratulate their makers. It is possible that, in a future year, we could do something more like the CS120 Art Show, having the games someplace public to be enjoyed. I'm not sure I have the endurance for planning that kind of event, though, so I'm really not sure right now where the next logical step is here.
Checklist Grading and Design Quality. Checklist-based grading worked well for the technical matters that are expressed in the syllabus, but it's really not enough to help students think about iterative design. What to do with a team that makes a terrible design decision, which I give feedback on each iteration, and which they never change, to the detriment of their project? As mentioned above, game design is not actually in the learning objectives, but it sure seems like a good opportunity to reinforce some ideas of user-centered design. At the end of the second iteration, I decided to have them try the five-point rubric I talked about in a previous post: clarity, innovation, immersion, flow, and fiero. I explained to them that I didn't quite agree with that taxonomy, but that the goal was to just get talking about design issues. Indeed, teams formed up into clumps and had useful conversations that were then referenced by a few students in their final reflections. It would be easy enough to bring this more formally into the course with just a bit more structure and scaffolding.
The 3D Blind Spot. My supposition is that a student who wanted to learn Godot Engine's 3D features could just do it, and this is based on the same kind of belief as my idea that a student could learn Unity or Unreal Engine based on their experience in the class. However, I have no real data about that. Nobody in the class seemed to mind skipping over 3D. Indeed, students could have done 3D games as their final projects, but nobody seemed to want to. Instead, games had the look and feel of either retro Flash games or 2D indie games. I do wonder, though, as my department is looking at more strategic collaborations with the Animation department, how exactly a student from this course would be able to jump into a collaboration with a 3D artist. Maybe we should try to set this up in a jam experience to see what happens.
Of course, we had all the normal pros and cons of a semester, with some students really excelling, some falling behind, some showing up every day and asking good questions, some refusing to show their faces. That's all pretty normal. Overall, this course was a great joy to teach this semester, and I had a wonderful time working with the students on their projects. I'm hopeful that they are inspired to carry on, join some jams, and keep sharing stuff with the community.
No comments:
Post a Comment