
Secrets of the Masters - An Algorithm for Learning to Program - agavin
http://all-things-andy-gavin.com/2011/09/11/video-game-programmer-method/
======
dmbaggett
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.

------
sophacles
_If you don’t like to read, either learn to or find yourself a new career._

This is so true. About two years ago I realized that a significant chunk of my
time was reading. I would read howtos, api docs, in depth analysis of things,
both directly related to my job that day and programming in general. I did an
analysis and realized that I was easily reading the equivalent of a 1000 page
book a week. I have since taken efforts to both increase the quantity and
quality of my reading, and it has paid off. I actively seek out topics I am
ignorant of, and deeper articles on topics that have interested me. I also try
to look at tools I don't expect ever to use. In all these cases I just read.
This has given me a breadth I hadn't enjoyed before, and I suddenly have
access to a whole new understanding when I and my co-workers encounter
problems -- "hey let's look over here for ideas, that field has encountered
similar problems"

 _DO NOT EVER LEAVE THE COMPUTER IF YOUR PROGRAM DOES NOT RUN._

I disagree with this. There is a point at which I need to just be done with an
issue for now. This give me a chance to background process the problem. The
number of times the answer "just comes to me" while doing something else has
given me a certain amount of faith in temporarily walking away from the
problem. A lot of people call this the "shower solution".

~~~
Goladus
I have, on occasion, intentionally left a program in a state that would
generate a compile error to give me a place to start the next day.

Edit: Incidentally, I do agree with the sentiment in the article, though,
which is that you should develop in manageable chunks and avoid derailing so
far from a working program that you can't see the results of your work within
a reasonable amount of time.

~~~
pointyhat
I tend to replace them with assertions that blow up the tests. I never leave a
compile error.

Usual format:

    
    
       Assert.Panic("not finished");

------
astrofinch
I'm really glad to see someone discussing the actual mechanics of how they
program. We need more arguing about which mechanics are the best and less
arguing about which tools are the best. I'm sure the top 1% of programmers are
the top 1% because of their awesome mechanics, not their awesome tools.

In my experience the quality of your debugging facilities determines a lot of
how important it is to program by accretion. If you are getting really high
quality tracebacks when there is a bug, it tends to be safer to add a lot of
code at a time.

For me the Holy Grail has always been for my program to run on the first go
without any bugs. I have achieved this for small Python scripts. To write
conceptually correct code on the first go requires a much higher level of
mental engagement, but it is far more satisfying than working by trial and
error. (I guess it is probably all right to have trivial bugs like a forgotten
import statement or a misfired library call.)

------
wccrawford
I guess I expected something more secret. That's pretty much what I do, except
for the 'don't leave the computer if the program doesn't run' bit. When the
program doesn't run, and I'm pulling my hair out that's the -best- time to
leave the computer. Go get some fresh air, a soda, maybe a nap... Anything to
take your mind off it long enough to think straight again.

~~~
agavin
There are no magic bullets here. Becoming a great programmer takes a LOT of
time and effort. It's fun and rewarding, but not exactly easy. :-)

