Give Blood

I started writing this post on my 21st birthday (this past Sunday), so it's going to be pretty frivolous and might not teach you anything-but hey, you've been warned. Because it's my birthday, I've been thinking about my successes and failures that I've had growing into the game developer that I am today. A bit of a postmortem of going from being a kid that loved video games and math to heading into my final year of college with more than a few games under my belt.

I decided I wanted to be a game developer when I was in 7th grade, which is now 8 years in the past (I'm a junior in college now). This decision was met with resistance from most people that I knew, but I was really serious about it. Most people thought I'd grow out of it and choose to do something that “made a difference”, especially those who knew that up until that point I was a kid that wanted to make use of my love of math and science at NASA working as a researcher.

Clearly, I didn't grow out of it. I suppose that it didn't help that I was already very aware that it was “nearly impossible” to get into the games industry. With this in mind, I managed to get a bunch of scholarship money at a private school on the other side of town for one reason: computer science classes. I didn't make games in high school (and I'm glad I didn't – I needed to be a kid), but getting serious about programming years before college was one of the best things to happen to me. Exposure to code before college helps so much farther down the line (by the way check out Brett Douville's awesome post about teaching his son about programming). But still, I knew that I had a great deal of work was ahead of me because I knew how hard it was to get a job.

Not that long ago, this video surfaced about game development:

http://www.youtube.com/watch?v=lGar7KC6Wiw

To put my thoughts at the time into perspective, I acted a bit like I had that video running on repeat in my head (even though that particular video didn't exist yet). I made the decision to attend Michigan State University largely for financial reasons, but also because of job opportunities with the game development lab I currently work for. Attending a large university was a bit worrisome to me, given that I didn't think a diverse program could compete with a specialized school like Digipen or Full Sail. I felt like I had to work my ass off to make up to what I would probably be missing from class. I got involved with Spartasoft, MSU's game development club, and vigilantly attended every game jam that year. By the time the year closed, I had worked on no fewer than six games of varying sizes, and was starting to get interested in writing shader code. To say the least, I was working hard and was perhaps overreacting a bit to my worries that I might be getting a “lesser” education.

Freshman year was also the year that I watched many of the seniors that mentored me fail to get jobs. The industry was starting to feel the pains of the recession and things were rough, and it scared the shit out of me. No matter how hard I was working that year, I pushed myself into overdrive the next year. I was involved with a team in a game development competition that ended up winning a trip to GDC paid for by Ford Credit. Being an underclassmen on the team as well as the primary programmer, it would be the first project I seriously crunched for, but I'm glad I did because going to GDC that Spring changed my perspective about everything.

Up until that year, I suffered from something that I suspect afflicts many young programmers. I thought I could be both programmer and designer. I mean design gets all of the glory right? Every kid wants to be the next Miyamoto or the next Ken Levine, and I still reveled in the thought. But that year I would finally get enough experience to realize that design is really hard and you might kill yourself if you try to be both a good programmer and a good designer. Still, I thought maybe gameplay code was the place for me, or a scripting heavy design position. And then GDC hit me like a train hitting a chicken, blowing apart all my thoughts about game development as a career. The fact of the matter is that engine code is really cool, tool development is incredibly important, and hand optimizing assembly code makes you a badass. I had started to become interested in graphics and rendering, and John Hable's presentation about HD rendering in Uncharted 2 convinced me that I wanted to do graphics code professionally. If you get the chance, check out some of his presentations and his website, there's some great stuff there.

Going along with these newfound desires to work on lower level systems, I once again decided I wasn't working hard enough and hurled myself further into my work for the next year. I had the portfolio development class for MSU's game specialization that fall, and I began pulling tons of late nighters and all nighters for my games. I look back on college and realize having a laptop and being able to take my work everywhere with me was both a blessing and a curse. I got to the point where I got a feature implemented into a game while in the back seat of a car on a coffee run. I was out of control, wanting to learn and accomplish so much, so fast. So was it worth it? Now that you've read through several paragraphs of me admitting to crunching increasingly more throughout college, I'm going to finally get to my point.

For the first Spring in a long time, I don't feel like college is a time bomb with only so much time left. Three years of increasingly stepping up my dedication to learning the art of game development has finally lead me to become the programmer I want to be. Maybe I worked too hard at times, but it's no small task to become a programmer cut out for game development in just four years time. The way I viewed life, if you want to get a job in the games industry, you have to become a good game developer, and the only way that that will happen is if you love making games and learning how to make even better games. I went back to GDC this year, and I'll be back again next year, because I love learning about all the crazy techniques people are developing and trying. People talk about how you have to have connections to make it as a game dev (what are we, film?), but I honestly think that's bull shit. I don't want your card because I want a job, I want your card because I want to be friends with people riding the edge of what games can do (speaking of which, props to the Battlefield 3 team). If you want to make games throw yourself at it, because only you can make yourself a crack game developer.

When I'm walking to the lab and I feel like I'd rather go home and sleep through the afternoon, I listen to one song consistently. It's called “Ali vs. Frazier 1” by a Massachusetts hardcore band named Bane. I think it summarizes my view's on what it takes to become successful at anything worthwhile, including game development:

(rumble, young man, rumble)
how many more days will you sit
and talk about your ambitions
all that you can be
the person you are dying to be
the place you want to get to
but always out of reach
before that fury swells inside of you
grows so big that it forever quiets you
stand up to your demons
make a run at your goliath
find the best, find the worst
waiting in both of you
it's not the who or the what that is lasting
but how you fight
that is the fight
the only mark that will not leave you
and I will feel my heart drum its final beat
if it meant that I have given this my all
there's nothing left for me to believe in
if not your, if not this...
what else is there but death?
(it's your call...it's all on you)
give more
give everything
give blood

Resources for the Aspiring Game Programmer

A little while back I was asked to put together a list of some resources for people interested in learning game programming at a professional level. These are some of the most useful resources I've found, many are straight from my book shelf / browser history. I'll try to remember to update this if I come across new things. Feel free to ask question or make suggestions in the comments.

Books:

Game Engine Architecture by Jason Gregory:

A good read for anyone looking to go into game development professionally, covers many topics related to 3D game development, and covers many of the topics that could be covered in typical game programming interview or programming test.

http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/ref=sr_1_1?ie=UTF8&qid=1300117839&sr=8-1

Programming AI by Example by Matt Buckland:

An excellent introduction to programming game Artificial Intelligence, something which is quite different from AI in an academic setting, as is the case with the class offerings.

http://www.amazon.com/Programming-Game-Example-Mat-Buckland/dp/1556220782/ref=sr_1_1?s=books&ie=UTF8&qid=1300118409&sr=1-1

Artificial Intelligence for Games by Ian Millington:

Another AI book that is structured more like a traditional textbook. Makes for a good reference.

http://www.amazon.com/Artificial-Intelligence-Games-Second-Millington/dp/0123747317/ref=sr_1_1?s=books&ie=UTF8&qid=1300118482&sr=1-1

Real-Time Rendering by Tomas Akenine-Moller:

The definitive text on graphics in real-time applications, I have rarely met a graphics programmer that hasn't read this cover to cover. Very math and theory heavy, light on code.

http://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenine-Moller/dp/1568814240/ref=sr_1_1?s=books&ie=UTF8&qid=1300118547&sr=1-1

Real-Time Collision Detection by Christer Ericson:

Perhaps the most popular book on Collision Detection in games.

http://www.amazon.com/Real-Time-Collision-Detection-Interactive-Technology/dp/1558607323/ref=wl_it_dp_o?ie=UTF8&coliid=I2I02492N3ZKNN&colid=1PXQOGX25DY1T

Essential Math for Games and Interactive Applications by James M. Van Verth:

An Excellent reference on common mathematical concepts that repeatedly come up in 3D game development.

http://www.amazon.com/Essential-Mathematics-Interactive-Applications-Second/dp/0123742978/ref=sr_1_2?s=books&ie=UTF8&qid=1300118975&sr=1-2

Web Resources:



Unity 3D:

Unity is a free 3D game engine that is used in the Game Specialization and several research labs at MSU. Easy to pick up, well documented, and has a strong online community:

www.unity3d.com

NVIDIA Developer Zone:

NVIDIA has several free books available in their developer zone. These often have excellent information that applies across all hardware and are not just NVIDIA's, this includes the excellent GPU Gems series.

http://developer.nvidia.com/page/home.html

Unreal Development Kit:

UDK is a free to use version of the well known Unreal Engine. It is a bit larger and harder to use than other engines (Unreal is meant to be used by large teams at professional studios), but experience with it looks quite good with studios that use it (Gearbox, Irrational, Epic, etc).


http://www.udk.com/

AltDevBlogADay:

AltDevBlogADay is a collective blog run by Mike Acton, the Engine Lead at Insomniac. It features daily articles from programmers all across the industry:

http://www.AltDevBlogADay.org

Gamasutra:

The most official news site for the games industry:

http://www.gamasutra.com

Game Career Guide:

This is a sister site to Gamasutra that features articles for aspiring game developers:

http://www.gamecareerguide.com


Half-baked State Machines: Living with Regret

So I feel like programmers sometimes look at system that needs to be stratified into a state machine, and they ask themselves a very dangerous question "Do I really need to make this all that robust?" The answer should usually be STFU and write a decent state machine. I've had to deal with a state machine built on a switch statement that has now grown to over 2500 lines, which is the players character controller, and I want to smack the code's original author for giving me such a bee's nest to inherit.


Even with this most unfortunate experience under my belt, I still looked at a simple AI that I needed to write for my latest project, and thought "I bet I could get away with just a switch statement." In the end this is by and large a failure on my part, because even though the state machine get's the job done, I'm going to have to rewrite it if we decide to expand the scope of the game beyond the 4 weeks its currently set at.

Things that are important for any state machine:
1) Calling the active states update function each frame (or however frequent the state machine is supposed to act)
2) Letting the active state know when it is being exited
3) Informing the new active state that has just been entered

Anything that does not incorporate all 3 of these in a smooth and coherent manner can rapidly become a headache. This should be commons sense, but I've caught myself and another programmer falling into the same trap with this... So I figured it might be worth ranting about.