I would highly recommend watching Grant Sanderson's video on neural networks. He visualizes everything beautifully:
Recent community posts
It does take you to the room, I just tried it myself with the macOS version to double check. If you close the book and then pick it up again from the location that was shown to you in the search menu, it will be the exact same book that you just closed.
If for some reason this doesn't work for you, then please let me know (including what exactly I have to do to reproduce the problem).
Hi Bruno, it always makes me really happy to hear that this little simulator is being used for educational purposes, thanks for that!
The "fitness" score in this simulation is perfectly correlated to the creature's proficiency at the task. For example, the fitness score for the running task is computed as the horizontal distance from the start divided by a maximum distance value that a creature would have to reach in order to receive a perfect score of 100%. This maximum distance has been arbitrarily chosen by me. It obviously also scales with the simulation time of each generation, so that increasing that time doesn't make it any easier for the creatures to achieve a higher fitness score.
During the reproduction step, two creatures are selected and their chromosomes are recombined using 1-point crossover, which produces two new offspring. This step is repeated until the new generation has reached the chosen population size. Creatures with a higher fitness score have a higher chance of being selected as parents for reproduction and since the same creature can also be selected multiple times, the fitness score of a creature effectively contributes to the number of offspring that will carry part of the genetic information of this parent creature into the next generation.
I might allow the user to select between different selection and recombination strategies in a future update, in order to offer a few more options for everybody to experiment with.
I use TextMesh Pro to be able to inline images into the help text. It seems like I have to go though a whole process to upgrade the project to make sure TextMesh Pro continues to work properly.
Internally the currentCreatureBatch array is always used to simplify the implementation. When you turn off batch-simulation, it's practically the same as if you manually set the batch size to the population count. The sorting has to be done on currentGeneration in oder for it to sort the entire population and not just the current batch before the selection step, but if you have batches turned off, both arrays contain the same creatures anyway, so it doesn't make a difference.
The SetActive(false) is definitely necessary. Removing it changes the behaviour of the creatures and therefore also any previously saved simulation. That's why you see the fitness drop from 11.5 to 8.5. Since the entire movement relies on Unity's physics system, it is incredibly easy to break accidentally (I wasted a lot of time on exactly this one SetActive(false) call when writing the optimization branch). So even if this was causing the problems you are referring to, I couldn't just remove the call but would have to work around it in another way. That being said, GameObjects in Unity don't lose their transform position values when you deactivate them, so the values should still all be valid at that point in time.
Thanks for helping me debug this by the way! I'm sorry I can't test the actual project at the moment, but I will as soon as I have time. The creature movement looks great by the way!
On the picture you posted the horizontal distance also seems to be way outside of the normal range. It would be nice if you could send me the saved simulation file (stored in the Application.persistentDataPath: https://stackoverflow.com/questions/44419658/location-of-application-persistentd...) to firstname.lastname@example.org. I'll probably have time to work on this project again in roughly a month from now.
Thanks for confirming the improved memory management!
Now, while I still believe that a regular creature is highly unlikely to reach 100% fitness without any bugs helping, if you want to keep your creatures to improve beyond 100% fitness, you could also just remove the upper clamping limit of 1.0 when the fitness values are calculated inside of each Brain implementation (it should be within the respective Update call). That way you could keep the MAX_DISTANCE value at whatever it is, which would allow you to compare your creatures' performance to designs made by other people who are running an unmodified version of the simulator. As far as I can remember, fitness values above 1.0 should not cause any issue with any of the remaining code.
By the way, now that you had to remove TextMesh Pro, does the Russian and Portuguese text in the help center still show? I think I read somewhere that TextMesh Pro is now part of Unity itself but I haven't had any time to try to port this project to the 2018 version yet.
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 email@example.com 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.