Darwinbots Forum
Bots and Simulations => DNA - General => Topic started by: Elite on January 28, 2006, 10:40:42 AM
-
This thread is to discuss hivebot's hive coding (be that hive location, hibernating etc.)
The Hive is a location chosen by the Queen at the start of the sim as far away from the Pray communities as possible. It is a place that the species can come back to periodically to get orders from the Queen/Keepers.
When the species goes into hibernation it does so at the hive. Henk suggested a brilliant hibernation strategy:
All the hibernating bots tie together at the hive, then the 'wake up call' can be transmitted via chain reaction very quickly. Also, the hibernating bots could share nrg and include a few veggies in the 'hibernation web' to sustain the hibernating hivebots. Discuss the code for this here.
More importantly, we need some form of hive-selection code and basic hibernation code first.
Let the discussion begin :)
-
Wow this could easily get horribly complicated. Was there a specific pattern in mind or would the hibernating bots just congregate and tie together any old how? Who is it that gives the wake up call? Forgive me if I'm asking questions with answers elsewhere. :P
-
Ask all the questions you like :D
1) Is there a specific pattern in mind?
- No, the bots just 'latch on' to the mass of hibernating bots
2) Who gives the wake-up call?
- A special caste called the Keepers does not hibernate. At birth each wraith has the (5% I think) chance of becoming a Keeper. Keeper's are sterile and do not go into hibernation with the others. When the Keepers determine that there is enough prey to feed on again, it is they who wake the other wraith up. It is also the Keepers' job to send the species into hibernation when their prey's numbers become too low.
The Keepers wake the other bots up by shooting an info shot at one of the hibernating bots. Then the 'wake-up call' is transmitted through the hive via chain reaction through the ties.
While hibernating, the wraith share nrg with each other and there are a few veggies in the tied up mass as well to sustain the wraith through the hibernation period.
Any more questions? :D
-
From your description of the Keepers and the other Wraiths, it seems that the Keepers are the weak point in the chain... if anything malfunctions with them, or they are killed off, the whole system pretty much shuts down.
Also, chain reaction messages through networks is cool, but having tried this (somewhat naively) before, I ended up with the same info being passed between the same bots repeatedly. I think [Num] likened it to harmonic motion without a dampening force or similar.
My only idea to solve that was to have the bot send the info to other bots and then immediately sever its own ties and move away.
-
The Keepers are sterile, and therefore very strong. Rather than hibernating, they 'pick off' one or two Praybots when they need a snack.
When a new wraith is born, it 'decides' wether or not to become a Keeper (5-10% chance) so new ones are being created during reproduction.
Weak link in the chain? I don't think so - there will be fail-safes in place:
1) If the keepers haven't woken the hive up after so many cycles then they will wake up anyway
2) If any one of the hibernating wraith are attacked then all of them will wake up
3) If a Keeper is threatened then they will wake the hive
4) If the pray become too much of a threat then they will wake the hive
5) Once the hive have woken, they will produce new keepers when they reproduce anyway
6) I doubt Preybot is that much of a threat :D but we've always got to be open to new possibilities
As for the chain-reaction idea we'll probably try your idea (send message and then sever immediately), but we might have to play around with that one.
My idea was to use in/out signals to wake the hive
An alternative is that once one bot is woken they will try to wake others using info shots until they are all awake.
Thanks for your input Ulciscor :)
Do you have any ideas as to how to do the hibernation?
Personally I think ties are rather complicated and messy anyway. I would like to avoid using them with Preybot, but I just liked the hibernation tieing idea :)
I hope we can find a way to implement it.
-
I guess if we were to emulate nature and be really thorough, we could give the bots a pre-hibernative behaviour. Like squirrels gather food, maybe the bots could store up on shell and body before they hibernate. They could feed on this occasionally during hibernation and it would protect them from predators. When they woke up they could convert it back to energy to use to hunt.
I found ties a complete nightmare, but that's probably because I didn't have a clear plan about how to use them and what I wanted to do. It looks like that is being seen to properly this time.
-
No, ties really are a complete nightmare ;)
-
I kind of like them. :D
-
I kind of like them. :D
so ... you enjoy waking up screaming ...
takes all kinds. ;) lol
-
it is a great cardio vascular workout regime.
-
What about a tmemval, tmemloc combo? A keeper could transmit the wake-up call via them. Would have to first send the message to all ties, then delete them.
Keeper Sense if bot has wake up tmemval,
If not change it via tieloc/tieval
If so delete that tie
Something like that anyways. I don't think in/out could work since all the bots are sleeping. They'd be unlikly to see the message.
An alternative would be to use shots. A keeper could info shoot the message to all bots in the area that are sleeping. Who would in turn wake up all the bots they see.
-
Don't forget that an untied hive will live shorter, because it doesn't get the cost reduction given by ties.
-
you can make them share slime and shell for better protection
-
Here:
' I am hibernating ...
' NB - '.ties', '.hibernate' and '.wakeup' are custom variables
' How many ties do I have?
cond
*.numties *.ties >
*.hibernate 1 =
start
*.numties .ties store
stop
' If the number of ties is decreasing then delete all ties
cond
*.numties *.ties <
*.hibernate 1 =
start
*.tiepres .deltie store
stop
' Once I have no ties come out of hibernation
cond
*.numties 0 =
*.hibernate 1 =
start
0 .hibernate store
stop
' Wake if attacked
cond
*.pain 100 >
start
*.tiepres .deltie store
stop
' Time to get up
cond
*.wakeup 1 =
start
*.tiepres .deltie store
stop
SGified:
cond
start
*.numties .ties *.hibernate mult *.numties *.ties sub sgn mult store
*.tiepres .deltie *.hibernate mult *.ties *.numties sub sgn mult store
0 .hibernate *.hibernate mult *.numties 1 sub sgn mult store
*.tiepres .deltie *.hibernate mult *.pain 99 sub sgn mult store
*.tiepres .deltie *.hibernate mult *.wakeup mult store
stop
:)
How's this?
-
cond
*.numties *.ties >
*.hibernate 1 =
start
*.numties *.ties store
stop
' If the number of ties is decreasing then delete all ties
cond
*.numties *.ties <
*.hibernate 1 =
start
*.tiepres .deltie store
stop
This won't work. At least not in 2.36 or earlier.
You CANNOT perform calculations of any type in the condition step of the gene.
Num may have incorporated this ability into 2.4. Not sure though.
-
What are you talking about :blink:
I'm not calculating in the condition - *.ties is a custom variable.
I store *.numties into .ties if the number of ties > *.ties
And break all ties if *.numties < *.ties
Meaning that as soon as the number of ties decreases the bot severs all ties
PS: Made an error in the code - it should be:
*.numties .ties store
not
*.numties *.ties store
-
Ahh very clever. Much simpler than what I was thinking, needing to send info and then delete ties; instead using the tie deletion as the wakeup signal. Awesome! :D
Apart from mundane problems this seems like a cool idea. (Mundane being bots dying, decreasing the tie count and waking up all the hibernated wraiths, for example)
-
Bots dying:
A problem but not too unmanageable (if that's even a word). If a bot dies then there should be a good reason for it, and the hive should be woken to check if everything's OK. Bots die of natural causes anyway (pwaste) so there might be a few 'false alarms'. Might have them get the opinion of a Keeper before going on a feeding frenzy.
If the hive is being attacked and bots are dying then the hive should be woken up anyway :D
You make a great devil's advocate Ulciscor :evil:
Good for making sure that everything's completely foolproof B)
-
cond
*.numties *.ties >
*.hibernate 1 =
start
*.numties *.ties store
stop
' If the number of ties is decreasing then delete all ties
cond
*.numties *.ties <
*.hibernate 1 =
start
*.tiepres .deltie store
stop
This won't work. At least not in 2.36 or earlier.
You CANNOT perform calculations of any type in the condition step of the gene.
Num may have incorporated this ability into 2.4. Not sure though.
Yes, that's exactly what I did.
-
Physics in 2.4 seem entirely different too - my bots just seem to slide everywhere and tie to random things for some reason :wacko:
Maybe it's just me :D
Sizes have changed - you can get nearly invisibly tiny bots
Anyone have any comments on *.numties method
-
Yep, physics in 2.4 is entirely different. Pre 2.4 physics is a mess to maintain and edit.
And the physics in the version I'm working on now will be a little different too :D
-
I'm not calculating in the condition - *.ties is a custom variable.
You are absolutely right. I think my brain is fried :wacko:
too much working does that to you. <_<
-
Anyone have any suggestions on how to get the bots to hibernate - I was (and still am) thinking that the Keepers should use out/in
-
I think info shots would work best. Have the keepers shoot values into a certain 'wake up' location.
-
I mean for making the bots hibernate in the first place - not waking them up
But for that we can either use:
- Ties via *.numties
- Info shots (wake up bots who wake up more bots etc.)
Undecided :unsure:
-
The most obvious solution is to add a *.hibernate 0 = condition to every gene.
Not very elegant though.
-
Probably should have clarified some more: to make the bots go into hibernation/making them go to sleep/tell them when to hibernate
:D
Problem with that solution is that the bots will expend nrg while hibernating. If I wanted to make lots of work for myself I could turn whatever emerges into a SG bot :P
- It will be made less of a problem by the reduced costs however - just get them to stock up on nrg before they hibernate