Code center > Darwinbots3

Combat System and other things

<< < (4/6) > >>

Jez:

--- Quote from: Trafalgar ---I'd rather not have aiming (at where the target will theoretically be in the future) be even more difficult than it is now.
--- End quote ---
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...

vbraun:

--- Quote from: Numsgil ---Ties are also streamlined.  Each bot gets one tie it can form (though unlimited ties can form to it from other bots).
--- End quote ---

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?

Numsgil:

--- Quote from: vbraun ---
--- Quote from: Numsgil ---Ties are also streamlined.  Each bot gets one tie it can form (though unlimited ties can form to it from other bots).
--- End quote ---

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?
--- End quote ---

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.

Trafalgar:

--- Quote from: Jez ---
--- Quote from: Trafalgar ---I'd rather not have aiming (at where the target will theoretically be in the future) be even more difficult than it is now.
--- End quote ---
Do you think the ability to do that should be cost free?

--- End quote ---

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)

Jez:

--- Quote from: Trafalgar ---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.
--- End quote ---
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!

Navigation

[0] Message Index

[#] Next page

[*] Previous page