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 PMHi 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 ....
> [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 AMInteresting 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 PMI 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.
"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 AMThanks 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?
> 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