Bots and Simulations > DNA - General

Venom impact on .fixed

<< < (5/6) > >>

Numsgil:
I don't like artificial rule sets.  I like to keep things relatively simple and have the interactions between the simple parts define the world, so I agree with you guys.  That said, sometimes that's more difficult in practive than in theory.

Here's what I see we want:

1.  A way for bots to produce and react to different kinds of venom.  Different kinds of venom don't cancel each other out like they do right now.

2.  A voluntary conspec recognition system.  That is, bots can design or react to venom in such a way that they are immune to conspec's venom if that conspec agrees to doing so.

I've been thinking aout the combat system and how to change it for when I add phagocytosis.  Here's what I'm thinking at the moment:

Revamp the entire combat system into the following:

Attack - Defense
-1 nrg shots - Shell
Phagocytosis (eating another cell whole) - Poison (with poison not acting like it does now.  Instead, it would either drain energy from the digesting cell, or make the cell throw up, or something like that.  It's highly discussable).
Tie feeding - Slime

Venom and Info Shots - Anti-Venom (or you could call it something else.  Name isn't that important).  Also stopped by Shell perhaps.

(Viruses wouldn't be an attack that would work well against another species (at least, not without some modifications probably).  Viruses would be moved to be more for evolution simulations, where I think they belong.  This is another topic all together...)

Venom would be produced with two characterstics:

Conspec value and memeory location/value.

Conspec value is something I've been wanting to introduce for a while.  It's a value that a bot can set.  Venom that tries to attack a bot with the same conspec value won't harm that bot.  Ties that fire at a bot with the same conspec value won't be effected by that bot's slime.  .conspecID or something similar would be a super private sysvar that other bots can't either write to or read from.  Severeal existing sysvars would be moved to a similar private sysvar array for things generally accepted as private, such as delgene.  (That is, there are already private sysvars, I would just be formalizing the idea into a specific memory range).

Memory location/value would be where and what the venom does.

Venom that effects a bot is placed in a venom array that keeps track of what memory is being effected, controls the venom countdown, etc.

Venom produced by a bot would similarly be kept in an array that keeps track of what kinds of venom have been produced and are ready for use.

Anti-Venom works just like Venom except it stays in the bot and reduces the time effect of venom, being used up in the process.

I don't present the above as a finalized idea.  It's strictly a work in progress in my mind.  I present it now as an idea.  It does introduce alot of new crap that isn't strictly as clean as I'd like.  Feel free to take it and modify/mutilate it to create a better idea.

PurpleYouko:
Engine or not engine? That is the question.

Well first up you need to define what exactly you mean by the "engine".

If you mean the "physics engine" then what you say is entirely true. We need to develop DB such that this engine just maintains the environment and has little to do with what the bots do with it.

However there is a cross over in which the "engine" actually handles DNA actions. Something has to. The rules of the world's physics have to interact with the bot's DNA at some point. This is where we get the dilema. What exactly is the cutoff point where DNA handling engine stops and the physics engine takes over?

It would be great to get rid of all the arbitrary rules that plague DarwinBots but the problem is again.. What do you define as arbitrary? In real life, venom gets into the system of an organism and screws with it until either the organism dies or its metabolism manages to get rid of the venom. This, of course, takes time.

The present venom system is rather simple and was designed to replicate the effects of venom wearing off. It is rather imperfect and is one of the things that will benefit greatly from the new metabolism systems when they are implemented. It would be unrealistic to simply allow the DNA to remove venom as soon as it is detected. Even if we had a sysvar command such as .removevenom in which you can store energy to forcibly eject the venom, you still need some sort of "counter" that tracks the current level of venom in the robot's system. That counter has to be managed somehow.

Example: A robot has 4000 energy. It is hit by 16,000 points of venom (a really nasty dose). Some counter somewhere (possibly one of its memory locations) holds the venom value. It detects the venom and then saves some value into .removevenom to remove the venom. It can only spare 500 energy and this will remove 500 points of venom so it still has 15,500 left.

Now what? Does the venom remain until the bot can spare more energy to actively remove it? or do we just let it go away gradually? (like it does now) Either way it has to be tracked. We are just shifting the onus of tracking it from the main engine into the DNA engine.
Oh wait a minute. The two are actually the same thing as far as the program goes <_<

One improvement would be for the robots to have varying levels of resistance to certain venoms (ie. having memory locations forcibly changed for more than one cycle) This resistance could be learned and remembered but then we would have to track that too. A whole array equal in size to the actual memory array, would be need to track it.

Alternatively we use enzymes in the new metabolism system which are more or less efficient at removing venom. this allows for random mutations and selection based on venom immunity. That would be my vote.
Even so the enzymes would simply effect the efficiency of venom removal and th evenom still has to be track by some engine or other.

I just don't see any feasible way to totally remove venom from the physics engine, after all venom does have a physical effect on an organism.  :unsure:

Endy:
Like the idea of conspecID. Would remove alot of the unatural effects of bots being conspecs. Canni's should be affected by another's venom like any other bot.

Would also making MB's much easier. Slime wouldn't be the major drawback it is now.

Perhaps bots in confusion could also change it to receive some sort of assistance from family.

Poison isn't similarly neutralized between conspecs is it?

I have one of my main EvoBots using this to moderate cannibotism, and it always seems to work.

Numsgil:
I thought poison was conspec immune, but I may have broke that when I rewrote the shot routines a while back.  Or I could just be wrong (a first time for everything :P)

Endy:
At least in 3.6 EvoBot5.4StemA seems to work right. A cannibalistic conspec is poisoned, making it a non-conspec(in regards to the bots feeding). The unfortunate bot is quickly recognized and eaten.

If it wasn't working right the bots under mutations shouldn't be able to reach anywhere near the population levels they routinly manage.

Navigation

[0] Message Index

[#] Next page

[*] Previous page