Skip to main content

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

PilotFlying

7
Posts
1
Following
A member registered Sep 20, 2018

Recent community posts

Yes, it does glitch out in both 2.0.3 and 2.0.4 (Windows x64)

Thanks, I'll send you a small file of the simulation run, I believe you can get the creature from there? Two files in fact, the first is of the creature before some slight changes which made the glitches significantly worse. Maybe these changes (bone length if I recall) will give a hint.

I can still get the glitch below, with the latest master branch.


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!

About the TextMesh, I can confirm that these steps work (all help text shows up after project conversion)

(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.

(1 edit)

File is on the way, thanks! See also more notes below.

About the TextMesh Pro: No help text shows up in my build, not even English! It's not a matter of just deleting.
(Never used Unity, I don't know what TextMesh does. I tried deleting it because I got errors for conflicting dll's in that folder).

Restoring the MAX_DISTANCE and removing the clamp works as you suggested. Apparently you have also been spot on with the expected "physical limit". At least for my creature. It's improving only marginally to about 11.50 m/s after 1000 generations. This conclusion might be contingent on the bug though:


About the bug, I think it has to do with the call creature.gameObject.SetActive(false); in SimulateGeneration(). I think because the sort in EndSimulation() is done on the currentGeneration and not currentCreatureBatch (which apparently is used even when settings.simulateInBatches is false?),  the joint.transform.position returns garbage later, when GetXPosition() is called on the best creature, because the best creature has already been set inactive and the transform.position is undefined? 

If I comment out this SetActive(false) call, there is never a case of "crazy" numbers for a generation - even when compiling the Optimization branch, for which the crazy numbers would happen all the time. 

Problem is, when removing this call my speeds also go much lower. From 11.50m/s to around 8.5m/s, even though on screen the creature seems to be travelling as fast. I don't understand enough about the code to figure out if the lower speeds might in fact be the correct ones. They do improve though: i.e., the same creature that did 11.5m/s and then fell to 8.5 m/s does go up to 9.3m/s in a few generations (whereas before removal of SetActive(false) , the speed would not evolve). 

All this testing was done without batches activated. 

Thanks again!




In the running task, my creature sometimes gets a very high speed. I think it is related to a wrong  "vertical distance from start". 

I compiled the latest Optimization branch on github (64-bit, Unity version 2018.2.8f1, I had to completely delete the folder Assets\TextMesh Pro to get it to compile). The Optimization branch greatly increases the frequency of this bug. Perhaps something to do with the "transform.position" call in "CalculateBasicBrainInputs()"? 

As an aside, I think the Optimization branch does fix the high memory consumption.

Another aside: I looked into compiling my own because I wanted to increase the MAX_DISTANCE from 55. I think once you get 100% fitness,  at an equivalent speed of 11 m/s, evolution stops (the best creatures sort is not effective) and I wanted my creature to keep improving. I don't understand how some people got speeds much higher than 12 m/s in some gifs, unless it was a one-off or the design happened to be great to begin with. Point is that once you have a pool of 100% fitness evolution becomes random and not driven by performance?

Thanks for this great simulator!