Talk:Bullet Shielding

From Robowiki
Revision as of 12:20, 26 April 2010 by Urgood2 (talk | contribs)
Jump to navigation Jump to search
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? Quote:

Using the intercept coordinates you calculated earlier, slide them along the enemy bullet's trajectory to make them land at exactly the midpoint of a nearby displacement. To do this, use parametric (or vector) equations for your coordinates to calculate a parameter, then subtract 0.5 from your parameter and round it off, then add the 0.5 again and recalculate the coordinates.

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

You cannot post new threads to this discussion page because it has been protected from new threads, or you do not currently have permission to edit.

Contents

Thread titleRepliesLast modified
Harder then I though403:01, 19 February 2013
Adjusting Bullet Power518:00, 12 February 2013

Harder then I though

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.

Chase23:55, 18 February 2013

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

Chase00:41, 19 February 2013
 

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.

Chase00:46, 19 February 2013

Nice looking code.

Skotty02:57, 19 February 2013
 

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

Chase03:01, 19 February 2013
 
 

Adjusting Bullet Power

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.

Skotty14:07, 12 February 2013

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.

Skilgannon16:56, 12 February 2013
 

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.

MN17:31, 12 February 2013
 

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.

Skilgannon17:37, 12 February 2013

No -- Just trying to get the tail to cover largest portion of the enemy wave. But minor bullet power changes just don't seem to make enough difference in bullet speed to do this effectively. However, it could be improved by moving forward or backward a little before taking the shot. I haven't experimented with that.

Skotty17:53, 12 February 2013
 

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

MN18:00, 12 February 2013