Monday, April 30, 2007
My experiences writing AI software for vehicle control in games and virtual reality systems
I have in the past offered advice in the comp.ai.games news group re: AI control of vehicles. Here are a few short notes based on some experience that I have had. I have had the good fortune of getting to spend a fair amount of time (both on my own, and while being paid) writing code to control vehicles in games, etc.:
* Writing example code for my book AI Agents in Virtual Reality Worlds
* Working on the Indy 500 car simulation system at SAIC. I actually worked on the motion platform control, network programming, and sound system software. For this project, you always raced against other people, also in simulators.
* At Angel Studios working on 2 Nintendo games and a PC-based hover craft racing game.
Anyway, I do have some advice on how to write AI driving opponents:
The first thing that you want to do is to define data structures for navigational "way points" that AI vehicles follow and simply have the vehicles move between these "way points". If possible, AI controlled vehicles should use the same physics simulation code as the player's vehicle (at least when the AI vehicle is close and in the player's field of view).
After your AI controlled vehicles can move along using "way points", then, based on the game theme, add logic for detecting the proximity of the player's vehicle (e.g., AI vehicle might swerve into the player's vehicle under specified circumstances), etc. Do not bother with complex behavior if a vehicle is not in the rendered scene for a player.
It should be fairly easy to get the code running to follow way points, but that is definitely your first step. Combining driving logic control with "lerping" between weigh points will also make the vehicles look a lot more realistic while more or less keeping them where you want them.
When possible, your movement logic should depend heavily on where the AI vehicle is in the player's field of view. For efficiency, it might be expedient to use simple finite state machines for the control logic. However, I have experimented (again, see my book) with using expert systems, neural networks, and genetic algorithms. For Java programmers, my book "Intelligent Java Applications" contains a (not practical, but fun!) example of using genetic algorithms to train simple control programs in an "asteroids" style arcade game.
Good luck, and have fun!
* Writing example code for my book AI Agents in Virtual Reality Worlds
* Working on the Indy 500 car simulation system at SAIC. I actually worked on the motion platform control, network programming, and sound system software. For this project, you always raced against other people, also in simulators.
* At Angel Studios working on 2 Nintendo games and a PC-based hover craft racing game.
Anyway, I do have some advice on how to write AI driving opponents:
The first thing that you want to do is to define data structures for navigational "way points" that AI vehicles follow and simply have the vehicles move between these "way points". If possible, AI controlled vehicles should use the same physics simulation code as the player's vehicle (at least when the AI vehicle is close and in the player's field of view).
After your AI controlled vehicles can move along using "way points", then, based on the game theme, add logic for detecting the proximity of the player's vehicle (e.g., AI vehicle might swerve into the player's vehicle under specified circumstances), etc. Do not bother with complex behavior if a vehicle is not in the rendered scene for a player.
It should be fairly easy to get the code running to follow way points, but that is definitely your first step. Combining driving logic control with "lerping" between weigh points will also make the vehicles look a lot more realistic while more or less keeping them where you want them.
When possible, your movement logic should depend heavily on where the AI vehicle is in the player's field of view. For efficiency, it might be expedient to use simple finite state machines for the control logic. However, I have experimented (again, see my book) with using expert systems, neural networks, and genetic algorithms. For Java programmers, my book "Intelligent Java Applications" contains a (not practical, but fun!) example of using genetic algorithms to train simple control programs in an "asteroids" style arcade game.
Good luck, and have fun!
Labels: AI in games
Tuesday, April 17, 2007
Something like Google page rank for semantic web URIs
A key idea of the semantic web is reusing other people's URIs - this reuse forms interconnections between different RDF data stores. The problem, as I see it, is that while URIs are unique, we will end up with a situation where (as an example) there might be thousands of URIs for NewsItem. The Swoogle semantic web search engine is useful for finding already existing URIs - a good first step toward reuse.
Swoogle will return results using their type of 'page ranking'.
So, we need two things to accelerate the adoption and utility of the semantic web: web sites must start to include RDF and this included RDF must reuse common URIs for concepts and instances.
Swoogle will return results using their type of 'page ranking'.
So, we need two things to accelerate the adoption and utility of the semantic web: web sites must start to include RDF and this included RDF must reuse common URIs for concepts and instances.
Labels: semantic web
Monday, April 09, 2007
Great Overview of Knowledge Representation
Bill Clementson mentioned Conrad Barski's new open content article on Knowledge Representation. Nice! Conrad provides not only a great overview, but just as important, the motivation for treating Knowledge Representation as a science.
Labels: knowledge representation
Sunday, April 01, 2007
Defining AI and Knowledge Engineering
Our own intelligence is defined by our abilities to predict and generalize. As Jeff Hawkins points out, we live our lives constantly predicting what will happen to us in the next few seconds. (See Numenta.com - Hawkin's company - for the source code to NTA hierarchical temporal memory system.)
We also generalize by learning to recognize patterns and ignore noise.
AI systems need to implement prediction and generalization, and do this in a way that scales so that we can move past small toy problems. Scalability is most important in prediction because of the size of data required to model the environment that an AI will live in and the real time requirements (prediction does us little good if the calculation takes too long).
Knowledge Engineering is not AI, it is the engineering discipline for the understanding and re-implementation in software of human level expertise in narrow problem domains.
We also generalize by learning to recognize patterns and ignore noise.
AI systems need to implement prediction and generalization, and do this in a way that scales so that we can move past small toy problems. Scalability is most important in prediction because of the size of data required to model the environment that an AI will live in and the real time requirements (prediction does us little good if the calculation takes too long).
Knowledge Engineering is not AI, it is the engineering discipline for the understanding and re-implementation in software of human level expertise in narrow problem domains.
Labels: knowledge representation, neural networks
Subscribe to Posts [ATOM]
