Teacher Teach Thyself


It’s a well-worn idea, but teaching sure does provide a bunch of opportunities for learning. Over the last semester and preparing for this one there have been at least three fairly major approaches to making my own work that were heavily influenced by my teaching:

Twine. I had the students in my game design studio use Twine as their first game making tool to explore how they could work with (or against) it to recreate ancient Greek myths. While the students, disappointingly, pretty much universally hated Twine, their hatred pushed me to work with it myself to see if I could figure out why or, more important, how I could use Twine in a way I found interesting. That led to making Burnt Matches – which was in part a game about responding to a game jam we did around the documentary Into Eternity, but was also hugely about learning about how to incorporate JavaScript and Twine macros into my understanding of how to make games in that environment. It led to interesting work, I think, and I even incorporated some ideas I saw in student projects into the final product. If I hadn’t been teaching Twine (and reacting to my students’ reactions to it), I don’t think I would have pushed myself so hard to figure out an interesting angle on it.

jQuery UI. I teach web programming courses in my department as well as game design, and one of the tools that comes up a lot is jQuery. I’ve always been fascinated by jQuery UI, mostly because of it’s .draggable() function that allows you to make pretty much any element on a web page draggable with the mouse. Because I’ve spent a fair bit of time looking at that library, I realised comparatively recently that the project about user interfaces (currently called It is as if you were doing work) could actually be made in jQuery UI. There’s a nice feeling of appropriateness to use an actual library for generating productivity oriented interfaces (with sliders, buttons, dialogs, etc.) to make a game. In the past I’ve always specifically used game making environments or libraries to make my work (understandably), so there’s definitely something fun about using a different set of tools, and tools that are appropriate to the subject matter of the game, to make this one. Naturally, had I not already been using jQuery UI I presumably wouldn’t have used it for this project. (Although I have to say it’s been a huge pain in the ass getting the widgets to play nice so far.)

GitHub. One realisation I’ve come to with our students over the last while is that they really should know a version control system like Git in order to manage their structuring of work, their backing up, and their collaboration. At present we don’t teach this in any of our classes, so I’m moving toward teaching Git/GitHub/GitHub Desktop. Prior to deciding this I haven’t really used version control outside of in my undergraduate Computer Science degree and when collaborating more recently with Jonathan Lessard on Game Studies. So I’ve been learning Git for the last while to teach it and, unsurprisingly, I’ve been using it for my current projects. It’s been helpful (and makes me feel like a “real programmer”), but one particularly nice outcome is that it will allow me to trivially open source my games on release, which is something I’ve been meaning to do, but just uploading a .zip of the project feels so crass. Along with that, it should make including process materials with projects much easier too, as I can just have a folder of process material/documentation in the repository and have that be part of the release as well. Perfect.

So that’s probably more than you needed to know about some technical minutiae of work I’ve been doing lately, but I do think it’s nice that you this out of teaching along with the other obvious “good stuff” like getting to see students improve, seeing impressive projects grow, and so on.


6 January 2017
← next words previous words →