Darwinbots Forum
Code center => Darwinbots3 => Topic started by: Numsgil on July 25, 2007, 07:04:17 AM
-
These are all rather inter-related concepts. I think they mesh well; we'll see how they flesh out under scrutiny.
[you]Substances[/you]
First, there's basic substances. These were discussed before: (here (http://www.darwinbots.com/Forum/index.php?showtopic=1588))- nrg - As now-- keeps a bot alive and is the currency actions are paid with. A bot can only keep so much nrg on hand, though. Nrg is massless, volumeless, and otherwise exists more as an abstraction than a physical substance.
- Waste - Waste is produced whenever nrg is used to fuel a process (move forward, etc.) and from the metabolization of poison and venom. It's also massless and volumeless. As now, it can cause Alzheimers if it builds up in too great a quantity.
- Poison and Venom - Also massless and volumeless. Works very similarly to how they do now (more later). A bot needs to metabolize poison and venom into waste to remove the effects (effects do not wear off over time).
- Fat - a longer term nrg storage solution. Fat has medium density. Probably comporable with how body works now.
- Muscle - denser than fat. Muscle also has an nrg upkeep every cycle that needs to be paid. Muscle is the engine that bots use to do pretty much anything. The more muscle a bot has, the easier it is to perform multiple tasks in a cycle, or give stronger efforts.
- Chloroplasts - Very volume-y (makes your bot get really bloated) and heavy. Animals can build chloroplasts but it'll make it harder to move (F = mass * acceleration, remember) and a larger target (more on this later). Chloroplasts turn light a bot receives into nrg.
- Shell - Mostly as now-- protects against shots.
- Slime - Mostly as now-- protects against ties.
In general, bots can only build or destroy substances slowly. A bot would find it difficult to quickly drop 90% of its fat into nrg during a fight. My goal with Fat is to differentiate between nrg available for combat and nrg stored for long term survival (so that a victor of a battle has a prize. This will make sense later in the post).
[you]Vision distance[/you]
It'll mean using a better space partitioning scheme, but basically a bot has the potential to see forever away. However, bots can't see objects that have an apparent size (http://en.wikipedia.org/wiki/Apparent_size) that is too small. This threshold probably also relates to how big the bot is itself. Very small bots can become so small that they're all but invisible to a larger bot. Very large bots can become so large that they're visible from everywhere on the field. The idea here is that it encourages niches. Very small bots can easily prey on larger bots without being noticed. Of course, they're also going to have a hard time doing much damage to a larger bot.
I'm not totally sure how I'm going to handle aggregate size, like a field of 100 veggies that's too far away to see individual veggies but close enough that you should see a green smear. But I remember reading about various algorithms so I don't think this should be too impossible.
[you]Vision information[/you]
The present method of refeye and myeye will be replaced with a more superficial system. You can tell the following about a bot just through vision:- relative velocity
- distance (or maybe just use apparent size and have no depth perception at all. Not quite sure. You could try to just keep moving towards another bot until you bump into it.)
- in/out pairs
- target's shell and slime (but not poison and venom)
- angle from bot's eye to target bot (this and distance basically give you polar coordinates for the other bot)
- angle target is looking
- if the target is tied to anything
- if the target is shooting
- size (radius or diameter)
- nrg (maybe. Might be neat if there isn't an easy way to tell if something is dead or not)
Maybe some others depending on new features. The basic idea is that the amount of information you can gather from another bot just by looking depends mostly on its observable characteristics. Snooping for more private details (like how much nrg the other bot has) requires other methods. I'm imagining in/out being used as the primary conspec recognition system.
[you]Size[/you]
Instead of having 100 nrg be a hard and fast amount, the 100 instead means a supply of 100/1000. As a bot gets physically larger, its capacity for nrg, muscle, fat, just about anything gets larger with it. So a very small bot looking at a huge bot basically sees an infinite supply of nrg. If a small bot had 100 muscle and grew 10 times larger, it would read a drastically smaller amount of muscle. It's actual muscle hasn't changed, but it's relative amount has.
In this way, artificial limits like we have on body right now (32000 capped) can be removed. All the controls scale with the bot as they get larger. You could have a bot with 4 billion chloroplasts. And since a bot's radius increases with the cube root of volume, even gargantuan bots aren't going to be unimaginably bigger. The simulation and user can handle it. (A bot with 4 billion fat might only be 100 times larger than a bot with 1000 fat).
It also means that keeping your bot 20% muscle 30% fat, at 78% max nrg capacity, etc. is very easy. Absolute amounts don't matter much.
On the other side, where things get very tiny, we'd probably want to set up some sort of minimum bot size (the DNA has a physical size maybe).
[you]Combat[/you]
This would represent a rather large change.
Shots get streamlined. The familiar -1 shots become a strictly attrition weapon. Instead of returning nrg shots, they just lower the target's nrg. Your goal with these combat shots is to kill your opponent. Venom becomes the "special" feature for shots, and works largely like it does now (see the discussion of poison below. Venom works the same, only it can be shot). Shots can be stopped with shell. Info shots get replaced by ties, as described below.
Ties are also streamlined. Each bot gets one tie it can form (though unlimited ties can form to it from other bots). Each bot has total control over its tie. Its victims can't hijack the tie. Ties are used to suck nrg from an opponent. It can also read and set memory locations (replaces info shots. Sort of like ties can do now, but more versatile. You can read and write to multiple memory locations in a single cycle). Ties are stopped with slime. Also, if killing your opponent is your goal, shots are much more effective at reducing an opponents nrg levels. Though you don't get the change to play with your opponents internal memory.
The third attack type is phagocytosis (consuming your opponent whole). A bot can draw another bot into itself to be digested. Instead of just feeding on the target's nrg like ties, a bot can digest the victim's fat, muscle, etc. A potentially huge source of nrg. If the victim was alive, it has a very good opportunity to inflict some serious damage, since the inside of a bot isn't protected with shell or slime. Bots can also try to eat just a small portion of a corpse (you can't divide a living cell of course. Probably just swallow the whole thing if it's alive). If a bot doesn't like something its eaten, it can empty things from its stomach (regurgitate).
Bots can also consume bits of shapes to build nests and hideouts. A bot would swallow some portion of a shape in front of it, carry it outside the nest, regurgitate it, and then continue the process.
Poison isn't really a defense against being eaten, but it can make the bot that ate you rather sick. Instead of how it works now, poison would work more like present venom. You can make a memory location store any value you want. Bots can also have multiple types of poison in them at once, waiting to be eaten. The poison is realeased as the predator begins digesting the poisonous victim. The effect on the predator is related to how much poison is in its system. Very large bots can handle more poison than very small bots. Poison's effect is to weight a memory location towards a set value after the DNA has run.
Bots can metabolize poison into waste, but it takes nrg to do and takes up some muscle that could have otherwise been spent attacking, growing, etc.
[you]Muscle[/you]
The amount of muscle a bot has determines how much nrg it takes to do a given task. In addition, if a bot tries to do too much in a cycle, it has to push its muscles beyond their optimal level and pays more nrg for it.
Basically, the less a bot does in a cycle, the more efficiently it does it. And the more muscle it has, the more efficiently it does it. But muscle has an upkeep cost so you can't afford to do a large task too slowly.
[you]Viruses[/you]
Instead of drifting shots, I'm imagining sticky particles. When a bot produces a virus, it sticks to the surface of the bot. When another bot collides with the infected bot and touches the virus particle, it gets infected. Bots can also get infected by having its tie touch a virus particle, or eating an infected bot. But basically, some form of physical contact is needed to spead a virus.
Viruses would also be cheaper to produce, and multiple viruses could be being built at the same time.
[you]Still needs work[/you]
I'm still working on drawbacks for shell and slime. At the moment, I'm playing with the idea of having shell inhibit growth or shrinkage. A bot would have to molt the shell off if it wanted to grow or shrink. Having shell just be really massive as it is now also works well.
Slime washing away every cycle doesn't work as well. I'm open for suggestions. The ideal drawback would influence a bot in a way that isn't always negative, and impacts the bot in ways outside of just nrg consumption.
Also, I'm not sure about a primary defense against viruses. We could just use slime like it does now, but I'm not sure I like the idea of loading more onto slime than what it has right now. We could invent a whole new substance just to counter viruses, but I'm not sure I like that idea either.
[you]Conclusion[/you]
This is still raw. It hasn't been playtested, so there could be some hugely unbalanced elements. Please comment on anything you feel is missing or could be done better.
-
Having poison cause memory locations to be weighted towards a number sounds like a good idea to me, since if done well, it might prevent instakills from setting strpoison, strvenom, etc, to high values. I would also suggest that venom be handled the same way. Right now there are three ways to instakill with strpoison/strvenom: ties, info shots, and venom. The only reason venom isn't used for it now is because it would cost more than info shots for no greater effect (since the target will generally die in the same cycle that the shot hits in, when hit by an info shot).
It would be nice to allow bot authors (and evolution) to give bots resistance to a particular kind of poison/toxin somehow, like how some animals in nature have evolved immunity to various poisons that are in their environment, or that they produce. I'm not sure of the best way to do this. If you can read the memory address that poison or venom is affecting, and can order metabolizing of substances that affect a particular memory address, you would be able to easily code immunity to all poison and venom, which would not be a good thing. So perhaps have just the ability to target metabolizing on particular addresses, and the ability to see if you are poisoned/venomed, without being able to see what the poison/venom is actually affecting. Or, perhaps poison/venom should have an ID which is a hash of the memory address, and the metabolizing function should still take the actual memory address - you wouldn't be able to reverse the hash, but you could use a hash command (or poison yourself and look at the hash on the poison and the poison-making DNA) to determine the hash for particular memory addresses, and code recognition and metabolizing of particular poisons/toxins. Something like this could code for detecting and metabolizing an eye5 poison (I pulled the hash number out of thin air, it's not a real hash):
cond
phash = 31878
start
.eye5 .metabolize store
end
There should probably be some method to prevent instakill tie attacks too - the best one in my opinion would probably be to simply forbid the expenditure of more than a certain amount of energy per cycle on strvenom, strpoison, etc. Preferably, cap it somewhere near the amount of energy that you can drain through a tie.
Also, should something be done about being able to remove another bot's poison/shell/venom/slime via venom and/or tie attacks? (By setting strpoison etc to -10000)
I like the idea of having fat and muscle and such.
I think it would be better to have a separate antiviral substance inside the cell, which has a chance of killing a virus when it tries to infect the cell, rather than having slime stop viruses.
Requiring touching to spread a virus is also a bit of a pain, but not that bad - Right now we almost already have to do that to have controlled infecting. I have some test bots which infect veggies with viruses, and to accomplish this fairly reliably, I have them stop just within vision range of a target, and then accelerate towards them at high speed just before firing the virus - the result being that the virus hits the target fairly often since its velocity has the firing bot's velocity added to it when the virus is created (overpowering the random component of the virus' velocity due to the bot's high velocity at the time of firing).
I would also suggest that bots should be able to stay slimey until something destroys the slime - say, allow bots to fire acid shots which dissolve shell, and something like soap to dissolve slime.
-
Poison
I think it would be interesting if poison was altered as follows:
- Any memloc / memval pair is a specific type of poison. A bot might have more than one kind.
- Poison decays only when the host bot tries to use the affected memory location or when it tries to destroy that particular poison. The rate of decay for either would be dependent on muscle
- Poison does not care who created it - any bot containing a particular poison is affected by it.
- Poison may proliferate into a bot's slime at the bot's discretion. More on this later
This means a bot can't make use of a poison that would destroy itself - it needs to be immune to the poison in order to deal with it's use. Also, while a poisonous species would be bad to eat, a predator may evolve a gene to unmake that particular poison.
Vision
If you are going to do apparent size instead of distance, it would be fitting to do apparent relative velocity as well.
Energy and Muscle
I'm in favor of entirely dropping direct energy cost for actions, instead making muscle upkeep a function of how much the bot exerts itself. So with more muscle a bot would have a higher base upkeep cost, but actions would be more effective and upkeep wouldn't scale up as quickly.
Shell
The effectiveness of shell should be based on the thickness, which would get scaled down as a bot's surface area increases. Also, I was of the understanding that -6 shots were sopposed to be considered to be phagocytosis. Since they are being replaced, shell should work in a different way. Maybe something like this:
- Shell has a thickness and an opening
- In order to consume another bot, the opening must be sufficiently large
- When a bot has been consumed by another bot, the shell acts as a buffer, slowing down the rate at which it can be eaten. The shell would be less effective with a larger opening.
- Shell has a fairly large amount of volume, so more shell makes a bot harder to swallow.
Slime
I imagine slime as a container on the surface of the bot. Slime can contain both poison and viruses. Viruses may pass between the bot and its slime, and poison would also pass between them. Instead of decaying on its own, the bot may shed the slime (along with whatever is in it). Colliding bots may end up exchanging slime and the slime's contents. This idea isn't completely thought out, but here are some ideas:
- The more slime you have, the harder it is for something inside of the slime to get inside of the bot
- The more often you wash off your slime, the better defense you have
- Bots that don't wash off their slime may become pretty gross from the stuff in the slime
- The less slime a bot has, the harder it is to get rid of the slime
- When a bot is swallowed whole, the contents of the bot's slime are consumed rather quickly.
- When slime is shed, it acts as a particle and decays over time. As it decays, the contents of the loose slime vanish.
Viruses
Instead of treating them like real genes inside of a bot, treat them as something the bot contains. So when a bot makes a virus, it starts out inside of the bot and it can be transferred when the bot is consumed or by moving out of the bot into the bot's slime.
I had other thoughts about this, but ive since forgotten them, and I have an exam tomorrow.
-
It would be nice to allow bot authors (and evolution) to give bots resistance to a particular kind of poison/toxin somehow, like how some animals in nature have evolved immunity to various poisons that are in their environment, or that they produce. I'm not sure of the best way to do this.
Hmm... real poisons and venoms are usually neutralized by an animal's antibodies. Animals (and even people that are envenomated alot) that are immune to poisons or venoms generally are immune because they have alot of those particular antibodies in their blood. Their bodies can react quickly to the venom before the venom can begin its work.
So maybe bots produce antibodies for specific memloc locations and store them to give themselves immunity from a specific type of venom or poison. Instead of working like shell or slime, these antibodies would slowly neutralize the venom/poison over several cycles. The antibodies would need to meet up with the venom particles, so you'd have a gradual decay. Of course, up the number of antibodies and it'll decay quicker.
That way, even a bot that is "immune" to a specific type of venom or poison would still be effected by high doses. The increased levels of antibodies would just weaken the overall effect of the poison or venom over several cycles. If poison and venom also took a while to "circulate" through the bot, you'd get a nice bell shaped curve for the effect. The more antibodies you have, the shallower the bell curve.
There should probably be some method to prevent instakill tie attacks too - the best one in my opinion would probably be to simply forbid the expenditure of more than a certain amount of energy per cycle on strvenom, strpoison, etc. Preferably, cap it somewhere near the amount of energy that you can drain through a tie.
I was thinking of drastically limiting the amount of substances you can make/unmake in a cycle. Maybe down to just 1. The way it works now, you can just build 1000 units of venom to use as soon as a battle starts. I think if you're a venom bot, you should have to carry around a store of venom with you. And you shouldn't be able to use up all your fat reserves during a battle that lasts just a few cycles.
If it took a great deal of time to store up fats and muscles, bots would have to decide on a strategy early on and stick with it. You can't exist as a huge shot bot and then suddenly become some miniscule tie feeder.
I think it would be better to have a separate antiviral substance inside the cell, which has a chance of killing a virus when it tries to infect the cell, rather than having slime stop viruses.
Maybe combine with the antibodies above somehow. Not quite sure how it should work.
Requiring touching to spread a virus is also a bit of a pain, but not that bad
At the moment its possible to feed without touching a bot using shots. In fact it's pretty much the standard method. But in the new system you either need to consume another bot or tie to it to extract energy (or I suppose you could use venom to force the other bot to send you nrg shots), so there's going to be alot more touching just to survive.
I would also suggest that bots should be able to stay slimey until something destroys the slime - say, allow bots to fire acid shots which dissolve shell, and something like soap to dissolve slime.
Hmm, that's an idea. But I'm not sure how it would work. Ideally they wouldn't use something like shots, just because it's nicer if there's alot of variety in how bots interact with each other. Or maybe their method of delivery reflects what shell and slime protect against. "Acid" could be delivered through a shot. "Soap" would be delivered by injection like a tie (get close to your target and inject something into its slime coating to dissolve it).
Poison
I think it would be interesting if poison was altered as follows:
- Any memloc / memval pair is a specific type of poison. A bot might have more than one kind.
- Poison does not care who created it - any bot containing a particular poison is affected by it.
I see where you're comming from, but I think envisioning a "venom sac" in the bot makes the most sense. You don't necessarily want bots of the same species, for instance, immune to each others venom or poison.
If you are going to do apparent size instead of distance, it would be fitting to do apparent relative velocity as well.
Hmm, yes. How would you set up something like a simple following gene though? It wouldn't tell you if an object was moving away or towards you, so following it would be difficult. Maybe give the relative speed comming towards or away from you, and the change in angular position to you. But then you'd end up with the orbitting problem early bots had before relative velocity sysvars were introduced, since a bot would probably just turn to match the target's angle instead of using .dx or .sx.
The effectiveness of shell should be based on the thickness, which would get scaled down as a bot's surface area increases.
Yes, I was thinking this too. Ideally the shell would have sections, and a bot could fire on a single section to wear it down instead of trying to break through all the shell at once. If you can keep fighting against a single section of shell, you can effectively take it out. When a bot builds new shell, it would fill in this combat damage first before increasing the shell thickness elsewhere.
Or even have the bot build shell only on specific areas. Only plate its backside maybe. But I'm not sure how a bot would determine where to place the shell, or how to set up the sections.
Also, I was of the understanding that -6 shots were sopposed to be considered to be phagocytosis. Since they are being replaced, shell should work in a different way.
Shell and poison are switching roles in this case. Before poison protected against -1 shots and shell from the -6 shots. Now its poison that protects against being eaten and shell that protects against combat damage.
- In order to consume another bot, the opening must be sufficiently large
I am playing with the idea of shell locking the volume of a bot. A bot that tried to increase its size (say, by eating another bot) beyond the limit imposed by the shell wouldn't be able to do it. But part of me feels that it would make shell have too much of a downside and bots would be better off without it, defeating its purpose except for a very limited niche role.
- When a bot is swallowed whole, the contents of the bot's slime are consumed rather quickly.
I do like the idea of placing poison in the slime. A bot that eats you when you're still alive might get a bad enough taste in its mouth that it spits you out before you're totally dead. Plus it buys you a little time as the bot digests the slime layer before it gets to you. A sort of synergy between poison and slime.
But I also want to be careful and try to keep things relatively balanced. Maybe there are some other synergetic combinations that could be worked out.
Instead of treating them like real genes inside of a bot, treat them as something the bot contains. So when a bot makes a virus, it starts out inside of the bot and it can be transferred when the bot is consumed or by moving out of the bot into the bot's slime.
It's a hard time balancing how viruses work. In nature, viruses really have two forms. The first is for travel between cells, when the virus dons a protein coating. Inside a cell the virus is rather naked and unremarkable from other DNA or RNA.
The most obvious solution would be to give any bit of DNA that wants it a protein coating and kick it out of the cell. But for that to work, you'd need to allow DNA inside a cell to replicate itself first, and then reinsert that copy into the genome, which I'm not sure I want to allow (4 billion base pairs of a repeating virus. Yuck, it would crash the system.).
-
I am playing with the idea of shell locking the volume of a bot. A bot that tried to increase its size (say, by eating another bot) beyond the limit imposed by the shell wouldn't be able to do it. But part of me feels that it would make shell have too much of a downside and bots would be better off without it, defeating its purpose except for a very limited niche role.
Or maybe part of the shell breaks off if the bot grows too large for it.
Hmm, yes. How would you set up something like a simple following gene though? It wouldn't tell you if an object was moving away or towards you, so following it would be difficult. Maybe give the relative speed comming towards or away from you, and the change in angular position to you. But then you'd end up with the orbitting problem early bots had before relative velocity sysvars were introduced, since a bot would probably just turn to match the target's angle instead of using .dx or .sx.
The bot you're looking at has a real size and an apparent size. The apparent size is a function of distance. The apparent veldx could be based distance the same way the apparent size is. Preventing an orbit could be simply done with *.refveldx .dx store as it is now. Or even without refvel vars at all, there is Jez's method of *.dx .sx store.
This would make it possible to keep the refvel vars working in a similar fashion and usable in almost the same way, while at the same time returning less real information. If *.refvelup was "apparent", the bot wouldn't know exactly how fast another bot was approaching or moving away, but it would know enough in order to try to out accelerate it, because it would be able to tell if it is catching up or falling behind.
-
I see where you're comming from, but I think envisioning a "venom sac" in the bot makes the most sense. You don't necessarily want bots of the same species, for instance, immune to each others venom or poison.
Under the system I suggested, the "sac" would be a separate bot set up in a way so that it isn't succeptible to the poison. For example, a poison that stores some sort of strange action, like spinning around, would be entirely ineffectual in a bot that has no muscle. A poison that constantly produces fat could be contained in a bot with a small shell (if shell restricts growth). This way specialized parts become necessary to handle the deadliest toxins.
-
If you are going to do apparent size instead of distance, it would be fitting to do apparent relative velocity as well.
Hmm, yes. How would you set up something like a simple following gene though? It wouldn't tell you if an object was moving away or towards you, so following it would be difficult. Maybe give the relative speed comming towards or away from you, and the change in angular position to you. But then you'd end up with the orbitting problem early bots had before relative velocity sysvars were introduced, since a bot would probably just turn to match the target's angle instead of using .dx or .sx.
What a cool idea! The bots are way to accurate atm (IMO). Even top end predators (I.e. cheetahs) have bad hunting results (something like 1 in 10 attempts are succesful or was that lions?) Nothing nature has produced does internal trig (AFAIK) when trying to catch something that is moving. It all comes from practice. Bring back the old days when the bots were a bit more hit and miss!
I am playing with the idea of shell locking the volume of a bot. A bot that tried to increase its size (say, by eating another bot) beyond the limit imposed by the shell wouldn't be able to do it. But part of me feels that it would make shell have too much of a downside and bots would be better off without it, defeating its purpose except for a very limited niche role.
You know that bit earlier when you were talking about the ability to place shell on specific parts of the bots body? Well this seem to tie in nicely, I'm thinking limpets and crabs here; one produces a shell that grows larger as it does, while the other sheds its shell and then has to wait for a new one to form.
Thinking about that though the crab might be hard to do without allowing growing space inside the shell, not sure how it really works.
-
What a cool idea! The bots are way to accurate atm (IMO). Even top end predators (I.e. cheetahs) have bad hunting results (something like 1 in 10 attempts are succesful or was that lions?) Nothing nature has produced does internal trig (AFAIK) when trying to catch something that is moving. It all comes from practice. Bring back the old days when the bots were a bit more hit and miss!
(Small) cats are capable of determining the location of a small critter underneath a layer of snow from sound, and pouncing and grabbing it *through the snow* on the first try. Cats are, in fact, rather remarkable predators.
Lions and such can't necessarily catch their prey because they have evolved concurrently, and the prey runs quite fast, and the hunter will eventually tire as well. They generally go after weaker pack members, since they're easier to catch. Ancient humans (or a human with remarkable physical fitness today) could catch them, however, simply because such humans have ridiculous (running or walking) endurance, and can follow the animal until it gets tired and can't run any more.
As for skills, aside from humans and some (or all?) great apes, and perhaps a few other species, much animal behavior and skills are actually innate.
Chickens, for instance, will scratch at the ground to look for food regardless of whether they have a parent who demonstrates it to them or not. And different species of fowl, for instance, eat different things, regardless of the fact that nobody teaches them what to eat (guinea fowl, for example, eat ticks and other small bugs, but do not scratch at the ground, and are supposedly quite good in a garden for taking care of insect pests without killing your plants - unlike chickens, who will trample everything, eat some of the plants, and even dig up recently planted seeds while scratching at the ground).
Chickens and guineas also seem to be quite incapable of comprehending the consequences of perching on or near their food or water supply, as they will poop into it without even noticing, and seeing the results later doesn't dissuade them from perching there again later (You actually have to set it up such that it's impossible to perch over it, or that they can't poop on it if they do). If I had to guess, this would probably be because in a jungle (or any part of the wilderness, really), where their ancestors evolved, pooping into a river, lake, or swamp probably wouldn't do much to it, and you're not likely to have a fixed food source underneath the tree you're perching in, what with having to forage for all your food.
-
(Small wildcats)
It takes the least amount of stimulation to induce a cat to stalk and the most to get it to eat. From an evolutionary perspective this makes sense. Because hunts typically end in failure approximately two thirds of the time, an animal which waits until hungry to hunt would lose on two counts. First, it might not catch anything immediately. Second, the cat's energy-depleted state would decrease its hunting efficiency and make it even easier for prey to escape.
(The Fundamentals of Feline Behavior, Part 1)
http://www.mmilani.com/feline-behavior-fundamentals.html (http://www.mmilani.com/feline-behavior-fundamentals.html)
Cheetahs, I was wrong to mention them, are described as –
one of the most accomplished of hunters within the wild cat species - it catches up to 60%-70% of prey that it hunts. The lion on the other hand has a relatively low success rate (less than 30%) and combats this by hunting collectively
(Wild cat behaviour)
http://www.abf90.dial.pipex.com/bco/behav01.htm (http://www.abf90.dial.pipex.com/bco/behav01.htm)
I still think that learning plays a great part in hunting even with cats, one cat I knew, raised by people who let it draw blood without complaint, would go for your wrist (even someone’s throat once) when you tempted it with a piece of string. Its favourite game was to attack the postman’s legs in the morning...
Kittens are born with the innate sense to hunt I guess, that’s what the whole ‘play’ attitude of younger (higher IQ) animals is for, to train the instinct to a talent surely.
Are you thinking of the Arctic Fox and Lemmings when you mention the ability to detect prey through snow? I didn’t find any information on how effective they were.
When you mention prey/predator relationships V evolution I have to admit that would play an important part in all relationships.
One of the things your post has made me think about is the relationship between our bots and the ability of prey to avoid its predator, the innocent side step when you play tag for instance, something our bots don’t really have the ability to do anymore.
We are perhaps in a very difficult position because both species have, potentially, the same abilities. Plus bots have shots, extending their killing range beyond their position. It leaves less space for manoeuvrability; for prey to escape.
On a parting note, I think that birds in general don’t have the same ability to control their faecal ejection as some other species. I could be wrong, I certainly couldn’t find confirmation of the fact, it’s just something I seem to remember from an essay I did on different digestive tracts once.
-
Hmmm. I don't remember where (or when) I read about (what I'm remembering as) cats hunting things moving in the snow, and considering wikipedia's article on cats currently says that cats are not able to tolerate being both wet and cold very well (if it's accurate), perhaps it was about some other species instead. I thought it was cats since I seem to recall it (it being whatever it was that I read) saying that they were able to detect their position under the snow due to their swiveling ears.
-
The bot you're looking at has a real size and an apparent size. The apparent size is a function of distance. The apparent veldx could be based distance the same way the apparent size is. Preventing an orbit could be simply done with *.refveldx .dx store as it is now. Or even without refvel vars at all, there is Jez's method of *.dx .sx store.
I'm working through the math, and well, things would be very different from how they are now. Angular diameter can be approximated as real dimater / distance. It's an inverse function with respect to distance. If you were to plug in speed instead of diameter, you'd get a function that gets bigger as you get closer. That is, things seem to move faster when they're closer to you.
But when you're close to another bot, you'd want to use finer controls. So one obvious solution is to use the inverse of apparent speed times some base speed value. Something like 100 *.refvel div .up store. Which basically gives you a linear function based on distance. The further away from an object you were, the faster you'd try to go.
As the object got closer, it would seem to be going faster towards you. So a typical persuit would probably involve a huge speed up followed by a slow and gradual slow down. And then there are issues of decimal values being returned for apparent velocity, and their rounding issues.
However, if the object were to increase its speed away from you, this inverse term would become lower, and the persuing bot would slow down as if it were approaching. But of course it wouldn't be hard to check the apparent size of an object and make some sort of decision based on more information. If a bot were to take this refvel and divide it by apparent size, it would get a function basically equal to speed / diameter. Assuming the diameter won't be changing on the other bot very often, this gives the speed of the other bot divided by a constant.
In general, it just has a whole slew of implications and I'm still trying to sort through them all. It might just, in the end, be about the same as giving a bot distance and relative speeds. I'm not for obfuscating terms that a bot can easily calculate.
And in the end, unless you're imagining bots as floating space whales, it's hard to conceive of a situation where you'd be confused if another animal were really small or just far away. Even animals without bifocal vision still have some basic lens structures set up that can give a good guess at distance (things are blurry if they're far away and you're looking at something close up).
Under the system I suggested, the "sac" would be a separate bot set up in a way so that it isn't succeptible to the poison. For example, a poison that stores some sort of strange action, like spinning around, would be entirely ineffectual in a bot that has no muscle. A poison that constantly produces fat could be contained in a bot with a small shell (if shell restricts growth). This way specialized parts become necessary to handle the deadliest toxins.
I dunno, on the one hand it's nice to move towards a more specialized system, where several bots would have to work together to be the most effective. But on the other hand, I think the program should work as a simulation of whole creatures. You should be able to pretend a bot species is a lion and another a tree just as easily as imagining one is an ameoba and another a volvox.
I think I'd like to keep specialization seperate from the ability to effectively use a feature. Have a colony of bots work better because of economies of scale instead of whole new features. Well... There are physical connections between bots to form structures. Maybe invent some other new features that are possible when you have a large number of bots working together, beyond just structural ones.
I am playing with the idea of shell locking the volume of a bot. A bot that tried to increase its size (say, by eating another bot) beyond the limit imposed by the shell wouldn't be able to do it. But part of me feels that it would make shell have too much of a downside and bots would be better off without it, defeating its purpose except for a very limited niche role.
You know that bit earlier when you were talking about the ability to place shell on specific parts of the bots body? Well this seem to tie in nicely, I'm thinking limpets and crabs here; one produces a shell that grows larger as it does, while the other sheds its shell and then has to wait for a new one to form.
Thinking about that though the crab might be hard to do without allowing growing space inside the shell, not sure how it really works.
I'll research and try to find out why some animals need to molt and others don't. Hopefully I'll come up with a reasonable solution that allows minimal shell protection without restriction, and more endurable shell protection that requires molting to grow further.
It wouldn't be hard to give a bot the ability to puff up its size artificially. Insects do it all the time when they molt their shells and make new ones. That way the new shell is larger, and the insect still has time to grow into it. It could also be used as defense. Make another bot think you're larger than you really are. Of course, other than looking impressive size is something you want to avoid. Just makes you a target for the bigger predators. If you don't have the muscle to back up your size, you're just a sitting duck.
-
I'd rather not have aiming (at where the target will theoretically be in the future) be even more difficult than it is now.
-
In general, it just has a whole slew of implications and I'm still trying to sort through them all. It might just, in the end, be about the same as giving a bot distance and relative speeds. I'm not for obfuscating terms that a bot can easily calculate.
And in the end, unless you're imagining bots as floating space whales, it's hard to conceive of a situation where you'd be confused if another animal were really small or just far away. Even animals without bifocal vision still have some basic lens structures set up that can give a good guess at distance (things are blurry if they're far away and you're looking at something close up).
No matter what information you give about size, position, and velocity, it will be possible to at least guess at reality based on that information (if it isnt, the bots are screwed). The only thing that changes is how much time and effort it takes a bot to get the real values. Things may be better off if the bot just had real size, speed, and position from the start. I just care about consistency.
I think I'd like to keep specialization seperate from the ability to effectively use a feature. Have a colony of bots work better because of economies of scale instead of whole new features. Well... There are physical connections between bots to form structures. Maybe invent some other new features that are possible when you have a large number of bots working together, beyond just structural ones.
If you had a siamese twin, you would be at a disadvantage. Why? Because neither of you is delivering something the other can't do on their own, and yet you restrict each other's movement. Right now, bots have only the smallest of differences in form and function, the only real difference being behavior. Because of this, I don't think it's good to be essentially giving a bot an extra 'organ' for something that is more an of amenity than a necessity.
-
I would like to see multi-bots with, say, a tail with a heavily shelled end cell (or cells), with it being capable of coordinating swinging the tail to strike an enemy with the shelled end, to damage or destroy them with the force of the impact.
-
I would like to see multi-bots with, say, a tail with a heavily shelled end cell (or cells), with it being capable of coordinating swinging the tail to strike an enemy with the shelled end, to damage or destroy them with the force of the impact.
That would mean single cell bots would also have the ability to damage other single cell bots through collision as well though wouldn't it?
Don't get me wrong, it's an interesting idea; perhaps limit it to shell on shell impacts or give bots a deformity limit rather than the overlap they have now, physics states that energy is motion X mass? so the faster moving of two equal bodies causes more damage.
Nums;
The thought of comparing limpets to crabs was that limpets have an open space to expand into, crabs are enclosed so they have to shed their shell to expand.
/.\ becomes /.\
................. /oo\
I realise that it would mean bot shapes become deformable though and that shell would become plates placed in regions over the bots body.
-
I'd rather not have aiming (at where the target will theoretically be in the future) be even more difficult than it is now.
Do you think the ability to do that should be cost free?
(abyaly) ->
[!--quoteo(post=0:date=' post=:name=)--][div class=\'quotetop\']QUOTE ( @ ' post=)[div class=\'quotemain\'][!--quotec--]it will be possible to at least guess at reality based on that information[/quote]
I would much rather that bots guessed at things for the main unless they spent a fair bit of energy working stuff out, it should all come down to a 'paper scissors stone' balance. This is an evolution game, even in the leagues, there shouldn't be one way to be the best...
-
Ties are also streamlined. Each bot gets one tie it can form (though unlimited ties can form to it from other bots).
This would make a multibot with more structure than a worm impossible, which is far from desirable. Maybe allow a bot to make more ties after the previous one hardens, with maybe a small upkeep for hardened ties?
-
Ties are also streamlined. Each bot gets one tie it can form (though unlimited ties can form to it from other bots).
This would make a multibot with more structure than a worm impossible, which is far from desirable. Maybe allow a bot to make more ties after the previous one hardens, with maybe a small upkeep for hardened ties?
I'm working on replacing ties-as-connective-devices with joints-- that is, simple weldings between bots. The problem is that using ties to form structures puts alot of stress on the physics engine's design.
-
I'd rather not have aiming (at where the target will theoretically be in the future) be even more difficult than it is now.
Do you think the ability to do that should be cost free?
Actually, I think the F1 (and other competitions) ruleset should be changed to have (small) costs for math operators. The cost amount could be balanced to remove the energy advantage that SG bots have over bots which actually use conventional conditions, without making the cost so high as to make SG bots unfeasible.
I rather expect this would cripple Guardian, too, since it uses a ridiculous amount of math, and quite a bit of repetition of identical DNA, to avoid doing any unnecessary* stores.
*unnecessary meaning temporary variables. At the moment using temporary variables costs energy and saves CPU time. I went the opposite direction with the version of Guardian that's in the league - energy efficiency at the cost of CPU efficiency.
Although Guardian is capable of predicting positions in the future (with semi-decent reliability), if it is tied to anything, accuracy goes right out the window thanks to the tie physics. I'm not suggesting that 'get predicted position of bot after N cycles' should be a command, though. That'd take all the challenge out of trying to give a bot better shooting accuracy.
Also, I have been working on a more CPU-efficient version of Guardian (much shorter DNA length, due to replacing a lot of the duplicated DNA with stores to temporary variables), but haven't entered it in the league yet because it turns out that neither version of Guardian can currently beat Rabidus reliably (and the faster version gets stomped by Rabidus more reliably than the version currently in the league does). Rabidus, Etch, and Guardian seem to have a rock-paper-scissors thing going.
I've also been trying to work on some multi-bots, but have been having a great deal of trouble with ties - fixlen and fixang aren't working reliably for me. They're either bugged, or I haven't figured out how to use them properly. What little documentation there is (about fixlen and fixang) is more or less useless for actually figuring out how to use them, so it's a little hard to tell whether I'm feeding them the correct input (e.g. angle relative to the eye? or to the bot's aim? or to 0?), and whether they're behaving the way they're supposed to be.
I'm trying to use fixlen to move a parent and child bot a short distance away from each other after the child is born*, but it doesn't do anything to them unless I drag them apart manually (at which point they snap to the specified (fixlen) distance).
* = I'm replacing the tie and waiting for it to harden first. That's all going fine, fixlen and/or the tie length just aren't doing anything to the bots' positions until something moves one of the bots. I'll probably try making them thrust apart a little next, to see if that engages the snapping-into-place.
The aforementioned bot forms a pair, with each having an eye which looks everywhere except at the other bot in the pair. I've been trying to set them up such that when one bot in the pair sees another bot, it will rotate their tie to spin the bots so that both bots can see it. So far I can't get it to rotate them towards the target, but if I try to move one of the bots manually, they snap back into the same angle they were at before. So, fixang is definitely doing *something* - just not what I would like it to do. I've moved the target around them and confirmed that they are seeing it, but they still snap back to the same (wrong) angle.
Attempting to transfer coordinates over ties seems to be rather a pain in the ass, too (easier to just rotate the tie to spin the bots - or it would be, if it was working).
I haven't finished exhaustively testing everything to make sure fixang really is the problem, though, which is why I haven't posted a bug report on it yet (plus I prefer to know why something is doing what it is before I post a report).
As for bots having multiple ties, multi-bot internal communication is hampered significantly by the fact that you can only write one value through one tie per cycle, and if you want to read a value through a tie, you can also only read one per cycle (except for tref* vars). One thing that might help would be having tin1-tin5 which read from out1-5 on one tied bot (same bot that tref*/tmem* etc would work on).
Getting back to multiple ties, Guardian, for example, uses multiple ties in two situations:
1. If you are tied to another bot, and it is a friendly (or tiepres is 0), you can still tie to an enemy or veggie to kill or feed on them.
2. If you are tied to another bot, and it is a veggie, you can still tie to an enemy to kill them.
Being restricted to one self-made tie at a time would be rather a pain, since you would have to deltie your existing tie in order to make another, and you can't deltie a birth tie (so you would have to replace it with a regular one first). (Can you even delete a tie to one bot while tying to a different bot in the same cycle? I've determined that you can't send values through a tie on the same cycle that you form it, although the version of Guardian in the league tries anyways)
-
Actually, I think the F1 (and other competitions) ruleset should be changed to have (small) costs for math operators. The cost amount could be balanced to remove the energy advantage that SG bots have over bots which actually use conventional conditions, without making the cost so high as to make SG bots unfeasible.
That's a good idea, if SG bots still have an advantage when the next update is released I'll look into adding those costs.
I've never figured out how to use ties properly myself so good luck!
-
Ah ha. It doesn't wrap input angles, it caps them instead.
If .mem(468) <> 32000 And .Ties(k).Port = tn Then 'fixes tie angle
If .mem(468) > 628 Then .mem(468) = -627
If .mem(468) < -628 Then .mem(468) = 627
.Ties(k).ang = .mem(468) / 200
.Ties(k).angreg = True 'EricL 4/24/2006
End If
(So I have to wrap them myself to make sure they're within -627 to 627)
-
Are you using aimdx/sx anywhere?(I did attempt to look myself, That thing's huge ) They'll rotate the whole mb rather than a single bot. Setaim will only rotate that bot. For stretching/turning MBs tielen/tieang1-3 work alot better, but aren't as selective as fixang/tieang. Since you should only have one main tie to worry about, that shouldn't matter too much.
I've determined that you can't send values through a tie on the same cycle that you form it, although the version of Guardian in the league tries anyways)
That was to give other bots a chance at deleting the tie before being attacked through it. Not really all that useful since most bots randomize their tie numbers, to prevent enemies from remembering them.
-
Are you using aimdx/sx anywhere?
Hmm, no. IIRC, I just set them to 0 (when they aren't already 0, which is probably never if they're cleared before each cycle) in case something is screwing with them with info shots, ties, or venom. I'll have to try them sometime.
-
Actually, I think the F1 (and other competitions) ruleset should be changed to have (small) costs for math operators. The cost amount could be balanced to remove the energy advantage that SG bots have over bots which actually use conventional conditions, without making the cost so high as to make SG bots unfeasible.
I think a dna length cost would effectively neutralize any advantage to an SG bot without crippling them (except guardian and bucket). Just make it so that the cost of having a cond block is the same as the cost of working around it wrt number of operations.
-
I've been working on a similar java version of DarwinBots (which is how I came to find out about it). Here's a few Ideas I thought would be worth contributing:
- Cell Wall - a bot had a health rating, which was represented by the integrity of its cell wall. attack shots would simply digest the cell wall.
- Hot spots - to represent a volcanic area, a map would have some hot spots. As hot spots generate ammonium, which helps amino acids to be produced, a bot would be able to build enzymes easily in hot spots, but the cell wall would disintegrate slowly.
- A bot that has no cell wall bursts and releases all its energy in the form of proteins eg energy shots.
- Toxins - although toxins wear off after time, they steadily inflict damage to the bot which happens to contain it. Each poison has an ID, and it can be used to create an antidote or expel it, no matter in which bot it's in.
- Shells can be dumped in place to build a communal shell/fortress.
- A bot without shell can destroy a bot with a weak cell wall, then use its shell as a home.
I hope these ideas are of some use.
-
I've been working on a similar java version of DarwinBots (which is how I came to find out about it).
Ooh, do tell. I'd like to see something like that.
Cell Wall - a bot had a health rating, which was represented by the integrity of its cell wall. attack shots would simply digest the cell wall.
I played around a little with this idea, but I'm not sure how far to take it. At present, I'm thinking that a bot's shell is directionally dependant like this, and when another bot tries to damage it they have to eat through just the shell in the vicinity that the shot hits in to tunnel through and damage the actual bot.
Hot spots - to represent a volcanic area, a map would have some hot spots. As hot spots generate ammonium, which helps amino acids to be produced, a bot would be able to build enzymes easily in hot spots, but the cell wall would disintegrate slowly.
Years ago I was playing with the idea of a black smoker. A volcanic hot spot that spewed out useful and poisonous chemicals. I might still play with it at some point, but it's not on my list for an initial release.
A bot that has no cell wall bursts and releases all its energy in the form of proteins eg energy shots.
At present I'm imagining making a bot turn in to an inert corpse when it dies, allowing the hunter to feed at its own pace. But I think Eric might be working (or thought about working) on something like this for the current version.
Toxins - although toxins wear off after time, they steadily inflict damage to the bot which happens to contain it. Each poison has an ID, and I can be used to create an antidote or expel it, no matter in which bot it's in.
Shells can be dumped in place to build a communal shell/fortress.
I'm playing around conceptually with the idea of extracellular substances. I'm not totally sure what the end result will look like, of course, but I think building a fortress will probably be possible.
A bot without shell can destroy a bot with a weak cell wall, then use its shell as a home.
I could see something like this. I'm working towards having it be possible for a bot to live inside another bot. Could just as easily allow a bot to live inside a corpse.
I hope these ideas are of some use.
Sure, I always appreciate brainstorming ideas.
-
I might still have a .jar lying round...
-
Aaargh!
The UI is confounding, I still haven't made the bots distinguishable from shots.
My knowledge in I/O is minimal, so at the moment all I can run is my equivalent of Animal Minimalis. Here's the code:
[div class=\'codetop\']CODE[div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']rule "move forward"
salience 30
when
$bacterium:Bacterium(0==0)
then
$bacterium.accelerate(1.0);
end
rule "feed"
salience 10
when
$bacterium:Bacterium(eye5>=50)
then
$bacterium.feed(50);
end
rule "reproduce"
salience 20
when
$bacterium:Bacterium(energy>=5000)
then
$bacterium.reproduce(50);
end
rule "turn left"
salience 0
when
$bacterium:Bacterium(eye3>eye5)
then
$bacterium.turnLeft(20.0);
end
rule "turn right"
salience -1
when
$bacterium:Bacterium(eye7>eye5)
then
$bacterium.turnRight(20.0);
end
you can see several similarities; the salience factor determines in which order the DNA is executed.