Map AI so far....

[Druid2]

Upgraded to Netscape 4.6 last nite, and now the applet runs fine.

I have no idea what it's doing, mind you.

But if it's supposed to put numbers in the map squares, it's running fine. *LOL*

[Rebel]

Druid:

And here I thought I was the only one that was totally lost in the woods.

Rebel

But seriously, it looks like it is doing a great job of figuring the intensitys, at least i hope that is what it was doing.

BTW, am running 98,communicator 4.5, on an AMD K6/350 and the applet seems to run fine.
Just to let you know that it does run on other processors.

Rebel

[Blade Runner]

Rebel,

I use AMD too (K6-II 300). I plant to change K-7 as soon as possibile. (IMHO the best processor of the century) ;-)

Blade Runner

[Druid2]

JimC,

[I cant get the app to run this morning, so I'm commenting on what I remember from the last time.]

As I remember it, the app goes on calculating the intensity value for each square, eventually, it will fill the entire displayed area until the goal is reached.

A) This suggestion involves some "pseudo-hueristic" pruning of the squares you need to calculate. "Pseudo" because in some cases, you will have to go back and re-activate the pruned branches.

After you've gone out n squares in each direction, you prune out the least desirable 50% of the squares. The you go about finishing the path calculation.

Only if the remaining paths lead to dead ends do you go back and calculate the already eliminated 50%.

Of course it wont be perfect; sometimes you'll wind up taking a "longer" path. But that would only be when the path goes in the "wrong" direction at first because there's a dramatic increase down there somewhere.

B) Also, I didnt try to look at the details of each loop, but this occurred to me as I was watching the numbers appear on the squares. If there are 3 squares [x(1), x(2), x(3)] , all of which could lead to square y, does the app calculate the value for each of the x(i)to y paths? or only for the most desirable of the x(i)?

Again, a compromise down from the "pure AI" maximized path, but a reasonable way of cutting down the number of iterations.

C) This one is more problematical, but might be a real time-saver if it can work. It is based on expanding particular paths, instead of calculating a value for a square. I cant explain it without an example [and maybe I cant explain it WITH an example ]:

The path is to be from X to Y, over some distance. X is roughly south of Y. Lets assume that a human would consider 3 paths: one heading NE from X and working back to Y, one heading N from X to Y, one heading NW from X and working back to Y.

As the app gets n squares out from X, you make the first path pruning. You identify the most desirable, 2nd most and 3d most desirable. I'll give them arbitrary values: [low value=more desirable]
1st = 2000, 2nd=3000, 3rd=4000 of "desirableness". {wrong term, but I want to purposely stay away from the ones you've used, in case I use them wrong.}

The concept is that there is now no reason to consider expanding any path except the 1st, until the value for path1 exceeds 3000 [the path2 value], then you need to expand them both. If either exceeds 4000 [path 3 value], you go back to expanding only one, until they are all over 4000.

Then you go back and get the path4 [path 4=5000, for example]. you continue expanding path 1,2 & 3 until one of them exceeds 5000.

At that point you continue to expand the paths until ALL of them are over the path4 value, or you get to the objective, etc etc.

[This is, to the degree I remember it, a swipe of some thing I saw in trying to do the "Knights Tour" on a chessboard.]



[This message has been edited by Druid2 (edited June 08, 1999).]

[Mark_Everson]

Druid:

I think you need to read the description in the link in my first post in this thread to know what's going on. This intensity thing is using multiple paths spanning different parts of the map to find the strategic spots like isthmuses (You know, the ones people block off in civ, but the AI has No clue about). The path intensity calculation will be run in the background, so it won't slow the game down. Doing this work in the background should actually make unit pathfinding easier and quicker.

[Druid2]

Mark,

Aw *CHIT*

I said all along, I didnt grok the intensity thing.. *LOL* at myself.

But if this is in background, and available when the moves are being determined, then I dont understand the 'tileless' movement problems...

Communication by forum post is NOT the best way.. *L*

[JimC]

bump....

Just in case anyone wonders where I've been - I'm working on a Genetic Programming package that may be of some use to this project.... who knows.

Jim

[Mark_Everson]

Hey Jim:

I was wondering, but hey, people have Lives and stuff . I'd certainly like to see your package when its ready.

-Mark

[JimC]

It's pretty much finished, but I'm doing some extensive modifications to prevent the computer 'cheating'

examples - multiplying a subtree by -1 twice, then claiming that it's a good mutation because a high fitness value has been maintained

or - 'fudging' the integer value 0 by taking the sin of a random value about 10 times

or - mutating a value which has been multiplied by 0 and claiming it as a valid mutation

etc. etc....

It doesn't seem to like running under the Hotspot JIT for some reason - I've sent a bug report to JavaSoft and it will hopefully be sorted out in the next release.

That's all for now.

Jim