In the Fall, I will be teaching Game Programming (CS315) again, the first time since 2015. Normally it would have been offered last year, but we had a teaching pinch as we were conducting three faculty searches simultaneously. Last time I taught the course, we used PlayN, which remains one of my favorite game-programming libraries. I even wrote an article in the Journal of Computing Sciences in Colleges about it. This year, however, change is afoot.
I have a grant from the Indiana Space Grant Consortium to enhance Collaboration Station, the educational game about the International Space Station that my team—Space Monkey Studio—developed in Spring 2015. You can read all about that in my post from the end of that semester. It's a small grant, but I figured I can supplement the scholarly production goals by dovetailing the project into my teaching. Hence, I will use the revision of Collaboration Station as a case study for this coming semester. I will recruit a small team to finish and publish it in the Spring, but I would like to see my CS315 students providing much of the creative production work during the Fall.
Two of the primary goals for the revision are cross-platform support and robust, cross-platform multiplayer support. When we started Collaboration Station in PlayN, I had hoped to use the cross-compilation feature to produce an iOS build; however, that was right around the time that licensing changes made that feature questionable. Additionally, the Bluetooth-based networking that we implemented on Android was not possible in iOS. During our production, we tactically dropped iOS support from our plans and successfully released the Android version, but this future work will revisit the issue.
I talked to several vendors and developers at GDC this year, and based on those conversations, I decided that Firebase could provide a perfect solution for networking, and that Unreal Engine (UE4) would provide a robust and learnable platform for development. Learnability is important: as much as I love PlayN, it was always challenging to teach with, since there are not many tutorials. The APIs are best explored by reading the source code and exploring GitHub repositories, which my students tend to have trouble with. It's a good skill to develop, of course, but it takes time! UE4 has myriad high-quality official and unofficial tutorials, videos, online courses, and assets, which means it should be easier to let students explore in their preferred mode. Also, in case you haven't seen it, UE4 contains an excellent graphical programming environment called "Blueprints". Here's an example from my UE4-based implementation of the Collaboration Station memory minigame:
The whole block is commented to describe its intention, as one would do with any source code comments. When this agent receives the "Play Grid Complete Effect" event (red, upper-left), it sets a 0.5-second timer, after which it fires—and handles—the "Delay Complete" event. After that, a new grid object (of class "BP_Grid") is spawned at the location of the previous one. After that, the old, finished grid is destroyed. Epic has put a massive amount of effort into making Blueprints easy to work with, but it's still very robust and powerful. I have heard some well-meaning evangelists claim you can use UE4 "without programming", but make no mistake: this is certainly programming! It's just visual programming rather than text-file-based programming. This gives it a much gentler syntax than C++ (which is the alternative in UE4). The Blueprints API is also completely searchable from withing the Blueprints editor itself, which means that once you learn some core terminology ("event", "actor", "pawn", "vector", etc.), you can often find what you need without having to leave the IDE.
Below is a quick, low-fidelity screencast showing the memory game in action. It starts with a short introduction, then shows the player flipping cards. After a few flips, he realizes that the "randomize" developer option was turned off and clears the board easily. This earns him a "Boost" that can be given to another player. This is one of the new gameplay features I have planned for revision, something to make the game feel more like a collaborative effort rather than disjoint individual minigames.
There has been no bridge between Firebase and UE4, however, and so I was excited to read about GameDNA's development of a Firebase Realtime Database plug-in. Unfortunately, its release has been mysteriously delayed, with no new release date announced. Before heading out for a family vacation, I developed a skeleton software architecture as demonstrated in the video above. I hoped the plug-in would be released while I was away so I could pick it up on my return, but no such luck. If it comes out in the next few weeks, I hope to be able to stub in the essential multiplayer architecture; if not, that will have to wait until after the semester starts, when it's much harder to carve out days for serious engineering efforts. My experience developing the original Collaboration Station was that the networking layer was too technically complicated for my students to handle themselves—the course does not have any networking prerequisites, and writing production code is not the time to make all the newbie mistakes.
I have had these plans swirling around my mind for some time now, but I have found it challenging to turn these ideas into a coherent course plan. As I wrote about after Ludum Dare 38, it took me months to make sense of UE4, and that's with a lot of background knowledge about programming in general and game development in particular. I am sure the path I took would not be optimal for my students, and so I am left uncertain about the pedagogic details. Very roughly, I imagine a structure like I use in all my project-oriented classes, with a few weeks of fundamentals followed by group projects. I plan to incentivise teams to develop minigames for the Collaboration Station revision, although I don't want to mandate that for fear of diminishing the motivation of teams who have another vision. I am not sure where that balance should be between the up-front instruction and the guided chaos of learning-by-doing.
The course design is complicated by the sheer scale of the class: last time I taught it, I had about 14 students, and I was able to keep track of their 4–5 teams without too much effort, but this time I have a full class of 32. Our existing lab machines don't have graphics cards that support UE4 development; the department has acquired one game development workstation and has budgeted for two more, but that's still ten students per workstation! I know that some of the students will have laptops that are capable of running UE4, but I have no way to know how many until I meet them. If only a handful have machines that can run UE4, then there's not much point in trying to use the classroom to do development work—honestly, I'm not sure what that would portend, and so I'm just hoping we hit at least the 50% mark so that pairs can work together during scheduled class time.
I know I want to grade them based on their process rather than their product, since I know first-hand that it took a lot of trial-and-error before I was able to confidently make something reasonable in UE4. A focus on process means that I can pull on my experience with Agile techniques such as Scrum. I don't think XP will work here since it's not clear to me that test-first is the best way to write experimental gameplay code, and I expect a lot of what my students will write will be shot-in-the-dark experimental code. Other concepts of Clean Code can still be applied of course, such as the importance of decomposition: hundreds of Blueprints on one screen are just as bad as any other monolothic design. (Actually, whether a visual language or a text-based language is worse for readability of badly-written code would be a great research project.)
A few days ago, I suddenly remembered reading about OKRs late last semester and thinking that they might contain something interesting for use in my Fall teaching. For those who don't know, OKR stands for "Objectives and Key Results," and it's a way of orienting an organization toward productive work. They are famously used at Google, among other places, and this Google Ventures presentation gives a comprehensive overview. One of the important features of OKRs is that they should not be used for employee evaluation—something I had forgotten until I got one or two hours into reviewing what they are and how they work. However, I was reminded of another important property of OKRs: they can be deployed at any level of the organization. I decided to try my hand at writing OKRs for Fall's Game Programming course, with an eye toward considering how articulating my objectives might help me develop appropriate student learning evaluations.
Without further ado, here are the objectives and their associated key results:
- Produce a stable beta release of revised Collaboration Station by the end of the semester.
- No gameplay crashes through ten routine plays
- Released as beta on Google Play Store
- All the sources are in the github repository
- Include six minigames, including UE4-implementations of the original four
- Document, in the repository, how to write and integrate new minigames
- Implement revised multiplayer support via Firebase
- Players can join game by keying in an ID
- Firebase rules enforce structure
- Include boost-generation and boost-consumption in each minigame
- Gracefully handle, through narrative, player drop-out
- Produce a public Web site designed to help CS majors learn UE4
- Provide four introductory paths through available materials
- Curate and critique ten or more UE4 videos
- Compose two original tutorials in text, video, or multimodal
OKRs are supposed to be ambitious, perhaps even a little painful. One is not supposed to hit them all; a reasonable target is around 70%. Keep in mind that this is really my first effort at using this technique, and yet I feel like this was a useful exercise; I think these may help me articulate my expectations for my students and develop assessments, likely through an achievement-style system as I have used in CS222 for several semesters.
The first objective is about the software production itself, and the key results are all clearly measurable. At first I didn't have the "through ten routine plays" clause, but I realized that without such a clarification, there was no bounds around the KR to keep it feasibly measurable. The second objective deals with the multiplayer aspect, with the possibly-pessimistic assumption that this is something my students and I are going to have to deal with during the semester rather than my sorting it out over the summer. That last objective is based on something I tried way back in 2010, when I was first learning Android and having my students join me in the process. We structured the whole course around a public site; I wrote a little about this back on my old wordpress blog. If my students can figure out how to learn UE4 within the context of our course, then expressing how they did this should help them crystallize their own understanding, and it will produce something of value for future students. This also could give the course a different flavor for a student who was more interested in, say, running summer camps for kids on game development rather than producing games themselves: it's a different yet valid way of knowing the domain. Then again, I could cut that last piece entirely so as not to dilute my students' focus. Clearly, I have not yet decided, but I would like to have a draft course plan complete by the end of the week.
I believe that I have laid out all the major elements of the course. As always, I welcome your suggestions and comments. Expect a follow-up post later this month that ties some of the loose ends together.
No comments:
Post a Comment