Missile vs Flying interference #955
Comments
|
Only 1 out of 3 SmallTNT runs produced a flying machine, and it did so fairly late. I'm running a batch of plain small now to see if maybe there is an issue with the direct encoding or some other setting after all. In theory, these should succeed better than the vector-to-volume GECCO batch, but maybe not? |
|
The direct encoding for small plain flying machines is incredibly successful. They all produce flying machines fairly quickly, which is great, but it makes the problem of producing flying machines with TNT all the more daunting. As a start, I suppose I'll simply try evolving for longer. |
|
The latest batch of SmallTNTFly runs have actually been a bit more successful at generating flying machines, though many have flown vertically, and they are not transporting TNT, and why would they? I guess there needs to be a fitness that specifically measures the change in center of mass of just the TNT blocks to see if they are moving. |
Added the option to filter out all blocks except TNT blocks before doing change in center of mass calculations. We want to see how much the TNT moves, not how much other blocks move. Though I wonder how the exploding blocks will be treated. What if there is no TNT?
SmallTNTFlyTNT may need a better name later, but for now it is what checks for the movement of TNT blocks.
|
Testing out the idea of tracking TNT movement right now |
|
It is a bit harder to create flying machines when just tracking TNT movement, but it is possible. The SmallTNTFlyTNT runs produced some flying machines, but no missiles yet. Missile MOME has also failed. Now I am trying MOME with Missile fitness vs the change in center of mass of the TNT, so measuring the flight of only the TNT blocks. We'll see what happens. |
Support for sequentially stacking fitness results from different fitness functions has been added. Specifically, the fitness score is the result of adding individual fitness scores together, except that later scores are not added unless earlier scores pass predefined thresholds. Since selection is not fitness proportional, this means that weighting the objectives is no longer necessary. The specific test here is to see if it helps to only reward fitness for destroying targets AFTER shapes are capable of flying. The chosen fitness threshold should mean that the score of any shape is simply the ChangeCenterOfMass up until a point when the shape can fly, after which point a bonus from actually destroying targets could be incorporated. Note that the specific batch file being tested also requires that the shape have moving TNT blocks (simply flying without moving TNT around does not count).
|
Seeing what happens if you can't get any missile fitness until after you are flying |
|
Still not really working, so now I'm combining the restriction of not getting any missile fitness until the shape is flying with the idea of a soft archive from Mat Fontaine's MAP Annealing paper. There is a new batch file for running this test. |
More tests are needed, but I think the Missile fitness is messing with selection too much and preventing flying machines from emerging. I'm doing tests right now of pure fly fitness but with the missile block set to see how hard it is for flying machines to emerge. It can take a while.
I might just need to let evolution run longer, which I thought I had ruled out. However, here is another option:
In a multiobjective setting, define missile fitness so that it is always 0 unless the machine is flying. Note sure how hard it will be to detect that information across fitness functions, but the idea of treating missile fitness as 0 until the machine flies should at least encourage flying machines as quickly as having no missile fitness at all.
The text was updated successfully, but these errors were encountered: