Do you have a particular type of game in mind? I ask because I find thinking in simplified terms makes some of the 'hard maths' easier to grasp and I wonder if that is the cause for the question.

Have the player in some sort of vehicle and the robots give chase. They robots make alterations to their chase pathways based upon their interpretations (Kalman filter) of the players' moves. The robots could have a limited sampling rate which changes as the player advances.

I note that this would be the opposite of a self-driving car inasmuch as the robots would be trying to collide with the player . . .

Or, were you looking for a more practical example? (i.e. How does one implement XXX for a game?)

Kalman Filters seem a good fit for client side prediction in multiplayer games. Usually you can just use basic dead reckoning to predict and display the actual current positions of remote players from their last known positions and velocities. Using a Kalman Filter you could save significant bandwidth by letting the client calculate a decent approximation of the velocities from the stream of positions alone.

In fact halfway through writing the above I googled and found this:
http://www.springerlink.com/content/f61155364tj12042/

I can't speak to Histogram filters, Kalman filters or Particle filters, but I know that Astar (unit 4) is used in video games (I've used it myself). My best guess on the filters is that they are only useful if you need bots that don't cheat and have to figure things out for themselves, but I think that's rare in most video games.

Usually ai in games do not need localization to figure out where they are, they have direct access to their current location. However, for example if you were making a stealth game where the ai agents were trying to find the player without cheating, you could use histograms or particle filters for the ai to localize the player.

I wondered if you could get a racing game and, using a program entirely external to the game get it to drive around the track from the same outputs you get as a human driver (screenshots, forcefeedback, audio too I suppose if you can do anything with that)

Then I suppose you could go the expensive route and build a robot to use a physical wheel and pedals or cheaply simulate the inputs using a "virtual" wheel and pedals that fooled the game there was a real direct input wheel attached to the computer.

But, for the case where you are writing a game and the AI is part of that game I'd say that noisy sensors and so on that kalman et al are solving aren't happening. Why use a kalman filter to predict velocity if the game knows exactly where players are standing and where the AI is, and where they are moving to and where movement is precise?

But a robot that could sit and play Team fortress 2, in the same way a human player does, would be a fun project I'm sure - and as I said, you could start without needing any hardware just a PC to run the code outputting the keyboard / mouse movements.

It'd probably get banned though if you used it online without getting permission from the developers (or sticking to your own private servers)

One problem with AI is that in, say, an FPS game you have to program the AI to miss the player in a realistic way (hitting the player is the easy bit) - perhaps if you did separate AI from the game and went down the route of analysing each frame of video output and using filters to predict enemy movement and so on, you might create something that felt far more realistic to play against than your typical in-game AI.

Team fortress 2 has some fancy movement where players can fly across the world map by shooting their own rockets at their feet when jumping - the AI in game, generally just run around on the ground, it would be interesting to get the AI to use the skillful movement to get around the map that the best human players do. You might need drivers that let you output stereo images to process to figure out distances to do that kind of thing.