So you want to be a video game programmer? – part 4 – School

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

There are two basic approaches: home training and school. Personally I’d recommend both.

Let’s talk school. In my day (1980s) pre-collegiate computer classes barely existed, and if they did they were mostly about Pascal programming and data-structures. They often used p-System pascal, an old-school predecessor to Java!

College Computer Science programs followed (and I imagine they still do) a traditional regimen of stuff like Algorithms, Data-structures, Architecture, Compilers, AI, Theory of Computation etc. They rarely taught or emphasized programming itself. Personally, while I have this training myself (several years at the M.I.T. AI Lab working toward my PhD) I got it long after teaching myself to program and after having 5 published video games on the market.

What I was taught at M.I.T. (1992-94) was way too theoretical to make a good starting place for a young programmer. Don’t get me wrong, I learned a tremendous amount there and it really upped my game. But it was best digested in light of several years practical experience. So I don’t personally think that traditional CS is the way to start. But if you are really serious about computers it is a very solid choice for your higher education. You just need to be ready for it.

And here is the dirty secret about the University Education system: It’s made up of classes. Yep. Your four (or more) year educational experience will just be the summation of eight semesters worth of classes, usually 4-5 per semester. The exact order of these, which topics, and how they are taught will be at the whim of all sorts of varied factors. For example: scheduling, major and general requirements, teacher sabbaticals, friends, personal choice, etc. The school itself will have broad requirements (like you must have 3 science and 2 history classes). You major/department will have more specific ones (like requires 14 classes in the major, with 7 out of the 10 “core” classes — as defined by the department). So everyone’s education is different. That can be a good thing, but it’s less coherent.

And even within a particular class type, like say: Computer Architecture, the classes vary wildly and are rarely designed to work with each other or be taken in a particular order. The school and department might have determined that it should have a Computer Architecture class, but each teacher is free (somewhat) to determine the specific content and style of his or her class. Teachers vary wildly in teaching ability. I mean WILDLY! Even at the best schools. In fact, the teaching quality at M.I.T. was considerably lower than at my undergraduate school, Haverford College. It’s not that the M.I.T. professors weren’t as smart — they were plenty brilliant — but they leaned more toward being famous researchers while Haverford selected people who excelled first and foremost at undergraduate education.

In any case, even within a particular major, say Computer Science, the slate of courses you take might not form a coherent picture. There isn’t much effort made to ensure this. It’s more like, “we need a Compilers course, who wants to teach it?” and then that professor goes off and builds their plan. I’m sure there are constraints and feedback, but it being part of a single coherent program doesn’t seem to be one of them. And teacher style so heavily influences the experience. Now, don’t get me wrong, many of these courses are really good. But they require that you, the student, do a lot of the work integrating the bigger picture. Which really, for first rate minds trying to absorb advanced modalities of thought, is totally fine. It’s just not exactly the same as learning a complex practical field like programming.

But let me speak briefly about the classic topics:

Theory of Computation – Is the cool (but highly esoteric) field of math that endeavors to prove things about what can and not be computed. It includes a lot of discussions about theoretical computers like the Turing Machine and what sorts of computational problems are equivalently complex. This is actually very useful, but only if you have already encountered practical programming tasks. Otherwise it will probably just confuse the bejesus out of you.

Compilers – Is about writing compilers, and how computational semantics are transformed. This is bordering on totally useless for the novice programmer. I myself found it fascinating, but I wrote several compilers. Again, you want to study this several years into your career.

Algorithms – Is the formal study of different methods of problem solving. This is where stuff like the difference between a bubble and an insertion sort goes. Every programmer should know the basic algorithms, but you can read a beginning book fairly early in the learning process and pickup the basics. The college version is much more rigorous. But in the early stages you can lean on libraries which encapsulate these solutions.

Data-structures – These relate closely to Algorithms, but are methods for actually storing data in computers. Different data-structures lend themselves better to different algorithms. The mistake made by a purely academic approach is in thinking that they make a lot of sense without some practical knowledge of the kind of things that you do in normal computing. Still, Algorithms and Data-structures are essential at all levels of programming beyond the totally trivial, and these are the most practical of the classic topics.

AI (Artificial Intelligence) – Can be extremely useful to the game programmer. Games, after all, need enemies that appear intelligent, and in addition have to solve all sorts of big computational problems which use AI techniques (like moving the camera around etc.). But as taught in school it’s pretty theoretical and you need at least a couple years of practical skills first.

Architecture – Is the study of computer hardware, usually micro-processors. A lot of people hate this topic, not being hardware guys. And although you can learn this anytime, you really should. It’s impossible to be a truly great programmer without knowing something about the hardware that makes it all happen. If you are into compilers, this is even more true. I personally loved these classes.

I also want to mention the subject of Programming Languages. Most schools rightfully view the choice of specific programming language as fairly “academic” (or not actually). In the above classes advanced CS guys learn that all normal computer languages are “Turing Complete” and therefore equivalent to each other. Any program in one could be converted to a program in another by automated means (this is what compilers do). Languages all have the same basic features. And if it’s missing one you can write the feature within itself. So who cares which one you use?

This makes a certain academic sense, but in practice, the choice of programming language is vital. And the budding programmer should be introduced to a wide variety of them at a steady yet-not-overwhelming pace so that they learn the fundamentals common to all and do not become one of those lame-ass programmers who are afraid to learn a new programming language. I can be programming in any new language in one day, proficient in a week, expert in a month, master in six. It’s just not that hard.

Schools often have a particular language that they favor. These days it might be Java. In my era it was either Pascal or C. For many schools it’s still probably C/C++. At M.I.T. it was Scheme/Common Lisp! But often professors are also free to just teach a class in a different language. I had an undergraduate AI class all in Prolog. For the gifted student this is a good thing, having a whole class in a new language, as it’s a decent enough emersion to actually learn a new mode of thought (the Prolog class substantially improved my programming even though I’ve not used Prolog since). But also some professors will try the new language for each assignment approach, which is retarded, as there isn’t enough time or depth to master anything, and so the whole assignment becomes about learning the minimum information needed to get it done. The net net is that there is rarely a coherent plan to get you programming and then to have you learn a wide range of practical languages. In said plan, you might start learning with an easier interpreted language like Python, then be taught to master four or five others that are both practical and varied (say C/C++, Java, Javascript, at least one assembly, a “fancy” or two like Ruby/LISP/Scheme/Prolog/Smalltalk etc.) That doesn’t usually happen. You might get lots of Java and a smattering of 10 others.

College professors also don’t usually think that classes that directly and specifically teach programming languages and practical programming are very cool. There is no research or terribly theoretical aspect to them. I.e. the subject isn’t very academic. They are rarely themselves very good programmers (if they were, they’d be off working for Google or whatnot :-) but seriously the personality type for “programmer” and “professor” are different – albeit both bookish). This leads to professors rarely adding this kind of class to the curriculum unless someone makes them.


Having heard about all these more practical Gaming majors that colleges now have, but which I know nothing about (they didn’t exist 20 years ago), I asked a friend of mine who just finished her CS degree yesterday! Lauren is a fellow blogger, programmer, WOW fan, and budding game designer-programmer. Big congratulations! Her comments are in blue:

Having just completed my degree yesterday, I can confirm that not as much has changed in Computer Science education as one might expect, especially given the exponential growth of the field. Aside from the specific languages taught, which for me was mainly Java instead of Pascal, the curriculum is much the same. The breadth of languages taught is still very much dependent on what you choose to seek out yourself; were it not for honors opportunities or research, I never would have become as familiar as I am with functional programming or the MVC architecture.

After the first two years, programming takes a back seat to theory; upper division classes, while useful and offering a degree of specialization, can be light on actual coding. There are still opportunities to improve your skills, though. Project classes, at least at my school, offer a chance to really show your programming chops, so to speak; with the exception of one I personally considered, all required the completion of extensive coding projects in ten weeks or less to the exclusion of lecture material.

The biggest factor that affected the quality and extent of the education I received was the professors. Sometimes, you will get a truly horrible lecturer, someone who isn’t fair or just doesn’t care. For me, this happened more often than not. The best advice I can give is: Be able to teach yourself. To be honest, I didn’t bother attending classes where the professor was incapable of teaching — I don’t want to waste my time. I went home and read the textbook, or taught myself using tutorials or information online.

“Bad” classes will happen, and the most important thing I learned in college, or even before, is that you need to take active control over your education. Even if the teacher sucks, you can’t blame a failing grade on him; you have the power to learn the material and should do so to the best of your ability. This isn’t to say that poor professor performance doesn’t raise my hackles (it does, a lot), just that self-directed learning is a necessity for succeeding as a student and a programmer, especially since the number of future employers that will accept “The teacher sucked!” as an excuse for a failing grade must be pretty small.

Even if you’re taking the so-called “structured” or “formal” education path, no one will hold your hand. You need to look out for yourself, and find opportunities to broaden your knowledge. I learned firsthand that often these opportunities will not be supplied to you, or even pointed out. You need to be responsible for your own education, especially at large universities. Self-directed study and college are not mutually exclusive.

In that spirit, in addition to my CS degree, I also took a Concentration in Game Culture and Design. This was an interdisciplinary program in conjunction with the art school which, did add a nice game “focus” to my studies. I think these types of programs can be helpful, though to say this improved my coding skills would be more than a stretch. Mostly, it gave me a bit more insight into the game pipeline, and the scale of the work that goes into making a game. I’ve gained some skills which I otherwise wouldn’t have been exposed to; for instance, I’m now comfortable finding my way around game design docs and I’ve had practice giving pitches.

While not a value traditionally espoused as part of a CS education, some gaming or art courses can help your creativity. I can’t speak for the more technical games programs out there, I think there is merit in learning a bit about the industry even prior to leaving school.

This fresher opinion confirmed my belief that no school can be as rigorous as GOOD self training like I gave myself, and under no circumstances should you want until you’re 18 (unless you already are!).

The basic message: Start as early as you can, preferable at age 8-12.

Given that college is roughly age 18-22, and adds a lot of value an education begun at home, it can actually dovetail perfectly with said self education. This will be the topic of a later post in this series.

CONTINUED HERE with The Method!


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

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

Andy:  or blog

Read more from guest blogger Lauren here.

Or more posts on video gaming here.

And what I’m up to now here.

So you want to be a video game programmer? – part 2 – Specs


There are a couple of broad categories of programmers working on video game teams. If programmer is your player class, then the following types are your spec. Programmers are all warlocks and mages so instead of “demonology” or “frost” you can choose from below. (NOTE: if you don’t get this joke, you don’t play enough video games) This is the real world however, and many programmers dual (or even triple) spec — i.e. they handle multiple specialties.

1. Gameplay programmer. Programs enemies, characters, interfaces, gameplay setups etc. Probably also does things like AI and collision detection. These programmers are sometimes a little less hardcore technical than some of the other types, but this is the sub-field where the most “art” and experience are often required. Learning how to make a character’s control feel good is not something you can read about in Knuth. It takes the right kind of creative personality and a lot of trial and error. In a lot of ways, this is the heart and soul of game programming, the spec that truly differentiates us from the more engineering programming disciplines.

2. Tools programmer. Works on the extensive tools pipeline that all games have. This is the only branch of game programming where you don’t absolutely have to know and breathe video games inside and out, and it’s a little closer to mainstream applications programming. That being said, life at most video game companies is so intense, you better love them. Tools programmers tend to be very good at practical algorithms, data processing, etc. For some reason, perhaps because it’s more “behind the scenes” this spec is often viewed as less glamourous and there are fewer programmers who want to go into it.

3. Sound programmer. A very specific niche. Here you have to not only know how to program well, but you have to care about the esoteric field of sound. You need the kind of ear that can tell if there is a one sample glitch in some audio loop, and you need to care if the 3D audio spatialization is off or the sound field isn’t balanced. This is often a fairly low level area as audio programming is often done on DSPs.

4. Collision programmer. This is a really specific spec, and often overlaps with Graphics because it involves totally intense amounts of math. You better have taken BC calculus in tenth grade and thought “diffy-q” was the coolest class ever if you want to go into this.

5. Network programmer. In this era of multiplayer and networked gaming there’s a lot of networking going on. And programming across the internet is a bit of a specialty of it’s own. In general, video game programming takes any sub-field of programming to it’s most extreme, pushing the bleeding limits, and networking is no exception. Games often use hairy UDP and peer-to-peer custom protocols where every last bit counts and the slightest packet loss can make for a terrible game experience. If this is your thing, you better know every last nuance of the TCP/IP protocol and be able to read raw packet dumps.

6. Graphics programmer. Some guys really dig graphics and are phenomenal at math. If you don’t shit 4×4 matrices and talk to your mom about shaders, don’t bother. This sub-specialty is often very low-level as graphics programming often involves a lot of optimization. It may involve coming up with a cool new way of environment mapping, some method of packing more vertices through the pipeline, or better smoothing of the quaternions in the character joints (HINT: involves imaginary math — and if you don’t know that that means the square-root of -1 then this sub-field might not be for you).

7. Engine programmer. For some reason, most wannabe video game programmers hold this up as their goal. They want to have created the latest and greatest video game engine with the coolest graphics. Superstars like Tim Sweeney,John Carmack, and even myself are usually seen as falling in this category. The truth is that superstars do all kinds of programming, and are often distinguished by the fact that we are willing and able to handle any sub-type and tie it all together (see lead below). In my mind engine programmers are jacks-of-all-trades, good at building systems and gluing them together. The top guys often blend with Graphics and Lead below. There’s also tons of stuff like compression (nothing uses compression like games, we’d often have 8-10 different custom compressors in a game), multi-threading, load systems (you think seamless loading like in Jak & Daxter is easy?), process management, etc.

8. Lead programmer. People also dream of being the lead. All the great programmers are/were. This is the hardest spec, and no one ever starts out in it. You need to be able to do any of the other specs, or at least judge what approach is best. You need to be able to roll up your sleeves and dive in and fix crap anywhere in the program. You need to live without sleep (4 hours a night every day for years baby!). You need to be able to squint at the screen and guess where the bug is in others people’s code. You need to know how to glue systems together. You need to be able and willing to trim memory footprints and optimize (no one else wants to do it). In fact, you have to know the entire program, even if it is 5-10 million lines of code, and you have to do all the crap that no one else wants to do. Plus, you often have to manage a bevy of other personalities and waste lots and lots of time in meetings. Still want the glory? Being lead is all about responsibility!

CONTINUED with Part 3: Getting Started


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.

And what I’m up to now here.