jcbrockschmidt / agario_a-life Goto Github PK

Oftentimes, the behavior of each blob will change drastically when a simulation is reloaded. This most likely means a flaw in the current saving and loading scheme that has been implemented.

This glitch presents itself in the code in the master branch. The secondary branch does not have this same glitch. The latter branch will probably overwrite the master branch eventually.

This issue has gone under two titles. Both are listed below, from newest to oldest.


Blob Brains Outputting Enormous Numbers:

Blob brains occasionally output huge numbers. For the most part, these neural networks seem to behave themselves. However, every once and awhile every blob's brain's neural network begin unanimously output huge numbers to all output nodes. There exponents are typically close to 220 (scientific notation) for some reason.


Majority of Blobs Move to the Right:

As of updating the fitness function for blobs, virtually all blobs in a world seem to uniformly move the right. Testing consistently showed that the removal of fitness = pow(peakSize,4.0)+timeAlive; caused this disturbance. Replacing such with the mathematically identical code fitness = (peakSizepeakSizepeakSize*peakSize)+timeAlive; did not seem to remove this behavior, despite output confirming that the two has virtually identical output. Furthermore, replacing it with fitness = pow(peakSize,2.0)+timeAlive; produced the same undesirable uniform behavior. But, oddly enough, replacing the code with lines like fitness = pow(peakSize,2.00001)+timeAlive; did not disrupt the simulation.

Understand that changing the fitness function is expected to bring behavioral changes. However, this effect should be over time. The start of any two simulations with different fitness functions should produce an equally random set of blobs.

Function for loading a save file does not seem to throw a premature EOF exception when it should.

There appears to be a reoccurring out of range error while calling sim::kill. In other words, sim::kill is being called, asking to delete a blob that is not in the population. This error could also mean the that the wrong blob is being killed off in some cases.