Talk:Basilisk

From Robowiki
Jump to navigation Jump to search

Contents

Thread titleRepliesLast modified
Bullet Shielding1321:19, 19 April 2019
Targeting422:34, 10 April 2019
Stop and Go1222:34, 10 April 2019

Bullet Shielding

Basilisk gets bullet shielded to death by Cold Breath, uCatcher and BulletCatcher in the micro rumble. You might want to add a really little amount of random factor so bullet shielders won't hit you consistently.
You will gain free APS and I'll lose some =(
Dsekercioglu (talk)11:20, 23 March 2019

I never ever put anti-shielding code into any of my bot. I just do everything “correctly” and shielders simply don’t work anymore.

Xor (talk)00:34, 24 March 2019
Aren't Bullet Shielders supposed to be working against any deterministic strategy? IIRC what I do is to fire with some kind of random deviation when WhiteFang gets shielded more than 50% of the time.
Does doing correctly include not firing angles that do not hit? =)
Dsekercioglu (talk)10:50, 24 March 2019

“correct” means shooting at the angle with statistically maximum hit rate, instead of the intuitive center.

Since it’s statistical, it suffers from rounding errors and is chaos so shielding is impossible.

Xor (talk)03:53, 25 March 2019
Does this mean you are including enemy bullets in your firing algorithm to eliminate angles?
Removing the shielded bullets might actually be a smart idea in AS Targeting.
Dsekercioglu (talk)10:58, 25 March 2019

Not yet, but this sounds a good idea. Anyway I don’t think this will improve anything actually, since you don’t have precise information.

What I mean in statistically best is when you take precisely how robocode physics works into account, e.g. precise intersection and don’t use bins.

Xor (talk)11:13, 26 March 2019
 
 
 
 

Done! I added a random factor onto the gun if the bullet hit bullet event happens too often! Thanks for the idea, Basilisk 2.5 is now in #22 :)

Slugzilla (talk)13:05, 26 March 2019
For a second I thought it was roborumble =)
Congrats on 22th place, maybe I'll do a mini bot just for competition.
Oh and BTW if you have code size issues have that random factor on all the time. You should statistically have the same hit rate and you will have more place for future plans.
Dsekercioglu (talk)14:51, 26 March 2019

Haha I wish #22 in the roborumble :) Basilisk 2.5 is 1464 bytes so I will definitely make the random factor all the time. I plan to add some more segmentation to the gun and tweak the movement more in the future.

Slugzilla (talk)16:07, 26 March 2019
 
 

Hi, semi-random question. I saw David Alves' video on the evolution of robocode strategy and I watched the part about the bullet shadowing. While bullet shielding can be beaten with a random factor or precise intersection, do bullet shadows create a safe zone that cannot be hit by any bullets, even with a random factor, provided the shadow is large enough?

Slugzilla (talk)01:01, 19 April 2019

Short answer: yes, but you'd have to do it on purpose to make a bot-sized shadow. Bullets are just a short line segment, so you can optimize for maximum shadow size with that in mind. If the bullet is very close to an opponent when they fire, the shadow that is will cast will generally be larger. The more distance between the bullet's intersection with the enemy's wave and you, the larger the shadow grows. Also, if the bullet is perpendicular (not pointing directly at them) the shadow will be larger because it has more surface area relative to the wave. If you watch a bot that tracks bullet shadows long enough with debug graphics turned on, you'll start to notice all that.

Enamel 32 (talk)01:50, 19 April 2019

Awesome! I'm going to try to create a robot that uses active bullet shadowing, kind of like MoxieBot. Thanks for the help!

Slugzilla (talk)21:16, 19 April 2019
 
When you are bullet shielding, you cannot cover the whole bot width. You don't have enough time to move to get the perfect angle so your actual goal is to predict(no learning is used generally) where the enemy fires. :When using bullet shadows what you do is: "My bullet was here, if there were any other bullets in this zone they would have collided. Therefore, the opponent didn't fire here.
In conclusion, bullet shadows guarantee that you won't be hit in that area while bullet shielders aim to predict where the opponent fires at.
Dsekercioglu (talk)08:53, 19 April 2019

It seems that bullet shadows are used for information purposes rather than a defensive technique. However, if you are firing to create large bullet shadows rather than hit the enemy, could the bullet shadow be wide enough to hide in? Thanks!

Slugzilla (talk)21:19, 19 April 2019
 
 
 
I will probably regret this=)
It seems to me that you have a huge bug in your targeting. Max escape angle is fixed in the targeting class however you are using different fire powers. It makes your gun use limited bearing offsets instead of guess factors. You cannot hit robots that rotate around you when you are firing with full power.
Dsekercioglu (talk)15:30, 9 April 2019

Oh no! I will have to fix that soon. Thanks for pointing it out!

Slugzilla (talk)22:29, 9 April 2019
 

I think I fixed it. When you have the chance, could you take a look just to confirm? Thanks!

Slugzilla (talk)23:57, 9 April 2019

MEA is asin(8/v) as orbiting is not the smartest thing to do. Also, you don’t need to cast BINS to double as MEA is already a double. I might be responsible for MEA as I used to think it was the correct one=(

Dsekercioglu (talk)06:11, 10 April 2019

Ok. Thanks!

Slugzilla (talk)22:34, 10 April 2019
 
 
 

Stop and Go

Hi, I was comparing my robot to Cotillion and EpeeistMicro, and I noticed that my robot gets consistently worse scores against head on and linear targeting bots then the other stop and go bots do. Basilisk gets around 75 - 90% on the simple targeters, while Cotillion and EpeeistMicro get around 90 - 95%. I use Cotillion's formula for the stop and go movement calculation, so I don't know what it is about my robot's stop and go that makes it worse than the others. Could someone take a look at my code and tell me what makes it worse than the other stop and go robots? Thanks!

Slugzilla (talk)01:35, 8 April 2019

I posted the code on Basilisk's page so if you want to take a look you don't have to download and extract my robot. Thanks again!

Slugzilla (talk)01:41, 8 April 2019
 

I haven't looked at the code, but my guess is your distancing is trying to get away too quickly/steeply, so you sometimes aren't moving a big enough angle laterally to get out of the way, especially with smaller bullet powers.

The other thing might be that you have false bullet detections.

Skilgannon (talk)10:47, 8 April 2019

Hmm, I tried moving around with the movement lateral angle set to 0.3, 0.4, and 0.45, but it didn't seem to do any good. However, I did notice that every so often, Basilisk didn't move when a bullet was fired. I think I will tackle that problem when I have more time this weekend =) Also, it seems my robot gets rammed a lot more often then Cotillion and EpeeistMicro. Against Dalek, approximately every 10 rounds Dalek runs into him, but Cotillion and EpeeistMicro never seem to have this problem. Maybe I'll add some anti ramming code later =) Thanks for the help!

Slugzilla (talk)02:14, 9 April 2019

The code seems identical but I have noticed some randomized direction change in Basilisk. It might also be that it gets activated when it's not supposed to.

Dsekercioglu (talk)05:53, 9 April 2019
 

Sounds like some bugs or missing factors in the enemy energy tracking.

Skilgannon (talk)11:40, 9 April 2019

I don't think so, it both counts hit bullets and energy gains in the bot. Maybe try printing different movement modes on the console to see if they are being switched abnormally?

Dsekercioglu (talk)15:07, 9 April 2019

The randomized direction change is only supposed to be activated when its using random movement, but I'll add some print statements to make sure. Thanks!

Slugzilla (talk)22:20, 9 April 2019
 

Maybe I should move the stop and go into the onScannedRobot event instead of its current goTo void. Currently I am using prevEnergy > enemyEnergy, with enemyEnergy being called every tick and prevEnergy being called right after moving. If I move it into the onScannedRobot event, and use prevEnergy > e.getEnergy(), do you think that would fix some of its problems? Thanks!

Slugzilla (talk)22:25, 9 April 2019

As long as you are checking if delta energy is between 0.1 and 3.0 there shouldn’t be any problems. I think that your current system of upgrading enemy energy is working but I’m not sure.

Dsekercioglu (talk)22:35, 9 April 2019