Way of the Warrior – The Lost Interview

A Twitter friend of mine dug up this ancient and forgotten interview that I gave from my Cambridge Mass apartment in 1994, during the development of our 3DO fighting game, Way of the Warrior. The original post can be found here, but he gave me permission to repost the whole thing here. It’s certainly one of my older interviews on record. I did a number in the 80s but those are pre-web and certainly long lost (unless I comb through my parent’s basement for old copies of EGM and the like!).

_

Back in May I had a chance to interview Andy Gavin, one half of the team that makes up Naughty Dog Software. The other half consist of Jason Rubin who’s a graphic arts specialist. These guys are based in Cambridge, MA., where I happen to be from, and have created what may be the best fighting game for the 300. I played Way of the Warrior and it definitely blows the first Mortal Kombat away easily. The game is similar to Mortal Kombat in many ways. The digitized characters, fatalities, combos, blood galore, hidden characters, and special attacks are all here. What Way of the Warrior does is take if a step further with an amazing AI(Artificial Intelligence), characters that shrink and grow, over 50 attack moves for each character, 100% 3D scrolling, hidden weapons, interactive backgrounds, bonus items, and so much more. Let’s have a talk with Andy and see what he has to say about Way of the Warrior.

VGT: When did you first start programming video games?
Andy: About 1 0-12 years ago, the first game we made was Ski Crazed on the Apple II, which came out in 1986. It sold a couple thousand copies. Dream Zone was our next game that sold about 15000 copies. Keef the Thief, from Electronic Arts, did much better and sold about 50,000 copies on various machines. We then did Rings of Power, which was our only Genesis cartridge. It’s was very complex and sophisticated and took about 2 1/2 years to produce.
VGT: When was Naughty Dog founded?
Andy: Well , Naughty consists of mainly Jason Rubin and myself . Naughty got its names from a cartoon character that Jason drew. (Andy showed me a picture of an old Naughty Dog logo). Their new logo is on their flyers. The character was created about 8 years ago.
VGT: Is there any downside when programming on the 300 with their CO’s? Does access time and RAM space affect your games?
Andy: Well, first of all the 3DO has 3 megabytes, not mega bits of RAM, which is bigger then the largest SNES cartridge. The CD itself is 660 megabytes . There are technical issues that need to be addressed when programming on the 3DO. One has to use clever designs to reduce and eliminate load times. In Way of the Warrior the entire program was designed in what we call, Asynchronous. The loading is done while you play, by anticipating what needs to be loaded’ in advance with a hardware process called DMA (Direct Memory Access) . There ‘s a short pause going into a fight, but once the action has begun, there is no pause. Players can perform all their moves, with fatalities, 3D scrolling and the stereo music blaring, but with no load time.
VGT: So even though we’re playing continuously, there’s no slow down what’s so ever.
Andy: Yes, the 3DO is capable of loading stuff without any slow down. However, many previous CD games, including the 3DO, have had notable slow delays.

VGT: Like the Sega CD for instance?
Andy: Yes, this is due to sloppy, programming and not being aware of how to program on CD’s. It’s a difficult issue when writing programs that can actually play and load at the same time. It’s a technical challenge. With good program design the load time can be minimized. In turn, the quality of the sound effect, music, FMV, and game play surpass any cartridge game. Cartridge games only have a limited amount of memory in which you can program. CD’s only cost a dollar to manufacture, while cartridges can cost anywhere from 20-30 dollars. CD’s have enormously superior cost to storage ratio.
VGT: Can the access time for the Sega CD be reduced with technical design programming?
Andy: They can definitely reduce the access time. I don’t know that much about the Sega CD though. I don’t think their DMA is better than the 3DO. The 3DO has 4-5 times more memory. It also has a CD drive that’s twice as fast. It has decompression hardware that effectively doubles the speed. It has a unique and extremely powerful custom DMA architecture that can move graphics from disk to memory to screen and back without effecting game play.
VGT: What makes Way of the Warrior different from all the other fighting games?
Andy: As I mentioned before, I have an Artificial Intelligence Graduate degree from MIT. The computer players in WOTW are much more sophisticated then in other fighting games. Whereas they often resorted to patterns to beat the human players, there are no patterns programmed in for WOTW. It uses research grade AI that learns the best way to beat you. It’s extremely cunning and different and actually looks like a real player fighting by adapting to the situation and using all it’s moves.
VGT: Is it always learning consistently more and more each time you play it?
Andy: Yes.
VGT: What about the characters? What makes them so special.
Andy: The characters have around 50 normal moves and about 15-20 special moves. These moves reflect their styles and personalities. There are many secrets that use the background area and hidden characters can also be found.
VGT: So is each character equal in sense or are some stronger then others?
Andy: All the normal human characters are designed to be equal even though they’re different.
VGT: Well, I remember the first Street Fighter II game had very uneven characters. Some had a major advantage over others.
Andy: It’s tough to get the characters exactly even. We tried to get them as close as possible. People also developed different strategies for beaten the other characters. There are a lot of unique techniques and abilities for each character. Like Konotori, which means “stork” in Japanese, can flap and stay in the air longer. Major Gaines has special steroids’ implants that can change his size and therefore the amount of damage he receives become minimal. Nikki Chan is a Chinese Kung Fu artist who can do flips with special moves. She’s very fast and agile. Crimson Glory has close in grabs and special multi-missles that can be fired. Some character has special weapons. Nabu Naga has a sword and throwing stars. Shaky Jake has a staff.
VGT: There seems to be a little bit of everything from all the other fighting games in this game.
Andy: The other fighting games are very narrow. Most of them are to much alike. What we tried to do was take everything good from all the other fighting games and combine them all into WOTW. We’ve added unique features with better graphics, sounds, 3D backgrounds, special magic and potions, panning and zooming, background interaction, and larger more detailed characters.

VGT: Was the process of digitizing the characters the same as Mortal Kombat.
Andy: There are similarities. We’ve never seen them actually doing it. We have seen photos in magazines. They are actually a little more regimented then ours. Their fighting engine is much less sophisticated then WOFW. It requires that every characters moves line up to the exact same position. When each character does a high punch in Mortal Kombat, they high punch at the exact same point. So when they digitize their characters they have to line up perfectly. In WOTW, every character has its own information so not all characters need to have a high punch. Some of the characters punch high, some low, while others are tall, short, big and small. There’s no requirement that the character be the same size. We built the character the same way the actor would appear, rather then force them to convert to our pre-requirements.
VGT: With the 300 having such a small user base at this point, do you think it can increase sales and become successful?
Andy: We think it has a good chance. All game systems start off with a small user base. People forget the Genesis came out in August of 1989 and 2 years later when the Super Nintendo was released it only had 700,000 machines out there and only 23 games after the first year. 300 already has more then that. The 300 is the first of the 32/64bit machines and the difference is academic. Sony, Sega, and Nintendo have all announce 32/64bit systems that won’t be available until 1995. The 300 will be the only significant 32bit machine when Christmas comes. It will have a year of development by then and the price will probably drop some more. So I think it’s in good shape. We hope WOTW with help sell systems.
VGT: Are there any other projects being worked on for the 300?
Andy: We have 2 other projects we’re working on, but we can’t comment on them at this point.
VGT: Do you think that CD’s are the way to go for our future programmers?
Andy: I think this year is the year of the CD’s. It already has the PC market. It offers so many advantages in cost and amount of storage . The access time disadvantage can be overcome with well-designed machines and good programming techniques.

VGT: Are there any other types of games that Naughty Dog will be working on besides fighting?Andy: We signed a deal to put WOTW in the arcades.
VGT: If WOTW does come to the arcade, will it be different then the 3DO version.
Andy: It would be a bit different. The basis of it would be the same. There are different constraints for the arcade version. The 3DO is capable of producing arcade quality games.
VGT: What’s the most outstanding achievement you’ve seen in video games today? What games really blow your mind?
Andy: I have favorites over the years. I tried Ridge Racer which was very impressive looking, but had mediocre game play. In the PC world, “DOOM!” was very good looking. It shows us that 3D games are here and can be produced very well, even on PC’s.
VGT: Well, that’s about it for the questions. Thank you very much for taking the time to be interviewed by VGT. We all hope that Way of the Warrior is very successful and we look forward to reviewing it and any other games that are produced by Naughty Dog.
Andy: Your welcome. Thank you for choosing Naughty Dog as your first interview. We look forward to reading VGT when it’s released.

This is back to 2011 Andy. It’s so worth watching the totally hilarious video from our 1994 masterpiece (LOL). As you can see, we went for over the top.

For more info on my video game career, click here.

For what I’m up to now, click here.

Ready Player One

Title: Ready Player One

Author: Ernest Cline

Genre: Pop Science-Fiction

Length: 384 pages

Read: September 13-18, 2011

Summary: 10: buy book 20: read book 30: goto 10

_

I read this after two different friends recommended it in the same week. Wow! If you’re one of my (presumably) many readers who love video games. Go buy and read it. This is pretty much the ultimate classic video games novel! And I should know, having been born in 1970, the perfect time to experience the full rise of video games and modern pop culture (inaugurated May 25, 1977). I was so enamored of computers in general and these little beasties in particular that I went and made (and sold) thirteen of them professionally.

But back to Ready Player One. It’s a first person narrative set in a roughly 2040 dystopia where the world has basically gone to shit and most people live inside a gigantic virtual reality video game. It’s creator has died and left his vast fortune to the winner of an elaborate easter egg hunt (think Atari Adventure Easter Egg crossed with the Great Stork Derby). This whole world and contest centers around an obsessive love of all things pop-culture and 80s, particularly films, comics, and most importantly, video games.

In practice the novel is an old school adventure set mostly in virtual reality. But it contains an astounding number of well placed and deeply woven 80s pop-culture references. For me, they were continual fun. I got 99% of them, including some damn obscure ones. I’ve played every game described in the book (except for Dungeons of Daggorath — never had a TRS-80 — but it looks like Wizardry), seen every movie, heard nearly every song, etc. I don’t know how this book will read for someone a lot younger who isn’t up on all this old school geekery, but I sure enjoyed it.

The story is great fun too. The protagonist is likable and all that. It’s not a long book but races along. There are a few second act jitters (the “romantic” period between the first and second keys), but I blew through them fast enough. The prose is workmanlike but unglamorous and there are some cheesy or cringeworthy moments. They don’t distract from the fun. The last third in particular was awesomely rad with numerous 1337 epic moments. When the protagonist faces off against an unstoppable Mechagodzilla avatar and invokes a two-minute Ultraman powerup I felt tears coming to my eyes.

As Science-Fiction the book is a bit mixed. Mr. Cline manages to deftly describe what must to the novice be a bewildering array of virtual reality technologies and concepts. He’s fairly unusual in actually specifying some of the interface elements in his world and he does a credible job with all of this. Nothing stood out as particularly bogus, but was based on decent extrapolation. There are some elements, however, which still exist in his 30-years-from-now future that are already on the way out. Hard drives in “bulky laptops” for example. One only has to look at the iPad and the Macbook Air to see that writing on the wall. Again, I must point out that these minor quibbles do not detract from the book’s extreme fun factor.

Cline is uncannily knowledgable about his video games (and again, I should know), but there is a curious oddity in the biography of the central Bill Gates crossed with Richard Garriot character. He is described as releasing his first hit game (for the 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 TRS-80 had gone the way of Allosaurus and plastic baggies hadn’t been seen in years. My first game, Math Jam, was released in baggies in 1984 and that was way late for them. 1987 featured games like Zelda II, Contra, Maniac Mansion, Mega Man, and Leisure Suit Larry. All of these are well after the era venerated in the book. This small, but important, error is odd in a book so otherwise accurate. I can only assume that the author (and his character), living in the middle of the country, existed in some kind of five-year offset time-warp :-)

On a deeper level, the novel toys with one of my favorite futurist topics: Will we all get sucked into the computer? I actually think the answer is yes, but that it’s unlikely to happen via 90s envisioned visors and immersion suits (like in Ready Player One). I think we probably will have retina-painting laser visors/glasses at some point. Then neural implants. But the real big deal is when our brains are digitized and uploaded into the Matrix. Muhaha. I’m actually serious, if flip. Eventually it will happen. If not this century then the next. I just hope I make it to the cutoff so I can evade bony old Mr. Grim and upgrade.

In conclusion, I have to agree with the back cover quotes of some other authors I like:

John Scalzi: “A nerdgasm… imagine that Dungeons & Dragons & an ’80s video arcade made hot, sweet love, and their child was raised in Azeroth.”

Patrick Rothfuss: “This book pleased every geeky bone in my geeky body. I felt like it was written just for me.”

So if you have even the least enthusiasm for video games, virtual reality, 80s pop culture, or just plain fun. Go read this book!

For more book reviews, click here.

PS. If you are 5-10 (or more) years younger than me (born 1970) and have (or do) read this book. Tell me in the comments what you think of it. I’m really curious how those who didn’t live it see it.

I couldn’t resist.

Crash Launch Commercials

In honor of the recent 15th Anniversary of my baby Crash Bandicoot, I present collected together the original suite of American TV Ads which premiered in September of 1996. It’s the suit that helped make the Bandicoot what he was.

Thanks to Playstation Museum for collecting and uploading these. You’re hurting my elbow!

_

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.

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.

So you want to be a video game programmer? – part 3 – Getting Started

…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: [WhyThe 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.

So you want to be a video game programmer? – part 1 – Why

This post is a sequel of sorts to my How do I get a job designing video games. The good new is — if you’re a programmer — that nearly all video game companies are hiring programmers at all times. Demand is never satisfied. And the salaries are very very competitive.

The bad news is that it takes a hell of a lot of work to both be and become a great game programmer. Or maybe that isn’t such bad news, because you absolutely love programming, computers, and video games, right? If not, stop and do not goto 20.

I’m breaking this topic into a number of sub-posts. Although this is the intro, it was posted a day after the second, number 2, on types of game programmers, but I’m backing up and inserting this new number 1 (I’m a programmer, I know how to insert). Other posts will follow on topics like “how to get started” and “the interview.”

_

So why would you want to be a video game programmer?

Let’s start with why you might want to be a programmer:

1. Sorcery. First and foremost, being a programmer is like being a wizard. I always wanted to be a wizard. Given that magic (as in the D&D variety) doesn’t seem to be real (damn!) programming is the next best thing. Computers are everywhere. They’re big, complex, and all sorts of cool everyday devices (like iPhones, set-top boxes, cars, and microwaves) are really basically computers — or at least the brains of them are. 99.9% of people have no idea how this technology works. As the late great Author C. Clarke said, “any sufficiently advanced technology is indistinguishable from magic.” Yay computers! If you actually know the arcane rituals, incantations, and spells to controls these dark powers then you are… drum roll please… a wizard.

2. Career security. Computers are the foundation of the 21st century economy. Nearly every new business is based on them. Knowing the above incantations is secret sauce. All the growth is in high tech (product possibility frontier and all that). Hiring is supply and demand too. The demand is for programmers and other high tech specialists.

3. Even more career security. Programming is hard. It requires a big New Cortex style brain. This means lots of people can’t do it. It takes years of study and practice. I’ve been programming for 30 years and there is still an infinite amount for me to learn. Awesome!

4. It’s a rush. Creating stuff is a rush. Making the infernal machine bend to your warlocky will is a huge thrill. It never gets boring and there is always more to learn (related to #3).

5. It pays really well. This is related to #2 and #3. People need programmers and they can’t get enough, so they have to pay competitively for them. Even in the late 90s early 00s at Naughty Dog it was very rare for us to start ANY programmer at less than $100,000, even ones right out of school. Good ones made a lot more. And if you’re a total kick-ass grand master wizard (nerd) like Bill Gates or Mark Zuckerberg you can even start your own company and make billions. Take that you muscle bound warriors!

6. Solo contributions. You like spending time with machines and find all day dealing with illogical humans at least partially tedious. Sorry to say it, but even though most professional programming is done in teams a lot of time is spent at the keyboard. For some of us, this ain’t a bad thing.

7. Socialization. You need an excuse to hang out with others. On the flip side, because of this team thing you’ll be forced to socialize on and off between coding. This socialization will have certain structural support. This is convenient for the would-be wizard, master of demons but terrifying forces, but afraid of starting conversations.

So why would you want to be a video game programmer specifically?

8. Video game programming is really hard. Probably the hardest of the hard. It combines cutting edge graphics, effects, the latest hardware, artistic constraints, tons of competition, very little memory, and all sorts of difficult goodies. The really serious wizards apply here.

9. Other types. Video game teams have artists, musicians, and designers on them too. Lots of tech jobs don’t (although they sometimes have those pesky marking folks). Artists etc are cool. They know how to draw or compose cool stuff which makes your code look and sound much cooler.

10. Consumer driven. If you make it to work on a professional game they often sell lots of copies and people will have heard of what you do. This is much much cooler than saying “I worked on the backend payment scheme of the Bank of America ATM.” It’s so cool that it might even get you laid — which is an important concern for bookish wizards of both genders.

11. It’s visual. Seeing your creations move about the screen and spatter into bloody bits is way more exciting than that green text on the bank ATM. Talented artists and sound designers will come to you with said bloody bits and all sorts of squishy sounds which will make your coding look 1000x more cool than it would by itself. If you aren’t into bloody bits than you can work on a game where enemies explode into little cartoon rings. It’s all cool.

12. It’s creative. For me, I have to create worlds and characters. I’ve been doing so my whole life. Right now I’m not even programming but I’m writing novels, which is also about creating. Programming in general is pretty creative, but game programming is probably the most so.

13. Love. You love video games so much that working on them 100+ hours a week seems like far less of a chore than any other job you can think of!

I’m sure there are more reasons, but the above seem pretty damn compelling.

CONTINUED HERE with Part 2: “The Specs”

_

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.

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

…CONTINUED FROM PART 1.

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.