Image 01

21st Century AI

A blog about achieving meaningful Artificial Intelligence

Posts Tagged ‘A Star’

T. rex (AI) successfully locates and hunts prey on Dinosaur Island.

Thursday, August 1st, 2013

A T. rex named George successfully found, tracked, pursued and attacked an Edmontosaurus named Julie. Click to enlarge.

A T. rex named George successfully found, tracked, pursued and attacked an Edmontosaurus named Julie. Click to enlarge.

This blog is reposted from my Dinosaur Island blog here.

It has been said that nobody wants to see how politics or sausages are made. Artificial Intelligence (AI), for some, may also be added to that list. Today’s blog topic is about achieving an important milestone in the AI behind Dinosaur Island: a T. rex ‘looked’ around his virtual world (using a 3D line of sight algorithm), spotted potential prey (an Edmontosaurus regalis named Donna) pursued it using an optimized A* least weighted path algorithm that avoided steep slopes and boggy terrain (the attack was up hill) , then saw a more attractive target (an Edmontosaurus regalis named Julie), changed his pursuit and successfully overtook the prey.

This AI is unique and probably the first time such a series of events has been demonstrated in a 3D virtual world environment. Below are step by step screen captures showing the events:

Screen capture with all AI tracing turned on. There are three dinosaurs in this image. George sees Donna (dark red line), Donna is looking almost due east (dark red line) at the forest of Araucaria trees where she wants to go to eat, the cloud of yellow is the AI looking at alternative paths for Donna to climb up a hill, Julie is also looking at the same forest of Araucaria trees to her northeast and the AI (yellow path) has plotted the best route for her to climb the hill. (Click to enlarge).

Screen capture with all AI tracing turned on. There are three dinosaurs in this image. George sees Donna (dark red line), Donna is looking almost due east (dark red line) at the forest of Araucaria trees where she wants to go to eat, the cloud of yellow is the AI looking at alternative paths for Donna to climb up a hill, Julie is also looking at the same forest of Araucaria trees to her northeast and the AI (yellow path) has plotted the best route for her to climb the hill. (Click to enlarge).

This screen capture taken 10 seconds later shows Donna approaching the Araucaria forest to the east and Julie climbing the hill towards the same forest to the northeast. George now sees that Julie is the closest prey and switches his attack to her (dark red line) and races toward her. (Click to enlarge).

This screen capture taken 10 seconds later shows Donna approaching the Araucaria forest to the east and Julie climbing the hill towards the same forest to the northeast. George now sees that Julie is the closest prey and switches his attack to her (dark red line) and races toward her. (Click to enlarge).

 

Ten seconds later, George has closed the distance and has attacked Julie from the flank. (Click to enlarge).

Ten seconds later, George has closed the distance and has attacked Julie from the flank. (Click to enlarge).

It’s important to remember that Dinosaur Island will ship in full 3D; these screen shots are of the AI testing environment which is in 2D.

Now that we have created a ‘perfect killing’ AI we will have to make it ‘stupider’ by adding distractions and imperfections.

Pathfinding, Academia and the Real World

Thursday, July 15th, 2010

“When game developers look at AI research, they find little work on the problems that interest them, such as nontrivial pathfinding, simple resource management and strategic decision-making, bot control, behavior-scripting languages, and variable levels of skill and personality — all using minimal processing and memory resources. Game developers are looking for example “gems”: AI code that they can use or adapt to their specific problems. Unfortunately, most AI research systems are big hunks of code that require a significant investment of time to understand and use effectively.”
- John Laird, “Bridging the Gap Between Developers & Researchers”

Pathfinding is a least-weighted path graph problem. There, I said it.

My plan for this blog was to keep it at a fairly high level of abstraction and not to use terms that would scare away computer game designers who, for the most part, feel about math the way vampires feel about garlic (or silver or crosses depending on which particular form of vampire fiction you’re reading this week). But, yeah, pathfinding (which is an important part of RPGs, wargames and even sports games) can be reduced to well researched and well understood mathematical problem.

Computer game designers (or programmers) usually work in a grid; that is to say their world (or battlefield, or playing field) can be represented by a two-dimensional matrix. Though we often think of a graph as a tree-like object, a two-dimensional matrix in which every cell is connected to its neighbors (e.g. a battlefield, RPG world, football field, etc.), can also be represented as a graph.

So, as a computer game programmer, why do we care that RPG worlds can be represented as a graph? Well, it turns out that there is an algorithm that can be mathematically proven to return the shortest path between two points in a graph. Now, if you’re not a computer game programmer you’re probably saying, “well, if they’ve got this whole shortest path thing worked out, why is that half the time in a game when I tell my player to go from Point A to Point B it gets stuck behind a wall or a rock or something trapped like a doofus?”  And the answer to that is: because the programmer didn’t use a guaranteed least weighted path algorithm.

The reason that we refer to this type of an algorithm as a “least weighted path” algorithm is because we can give a ‘weight’ representing the ‘cost’ of moving from one cell (or square) to the next cell (or square). For example, we might say that moving ‘north’ through ‘clear’ terrain costs 1, and moving northeast through a swamp costs 3 and moving east through a forest costs 2, etc. So we’re not really talking about a ‘fastest’ path or a ‘shortest’ path, but, technically, the path with the lowest ‘movement costs’ or weight. Does that make sense? If it doesn’t, drop me an email and I’ll explain it, hopefully more clearly, in another post.

And now let’s look at the reasons why the programmer didn’t use a guaranteed least weighted path algorithm:

  1. Speed. The oldest guaranteed least weighted path algorithm is commonly known as Dijkstra’s algorithm. It was first discovered by Edsger Dijkstra in 1959 and there is a very good explanation of how it works (complete with animation) here. Dijkstra’s algorithm is taught in every undergrad AI class. It’s not very complicated and it’s easy to implement (in fact, it’s usually an assignment by the middle of the semester). So if the “fastest path from Point A to Point B in a computer game” problem has been solved why doesn’t everybody use Dijkstra’s algorithm? Good question. The reason that computer game programmers don’t use Dijkstra’s algorithm is that it is an “exhaustive search” (which means that it has to look at every possible path) and then determines the fastest route. In other words, it’s sloooooow. Really, really slow.
  2. Time. I’m not talking game development time – though often the problem is simply that the game publisher is forcing the game ‘out the door’ before it’s really completed – I mean ‘clock cycles’ or there isn’t enough time for the computer to both render all these polygons that represent explosions and mountains and whatever and for the computer to do AI calculations. AI is constantly getting short shrift when the CPU budget is being determined.
  3. Ignorance. There’s another solution to the “least weighted path problem” known as A*; pronounced ‘A star’ (I once had the temerity to ask Nils Nilsson, one of the authors of A* what the ‘A’ stood for and he replied, “algorithm;” and now we all know).  Thankfully, Amit Patel has done a great job of explaining A* (with lots of graphics) here, so I don’t have to. Again, I’m not going to get into the math behind A* but I am going to leave you with this mind-blowing statement, “the guaranteed worst-case runtime of A* is the best-case runtime of Dijkstra’s algorithm.” What did he just say? That Dijkstra’s algorithm will never return a least weighted path in less time than A*. So, you should be asking, “well, why doesn’t everybody  use A* instead of Dijkstra’s algorithm?” The answer, as crazy as this sounds is, A* is rarely, if ever, taught in academia. What?!?!? Yeah, there is a weird prejudice against it because Dijkstra solved the problem way back in ’59, it is a mathematically proven solution, so why bother with anything else?

You see in Academia, especially in computer science which is usually a department inside the division of mathematical science, RAM and runtime are often thought of as ‘infinite’ commodities. I suspect that this way of thinking about problems stems, in part, from Turing’s theoretical machine which had infinite RAM (an infinite strip of paper) and an infinite amount of time to solve a problem. Unfortunately, those of us that live and work in the ‘Real World’ have neither infinite RAM or time. We need algorithms that return solutions fast.

Lastly I would like to mention  Dimdal’s work on optimizing A* in “Real World Terrain” situations. I wrote a paper about it which is available here. I use a modified version of Dimdal’s modification of Nilsson’s A* for my own pathfinding routines in TIGER. The result is an extremely fast least weighted path algorithm that takes a fraction of the time to calculate as Dijkstra’s algorithm or A*.

And now you know the difference between academia and the real world and why your character in an RPG gets stuck behind a bunch of rocks acting like a doofus.