Part 8.2: Updates from Playtesting
The playtesting has been going well over on the Community Forum. I’m really glad I took the initiative, because it revealed a TON of problems I had with the current algorithm. One of these problems was actually a fundamental problem with how predation was being simulated in the algorithm, and fixing it has been the reason I’ve been pretty quiet on this thread lately.
However, I wanted to give anyone who is following this an update so that they can keep up with development. Here’s a summary of all the problems I’ve found SO FAR, and how I’ve improved the algorithm to address it. I’ll save the major change regarding predation for last:
-
Problem: Traits are not inter-dependent. Yes I know this is more of an Episode 2 issue, but it was good to get the basics done now. Traits like Base Metabolism, Body Volume, Body Mass, and others were completely independent. Some traits, like Body Density, didn’t even exist (meaning they couldn’t be evolved). But what happens to your other traits when your species evolves a larger body? What if they evolve a greater proportion of their body being muscle? Realistically, a larger creature should expend more energy than a smaller one.
- Solution: Implement a basic version of tissues. Each creature is now composed of one or more tissues, and each tissue has properties like density, metabolism, strength, etc. The two basic ones for now are Connective Tissue (uses little energy but doesn’t do anything), and Muscle Tissue (uses lots of energy but provides strength for swimming). Now, instead of telling the algorithm how much an organism weighs, you tell the algorithm the shape and dimensions of the organism, and what tissues it has and how much of each, and the algorithm itself calculates things like volume, mass, total metabolism, etc. This means that creatures can now evolve changes to specific tissues, like reducing the metabolism of a certain tissue, or increasing the strength of another tissue, or changing the ratio of the tissues.
-
Problem: Species competitiveness was being funky. After doing a few simulations, I noticed that species with lots of members but poor perception were doing surprisingly well in terms of interspecific competition with other species. Even when their perception was so weak they would detect less prey than a competitor species, they were still outcompeting that species. That’s how I realized that competitiveness was using the Required Hunts, which is the theoretical total number of a species needs to feed all of its members!
- Solution: Make competitiveness use Detected Hunts instead of Required Hunts. This made me realize that obviously, a competitor can’t compete with you for a prey he does not see, so I changed the equation for competitiveness to use detected hunts instead of required hunts. This way, a species with lots of members but with very poor detection could potentially be less competitive than a similar species with a smaller population but much better perception skills, since the latter species is actually finding and thus chasing much more prey.
-
Problem: It was getting hard to write the code for all the species. So far I had only been writing code for the algorithm for 1, 2, or at most 3 species. But during the playtest we went up to 4 by the 2nd round, and have the potential to go even higher. And many of the parts of the algorithm require me to write out a whole set of code for EACH species that is in the patch. For example, at the end of the algorithm I have instructions (aka code) on how the computer should produce Excel population reports of each species’ performance over the simulation. With 4x more species, I have to have 4x more code/instructions. And 4x more code doesn’t lead to 4x more mistakes, it leads to 4000x more mistakes, because your brain gets overwhelmed by all the words and numbers.
- Solution: Automate as many parts of the algorithm as possible. This was a task I had been delaying for some time now, but I finally got around to doing it. For some parts of the algorithm, I had just been procrastinating doing it. For other parts (like the part that tells it to produce the population performance reports) I legitimately could not figure out how to program it. By running the play-test though, the pressure forced me to sit down and tackle all of these tasks, and I was able to solve and automate all of them! For example, with the population performance reports code, it now loops through every species of the patch and uses the same instructions (code) to produce the reports for each one. This drastically reduces the chance for errors, and also makes it super easy to just increase the number of species in the patch and the algorithm will automatically create reports for the new species. It even knows how to name each file separately after the species it’s being created for!
These next three problems are the ones that led to me realizing the need for a major predation overhaul.
Problem: How do I display performance stats easily?
The first time I got around to posting a round of the play-test, I realized a big problem: How do I show the information clearly to the players? I am very familiar with all of the variables and how to read the population reports, and I also have access to the simulation itself so I can dissect it to see why the species perform as they do. So I am a biased sample. Additionally, I post simulation results at the end of each of my posts on the development thread for the algorithm, but those are mostly to show readers the gist of the updates to the algorithm, not to inform players for what decisions to make that will affect the outcome of their gameplay. The latter requires much more detailed and clear information.
I needed something clear and concise to be able to show the player, which they could then use to gauge where the weak-points of there species lied and what to evolve next generation. However, I could not yet think of a solution to this issue so I just sat on it.
Problem: Reproduction is still taking up waaay too much time in the month.
After doing multiple simulations with multiple species with differing traits, I noticed that there was an irrefutable pattern that hunting was far too quick and reproduction was taking up far too much time. It was usually comprising 99.99% of the lifespan of the organism. As a result, this greatly overpowered evolutions to reproduction (like mating frequency) and underpowered evolutions to hunting (like increasing swimming speed). I could not for the life of me figure out why this was the issue. After a several days of skimming the code and trying to find the issue, I thought I stumbled across something when I looked at the code for surveying/detecting prey.
If you recall from Part 8, I borrowed an equation from chemistry called the Collision Frequency Equation. I used it to calculate how often a prey “collided” with the senses of a predator. In other words, how many prey a predator surveyed per month. I realized that the equation gives you the number of collisions per second, and I was multiplying this by the number of seconds in a month. But a predator may not spend the entire month surveying! In fact, he only surveys as part of his “Hunting” life activity, and spends the rest of his time reproducing (which should’ve been 99% of the month according to the problem I mentioned before this). Additionally, I realized that the seconds that were being spent surveying were not actually being included in the time that it took to hunt, which was part of the reason that hunting was taking such a short amount of time to finish.
So I had to make the collision equation use ONLY the number of seconds that the species was spending hunting, to accurately determine how many prey were actually surveyed. This brought me to the last and biggest problem
Problem: What do I calculate first?
It was at this moment that I realized the fundamental flaw with the current design of predation. What do I calculate first?
To find out how many prey are surveyed per month, I need to know how many seconds are spent hunting. But to find out how many seconds a predator needs to spend hunting every month to feed itself, I need to know how successful it is at its hunting, which includes how many prey it surveys and detects.
Furthermore, I realized that because of the change to how competitiveness is calculated, I needed to know how many prey were detected to calculate competitiveness, but to know how many prey are detected I need to know how much time is spent hunting, but to know how much time is spent hunting I need to know how successful the species is at hunting, and to find how successful the species is at hunting I needed to know how competitive it was (among other things).
What comes first?!?! Had I discovered an impossibility in simulating evolution through purely using population math?
This realization had me considering whether to quit the algorithm entirely, because it was so fundamental to the algorithm’s design, and I simply could find a way around it.
Solution: The predation overhaul.
After a few more days of sitting on the problem, I finally figured out a solution.
The collision equation gives a number of prey surveyed by the predator every second. If you take the reciprocal of this, that gives you the number of seconds it takes for the predator to survey one prey (Let’s say 60 seconds).
But what if the predator only actually detects 50% of the prey it surveys. In that case, the time it takes for a predator to detect one prey is 60 seconds ÷ 0.5, or 120 seconds. This includes the fact that the predator surveyed two prey and only detected one of them.
Then you repeat this for the multiple steps of hunting. If a predator only wins 50% of chases, then you divide 120 seconds by another 0.5. In fact, you keep dividing for every step of the hunting process that involves a success rate (like combat, interspecific competition, intraspecific competition, etc.). Once you’ve divided by all of those success rates, you’ll have the overall time you need to spend hunting to get one successful, completed hunt. Then you look at the time you have available in a month, and you calculate how much time you would have to spend hunting to get the number of successful, completed hunts you need to feed yourself. If there is not enough time in the month, or your prey runs out, or you finish feeding yourself, then you stop hunting and switch to reproducing. Then, once you have the final number of successful hunts you are able to perform, you use your success rates to work backwards and find out how many hunts you attempted to get that many successful hunts. This solves the problem of not knowing what to calculate first!
And as I thought of the steps of the hunting process, I realized that I could now calculate a time for each step of the hunting process. It takes time to detect, and if you successfully detect it takes time to chase, and if you successfully chase it takes time to defeat the prey in combat, etc. Additionally, the predators would spend time on both successful and failed hunts (which is something I realized I had not been calculating earlier, only the time spent on successful hunts). And even from among the failed hunts there would be different levels of how early it failed. One hunt could fail right at the get-go because the predator does not detect him, while another hunt could have the predator detect the prey but fail to catch the prey. So I also had to calculate the different amounts of time spent on the different types of failed hunts. The solution to this is that the species should now spend a LOT more time hunting, and thus a lot less time reproducing, and have much more realistic behaviours, solving the second problem.
Then I realized that each of these success percentages are perfect statistics to show to a player. Percentages are a very easy number to think about and use to represent values, and can easily convey how well a species is performing. Thus a species’ performance in hunting can be simply displayed by its success rates (as percentages) in each of the steps of hunting. Additionally, all of these percentages can be multiplied together to produce an Overall Hunting Success percentage, to give you an idea of your overall success as well. Using these different percentages, a player can more easily identify “Oh! My chase success is very high, which means I’m already very good at catching my prey and don’t need to increase my speed even more. But my detection success is very low! I should evolve better perception!” In addition to the success rates of each step, you can also show the time spent on each step, to give a the player a better idea of what they can evolve to improve their survival. This solves the third and final problem of how to show the performance information clearly to the player!
Conclusion
That’s an update on the progress I’ve made on the algorithm since I started the play-testing. The first few solutions have already been implemented, but the predation overhaul will be major and will take some time. I’m predicting that it could take anywhere from 1-2 weeks to fully finish and fix all of the bugs. In the meantime, I may not post another update to this thread until I finish the overhaul. I also may pause the play-test until I finish the overhaul, so I can use the overhauled algorithm for Round 4. But if the overhaul proves to be taking too long, I’ll just go ahead with using the old code for Round 4.
All in all, the play-test has proven to be a great success! It’s helped me catch a lot of major bugs and design flaws, and I hope has given the players a good chance to experience the excitement of the competitive race of evolution, and how that could feel in Thrive!