View source for Talk:Bullet Shielding

Credits - Bullet Shielding Old wiki page: BulletShielding Original author(s): Vuen

Discussion from Old Wiki

I was just reading this, and thought of an idea: Instead of theming Firing/Movement? on bullet collisions like this, why not use this technique to enhance the existing methods of WaveSurfing? Basically, track movement of your own bullets, and check what "umbrellas" exist, and set the danger factor to 0 where it is covered by an "umbrella". A robot using this would be able to take advantage of these zero-danger locations while still using good movement when it can't get to these zero danger locations. You don't even to make the firing algorithm optimized for creating as much BulletShielding as possible, just just look at what lucky BulletShielding happens to exist. Perhaps this could be combined with firing that is designed to create more BulletShielding, but even without that you could use this to make WaveSurfing just a little bit smarter. -- Rednalexa

I've tried this recently, and in practice the width of these umbrellas are rather narrow. I'm still working with the idea though. I spent a couple hours earlier today looking at the logistics of creating deliberate safe(r) areas. More work ahead of me. -- Martin

Well, even if the umbrellas are very narrow, it could still reduce the overall danger (both actual and calculated) across the width of the robot. Even if it wouldn't change the lowest danger location for the robot very often, every avoided bullet counts. Best of luck tring to implement this type of thing. I might give it a try once my WaveSurfing is working well enough to be worth looking for these smaller optimizations. -- Rednalexa

I've tried this too, no success. I thought this could be a nice secret weapon, but it hat no impact on the score ;( But the idea of BulletShielding is fascinating, I tried it every once in a while :) --Krabb

Interesting. Well, despite the past failures people have had with this, I'll probably give it a try some day just for fun. I think that somebody will manage to get this to add a tiny tiny fraction of score. Maybe 0.01 extra score in the RoboRumble will be achievable some day with this? :) -- Rednalexa

Multiple bullets?

Is it possible for more than 2 bullets to collide? And if so, how do the mechanics of that work? --Starrynte 04:29, 23 April 2010 (UTC)

I actually have no idea. Both may be removed from consideration as soon as the collision is detected, but I dunno. I imagine you could easily tell from looking at the Robocode source. Or of course you could code up some bots that fire intersecting bullets and see what happens. =) --Voidious 20:52, 23 April 2010 (UTC)

Voidious is correct and incorrect. Each bullet can only hit once, either other bullets, robots or wall. So if more than two bullets collide, each bullet will be paired with other bullets and the odd one is left. This happen randomly, so it is completely unpredictable which pair will collide. No, it can be easily tell from Robocode source. It is quite complicated and very modular. =) --Nat Pavasant 05:24, 24 April 2010 (UTC)

Parametric equations?

How do I use "parametric equations"? Could someone explain this to me? For example, what kind of equations would I use the "center" the intersection point?

---- Josh S 11:18, 26 April 2010 (UTC)

No practical need to adjust the bullet power

In MoxieBot, I found that the bullet shadows are usually smaller than the width of my bot, and that the increased shadow size given by 'centering' the collision didn't make up for the additional energy loss from firing a bullet of power greater than ".1". Ncj 05:58, 4 February 2011 (UTC)

It really shouldn't be hard to get such a simple concept to work. I thought I had to working too. But apparently it was a number of flukes all happening in a row.

I am not particularly surprised I failed. I mean come on, its me. But I have a few more ideas.

Got it, this time I am sure. I will post some code for everyone to peruse soon. Darn off by 1 errors.

Here you go, enjoy! https://gist.github.com/Chase-san/7edb0974df656bec12d8

Sorry that it is a mess and for all the custom/internal class usage. But I don't think it is anything to foreign.

Vector is Point2D on steroids. Line is just Line2D with custom initializer. MintState tracks all data. It updates energy according to HitByBullet and BulletHit as well.

One last note. This is a very basic bullet shield. It might not work 100%. But it does work. That is enough for people to take it and run I think.

I'll rewrite it to not use special classes soon.

Nice looking code.

Yeah, look again, I just fixed a bug. :)

I've been playing with adjusting bullet power the last couple of days. It seemed to be a good idea in theory, but the idea of using 0.15 power and adjusting it would make it seem like you could successfully adjust in a small range of power like 0.1 - 0.2. In practice, if I didn't make an error some where, this is far from the case. I'm seeing a range of more like 0.1 to 1.5, and anything over about 0.4 is, in my opinion, way too high a power for a shielding shot. You might be able to improve slightly keeping a small range of power like 0.1 to 0.2, but it will often be far from hitting the midpoint.

I was also thinking something similar, adjusting the bullet power (in regular surfing) to maximise the overlap of the waves and thus the size of bullet shadows. My biggest objection is that I wouldn't be able to use the x.x5 rounding bug to my advantage. The other problem was that it would also make the enemy capable of figuring out where I fired based on where the overlap was biggest.

I'm surprised it didn't work for you. Maybe if you simulate firing a tick later instead you will get better overlap? If your bullet power is significantly less than theirs you also get lower gunheat, so you have a few ticks to spare where you can choose when to fire.

No matter the bullet power, bullet shadows are still very narrow.

I played a bit with bullet shielding. Guessing which angle the opponent is firing at seems to be a lot more important than maximizing shadows.

Moving in a way to create spikes in opponents targeting history and make their guns predictable also works wonders... unless opponents have anti bullet shielding embedded in their guns.

Hang on, looking at your description on the Xandercat page, are you trying to get the bullets to hit at half-way travel such that bullet.dist(fireLocation) == bullet.dist(targetLocation)? What I was talking about was shifting the point of intersection of the wave such that your bullet 'tail' covers the largest portion of the enemy wave.

Moving sideways helps shooting a bullet "diagonally" and hitting incoming bullets more effectively. Very useful if the incoming bullet used head-on targeting.