Fitness for (Flying) Machine Movement

[schrum2]

We need some way to measure how close we are getting to a flying machine. Extend the CheckBlocksInSpaceFitness class in a new BlockMovementFitness class.

I'm not sure what the best approach to this will be, but here is my idea. The fitnessFromBlocks method that needs to be overridden is defined in such a way that the blocks sent in could have been what the CPPN generated before being instantiated in the world (no need to read the blocks from the world). However, the corner gives you the ability to read the blocks from the world itself to see where they are, as done by the CheckBlocksInSpaceFitness.readBlocksFromClient method.

So, what we can do is impose a mandatory wait time (set by a command line parameter) at the start of the fitnessFromBlocks method that gives the blocks a chance to move. After the delay, read how the blocks are actually positioned in the world, and then compare the original block list to the updated block list in some way. If the lists are identical, then the score should be 0. However, we have to watch out for the fact that the order of the blocks in the lists could be different even though they represent the same shapes.

One blocks list should probably be read into a 3D array first (as in DiversityBlockFitness). Next, loop through the other blocks list, and every time the blocks differ, add a point? Maybe just the difference in block counts could be used. Perhaps this issue actually needs two different fitness functions to be defined. We need to explore options.

This fitness function should probably have unit tests as well. It will be tricky to tell if it even works.

[richeyme]

As of right now, the flying machine only works when it is implemented/spawned in the exact same way as it is done in example.py (not sure if this is because of orientation of the blocks or the position that it is placed in). It has had no luck otherwise, which may trip us up later when trying to have the AI learn how to make the flying machines itself.

[schrum2]

We'll keep BlockMovementFitness around, but make a new ChangeInCenterOfMassFitness.

Before doing this, we have to make sure we have a way of generating the shapes with a lot of space between each one. First, remove the SPACE_BETWEEN in MinecraftClient, and instead, wherever it is used, get the value from a new command line parameter "spaceBetweenMinecraftShapes"

Once this works, you can make the ChangeInCenterOfMassFitness and test it with a large value of "spaceBetweenMinecraftShapes". Basically, the center of mass is the average across all x/y/z coordinates of the blocks, and you can calculate the distance between the starting center of mass and the ending center of mass

[schrum2]

This new fitness function will eventually need unit tests too, and you can make some unit tests without even involving the Minecraft server. Just create two sets of different blocks to compare and calculate the center of mass of.

[richeyme]

It seems like this fitness function is calculating the fitness score correctly. I tested on a stagnant shape and a functioning flying machine and it gives the respective scores of 0 and 17.88889 (there are far more decimals but it's about that much). Not sure if it needs further testing of not

[schrum2]

Clean up all the individual tests so that the project is able to Maven install. Try to clear up warnings as well, such as the use of ff instead of static access. When comparing floating point values, provide some small epsilon range in which the result can vary

[richeyme]

Looking over the test one more time, the change of center of mass fitness function seems to working consistently.