Darwinbots Forum
Code center => Suggestions => Topic started by: Numsgil on April 14, 2005, 10:05:26 PM
-
I'm working on the egrid right now. Currently
A couple of issues:
1. How should you be able to dig into dirt, etc? Is it:
A. Shots. Maybe a -1 or -6 shot, or maybe even a whole new one!
B. Ties. Fire a tie at the ground and begin sucking.
C. A special new interaction method.
2. How long should it take to dig? Pretend you find a grid square packed to the brim with dirt. What kind of time frame should it take to clear it?
3. How do you spit it back out? Where do you store it? Are you allowed to feed while carrying a load if dirt or whatever?
4. About how massive is dirt, etc. I'm thinking that carting around a full load of it should slow you down as if you had built a bunch of shell. However I don't know what a full load is. How many trips should it take to clear out an egrid square?
Egrid squares are a little smaller than a regular bot.
-
I think ties make the most sense.
I have no idea about the other questions though.
-
OK, what do we learn from nature?
Who digs dirt? Two diggers come to mind: a mole and an earthworm.
Mole pushes the earth apart. It applies some energy to move dirt from where it was to some other place. Would it be possible that dirt from the square containing a bot is moved to neighboring squares? Bot bumps into dirt - dirt moves. Other organisms do that too: roots of plants, bacteria....
Earthworm swallos the dirt ahead of him, runs it through his digesting tract and leaves behind. Less common, but an idea anyway... And the bot needs to span multiple env.grids... maybe a multibot? If we simply allow bots to absorb anything from env.gird, then the head of the worm can "absorb" dirt, then share it back to its butt and the butt would "waste" it.
This is just the first thing that came to my mind. Let's see if other people have better ideas.
-
The system I'm thinking of can allow the 'mole' method of packing the dirt harder at the sides pretty easy. There's a zone between 'packed hard enough you can't get through it' and 'solid brick of material'.
Earthworm type methods can merge with ant like methods. They differ only in what is done with the 'eaten' material. That's my main emphasis. Trying to get a method for building ant nests.
-
Hmm, one way is to make "dirt" just another substance on e-grid. We were thinking about "absorb" commands that would grab a portion of stuff from the current square and place it in the stomach. These commands would be either very specific, addressing a particular layer of env.grid (say, to absorb only glucose) or very general, where a bot would just grab a piece of "whatever is out there". Then the bot could digest whatever it can and dump out "waste". So bots would run out, "absorb" dirt, run back and "waste" it out.
Or we can make special rules for dirt. Right now I am OK either way.
Maybe special rules is better, because dirt "will" be special - it will have characteristics that distinguish it from all other substances on env.grid, right?
P.S: 2.36.5 runs fine for me for 3 hours already. It is just 600,000 cycles (becuuse I am running size 12 with > 300 bots), but so far not probs.
-
I'm hoping to allow the env grid to have such broadly defined materials that things like dirt, etc., that seem special cases are in reality just subsets.
Absorbing dirt, however, can only be done from adjacent squares. So we need a way to absorb from grid squares adjacent to the current one. And then of course you have the issue of fat bots.
So are we thinking a custom absorbing method then? Something like ties would be neat, but it might be difficult to implement.
-
I think it should kinda be 2 layers, one is the upper one where you start, and one is a lower one where you can use a dig command to dig down to the lower dirt level.
You keep digging as long as .dig = 1 and you're there and there is dirt in the way. The energy to move will then be higher since you're digging. When set .dig = 0 then you dig up again, back to the surface. If you then enter the hole you dont need to set .dig to anything.
-
That's an idea, but it's a little flat still. You're either above ground or below it. That works for some behaviors but makes ant nests more difficult (I'm thinking I'd want nests like simant has).
-
Let's not get into 3d just yet. Don't really like the layers of "depth" idea much. Should be more like the side view of a very thin ant farm.
-
its not 3d, we just simply have a few levels of 2d, we can have more levels if we want. like if there is 4 levels then 3 .dig would mean we dig to the deepest one
-
whit that way we can create enourmus nests whit mazes and other stuff
-
whit that way we can create enourmus nests whit mazes and other stuff
But you would only be able to display one level at a time on the screen so your bots would keep bumping into invisible objects on other levels :blink:
-
im sure the pc can handle different levels and keep them seperate, but yeah you wold only be able to see one, unless you add an option to split the screen so all levels get a part of it
-
Please, can somebody (best of all Nums, I think, since he's directly working on the project) give me a rapid (but possibly complete) description of the features of the environment grid you're going to implement? I don't exactly know where to look to find one.
Thanks
-
E-grid overview.
The new e-grid is a multi (infinite actually) level array measuring 12 X 90
Most of the levels cover contain representations of concentrations of environmental stuff such as Oxygen, Carbon Dioxide, temperature, waste products like ammonia, Nitrates and Nitrites. Calcium and Silicon for use in building shells.
We are also intending to make at least one level represent walls of some kind to which robots can tie or dig into.
Robots will be able to interact with the grid square which they currently occupy.
Some interactions will be automatic such as veggies using sunlight and CO2 to make energy, growth and Oxygen.
Others will require input from the robot to actively gather something or poop waste to the grid.
Beyond this we plan to have an active "enzyme" system in which robots can specialize in various different types of metabolism. While not strictly enzymes, these processes will still be controlled by a mutating bit pattern stored in the DNA file. Eventually this will completely blur the distinction between plants and animals since each can use multiple methods but with greater or lesser efficiency.
Energy will be able to be derived from such diverse things as the nitrogen cycle and Sulfer metabolism such as found near black smokers.
-
The new e-grid is a multi (infinite actually) level array measuring 12 X 90
Guess you mean 120x90...
Oxygen, Carbon Dioxide, temperature, waste products like ammonia, Nitrates and Nitrites. Calcium and Silicon for use in building shells.
It seems it's not the matter of building an envgrid, but of finding adequate use of all this new things. So, which interactions are you planning to assign to all these new variables?
The idea of the "enzyme" system it's interesting, but seems to me a little bit vague. I think you should introduce it in the envgrid only ([you]only[/you]) when the first level of the envgrid, that you described above, will work [you]perfectly[/you].
Finally, what about the features of the original envgrid? Envgrid was conceived to localize in each of its squares the environment settings. That is, to give the ability to assign to each square different physics parameters (ex. friction, moving factor, brownian, gravity, buoyancy, all sorts of costs, light irradiation / energy feed, maybe mutation rates, and so on). This was the first, most coherent and straightforward idea to create different environments in a single sim, in order to achieve prolonged coexistence of different species in the same sim and speciation by colonization of new environments.
What happened to this project?
-
later it will also be differens in light depend on how far away you are from the equator, what time of the year/day it is
-
Finally, what about the features of the original envgrid? Envgrid was conceived to localize in each of its squares the environment settings. That is, to give the ability to assign to each square different physics parameters (ex. friction, moving factor, brownian, gravity, buoyancy, all sorts of costs, light irradiation / energy feed, maybe mutation rates, and so on). This was the first, most coherent and straightforward idea to create different environments in a single sim, in order to achieve prolonged coexistence of different species in the same sim and speciation by colonization of new environments.
What happened to this project?
It's on the back burner. Walls, etc. are being worked on currently to work through the grid. Later, I'll be adding ways to change the physics of an area other than just making it 'hard'.
Hopefully the final version allows alot of customization by the end users.
-
It's on the back burner.
hmmmm. I think I hate democracy.
-
y hate democracy? are you somekinda nazi or what? or a terrorist?
-
I think I have found the right place for my suggestions, at least I hope so, please bear with me if the idea isn't very clear, I'll be happy to try and clarify any points.
As I understand things the envgrid breaks the area down into lots of smaller areas so that enviromental conditions can vary across the region. While trying to model chemicals and enzymes to use these chemicals is most accurate it is also by its nature most complex, I suggest just three conditions to be defined in the Envgrid. Firstly the ammount of energy available to a browsing bot (or veggie) secondly Enviromental damage this could represent many things (simplest implementation would be a per cycle reduction in energy for bots in the affected area), and thirdly temperature, which I envision as affecting the energy cost of actions, my limited understanding suggests that in a cold environment things slow down, this could be represented by increasing energy costs for actions, and conversly decrease energy costs as temperature increases above the norm.
High temperature as I understand things also causes damage to cell structures, which is one area where the environmental damage could be used to help find balance.
A fourth variable I'm not so sure on the practicality but I consider worth a mention is enviromental mutagenic factors, that either increase or decrease the chance of mutation when a cell splits in the affected area.
As a side note this simple modeling of environment would I think allow an attempt at modeling the black smokers... but I don't know enough on the topic to do more than guess that it would be possible.
The other consideration of great import in this envgrid is the size of the squares (I presume squares, though any other tessalating shape could work in theory, but squares are simple). If the squares as much smaller than the bots then each bot is geing to be on multiple squares and I think for simplisty the affects of each should accumilate, this would have to be taken into account when setting the values of the affect that environment has on on the bot, also this would make shared resources rarer. However I think more interesting things will happen if the squares are closer to the size of the bots (as long as the sides of the square are less than the diameter of a bot the least number of squares a bot can be touching is four and I do not recommend having squares with sides larger than the diameter of bots), larger squares allow for multiple bots to be affected by the same part of the environment and for an energy source to have to be split between browsers, in this model I would suggest for greater variability the average of environmental affects be used, yet with some added formuli to show the shared resources. For example two browsers next to each other each occupying a total of six envigrid squares (simple 3*2 grid), each bot touching four of the squares, the middle two being occupied by both bots.
For temperature and environmental damage take the average of the value for each square occupyed, for browsing (energy gain from environment) the middle two squares being both occupied have their values halved. So if the energy available in each square is E (assuming equality for simplisty in this first case) each browser can gain (E + E + 0.5E + 0.5E)/4 or 3/4E Where as if they seperate they can both gain E.
If the distribution of energy is uneven then things become more complex, and if browsers have the ability to test possible positions arround them to look for richer feeding grounds interesting patterns of flocking to rich sources and solitary browsing could emerge.
That the damage caused by the environment is not dived is intentional in my thinking, I think that if an area is dangerously acidic/hot/whatever this is not reduced because it is effecting multiple bots.
I think that the ability to detect the energy availably from the environment and the ability to feed on it should be seperate functions, but that the ability to browse should have some inherent disadvantage, I suggest an increased cost for non browsing actions, this would allow preditors to monitor the available energy and wait for a browser to get close enough, effectivly ambusing it. If the ammount of increased cost is a user set variable the user can define the likelyhood of developing omniverous bots by evolution, seems to me to be an interesting thought, yet for leagues it can be set so high as to make omnivours impractical, which is I believe one of the arguments against removing the distinction between bots and veggies.
I hope that's comprehensable to everyone, I know some of the parts I mention are more relevent to other threads, but as I wrote I kinda got into a flow of thought and hacking this appart to post it multiple places seems inappropriate as I think it is all linked.
Thanks for reading, I hope you found it worth the time.
Math