GrandNumberOfPounds said:
Good morning, dean.
Someone asked in another thread, but if you wanted to get started in video game design (or just programming in general) where would you start?
Believe it or not, most "designers" start out in test. The usual path is test -> assistant producer -> associate producer -> producer / designer. The reason most of them start in test is because it isn't either a) programming, or b) art -- people who are good at one or the other tend to stay in their bailiwick. (There are of course exceptions. My big design credit just kind of happened because there was nobody else working on the project for a long time, so it pretty much turned out how I felt like making it.) Testers tend to be people that like to play games but aren't specifically skilled in one area or another, and if the cruel reality of how much work test really is doesn't faze them they may be able to climb the ladder to designer or producer. The high end of testing can get pretty rarefied -- I know a guy with a master's in computer science who is an XBOX tester for Microsoft. He pulls in a good $150K and doesn't write a line of code. There's a legend that testers are the programmers' worst enemy, but it's not true. I always had buddies in test who
were good to go burn a fat one with after hours would keep me updated on whatever bullshit the producer was trying to pull.
The job title "designer" is actually pretty rare, it's mostly done by the people running the show. "Producer," in games, is code for "project manager," and it takes someone really sharp to be good at it. A game is really two massive projects: there's the technical side of creating software that does what you need it to do, then there's the art side that shows what you need to show. A better term (and one you'll hear most often) is "assets," because it includes things like sound and writing.
A designer has to be able to understand the technical side. Not necessarily intricate details of the programming, but at least a sense of what's possible, what isn't, and a better-than-broad view of
how it gets done. Simultaneously, the designer has to understand how the art pipeline works; what is and isn't possible, how it all interrelates, and how to manage the (tens of) thousands of individual little chunks. Not a lot of people have the background to do this well. Rule #1 here is you absolutely have to know enough about everything that's going on so that you can't be bullshitted. Corollary #1a is "if you don't know what you're doing, deal with people who do." There is a lot of shit you have to know, and it's almost impossible to know all of it. An aerospace company making a new cruise missile (or what
ever) doesn't hire a project manager who just thinks things that fly around and go bang are cool, and can make some pencil sketches of how it should look. You have to be ruthlessly competent at all facets to be effective.
A "game design," per se, is a document that will usually end up running several hundred pages. It's not to be confused with "concept" or "idea" -- both those are necessary before the real design begins, but are the sort of thing that can be slammed out in one to half a dozen pages of text. The design has to describe what the game
does, and that includes what it runs on, how its controlled, what the shell is like (what the options and "metagame" controls will be) and everything else in nauseating detail. It of course changes over time and the design doc at the point of release is going to be quite different from what you start with, but you have to start
somewhere. If I wanted to submit a design to a publisher or developer, I wouldn't hand anyone anything less than a hundred pages long. You really have to think everything out as best you can ahead of time.
I could spout about this for days but I want to go eat food, so I'll say more later
ififeellikeit.
About programming: There is one (1) language you have to know. Everything, but
everything (ok, not everything, but close enough) is written in C++. I've seen one good game written in Java (Minecraft) and one in C# (Terraria), but forget all the crap they try to teach you about those, Python, Eiffel and Godknowswhatelse because when it comes down to it you need the god-damned thing to run fast, and 100% of the code libraries supplied by the console makers or anyone else are C++. A lot gets touted about languages that do garbage collection for you / manage your memory for you / automagically redimension arrays for you / whatever, but all that crap comes at a price, and the price is speed. You have to eliminate all the behind-the-scenes crap a compiler does for you and hammer on the hardware when you want. You can get yourself into more trouble with C++ (or C) than any other high-level language, but the reason you can is because it isn't spending millions of instructions per second babysitting your sorry ass. If you wipe your butt and are halfway careful about it, you can write reasonably portable code that'll run so much faster than anything else it just isn't funny.
It doesn't hurt to have at least a passing acquaintance with assembly code. There is one purpose for writing anything in assembler, and that's "to optimize a section of code for the target microprocessor." Period. I write a heck of a lot less of it than I used to -- compilers and the hardware have come a long way -- but still, there'll be those chunks that would really make things
go if they ran ten times as fast as they do.
Doom was famous for having only one short routine in assembler, but it wouldn't have run in real time without it. (Carmack is famous for being 10% genius and 90% moron, but that's another subject.)
A résumé citing education from someplace like Full Sail used to be a one-way trip to the round file, but that's doesn't apply as much as it used to -- except with reactionary old farts like myself. I know people that paid four times what I did for my two four-year degrees for one semester at "game school." I've used every stinking thing I learned in college -- math, physics, statistics, programming, everything else -- in making games. By definition, a game-oriented curriculum has to leave some of that out. I don't know what gets left out, exactly, but I would much, much rather see a straight CS degree on someone's résumé than a "game creation" degree. Do you get enough math at Full Sail to write a routine that'll rotate a unit quaternion? (I don't know, but I kind of doubt it.) The best game programmers (i.e. those with "senior / lead" in their job titles a.k.a. those who make the big bucks) are overwhelmingly straight-out programmers who happen to love games. Two of my best friends pull in well over $200K/yr, and they're just "straight" programmers who happen to love games, and understand them really well. Game programming is a little different than most other flavors in that you have to run in real time, so delving into that aspect of things is always a plus. There will always be some tools and things that don't need it, so knowing PERL and such never hurts (!), but when the pixels hit the monitor you want it to run like a raped ape.
I guess my point is: to be a good game programmer, first be a good programmer. The rest will take care of itself.
(I will now go eat food. Food is good. Food is our friend.)
