Make Larger Flying Machines

[schrum2]

We have a batch file that will try to evolve 5x5x5 flying machines, and it sort of succeeded once in that it produced tiny flying machines that flew away from the large mass of blocks. However, we want to have large structures that fly.

It is not clear how to do this. We may need to change the fitness function, and/or the MAP Elites binning scheme. Think of ideas along these lines, and maybe even make new issues as you come up with ideas to attempt.

However, the first thing to check is this: Try running your current big machine batch file for longer.

Change maxGens:60000 to maxGens:100000 in the batch file and run overnight on some machines to see what happens.

[schrum2]

The Piston Orientation behavior characterization makes use of a parameter minecraftPistonLabelSize whose default value is 6. This means that if a shape has 6 or more pistons along a given access, they are all binned the same by MAP Elites (no distinction between 6, 7, 8, etc). This was fine for 3x3x3 shapes, but might be a limitation for 5x5x5.

Make a new batch file for big shapes that copies the old one, but call it BigMinecraft-VectorPistonOrientation10Dim.bat. The minecraftPistonLabelSize in this batch file should be 10 and you need to add "Dim10" to the log and saveTo parameters as well.

Let this run on a couple of machines to see what happens.

[schrum2]

Extending the run-time to 100000 seems like it may have found a slightly larger flying machine. Will report more later. However, another long run failed, so more thorough experiments are needed. In the meantime, experimenting with the minecraftPistonLabelSize is still a good idea.

[schrum2]

I did a run with 10 dim, and it produced flying machines, but they were still small. We need a way to measure the number of blocks that are moving, so that moving more blocks gets more fitness.

I have an idea that involves looking at the history of the shapes, and doing a sort of set difference that reduces each step to only the blocks that change, so we can track how many are actually moving and multiply the distance by that amount. This is basically a measure of momentum. However, I need to do some refactoring in ChangeCenterOfMassFitness first, so this is on hold for a moment.

[schrum2]

I thoroughly refactored ChangeCenterOfMassFitness, so we should be able to move forward with this option. It basically changes code in the ChangeCenterOfMassFitness class in the calculateFinalScore method, providing a different way to increase totalChangeDistance (which should be renamed to a more general name) inside the for loop.

[schrum2]

881 Is partially addressing this using a fitness that counts the number of blocks that change on each read of the shape. This does not incorporate any information about covering distance though, so there may still be a need to incorporate this aspect of the fitness. In fact, the easy way to do it would be with a boolean command line parameter than slightly changes the calculation used by ChangeBlocksFitness

[schrum2]

Here is what is needed before this issue can be closed:

Have a boolean parameter: "minecraftChangeBlocksMomentum"

In ChangeBlocksFitness, if "minecraftChangeBlocksMomentum" is true, then the following line is different:

fitness += shape1.size() - shape1minusShape2.size();

What this line currently does is add the number of changed blocks to the fitness on each reading. This option still needs to be supported, but if the new boolean option is selected, then instead of just adding the difference, multiply that difference by the change in center of mass. getCenterOfMass is in MinecraftUtilClass, and you can apply it to both shapes and then get the distance between.

[TjRaffert]

I made those changes, and we are going to run it over the weekend.

[schrum2]

Make a batch file to run ChangeBlockFitness with the new direct encoding #899

[schrum2]

Although we are still working on the best way to get larger flying machines, we have some progress, and this issue has splintered into sub-issues tracked elsewhere.