Talk:Yatagan/Source

First, we initialize integer to 255 to save a byte. :)
Then, in the PM code we use (integer = integer >> 1), instead of (integer = integer - 1).

If I'm right (which I rarely am), this would be smaller, faster and smarter. How does it sound to you?

Sounds good. I did a geometric reduction of the key length in Toorkild as well, and it worked fine.

Hmm, for some reason, under Jikes, both of those changes add a byte of codesize. Any number above 127 takes an extra byte, and >> is one more byte than --

Were you using Jikes when you compiled Toorkild and got the weird savings from 255?

Yes, but I was using it for an array size, so that might have been something else happening.

So, if we do it just like Toorkild and use 64 as the initialization value, and use integer /= 2 instead of --integer, we should break even at 249 bytes, right?

Also, I think we should try using power-3 bullets, or at least go back to power 2.6667. I think 2.33333... is a little too soft for a bot with such an aggressive movement.

If the changes work, then go ahead and release version 1.0.4.

integer/=2 takes an extra byte from --integer, but if we switch our bullet power to 3 we have that byte to spare. I'll package it up and release.

Huh, for some reason it lost a lot against weak bots. Do you think this is because of the PM change, the bullet power change, or the movement change? I doubt it was because of the change to the random multiplier, because the RM shouldn't even be activated against weak bots.

I think the higher bullet power made it waste energy quicker, giving it an extra loss or two, which pushed a bunch of bots over into the random movement instead of orbit/oscillate.

One thing I noticed while watching battles was if it starts from very far away it does loops instead of settling for a nice orbital movement. I'm thinking of decreasing the turn amount caused by the distancing, especially as it isn't as sensitive to that now that the gun can handle any distance correctly.

Okay. Let's change the BP back to 2.33... and the constant in the distance controller from 2500 to 3000.

We also might try doing 3/orbit + 3/oscillate + 94/random instead of 2/orbit + 2/oscillate + 96/random.

One step at a time, I'd rather have less sacrificial rounds against top bots and lower the bullet power, although that gets us right back to where we were. I also want to see where the threshold is, so how about BP 2.666?

Sounds good.

I have another crazy idea that would allow us to get rid of the distance variable. The problem is, it would cost about ~2 bytes in other areas. Should I try it?

Of course, give it a go. I'll see how it compiles.

Sweet, that saves 3 bytes, down to 246. I'll package and upload in the morning when I'm a bit more awake =)

Ok, that doesn't work because the absoluteBearing has been fully initialised and doesn't just use the e.getBearingRadians() value, so it goes in circles. Oh well, I was hoping for some more codesize there!

Try it again with a pair of parentheses around e.bearing + heading. That should fully initialize absolute bearing. If it doesn't, then there must be something else going on.

What were you planning to do with the extra space?

Nope, the problem is in the distancing, see the change I made that fixes the behaviour.

I'm not sure what to do with the space, but I'm sure we can think of something. Perhaps better bullet power selection for rambots or something like that.

I think I figured out a way to get those bytes back--at a loss of targeting accuracy. We'll see if it's worth it.

I highly doubt you'd be able to fit anti-ram in 3-4 bytes. But, it seems that almost every time I say that, you prove me wrong. :)

Ooooh, that is ugly ugly ugly. But this is nano, the king of ugly, so it would only be fitting if the king was ugly too. I'm not sure what we'd gain from rambots would make up for this, but it's worth a try I guess.

I'm not really worried about rambots; Yatagan already does fine against them. Let's just enter this version as it is, and see if the performance loss is substantial.

I'm not sure why, but it stayed at 249 bytes.

Skilgannon,
I think that it would be best to use the Development Version section as the main development code base. Sort of like how Chase and I managed the co-development of Talon. That is, whenever either of us tweaks Yatagan, we update the code on this page. And, whenever we decide to release a new version, we package the code on this page.

Also, I would appreciate if you posted the code-size after you change something.

Thanks.

No problem.

I think it would be best if we change the default chance-of-reversing in RM mode from 0.666667 back to 0.5.

Done. This is something which will need some tuning, though. And how about a larger orbit distance?

The HOT avoidance likes to be really close to minimize wall hits, the LT avoidance really doesn't care how close it is, and the RM mode likes to stay just about as far away as possible.

Both Moebius and Sabreur use 160, and I believe Mike said that after a lot of testing, he found that 160 was the best distance for Moebius.

But, if you would like to try 180 or 200, go ahead.

Huh, apparently 0.6666666666667 was about 0.4 APS better than 0.5.

Do you have any idea why it's performing so horribly against other PM bots?

Those two oddities are linked. Because it only decides once per enemy bullet which direction to go in, and because of the close fighting distance, we end up with two large probability spikes, one at GF1 and one at GF-1 (or as close as is reachable). If it were further away more than one bullet firing event would happen, so it would make the decision more than once, adding variability to where it ends up (2^n spikes for n bullet firings). Either we need to take the reversing decision out of the bullet-fired dependency, or we need to be far enough away that it can even out those spikes.

PM doesn't care about GF's, but a movement that is easy for a GFT gun to hit is usually easy for a PM gun to hit.

If you could fit a .08 probability of reversing every tick without loosing performance elsewhere, that would be amazing. The reason Yatagan's movement is small enough to fit distance control and good energy monitoring is because it's so simple and elegant. When the enemy fires, either never reverse, always reverse, or have a random chance of reverse or not reversing.

I guess we'll try a distance of 200/220 in the next version. It will almost certainly harm performance against HOT, but the gain against PM might make up for it.

I think I might have something which keeps full functionality but also reverses with a 0.08 probability. The problem is, it also reverses with any enemy bullet fire, so should I decrease that probability? I'm thinking down to about 0.06, since there needs to be a good chance of a direction change happening during the flight time of the bullet, but there was already one at bullet fire time so we don't want it reversing all over the place. Or should I stick with 0.08?

Go ahead and test with 0.06 or 0.05.

Never mind, I figured out a way around that too, all while using even less codesize than our previous reverse method, so I added back setAdjustGunForRobotTurn(true). Being able to feed custom variables to a random multiplier can do miraculous things! Particularly when you only want probabilistic behaviour, and not absolute behaviour. But hey, a probability of 1 in 20k is pretty much 0, right? ;-)