Earlier today, I wrote about some of the constraints and unknowns I'm dealing with as I move forward with Fall course planning. Here, I want to share a reflection about how I've thought of my Fall 2020 Game Programming course (CS315). The course plan is online, and I welcome you to take a look and let me know what you think.
Godot Engine
The most obvious change is a switch from Unreal Engine to Godot Engine. I have spent a lot of time getting to understand UE4 and how to teach it, and so it was no small decision to make the switch. When we first set up Fall's schedule, my plan was to teach the class in our computer lab with our nice desktop rigs. However, with the shift to online instruction, I have to face the fact that not every student will have equal access to machines that can run UE4. We looked briefly into remote desktop solutions, but that was not possible either.
Godot Engine was a clear runner-up. It is free software, being licensed under the MIT License, and it is multiplatform. The documentation is astoundingly good, and it seems that there's enough people working with it to find good answers to common problems online. It has a small footprint, both in terms of the editor and deployment, and it doesn't take a workhorse desktop machine to get good performance. Indeed, when you look at the actual features my students have used from UE4, they rarely even use what makes that engine so powerful. Godot also publishes to the Web, which is one of the main reasons I've been happy to use it with my family. Its scripting language looks a lot like Python, which our CS majors learn in their introductory course. The node and scene system may at first be surprising to my students, but I am hopeful that I can use to explain concepts of object-oriented design. I think its approach may be like studying Lisp: you may not use it all the time, but it gives you a different way to think about program structure.
Course Project Structure
My intention for the course is that the students start by working through the well-known Dodge the Creeps tutorial before going into a tightly-scaffolded Angry Birds-style project. I struggled a bit with how to scaffold the experience, but I decided to go with weekly submissions with well-defined steps. I think that this series of steps should help students learn what I want them to learn, although I freely acknowledge that this is not the only series of steps that could do so. Most of my students coming into the class have no real game development experience, and so small steps with check-ins is probably worthwhile. It will mean I have to spend more time reading submissions, since each student will submit one per week, but this is mitigated by the use of specifications grading and checklists. I have written before about this combination, indeed sometimes positively and sometimes negatively. Regardless of whether or not a subset of students struggles with conscientious completion of checklists, it is a lot easier for me to verify a checklist than to grade a submission from scratch.
A challenge with this approach arises if a student falls behind. What if a student is content with a C on the first iteration but seeks an A on the second iteration, but their previous work has not set them up for success on the subsequent? At this point, I am going to accept this as a possibility where the answer has to be that they go back and retool the previous increment to support their higher aims. There is a possibility that I could drop reference solutions after each iteration, or ask successful students to share their implementations with their peers, but I think I'm going to go with the more direct, linear approach. There's a lesson within it that is hard for students to learn: your choices when writing software have consequences. Even after CS222, when students always proclaim that they have seen the light, I still see students not building up solid foundations from which to work. Since the project will only last about a month, I think it's OK for there to be some pain around mistakes, since it's the kind of pain that leads to growth, and without too significant of consequences.
My plan on paper is that once we finish the three iterations of Project 1 that you can currently see online, we will have a class discussion or vote about whether they want to have a final iteration that lets them pull all the pieces together, or if they want to jump into a second, 3D project. Until I get to know the students, I don't know which they will prefer. In any case, my plan is that the second project last 2–3 weeks only, so that they can see that 3D is basically 2D but with an extra dimension. I mean, that's literally what it is, though it has a mystique about it. This will then position the students to be able to move into a final project, which I have not yet specified. Right now, I think I will make the final project group-optional, and I expect to give the students plenty of opportunity to give input on how it will be graded.
Community
I am concerned about our ability to form a community of trust and respect without being able to hang out together in the lab. When I teach game programming in the lab, I spend some time doing direct instruction and worked examples, but I moved a lot of that to my game programming playlist on YouTube a while ago. (I have not yet put any Godot Engine content onto that channel, although I expect I will do some in the Fall or later this summer.)
My solution for this class is to award course credit for “community participation,” and to allow students to get these credits in various ways. The simplest and default case that I plan for the course is that, after a major milestone, students will post links to their games and repositories to a discussion board on Canvas. Then, other students will be able to earn community participation credit by reviewing and responding to three other students' projects. I am sure this will be nowhere near as exciting as our showcase days in the lab, but at least it will get students thinking outside of themselves for a bit.
I have written up a few other ways for students to earn these credits as well, drawing in large part upon my experience designing achievements for CS222. As of this writing, these alternatives include: participating in jam; creating a tutorial, blog post, vlog, stream, etc. relevant to course goals; serving in a leadership role in a community or campus organization relevant to course goals; or anything else they pitch that I approve. I'm hopeful that this will help students remember that while they are accountable for their own work, we're all in this together.
The Weekly Schedule
Of course, we will have to roll with the punches in the Fall, but I also need some kind of plan to get started. Right now, that plan looks like this: on Tuesdays, we'll do a live, synchronous meeting that is recorded for those who cannot attend. Here, I'll introduce the project for the week, explaining tricky parts, and perhaps showing the first couple of steps to get moving forward on it. On Thursdays, I'll do a sort of workshop / Q&A session. I am not sure exactly how that will go, but it will give me a chance to address to the whole class any patterns of questions I have seen. Maybe it will be like last semester's optional Zoom meetings in CS222, where I had no sense that students even knew I was there, but I'm hopeful that we can try to make it worthwhile for students to drop in. Unlike CS222, when each team was doing their own projects and could rely on each other, CS315 will have many people working separately toward the same goal, and I think this will mean more incentive to come and talk to each other.
A missing piece here is something like “office hours.” I have essentially given up on traditional office hours for various reasons that will derail this post—including even an argument that they are counter to social justice, believe it or not. I have been inspired though—and emboldened by an article on Medium recently written by my friend Travis Faas—to do some kind of less formal, streamed experience. A student who needs confidential help can always set up a traditional meeting via email, of course. This alternative would be something more like “Pints with Paul” if my students were all over 21, or if we didn't have ridiculous alcohol laws. “Programmin' with Doctor lG” doesn't have quite the same ring to it, but the idea is that I would be on something like YouTube or Twitch, actually actively working on something. Students could stop in and see what I'm doing, how I work, engage with the process, or ask about something currently happening in class. At that point, I would put my own thing down and we'd work a bit on theirs. I don't know exactly how that would work, but it's an adequate description of where my head is right now.
Over 4000 Words and Counting
I will mention briefly that the projects page for the course right now has over 4000 words and only specifies up through the third iteration of the first project. It contains more direct instruction than would normally put onto such a page, but I need students to be able to work primarily from it rather than from lab interactions with me and with each other. It struck me as I was working on it that I was in a sense writing a short book about Godot Engine project development, including self-evaluation exercises. It makes me wonder whether I can generate any additional value from this effort beyond what will help twenty or so undergraduates in one semester. For example, I could post the link to the course more broadly, or share it Godot Engine discussion boards or something.
Licensing
Another change to the course plan is that I (finally) have an explicit license included on the page. I regularly fight with students about intellectual property, frustrated in their lack of education in this area despite the ubiquity of digital media. At the same time, my own publicly-shared course plans never really said anything specifically about what I was allowing other people to do with them. There is now a clear statement that the plans are licensed under the Creative Commons Attribution-ShareAlike license. In fact, my original plan was to also include the NonCommercial restriction to the license, but the license selector pointed out that this would mean my work was no longer part of free culture, so I removed that clause.
As always, thanks for reading, and feel free to leave a comment or a question.
No comments:
Post a Comment