This is the last in my series of Summer 2017 course revision posts, turning to the course I teach every semester and revise every summer: CS222 Advanced Programming. The most significant changes to this course result from its finally returning to a twice-per-week meeting schedule. When I first offered the course, it was on a Tuesday/Thursday schedule. The extra 25 minutes in a meeting gives time for more sophisticated discussions and more hands-on practice. Also, with two meetings per week, I was able to give assignments every day and still turn them around rapidly. A few years ago it was moved to a MWF schedule, and I remember the meetings feeling very short. Also, I feared I wouldn't be able to keep up with three grading marathons per week, and so I switched at that point to my weekly assignment schedule. That very semester, I asked to return to the twice-weekly schedule, but this request was forgotten or not acted upon. Several friendly reminders later, I'm scheduled again for twice per week.
There have been a few changes over the years that mean I cannot simply pull back in my old course plans. The original incarnation of the course used Joshua Bloch's Effective Java as a text. In the intervening years, I switched over to Robert Martin's Clean Code, which gains generalizability over the Java-specific information in Bloch's text. I have been happy with that transition. Another significant change is in the structure of the course. I used to have about five weeks of introduction, a two-week project, and then a six-week project completed in two three-week iterations. Several semesters ago, I decided to cut the introduction short and add an extra three-week iteration to the final project. As with the change in texts, I think this was a very positive change.
I have decided for the Fall to bring back the "daily" assignments during the first three weeks of the course. I also plan to extend the assignments into the project portion of the course in order to help students stay on track. For example, I like to introduce design thinking each semester and have students consider a five-step design-thinking process and consider what it means to their team and their final project. This is usually isolated to class time, and I suspect most people don't carry this idea with them after the discussion. Giving a small essay assignment after the in-class exercise should both reinforce the material as well as incentivize attendance and participation.
I started the process of breaking down the weekly assignments into twice-per-week assignments, but I haven't quite finished that yet. I think I may just leave it as-is, though, and see how the first week of classes goes. I would like to leave the door open to allow myself to transition in-class discussions more smoothly into assignments, having students wrap up some examples or write responses to an idea, for example. This kind of spontaneity appeals to my just-in-time teaching philosophy, although I am a bit concerned about teaching three courses on Tuesdays and Thursdays with 90 minutes between each. I will need to safely guard the 90 minutes after CS222—the first course of the day—to give myself time to tweak the assignment for the next day and to prepare myself for the next class.
The rest of the course will stay pretty much the same. I will come up with a reasonable two-week project, likely reusing my Wikipedia Analyzer project but modifying it to use JSON rather than XML. One of my students pointed out in the Spring that Wikipedia's XML API is being deprecated, so I may as well get my students in CS222 doing some JSON parsing. The final project format will remain the same, except for the occasional assignment dropped in to keep students honest. I am keeping the achievements as well, although using the smaller number of creditable achievements that I tested in the Spring (four) rather than the larger number I had been using in the Fall and previously (six).
The current draft of the course description is online. I recreated my course site design based on the Polymer 2.0 release, and the sites for other two courses I wrote about earlier this week were derived from this one. The navigation no longer has to make use of hash paths, thanks to the service worker. This caused me a slight headache the other day when I loaded the page over HTTP and all the navigation broke. I was able to port the essential parts of the platinum-https-redirect element, which does not yet support Polymer 2.0, to force my course pages to load over HTTPS. I also tweaked the sw-precache configuration this morning for all the sites, hopefully in such a way that the static content is appropriately cached for offline access.
I feel good about getting most of my course redesigns done this week. I will be participating in my university's pilot of Canvas as an LMS, and I have spent some time tinkering with it as well. It seems like it will serve my needs well, and it has several features that are clearly superior to Blackboard. I am curious to hear what others in the pilot think, especially those who were more entrenched into the Blackboard ecosystem. I try to use the LMS as little as possible, since the tools of my trade live elsewhere on the Web.
Thanks for reading! As always, feel free to share your thoughts and suggestions in the comments.
Friday, July 28, 2017
Wednesday, July 26, 2017
Summer 2017 Course Revisions: Game Design
In case I have not mentioned it here before, I am grateful to have another internal grant to pursue an immersive learning opportunity—that's Ball State's brand of student-centered, faculty-mentored, product-oriented, community-connected learning experience. Over the next academic year, my students and I will be working with Minnetrista, which is a local museum and cultural center. In particular, we will be creating geolocative games that can be played on Minnetrista's beautiful grounds. This is a spiritual successor to last year's Spirits at Prairie Creek game (blog post here), which was my first foray into geolocative games. This year, we'll be using the spatial element along with more focused and educational narrative content. The grant allows me to teach my game design course at the Honors College, and so one of my summer tasks was to revise the course. It is offered as an honors colloquium, which means that it's only open to Honors juniors or seniors, who come from any department on campus; each Honors student has to take six credit-hours of colloquia, so it's sort of a captive audience of high-achieving students.
I have decided to make some changes to the course to try to improve the outcomes. The results can be found on the course description that I published yesterday afternoon. The overall structure will be the same, with a few weeks of theoretical foundations and exercises followed by focus on iterative production of final projects. The most obvious change is in the book selection. Many years ago, when I was using the Honors Colloquium as a team production environment, I had an achievement where students could read Koster's Theory of Fun for Game Design. This book was immensely influential on me: reading it was one of the factors that shifted my scholarship from information visualization to a focus on games and game design. Each time a student earned this achievement, I asked if they thought it was something everyone should read, and my recollection is that the answers were unanimously affirmative. A few years ago, then, I made this a central reading for the course. We spent a lot of time discussing the weighty and beautiful ideas Koster presents in his classic book. However, Koster's treatise is about why we make games, not how to make games, and given that my students generally have no background in game design—and almost all of them have precious little exposure to games beyond school sports and Monopoly—I started wondering if I was getting the cart before the horse. This year, I have designed the first several weeks around reading Schreiber's Game Design Concepts, which began life as a massive open online course in Summer 2009, before the "MOOC" acronym was popularized. It remains on the Web as, essentially, a free and high quality game design textbook. My students will be working through a rather aggressive schedule of readings and exercises as we go through the first ten levels of Schreiber's work. I hope that this will help prepare students more explicitly for game design work, familiarizing them with more of the nomenclature and processes of game design.
A related goal for the course is to increase the accountability of the learner. With any discussion-oriented class, one tends to have a mix of levels of engagement, but one maxim remains true, especially for Honors Students: if you grade it, you communicate to them the seriousness of it. I would rather have all my students engage through pure passion for the subject, but that's kind of a pipe dream: these students are pulled in so many different directions that even a passionate student needs to sacrifice their interests for more pragmatic issues. Hence, for the first time in my roughly twenty years of teaching, I am assigning participation credit. The course will only have 10–15 students, and so I hope that I can do this in a lightweight manner, with a simple sheet in my binder that I can mark as students share insight and critiques. You can be sure I'll let you know how it works out.
The course description lays out a high-fidelity schedule through October 12, at which point I expect to transition to production mode. Rather than specifying the precise final project requirements and schedule, I designed the grading scheme in such a way that the students and I can negotiate the requirements when we get closer to it. I think if the students work through all I am asking them up to that date, they will have a good sense of what they can expect from themselves moving forward.
I am excited to teach this course again, and I'm hoping for a positive mix of majors and interests. At some point I have to dig up some more icons to use for achievements, since I just dropped in a placeholder question mark yesterday. My next course redesign task might be my most ambitious one yet, though, as I have to reconsider my CS222 plans in light of moving back to a twice-per-week schedule. But first, breakfast!
Thanks for reading, and as always, feel free to share your thoughts in the comments.
I have decided to make some changes to the course to try to improve the outcomes. The results can be found on the course description that I published yesterday afternoon. The overall structure will be the same, with a few weeks of theoretical foundations and exercises followed by focus on iterative production of final projects. The most obvious change is in the book selection. Many years ago, when I was using the Honors Colloquium as a team production environment, I had an achievement where students could read Koster's Theory of Fun for Game Design. This book was immensely influential on me: reading it was one of the factors that shifted my scholarship from information visualization to a focus on games and game design. Each time a student earned this achievement, I asked if they thought it was something everyone should read, and my recollection is that the answers were unanimously affirmative. A few years ago, then, I made this a central reading for the course. We spent a lot of time discussing the weighty and beautiful ideas Koster presents in his classic book. However, Koster's treatise is about why we make games, not how to make games, and given that my students generally have no background in game design—and almost all of them have precious little exposure to games beyond school sports and Monopoly—I started wondering if I was getting the cart before the horse. This year, I have designed the first several weeks around reading Schreiber's Game Design Concepts, which began life as a massive open online course in Summer 2009, before the "MOOC" acronym was popularized. It remains on the Web as, essentially, a free and high quality game design textbook. My students will be working through a rather aggressive schedule of readings and exercises as we go through the first ten levels of Schreiber's work. I hope that this will help prepare students more explicitly for game design work, familiarizing them with more of the nomenclature and processes of game design.
A related goal for the course is to increase the accountability of the learner. With any discussion-oriented class, one tends to have a mix of levels of engagement, but one maxim remains true, especially for Honors Students: if you grade it, you communicate to them the seriousness of it. I would rather have all my students engage through pure passion for the subject, but that's kind of a pipe dream: these students are pulled in so many different directions that even a passionate student needs to sacrifice their interests for more pragmatic issues. Hence, for the first time in my roughly twenty years of teaching, I am assigning participation credit. The course will only have 10–15 students, and so I hope that I can do this in a lightweight manner, with a simple sheet in my binder that I can mark as students share insight and critiques. You can be sure I'll let you know how it works out.
The course description lays out a high-fidelity schedule through October 12, at which point I expect to transition to production mode. Rather than specifying the precise final project requirements and schedule, I designed the grading scheme in such a way that the students and I can negotiate the requirements when we get closer to it. I think if the students work through all I am asking them up to that date, they will have a good sense of what they can expect from themselves moving forward.
I am excited to teach this course again, and I'm hoping for a positive mix of majors and interests. At some point I have to dig up some more icons to use for achievements, since I just dropped in a placeholder question mark yesterday. My next course redesign task might be my most ambitious one yet, though, as I have to reconsider my CS222 plans in light of moving back to a twice-per-week schedule. But first, breakfast!
Thanks for reading, and as always, feel free to share your thoughts in the comments.
Monday, July 24, 2017
Painting Imperial Assault: Twin Shadows
I found a good deal on Imperial Assault: Twin Shadows and decided it was time to get back to painting some Star Wars figures. Fantasy Flight Games announced several months ago that they would be making a cooperative app similar to Road to Legend for Imperial Assault. Knowing how the Visions of Dawn expansion (painting report 1 & 2) added quite a bit of enjoyment to my family's playing Descent (painting report 1 & 2), it seemed like Twin Shadows could be a worthwhile acquisition.
I started out with the Heavy Storm Troopers:
There are four of them, and I distinguished the elite from the regular units by the coloration of the backpacks: two in blue, two in red. I spray primed the whole set with white Krylon, which especially simplified these guys. A wash brought out the details, and a few layers of white to bring up the highlights. The gun and backpack were done in a mix of gunmetal and dark grey, with black ink wash for shading and a light touch of highlights. No real tricks, but there's something satisfying about the iconic contrast of Storm Troopers.
Next up were the Tusken Raiders:
Tusken Raiders are also called "Sand People," but I think I will call these guys "Sepia people." I mixed a few similar khaki tones for the various parts of cloth and did all the shading with a sepia ink wash. I focused the highlights on the headwraps. Adequate tabletop quality, I say. I decided to distinguish the elite units by painting the heads and spike of their gaffe sticks in bronze. If that doesn't scan well at the table, I can always go over the whole weapon that way.
Next up is Saska Teft, the engineer:
She was done in a similar straightforward style: base coat on everything, colored ink washes for the various regions, brushed on highlights. The face is not great, and though I hate to blame my tools, it wasn't until I was done that I realized I was not using my good brush. I have two brushes with similar handles, and I had accidentally grabbed the wrong one; at the time, I was disappointed that my good brush had already lost its tip, but it wasn't the right brush at all.
I used a light blue glaze for some OSL coming from the screen she's carrying. I don't do a lot of OSL, but one of the important tips I applied here—I think from one of Ghool's tutorials, though I cannot remember specifically now—was to highlight the lit areas normally first. That is, on her right side, I applied faint highlighting in the "natural" colors, as if there were a white light source on the side. Then, the glaze tinted those highlights to give them the right color. Whatever video I watched or article I read, the author was right about the error mode: some of my earlier OSL, I simply tinted the areas I wanted to look like they were glowing, but that's not really how light works. I think it's a nice effect, subtle but noticeable.
Last figure in the expansion is Biv Bodhrik, the vengeful guerrilla:
He took a bit longer than Saska Teft for a few reasons, one being that he has more different pieces and colors, another being that paint around that massive weapon was tricky. Keeping in mind that the figure was primed white, and much of his outfit is a sort of khaki, my first step was to mix some different washes to tint and shade those areas. I don't think I had tried this before, but I think I was expecting it to be more dramatic than it was; it clearly still needed significant highlighting, or for the detail-light kneepads, repainting. I decided to try some two-brush blending on some of the larger parts, so I mixed up some deeper shades for the jacket, shirt, and kneepads. Turns out for the jacket in particular, I didn't have the tone quite right, mismatched brown and green. However, after I looked at it, this really gave it a weathered look I hadn't intended. I moved forward with a bit of clean-up work but kept the tonal variation. I know I've written about the idea of doing more tonal variation before, so here's my first real result—arising from a complete accident!
I wet-blended the orange shoulderpad for what I consider a good highlight, and the two rebel insignia were freehanded. Up close one can see the imperfections, especially in the small one on the weapon, but at the table I think they look fine. Also, in case you're curious, the card art has the shoulder insignia tilted and off-center, too, and that's why I painted mine that way.
I have not painted many figures with his shade of skin tone. My painting has a reddish hue that is not found in the card art, but I had trouble matching that sort of dark-chocolate tone. It will give me something to work on.
This leads me to my other trouble, that old bugaboo that I've been fighting with for years now: photographing miniatures. In my original set of photos, I maxed out the whites in post-processing, as in my Descent heroes post, for example. However, I did this post-processing in the Google Photos app on my Nexus 5X. When I opened the Web app, the cropping was saved but not the color level changes. Also, the Storm Troopers in particular looked awkward with the whites cranked up. On a lark, I also tried shooting on black background. Here are some examples:
Neither of these were subject to any post-processing. The Storm Trooper looks pretty good here, except for a bit of a "glow" (there's probably a photography term for that). The skin tone on Biv Bodhrik is much more accurate to life than the other picture, capturing that reddish hue I mentioned. Look at Saska Teft's vest, though: the line details are gone due to the glow of the light color.
Unsatisfied with both, I took a different approach and, in the Google Photos Web app, turned the whites up to 75% on all the white-background images above. This "works," and it certainly is more predictable than my old "photograph in front of a relatively clean piece of paper" approach, but I still find myself wishing that my online logs here had more color and brightness verisimilitude with the real painted miniatures.
That's it for Twin Shadows. It's been two years since I played the core Imperial Assault campaign, so perhaps I'll try to grab some friends or teach my boys to play through the Twin Shadows mini-campaign. It has the problem that, as the Imperial player, I still don't really want the Imperial player to win: I cannot shake my enthusiasm for the Rebellion nor my DM-style rooting for the players. In the mean time, back to Fall course planning!
 |
| Caution: No Boba Fett contained within. |
Next up were the Tusken Raiders:
Tusken Raiders are also called "Sand People," but I think I will call these guys "Sepia people." I mixed a few similar khaki tones for the various parts of cloth and did all the shading with a sepia ink wash. I focused the highlights on the headwraps. Adequate tabletop quality, I say. I decided to distinguish the elite units by painting the heads and spike of their gaffe sticks in bronze. If that doesn't scan well at the table, I can always go over the whole weapon that way.
Next up is Saska Teft, the engineer:
I used a light blue glaze for some OSL coming from the screen she's carrying. I don't do a lot of OSL, but one of the important tips I applied here—I think from one of Ghool's tutorials, though I cannot remember specifically now—was to highlight the lit areas normally first. That is, on her right side, I applied faint highlighting in the "natural" colors, as if there were a white light source on the side. Then, the glaze tinted those highlights to give them the right color. Whatever video I watched or article I read, the author was right about the error mode: some of my earlier OSL, I simply tinted the areas I wanted to look like they were glowing, but that's not really how light works. I think it's a nice effect, subtle but noticeable.
Last figure in the expansion is Biv Bodhrik, the vengeful guerrilla:
I wet-blended the orange shoulderpad for what I consider a good highlight, and the two rebel insignia were freehanded. Up close one can see the imperfections, especially in the small one on the weapon, but at the table I think they look fine. Also, in case you're curious, the card art has the shoulder insignia tilted and off-center, too, and that's why I painted mine that way.
I have not painted many figures with his shade of skin tone. My painting has a reddish hue that is not found in the card art, but I had trouble matching that sort of dark-chocolate tone. It will give me something to work on.
This leads me to my other trouble, that old bugaboo that I've been fighting with for years now: photographing miniatures. In my original set of photos, I maxed out the whites in post-processing, as in my Descent heroes post, for example. However, I did this post-processing in the Google Photos app on my Nexus 5X. When I opened the Web app, the cropping was saved but not the color level changes. Also, the Storm Troopers in particular looked awkward with the whites cranked up. On a lark, I also tried shooting on black background. Here are some examples:
Neither of these were subject to any post-processing. The Storm Trooper looks pretty good here, except for a bit of a "glow" (there's probably a photography term for that). The skin tone on Biv Bodhrik is much more accurate to life than the other picture, capturing that reddish hue I mentioned. Look at Saska Teft's vest, though: the line details are gone due to the glow of the light color.
Unsatisfied with both, I took a different approach and, in the Google Photos Web app, turned the whites up to 75% on all the white-background images above. This "works," and it certainly is more predictable than my old "photograph in front of a relatively clean piece of paper" approach, but I still find myself wishing that my online logs here had more color and brightness verisimilitude with the real painted miniatures.
That's it for Twin Shadows. It's been two years since I played the core Imperial Assault campaign, so perhaps I'll try to grab some friends or teach my boys to play through the Twin Shadows mini-campaign. It has the problem that, as the Imperial player, I still don't really want the Imperial player to win: I cannot shake my enthusiasm for the Rebellion nor my DM-style rooting for the players. In the mean time, back to Fall course planning!
Thursday, July 20, 2017
Summer 2017 Course Revisions: Game Programming
I introduced the main ideas of my CS315 Game Programming course revision in my previous post. Since then, I have worked on the course design and come up with a plan that I think will work. I have posted the course description online in case anyone wants all the details; here, I want to document a few of the decisions and their rationale.
To get the students' hands dirty, I developed an assignment I've called "Flappy Whatever." The assignment specification is actually posted up on Ball State's Canvas instance. The university is conducting a pilot investigation of Canvas as an alternative to Blackboard; I am coming in on the second or third semester of the pilot, and I figured putting the assignment there would give me a chance to get to know the interface a bit. Short version: it's fine. More to the point, the assignment is for individuals or pairs to develop a minimally playable game in Unreal Engine 4 that meets the following requirements:
To get the students' hands dirty, I developed an assignment I've called "Flappy Whatever." The assignment specification is actually posted up on Ball State's Canvas instance. The university is conducting a pilot investigation of Canvas as an alternative to Blackboard; I am coming in on the second or third semester of the pilot, and I figured putting the assignment there would give me a chance to get to know the interface a bit. Short version: it's fine. More to the point, the assignment is for individuals or pairs to develop a minimally playable game in Unreal Engine 4 that meets the following requirements:
- Includes firing a visible projectile in a parabolic trajectory, using UE4's physics engine
- Include a scoring or end condition
- Source code is posted to our class GitHub organization
- Game title includes the word "Angry" modifying a noun
This is a riff on an assignment I gave one of the first semesters I taught CS315, where the students had a week to make a simple projectile-based demo. I fondly remember one of my students styling it as Homer Simpson throwing donuts. I've scheduled two class during which students are working on this, and I've added a requirement that students bring in questions about what they encounter. I hope that this will drive us quickly to the areas that are both important and misunderstood. We'll close up the assignment with a demo day, where students can show off what they came up with. I'll put together a demo of some kind using UE4's Paper2D system, since this will be something useful for the Collaboration Station revision, but I would be fine with students building something in 3D space for the assignment as well.
From there, I want to move rather quickly into incremental and iterative development. I will do one or two classes to introduce fundamentals of Scrum since there will be too many students for me to directly manage: I plan on using a Scrum-of-Scrums configuration, with students optionally rotating who is acting Scrum Master each iteration. I didn't put this in the course description, but I plan to grade each iteration the way I normally do for my game studio courses, with each student participating in a collective reflection and writing a personal, individual reflection. I intend on allowing students to shift between groups between iterations if they wish, and I am considering asking each team to identify its own OKRs based on the ones I wrote up before.
Careful readers may notice that I completely dropped the concept of my students making a public or private "How to learn UE4" site. As I imagined the structure and rhythm of the class, it seemed too far afield. I don't doubt that it could be interesting, but it would also necessarily distract the students from participating in the communities, forums, and wikis that are already out there. If some students express strong interest in it, I could bring it back as optional, but I don't think I'd really miss it if it were gone.
I am obligated to somehow interpret my students' project-based learning experience honestly into a grade, so I decided that the most clear and direct way to do this was to have them chase MacGuffins. Students earn MacGuffins for satisfactorily completing Angry Whatever and each project iteration that we endeavor. They can also earn a MacGuffin for completing an achievement, of which I currently have two: one is to participate in a game jam such as Ludum Dare; the other is to present at the 2017 Symposium on Games in Academia that my Serious Games Knowledge Group will be hosting in November. I will probably think of others as the Summer continues. If a student does all the expected work of the course satisfactorily and completes an achievement, they get an A. For each step down (or, equivalently, each MacGuffin they did not find), it knocks down one letter grade. This sounds fair to me: do only the in-class stuff, and you have done Very Good ("Well", natch). Skip an iteration, skip the intro assignment, or royally screw up someplace, you did Average. Anything less is Poor.
This plan leaves me with a bit of prep yet to do, such as designing the specifics of a Scrum tutorial and perhaps making some UE4 tutorial videos, but overall I think it is sound. Even if I simply left this alone until the semester started, it's enough to get everything rolling. That's good, because I think it's time for me to turn my attention to the revisions to CS222—which is moving to a Tuesday/Thursday schedule, affording some potentially significant changes—and retheming my game design colloquium around or upcoming project. More about that in later posts. Thanks for reading!
Tuesday, July 18, 2017
Background and preliminary planning for the Fall 2017 Game Programming Course
It's that time of year where I design my courses for the Fall and share my thoughts and plans on my blog. This year, however, I have been having some difficulties, and so in the spirit of reflective practice, I've decided to write about some of them instead.
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:
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.
Subscribe to:
Posts (Atom)