NPC Auto-Evo Thread

~sciocont wrote:

I am liking this a lot. So, we're all clear on how this is going to work now? All we have to do is map out the niches for each biome, including all of their required attributes, then roadkill has the code for placement.

Precisely. The code will add, replace, and remove organisms to make the best fit. Be sure to include a list of possible resources into each biome. (Rocks, streams, etc)

roadkillguy wrote:

~sciocont wrote:

I am liking this a lot. So, we're all clear on how this is going to work now? All we have to do is map out the niches for each biome, including all of their required attributes, then roadkill has the code for placement.

Precisely. The code will add, replace, and remove organisms to make the best fit. Be sure to include a list of possible resources into each biome. (Rocks, streams, etc)

Ok, I'll do a mock-up of a mini biome.

Also, we may need to make a global (universal, in this case) compound list, depending on if we want that. (I believe that's the key to balancing any given biome, if it's done right) That way, plants wont just magically spawn unless the Biome contains the resources in the dirt and water, and a carnivore wont be able to move in without meat. The stage is then set for Mysterious Calligrapher's Biome Levels.

We may be able to get away with it for now, but it may become an issue in the future.

I like the code for the niches, but while is is good for determining niches it looks as though we are going to get a load of organisms with a score of 0, or very close, and they'll just stay there. I know this isn't the code's fault, but how is this avoided? (If it needs to be, it seems to)

More attributes, and food sources taken into account. Compounds would help too. The more we define a niche, the more the score can vary.

I've also made a discovery. While writing food comparison into the organism score function, I found that Niches needed to be able to depend on eachother. Niches also need to be able to depend on a resource, such as the ground (Plants eat dirt). Niches, inadvertently, are thus resources, specifically organisms, for their eating ability.

Niches = Organisms + required attributes + current organism (Which is kind of obvious, but I didn't intend for a Niche to be a derivative of class organism)

Often when coding lots of classes, logic will begin to sort itself out. (It's amazing, really) Just thought I'd share that.

Also, there seems to be an order to things. A herbivore will not be added until grass is there (he wont pass the niche test), so effectively the computer is telling us that grass comes before herbivores, and the evolution system works out great. I'll post more code when it's working. (Something's up)

... I think you just read my science brain and translated it into codespeak.

And I put up the first bare-bones biome system - Highly Arid, water resources pretty much negligible. Resources will be added to it later, but right now it's just a series of empty deserts. It's here, if anyone would like a look. Hopefully it's inteligible. (second post down.)

roadkillguy wrote:

More attributes, and food sources taken into account. Compounds would help too. The more we define a niche, the more the score can vary.

I've also made a discovery. While writing food comparison into the organism score function, I found that Niches needed to be able to depend on eachother. Niches also need to be able to depend on a resource, such as the ground (Plants eat dirt). Niches, inadvertently, are thus resources, specifically organisms, for their eating ability.

Niches = Organisms + required attributes + current organism (Which is kind of obvious, but I didn't intend for a Niche to be a derivative of class organism)

Often when coding lots of classes, logic will begin to sort itself out. (It's amazing, really) Just thought I'd share that.

Also, there seems to be an order to things. A herbivore will not be added until grass is there (he wont pass the niche test), so effectively the computer is telling us that grass comes before herbivores, and the evolution system works out great. I'll post more code when it's working. (Something's up)

That's brilliant! Everything is going well, I see.
Yesterday I drew up a biome food web for us. It's a bit complicated even though it only has 17 species. However, It made me realize a few things.

1- We may need more attributes to define a niche so far I can only come up with size diet and movement type. I don't want our niches to become to exact, because that will stifle interesting evolution, but I don't want the definitions to be too simple.

2- The food web is sort of arbitrary... I really just put in random connections between the levels for what feeds on what. I know this is probably the only way to do it, but it still irks me.

3- We need to decide how many species max can be in a biome. The biome I created had 17, and I though of it as a plains type biome by the descriptions of the creatures. Plains would probably be a low stage 2 biome, so a high stage 3 (tropical rain forest) would have a lot more. Maybe 50 species?

I've set up a new thread to deal with this.

sciocont wrote:

2- The food web is sort of arbitrary... I really just put in random connections between the levels for what feeds on what. I know this is probably the only way to do it, but it still irks me.

I don't think that matters. Some niche definitions might be a little too vague or too specific, but that's where we can fine tune the game.

Some definitions of niches should also be required (I.E. you have to specify some minimum attributes for each niche)

I would say:
-Name
-Size
-Mass (I proposed that in the other thread so maybe not)
-Breathable Atmosphere (Plants too?)
-At least one other niche/resource to eat. (Maybe Atmosphere should play into this; I'm not sure how)

roadkillguy wrote:

sciocont wrote:

2- The food web is sort of arbitrary... I really just put in random connections between the levels for what feeds on what. I know this is probably the only way to do it, but it still irks me.

I don't think that matters. Some niche definitions might be a little too vague or too specific, but that's where we can fine tune the game.

Some definitions of niches should also be required (I.E. you have to specify some minimum attributes for each niche)

I would say:
-Name
-Size
-Mass (I proposed that in the other thread so maybe not)
-Breathable Atmosphere (Plants too?)
-At least one other niche/resource to eat. (Maybe Atmosphere should play into this; I'm not sure how)

What do you mean by minimum attributes? The definition for each niche is already the minimum required attributes.

Decomposers and detrtitvores will not need anything to eat on the food chain, so they wiill play mostly the same role as autotrophs.

As in, whoever writes the niche could choose to specify more or less about the organism, but should have at least certain parameters.

roadkillguy wrote:

As in, whoever writes the niche could choose to specify more or less about the organism, but should have at least certain parameters.

Ok, that's what I thought.

So, is this concrete enough to add to the wiki? Because i think we need to get this idea and biomes up there as soon as we can.

US_of_Alaska wrote:

So, is this concrete enough to add to the wiki? Because i think we need to get this idea and biomes up there as soon as we can.

Yup.

Righto. I think we'll just ask Scio to do it, though. I don't understand this enough to make the wiki page.

US_of_Alaska wrote:

Righto. I think we'll just ask Scio to do it, though. I don't understand this enough to make the wiki page.

It's up now.

I like the systems suggested here a lot. Using niches to test a species fitness is a good way to avoid the complexity of defining actual fitness, and not an unreasonable simplification either.

There are a few questions/issues I came up with though:
- I can't find a good definition of how long a generation is? Some old threads I've looked at mention 'skipping forward in time a few million years', suggesting that the player plays for a session (10-15 mins?) and then skips forwards to speed up evolution. Other posts seem to suggest that this would happen automatically every few minutes (5-10). If the first suggestion (skipping time) is what's proposed, allowing only a single creature to evolve each time would be severely limiting (I know this has been discussed before, I'll expand on this in a second). Alternatively is the idea to skip time, but every time this happens run multiple generations? In the second suggestion (a generation every few minutes) this would be more reasonable, but considering the miniscule changes we're making this would need to happen fairly often (perhaps several times a minute).

As a coder this should be relatively simple (nothing truely is, but there's nothing here which I'd be overly worried about) to implement, and in addition should run very quickly. My suggestion then is instead of evolving just one or two species, give all of them a chance of evolving every evo-step (the probabilities could be the same as they are now). This would mean the evolution progresses more quickly, allows every species a chance to adapt to a new threat, and has the added advantage of reducing the impact of arms races on other species (if two species concentrate all their evo oppertunites on beating eachother, sooner or later something else is going to come along and wipe them out). If your worried about things changing too quickly, simply reduce how much an organism can change each time.

Also, it's fairly simple to preserve the 'reactionary' evo system, by having each organism take note of what changes made last evo-step affect them (this could be done largely during auto-evo, the only things to notice during the next simulation period are disasters and other major events). These changes could be adaptations by a predator/prey, invasion of their niche, reduction of one or more food sources, changes to their biomes environment etc.

In terms of the chess analogy, you could imagine every species playing their own private game of chess, with moves by other species affecting both the position of pieces on their board, and the layout of the board. Rather than potentially having to wait a few dozen turns to be able to react to another pieces move, it gets that oppertunity every turn, and can either react, dawdle, or not move at all. Note that species can only react to moves made the evo-step before, they are not aware of changes made this step until next step.

Finally, while I like the way your using niches, I think we could improve the way their defined, allowing them to be more dynamic, and not requiring us to predefine each niche in every biome. I'll think about this some more today and try and post in the relevant thread tonight.

Seregon wrote:

I like the systems suggested here a lot. Using niches to test a species fitness is a good way to avoid the complexity of defining actual fitness, and not an unreasonable simplification either.

There are a few questions/issues I came up with though:

Thank you very much for the review of the system. Since I created the system, I do have the answers you seek.
-Generations happen after a preset amount of time, say 5-10 minutes in real time. It goes this slowly so that the player can figure out what's going on.
-It's for this same reason (player recognition of species) and the goal of simplicity that I wanted only one organism to evolve at once. In an added bonus, this simulates punctuated equilibrium.

However, if you think more mutations per generation are necessary, I might have a good idea of how to simplify it. Instead of selecting one species in the selection step, the computer selects a number of species that corresponds with a certain percentage of the total number of species. So, say, it gives a mutation to 20% of the organisms in a biome every generation.

I'm still not sure how more mutations affect the complexity of the evolution system, which makes me a bit more apprehensive.

If you want to check out the Food web Creation thread we're discussing there how to make dynamic niches, defined by properties required by the environment and lower trophic levels.

What do you mean when you say complexity? Are you worried about the players ability to interact with the result, the computational load, or the task of actually coding auto-evo?

I understand your points too, and so long as such a generation happens often enough I think it could work. I hadn't thought about punctuated equilibrium, and thats a good argument for only allowing one organism to evolve, however it's also a good argument for allowing multiple organisms to evolve, when they have good reason to do so (after a disaster or other event). What I'm suggesting isn't that every species evolves, rather that every species has a chance to evolve, that chance normally being around 1%, unless some event raises it (very similair to the probabilities described in this thread).

Whichever we decide, it should be fairly simple to code a system which is capable of both (limiting it to one species per evo-step is a special case of allowing multiple species to evolve per step), so we could test both when needed.

Did you mean this thread? I'll have a look through it this afternoon.

Seregon wrote:

What do you mean when you say complexity? Are you worried about the players ability to interact with the result, the computational load, or the task of actually coding auto-evo?

I understand your points too, and so long as such a generation happens often enough I think it could work. I hadn't thought about punctuated equilibrium, and thats a good argument for only allowing one organism to evolve, however it's also a good argument for allowing multiple organisms to evolve, when they have good reason to do so (after a disaster or other event). What I'm suggesting isn't that every species evolves, rather that every species has a chance to evolve, that chance normally being around 1%, unless some event raises it (very similair to the probabilities described in this thread).

Whichever we decide, it should be fairly simple to code a system which is capable of both (limiting it to one species per evo-step is a special case of allowing multiple species to evolve per step), so we could test both when needed.

Did you mean this thread? I'll have a look through it this afternoon.

Yep, that's the thread I was referring to. With complexity i'm talking about the computational load. I also think there is a chance to create paradoxes with many organisms evolving at once, although I haven't thought of any specific cases in which this might happen.

I'm not sure I understand what you mean here- in the current model, every species does have a chance to evolve in each generation, some just have a higher chance than others, based on their populations and reaction chances. Do you mean that even if the evolution program does not pick a creature, it still has a dice-roll chance at evolving? That sounds like a pretty good Idea to me, actually.

Thats pretty much exactly what I mean. In your model a single die is rolled to decide on a species to evolve, and a second die is rolled to chose a mutation. What I suggest is that a die is rolled for every creature, deciding whether it will evolve, regardless of what happens to other creatures this step (what happened last step may change probabilities this time round).

A simple example:

Code:

3 species, A-C, with populations 100, 200, 300.

Base probabilities:
A = 100 / 600 = 17%
B = 200 / 600 = 33%
C = 300 / 600 = 50%

In your model a single die is rolled: p = [0 1]
if 0    < p < 0.17    -> A evolves
if 0.17  < p < 0.5      -> B evolves
if 0.5  < p < 1.0      -> C evolves
only one of the three can evolve

in my model, three dice are rolled: p1, p2, p3 = [0 1]
if  p1 < 0.17 -> A evolves
if  p2 < 0.33 -> B evolves
if  p3 < 0.5  -> C evolves
all three can potentially evolve, but the probability of that is much lower (0.17 x 0.33 x 0.5 = 0.028)

If a species is chosen to evolve, auto-evo handles mutations for each one exactly how you've described before.

In reality all these probabilities should probably be much lower, and would be with more species and a bit of tweaking, but hopefully this makes everything a little clearer?

Seregon wrote:

Thats pretty much exactly what I mean. In your model a single die is rolled to decide on a species to evolve, and a second die is rolled to chose a mutation. What I suggest is that a die is rolled for every creature, deciding whether it will evolve, regardless of what happens to other creatures this step (what happened last step may change probabilities this time round).

A simple example:

Code:

3 species, A-C, with populations 100, 200, 300.

Base probabilities:
A = 100 / 600 = 17%
B = 200 / 600 = 33%
C = 300 / 600 = 50%

In your model a single die is rolled: p = [0 1]
if 0      < p < 0.17    -> A evolves
if 0.17 < p < 0.5      -> B evolves
if 0.5  < p < 1.0      -> C evolves
only one of the three can evolve

in my model, three dice are rolled: p1, p2, p3 = [0 1]
if  p1 < 0.17 -> A evolves
if  p2 < 0.33 -> B evolves
if  p3 < 0.5  -> C evolves
all three can potentially evolve, but the probability of that is much lower (0.17 x 0.33 x 0.5 = 0.028)

If a species is chosen to evolve, auto-evo handles mutations for each one exactly how you've described before.

In reality all these probabilities should probably be much lower, and would be with more species and a bit of tweaking, but hopefully this makes everything a little clearer?

That... that is a great idea. It makes a ton of sense, and doesn't disrupt anything else in the system, except for making the modification of odds step for the next generation a bit more complex (which doesn't really matter, seeing as it is already extremely simple.).

It would make things slightly more complex, but it should just be a case of doing what we were doing anyway, just with more potential changes. If I've understood whats involved correctly (and chances are I've missed a few things), there's nothing here which should take an unreasonable amount of time to compute.

The only reason an auto-evo step should take anything beyond a second or two, is the need to generate new graphical representations for the evolved creatures (new procedural textures, limb structures, procedural animation?), but I have no way of knowing how long that could take regardless of how many creatures evolved. Keeping in mind that you'll only see those creatures in your biome anyway, it's something we can reasonably tackle once we get there.

Seregon wrote:

It would make things slightly more complex, but it should just be a case of doing what we were doing anyway, just with more potential changes. If I've understood whats involved correctly (and chances are I've missed a few things), there's nothing here which should take an unreasonable amount of time to compute.

The only reason an auto-evo step should take anything beyond a second or two, is the need to generate new graphical representations for the evolved creatures (new procedural textures, limb structures, procedural animation?), but I have no way of knowing how long that could take regardless of how many creatures evolved. Keeping in mind that you'll only see those creatures in your biome anyway, it's something we can reasonably tackle once we get there.

Yes, it seems like this wouldn't change very much at all, computationally. As long as we limit the total number of species in a biome, the representation shouldn't be much of a problem either. I'd hate to pin people to a loading screen, so I'd suggest that as soon as a generation finishes mutating, the next generation begins to compute, so that all of the /model/texture/behavior changes are done within the time limit of the generation.

That's another good point, many of these things can be computed in the background. The game would need to know about any disasters which are going to happen beforehand, but that's not unreasonable either. At the very least all biomes besides that of the player can be pre-computed, so that the player can have some influence on the auto-evo process through actions taken during the play session, that leaves just one biome to compute. If there's any need for a loading screen at all, it'll be for graphical changes, not the auto-evo step.

Seregon wrote:

That's another good point, many of these things can be computed in the background. The game would need to know about any disasters which are going to happen beforehand, but that's not unreasonable either. At the very least all biomes besides that of the player can be pre-computed, so that the player can have some influence on the auto-evo process through actions taken during the play session, that leaves just one biome to compute. If there's any need for a loading screen at all, it'll be for graphical changes, not the auto-evo step.

Exactly, only the biome(s) you live in will be affected.