How much graphics stuff to learn before starting to learn game AI ?
Hi,
I would like to start learning game AI and have looked at "Programming game AI by example" to be my first book since it is highly rated and it seems to be for beginners too (beginners in AI that is). I know C++ fairly well (I use C++ Primer 3rd ed. by Lippman as my reference and have been satisfied with it) and DirectX9.
My question is, how much of the graphics part do I need to learn before starting in AI. I already know how to display a scene using a 3D API with lights and textured meshes (static and skinned) and cull them using octree spatial partitioning and know the basics like transformations. Are these enough?
Before, I really wanted to dive into graphics programming but seeing that graphics advances so fast (for me at least) that sometimes you need a good graphics card just to learn things like shaders. And seeing that graphics related things get abstracted anyway by either API's, engines, or some form of utility library (e.i D3DX) that it feels like there isn't too much of a reason for me to re-invent the wheel (main example are the D3DXMath and D3DXMeshes + X files). And most importantly, I believe that dynamic AI's will contribute a lot in gameplay than just aiming for better (more realistic) graphics.
Well, basically that's my reason for going to the AI scene. Guys, I would also like to hear advice regarding some issues in learning AI (pitfalls, considerations etc.) aside from my initial question.
Thank You very much and I apologize for the long post.
you don't need to know any graphics to program AI. What I think you are asking though, is "if i'm doing everything myself, how much graphics do i need to be able to work on my AI".
It depends on what you're doing. For instance, to work on a high level tactical AI for an RTS game you don't need anything more than the ability to draw a 2D top-down scene with a bunch of squares running around representing your guys. Similar actually for an FPS except then you'd also want a 3D scene in which cubes can run around.
You'll find that you need a lot of simple Linear Algebra; which is also requisite knowledge for graphics...
Otherwise I guess the biggest conceptual difference between Game AI and graphics is this: Graphics is typically a lot of front-loaded work whereas a huge amount of the AI work is back loaded. With graphics you typically work out a really elegant and optimized base data structure/ architecture of some sort. After that you're just coding relatively simple shaders and effects to actually make it pretty. With AI you typically get a little simple skeleton up really fast. The bulk of the work doesn't happen until all your sub-systems come online and you have to make them all work together in harmony.
Biggest pitfall with game AI is complexity. Your instinct is to actually model what you, the player, does. This is generally a pretty bad approach since you're not going to get your brain into code. Always strive for simplicity: is tehre a way to get the desired complex effect through a combination of a couple really simple inputs? Can you get the illusion of intelligence somehow without that intelligence actually being there?
Also remember that the point of game AI is not to be amazingly smart, the point is to support the game mechanics. If it's a sniping game entities should frequently stand still; if it's a stealth kill game entities should perhaps hang out near shadows. Basically game AI often does "dumb" things. If i were a guard and some dude was running around with a sniper rifle killing all my friends I'd always keep moving and rarely put my head above cover. That's not a lot of fun to play against though. =) The art comes in when you can make the AI vulnerable to game mechanics and still appear intelligent.
-me
It depends on what you're doing. For instance, to work on a high level tactical AI for an RTS game you don't need anything more than the ability to draw a 2D top-down scene with a bunch of squares running around representing your guys. Similar actually for an FPS except then you'd also want a 3D scene in which cubes can run around.
You'll find that you need a lot of simple Linear Algebra; which is also requisite knowledge for graphics...
Otherwise I guess the biggest conceptual difference between Game AI and graphics is this: Graphics is typically a lot of front-loaded work whereas a huge amount of the AI work is back loaded. With graphics you typically work out a really elegant and optimized base data structure/ architecture of some sort. After that you're just coding relatively simple shaders and effects to actually make it pretty. With AI you typically get a little simple skeleton up really fast. The bulk of the work doesn't happen until all your sub-systems come online and you have to make them all work together in harmony.
Biggest pitfall with game AI is complexity. Your instinct is to actually model what you, the player, does. This is generally a pretty bad approach since you're not going to get your brain into code. Always strive for simplicity: is tehre a way to get the desired complex effect through a combination of a couple really simple inputs? Can you get the illusion of intelligence somehow without that intelligence actually being there?
Also remember that the point of game AI is not to be amazingly smart, the point is to support the game mechanics. If it's a sniping game entities should frequently stand still; if it's a stealth kill game entities should perhaps hang out near shadows. Basically game AI often does "dumb" things. If i were a guard and some dude was running around with a sniper rifle killing all my friends I'd always keep moving and rarely put my head above cover. That's not a lot of fun to play against though. =) The art comes in when you can make the AI vulnerable to game mechanics and still appear intelligent.
-me
Good post Paladine
Also, just so you know, Mat gives you in this book a little framework to display entities in 2D. From the background you come from, I'm pretty sure you know more than enough to have a convincing demo :) If you feel lazy though, feel free to use Mat's code.
If you want to take a look at the code and binaries, they're available here.
By the way, Mat is "fup" on the boards, so if you've got questions about the book, feel free to post them here :)
Cheers
Also, just so you know, Mat gives you in this book a little framework to display entities in 2D. From the background you come from, I'm pretty sure you know more than enough to have a convincing demo :) If you feel lazy though, feel free to use Mat's code.
If you want to take a look at the code and binaries, they're available here.
By the way, Mat is "fup" on the boards, so if you've got questions about the book, feel free to post them here :)
Cheers
Quote: Original post by Palidine
Also remember that the point of game AI is not to be amazingly smart, the point is to support the game mechanics.
Unless you are implementing a chess game or something similar.
Just my 2 Cents :)
June 22, 2006 11:13 PM
Quote: Original post by Palidine
Otherwise I guess the biggest conceptual difference between Game AI and graphics is this: Graphics is typically a lot of front-loaded work whereas a huge amount of the AI work is back loaded. With graphics you typically work out a really elegant and optimized base data structure/ architecture of some sort. After that you're just coding relatively simple shaders and effects to actually make it pretty. With AI you typically get a little simple skeleton up really fast. The bulk of the work doesn't happen until all your sub-systems come online and you have to make them all work together in harmony.
-me
You might investigate graphics more (as being used in games and as being planned for the latest games). Graphics too can be 'back ended' when after the graphics engine is complete (much like an AI engine) you then still have to provide all the data (graphics content). Look at how much work it takes to build the meshes, skeletons, textures, animations, effects, behavior scripts (to integrate/coordinate/sequence).
Yes AI takes alot of data built upon a common engine (and its symbolic form makes it less efficient to manipulate/create), but you might find that it is also true for game graphics.
June 22, 2006 11:22 PM
Quote: Original post by KuroKage
Hi,
I would like to start learning game AI and have looked at "Programming game AI by example" to be my first book since it is highly rated and it seems to be for beginners too (beginners in AI that is). I know C++ fairly well (I use C++ Primer 3rd ed. by Lippman as my reference and have been satisfied with it) and DirectX9.
My question is, how much of the graphics part do I need to learn before starting in AI. I already know how to display a scene using a 3D API with lights and textured meshes (static and skinned) and cull them using octree spatial partitioning and know the basics like transformations. Are these enough?
Before, I really wanted to dive into graphics programming but seeing that graphics advances so fast (for me at least) that sometimes you need a good graphics card just to learn things like shaders. And seeing that graphics related things get abstracted anyway by either API's, engines, or some form of utility library (e.i D3DX) that it feels like there isn't too much of a reason for me to re-invent the wheel (main example are the D3DXMath and D3DXMeshes + X files). And most importantly, I believe that dynamic AI's will contribute a lot in gameplay than just aiming for better (more realistic) graphics.
Well, basically that's my reason for going to the AI scene. Guys, I would also like to hear advice regarding some issues in learning AI (pitfalls, considerations etc.) aside from my initial question.
Thank You very much and I apologize for the long post.
You can do a game with alot of AI and have the player interaction be completely in text form.
Graphics are useful for data visualization and to facilitate input and can bring a more natural flow of information from the program to the player.
But you dont need pretty glitzy graphics to communicate the information and can use simpler forms (like using billboards instead of fully 3D meshes of objects). Fully realistic physics arent always needed as long as the simulation's important datas can be presented sufficienly.
Consider also that graphics engines are on the market which can greatly simplify your use of 'graphics' as a data representation method. You only have to learn enough about creating the visualizations you require without having to create the engine/tools yourself (dont have to understand the internals).
Quote: Original post by Anonymous PosterQuote: Original post by Palidine
Otherwise I guess the biggest conceptual difference between Game AI and graphics is this: Graphics is typically a lot of front-loaded work whereas a huge amount of the AI work is back loaded. With graphics you typically work out a really elegant and optimized base data structure/ architecture of some sort. After that you're just coding relatively simple shaders and effects to actually make it pretty. With AI you typically get a little simple skeleton up really fast. The bulk of the work doesn't happen until all your sub-systems come online and you have to make them all work together in harmony.
-me
You might investigate graphics more (as being used in games and as being planned for the latest games). Graphics too can be 'back ended' when after the graphics engine is complete (much like an AI engine) you then still have to provide all the data (graphics content). Look at how much work it takes to build the meshes, skeletons, textures, animations, effects, behavior scripts (to integrate/coordinate/sequence).
Yes AI takes alot of data built upon a common engine (and its symbolic form makes it less efficient to manipulate/create), but you might find that it is also true for game graphics.
I'm pretty sure he was talking about the programming side of view. You'll have artists to build these meshes, skeletons, etc... but all the logic within the AI will have to be written by programmers.
Hi again,
Thanks a lot guys for all the replies! I would like to ask a few more questions.
(1) I've heard that the reason why some AI in games aren't so good is because AI requires a lot of processor cycles and that making them do complex stuff actually compromises the framerate. Is this true?
Just to cite an example, in RTS games, if you know that the enemy attacks you at a certain direction (say, North West) and you've put a lot of defenses in that area, they would still go there, thus getting wasted. They don't search if there are any openings in your base and attack there. In action games (Onimusha, DMC), they very much have a pattern that anyone can easily get to counter. If they get rid of that pattern, I believe that It will dramatically increase the gameplay. But then again, only if AI computations isn't too taxing for the processor.
(2) Regarding the whole graphics thing, if it's a fighting game, wouldn't a cube be insufficient to test an AI? Maybe because there are a lot moves involved that the cube is unable to represent clearly. Wouldn't the AI programmer at least need to know how a skinned-mesh character is created (even if there are no textures, as long as it is humanoid in shape) and how to manipulate the bones (via quaternion interpolation perhaps)? Though I already know this using the .X format, I would just like to know if this is perhaps the case.
Thanks again in advance.
Thanks a lot guys for all the replies! I would like to ask a few more questions.
(1) I've heard that the reason why some AI in games aren't so good is because AI requires a lot of processor cycles and that making them do complex stuff actually compromises the framerate. Is this true?
Just to cite an example, in RTS games, if you know that the enemy attacks you at a certain direction (say, North West) and you've put a lot of defenses in that area, they would still go there, thus getting wasted. They don't search if there are any openings in your base and attack there. In action games (Onimusha, DMC), they very much have a pattern that anyone can easily get to counter. If they get rid of that pattern, I believe that It will dramatically increase the gameplay. But then again, only if AI computations isn't too taxing for the processor.
(2) Regarding the whole graphics thing, if it's a fighting game, wouldn't a cube be insufficient to test an AI? Maybe because there are a lot moves involved that the cube is unable to represent clearly. Wouldn't the AI programmer at least need to know how a skinned-mesh character is created (even if there are no textures, as long as it is humanoid in shape) and how to manipulate the bones (via quaternion interpolation perhaps)? Though I already know this using the .X format, I would just like to know if this is perhaps the case.
Thanks again in advance.
Regarding 1...
Patterns are there because players need to know what its enemy's gonna do to some extents (might be multiple patterns, blended patterns, etc...). Games wouldn't be much fun if you wouldn't have a clue what the AI's gonna do. It might be challenging, but not that fun.
Regarding 2...
It depends on what your goals are. Printing out on the screen the move the cube is currently playing seems sufficient to me. You probably don't want your moves to rely on assets, so it would be defined somewhere (config file, script, hardcoded, what ever) that move X is triggered by input I and has a range R, spawns effect E and does D damage... The demo will be way less entertaining than fully animated characters, but you can build your entire gameplay without having assets.
Now, if you want to do something like a clone of Dead or Alive 3, get ready for some action... it will require that you have synchronization between your characters, inverse kinematics, etc... if what you want to show off is AI, you'd better aim for something like Street Fighter or Mortal Kombat.
Hope this helps
Eric
Patterns are there because players need to know what its enemy's gonna do to some extents (might be multiple patterns, blended patterns, etc...). Games wouldn't be much fun if you wouldn't have a clue what the AI's gonna do. It might be challenging, but not that fun.
Regarding 2...
It depends on what your goals are. Printing out on the screen the move the cube is currently playing seems sufficient to me. You probably don't want your moves to rely on assets, so it would be defined somewhere (config file, script, hardcoded, what ever) that move X is triggered by input I and has a range R, spawns effect E and does D damage... The demo will be way less entertaining than fully animated characters, but you can build your entire gameplay without having assets.
Now, if you want to do something like a clone of Dead or Alive 3, get ready for some action... it will require that you have synchronization between your characters, inverse kinematics, etc... if what you want to show off is AI, you'd better aim for something like Street Fighter or Mortal Kombat.
Hope this helps
Eric
Good AI isn't so much a matter of CPU power as it is design.
Far Cry is the best example I have. It's AI is very sophisticated and I would imagine chews up a fair number of clock cycles . . . but the characters in the game don't behave all that intelligently. They have a tendency to stray into the line of fire. Sure, they'll jump behind cover and signal their teammates, but three seconds later they'll walk back out and let you shoot them in the face.
F.E.A.R. uses a much more elegant solution: split the team up and make them very patient. Enemies in F.E.A.R. never run into your line of fire. They try to catch you off guard by following different paths to your location. They look considerably smarter than the mercenaries in Far Cry, simply because the designers took a different, simpler approach. F.E.A.R. also runs better overall, at least on my machine.
It's true that a great deal of work has been offloaded from the CPU onto dedicated hardware (video cards, sound cards, and now AGEIA physics cards). This lets programmers devote more power to interesting things like AI . . . but in the end it boils down to design. How efficient your AI turns out is entirely up to you. And Palidine is absolutely right: it's more important that your agents look smart. Players who never see your code won't know the difference.
On-topic but not directly related to your post, I'd like to give a couple pointers when you develop your low-level AI (the part of your game engine that handles AI). The two most time-critical aspects of AI processing are path-finding and object acquisition. By object, I mean objective, as in goal targets (items to grab, switches to pull, people to shoot, etc.). These two components will be hard-coded into your engine and hopefully highly optimized. They'll also take advantage of space partitioning in your map data in much the same way your renderer processes only the potential visible set, and not the entire level.
That last part might be a bit confusing. Bottom line is, path-finding and sensory response are your AI bottlenecks. You can script everything else, provided the interpreter is fast. Or you can hard-code everything, though this limits extensibility. By the way, if you want to take a look at the scripts that govern Far Cry's AI, you can download the SDK. You don't need a copy of the game to install it.
Far Cry is the best example I have. It's AI is very sophisticated and I would imagine chews up a fair number of clock cycles . . . but the characters in the game don't behave all that intelligently. They have a tendency to stray into the line of fire. Sure, they'll jump behind cover and signal their teammates, but three seconds later they'll walk back out and let you shoot them in the face.
F.E.A.R. uses a much more elegant solution: split the team up and make them very patient. Enemies in F.E.A.R. never run into your line of fire. They try to catch you off guard by following different paths to your location. They look considerably smarter than the mercenaries in Far Cry, simply because the designers took a different, simpler approach. F.E.A.R. also runs better overall, at least on my machine.
It's true that a great deal of work has been offloaded from the CPU onto dedicated hardware (video cards, sound cards, and now AGEIA physics cards). This lets programmers devote more power to interesting things like AI . . . but in the end it boils down to design. How efficient your AI turns out is entirely up to you. And Palidine is absolutely right: it's more important that your agents look smart. Players who never see your code won't know the difference.
On-topic but not directly related to your post, I'd like to give a couple pointers when you develop your low-level AI (the part of your game engine that handles AI). The two most time-critical aspects of AI processing are path-finding and object acquisition. By object, I mean objective, as in goal targets (items to grab, switches to pull, people to shoot, etc.). These two components will be hard-coded into your engine and hopefully highly optimized. They'll also take advantage of space partitioning in your map data in much the same way your renderer processes only the potential visible set, and not the entire level.
That last part might be a bit confusing. Bottom line is, path-finding and sensory response are your AI bottlenecks. You can script everything else, provided the interpreter is fast. Or you can hard-code everything, though this limits extensibility. By the way, if you want to take a look at the scripts that govern Far Cry's AI, you can download the SDK. You don't need a copy of the game to install it.
GDNet+. It's only $5 a month. You know you want it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement