…CONTINUED from PART 2. Or start at Part 1.
Some kid is always asking me, “I love video games, how do I learn to program them?”
First of all, a warning. Reaching the skill level to be a professional video games programmer takes years. There are no shortcuts. You can not possibly go from nothing to professional grade skills in less than perhaps 2-3 years — and for that you’d have to be an uber-genius — usually it takes 5-10.
The good news is that you can start very young (8-10 — I started at 10) and you can do it on your own with common equipment and readily available information.
There are two basic approaches: home training and school. And while I personally recommend both, I’m going to use this post to give my own “origin story.” In followups we can apply these lessons to the present (programming itself hasn’t changed all that much in 30 years — there are just more libraries).
[ BTW, if you’re new to the blog and wondering who the hell I am in this context, click ]
Rewind to 1979. Some of my favorite things in the world were Dungeons and Dragons and arcade games. I was really too young to actually play D&D accurately, but I loved reading the books and modules (besides my regular diet of fantasy novels). I went to the Apple Store (not actually owned by Apple or nearly as glamourous as they are today — in fact, the owner resembled Gandalf) and saw the game Akalabeth running on an Apple II (not a + or an e, but an old school II). Boy did that set me to dreaming!
Then in 1980 my science teacher brought into class a Heathkit H8 her husband built (yes built). This early computer ran a lousy version of BASIC and possesed the world’s worst storage device: the audio tape drive. Actually punch cards were worse, but with the tape drive, saving your program bordered on impossible (at least for the sharing audio tapes with the rest of the class) and so you had to type it in repeatedly. We were given a single mimeographed sheet of paper with the BASIC commands. I read this a couple times and then wrote out longhand the first draft of a text-based RPG where you wandered around and fought orcs and trolls for gold and tretchure (this is how I spelled treasure at 10). During lunch I typed in and debugged the game, editing my paper copy as needed. I used my friends as beta-testers. It may seem overly ambitious to try and recreate D&D as one’s first program, but it illustrates the programmer principle of: program what you love.
Then my best friend got himself a brand new Apple II+ (just released). This was a slick update of the Apple II. It had a whole 48k, came with BASIC, and was often (but not always) accompanied by a 143k floppy disk drive! Low low price of $900 just for the floppy drive! In any case, the II+ was so much more awesome than the Heathkit. It even had graphics!
So I began pestering my father for an Apple. This took 9-10 months of continuous harassment — the machine was expensive — and all sorts of creative techniques to convince him. I offered to mow the lawn for free. I explained how various accounting software would make balancing his checkbook a breeze, etc. Once I was victorious (Jan 1981) we got the accounting software, but he never used it, leaving me to my own devices on the machine. And I think I kept getting paid for the lawn. Still, this episode illustrates another important programmer principle: persistence.
After the Apple arrived, I spent nearly all of my free time (perhaps 6-8 hours a day) on the thing for years. This is essential. You must offer up blood onto the alter of the programming gods. Principle: sacrifice. I used this time in many ways. I played a lot of games. I used every piece of software. I taught myself to program. I hacked. Principle: market research. But I couldn’t afford as many games as I wanted and in those early years the available library was small, so I was always trying to make my own.
I wrote totally lame versions of nearly every arcade game ever made. In BASIC at first (we’ll get to the issue of environment later). I would generally spend a day or three banging these out until they were marginally playable and then move on to new projects. Lesson here: practice. I chose more and more ambitious games and would use each one to teach me something new. I did this in incremental steps, mostly 1-2 day projects. By way of example, I might upgrade something or I might add a load/save system (requiring learning about I/O). My early games didn’t have much in the way of collision, later ones did. I started with text, then moved up to lores graphics, then highres, then shape tables, then bits of assembly language subroutines for blitting. Principle here: baby steps.
Baby steps are incredibly important. You can’t learn everything there is to know in computers in one shot. Each little area takes multiple projects and days — at least — to learn and master. Take file I/O. I’m sure I got something up and going the first day or two back in the early 80s when I decided to add a load/save system, but I was still learning about file I/O 25 years later on Jak 3 (of course then I was inventing new ways of doing stream I/O, but it was learning nonetheless). Your first pass might work, but often you barely understand any of the principles involved.
You have to start simple, build up blocks, and go from there. That’s why interpreted languages and text programs are a good way to begin. You need to learn about variables, scope, and flow of control before you can jump into 3D graphics. And forget about complex unforgiving environments like C/C++ or assembly to begin with. Those come later and are just one more thing to spend a series of baby steps on. Just learning about makefiles or projects and compile options could stop a novice dead. So don’t — yet. Each task (and thing to learn) should be broken into some chunk that only takes a couple days at most to digest — or at least make some headway on. This leads to a virtuous feedback loop of progress and learning.
I kept writing those lame little games for about 3 years (100s of them). Of all my friends with computers (we all programmed in that era because computers didn’t do much if you didn’t program) my games were the coolest. I used them to invent all sorts of excuses to develop new skills. I wanted to learn about interpreters so I made an engine to allow the creation of text adventure games using a custom scripting language. Once I got this going I upgraded it to graphic adventures, which proved to be a perfect excuse to implement an idea I had seen in the Sierra games where line drawing and fill commands were used to compress images to a fraction of their raw size. On the Apple II a raw graphics screen was 8k. So a floppy only fit 17. A normal compressor (ancestor of zip) might squeeze this to 3-4k but that is still only 30-35 images. This “save the drawing commands” style made them a fraction of that. But for it to work I not only had to create the “renderer” (including an assembly fill routine) but I also a whole “paint program” to allow the recording/creation of these proprietary images.
However, each of these sub-steps resulted in satisfying progress on its own. Principle: chunking. For example that fill routine. It took several days, and my mastery of recursion in assembly wasn’t the best so it left little corners unfilled, but it was cool in of itself. My first fill routine (in BASIC) took 5 minutes to do a fill, and the assembly one only a second or two. Plus, I was to keep using it in all sorts of programs for years (with improvements). Principle: reuse. Building on the tools you make is essential to programming.
In 1982, I met Jason Rubin. He also programmed. He was an amazing (by the standards of the time and our age) artist and his games LOOKED REALLY COOL. But they crashed a lot. Mine rarely did. From the beginning I hated crashing. Still can’t tolerate it. I have trouble leaving the keyboard if a crash bug is still outstanding. Principle: perfectionism. My programs also did much cooler “programming” stuff. They just didn’t look cool. When we combined our talents, things really took off! Our games now looked cool AND ran decently. Impressive stuff. Lesson: partnership. Not everyone can be good at every aspect of computers. Nor even of programming itself.
CONTINUED with Part 4 – School!
Parts of this series are: [Why, The Specs, Getting Started, School, Method]
Subscribe to the blog (on the right), or follow me at:
Andy: or blog
Or more posts on video gaming here.
[…] So you want to be a video game programmer? – part 3 – Getting Started « All Things Andy Ga… says: August 30, 2011 at 7:38 am […]
[…] Post navigation ← So you want to be a video game programmer? – part 2 – Specs So you want to be a video game programmer? – part 3 – Getting Started → […]
Assembly? That’s hardcore. I haven’t even fully retained the concept of binary code, and with all these other languages out there, it’s really hard to try at times.
And if hacking falls under market research, then I guess it’s not as malicious as most people would think. 😀
Thanks again. 🙂
There was no network. I got a modem early (in 1984!). Before then hacking was modifying other peoples software (often to remove the copy protection). But I no longer condone that (except as a learning exercise). I’ve bought 100% of the (commercial) software I’ve used since around 1989.
Also assembly wasn’t as hardcore back then (it still was). The Apple II had a microassembler and dissembler built into the ROM. The manual for the 6502 and for assembly programming came in the box with the computer. The machine only had about 230 instructions when you include all the addressing mode combinations. Without that it might have been 30-40. There were only a handful of registers and no caches, no pipelines. It was much easier to learn.
That’s interesting. I had no idea that assembly went through any change at all. I learn something new every day. So did it actually change as the functionality of computers progressed?
Assembly is processor specific. So, given that new processors have been coming out steadily for 40 years, it does keep changing. Now, there are architecture families, in that modern Intel assembly is descended from 8088 assembly, but there are vast new features. Each family: ARM, PowerPC, Intel, MIPS, etc has it’s own architecture. Each variant chip it’s own specifics. That being said, they are all fairly similar in principle. Mostly instructions move data from one register to another, or apply ALU/FPU operations. For example (add r1,r2,r3) might add the contents of r2 to r3 and put it in r1. The semantics of this vary a lot, but the basic concept of arithmetic operations is pretty consistent. Other things like branching, memory management, etc are a little more varied, and there are the complexities of advanced floating point and vector units.
I love hearing about the Heathkit H8. It has a kind of “In MY day…” to it that makes me smile. My father worked for RCA and in 1978 he taught me to program a really simple Lunar Lander game into his RCA Cosmac VIP. This picture spells it out pretty well: http://elblogdemanu.com/wordpress/wp-content/uploads/2008/02/CosmacVip.jpg
Lunar lander was one of my many “arcade ripoff” self programming jobs. In fact, I remember I used it to learn about shape tables (an obscure pseudo-sprite functionality in Applesoft BASIC). STs were so slow that the frame rate might have been 1 frame a second. Maybe 2-3. LOL.
Great article series, can’t wait for the next part! 😀
[…] …CONTINUED from PART 3. Or start at Part 1. […]
[…] replaced/supplemented by “need”). My first program was a text-based dungeon master (see here). If you want to be a video game programmer, there’s nothing better than a game. If […]
[…] TRS-80) in 1987 in plastic baggies. Besides wondering if any TRS-80 game had much cultural impact (Read my own Apple II guy origin story here!), the date is totally off. If he was talking about 1982 that would have been fine. But by 1987 the […]
[…] people supporting it who aren’t older than me (and I’m not a young programmer anymore, started in 1980!) Still, you can feel lots and lots of LISP influence in all the new runtime typed languages (Ruby, […]