I Am Not a Teacher

…anymore. Specifically, I’m not teaching the game programming course again this autumn, as I had hoped. I was interested to do it, but Mohawk was a bit tight on funding for sessional instructors this year, so one of the regular professors took over.

It is unfortunate for me, as I had a number of ideas for improving the course and my framework that I wanted to try. On the other hand, it means I still have my free time—teaching required me to go to Mohawk twice a week for 4 hours in total (and transportation and preparation time on top of that) while still maintaining full hours at my primary job at Mac, which was draining. Not that I’m making much productive use of my free time, but still… it’s nice to have.

I think this may be the last time this course is taught at Mohawk, at least using the current platform (OpenGL via C++). I know that Mohawk is restructuring its Software Engineering program (for one thing I believe it’s going to be renamed to “Software Development” which is just as well; I don’t think we had much actual engineering discipline taught) and as part of that C++ is being phased out. Depending on when that happens (or happened) this course may yet be taught once more, but once only. After that, it will either have to change (perhaps to C#/XNA?) or be retired.

Incidentally, I taught Assembly Language the previous year and that too was phased out. I’m not sure if these changes are good or not. Although I feel C++ and even Assembly are important and worthwhile to learn (and I’m sure quality university programs will continue to teach them), Mohawk is focused very much on catering to the broad needs of Industry, and getting their graduates jobs. And the bulk of the jobs these days seem to be in Java or C#, and typically on a web platform. So perhaps overall it is the correct direction for the college.

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.

XNA 3.0

XNA Game Studio 3.0 was released recently, and I downloaded it. I had tried the original 1.0 release back in 2006, and found it to be interesting but somewhat difficult. At that time I hadn’t yet any 3D programming experience (my foray being with OpenGL later that year), and I think that was the principal barrier for me. XNA doesn’t have a fixed-function pipeline nor an immediate mode, both of which are much easier to get started with (someone agrees with me).

Interestingly the (recently released) OpenGL 3.0 spec was supposed to do away with both the fixed-function pipeline and immediate mode, but they were instead left intact and marked as deprecated. They’ll work for now, though it’s unclear how long they will continue to do so. This may eventually have some implications for those learning (or teaching) 3D programming.

Getting back to XNA, presently I’m trying to do something that’s trivial in OpenGL: draw points and lines in 3-space. I haven’t yet had any success, though I have some leads and a rough idea of what’s involved–it is, as I am wont to say, non-trivial.

I do rather like most of the other things about XNA though, now that I understand it better. One small detail that is convenient for me: XNA has not inherited the left-handed coordinate system of its ancestor Direct3D, and instead uses the same right-handed coordinate system as does OpenGL.

Follow

Get every new post delivered to your Inbox.