next »

[Tiblanc]

This project is currently nameless. One day, I'll find a clever name.

The goal is to create an ecosystem where tiny people can do whatever it takes to pass on their genes to the next generation. The final simulation would have thousands of entities creating a closed economy by doing their own thing. The theory is entities who are providing a useful service to the community would get paid more and have more resources for reproduction. This should optimize the economy and allow a finite resource pool to sustain an ever increasing number of entities. Technological improvement will happen as mutation. I'm hoping that having technology part of the genome will cause communities to specialize and rely on trade to improve the overall efficiency.

Another point I would like to see emerge is the development of population centers. Our current economy has high density population areas supported by vast, low density farming areas. I believe this is due to time/energy savings from having a lot of economic actors in close proximity. That should be interesting to see emerge.

There are a few game ideas that could be built on top of this, but for now I'm not attempting any of them. I'm focusing on the simulation as a framework experiment and will incrementally build it as time allows.

[Tiblanc]

Iteration 1

The first iteration was getting the genetic algorithms in place. For this, I build a very simple simulation where entities are ranked based on how close they are to the background color. Every iteration, 10% of entities are randomly killed, then up to half are killed based on the sum of difference between their red, green and blue values compared to the background. New entities are created by randomly picking 2 surviving parents and having their genes randomly picked. Mutations can happen to any gene, causing the gene value to shift slightly in any direction.

Entities have 3 genes: Hue, Saturation and Value. The idea is to have genes represent something different than fitness values. A change to any of these values will cause a change to the 3 RGB values. Favorable mutations can sometimes require 2 different mutations. I have observed this with the saturation gene where a greyish blue would often make the creatures lose saturation which got them closer to the target color, but then they would be unable to adapt to another color because their hue could become any value and they got stuck in a valley of grey. That would have required a lot of lucky mutations, which I never got to happen. That wasn't the main goal of this milestone, so I'll leave it there.



The next iteration will be about modifying the genome. Instead of having 3 genes, they will have more and they won't be fixed anymore. Mutations will alter both the power and the type of genes. A Hue gene might mutate into a Hue/Saturation gene, for example.

[Tiblanc]

Iteration 2

It's been over a year since the first iteration, but life has a way to interfere with projects as soon as you start them. Anyways, the project isn't dead, it has only been given the opportunity of a lengthier thought process.

Building on the iteration 1, the genome has been modified to contain 10 genes with each gene containing a value from -16 to 16 and the 3 categories : Hue, Saturation and Value. Each category can be either positive, negative or neutral. For example :
- Gene 1 : H+S- 5
- Gene 2 : H+V+ -2
- Gene 3 : S+ 4

That would give a final value of :
Hue : 5 + -2 = 3
Saturation : -5 + 4 = 1
Value : -2

These values are normalized from a 0-256 range with 128 being the zero point.

Mutations can modify any of these properties. Gene 1 could see its Hue change from positive to negative or could get a Value component added. With more genes, there's more chance for mutation and the critters quickly converge into the target color. There's also a lot more variance once they have converged because a there are more gene combinations that give a correct answer and when they merge, they can create extreme offsprings.



The next iteration will be a tweak on the lifecycle of critters. Instead of getting killed and reproducing at the same time, they will do so after a time period determined by their fitness level. This will simulate an economy where the richest get to reproduce more.

[miroz]

It's great that you continued the project after a year.
I'm a sucker for economic simulations, genetic programming, and emergent behaviors, so it will be great to watch your progress. I started countless projects to test different economic ideas, with only some mild successes. I hope you can get the simulation working.

[Tiblanc]

It's great that you continued the project after a year.
I'm a sucker for economic simulations, genetic programming, and emergent behaviors, so it will be great to watch your progress. I started countless projects to test different economic ideas, with only some mild successes. I hope you can get the simulation working.

Hey thanks for your support! I didn't seem to have gotten a notification of your reply and my life got busier again right after as a weird twist of fate. I have a new iteration though.

Iteration 3

I implemented the basic currency of the simulation, lifeforce. There's a problem with money in the sense that if it's not backed by anything, then there's no reason to accept it as a payment. So lifeforce is what critters consume every tick. The older they are, the more they consume. Right now it's linear, which means that unless they have perfect color match, then they will slowly lose their lifeforce before turn 200 and when they reach some negative threshold, they die. The RGB channels difference with background color is used in lifeforce generation. Whereas before they would die if their fitness level wasn't good enough, now they generate less lifeforce.

I wanted to have genome influence reproduction cost, but that didn't work out as planned and it was a feature for the deeper economic sim, so I replaced it with a flat fee regardless of genome. When a critter reaches that number, it gets 1 reproduction ticket. When a critter has 2 reproduction tickets, they can initiate reproduction with any critter that has at least 1 ticket. The partner is chosen randomly. Since right now reproduction is guaranteed, there's very rarely more than 1 critter with 2 tickets. They both lose 1 ticket as a result.

The reason to do it that way is to create more pressure for the fittest critters. If you barely get 1 ticket in your lifetime, then you have to rely on selection luck to reproduce. If you're fit and you can reach 2 tickets, then your reproduction is guaranteed.

Another reason is there are times when a single critter might be suitable. Although that doesn't happen here, it's a possibility in the planned economic sim. In that case, reaching 4 tickets will allow a critter to reproduce with itself in some weird inbreeding mechanism.

To prevent population overflow, a lifeforce production modifier is used based on population size. The higher the population, the less lifeforce is generated for a given fitness level. This is apparent in this gif. The colony initially wipes because it's not fit enough for a 100 population size and barely survives. Then greater lifeforce generation kicks in and they manage to build a stable population, until a random lucky critter gets the color right and reproduces like a bull. It creates a large generation of good color matches, who then create another generation. At that point, lifeforce generation slows down and even if they match the color, they no longer reproduce 5-6 times, but only 2-3. The colony then stabilizes at around 160 critters. That would represent optimal usage of that land based on generation and consumption parameters. If they could, they would need to tech up and increase their lifeforce per critter generation somehow to increase their population, which would lead to specialization and market dynamics.

Black squares represent how many times that particular critter reproduced.



And that's it. The next iteration will introduce a second resource that critters will be able to get. They will need both lifeforce and that resource to reproduce. Specialization will have to happen because getting both won't be as efficient as going for 1, which means trading. I'll also get reproduction failures to encourage speciation and push critters in 2 distinct groups.

[Tiblanc]

Iteration 4

I implemented a second resource, stone. Stone is collected to the inverse of lifeforce. The goal was to see if critters would eventually split into 2 groups. To facilitate trade, a liquidity provider was created following simple a*b=k rule, where the product of lifeforce and stone must always equal a constant. This allows them to trade stone when they have an excess of either resource or when they're about to die and they sell off their assets in a last ditch attempt to stay alive and reproduce.

I also implemented selective reproduction. When a critter wants to reproduce, they'll randomly select 5 available mates, then compare their color with the other critter. This gives them a percentage change for a successful reproduction. It was made to make it easier to reproduce with similar critters, which should have kicked in if they split into 2 different colored groups.

And it failed.

The interesting thing that came out of it is since the first generation were all born at the same time, they all reached old age at the same time. At that point, they started selling their stone to buy themselves one more turn, which tanked the price. There just wasn't enough new critters to farm lifeforce for them that they all died at the same time, wiping more than half the colony at once. This gave a lot of room to the next generation who then repeated the cycle.

I have tweaked with whatever I could to try and make it work, but the critters always evolved to the same color, which was an in-between based on the needed resources for reproduction. I think it's normal because their production rates are a continuum and will tend to gravitate where they have the highest odds of reproduction regardless of market prices. Since prices fluctuate a lot based on generational cycles, it makes the most sense to produce less total resources and be shielded from market fluctuations. They have chosen vertical integration.

That's all fine because I planned on getting rid of the RGB mechanism eventually, which I'll do next iteration. I will change it so their genes dictate their actions and stats affecting these actions. This should hopefully create species because they won't be able to find that sweet spot where they produce both.

[Tiblanc]

Iteration 5

After much real life distraction, I finally got back to it.

The biggest change here was an overhaul of the genome. Instead of defining a color, it now defines what a critter will do. A genome has 1 action slot and 5 stat slots. The genes are defined in a cyclic graph structure, which could be seen as a tech tree. Mutations can alter the gene type based on this graph. Each gene has a reproduction cost that increases the more powerful it is.

The action slot determines what the critter will do. Right now there are 3 actions. The first one is represented by the human icon and it's generating lifeforce and stone with a factor of 0.35. The other 2 are generating lifeforce or stone with a factor of 1. Essentially, they are now jack of all trades or specialists.

The stat slots determine the critter's stats. Shocking stuff really. The stats genes are either 1 to all stats, 1.5 to a single stat or 2 to a single stat. Critters have a base stat of 10 in all 3 stats. This means a critter could have almost anything between 20/10/10 and 15/15/15. This is translated to RGB values for better visualization.

Early on in this iteration I multiplied production by the relevant stat, but that didn't work out, partly because genes could provide 5 stats instead of 2 and also because I realized this sim was actually a linear optimization solver. Given 2 possible combinations, if one of them produces more value under all circumstances, then it will always finish in this state. In order for the simulation to produce interesting patterns, it needs more variables. The more variables there are, the more patterns can emerge. Also, using non-linear functions creates more patterns because there can be multiple situations where one is better than the other.

That last one is what I ended up doing for stats. Instead of a multiplicative effect on the base production value, it reduces the overcrowding penalty. The penalty is equal to the stat value multiplied by 5 and divided by the number of alive critters with a maximum of 1. This means stats are meaningless when there's no critters and as overcrowing happens, those with stats can keep producing at full value while those with lesser stats end up producing less. The end result is farmers have higher wisdom while miners have higher strength, while constitution does nothing because I felt it wouldn't provide any meaningful outcome due to lacking variables in this iteration.

As for what happens during a run, it ends up following a cycle, which I think represents our society well. Early on, there's plenty of room, so generic individuals start reproducing, then create a either a farmer or a miner. This critter possesses higher production and will quickly reproduce, setting the simulation in one of two states.

With more farmers, lifeforce quickly floods the market and stone becomes very valuable. Population grows rapidly, but eventually reaches a limit because there isn't enough stone. Miners who happen to be alive gets great value out of their stone and reproduce more. This leads to the new generation flocking to mining and after a while, the price of stone starts dropping like... a stone... and then starts the great lifeforce shortage. During this shortage, whoever is getting old can no longer afford lifeforce because they produce less as they are and consume more lifeforce, so they all die in rapid succession. Population halves rapidly, which reduces overcrowding pressure. At that point, the few farmers who didn't pick up mining are in great demand and can acquire their stone for reproduction on the cheap, which produces a lot of new farmers.

And the cycle continues forever.

Here are some screenshots.

This is the start of the simulation, where 10 brave souls spawn in the middle of nowhere and have a bright future


In this run, miners was the hot job and stones were aplenty, but lifeforce became scarce and doom was imminent


The old folks died and farmer started doing business. We can see a lot of new farmers joining the world(they spawn on the top)


After a while, price went back to normal and miners started being the hot job again to repeat the cycle


That's about it for now. To create more interesting patterns, the simulation needs more variables. One way to achieve this will be by creating multiple areas with different production values and allowing some form of trade between the areas. This means reworking the UI and that's what the next iteration will be about.

[Tiblanc]

Iteration 6

I refactored the simulation to have multiple independent areas with their own production ratings. I then reworked the UI to remove the individual critters and group them by their action.

The setup is the first area has a production rating of 2 for both lifeforce and stone, the second has 1.5 for both, the third has 1 lifeforce 3 stone and the last has 3 lifeforce 1 stone. The idea was to test if the first 2 areas would have any meaningful population difference and also to see if different production ratings would have any impact on the action distribution.

Spoilers : it didn't

The population split is still directed mainly by the boom/bust cycles. Having a different production rating split doesn't do much other than direct the cycle one way or another from the start. The only thing that did happen was the 2nd zone had a constantly lower population count than the first.

Here's a screenshot from the start of the simulation.



The 3rd area which is the best stone area got its fair share of farmers, which makes perfect sense because 1 miner can sustain more farmers in this area. The opposite happens in the 4th area where a farmer can sustain more miners. Since they still need the same resources to replicate, the workforce splits into whatever ratio gets closest to that value.

Here's a screenshot from later on in the simulation.



Poor miners all got killed off because the markets crashed at the same time. That's something I'll need to figure out, but the problem might disappear as I add features to the simulation, so I'm not too bothered right now.

Then I added trading between zones. Right now it's done artificially. I take the total population count, divide by 20 and that's the stone that will get checked. The highest priced zone is compared to the lowest priced zone and if there's a 10% price difference, then stone is moved. The difference is tallied as profit.

This linked zones together. By being loosely linked, the boom/bust cycles aligned and were softened. Early in the simulation, the 3rd zone stone price drops and the 4th one rises, so trading starts between the 2 zones. I thought this would have allowed both zones to cooperate by using each other's strengths, but no, they still decided to farm rocks and mine greenfields.



This is a screenshot from later in the sim. The populations never stabilized and it was kind of like the previous runs.

I'm thinking this is caused by the rapid price volatility and the inability of critters to adapt to the new situation. This could also be caused by the simulation taking away a lot of lifeforce as profit, which doesn't do much for critters since they will sell at the low price and buy at the high price. The long term plan is to have trading done by critters, which means the lifeforce would remain in the simulation and trading capacity will adapt to the situation, so maybe that would also stabilize it.

I'm not sure yet what the next iteration will be about. Features I'm planning on implementing in the near future are :
- A new Tool resource that allows critters to increase productivity
- Trade action for critters
- Replacing liquidity providers by critters figuring out their own bid/ask prices

[Tiblanc]

Iteration 7

This one was about trying everything I could think of.

First I figured if I added complexity, then maybe it would force the simulation into a higher state. I added stone tools which are created by consuming some stone. Then I added 2 actions for lifeforce and stone that use these tools for a much greater output. That didn't work well because as soon as stone went into shortage, toolmakers all went broke which killed that little tool production there was and advanced actions then died in turn. Another situation was if tool prices went very high, the first toolmaker to spawn saw huge profit and started reproducing like a madman, which completely saturated the tools market and killed them all.

Turns out that throwing a bunch of Jenga blocks in the air and hoping to get a stable tower was like wishing for a unicorn.

Then I thought maybe the cycles could be broken by adding damping mechanisms. What I mean here is if tools are worth a lot and a toolmaker spawns, then he shouldn't be able to profit that much from it. The proper way to do it would have been to split labor and capital, but I wasn't ready for that yet, so I implemented that through the liquidity providers. If volume increased, then they tried to increase their liquidity by charging a fee. This means that if the price is high, sellers receive less and if the price is low, buyers pay more for it. That sort of worked, but not really. There was no stopping the cycles.

What I needed was some form of AI that could act based on market conditions, but that's not what I want. If I build an AI, it can easily solve this and that means I'll need to update this AI as the simulation complexifies, which defeats the point of having an emergent economic model that can adapt to any situation.

Since I was going to split capital and labor, I figured I could try a bit of it in this iteration. Because both will have different reproduction and maintenance rules, capital would no longer die of old age. Pausing production would be possible and that would provide a basic form of AI. If the main action isn't profitable, then it pauses. Pausing can incur other costs, like machines rusting from not being used, so they could still die over time.

That worked slightly. I had a more stable simulation, but the cycles were still present. It didn't overshoot like before, but it didn't really stabilize in a higher state. Tools critters would usually become idle until they died and then there was nobody left to create tools.

Then I tried the middle ground approach and that worked better. What I did was create weaker minor versions of production recipes for each main action and give them to action genes based on their mutation tree. For example, the basic lifeforce action can mutate to the lifeforce+stone action, the lifeforce using tools one or the basic stone action, so it gets all 3. The theory was that if one of these was in short supply, they could forego their main action to do this other minor action. When another critter came into play with that action as their primary one, they would be more efficient at it and relieve other critters from using the minor action.

This is a screenshot from a few minutes into the simulation with trading disabled. Numbers in parenthesis represent idle critters, which never happened with minor actions. The second number is for that action using tools.


The first one has a production rating of 2 for both stone and lifeforce, second is 1.5. Third one has 3 stone 1 lifeforce and fourth one is opposite at 1 stone 3 lifeforce. Without trade, they had to have more critters take on the less profitable jobs to achieve a balanced state. For some reason, there were a lot of critters taking on tools on the 2nd and 4th one, which I guess came from the higher lifeforce profit, since lifeforce is consumed every tick.

Then I reenabled trade. I messed up a bit here with the tools recipe since it consumed 1 stone for 2 tools. This made tools less valuable per unit and since trade moves a specific amount of either stone or tools, then stone was always more profitable to trade. This made the 4th zone richer because it can generate more lifeforce and import stone. I suspect the stone critters in there to be creating tools as a minor action more often than mining stone based on the production per critter values. Why didn't they become toolmakers instead, I don't know. It's a bit hard to debug, so that will remain a mystery.


This simulation was very stable, so there's that, but that still leaves the elephant in the room. I have no idea how to make these critters properly price things. The liquidity providers were supposed to serve as temporary measures until I figured it out, but with these minor actions, it became even harder. What they're trying to do is to maximize their wealth to be able to reproduce, so they need to figure out the best action to take that tick. To do that, they need some form of market data to know what they can buy and what they can sell, which would come from other critters, so that creates a chicken and egg situation. The only constant here is the per-tick lifeforce consumption value.

I might end up putting this project on the backburner until I figure out a simple solution. I have some starts of ideas, but there's always a chicken and egg problem somewhere, so we'll see if I can figure this out eventually.

[Tiblanc]

Iteration 8

Success? I managed to get something working, but before I promote it to "Great Success!", there are still hardcoded things that will need to change.

I almost refactored the entire simulation. The goal was to get rid of liquidity providers and have critters provide their own liquidity. For that, I needed to add the concept of inventory management and that's when I figured out the pricing issue.

Critters will now look at their per tick consumption to manage their inventory. They will take the highest per-tick consumption/production from all of their production recipes, add the per-tick maintenance costs and land tax. This gives a rate per material. Then, they take the lifeforce value of each of the materials, multiply by the rate and add to the lifeforce rate. This gives the projected rate per material for every material that the critter can use or produce. I was originally trying to differentiate production from consumption, but that caused issues when a critter can both produce and consume a material, so I simply use the max of either.

The goal of critters is to maximize the number of ticks they have available in their inventory. However, this isn't linear. Taking inspiration from marginal utility, each additional tick has lower value than the previous one, which means that given a choice between producing A and B, if the critter has a lot more A, then they will choose B even if B produces less. To do that, I take the number of ticks, square root it and that's what I call the wealth value. I multiply this by the base lifeforce value to get the perceived value and the sum of all perceived values is what critters use to determine their net worth. They will only do an action if this net worth increases and they will do the action that increases this net worth the most.

I also changed the way critters produce. Before, they would get decreasing production due to overcrowding. Now, they produce a constant amount, but the more critters in the area, the more lifeforce they pay per tick. This is the start of a land value tax component. I kept it simple for now, but eventually I will change this tax to try and maintain a maximum number of critter in the area instead of allowing an infinite number of critters. It works for now, but will break when productivity will grow.

Next was transforming critters into liquidity providers. They do not care if they produce or consume a material. If someone is willing to give them a good price for it, they will trade it. I didn't use the simple ab=k method I used in the previous iterations because it breaks when a critter has 0 of a particular item. It tries to divide by zero and that gives infinity price. Instead, I used the wealth value from above to determine the price relationship between 2 materials.

I take a material and calculate the number of ticks in inventory. Then I calculate 3 values, the number of ticks for 85%, 60% and 55%. The wealth values of each of these are calculated as well as the difference with the previous value. Then I take this wealth differential value and add it to the lifeforce current wealth value and calculate the number of ticks this would give. The ratio between the number of ticks, multiplied by the base lifeforce value gives the selling price of the material. The number of ticks gives the quantity of material to sell. This creates 3 ask orders. I do the opposite to create 3 bid orders.

After all critters have placed their orders, I run an auction. The auction finds the price point where the highest volume is traded, which means if it tests for a price of 2, all bids over 2 and all asks under 2 are included. The optimal price becomes the traded price and all orders are filled at that price, making sure it balances on both sides. The reason for doing it this way was to eliminate sequencing from the equation. If a stone producing critter acts after 5 other stone producing critters, then these 5 would always clear the order books and the last one would never find a good buyer. The auction system eliminates this because they all trade at the same time.

Any order that was not filled remains in the order book. This is what the trader uses. It will arbitrage up to 1 material from any market where bids and asks overlap, starting with the highest gap. Eventually this will either be critters doing it themselves or it will be a player feature where the player can setup trade routes between settlements.

The final change was to alter reproduction mechanism. Before, it was closer to how reptiles do it, where they lay eggs and go away. Now, it's closer to mammalians. To be eligible for reproduction, the average wealth value is calculated for all materials, then squared and divided by a target number of ticks. This translates into the previous ticket system and anyone with 2 can reproduce with anyone with 1 or if they have 4, they reproduce with themselves. For the next 25 ticks, each parent will transfer 2% of their current lifeforce to the kid. The kid will start producing at the 20th tick, but before that, they will place orders to start filling their inventory. Since they're all lifeforce and no material, they will initially bid high and parents will indirectly sell to their kids, which is equivalent to them giving materials directly, but much simpler to implement because kids might have completely different material needs if they mutate. The 5 extra support ticks is in case something went wrong. I view it as living with your parents while you save up for a house kind of situation. While they are supporting a kid, they cannot have another one.

The end result was a fairly stable simulation. The boom/bust cycles were all but gone and critters slowly teched up. As they started using tools, production rates per critter went up, which means they reproduced and that increased the land tax on all critters. This put higher pressure on the older ones and they eventually died because they couldn't pay it anymore and the economy specialized. I believe it solved the boom/bust cycles because liquidity now adapts to the local population at the same time instead of being delayed. There's no buffer anymore that causes this lag.

Here's some screenshot. First one is a simulation run without any trade. All regions are isolated in this run. The first zone is balanced, second is balanced, but weaker overall, third produces more stone and fourth produces more lifeforce. I think the reason why the fourth one dominates is because of the land tax. There's a hard cap on the number of critter an area can support, which is the maximum lifeforce production rate of a critter in the area.



This one is with trade enabled. I'm not sure why there are so few miners in the 3rd area. This might be due to the trader having too little capacity. Regardless, the tool business thrived and that's what ended up being traded. The first 3 zones became manufacturing centers for the 4th, probably extracting their own stone, turning it into tools and shipping it to the 4th.



And that's more than enough for this iteration. For the next one, I'm going to add iron and iron tools to experiment with a deeper tech tree. I'm also going to create a longer genetic progression toward higher tech. At the moment, as soon as they go from the initial gene to the farming/mining gene, they gain the stone tool minor actions. There should be at least 1 gene inbetween to allow for smoother technological upgrades.

[Tiblanc]

Iteration 9

The goal here was to see if the simulation could develop a market for something that has no immediate demand. Iron was added, which can be turned into iron tools which can be used by farmers and miners to produce more stuff.

My original thoughts were to continue with the intermediary genes, but that quickly failed. The reason was there was too many combinations to properly bootstrap the iron economy. I would have needed a single gene that mined iron, produced iron tools and used these tools to produce something. This created a web of interconnections between everything and I foresaw a future where everything requires 4 or more resources completely failing.

I scrapped that idea and refactored the action genes. They now possess 3 action genes, one is a primary gene and the other 2 are secondary genes. A mutation can swap these genes around. When a mutation occurs on a primary gene to transform into another action gene, it gets demoted to secondary status and a secondary gene takes its place as primary gene. It's the same gene, but now these genes have a primary and secondary action with the secondary action being a weaker version of the primary one. I then removed all intermediary genes.

When they act, they look at their 3 actions and decide which one would increase their wealth the most. Wealth is still determined by how many ticks worth of stuff they possess and their perceived value.

This change allowed them to evolve into new markets without depending on them. For example, if mining stone with stone tools is profitable, that would be their primary action. A secondary action could then evolve into mining stone with iron tools even if there are no iron tool available. They will list a bid for iron tool at some outrageous price, but they can still function with their primary action.

I then saw some progress toward iron tier. The first line shows the last auction price, which is how much that product is worth in that zone. The number on each line represents how many action genes exist in the area. In parenthesis is the number of secondary genes. The columns are lifeforce, stone, stone tool, iron tool and iron. I know iron tools and iron should have been swapped, but Unity UI kind of sucks to work with, so I just called it a day.



That took a super long time and performance issues started appearing with so many critters. It worked, but it wasn't working well enough. The second zone has the highest extraction rate for iron, but never developed iron miners.

The issue here was that the simulation was too stable. Before, it was unstable due to boom and bust cycles, but now, with 3 action genes, critters could easily survive even if they were inefficient. This led to a stagnant economy and while progress happened, it happened way too slowly.

What I needed was the equivalent of a canadian forest fire and that's what I did. I modified the land tax to follow a sinusoidal curve, varying by +/-25% every thousand ticks or so. This recreated the boom and bust cycles. Critters reproduced like crazy when the land tax was low and died off in masses when it went the other way around. With more reproduction comes more mutations, which advanced the technology in a faster way. After a while, whoever lost the genetic lottery was killed off and a new cycle started again.



This was taken during a boom phase and that's why the 4th area ended up with 700+ critters. Its lifeforce production factor is 3, so getting tools means they can sustain a large population. The 2nd area saw iron miners thrive, but it was constrained by trade capacity.

This trade capacity is determined by the number of alive critters in the world. It's 1 per 100 critters. Tool makers produce 0.5 every tick, while extractors vary based on tool type and area yield. Without tool it's 1-3 and with iron tools it's 3-9. Early on in the simulation, stone is what gets traded. The 3rd area sells some stone to the 4th one because its yield is 3 vs 1 and it kickstarts that area. Whoever develops tools first will then buy that stone and start exporting stone tools. After a while, stone tools saturate trade capacity because it has higher value per item and tool making develops where stone is cheaper. When iron comes into play, the same happens and stone tools start getting priced out of trade, with iron and iron tools being the traded products. It's why the 2nd area ended up with so many iron tool makers even if they don't use them that much.

Next iteration will introduce the concept of labor as a second input to production.