Critter overpopulation -- action slowdown

[Zarquan]

One thing that I wish the game allowed for better is non-grooming ranching.  In my current base, I have two major places where I have one tile ranches.  I have a drecko starvation ranch (fed by one drecko ranch) and a one tile slickster pen.  The main drag on my system is the one tile slickster pen.

Spoiler

 

This design is made so that the slickster ranch is self sustaining, as each slickster in the ranch lays an egg to replace themself before they die.  This currently has 8 feeder ranches because I make a lot of CO2 and want a lot of food. 

The eggs in this room are in an open pneumatic door so that the slicksters above are not confined.  Slickter larvae can swim up to join the rest of them.

The math works out so that 21.25 eggs fed in to this pen can produce 1000 kcal/cycle on average perpetually for as long as you can provide CO2.  Plus, they deal with CO2 and produce petroleum or crude oil, which is just good.

The incubators above are to replenish the ranches.  They are powered because I have excess power and they train my dupes in ranching.  The pneumatic door is set up on a timer (20 seconds open, 30 second closed) so that any slicksters that actually fully grow in that chamber eventually fall in to the one tile pen.  The oldest slickster I have seen up there was 12 cycles old, but they usually fall in within a couple cycles.

 

Overview of the whole system:

As you can see, I have over 600 slicksters in this one tile space.  Now, I understand that this should have a drag on the system, but I feel that it is greater than it should be. 

I was watching my ranchers and it took about a minute real time for the animals in the happy ranches to react to the ranchers calling them to be groomed.  On top of this pen, I have 8 feeder pens with 8 slicksters each and 3 dedicated ranchers (1 level 14 and 2 level 12) and they can't even come close to keeping up.

My thinking, as a person who has training in computer programming, is that these slicksters should require next to no computation.  They have no pathfinding, so only thing that should be considered is whether they need to eat or not.  In my mind, this would take less than a second for the entire ranch, especially if they are offscreen because then you don't even have to load an animation.

Regardless, I think that if a critter is being called to a grooming station or to any other station, it should be placed near the front of the queue as high priority.  This is a relatively rare occurrence compared to all the other critter operations, so I don't think we would see critter starvation from starvation in the priority queue.  I also think that if a critter is reports as drowning, it should also get priority, but probably lower than than grooming, as I consider dupe time to be far more important than critter time.  I believe this would lead to a much more consistent ranching experience when there are lots of critters.

(I meant for this to not be a suggestion, but here we are).

Any thoughts?

[Zarquan]

I would like to point that the minute real time means that if I am playing on the fastest speed, it takes about 3 minutes in game time for the slicksters to respond, meaning each rancher only grooms 2-3 critters per day.  This means that it takes all three of them to keep about 16 slicksters happy, which seems like overkill.

EDIT:  I just watched a slickster walk in to a 2 tile high area of liquid and just sit there until it drowned.  I feel like this shouldn't be happening.  Death from starvation or drowning shouldn't happen if they can eat or move to safety.

[JRup]

I've had a lot of slicksters die off that way, specially in the wild. Even though they're capable of "hovering" they just die off if given a chance to 'drown'. Weird stuff also happens on load. The latest slickster pen I also built with mesh tile to avoid this.
I'm just wild ranching some around a CO2 vent for meat and eggshells, they just happen to poop petro so I gracefully deal with the "byproduct". No grooming. Nope, nada, zilch. Stay wild you weird floaters.

[Zarquan]

12 minutes ago, JRup said:

I've had a lot of slicksters die off that way, specially in the wild. Even though they're capable of "hovering" they just die off if given a chance to 'drown'. Weird stuff also happens on load. The latest slickster pen I also built with mesh tile to avoid this.

It's not that they fell in and couldn't get out.  It is that they wandered in to a spot where they were under liquid that they could have wandered out of but didn't get a chance to think before they drowned.

[JRup]

3 minutes ago, Zarquan said:

It's not that they fell in and couldn't get out.

That's why I said "given a chance"
They live their lives in sorry black gas, I guess they need more excitement in their lives or they take the plunge. :'(

 

[TheMule]

On 9/14/2020 at 7:43 AM, Zarquan said:

who has training in computer programming

Then, you know how real time systems work. Below a certain load threshold, there are no problems. Above the threshold, in non real time system everything slightly slows down: you can see it as the inevitable lag being distributed... not evenly, because there are priorities at play, but there's a general principle of no starvation, and not task is ignored for long. In real time systems tasks that are deemed not important are simply ignored. You can think of that as if the lag was concentrated in less important tasks to leave the important tasks as lag-free as possible.

From what I've experienced in the game, that's how ONI works, and critter movement is a very low prio task in ONI. As in, it's the first thing the scheduler skips or - if you wish - the last thing the scheduler does. Since there is a limited number of tasks the game is able to complete per tick and critter movement is last, your 600 slicksters lagging is no surprise. It's entirely possible the rest of the game isn't particularly lagged.

Let's say the scheduler is able to complete all other tasks in a tick, then it starts looking at critters, but it has time to move only about 200 of them. In my game that's more than I have around, and I see no lag. In you game, critters are moving at 1/4 of their regular pace.
 

On 9/14/2020 at 7:43 AM, Zarquan said:

Regardless, I think that if a critter is being called to a grooming station or to any other station, it should be placed near the front of the queue as high priority. 

I would agree that, when a dup is waiting for them, critters movement should get higher prio. But what would you like to get ignored instead? Packets moving inside pipes? That might lead to boilers failing due to unbalanced heat exchangers. I mean, there's always a price to pay.

[SharraShimada]

You think, there is no pathfinding, but you are wrong. 

There are 600+ Critters looking if there is a path now. And again. And again. 600 times the same procedure because there could be a valid path the next microsecond. The pathfinding code does not know, there will be no path for eternity. 

[Zarquan]

9 hours ago, TheMule said:

Then, you know how real time systems work. Below a certain load threshold, there are no problems. Above the threshold, in non real time system everything slightly slows down: you can see it as the inevitable lag being distributed... not evenly, because there are priorities at play, but there's a general principle of no starvation, and not task is ignored for long. In real time systems tasks that are deemed not important are simply ignored. You can think of that as if the lag was concentrated in less important tasks to leave the important tasks as lag-free as possible.

From what I've experienced in the game, that's how ONI works, and critter movement is a very low prio task in ONI. As in, it's the first thing the scheduler skips or - if you wish - the last thing the scheduler does. Since there is a limited number of tasks the game is able to complete per tick and critter movement is last, your 600 slicksters lagging is no surprise. It's entirely possible the rest of the game isn't particularly lagged.

Let's say the scheduler is able to complete all other tasks in a tick, then it starts looking at critters, but it has time to move only about 200 of them. In my game that's more than I have around, and I see no lag. In you game, critters are moving at 1/4 of their regular pace.

I wouldn't be having a problem if it was handling 200 critters in a tick.  Remember, I saw a slickster larva just float in to a 2 tile high liquid and sit there until it drowned.  It takes around 30-60 seconds in game time for a critter to drown, and there are about 700 critters on the map.  This means that it isn't handling more than 5 critters per tick. 

6 hours ago, SharraShimada said:

You think, there is no pathfinding, but you are wrong. 

There are 600+ Critters looking if there is a path now. And again. And again. 600 times the same procedure because there could be a valid path the next microsecond. The pathfinding code does not know, there will be no path for eternity. 

I would argue that this is a waste.  Why should it create the navigation map for every critter in a tile when it can use the same one for all of them?  If it calculated the pathfinding for my 600 slickters once, then it would be far more efficient.  It would also increase the efficiency of my other ranches too, which are designed to reduce pathfinding.  My one tile ranch is ideal for this, but any dense ranch would benefit significantly.

9 hours ago, TheMule said:

I would agree that, when a dup is waiting for them, critters movement should get higher prio. But what would you like to get ignored instead? Packets moving inside pipes? That might lead to boilers failing due to unbalanced heat exchangers. I mean, there's always a price to pay.

When a rancher calls a critter to a station, they would be moved to the front of the line or near the front of the line of critter processing.  Therefore, they deprioritize the other critters.  Compared to the other aspects of critter events, being called to a grooming or shearing station is relatively rare.  This means that pipe and physics simulation still take priority.

[TheMule]

1 minute ago, Zarquan said:

This means that it isn't handling more than 5 critters per tick. 

You assume they are treated fairly. It might not be the case. You can't be sure critters are looked at in a round-robin fashion. Some may have a greater chance to be ignored than others.

Anyway I trust the devs know better their game than we do. We're just guessing.

[Zarquan]

13 hours ago, TheMule said:

You assume they are treated fairly. It might not be the case. You can't be sure critters are looked at in a round-robin fashion. Some may have a greater chance to be ignored than others.

Anyway I trust the devs know better their game than we do. We're just guessing.

The only way this event would make sense to me would be if either the critters were working in a prioritized queue that deprioritized drowning critters to the point of queue starvation or it is round robin handling less than 5 critters per tick.  I can't really think of another answer.  (EDIT:  It might also be that the critters are in order and older critters get to act first.  Then when a new critter hatches, it starts it from the beginning.  That would also make sense to me.)

Either way, if a critter can easily path their way out of a drowning situation on the first try, they should never drown. 

The thing is, I see this as a significant problem in the game.  When significant problems are discussed, a solution can present itself and make it easier on the devs to fix.  I know that changing things is hardly ever easy in a complex game like this.  But my thinking is that a large number of the problems with critters would be solved if:

1. Critters called to station get priority over other critters.
2. Critters who are dying get a chance to save themselves before they die.
3. Navigation maps and pathfinding is shared between critters occupying the same space.

3 is harder.  Caching can result in all kinds of strange behaviors in this kind of situation, like critters trying to walk through newly placed walls.  But 1 and 2 don't seem like they would be prohibitively difficult.

EDIT:  2 already exists in a form for dupes.  If a dupe hits 0 kcal while getting food, they don't die.  They just walk over, get their food, then eat.  If they stop for any reason at 0 kcal, they die.

EDIT 2:  I would like to point out that I am not expecting miracles here.  I don't think I should be able to have unlimited slicksters with these changes.  But I think that critters could be far more efficient and 600 critters shouldn't break the game, especially when they can't move.

[TheMule]

13 hours ago, Zarquan said:

 It might also be that the critters are in order and older critters get to act first.  Then when a new critter hatches, it starts it from the beginning. That would also make sense to me

That something more like what I was thinking. It doesn't have to be a strict order. Maybe shinebugs are considered before slicksters. Maybe there a list of slicksters and newborns (or new adults) earn a random (but fixed) place in the list. Those that end up at the end of the list are the unlucky ones.

 

13 hours ago, Zarquan said:

The thing is, I see this as a significant problem in the game

I don't. I don't see 600 slicksters as "normal", sorry. It's like a game with 100+ dups. Those are extremes, pushing the game engine beyond its limits.

Would it be nice if the engine supported these extremes better? Definitely yes. Is it a major problem if it doesn't? I don't think so.

IMHO this is a case of "Doctor, it hurts when I do this. Then don't do that". I'm sorry, this is what I think, honestly.

[riwenna]

On 9/14/2020 at 6:43 AM, Zarquan said:

I was watching my ranchers and it took about a minute real time for the animals in the happy ranches to react to the ranchers calling them to be groomed.

I agree with most of what you said. I actually really love ranching-based economies, and in my current playthrough am trying the shine bug solar power. They're all trapped in one tile, I think the total count is still well below your 600 slicksters (I would say maybe ~100 bugs atm) and it takes my rancher forever to summon any critter in any rach to the grooming station.

[Zarquan]

13 hours ago, TheMule said:

I don't. I don't see 600 slicksters as "normal", sorry. It's like a game with 100+ dups. Those are extremes, pushing the game engine beyond its limits.

Would it be nice if the engine supported these extremes better? Definitely yes. Is it a major problem if it doesn't? I don't think so.

IMHO this is a case of "Doctor, it hurts when I do this. Then don't do that". I'm sorry, this is what I think, honestly.

But the thing is that there are people who play with stacked critters.  For example, riwenna above and Brothgar both stack shinebugs and generate solar power for them.  Some people set up more than one of these solar setups just because it's free power and it's a cool build.

Another common form of stacked critters is dreckos.  You have a few drecko ranches and the excess dreckos go in to a small room with only a shearing station.  This greatly increases the effectiveness of the drecko ranches, multiplying the plastic or reed fiber production by about 4 if I recall correctly.

Even more common, to the point where pretty much every late game base I see does it, is starvation ranching shovel voles.  Of course, you need fewer shovel voles, but I generally see large numbers of shovel voles in these bases.

I think the game should probably either not let us do things like this or should be able to make things not run too badly when it does happen.

If Klei implemented the first two ideas (Critters called by dupes get priority above other critters and critters who are about to die get a chance to save themselves), then the critter slowdown wouldn't matter until you had many thousands of critters.  But then you would probably start running in to ram problems, and that isn't solvable without a massive rework to how critters fundamentally work.

[Meltdown]

On 9/15/2020 at 9:49 PM, Zarquan said:

Caching can result in all kinds of strange behaviors in this kind of situation, like critters trying to walk through newly placed walls

I think that kind of problem could be solved by tying cache validity to room changes. The game already keeps tracks on rooms and enclosed spaces. If you add or remove tile inside the room, the game will detect it and run all kind of checks on that room. Determining navigation maps for different types of critter movement could be added to the list of those calculations.

[TheMule]

11 hours ago, Zarquan said:

But the thing is that there are people who play with stacked critters.

No doubt. I do too. I stack all wild pokeshells on one single tile.

11 hours ago, Zarquan said:

You have a few drecko ranches and the excess dreckos go in to a small room with only a shearing station.

Not really. I do that too, but you need a (relatively) large room with many shearing stations, one wouldn't do. I do one breeder ranch with glossy/mealwood for most of the early/mid game, later I add a second one with regular dreckos, and dump all the eggs (minus the ones for the unpowered incubators of course) in a hydrogen filled room with 3 shearing stations. That gives me all the plastic I need and a decent amount of fibers. But numbers are in the 30-40 (usually less) range counting breeders (I haven't actually counted them but that seems about right). I don't think you need to go bigger than that unless your goal is to fill every tile in the map with a chequered patter of plastic/insulation tiles.

Well at end game some folks like to have only hydrogen rockets, and many of them, but I'm not on the boat, I use petroleum rockets for all destinations <80k as they are cheaper and farm only 1-2 destinations with hydrogen rockets. Meaning I don't need much insulation, even at endgame. And if I do, I use the pwater from my boiler to grow thimble reeds, so far no map was so low on water that I had to worry about that. And I can pip plant wild ones. There are different solutions to the fiber problem.

11 hours ago, Zarquan said:

I generally see large numbers of shovel voles in these bases.

Not really. The vole/dup ratio is almost exactly the same as the hatch/dup in regular ranching, 1.6. Meaning, if you you have base with a reasonable number of dups (let's say 30) you need 50 voles. I also like to keep the wild ones (and tame only 1-2 of them), so make it 40+40. You set the context here, 80 voles isn't "large numbers" at all, compared to 600 slicksters plus all the other critters.

What you've described is what I do. But it's something more like, 40 pokeshells (if I'm lucky), 40 dreckos, 80 voles in a 30 dups colony. What are we at? 250 critters in the whole map? That seems reasonable to me.

What you wrote before, 600 slickster + all the rest, we're looking at 800+ critters on the map. That's more than times 3. Not the same thing. It's like comparing a colony with 30 dups to one with 100+. I expect problems. And I know of people with a low end gear that doesn't support even 30 dups well.

Of course we agree that it would be nice if the game engine supported 100+ dups and 1000+ critters on a 768x512 map. But the fact it doesn't isn't a "problem" to me. It's a limitation you have to deal with. As long as it supports "regular" gameplay, I'm not complaining. And I'd trade a smoother experience on a colony with less than 300 critter with problems for one with 800+ any day, if I had to make the choice.

11 hours ago, Zarquan said:

If Klei implemented the first two ideas

If the many assumptions we made are correct, and if Klei hasn't already implemented something along the line. That's a lot of ifs. We haven't seen the code. I'm all for criticizing an implementation when I see one. I'm not for criticizing something I am imagining.

I think the devs know the game better then we do. I trust them to know how to write a game better than I do, at least.

[Zarquan]

7 hours ago, TheMule said:

If the many assumptions we made are correct, and if Klei hasn't already implemented something along the line. That's a lot of ifs. We haven't seen the code. I'm all for criticizing an implementation when I see one. I'm not for criticizing something I am imagining.

It is clear to me that they have not implemented either 1 or 2.  If they had implemented 1, then there wouldn't be critters doing things between a dupe calling a critter and the critter responding.  But the critter would respond quickly.

If 2 were implemented, I wouldn't have critters drowning when they can easily move to safety.

7 hours ago, TheMule said:

Not really. The vole/dup ratio is almost exactly the same as the hatch/dup in regular ranching, 1.6. Meaning, if you you have base with a reasonable number of dups (let's say 30) you need 50 voles. I also like to keep the wild ones (and tame only 1-2 of them), so make it 40+40. You set the context here, 80 voles isn't "large numbers" at all, compared to 600 slicksters plus all the other critters.

What you've described is what I do. But it's something more like, 40 pokeshells (if I'm lucky), 40 dreckos, 80 voles in a 30 dups colony. What are we at? 250 critters in the whole map? That seems reasonable to me.

What you wrote before, 600 slickster + all the rest, we're looking at 800+ critters on the map. That's more than times 3. Not the same thing. It's like comparing a colony with 30 dups to one with 100+. I expect problems. And I know of people with a low end gear that doesn't support even 30 dups well.

I only have about 100 non-slickters and about 20 dupes.

7 hours ago, TheMule said:

Of course we agree that it would be nice if the game engine supported 100+ dups and 1000+ critters on a 768x512 map. But the fact it doesn't isn't a "problem" to me. It's a limitation you have to deal with. As long as it supports "regular" gameplay, I'm not complaining. And I'd trade a smoother experience on a colony with less than 300 critter with problems for one with 800+ any day, if I had to make the choice.

But the point is that these changes wouldn't affect anyone negatively.  Ranchers would be faster and critters won't die if they can save themselves.  These both seem like good things to me that I believe has no downside.

Quote

I think that kind of problem could be solved by tying cache validity to room changes. The game already keeps tracks on rooms and enclosed spaces. If you add or remove tile inside the room, the game will detect it and run all kind of checks on that room. Determining navigation maps for different types of critter movement could be added to the list of those calculations.

But then doors are still a problem.  An open door dosen't effect the room status but does effect the pathing.

[riwenna]

18 hours ago, Zarquan said:

riwenna above and Brothgar both stack shinebugs and generate solar power for them.  Some people set up more than one of these solar setups just because it's free power and it's a cool build.

Uuuh, feels straaange to find myself and Brothgar in the same sentence, even if it is his build I am using. Not a big fan of his heavily modded playstyle, but to each his own (and absolutely hats down to all of his contributions and calculations).

6 hours ago, TheMule said:

As long as it supports "regular" gameplay, I'm not complaining. And I'd trade a smoother experience on a colony with less than 300 critter with problems for one with 800+ any day, if I had to make the choice.

Yea, but "regular" gameplay can differ quite a bit from person to person... I tend to be a fairly slow and occasionally too-careful player (which unfortunately meant that the map where I've finally reached end game got rudely messed up by the Launch upgrade around cycle 1500 after pouring at least a year into it...). Which for somehow resulted in me constructing the shine bug solar first, integrated mini industry+oxygen brick second, and plumbed toilets after either of those in my current playthrough (I wanted a way to destroy of my germy P-water rather than designating a temporary dumping ground and since I usually do that by sending it to the electrolysers... we got metal refinement before proper loos).

The thing is, this is a game where people like to come up with over-the-top and limit-pushing contraptions and systems all the time. But I can get your point that optimising for 800+ critters on the map should probably not be a priority (and I made a bit of a mistake estimating how many shine bugs I have trapped in there... just continued adding bugs even after reaching max light, for... lime and lazyness I guess. So I do now, in fact, have 700+ domesticated critters. But, considering that I don't really need that many to keep my power going, I guess it's lights out for most of them so my hatches can get ranched).

6 hours ago, TheMule said:

That's a lot of ifs. We haven't seen the code. I'm all for criticizing an implementation when I see one.

Now, this, on the other hand, I can fully sign. I might have a hunch that there could be something done to improve the handling/decrease the load of critters trapped in a single tile. But, as somebody with training in computer programming, I don't even want to begin imagining the complexity of a simulation with this many interacting parts and systems. On some very, very, specific occasions I might be fairly sure I know what's causing the problem (like, when trying to store all the salt water on Oceania in a single infini-storage, and the game suddenly reading -2,147,483,647kg/tile before crashing), but in case of 800+ critters on a map... I wouldn't even dare to guesstimate.

[Zarquan]

29 minutes ago, riwenna said:

Uuuh, feels straaange to find myself and Brothgar in the same sentence, even if it is his build I am using. Not a big fan of his heavily modded playstyle, but to each his own (and absolutely hats down to all of his contributions and calculations).

His current run is actually two bases on a mirrored map.  He set it up so that one half is allowed to have modded buildings and the other isn't and each side runs as its own isolated base.  I haven't been following the series too closely (as I prefer staying as vanilla as possible too), but I definitely have seen a shine bug solar power plant or two in his non-modded side.

[riwenna]

6 minutes ago, Zarquan said:

He set it up so that one half is allowed to have modded buildings and the other isn't and each side runs as its own isolated base. 

Sounds interesting. Now if he only... removed the modded half :P

But I really do like his shine bug solar power plant design, can't help it. I just shouldn't have let them continue dropping eggs between the panels after the panels had maxed out, it would've probably be much more manageable (well, I'll know that in a minute... reducing the nubmer of bugs to just enough to keep the solar going at full power).

[riwenna]

So... after lights out for all the surplus Shine Bugs in that solar panel setup, and reducing the number of domesticated critters from 742 to 415 (out ot which 388 shine bugs... 8 in the main stable and 380 powering 8 solar panels total)... it takes a critter 30 seconds to realise it is dead on 3x speed :/

The Ranchers still seem to be having a hard time getting a critter to hear them whistle, but there seems to be somewhat an improvement to that (and to the fps...).

I could probably increase the Bug/kW ratio a bit by using the original 3-panel design instead of a 4-panel (since in my modified 4-panel desing the last panel gets only one tile of light, it takes many more bugs to max out the last of the panels)... and I don't even think it's a particularly "evil" or "exploitative" design - Shine Bugs give light. Solar panels turn light into electrical energy. This game is all about turning one type of resource into another one... it screams "put us together". Last playthrough I had... most of my resources obtained "organically", and all the critters ranched for material conversion. This seemed to be the next logical step, it really is a shame it makes the rest of the critters on the map so sluggish.

[KittenIsAGeek]

On 9/15/2020 at 12:31 PM, Zarquan said:

I wouldn't be having a problem if it was handling 200 critters in a tick.  Remember, I saw a slickster larva just float in to a 2 tile high liquid and sit there until it drowned.

The question you need to ask is "which of my 600 critters are the 200 that get evaluated?"  It is likely a shift evaluation. One tick gets the first 200, the next tick gets the next 200, etc.  That way all critters have an equal opportunity to be evaluated.  

29 minutes ago, riwenna said:

So... after lights out for all the surplus Shine Bugs in that solar panel setup, and reducing the number of domesticated critters from 742 to 415 (out ot which 388 shine bugs... 8 in the main stable and 380 powering 8 solar panels total)... it takes a critter 30 seconds to realise it is dead on 3x speed :/

Even when a critter sits in a single tile of space with no path to move around, it can still attempt to move.  It can change the direction it faces, and it can shift to one side or the other.  So the critter must still process the code checking to see if it has mobility.  

[Zarquan]

8 minutes ago, KittenIsAGeek said:

The question you need to ask is "which of my 600 critters are the 200 that get evaluated?"  It is likely a shift evaluation. One tick gets the first 200, the next tick gets the next 200, etc.  That way all critters have an equal opportunity to be evaluated. 

Except since there are only around 700 critters on the map, that means it should be handled within 3/5th of a second.  When I saw the baby slickster walk in to the 2 tile high water and sit there until it drowned, it did not get a chance to save itself.  Instead, it just sat there until it drowned.  Therefore, if it is a round robin approach like you suggest, it must be processing less than 5 critters per tick.

[KittenIsAGeek]

Just now, Zarquan said:

Except since there are only around 700 critters on the map, that means it should be handled within 3/5th of a second.  When I saw the baby slickster walk in to the 2 tile high water and sit there until it drowned, it did not get a chance to save itself.  Instead, it just sat there until it drowned.  Therefore, if it is a round robin approach like you suggest, it must be processing less than 5 critters per tick.

You're assuming that all critter evaluations are equal.  Depending on the algorithm involved, a critter trapped in a single tile may be more costly, computationally, than one with the freedom to move around.  The algorithm may be something like this: "Can move left?" "Yes? OK, pick left. Done. No?  Evaluate for movement right.  Yes? OK, pick right.  Done.  No? Evaluate for movement up by jumping/floating/flying..." Etc.  This sort of evaluation would dramatically reduce the computational time needed for a critter to find a movement path.  If it picks a random direction and can move that way, there isn't really anything more that needs to be done other than actually moving.  However, this sort of evaluation would increase exponentially for a trapped critter, because there would be a need to check every possible means of movement.  So, if the code can reasonably move 200 non-trapped critters about on the map without causing lag, that doesn't necessarily mean that it can do the same for 200 trapped critters.

[Zarquan]

2 minutes ago, KittenIsAGeek said:

You're assuming that all critter evaluations are equal.  Depending on the algorithm involved, a critter trapped in a single tile may be more costly, computationally, than one with the freedom to move around.  The algorithm may be something like this: "Can move left?" "Yes? OK, pick left. Done. No?  Evaluate for movement right.  Yes? OK, pick right.  Done.  No? Evaluate for movement up by jumping/floating/flying..." Etc.  This sort of evaluation would dramatically reduce the computational time needed for a critter to find a movement path.  If it picks a random direction and can move that way, there isn't really anything more that needs to be done other than actually moving.  However, this sort of evaluation would increase exponentially for a trapped critter, because there would be a need to check every possible means of movement.  So, if the code can reasonably move 200 non-trapped critters about on the map without causing lag, that doesn't necessarily mean that it can do the same for 200 trapped critters.

I highly doubt that they do this kind of assessment.  What they probably do is create the navigation map and pick a spot nearby to move to.  Otherwise, flying critters would only fly in straight lines before stopping and critters would freeze before going up or down steps.

I would also argue that if trapped critters take significantly more computation than non-trapped critters, this is a bug and it should be fixed.

[KittenIsAGeek]

Just now, Zarquan said:

I highly doubt that they do this kind of assessment.  What they probably do is create the navigation map and pick a spot nearby to move to.  Otherwise, flying critters would only fly in straight lines before stopping and critters would freeze before going up or down steps.

I would also argue that if trapped critters take significantly more computation than non-trapped critters, this is a bug and it should be fixed.

Valid point about the movement map.  That said...

Trapped critters would have no movement map, thus each tick they would need to evaluate if there can possibly be a movement map.  For a critter trapped in a tile (Bubbles really does get overly-excited at building sandstone floors!), I imagine that its as simple as a flag.  However, if a critter is in a space that is normally navigable (empty tile), then one would need a more robust method of determining when the movement map has a possibility of changing.

A possible way to test would be to make your single-tile farm a three-tile farm instead.   With three tiles of movement, there ought to be a movement map.  If performance improves, then the drag on the system is the test for a possible movement map.  If it doesn't, then there is some other mechanic in play that affects critter populations over a given threshold.