Game Programming Course: A Postmortem

The fall semester ended a couple weeks ago, and so too the course I was teaching, “Modelling, Simulation, and Game Programming”. Overall I found it a great experience, and learned much about both programming and teaching. However, I have to admit that I am slightly disappointed in the results put forth by the students. Some groups did fairly well but others either did not finish their games or produced games lacking in features or polish.

When I took the course, we were given a “simple game engine” to use, which was the one included in the book “OpenGL Game Programming“. This is not a bad book, though neither do I deem it particularly good. It does provide a good introduction to OpenGL and some basic physics commonly used in games. However the so-called engine (I’d call it just a “framework”) provided is, in my estimation, rather weak. Among the problems were:

• OS-level details were not adequately hidden
• Mixing of interface and implementation (code was present in header files!)
• Using variable timesteps (thus no easy framerate independence)
• Not taking much advantage of OOP techniques

The course consists of 5 small lab assignments, followed by a group project. I noticed the problems even while doing the labs–the examples provided were difficult to follow, due to all the Win32 stuff being repeated in each one and a clear structure not being discernible. I resolved to come up with something better to use for our project, and wrote a new framework that addressed all the issues listed above.

When I was asked to teach the course I wanted to have the students use my new framework, and that part worked out very well. Although I didn’t have time to rewrite all the old example programs, I did write some new ones designed to drop into my framework. This made the code very short and clear, without anything extraneous getting in the way of the technique being demonstrated. In fact the minimum amount of code required to get an OpenGL-ready window on the screen is only 3 lines! Overall the students approved and found the framework very easy to work with.

Given this significant advantage, why did the resulting games not significantly exceed the quality of those submitted in previous years? I have identified a number of reasons, among them the fact that it was my first time teaching the course, and that my course materials were weak (I had to develop much of it along the way, as I didn’t reuse much of the previous professor’s materials).

However I believe the primary reason was that I gave the students too much freedom. When I took the course I put in a lot of time, probably well over 100 hours (that’s in addition to the in-class time of 56 hours). I learned a number of things independently that were not covered in the course. I was highly interested and thus motivated to pursue it on my own. When I taught the course I assumed that my students would take the same approach,  and so I adopted a lax, “hands-off” style of teaching. I wasn’t strict about the project proposals–although I warned some groups that their ideas would prove difficult to implement, I nonetheless allowed them to proceed. I didn’t demand periodic updates on their progress, with working prototypes. I allowed them to manage their own schedules and left it up to them to approach me when they needed assistance. All this was a mistake.

This is an optional course, so surely everyone was there only because they were really interested? Well, perhaps. But interest doesn’t always come with the motivation and ability to do work. And making fun games isn’t all fun and games; there’s a lot of work involved. Perhaps it would have been fine had the students already been accustomed to professionalism,  industriousness and self-directed learning. However during the previous 5 semesters they were taught that they can easily pass their courses without developing much of those traits at all. In short, the students were lazy. (I don’t entirely blame the students; this is a major problem I have with the college, but I’ll have to leave that criticism for another time.) Part of that laziness seems to stem from youth–most of the students entered college straight out of high school, whereas I was 27 when I entered college. This hypothesis is supported by the one student in my class who did follow my intense approach to the course (in fact I believe he did even more work than I did), who is also in his late 20s.

If I teach the course again next year (likely but not certain), I’ll attempt to rectify these mistakes.

Advertisement