I coded the first two Crash games with Andy (and, on Crash II, with two other really awesome coders as well). I couldn't agree more with the recommendation of picking an old-school game and setting out to copy it. When it comes down to it, I pretty much learned to program games by, uh, programming games. Crappy ones, initially, but eventually pretty good ones. Then, an "A+" title at Naughty Dog.
I remember "discovering" double-buffering in high school when my friends and I were creating an Archon clone for the Atari ST (a 68000-based machine). My sprite was tearing and flickering all over the place; I then realized that's what double buffering was for. Sort of in the spirit of the modern (and massively overhyped) hackathons like the one that's going on in NYC this weekend, we'd stay up for 48 hours straight coding. Snow days were the best: you might get 4-5 whole days of hacking in! Man, we learned a lot coding clones of old games.
We made a PacMan clone with 100 levels. Sure, it was just a PacMan clone, but we had incredible fun making it, and it ended up being not only a great lesson for me in game programming, but an early lesson in how to structure a "big" program. ("Big" in quotes because it was only big relative to other stuff I'd written.)
And lest you think this kind of thing went out with the 16-bit era, I met a 13-year-old earlier this year who made a very convincing Pole Position clone in Flash. I'm totally hiring this kid when he's old enough for me to legally do so... unless PG funds his first startup when he's 15. :)
So, yeah -- if you want to learn how to code games, start coding a 2D sprite classic from the 70s or 80s and, most importantly, finish it. It might take you a year or more, but by the end you will have learned a lot. Then do the same thing with a more modern 3D game (a Doom-style POV game, for example). You will reinvent a lot of stuff, but you'll really know it cold. And these little games make great portfolio items that will help you land a job on a good game development team.
I remember "discovering" double-buffering in high school when my friends and I were creating an Archon clone for the Atari ST (a 68000-based machine). My sprite was tearing and flickering all over the place; I then realized that's what double buffering was for. Sort of in the spirit of the modern (and massively overhyped) hackathons like the one that's going on in NYC this weekend, we'd stay up for 48 hours straight coding. Snow days were the best: you might get 4-5 whole days of hacking in! Man, we learned a lot coding clones of old games.
We made a PacMan clone with 100 levels. Sure, it was just a PacMan clone, but we had incredible fun making it, and it ended up being not only a great lesson for me in game programming, but an early lesson in how to structure a "big" program. ("Big" in quotes because it was only big relative to other stuff I'd written.)
And lest you think this kind of thing went out with the 16-bit era, I met a 13-year-old earlier this year who made a very convincing Pole Position clone in Flash. I'm totally hiring this kid when he's old enough for me to legally do so... unless PG funds his first startup when he's 15. :)
So, yeah -- if you want to learn how to code games, start coding a 2D sprite classic from the 70s or 80s and, most importantly, finish it. It might take you a year or more, but by the end you will have learned a lot. Then do the same thing with a more modern 3D game (a Doom-style POV game, for example). You will reinvent a lot of stuff, but you'll really know it cold. And these little games make great portfolio items that will help you land a job on a good game development team.