Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

Hi again and thanks for explaining. I've been testing the optimization branch and I have some data points:

If I load my best save file (creature in the first video) into the optimization branch then during the first 3 generations from the save point the creature will invariably deteriorate to sub-11 speed. Then, by generation 4 from the save point, I will consistently get the "crazy" distance-from-start numbers. This will continue for each generation after that point, i.e., there won't be any "sane" gens in between (as I get with the master branch). In the video below (of the optimization branch) the loaded save file was gen 6830 created by the master branch:

So, for my creature, the optimization branch will have deteriorating behavior and "crazy numbers" as the rule (instead of the exception as is the case with the current master branch).  This happens no matter what I try, in terms of colliders, isKinematic, and  various other things I looked into. The only way to fix the distances is to eliminate SetActive(False). But then the physics change and there is no evolution (30% fitness after 7000 generations - I let it run over the weekend since it doesn't crash now).

But, if in evolution.cs I switch back to killgeneration() instead of resetcreatures() then I get the same behaviour as that of the released version (I later noticed that you have a related comment in the master branch). When I say the same behaviour, the "crazy numbers" also show up albeit with the same frequency as for the released version:


What I think is happening:

The SetActive(False) is necessary to keep the physics right (for some obscure reason) but, under some condition, it messes up the object's Transform(?) so that the position returned later on in best.GetStatistics() is garbage. The master branch destroys and creates new objects so a "messed up" Transform will not persist into the next generation. But the resetcreatures() of the optimization branch preserves the actual objects. Once a Transform is "ruined" it will carry over into the next generation. So the best creature in every generation after that will have the "crazy" distance-from-start numbers. 

The overall deterioration of the creatures (with components all over the place for gen 6846 in the video above) suggests that the destruction and recreation that goes on in the KillGeneration() of the master branch helps to mask an inherent problem with reusing the objects after deactivation/activation?

What is needed is some way to "reset the physics" between generations but without deactivating? This may even be a Unity issue, it makes no sense that commenting out the SetActive calls  in SimulateGeneration() changes the creatures so much.

I fixed the weird glitches that happened on the Optimization branch yesterday. (I also upgraded the project to Unity 2018.2 and reorganized the scripts a little bit). It's all merged into the master branch at the moment, if you're still interested. Thanks again for confirming the TextMesh instructions, they worked for me as well.

The problem was that I had forgotten to also reset the MuscleJoint rigidbodies when resetting the bones, which caused them to disconnect and glitch out.

I'm now working on the next big release with tons of new features that I'm very excited about.  

Thanks! Just gave that newest master branch a try  and it works great. 

And there is no longer a need to merge the "evolution-core" branch for the compile. Everything will be in evolution from now on?

Looking forward to the next release!

Yes, I removed the evolution-core submodule and re-integrated all the scripts into the same repository. Man, was that submodule annoying to work with.

The only reason why the "evolution-core" submodule existed at all was because I played around with making a "true" 3D version of this simulator (possibly with AR integration) in a separate app and I wanted to reuse most of the existing scripts. The submodule allowed me to do just that but it was still a significant overhead. If I ever decide to make a 3D version of this, I'll just add it to the current app (it's probably not going to happen though).