Bullet Shielding

Sorry for the confusion caused. I just named things the wrong way. When I say segment intersection, I mean the safe area generated by the intersection of those segments, like in bullet shadowing. What I wonder is if, in a perfect universe where computers can compute with perfect precision, two bullets laying on opposite rays would collide or not. Note that the lines actually intersect, so the segments. The safe area, though, degenerates to a single point. So my doubt was like: Robocode actually checks for an intersection of those segments or for a non-degenerate safe area?

Note this degenerated from an actually valuable discussion into a stupid curiosity. :P

Robocode doesn't care about that safe area at all. In segment intersection algorithm, The first thing is to determine whether they are on the same line. If so, robocode just ignores the intersection. This behavior look strange at first, but it is friendly to those who new to robocode. This way they (when trying two stationary robot, etc. sample.Fire) won't confuse — why my robot collides its bullet with another all the time?

Yeah, I was just interested in the behavior. Thank you again, that was pretty enlightening and makes total sense, it would be stupid if those bullets collided. Gotta take some time to make sure I understand all the Robocode mechanics.

After a long night, I just have to say that Bullet Shielding is the hardest thing... ever. You deserve a huge prize, man.

Thanks ;) Anyway, are you trying to build your own BulletShielder? Worth mention that a lot of good shielders are open source (although I haven't looked into any of them yet).

Yes, I was. I started reading the tutorial, but I found it really counter intuitive, so I decided to go by the bullet shadowing approach (or very similar to it). I looked at EnergyDome after struggling for a few hours, just to notice that the only difference was the use of Virtual Guns and the multi-movement thing. So it was doing pretty much the same thing I was for the intersection. I got happy and thought I was going to find where my bug could be. At this point I couldn't even shield a single bullet, so the VG thing was not a game changer. It turns out that I couldn't fix it. I'm just supposing it's in the actual intersection algorithm, since I can't even shield against Tracker after moving a fraction of a pixel. It should work easily if was doing things right, correct?

Even if your algorithm is correct, it won't work with wrong target. You could try SimpleBot 0.022c, which uses traditional HOT (for stationary bot) with random fire power. If the algorithm is all right, it would at least shield a lot.

That version is not in http://robocode-archive.strangeautomata.com/robots/ :P

Just added a link to it ;) Just forgot that It is never released.

No, it's not enough. Anything below 1e-8 can be considered as round-off errors, and the firing range you shadowed is much much bigger. You may try some debug graphics to see if everything works as expected, say, if they collide at calculated point.

That could be enough to cause a miss if you aren't moving to intersect the bullet. I think you should check what the predicted width of your shielded area is, and compare that to EnergyDome. It is a balance moving when you make the shot to get a bigger intersection area, because that means learning guns might learn your movement and not shoot HOT anymore. But not moving at all means your intersection width might be too small to be able to hit if enemies are predicting their movement.

Also remember that even if they aren't predicting their next location, if they make a shot while they are standing still (eg changing direction) then their aiming will be at your center and you will need to move when you fire to intercept the bullet.

Yes, this is crucial. But in my experience, when I set the threshold to 1e-14, it works pretty well — If the angle between your bullet and their bullet is below 1e-14, move. Else, don't move.

I also tried to take how good the intersection into account (etc. if the intersection is below 0.1, also move), but no improvement at all.

Therefore I think it's not because 1e-16 caused the miss — even 0 is not enough, when the angle is below 1e-14, the game just ignores the intersection.