Friday, October 1, 2010

Teaching Experiences - Game Programming Course

As I mentioned briefly, this Autumn I was teaching a course called Introduction to Programming Through Game Development. It was a short short course consisting of roughly 30 hours of combined lectures and guided practice. The idea of the course was to try out a new method for teaching basic programming. Unsurprisingly it was targeted to students interested in game development. Today I had the last guided session. Final results of the course will be evaluated once the students have turned in their assignments. For now, I will share some thoughts I had about the actual teaching.

Cramming basics of programming and basics of programming into one course is a lot of things to teach. If compared to our department's normal elementary programming course, the amount of topics is most likely doubled. The saving grace is motivation. However, in retrospect I should have probably reserved more time for the basics of basics. This time I got away with it, if only because everyone actually attending the course knew at least something about programming. Although this also means we didn't exactly reach our intended target audience. The first note to self: the course needs to be longer or some topics, no matter how useful they would be, need to be dropped.

The idea that motivation is higher when the topic is truly interesting is not surprising. From some comments, and some impressions I had while teaching, the course did seem to embody this idea. Our topics were more advanced and they were introduced on a quicker pace. Most people were still able to keep up. The course implementation suggests that those who didn't should have come up to speed on their own time (around 10 hours per week were scheduled for independent learning). It is safe to say however that motivation is clearly not enough to make this really really work as an introductory course.

My teaching paradigm can be summarized into a few words: "Provide impressive results early and often". Students on a programming should get their hands dirty within the first hour. This is not unlike games - the player needs to achieve something within the first five minutes or so. Drawing objects on the screen is in fact very easy when using XNA, so this requirement was definitely met. This I found to be in general a good thing when teaching game programming. Results are highly visible. Especially in the beginning. Once they know how to make a sprite move, the students are hooked. Then it is possible to move into the nitty-gritty of programming for a while. When they start to get bored again, it's time for more impressive stuff.

I still need to work a bit on this almost game-like course structure but I do think it definitely works. Starting with the easy stuff might sound like the way to go, but I think it's better to go for the impressive first even if it is a bit harder. Another really good thing about game programming is teaching object oriented programming. It becomes a lot easier if the objects are actual sprites on the screen. You can almost touch them, that's how concrete they become. OOP in general is one of the harder programming concepts to grasp but also one of the most important. Therefore it's really good if we can make it more accessible. In game programming it's also quite impossible to get very far and stay sane without using OOP.

To summarize, I think my teaching ideas are sound in principle but I need more experience. This course was just an experiment, but we're hoping to make it into a real course in the future. This will be my chance to improve it further, and of course improve my teaching at the same time. In the meanwhile, I'm teaching normal elementary programming for the next ten weeks, which will be another chance to improve my teaching abilities.

Next month I can follow up on this after seeing the assignments and feedback from students.

No comments:

Post a Comment