This semester, I taught a class that I am extremely unqualified to teach. It was super fun!
We are a relatively small university and a small CS department, so offering “fun” classes for our undergraduate students can be challenging, especially if such “fun” courses do not align well with anyone’s research. Despite many students getting into computing because of video games, we did not have a class in game development (we do have a graphics class, and some AI classes do AI for games, but no actual Game Dev class). Anyway, I decided to fix the gap and teach a GameDev class. Did I mention it was super fun?
My only “qualification” is two platformer-style games I did back when I was in college. Being a nerdy kid, one of these games was about a programmer in a distorted computer world exterminating bugs with a bug spray. This programmer eventually meets a girl, and his world gradually becomes normal… This game was meant for my then-girlfriend to play (geeky, nerdy introverts are weird! I could have just bought her some flowers!). Needless to say, I did not account for the fact that my girlfriend was not a gamer and failed miserably at passing even the first level of the game. Long story short, the girlfriend is now my wife, but flowers probably would have worked better anyway.
Anyway, as far as the class is concerned, I was not going to do a hardcore lecture-style course partly because I do not know much about game development to fill a semester’s worth of lectures and partly because I wanted to give students sufficient time to unleash their creativity and build some games. So, I did a crash course on some basics and then let students have fun making games in teams of 3-5 people.
In the first seven weeks, we learned the basics of 2D game development. We looked at managing game worlds and learned to think in discrete steps to simulate the world. We learned sprites, sprite sheets, animations, some particle effects, and doing backgrounds with parallax effects for faking depths. We discussed how to capture and handle input from players (and ensure all movements are “smooth” even when the frame rate fluctuates). We looked at ways to organize code better, such as using Entity Component System (ECS) architecture/frameworks. We also looked at proper ways of managing and loading game assets and scenes. We learned about game physics and how to use physics engines in our games.
As these initial weeks of the class progressed, I was making a small space-shooter-style game live in front of the students. Although I did prepare all the code in advance just in case I ran out of time or forgot something. The game is nothing fancy, but it was still fun to make something that can be coded more-or-less live in class with some AI help for creating graphics. You can see a short demo here.
For the rest of the semester, the students mostly worked on their group projects. Each group was supposed to make a playable game by the end of the semester. I was not mandating any particular game engine to give the students more flexibility to self-study and learn independently and pick the technology they prefer. However, I did suggest using libGDX, an older and a bit outdated engine, for people more comfortable with Java (they study Java in at least a few prior classes). Godot was the engine of choice for students who are more comfortable outside of the languages we cover in other classes. For example, two teams coded their game in Godot with C#.
Every week, groups made their progress demos, allowing for feedback from the class and plenty of discussions on making the games better and more interesting. I also covered several additional topics during the second half of the semester — some basic 3D and a bit on the video game history.
As the semester got to an end, the teams showed their games at the department’s end-of-semester poster symposium (which I happen to organize every semester). Here are a few demos of the games students made in half a semester’s worth of time.
We had one isometric bullet-heaven game where a player (or two players) needed to find an exit from a procedurally-generated level before being overrun by the enemies.
Another game was a rage-platformer that is very difficult to beat, as it makes characters go back and forth across the level to collect different items needed to win. The game also had quite a few rage-inducing surprises, like invisible blocks, or terrain/platforms that disappear when you step on them, etc. It is also notoriously difficult with controls (on purpose); for example, jumping strength depends on how long you hold the jump button, so you need to prepare to jump way ahead of time.
A platformer-style golf game. This one may look a bit simple, but it took a bit of time to implement and tune the physics right. Also, it is not that easy to play, and I am really bad at this game…
We also had a team that decided to hand-draw the animations for the characters in their platformer game… and then code/time these manual animations into the game.
Anyway, I think I will teach the class again next Spring. This was a fun experience for me; I learned a lot of new stuff for myself. We also had a ton of fun being creative in class with all the game ideas, even though we only had time to implement a tiny fraction of them. The students appreciated the freedom they had in this course — I did not bother with exams or quizzes or homework; the only assessment I had in class was the progress on the games (checked weekly in a casual manner), and the final result presented to the department at the end-of-semester poster symposium.