A point on movement in Darwin Bots

[Anonomous Guest Person]

I've often seen an arguement being used.
That arguement just happens to be that most organisms can't go from one point to another quickly. If their food source vanishes, the organisms that feed off of that food source most often should die along with it.
However, if you watch any Darwin Bots simulation, that isn't the case. Most bots can survive a trip across the field. Even if it's a very large field!
And also, most bots can generally do this rather quickly.
In fact, some energy efficient bots that convert body to and from energy efficiently enough could survive for generations!

It's my belief that this is one of the reasons that stable ecosystems only consist of an omnivoric predator, and a plant that unfortunately usually depends on the system for survival in more ways then one. (Approximately two to be precise.)

In fact, I think that the next challenge will be making a bot that can actually remember things, and pass such knowledge off to children, to the point where in mere generations, the species will have mapped out the entire field.

I'm not technically saying this is all bad, but it does make it less of a life sim. (Though the last paragraph means that there're more forms of evolution, which is good. By the time you read this, I should hopefully have written a point about evolution in Darwin Bots.)

I'm simply saying that, in Darwin Bots, most life forms can, and DO, go from food source to food source plenty of times.
I'm also saying that the advantage to this is that we can develop smart bots, that can map the environment, and gain an intelligence advantage over other bots.
Unfortunately, the consequences to this might make such an advantage useless in practice, since powerful bots can often make short work of everything else.
(Though I suspect that once permanent waste is fixed, powerful bots will be rather inefficient.)

[PurpleYouko]

I think one of the biggest problems here is that when veggies are reseeded, they appear in random locations.

Possibly they should appear near to the last veggie that died. This will keep food sources in roughly the same place throughout the game except in F1 mode when we want the food to be well spread out.

I have a couple of ideas how reseeding can be revamped using the "POFF" that dying robots leave behind as seeds that become new veggies after a certsain time has passed.

 :D  PY  :D

[shvarz]

One way to fix this is to greatly increase the friction in the system.  But you'll have to re-design your bots for such system.  Larger sizes and/or uncrossable barriers would be nice too.

[PurpleYouko]

Larger sizes would be good but we need to work on the zoom function a little.

Another BIG problem with larger sizes is that they screw up the robot's positional functions like .depth, .ypos and .xpos.

As soon as one of the screen dimensions gets bigger than 32000, the whole game just comes crashing down when one of our little bots tries to store it into a memory location.

Possible answer:  Change all robot memory cells from integer to long. Has a lot of knock on consequences though.

 :D  PY  :D

[Numsgil]

Maybe for things like depth, xpos and ypos, we store it's egrid location instead of its actual x,y pos.

There are like what, 120 x 90 squares in F1 standard?  That allows for a game 266 times larger than F1 along the x axis.  That's like 764 Million times as large as F1 in area.  All without changing the size of the robot memory array.

[PurpleYouko]

But you are talking about the e-grid.

I am talking about the x and y coordinate system which in a standard game under F1 conditions is somewhere around 8000 X 6000.

Anything over size 4 kills it.

 :(  PY  :(

[Numsgil]

What I'm saying is that instead of representing sizes to the robots in terms of twips (which are very tiny) we represent in terms of the Egrid squares, which are roughly the size of robots.

If a man is measuring distance in millimeters, it might not be a bad idea to hand him a meter stick.

[PurpleYouko]

OK I see what you are getting at but the problem then will be that as we get to larger and larger sims, the e-grid squares will become proportionally larger than robots so species like my Ant-Bots will not be able to find their way back to the queen.

To be honest I don't think they would work too well at size one in such a system. They need precise coordinates to feed the queen.

With some different programming I could make them work at size one but just imagine size 100. To a robot in that scale, one egrid square would be the equivalent of the entire screen at size one. There is no way that any kind of ant-bot could work in that kind of system. All the commands like .angle, .ypos, .xpos etc. would be about as much use as trying to find a street address with a map that only shows state highways.

 :(  PY  :(

[Numsgil]

I was thinking that are larger sizes the egrid's squares don't get larger, it just gets more of them, with each square being the same size.

For an ant bot, the queen is definately about as large as a single Egrid square.  An ant bot would have to go towards the queen's Egrid then look around for it.

She shouldn't be too hard to find, she's so fat...

(how fat is she?)

she's so fat when the drones come back to return food, all they have to do is fire in her general direction, even if they're halfway across the field.

...

[Fires writing staff]

[PurpleYouko]

More egrid squares?

That would get incredibly memory and processor intensive at large sizes wouldn't it.

To update the grid you have to scan the entire grid from top left to bottom right and adjust the level of each square based on the others around it. Imagine doing that on a size 100 sim with 12,000 X 9000 squares.

That would make 108,000,000 grid locations to update  :blink:

Don't think that is feasible. Do you?

That is why my vision of the e-grid (well Carlo's actually) is to keep it as 120 X 90 for all sizes, just change the scaling factor.

 :D  PY  :D

[Numsgil]

I'd have to play with it to know for certain.  It may not be as bad as you think.  Each single cell can only bleed into the ones around it, right?

I made a forest simulator I while back that had this same problem.  I could look up the code for it.

If done right, it would only be on the order of O(n), which isn't bad at all.

[PurpleYouko]

The way I have it working is that each cell only scans those directly above, below, left and right. I left out diagonals because it slowed down too much.

I also only update the grid on every 10th cycle to save game speed. When I tried doing it on every cycle it slowed the game down to a crawl.

Take a look at my code by all means. Speed it up if you can.

 :D  PY  :D

[Numsgil]

Did you fix the order of updating bug that I had in my forest simulator?

Here's the problem I had:

1.2.3
4.5.6
7.8.9

^ egrid.

cell 1 updates.  This causes 2 and 4 to change.  Then cell 2 updates, this causes 1 5 and 3 to change.

But there's a problem!  Cell 1's bleed effect has changed cell 2 before cell 2 updates, but the same is not true for cell 2's update of cell 1.

The answer I came up with way back when was to create a psuedo grid that stored the changes, so all changes could be applied after all cells updated.

I'll look at your code later when I have a chance.  It shouldn't be computationally expensive.

[PurpleYouko]

Actually my way does get around your problem to some degree but not quite in the way you suggest or possibly as efficiently.

What I was concerned about was making sure there were no net gains or losses of stuff in the entire grid.

Here is roughly how it works for a grid

1 . 2 . 3
4 . 5 . 6
7 . 8 . 9

Starting at cell 1, the program compares the value with 2 and 4. If there is a big enough difference then modifications are made otherwise nothing is done at all.

If the value in 2 is greater than that in 1 then a certain proportion of the difference is removed from 2 and stored temporarily in an independent variable.
next the value in 1 is compared to 4 and again if the difference is above a certain threshold, a portion of the difference is removed from 4 and added to the temporary store.

Once all neighboring cells have been checked, the temporary store value is added to cell 1

Then we move on to cell 2 and repeat.

In this method we are double checking cells that may have already been the central cell but changes will only be made if the value in that cell is bigger than the one in the present cell. In actuality I have never seen the value shared back again from cell 1 to cell 2.

At the end of the entire grid scan I inserted a check sum (not there in the present code) to see what the total was and it always stayed the same so I am happy that the math part is working.

I tried going the other way with each cell pushing its excess to the others in equal ammounts at first but that didn't work so well.

Using another layer of the grid to store changes and then adding them back in was one possible option to use but it would have meant scanning the grid twice to update the values. My way was a compromise that allowed for faster code.

here is the code for the grid updating (to save you looking for it)

Code: [Select]

Public Sub RefreshGrid(z As Integer)
  Dim Change As Single
  Dim tot As Single
  Dim val As Single
  Dim Threshold As Integer
  Threshold = 3
  Change = 1
  For xx = 0 To 120
    For yy = 0 To 90
      val = grid(xx, yy, z)
      
        tot = 0
        If xx < 90 Then
          If grid(xx + 1, yy, z) - val > Threshold Then
            grid(xx + 1, yy, z) = grid(xx + 1, yy, z) - Change
            tot = tot + Change
          End If
        End If
        If xx > 0 Then
          If grid(xx - 1, yy, z) - val > Threshold Then
            grid(xx - 1, yy, z) = grid(xx - 1, yy, z) - Change
            tot = tot + Change
          End If
        End If
        If yy < 90 Then
          If grid(xx, yy + 1, z) - val > Threshold Then
            grid(xx, yy + 1, z) = grid(xx, yy + 1, z) - Change
            tot = tot + Change
          End If
        End If
        If yy > 0 Then
          If grid(xx, yy - 1, z) - val > Threshold Then
            grid(xx, yy - 1, z) = grid(xx, yy - 1, z) - Change
            tot = tot + Change
          End If
        End If
        grid(xx, yy, z) = grid(xx, yy, z) + tot
      
    Next yy
  Next xx
End Sub
z represents the grid level to be scanned.

As you can see I only scan one layer at a time so that the program doesn't take such a speed hit. I tried doing all the layers and it pretty much stopped the program dead in its tracks. 20 cycles per second became 1 cycle.

Believe me when I say this stuff is extremely processor intensive.

 :D  PY  :D

[shvarz]

I noticed that you guys are looking at spread in both directions at the same time.  It might be easier to do diffusion in horizontal and vertical directions in separate cycles.  On one cycles it diffuses horizontally, on the next - vertically.  Not as accurate, but may be much easier.  

The diffusion rate might be different, but let's say it is such that over one cycle 1/3 of all amount in one cell diffuses into next. And 1/9 into next and so on.  If you have cells

A B C D

Then to calculate the amount of A in the next cycle simply use

A+1/3B+1/9C+1/27D

Single pass - all values calculated.