Saturday, 21 February 2015

A curriculum for learning to code

The other day in a conversation with a friend she mentioned how her teenage son-in-law aspired to become a game developer, and mentioned what his college plans were. Rather than go off on a side-track about the work-life balance issues experienced by game devs, my main reaction was to emphasise that one does not learn to code in school. If one hopes to develop any skill at it, it should be first and foremost a hobby and a passion, which formal education can supplement and refine (by imparting such things as design patterns and best practices, without which the pure hobbyist is likely to produce messy and inelegant code).

A 15 year-old wanting to start down the path to game development, I said, should begin by writing a Snake or Tetris clone, the skills for which can be picked up within a couple years, and would give a solid base for growing as a programmer from that point on, depending on what direction he wanted to go into.

Upon further reflexion, I think that this advice is a bit too blunt, but the basic idea—learning to code by writing progressively more complex games—is a pretty solid concept. But Tetris and Snake are a bit too hard to be considered beginner projects. Below I list a more realistic progression (which I might try with my own kids when they're big enough), which does grow with one's ability as one learns how software works. Of course it's not meant as a rigid path—if the passion is there to explore a given direction further (like writing interactive fiction with Inform, which might well appeal more to some personality types keen on fleshing out a fictional world, as opposed to moving on to Asteroids, which requires learning trigonometry), then that's what one should do. It's better to let one's specialisation (and one must specialise at some point) be determined by passion (for music, graphics formulæ, networking protocols, etc.) than anything else.

Here then is the basic progression I would propose one set out for oneself, as soon as one starts learning a programming language. Each project can be expanded on and have features added for as long as the student feels inspired to do so.

  • Guess a number. Basic algorithms and input/output concepts.
  • Hangman. More interesting / complex algorithms. Can begin life as an interactive console (scrolling up) and then upgrade to using ncurses or an equivalent to function on a fixed ASCII screen (including an ASCII art hanged man).
  • Sokoban. Introduction to graphics. Rudimentary collision detection (synchronous with player input). Beginning level design and storage.
  • Snake and/or Tetris. Introduction to the game loop. First version can be ASCII based, then can branch out into 2D graphics (or 3D, for the determined and impatient). Basic collision detection. These games could be long-term projects, adding in music, high score lists, etc.
  • Asteroids or anything that involves animation (a slot racer or side scrolling-shooter would fit the bill as well). Learning about how geometry, trigonometry, and perhaps even physics models impact animation. More complex collision detection, and asynchronous input.

The last item may be a hard sell, since the programmer has enough knowledge to branch out into different areas (a top-down RPG, Zelda clone, or platformer, for instance), and might not be interested in something like this, which can be quite complicated to code. However I include it as part of the curriculum because I think getting a feel for this maths-heavy part of animation programming is an important thing to be exposed to, if one wants to be a game programmer.

Any programmer who has written the above games has the basic skill set he needs to go forward with whatever kind of project he chooses to set for himself next. Hopefully along the way, along with from-scratch programming, he's naturally been exposed to a few APIs (ncurses, Java2D, etc.), and can, whatever ambitious project he sets up for himself next, figure out on his own which gaming library meets his project's needs, and can go about learning it without too much trouble. (It is not unlikely that porting that old Snake or Asteroids clone over to the new framework will be the first step in learning his way around it.)

Of course it's also necessary to do some outside reading in order to learn how to use programming language features, how memory management works, and how to implement all kinds of different algorithms efficiently. But the idea here is that the needs of the projects are what govern the learning, rather than taking a series of books and tutorials and working through them, as if they were the ends in themselves.

So that's my basic, generalist curriculum. I imagine others have already come upon this same idea independently, but I thought I'd share my take on it, for what it's worth.

It could of course be adapted for someone who only cares about creating fighting games, or RPGs, or what have you, but the course proposed above should, in my opinion, produce a self-confident programmer who can apply his skills to a broad range of things. More importantly, game programming requires a lot more skill and application than plenty of other forms of programming (web, database, utility applications, etc.) which, while not as fun, can also one day pay the bills quite nicely. Of course, knowing the right tools and languages, to introduce to the right person at the right time, in order to keep them engaged and enjoying the programming process, is another part of the puzzle. I look forward as a father to seeing whether I can finesse that for my kids, and transmit to them some of the fun that there is to be had in computer programming.

Posted by jon at 10:03 AM in Programming 
« February »
Older articles
Non enim id agimus ut exerceatur vox, sed ut exerceat.