Education: The Game

Just a short post. If we think of typical university education as a game, it is horribly flawed. I'm going to use one abstract course as a test unit for this analysis.

The game starts with the player having some resources (including skills etc.) which they have earned from previous games. Hopefully they can remember all that stuff, because this game is not going to re-iterate over that material. Often they are at least told what resources they should have before starting this game. When the game starts, it's level after level situations where the player gains resources. They just are not told what these resources do and how much they actually have them, because this information is completely invisible. Often these levels feel like grinding. Grinding for random drops, but the player doesn't even know what is dropped.

Skip to the end of the game. The infamous boss monster, The Exam. Now the player is rewarded for having all those bits of resources they have gained. Most players go grind for resources in completed levels just to be sure. Some just run through the levels, and only start getting resources a few days before the boss fight. After the boss dies, the player has to wait a while. Then they are told whether the boss actually died.

Our education system is like a game where all meaning is packed to the very end. We just grind through the levels until we get to the end and only then it is revealed to us whether that grinding was useful or not. Would you play this game? If it takes 40 hours? Or you could just skip the grinding for permanent resources, do a quick grind for some one-time items and defeat the boss. You get the same reward but your character has gained next to nothing. The game doesn't really reward you for having a better character, only defeating bosses.

I think this needs to go.

Global Game Jam 2011

Last weekend was made of small amount of sleep and lots of game development. In about thirty hours we designed and implemented a game, Hamsters and Plague. It's a tile-based puzzle game about the survival of hamsters after a plague. You can find information on the game from our project page. I have also started a blog for future development and other related discussion.

Making a game in such a short time is awesome in many ways. Especially learning. I will try to make a proper post mortem on our project when I'm less tired (later this week) and post it to the Hamsters and Plague blog. Naturally it's also important for my research to have actual game development experience. I once again realized how hard it is to evaluate learnability of something made by yourself and our game definitely could do a better job. Which I hope it will do in the future if I have the time to develop it further.

I'm also thinking that something like this would be a really good way to teach programming and team development. A rather tight time limit does wonders to motivation, at least when the topic is one that interests everyone. While school environment doesn't support over-the-weekend courses very well, something similar should be possible. Maybe we could give students credit points for participating in next year's Global Game Jam.

Teaching Experiences - Revised

I have now given evaluations for my game programming course, and also finished my part of teaching normal elementary programming. That means I have also received feedback.

As stated earlier, the course was structured to be somewhat game-like. I had prepared one large example and taken snapshots of its development phases. It started out simple, with just drawing a ball on the screen, and expanded slowly towards a complete game. On lectures we followed the progress of this example, with each new concept adding new features to our game. Much like each new ability in a game allows a player to face new kinds of challenges. Each concept was introduced using carefully selected or made lolcats and sometimes simple diagrams. Then I proceeded to explain the concept, using a whiteboard to visualize what I was talking about. Then we looked at the cool things that can be done to our game using that concept. The final step with each topic was to give the students a new feature they should implement to the game.

This was repeated with most topics. Some topics like comments, which are not very cool, I just explained and demonstrated. The pace was set so that during any given hour there would be at least some programming for the students to do. This method of teaching was appreciated in the feedback I got for the course. Feedback in general was positive. The things I should pay more attention to in the future were the order of some concepts, and overall pacing of the course. I could have also documented the example code a bit more. For some reason the students really liked my lolcat-infested lecture slides. I don't know if the slides were very useful, but if they were memorable, there's always a chance they helped in remembering the actual concepts as well.

Like games, the course gave the students their first success early - I had them make something interesting and impressive (yet simple) on the very first lecture. Similarly, the course structure was very gamey. Students were given new "abilities" and then immediately presented a chance to use them. Need to make game objects interact? Here's collision detection to help you! This way they progressively leveled up as game programmers. Course work assignment was also one long project instead of isolated homework exercises. Relatively long anyway, 100 hours was reserved for working with it. Most of the students who passed the course reported less hours though. The work was divided into phases, but I timed them a bit poorly. The first deadline was too late into the course, and the remaining two were both after lectures had finished.

If I get the chance to teach more game development courses, I think I should look for ideas to make them even more game-like. I had one quite good interactive lecture experience while teaching elementary programming. Our topic was designing programs. I chose a fairly simple problem, one that was easy to represent and understand, and then started asking the students how they would make a computer program to solve it, step by step. So instead of telling students how programs are typically designed, I went through the process with them instead. This is something I should do with a future course. Present initial conditions and then work with the students to make something of them.

Hopefully our department sees the value of game programming in teaching programming. My current evidence suggests it can be very helpful in motivating people. I also think teaching is valuable experience towards making applications that are easy and fun to learn.

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.

Foundations of Digital Games 2010

Another busy week behind. Exactly a week ago I was on my way to California, and more precisely the Foundations of Digital Games 2010 conference in Monterey. Here comes the aftermath.

Considering my own research, FDG2010 was mostly useful for the game design point of view but not that much actually. There were some interesting presentations and conversations with people about experimental game control methods, and finally some proper information about Kineckt. However, considering teaching game-related anything or game-aided education, the conference was much more useful for me. The details about the conference will be available later somewhere in the internet, so I'll just post some collected thoughts.

There was a plethora of sessions about inspiring more interest for computer science by using games and game design as part of CS education as well as to make potential students familiar with game development before college. I'm not exactly sure as to what the situation is here in Finland but I guess we can always use more interest. Probably the single most interesting session was about Microsoft Kodu, which is a visual game programming language, easy enough for children to learn. In the II City project, we are interested in using focus groups to create ideas for games, so you can probably see where this might be going. Yes, we can use Kodu to familiarize non-programmers with game dev.

Another thing I picked up were a lot of ideas for teaching a more serious game development course for post-grad students. This topic was presented in several sessions, and also discussed randomly throughout the conference. I'm mostly interested in doing this as a project-based course, and if possible, as a cooperation between our university and the department of industrial design in the University of Lapland. Bringing in artists from another university can get around the problem that CS students are not expected to have artistic abilities (and therefore we can't require them). This was how I had thought to do it to begin with, but discussions in the conference made me more confident. We can do this.

It was also nice to see a good glimpse of all the work being done in educational games, the Holy Grail of e-learning. There were quite a lot of projects presented that taught students computer science concepts in ways more interesting than plain programming practice. Using these kinds of games for teaching the basics of programming is an idea worth contemplation, especially if people are having a hard time grasping some of the concepts in our introductory course (I haven't asked yet, but in August I'll probably see for myself anyway). Of course, many a presented game taught other concepts than CS, such as how cats see the world.

Finally, game design was definitely not a forgotten topic. However, since there were always two sessions in parallel, I had to make choices, and because of my job, I ended up selecting all the education related sessions. So, like other people, I will have to check the interesting game design presentations when the presentation videos become available.

Jetlag and all that jazz aside, it was a good experience for a first conference trip. Although I definitely didn't expect that it would actually be cold in California. The wind was a real killer, especially on Saturday. In addition to huge amount of inspiration, I got to meet a lot of awesome people. Hopefully I'll be able to visit FDG2011 if it gets organized, wherever it might be. Oh, and the conference center had some serious Norman Doors - I took one pic, which I'll try to post later when I get it on my computer.

(During the trip I also had a lot of time to read books, so book reading report is up next)

Moving to Education - First Steps

Lately I've been working on course material, including sample code and lecture slides. I will be teaching my first course in august, and the topic is Introduction to Programming Through Game Development. It's a trial, an intensive course with the goal to teach students basics of programming and basics of game programming. We're hoping to inspire greater motivation for students to learn programming.

In my research, I'm taking part in rethinking usability. In education, I feel I should take part in rethinking teaching. I haven't fully thought out my teaching plan yet, but I will pursue active learning by having the students work on their own (simple) game projects throughout the course, instead of artificial exercise assignments. Of course, I'll have to do some lecturing since it's a basics course, and I'm specifically required to teach them the topics covered in our standard Introduction to Programming course. My initial inspiration for how I might do this comes from Ian Schreiber's blog Teaching Game Design, and for more inspiration, I think I'll revisit What Video Games Have to Teach Us About Learning and Literacy (by Paul James Gee).

I'm trying to avoid traditional lecture material. Instead of factual slides, I've made a relatively small amount, using mostly pictures that are fun and reflect the topic I'm talking about. More specifically, I'm using a lot of lolcats - we all have our personal quirks, so get over it. Slides aside, I have created an example project and taken snapshots from its source code throughout all phases of development so I can throw my students some practical examples to explore and play around with. I pretty much think that's all the material I'll need to pull this off (of course, we have a textbook as well, so students can look there if they prefer more reading).

My thoughts for this one are not exactly radical but it's a start. If the course goes well, we can probably try some more advanced courses in game programming, and then I can scrap the lecturing part altogether. Programming is fun. Game programming more so. Teaching game programming should also be fun. Looks like the course will be Introduction to Programming, Game Programming and Obscure Internet Humor. All in the name of science and creativity.

An interesting sidenote: Using pictures that are far from obvious is (sometimes) better than using ones that explain a thing really well. When I was leaning Japanese Kanji, the ones I found easiest to remember were the ones where I had to think for myself how to interpret the character. Humans are proud of achievements - if we make sense of something non-obvious, we want to remember our explanation and spread it to others. So maybe if students understand how this picture reflects doing operations to elements of arrays, the whole concept of arrays sticks better.