June 27, 2008

How to Become a Game AI Developer

The industry always needs more talented AI developers, and I thought I should post some thoughts here to share my own perception of the best strategies for picking up the skills the industry needs and getting into a game AI development role.

I'd originally written up this post months ago, but in light of Dave Mark's recent article on aigamedev.com, I thought it was time to post my 2 cents.

First and foremost, focus on developing the skills you need to become a solid, well-rounded game developer before you try to specialize.

#1: Generalize, Then Specialize

Game studios are generally not interested in hiring entry-level engineers as AI specialists right off the bat. We need engineers who have a broad understanding of all the different parts of a game's source code, and this means that it takes a few years to gain enough understanding of game development to be able to branch off into any particular area. In some cases, new hires will be asked to help fill in the gaps on a project that's rushing headlong toward its ship date. New engineers are often expected or to do work that no one else on the team has time to handle (or interest in doing).

It's fine to explain to a potential employer that you're interested in game AI engineering as a long-term goal, but you should expect that your first few years in the industry will not involve a lot of specialization.

It's important to keep in mind that becoming a generalist first is a good thing. An AI developer needs a solid understanding of the fundamentals of game development, a broad understanding of all the components of a modern game engine, and the irreplaceable experience you gain from shipping an actual product.

So first and foremost, gain the skills you need to become a great engineer. To most developers, that includes:

* A broad knowledge of C++ and the STL
* An ability to wrote code that's robust and readable
* A solid understanding of algorithms and data structures
* A good understanding of object-oriented programming practices
* A pragmatic attitude towards development and a willingness to take a "bottom-up" approach to solving problems
* An understanding of how to test code and how to code defensively (i.e. using the language features of C++ to minimize the possibility of defects and force the compiler and linker to tell you when certain classes of problems occur)
* A willingness to let the profiler drive performance optimizations, to find out where optimization is really necessary before attempting to optimize, and to look at big-picture algorithmic optimizations before trying to resort to fancy tricks and hand-coded assembly
* An understanding of how to use memory resources efficiently
* A broad understanding of the overall architecture of a modern game engine
* A solid understanding of the 3D math techniques needed in all areas of game engineering
* An ability to communicate and to work well on a team

EDIT: Here's a quick list of the most recommended books on my bookshelf for the kinds of general engineering skills I'm referring to: [Effective C++, More Effective C++, C++ Coding Standards, Code Complete, The C++ Programming Language, 3D Math Primer for Graphics and Game Development]

EDIT: [jorkin] Additional useful books here: The AI Programmer's Bookshelf - game AI programming book list.

#2: Write a Sample Program

The single best way to impress a company is to write a sample program in C++ (yes, you could use Java or C#, but the industry tends to use C++ exclusively on the game side, and Java and C# are only used on the tools side). Your program doesn't need to be anything graphically impressive, but do something that shows how you work and how you think. Don't use a group project from school -- make it something you wrote yourself and that you can take full credit for.

More importantly, you definitely want to be able to provide the source code as well, so you can give a potential employer a demo along with the sample code that was used to create it. Make your code as solid, readable, and bug-free as possible, and be prepared to answer questions about the choices you made when writing the code.

#3: Be Persistent

Once you have a solid background as an engineer and a good sample program to show potential employers, talk to as many companies as you can. The programming tests alone are worth the effort, and they'll do a lot to improve your skills no matter how long you've been in the industry.

When someone throws you a tough interview question, be sure to keep attacking the problem as vigorously as you can, and don't be afraid to ask the interviewer for help with it -- the interview is partly a test of how you handle pressure, how determined you are to solve a problem, and whether you can communicate when you're stuck in a corner or if you "lock up."

#4: Be Pragmatic

Finally, if you do discuss AI with a potential employer, make sure you approach it with a pragmatic attitude. Be aware that there's a world of difference between what "artificial intelligence" means in an academic setting and what we mean by "game AI." Also be aware that there are many in the industry who feel (often correctly) that game AI hasn't always lived up to its promises.

If you start talking to potential employers about neural networks or other machine learning techniques, you should expect that the hairs on the back of their necks will stand up, and you'll want to be able to explain exactly how it's relevant to game AI (which can be a tall order, given that there are still a few developers out there who think that any AI is too much).

Employers are very leery of hiring anyone who seems to have their head in the clouds, and you need to bend over backwards to prove that you're pragmatic. It's important to understand exactly what the challenges are with regard to game AI and where it fits into the overall process -- see my recent post on this blog for a list of the kinds of problems AI developers confront on a daily basis.

AI development can be very rewarding if you find the right company and the right project.

Good luck!

Posted by PaulT at June 27, 2008 01:15 PM
Comments

So... not a lot of people breaking into game AI via the proverbial "casting couch", are there?

Posted by: Dave Mark at June 28, 2008 07:00 PM

Hi paul,
Thanks for your very nice and expressive post. In my opinion, the last case(Be Pragmatic) was the most important aspect of our essay. But,I have a question: If potential employers can't understand the relations and overlaps between AI game industry and some AI pure knowledge like Neural Networks, how do they implement Learning techniques??! It's true for some other ones like Hiererchical Learning, etc. I'm not a game developer (I'm working on computer vision), so maybe that's why I'm confused ....

Posted by: vahid at June 29, 2008 02:13 AM

> [vahid]
> If potential employers can't understand the
> relations and overlaps between AI game industry
> and some AI pure knowledge like Neural
> Networks, how do they implement Learning
> techniques??!

Most of them don't!

Game developers tend to avoid machine learning for three reasons:

1. Online learning (i.e. learning during actual gameplay) isn't usually feasible -- not so much due to performance concerns but because learning can change the gameplay experience in unpredictable ways and make the game impossible to balance and impossible to test. When you ship a game, you need to be absolutely certain that the game performs in a way that's reliable and repeatable. Online learning can also open the door for players to implement all sorts of exploits -- if players can figure out how an AI agent learns, they can "teach" it how to behave in a way that works to their advantage.

2. Game designers want to make sure that the characters in their games behave in a way they can understand, and that when those behaviors do something they consider undesirable, they can change it. As a result, even offline/precomputed learning techniques can introduce a lot of additional complexity without necessarily resulting in better behaviors than skilled AI developers could create by hand.

3. Although it's certainly possible in most cases to use machine learning to make an AI agent more competent in terms of simply maximizing its own gameplay skills, this is usually not what we want -- our primary goal is to entertain the player and give our AI agents personality (in the case of computer opponents) or to construct our behaviors entirely for the purpose of supporting the human player (in the case of AI sidekicks).

As the saying goes: there is no fitness function for "fun."

Posted by: Paul Tozour at June 29, 2008 08:44 AM

Interesting points. I posted similarly about how game ai is more than just basic algorithm implementation... http://justinsboringpage.blogspot.com/2007/10/avoiding-ten-common-game-ai-mistakes.html

Posted by: sunny beach at June 29, 2008 01:17 PM

I am sincere when I say that I have the skills and abilities listed under "Generalize, Before Specialize", possibly only the bullet on defensive coding being an exception. How do you code defensively (beyond understanding asserts) against problems you’ve yet to experience?
As you might have guessed this is a student’s perspective. The problem I see with entry level AI programming is constantly the same one. Companies have a limited AI staff, all composed of senior developers. Experienced and worn in, but there is no quantifiable way to measure qualifications. How much does one need to know about game architecture? Should I be able to code my own rendering engine, coupled with an understanding of their optimizations? How much further deeper does my understanding of the STL and Data Structures need to be that is not covered by Game Gems and several small projects of use? And what if I presented a research paper with a complete UML of a game engine that more extensive than Game Code Complete?
My point is that it’s deceiving to assume that the qualifications listed under “Generalize, Before Specialize” are enough to by by-pass the entry level dilemma that is “experience”.
On the other hand I took much more kindly to the two sections that followed as they provided advice for those who are looking to go from an entry level position to one that they might feel more passionate towards.
I only hope that I lend an opportunity to work on tools for AI, so I can at least achieve a level of mentoring to eventually, confidently, apply for the only position available for AI programmers; Senior AI Programmer.

Posted by: Michael Kofman at June 29, 2008 07:53 PM

"How do you code defensively (beyond understanding asserts) against problems you’ve yet to experience?"
Posted by: Michael Kofman at June 29, 2008 07:53 PM

C++ is capable of implementing several idioms that can turn run-time errors into compile-time errors. This way, if another programmer uses your code in a way which goes against it's design (and hence probably untested behaviour), they won't even be able to compile their code.

The RAII idiom is probably a good introduction to this kind of "safe" usage of C++.

Posted by: ActionMan at June 29, 2008 08:44 PM

> [Michael Kofman]
> How do you code defensively (beyond
> understanding asserts) against problems you’ve
> yet to experience?

Great question! There are lots of ways to use the language features to rule out certain types of potential errors or force the compiler and the linker to notify you when certain kinds of defects occur. Off the top of my head, some of the more important ones are:

* Passing parameters by reference instead of by pointer in cases where the parameter should never be NULL (since the compiler helps ensure that references should never be NULL)

* Writing const-correct code (I can personally recount many war stories of times when ensuring proper const-correctness has found critical bugs and saved my hide)

* Using various types of managed pointers (such as one of the different flavors of "smart" pointers, or an auto_ptr class like the STL's implementation) to ensure proper memory management and automatically avoid the potential for memory leaks

The best advice I can give is to read Scott Meyers' "Effective C++" ...

http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1214838857&sr=8-1

... and Herb Sutter's "C++ Coding Standards":

http://www.amazon.com/Coding-Standards-Guidelines-Practices-Depth/dp/0321113586/ref=pd_bbs_6?ie=UTF8&s=books&qid=1214838857&sr=8-6

> [Michael Kofman]
> How much does one need to know about game
> architecture?

You should understand the general framework.

> [Michael Kofman]
> Should I be able to code my own rendering
> engine, coupled with an understanding of their
> optimizations?

Generally, no. If you're aiming towards a specialization in graphics in the long run, it might be a good idea to do more work in this area, but by and large, the industry is not expecting you to be John Carmack. For entry-level engineers, it's more important to have a solid understanding of 3D math techniques (cross product, dot product, vector math, matrix multiplication, etc) than to understand the minutiae of rendering engine optimization techniques.

> [Michael Kofman]
> How much further deeper does my understanding
> of the STL and Data Structures need to be that
> is not covered by Game Gems and several small
> projects of use?

You should try go gain as thorough an understanding of all of that as possible, especially the data structures you'll use most often as a game developer throughout your career (vectors and lists).

> [Michael Kofman]
> And what if I presented a research paper with a
> complete UML of a game engine that more
> extensive than Game Code Complete?

I haven't worked with any studios that used UML to any significant extent. I think a well-written code sample/demo is much more important.

> [Michael Kofman]
> My point is that it’s deceiving to assume that
> the qualifications listed under “Generalize,
> Before Specialize” are enough to by by-pass the
> entry level dilemma that is “experience”.

I'm an developer writing this to try to help other developers get into the AI development profession, make meaningful contributions, and help build the future of game AI. No one is trying to "deceive" anybody. I can't make any guarantees that this will be "enough" to get anyone into the industry; there's no way for me to know in advance what every company is looking for.

My point with that part of the post was to define the skills an engineer needs as a basis before any amount of specialization is possible, and to emphasize that doing a lot of work as a generalist, and working on many parts of the game and the engine, is almost always a prerequisite for that.

Posted by: Paul Tozour at June 30, 2008 08:29 AM

Thanks for a great article Paul, and:


don't be afraid to ask the interviewer for help with it -- the interview is partly a test of how you handle pressure


is advice I'm taking home with me, along with the advice on coding defensive- which I'm taking to heart as a student.

One question: what's your take on the worth of creativity versus programming abilities? Say, for instance, the ability to produce good ideas/solutions versus the ability to implement them. Does one weigh more than the other when applying for a job in AI dev, in your opinion?

Posted by: Hrafn Th. at July 17, 2008 07:23 AM

> One question: what's your take on the worth of
> creativity versus programming abilities? Say,
> for instance, the ability to produce good
> ideas/solutions versus the ability to implement
> them. Does one weigh more than the other when
> applying for a job in AI dev, in your opinion?

Creativity is always important. However, it's essential for developers to get a solid foundation in the existing techniques for game AI development so they can focus their energies on extending those techniques and addressing the big, unsolved problems. Otherwise, it's too easy to end up reinventing the wheel, or grasping for novel solutions for problems that have already been solved.

Posted by: Paul Tozour at July 24, 2008 04:46 PM