Darwinbots Forum
General => Off Topic => Topic started by: Anonomous Guest Person on March 13, 2005, 05:11:10 PM
-
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.)
-
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
-
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.
-
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
-
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.
-
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 :(
-
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.
-
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 :(
-
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]
-
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
-
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.
-
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
-
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.
-
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)
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
-
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.
-
Could work but you have to include the threshold check at some point otherwise you get diffusion from low to high sometimes.
:D PY :D
-
How? Could you explain?
-
In my code above, a particular cell only accepts "bleeding" from an adjacent cell if the value in the adjacent cell is greater than its own. This may or may not save on computing since it requires conditional statements.
In my code I can easily adjust the threshold (cell value difference) so that nothing happens when the two are almost the same or so that nothing happens when they are 10 apart or 100 or whatever. I normally set it to about 2 or 3. This way the e-grid tends to even out a lot better than if a cell grabs a percentage of the value from all surrounding cells regardless of values in them.
Make sense or am I still not explaining it well enough?
:D PY :D
-
You're basically checking the direction of osmosis. You don't want to go from low concentration areas to high concentration areas.
-
I don't think it will. I just don't see how. If stuff moves in both directions, then by definition more will move from higher concentrations than from lower.
Say you have two cells, A with 300 of something and B with 30 of something. When one third moves in both directions you get:
30 moves from A to B
3 moves from B to A
Final result:
A: 300-30+3=273
B: 30-3+30=57
If you start with both cells having 30, then it will be:
A: 30-3+3=30
B: 30-3+3=30
So it works. No nead for threshold conditions. Am I missing something?
Whether computationally it will be better to exclude from calculations cells with similar values, that I don't know. You are programmers, you figure it out.
-
Actually you are right. Your idea won't allow stuff to travel from low to high.
The only real problem with it is that it moves too much in one go. Within 10 cycles everything is homogenized pretty well.
My present system only allows a cell to lose 1 point in each of four directions so the rate of osmosis is limited. I deliberately did it this way so that places like black smokers where Sulfer is extremely high will not disipate into the rest of the sim too quickly. Otherwise there really won't ever be any areas of high and low concentrations. Without this difference we might as well not have an e-grid at all.
:D PY :D
-
What we need is a checkbox in the options screen for the speed of diffusion from cell to cell.
When in doubt, make it an option! :boing:
-
Yep, 1/3 was just an example. The real speed would depend on how you view DB - whether it happens in water/air/ground and whether bots are tiny/medium/large.
As for moving only one point per cycle - the speed should depend on the "difference" in concentrations.
-
It is all built with reference variables so that it can be adjusted from options eventually. That has always been my intention. So far I have connected it through but it will be easy enough to do so when I get around to it.
The difference threshold and the rate of diffusion will both be adjustable.
Maybe the rate can be dependant on the difference. Doesn't matter much either way except that the rate does need to be very low if we want any kind of environmental niches to form.
:D PY :D
-
One thing that we absolutely must have to get niches is bigger sims (what this thread started off) - bots should not be able to go from one side of the screen to the other. And that ties in with diffusion. If bots can cross the screen, then diffusion should be able to go over the whole screen fairly quickly too. Just some numbers to put this in perspective: the size of E.coli is ~ 5 micrometers. Which means that to get a niche of 5 millimeters wide we need a part of the screen to be 1000-fold larger than the size of a bot. And diffusion would go over that distance quite quickly...
-
First of all when I seen the vb code PY posted I sayed "wow nice"
***
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.
A.G.P. check this out http://s9.invisionfree.com/DarwinBots_Foru...p?showtopic=146 (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=146)
read the first post about "lessbeef" bot. , ( good idea a.g.p.)
***
PY, the only way to awoid going from intagers to longs for .xpos and .ypos is to have them as arrays (like everything in the Processor brakes into bytes 0,1,0,1, = 5)
Then have somthing like .getposerraylen so the bot will know how mutch intagers its working with just to get .xpos or .ypos
-
...or actually change the entire memory array into longs.
-
Occams razor applies here I think. (well probably it wasn't intended this way but what the heck)
If you can fix something in a simpe way than why mess about with complex stuff.
Changing all variables from integer to long isn't that difficult and it might even speed up the program since we can lose a lot of limits which at present are set to 32000 only because that is all an integer can handle. It is also quite possible that windows (a 32 bit environment) could well process long variables more efficiently and quicker than integers.
I did a few experiments with running robot memories as longs. It took about 10 minutes to convert and ran just as quick as it does now. The only reason I temporarily abandoned it was because I didn't have time to update every single subroutine that demands an integer input from the call. That would take a couple hours or more.
Bots, that sounds like a scaling system which although it wil work in theory, will cause a shit-load of grief at much larger screen sizes for robots like Ant-Bots who need a precise destination to return to the queen.
As I explained before, in a sim at size 1000 (1000 times bigger than standard), the coordinates would run from 0 to 9,000,000 along the x axis. If we use a scale factor of 1000 to keep the .xpos variable at 9000 then it will eventually become difficult for the ant to find its queen. When the robot is at position x=9,000,000 it will actually have more than 10 robot-widths at that loaction. It may never find the queen at all.
However with longs, it is trivial to return a value of 9,000,000 to .xpos.
:D PY :D
-
The only possible problem is that it complicates the already increadibly painful mutations system. If you have a value of 9000000 in a memory location, it could make some really crazy mutations. If we can keep all the memory locations at about the same range I think mutations would run easier.
I still like my idea of returning the Egrid location. I'll have to play with it a bit when I have the chance.
-
Returning the e-grid location has a number of benefits and a number of pitfalls too.
I know I keep on about the ant-bots but it does bring home a point. It is absolutely essential for an anaimal to be able to return to the exact same location that it was born.
Salmon go to the same river. Sea turtle go to the same beach. Ants go back to their nest.
Using the e-grid system would allow for almost infinite size playing fields but anything over about size 20 would screw up homing instincts. The queen ant is pretty big so you would only need to return to a position within a couple of hundred twips of it but it will soon become impossible to find her at large sizes.
:D PY :D
-
I'll look into the feasability of keepin the egrid squares sizes in twips constant but expanding the number of boxes as the size of the playing field increases.
-
That would be by far the best way providing we don't get a huge hit on speed.
Give it a try.
:D PY :D