I love teaching kids to make video games. I’ve done this for quite awhile now, using a lot of different languages, including Python, Scratch, the JavaScript/Processing port at Khan Academy, the Greenfoot Java IDE, full Java with Eclipse and the once-promising XNA platform in C#, killed in its youth by short-sighted Microsoft executives (though resurrected as open source code as Monogame). There is a lot to recommend teaching coding this way. Kids love to play video games, so it makes sense they’d love making them. And starting by creating a sprite and moving it across a screen is way more interesting than another “Hello World” program. But the more I do it, the more aware of the limitations.
One important limitation is that making a video game, much like making a website, is not entirely or even mostly a coding task. A big part of making a video game is actually graphic design. Much as they say there are really only a few basic plots in fiction, there are really only a limited number of different types of “actions” in a video game, especially a simple 2D one of the sort a student would hope to make. Once you get that working, it’s mostly about how your sprites and backgrounds look. Designing sprites and backgrounds is an interesting challenge in itself, but it’s a different skill from coding and a distraction from a coding class. Often I have to make hard decisions about how much time I want to let kids spend looking for or designing game sprites, because on the one hand the small number of sprites built into most gaming platforms is limited and quickly gets boring, but on the other hand I am teaching coding, not graphic design.
Furthermore, though these different platforms mostly make beginning a game very easy (with the exception of Java, which has a lot of hills to climb to even make a game window), often students quickly hit a ceiling when they start wanting to do things that the pre-designed built-in “move” and “turn” methods don’t let them do.
When they hit this limit, one of several things happens: some kids get bored and want to quit, some kids
doodle around and do the same thing over and over, and a smaller number of kids push against the limits of the platform. This can lead to some incredibly ugly code in a limited platforms – I’ve seen people build a scrolling platformer with Scratch, but it’s like painting your house with a nail polish brush, and the code is about as attractive. Other platforms have less of a ceiling; Greenfoot contains within it the full capabilities of Java, so theoretically you can do anything, but it’s a huge stretch to get from making a single-screen game with limited sprites and objectives to the sort of games kids imagine, with things like scrolling, jumping with gravity-like motion or different kinds of 3D.
So what’s the alternative? There’s always the “traditional” coding class, where students use Python or some other interpreted language to create text-based programs that say things like “Good job Jim you guessed the correct answer in 2 tries!” But as I argued in an earlier post, that’s exactly the kind of coding class that teaches everyone except natural programmers that coding is boring and not for people like them.
Physical computing, such as working with Arduinos, is definitely an area of potential here. I will be working with students making Arduino projects this year, and I’ll report on how it goes. As with games, physical computing involves working with things that are interesting learning tools in an of themselves but are not actually programming. More significantly, most Arduino programs, at least of the sort students do, are very simple, and may not touch on many advanced concepts. The difficult part of physical programming is usually the physical part. And anyways, you aren’t always in an electronics lab; sometimes you just have the computers to program with. So what else can you do?
I’ve been thinking about this a lot, and it came to me the other day: students really need to do is work with data. Real data, not the Northwind database or fake lists of names from the phone book. Data about the real world, like climate records, health surveys, demographic information, data that allows them to address real problems in the world. But where do they get the data? And how do we get it in a format that they can work with it?
I have thoughts about this, but it’s too much to add to this post. I’ll be addressing my ideas about how to get real data in the hands of students in future posts.
From the point of view of a “real” programmer, the answer is clearly no. At best they might generously allow that such a person is a “scripter” or some other diminutive. If a trained programmer with a computer science degree saw their code, the programmer’s reaction would probably be like 
If you have taken any programming class in your life, you’ve probably written a “Hello World” program. When I first learned BASIC, it looked like:
But then again, when we were kids it was a lot easier to believe. When I was a kid we played computer games on the Apple II++, almost all of them illegally pirated off pre-Internet bulletin boards we dialed into with modems like Matthew Broderick used in Wargames. Though we couldn’t write games like that ourselves, they used simple blocky graphics not too different from the blocks and circles we could draw after a few weeks of learning BASIC.
But imagine a student today trying to see the the bridge that goes from “Hello World” to games like Halo or Skyrim. When I was young, many video games were written by a single person, or at most a small team of three or four people. Kids today may not realize that a few people with a laptop couldn’t program Call of Duty any more than few people with a video camera could make Guardians of the Galaxy; both call for multi-million dollar budgets, enormous teams and expensive equipment.