Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Arzgarb

Pages: [1]
1
Darwinbots3 / DB3 Questions
« on: June 06, 2009, 04:56:20 PM »
I'll have to change my previous comments a bit, because a thought hit me. In the vision thread someone mentioned linking vision to light, so that bots couldn't see in the dark and would have to use smell, hearing etc. instead. But to have working ecosystems in the dark, we must also have an energy source that isn't dependent on light. So, maybe we could have the substance leaf linked with sunlight, but also explicit veggies that receive energy independent of sunlight, something like chemosynthesis.

2
Darwinbots3 / Vision
« on: May 19, 2009, 12:23:50 PM »
Quote from: Numsgil
An eye can potentially see infinitely far away, dependent only on the  apparent size of what it's looking at. So as bots are idling because they don't see anything,  the veggies might grow large enough to become visible and the bot can  go off chasing it.  Likewise lots of smaller veggies clumped together might also become visible as the clump gets more and more bots.  Probably the way it would work is that rods are sort of like how non eye5s work right now, but with higher resolution.  If enough rods have the same value, it registers.  Otherwise it's ignored.  Or maybe rods normally have a random static signal, and a bot has to do signal analysis in its DNA to determine what might be a signal or not (maybe its a codule which gets called before the other vision codules I mentioned above).  Or maybe a bot just sets a threshold for how statistically significant a signal has to be before it registers.
"Infinitely far away" sounds quite scary when the performance goal is 10 cycles/sec with 1000 bots, since in the current version vision calculation takes the most processing power in a sim. Especially with 4 eyes and much better resolution. But if you can figure out a clever algorithm for the job, this would be really great.

Also, the normally random signals that the bot has to process itself sound nice, but it'll need to be robust. Like a system codule that takes input (some rod/cone values in the int stack) and produces output (last value of boolean stack?) that is then used to decide whether or not the signal will then be processed by the actual eye codules. But this needs thinking, because a bot can't know how many rods will be activated, and so how many input values it needs to process...

Maybe the codule gets called for every single rod except the first one. It gets 2 input values: the value of this rod and the previous one (or multiple values from both, depending on final implementation), and produces one (boolean) output: are they "connected"? This way connected rods form chains, and if the length of a chain reaches a treshold (decided by a sysvar?), it will get registered as a signal. But of course, this would be a potential performance bottleneck, depending on eye resolution.

3
Darwinbots3 / DB3 Questions
« on: April 29, 2009, 05:46:21 PM »
A species forking system would be interesting, but not that important. It could be left optional, or evaluated only on user command.

I think there should not be specifically assigned veggies, but instead just bots with their body consisting largely of chlorophyll. This has been the single most important feature I've been waiting for in DB3. No more zerosims with complicated feeder shepherds, they can now take care of themselves and still evolve to animals! Chloro, on the other hand, should have some kinds of movement slowing/shot weakening/other downsides, to prevent veggyism from becoming the automatic best solution.

An in-sim DNA editor would definitely be helpful, so that one wouldn't have to constantly reload a sim when tweaking with a bot. As of DNA visibility, it could be done pretty much like it's now: the DNA itself is invisible, but certain aspects of it can be seen through ref-sysvars.

DNA should be quite flexible, allowing complicated structures and maybe some obscure stack manipulation (stacks are preserved betweed codules, perhaps?). But, on the other hand, the sysvars need to be redesigned so that an exact value is seldom needed for a task. If shooting is implemented, it should be broken into as many sysvars as there are shot types, for example. This way, mutations on the control flow and conditional structures could be dramatic, but changing numbers little by little probably wouldn't.

4
Darwinbots3 / Darwinbots 3 Progress
« on: April 27, 2009, 03:21:38 PM »
Quote from: Prsn828
I don't quite get what you mean with the whole Mod:ing of base-pairs thing.

Right now, a point mutation call involves specifying the probability of each type of base-pair being the result.  For instance, one might choose that for a particular species, a point-mutation returns 25% numbers, 50% operators, 10% commands, and 15% (insert the other thing I can't remember here).

In this way, you could specify a larger % of numbers to be returned, and you would increase the proportion of numbers in the mutation results.

Well, that's not what I meant  

Another example: I created a tester bot whose DNA was a single pb, the number "345". I then set point mutation frequency to 1 and type-value slider to "100% type", put one bot to the simulation and watched. The "345" mutated to "~", then to "cond", then to "~" again. But when it got back to a number, it changed to 1. No value mutations occurred at any point.

What I think happened was that the bp was first of type "number" and value "345". When it mutated to "~", it was changed to type "bit command" and value "345 % X", where X is the amount of different bitwise commands in the program, because there is no bitwise command linked with the value 345. I can't read VB, so I have no idea how all this is actually implemented, but it seems to work this way.

Conclusion: numbers greater than about 50 are quite rare to occur in evolved DNA, because type changes will likely reduce them again.

5
Darwinbots Program Source Code / += -= *= /=
« on: April 27, 2009, 02:06:08 PM »
I'd change their names to something like "addstore, substore, multstore, divstore" to better fit in with the current syntax and to avoid confusion with !=, %= etc.

6
Darwinbots3 / Darwinbots 3 Progress
« on: April 27, 2009, 01:32:56 PM »
Quote from: Prsn828
Oh, and DNA will be much more robust this time around.

One thing that currently reduces DNA evolvability is the mod:ing of values. For example, if a mutation changes a number to a logic operator, its value gets mod:ed to the number of values in the "logic operators" class. Since the amount of commands in other classes than number and *number is quite low (under 20 in all, I think), evolved DNA seldom contains large numbers. This could be fixed by not mod:ing the value of the base pairs and maybe storing the mod:ed value somewhere for faster use. What I mean is that while a bp now looks like (type, value), it should be changed to (type, value, modvalue), where modvalue only needs to be recalculated when a mutation occurs.

Quote from: Prsn828
Bots would be able to interact with the particles, and I believe they would likely need to break these particles off of solid, polygonal chunks of material in order to use them.
In this way, only the broken-off pieces would really interact with anything on a particle level, and the remaining polygon chunks will still be treated as a single object.

If particles can be broken off of shapes and then consumed by bots, you'll also want to allow them to be released again (maybe when the bot dies?) and to get packed together and transformed to a shape again. Otherwise you'll eventually end up with all material being chopped to particles and eaten up.

7
Darwinbots3 / Darwinbots 3 Progress
« on: April 19, 2009, 01:24:15 PM »
Quote from: Numsgil
Quote from: Arzgarb
And then about fat, chloro and muscle: will there be a limit on these total, or individual limits? If there will be a total limit, what happens when it's been reached, and the bot tries to make muscle, for example? Will nothing be made, or will muscle be made and fat/chloro removed?

I'm thinking no limits at all.  A bot gets a "normalized" quantity as a readback from its sysvars.  Like *.chloro might return 899, meaning that a bot is 89.9% made of chloro.  The bot itself might be tiny or really, really massive.

Right... So if the bot is, say, 70% chloro, 20% muscle and 10% fat, and size 100, and tries to make 10 more fat, it would after that be about 63,6% chloro, 18,2% muscle and 18,2% fat, and size 110? (If chloro, muscle and fat will be the final substances)

8
Darwinbots3 / Darwinbots 3 Progress
« on: April 17, 2009, 07:25:56 AM »
My 2 cents:

You talked about making multibots by making bots "sticky" and creating hinges on contact. Could that be used later on to make shell out of sand by sticking it to the bot's skin?

Also, has it been decided yet whether bots will gain energy by shooting, ties or phagocytosis(sp)? If phagocytosis is chosen, how will it be done? Someone else talked about bots opening "mouths" to their fronts, or bossibly to any side. I think the eater bot could then apply a force to another bot (with a .pull sysvar or something), trying to pull it through its mouth. The other bot could escape by simply running away or killing the eater before getting digested, but if the eater it smart enough to close its mouth, the food stays inside (it could still shoot). They could be treated like a shape in a shape, like bots in the sim.

And then about fat, chloro and muscle: will there be a limit on these total, or individual limits? If there will be a total limit, what happens when it's been reached, and the bot tries to make muscle, for example? Will nothing be made, or will muscle be made and fat/chloro removed?

Yay, first post ever after years of lurking  

Pages: [1]