Image 01

21st Century AI

A blog about achieving meaningful Artificial Intelligence

Posts Tagged ‘John Laird’

Dinosaurs, tanks and line of sight algorithms

Sunday, July 14th, 2013

A screen capture of MATE (Machine Analysis of Tactical Environments). Note the blue armor unit (labeled '0') just left of the center of the screen. Click to enlarge.

A screen capture of MATE (Machine Analysis of Tactical Environments). Note the blue armor unit (labeled ’0′) just left of the center of the screen. Click to enlarge.

MATE screen capture showing the calculated line of sight of Armor Unit 0 (click to enlarge).

MATE screen capture showing the calculated line of sight of Armor Unit 0 (click to enlarge).

 

Adjusting the height of an object in MATE to calculate its line of sight.

Adjusting the height of an object in MATE to calculate its line of sight.

(This article is cross-posted in my “Dinosaur Island” blog).

My doctoral research involved ‘computational military reasoning’¹, a phrase that I coined that means, “computers making tactical combat decisions.” My research was supported in part by DARPA (Defense Advanced Research Projects Agency, the people that really invented the internet). I was able to demonstrate in my MATE (Machine Analysis of Tactical Environments) program that a computer could make what computer scientist John Laird, called, “Human-Level” decisions and could do so very rapidly (see here for more information about MATE). Indeed, my friend, retired Lieutenant Colonel Mike Robel, once said that a computer Course of Action (COA) program like MATE was vitally important because “it’s hard to make your best decision when someone is trying to kill you.”

When I first began working on the design of Dinosaur Island I joked with some colleagues that the AI (Artificial Intelligence) wouldn’t be too difficult as I would just use my MATE program and cross out ‘tank’ and insert ‘triceratops’. There is some truth to that, as we will see today.

One of the first AI routines that I’m adding to Dinosaur Island enables the dinosaurs to find food and water. How does a dinosaur do this? Well, there are actually three ways that a dinosaur finds food and water:

  1. The dinosaur looks around for food or water.
  2. The dinosaur smells food or water.
  3. The dinosaur remembers where it last found food or water.

Right now we’re interested in the first option: looking around (this will also come in handy for spotting predators, too). How does a computer dinosaur ‘look around’?

Luckily, I’ve already solved this problem some years ago in grad school with TIGER (the predecessor of MATE). The solution is a 3D Bresenham line algorithm (I’m not going to write out the algorithm because you can see it here). The Bresenham line algorithm was invented by Jack Bresenham in 1962 when he was working at IBM and it was originally used for controlling a pen plotter (a type of printer that would pick up colored pens with a mechanical arm and draw on rolls of paper). However, if we have a 3D landscape (and we do in Dinosaur Island), we can take Bresenham’s two dimensional algorithm and extrapolate it into three dimensional space to determine if the terrain blocks an object’s view in a particular direction. If we do this in all 360 degrees and plot what can be seen (and what is obscured) we’ll have an image like the second screen shot, above.

Now, in MATE, I had to add a little dialog box so the user could input the height of the observer (the third screen shot showing the height of a tank). But in Dinosaur Island I realized that not only the height of every dinosaur can be calculated (just like the length and weight) but that taller dinosaurs, like the giant sauropods, might have a great advantage because they’ll be able to see farther. This will help them find food and water and see predators before the predators can see them.

Next, I’ll work on the ‘smell algorithm’ which will involve wind direction and speed. Luckily, I solved that problem a long time ago with a game/simulation I did in 1989 called, “UMS II: Nations at War.”

SmallRule

1) My doctoral thesis, “TIGER: An Unsupervised Machine Learning Tactical inference Generator,” can be download here. TIGER was an earlier version of MATE.

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.