So you want to be a video game programmer? – part 5 – The Method

…CONTINUED from PART 4. Or start at Part 1.

This post is presents an algorithm of sorts for learning to program. It applies not only to the fundamentals, but to all aspects, including the acquisition of small component skills. Thirty years after learning, I still follow the same basic procedure. To tell the truth, modified, it works for leaning most things.

Step 1: Goal. Invent some manageable goal that excites you (in a later context as a profession “excites” is often 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 it’s one of your first programs, make it damn simple. Copy some REALLY REALLY old and simple game like anything from before 1981 (PongBreakout, etc.). Truth be told, using text only for a couple weeks/months might not be a bad idea. Graphics just complicate matters. They’re awesome — and you’ll need them soon enough — but first the fundamentals, like variables, flow of control, scope, etc. Any individual task should take no more than a few days. If your goal is bigger than that, subdivide.

Step 2: Environment. All programming is done in the context of some environment, and you must learn about it. You need to start with a simple one. In my case it was mostly AppleSoft BASIC. For learning interpreted is good. Some decent starter environments today are Python, Ruby, Flash, Lua. DO NOT START WITH A LANGUAGE LIKE C. I will elaborate on this environment question in a separate full post, as it’s a large topic and highly religious for programmers.

Step 3: Research. This means reading. If you don’t like to read, either learn to or find yourself a new career. I’m serious. Reading separates the Neo Cortexs from the gibbering marsupials. I’m serious. Be a New Cortex. Your love of reading must be so extreme that you can stomach slogging through 900 page Library Reference Manuals (maybe not at first). Programming is full of details.

Step 4: Theory. Get out a pad of paper, a text file, Evernote, or whatever. Design what you are going to do. Later, you might or might not skip this step (and do it in your head), but it’s useful for the beginning programmer. You don’t need to write out the entire program, but you should design your data-structures and modules or functions. If it’s one of your first programs, you should hardly HAVE data-structures. You might instead write down the modes and loose flow chart between them.

Step 5: Code. Actually try coding your program. This is best done in an iterative way. My advice is generally to start with creating your core data-structures, and then the functions or methods that support them. Test each of these individually. Interpreted languages with a listener are the best because you don’t have to write test suites, but can just test the components as you go at the listener. Time spent debugging individual functions and groupings (say all the methods that belong to a data-structure) pays for itself 100-fold. I still do this. The less code you are testing, the easier it is to spot and find bugs. If you know that your functions are reliable (or semi-reliable) they provide robust building blocks to construct with.

Step 6: Debug. See above in “code” because they are heavily intertwined. Coding and debugging happens together in small loops. Again. The less NEW code you have to debug, the better. Debugging is hard for novices. Do not write an entire big program and debug it all at once. If you are using a language that syntax checks, check each function after you have written it. Fix the syntax errors (typos) and then test and debug the single function (or component of a program). Baby steps. Baby steps.

Step 7: Iterate and improve. Just keep adding things to your program to get it to where you want. Add a new feature. Improve an old one. Rip out some system and replace it. Add graphics. Upgrade them. Try to keep each of these changes as small as possible and test after each change. The longer it has been since it ran, the harder it will be to make it run.


I can not emphasize how important baby steps are. They are the key to avoiding fatal frustration. I have a law that helps define the size of subtasks: DO NOT EVER LEAVE THE COMPUTER IF YOUR PROGRAM DOES NOT RUN. You can take a piss or stretch. That’s it. I lived by this rule my entire programming career. You can’t always follow it, but try. Get your ass back in that chair. Mom wants you for dinner. Shrug. Your co-workers call you for a meeting. Snarl. I always think of a program like a car engine. You can sometimes merely tune it up, but a lot of times you have to take apart the engine to fix/add something new. That time when the engine is apart (the program does not RUN!) is very important, and should not be very long. If it is, you are not subdividing your tasks enough. I write all sorts of custom code to allow the engine to run again (even if in a half-assed way) while big changes are going on. These intermediate constructs are intended as throw-aways. But they save time. Having your program broken, writing more than a couple hours of new code that has not been tested, is a recipe for disaster. You could easily reach the point where you have no idea where the problem is. If you test in small bits as you go debugging is MUCH easier. Bugs are perhaps 80% likely in the most recently stuff. It’s the smoking gun you goto (haha) first.

You can do a lot with ASCII graphics!

A starter example of this whole process: My first game was a text based D&D type RPG game. I wanted to include a number of “cool” (to a 10 year-old) encounters. So I structured it as follows: There was the “character.” This was to be just a number of global variables (this is long before object oriented programming) like G (gold), HP (hitpoints) etc. I wrote a couple “methods” (functions – but they didn’t have names in BASIC, just line numbers) like “takes a hit.” This subtracts from HP, and if <= 0 branches to the “you are dead” part of the code (not really a function in those days). Then I wrote a number of “encounters.” These were the main flow of control in that program. It popped from encounter to encounter. They might be like: You have met an orc. draw orc on screen with text graphics (aka print statements). present options: “attack,” “run,” “use magic,” etc. wait for input and apply logic. If you are still alive send the player back to the main navigation loop (the place that doesn’t have a particular encounter).

That’s it. I expanded the program by doing things like: Adding more encounters. Adding resurrection as a pay option when you died. Adding an actual map to the main loop. Moving the “combat” logic from individual encounters into a function. Then adding to the character attributes like strength and dexterity which influenced combat. Beefing up character creation. Etc etc. These are all tasks that can individually be accomplished in a few hours. This is key. It keeps your program running most of the time. It provides good feedback on what you are doing.

The entire above “goal” -> “debug” loop can be repeated endlessly. Example: “add a save game.” You now have to save and restore the state of your player (various global variables). But to where? Disk presumably in those days. So you crack the BASIC manual and read about file I/O. First you go simple. There is one save game. It’s always named “adv.sav”. You write a function to open the file and write the vars into it. You examine the file to make sure it put them there the way you want to. You write another function to read the file. You add options to the game menu to call these functions. Then test.

Next baby step. Allow multiple save games. You add “filename” (or save slot or whatever) to the load/save functions. You hardwire it to something and test again. Then you add interface to the game’s main menu to specify which slot. You test that.

Iteration is king! Good luck.


Parts of this series are: [WhyThe SpecsGetting Started, School, Method]

Subscribe to the blog (on the right), or follow me at:

Andy:  or blog

Or more posts on video gaming here.

And what I’m up to now here.

19 comments on “So you want to be a video game programmer? – part 5 – The Method

  1. […] So you want to be a video game programmer? – part 5 – The Method « All Things Andy Gavin says: September 11, 2011 at 8:52 am […]

  2. […] So you want to be a video game programmer? – part 5 – The Method […]

  3. […] So you want to be a video game programmer? – part 5 – The Method « All Things Andy Gavin says: September 11, 2011 at 8:52 am […]

  4. […] So you want to be a video game programmer? – part 5 – The Method « All Things Andy Gavin says: September 11, 2011 at 8:52 am […]

  5. If there are major regrets in my life then I would say it is not starting programming earlier. I read a chapter or two of Basic at age ~14, had a C class at age 22 and made a rpg in actionscript at age 24… When I finished my Game Design Bachelor degree that same year I panicked a bit as I didn’t have proper fundamental skills to rely on. I could do 3D modeling/animation and art but I wasn’t the very best, I could write a detailed GDD, create a mod and lead a group of students to a well graded project etc. Creating that actionscript game over two months also really made it ‘click’ for me. Just pure excitement. Coming back to my home country I immediately signed up for online programming lectures (Java, C# and various web technologies).

    I managed to land a job nine months into that year (first six spent on classes) as a C# programmer. Two years after I still work there but today I’m the head of development (creating point-of-sale and ERP desktop systems and aiding twenty other programmers in doing so).

    In my spare time I’m mostly doing C++ and OpenGL but I’m not on a level where I’m coding ‘to-the metal’ in assembly for larger functionality or creating my own full programming languages. I aim to get there though and I have a shelf full of books I’m reading through. I also acquired some PSOne SDK material and I’m hoping to wrestle the more limited hardware.

    If I had started out programming in my earlier teens however I could have been on that level at the age of around 22 with a CS degree. Now I will be nearing 30 when I reach that level and it’s mostly all self-taught (and with a big student loan not much related to my professional skills).

  6. Randeep says:

    Awesome. However I would have thought that Math is also a component to consider with Graphics programming, how would you recommend going about learning about linear algebra?

  7. Wildux says:

    I’m a 15 years old kid. I’m coding simple programs on Windows Command prompt. I just finished my first saving loading system. I’ve done just as you wrote, taking baby steps and turns in testing and coding. I know this is just the beginning, but what should I do next? Maybe learn some Python?

    • agavin says:

      I’m going to write another post on languages and environments. But Python, Ruby, and Lua are all good new interpreted languages. I’m a big Ruby fan, but all three are good.

      • Wildux says:

        Tomorrow, I’ll do some research on those three languages. But now I need some sleep, it’s about midnight in Finland.
        Ps: Fastest reply ever. And from a die-hard programmer. Thank you for your time.

      • agavin says:

        The “programming ruby 1.9” (pragmatic programming) book is one of the best books on a language I’ve ever read. This in of itself is a big advantage — as it makes learning really easy. It’s free on the web, or the usual price in paper.

        There’s certainly nothing whatsoever wrong with Python either, and it’s probably a bit more popular, but the Ruby book is awesome. I also find ruby slightly cleaner as a language, but they are very similar.

  8. […] – Babysteps, babysteps, babysteps. Taken from today’s Hacker News: “I can not emphasize how important baby steps are. They are the key to avoiding fatal frustration. I have a law that helps define the size of subtasks: DO NOT EVER LEAVE THE COMPUTER IF YOUR PROGRAM DOES NOT RUN.” […]

  9. The hardest part of debugging for me was not really syntax error (because I was always such a perfectionist), but random program errors that came out of nowhere. I was on the verge of insanity with some of my more ambitious projects. I will frame this method next to my desk. If it worked for you, it should work for me. 🙂

    • agavin says:

      Baby steps helps with the insanity by reducing the amount of code you (most likely) have to consider for your bugs. In truth, bugs can be anywhere — and someday I’ll do a post on debugging, as any Naughty Dog who worked with me knows I’m a really good debugger — but they are most likely in new code.

      • I believe you. I’d like to hear some pretty nifty tricks of trade from you as far as debugging is concerned, but I really have got to stop putting over 3,000 lines of code without testing, and then expect a perfect result. Baby steps sounds more than efficient: it’s ingenious. I wonder why I’ve never thought of it before.

  10. Wildux says:

    I’ve now tried out Ruby and it’s a whole new world. Around 2x harder to learn than CMD, but as fast and 100x better. Just few simple projects done, but already looking forward to 2D-platformers.

  11. Hi Andy,

    This is an awesome series of posts. I totally enjoyed reading it. Especially more because I am reading such articles to get a greater insight into different ways of self-learning computer science. It is for my website, which I am hoping to develop into a community of peer learners, who are learning computer science and supporting each other.

    Thanks for the wonderful article… I will be reading your blog often now 🙂

  12. Victor says:

    I’m kind of lost where should Istart in terms of software?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s