search

schrum2 / MM-NEATv2

MM-NEAT version 2.0 is no longer supported. Please get MM-NEAT 3+ from https://github.com/schrum2/MM-NEAT
Other
11 stars 5 forks source link

Inability to destroy enemy base #418

Closed schrum2 closed 7 years ago

schrum2 commented 7 years ago

I feel like a lot of these agents fail to destroy the enemy base. In fact, there is a general problem with getting stuck in the a corner with certain tree search agents. This seems to be an issue with tree search, and not just our evolved agents (the opponent IDRTMinimax agent was doing it).

First, I want you to look at the technical reports on this agents, and see if this phenomenon was ever witnessed by other researchers. Is this simply a problem that certain tree search agents have? Did they have a way of getting around it?

I also want you to pit some tree search agents against each other in a 12 by 12 map using the GUI Frontend from the original code. What does it look like when IDRTMinimax goes against MLPSMCTS, or itself for that matter? Try out different evaluation functions as well. Do they exhibit this weird behavior of geting stuck in the corner? Report on your findings in this GitHub issue's comments.

Lastly, I have some ideas on how to help the evolved agents close in on the base more, but I want to wait until you finish the reporting asked for above. Expect more details on this issue later.

alicequint commented 7 years ago

IDRTMinimax got stuck in a corner MLPSMCTS with simpleSqrtEval3 did not get stuck at 100 or 60 time budget MLPSMCTS with simpleSqrtEval1 sometimes got stuck in a corner both with 100 and 60 time budget

schrum2 commented 7 years ago

Let's make a new type of input substrate like the terrain substrate, but designed to replace it. This substrate will account for enemy bases and obstacles, but not resources (those must still be sensed separately).

The idea is to have a value of 1 at the spot where the enemy building is, and a value slightly less (0.95?) in all adjacent squares, and a value slightly less (0.95 * 0.95) in all squares adjacent to those, and so on covering the whole screen (0.95^d where d is the number of steps removed from the enemy building(s)). This approach would lay down a gradient on the map that would make it easy to find a path to the enemy buildings.

These inputs would not change frequently, so we should compute the values once and save them, then only ever update them if either a new building appears or an old one is destroyed.

alicequint commented 7 years ago

gradient paths to the bases are implemented on a substrate activated by parameter "mRTSObjectivePath"

alicequint commented 7 years ago

i have a batch file running which has the first confirmed-functional version of objective path, if post watch and the fitness plots reveal that it works well, this issue can be closed

schrum2 commented 7 years ago

Are Base and Barracks really the only two types of buildings? Just wanted to be sure.

Additionally, make sure you visually confirm reasonable gradient behavior on maps of all sizes.

Lastly, see how the gradient performs when there are terrain obstacles. I don't think you are currently incorporating this. but terrain should be treated as deadzones and base cases for the gradient, so that the gradient only spreads out along paths that can be followed.

schrum2 commented 7 years ago

Reopened since the issue of gradients around terrain was not checked yet, as far as I know.

alicequint commented 7 years ago

base gradient works now,