There will be a lot of significant memory usage optimizations in the next update, so I'm hoping that that's going to fix it.
Recent community posts
If you click on the filename or the little eject arrow, it opens up a dropdown view of all of your savefiles that you can then choose from. I'm going to have it open by default in the next update.
I can't really give you that option within the release version of the simulator (other than maybe implementing different ones myself and just letting you select the one you want), but if you like, you can clone the source code from my Github and play around with that yourself. There's a Mutate method in the Evolution class that takes two parent chromosome strings and returns two offspring chromosomes, so that would be the only thing you'd have to change.
The project is not open-source - I'm currently not looking for collaborators and you can't redistribute the code so essentially all the regular copyright stuff applies - but feel free to experiment and play around with the code for any kind of personal or educational use! You can also send me an e-mail if you have problems with running the project or have any other questions. It might take a little while before I can answer because I'm a little busy at the moment, but I'll try to respond as quickly as I can. As a sidenote, I used Unity 2017.4.0 for the latest released version and haven't tested to see if anything is potentially broken in Unity 2018.2, so I'd recommend getting the 2017.4.0 version from the archives in case you want to edit the project.
Thanks! No, there is no manual learning rate or enforced convergence that I have control over. All algorithms are exactly the same no matter the size and complexity of the network. I have seen a few impressive results with networks that were significantly larger than the default setting, but I haven't found a clear guideline to consistently achieve that.
On the topic of manually editing save files: Here's a fantastic video that offers a lot of insight into how the save files are structured and how you can even edit them by hand if you know what you're doing.
1. + 2. The distance to reach 100% fitness is set by me pretty arbitrarily. I just decided on distances that would be quite hard to reach with most creature designs (that aren't glitched out). So the fitness is just the percentage of this arbitrary distance that your creature managed to travel in the given time (where the max distance is also scaled by how much time you give the creature - so if you give them twice as much time, they would need to travel twice as far to get the same fitness score).
The selection probability is proportional to the fitness (Fitness Proportionate Selection - Wikipedia). So if you have 4 creatures that all reach a 1% fitness score, they are each going to have a 25% chance of being selected for each necessary recombination step.
3. The brain is a simple feed-forward neural network. Each node takes all of its inputs, multiplies each one with a weight (the weights are the things that are optimized during the simulation and they determine the behaviour), adds them all together and runs that result through a so-called activation function (1 / (1 + exp(-x)) which calculates the output of this particular node. 3Blue1Brown (on YouTube) made some really good videos on Neural Networks recently, so I'd definitely recommend to check them out. The whole topic is pretty math-heavy though.
4. I've definitely seen better results that way than having it the other way around (e.g. 5-20-100) but I've seen even better results with a more balanced node distribution. You're right, there are lots of deep neural networks, for example for pattern recognition, that are setup with decreasing weights per layer but in this case that doesn't seem to be the optimal solution. Maybe it can actually produce better results but only after a very long simulation.
I only store the brain of the best creature in its chromosome representation, i.e as a string, which is an immutable object in C#, so there is no way for me to accidentally modify it without replacing the whole thing. On top of that, I have also already tested and confirmed that the creature in the "best of"-screen always has the exact same brain it had during the simulation.
In theory, the fitness should never decrease if the "keep the best creature" setting is turned on, but yes, I have also seen this happen. I currently attribute both of these problems to the fact that Unity's physics system (which the whole simulation is based on) depends quite a lot on random external variables - such as frame rate drops - and given its approximative nature isn't as deterministic as it should be.
I'm trying to optimize the performance as much as I possibly can for the next update in order to get rid of any potential performance spikes that might interfere with the physics system. I unfortunately can't change the physics system itself so there is a certain performance limit that I can possibly optimize to. If you create tons of creatures with a bunch of body parts each, the physics system is by far the main reason for the extreme lag that you will see, and there's pretty much nothing I can do about that, which sucks. I can't even hardware-accelerate it, even though the fact that none of the creatures collide with each other is a perfect basis to parallelize those physics calculations on the GPU.
These updates are great!
Possibly another small and easy to implement improvement: Add a quick link to a project's community page from the dashboard, for example in the "more" dropdown under "interact". That would be awesome.
When the "Keep best creatures for the next generation" option is selected, the chromosome / brain of the best creature is copied over to the next generation without any mutation. It might even be the best two creatures - I don't quite remember that right now. But they are definitely not altered in any way.
There will definitely be more updates in the future but it's also going to take a while before I have time to work on it again. I really only have a couple of weeks every year to spend on this. This project isn't and has never been my primary focus, but it's also not going to be abandoned any time soon :)
I explained what the latest state of that bug is over here: https://itch.io/t/150983/somthing-seems-off-in-the-pick-best-creature-algorithm-...
Effectively, the bug isn't that the best creature isn't being selected correctly, but that the best creature sometimes decides to just not repeat what it did really well in the previous generation, even though it has the exact same brain as before. Makes the whole thing much much more complicated to try to fix.
Hmm, the only info I could have given you on that is that all of those unzipped files (Evolution.exe, Evolution_Data and UnityPlayer.dll) need to be in the same folder, but you said that they already are. There's also nothing else I can find that might be causing this issue. The last time I tested the Windows build everything worked fine. I downloaded the .zip, unzipped it and then ran the .exe
Maybe someone else who uses Windows as their main OS and has had this problem before can help you out.
You can use the middle mouse button to pan the camera when building a creature (Or use two fingers if you are on mobile).
I don't know why I haven't added scroll to zoom yet, especially since it's just one line of code. It's going to be part of the next update, thanks!
Yeah, the distances in the simulation aren't really comparable to real life distances. They are only useful if you want to compare different creatures to each other.
As far as Unity and the physics system is concerned, the creatures are actually massive and the muscles are extremely powerful. Gravity is set to -50m/s² (in Unity meter units). I had to play around with these values a lot to get both natural looking behaviour and to get rid of as many unexpected physics bugs as possible.
So the fact that in the creature stats I write meters, doesn't mean actual meters. It's just because if I wrote "Average speed: 5 units/s" everybody would be asking what this arbitrary unit is, whereas its only purpose is to give you a comparison between creatures.
I really like this one! Do you maybe have the option to rerecord this at a higher framerate? If it's a performance issue you could try to set it to simulate in batches of 1 while you record, to make it a little easier for the CPU. Or you could send me the savefile to firstname.lastname@example.org if possible and I could try to record a gif on my machine.
If none of that is possible, I'll just use this gif, but I feel like the motion is too good to be displayed at only ~8fps.
1. https://stackoverflow.com/a/44421935/6214222 Company name in this case is "Keiwan Donyagard", product name is "Evolution"
2. You can take a look at the code, if you want. You need to scroll down to the UpdateInputs function in each Brain implementation. Here's the running brain for example. https://github.com/keiwando/evolution/blob/master/Assets/Scripts/Brains/RunningB..
3. The mutation variable determines the percentage of creatures that get mutated per generation. So if you have 10 creatures about 5 will be mutated during the recombination step. I say "about 5" because the actual number of mutated creatures is still random, based on a uniform distribution.
4. No, since the mutation rate works on a per-creature basis.
5. By group you mean have them expand and contract at the same time? Currently no, but maybe in the future (It's not very likely though)
6. I'm not too sure what exactly you mean by that? Something like this? https://arxiv.org/pdf/1706.03702.pdf
7. Since the last update there is now an option to visualize the amount of muscle contraction / expansion per muscle, which is effectively nothing other than the network output for that muscle.
8. No, the network gets randomly initialized every time you start a new simulation.
9. If you click on the little screen in the top right that says "Best of Gen..." you can view the best creature from any previously simulated generation.
10. On that same "Best of Gen" screen, you'll find some stats about the best creature of the previous generations, including the distance travelled. I might add little markers to the simulation screen to indicate the current distance sometime in the future.
Thanks a lot for the kind words!
I can see the the problem, but it's unfortunately not very straightforward to fix, without at least compromising in some other areas and possibly even breaking existing designs.
If I add an absolute limit to the minimal and maximal length of the muscles, that wouldn't really fix your problem, since the "global" max limit (that applies to all muscles) would have to be much bigger than you want, in case that you do need to use a longer muscle somewhere in your design.
If I use relative limits (e.g I say the muscle can only stretch to 200% of its original length within the design) then that will limit behaviour of your creatures in a lot of designs where you wouldn't expect it. For example, if you had to place two bones together at a small angle, but then wanted a muscle between the two to expand far enough to create a very large angle, the muscle wouldn't be able to do that, which would make it seem like it's not strong enough.
The best way I can currently think of to incorporate this would be to add general options to each individual muscle, where you could adjust stuff like this (relative expansion/contraction limits, force...) on a per-muscle basis. That way I could keep the current muscle settings as a default but also allow you to do some adjustments if you like.
However, that's going to take quite a bit more time to implement as compared to just slapping a fixed, non-adjustable limit on every muscle, and since I currently barely have any time to spend on this project I can't say how long it's going to take me (probably a few months) or if it's going to work out at all - I might come across some unexpected issues and would have to scrap this idea.
Yeah, that's definitely one of the first things I want to try in the future when I find the time. I'm interested to see how much I can increase the performance by offloading all of the network calculations from the CPU to the GPU, since those calculations are all naturally parallelizable anyway.
Currently the only option you have if you want the benefits of a larger population size and you're okay with trading in the time it takes to simulate a single generation, is to simulate your generation in batches that your CPU can handle at once.
I just released a linux version with the latest update.
However, I won't be offering any linux specific support or extensive testing of this linux build because I don't have the resources for that. Also as a heads up, there is a bug in the current version of Unity that causes every keystroke into an input field to be registered twice in linux builds [see here], which is quite annoying. I'm probably going to rebuild the linux version once they fix it.
Most of the tasks require a slightly different set of inputs, so the creature brains are not interchangeable between different tasks. (The same design needs a different type of brain for almost every different tasks)
Also, the even if the inputs were all the same, the creature still wouldn't be able to learn multiple skills and then "choose" based on the task it has to fulfill. It would have to unlearn the first skill and then learn the new task, which effectively ends up being the same as how it currently works anyway.
The stats are available for the best creatures of previous generations. You can switch to that view by clicking the little screen in the top right corner (during simulation) that says "Best of Gen..."
I already tried the Time.timescale approach but unfortunately it messes up the physics system causing the creatures to behave and move differently when everything is sped up, which ruins the whole simulation.
If anybody knows a different way I could implement a speedup that doesn't break the physics in Unity I would definitely give it a shot.