General Targeting Discussion

Not method specific questions:

I need a targeting method to pick off an oscillator without pattern matching. I've never even considered how to do this, and really don't want to "invent" such a primitive gun for this one little thing if it's already been invented, so, has it already been done? I'm guessing there's some kind of circular targeting with a way to account for periodic direction changes, or just something based on sin/cos waves. Has anyone done this? -- Kuuran

Well, I have tried, but always end up going nuts when my brain waves collide and entangle. =) It just so happens that AngularTargeting/Factored combined with AveragedBearingOffsetTargeting and some segmentation of the factors work quite well against oscillators. Try using a gun like in Gouldingi/Code and see if it is what you need. Of course, if it's for a nano you can't use it until Albert or some other brainiac manages to shrink that kind of gun considerably. Of course a brainiac like that probably can think out an anti-oscillator gun instead. =) -- PEZ

Hehehe :) Thanks, but thankfully it's not for a nano, I'm totally stuck on finding more space in NanoSatan at the moment. Instead I'm working on finishing up this proof of concept (which, with just it's supplementary classes, already crosses into mega :p). I need a targetting that can hit a regular oscillator, but does almost no learning (ideally the only learning is figuring out the period of the oscillator). I'll take a look at the AngularTargeting/Factored and AveragedBearingOffsetTargeting solutions, though :) If I can't make them work I'll just try extrapolating along a sin function stretched to a guess and check period. -- Kuuran

I've always thought of looking for 'periods' of movement as a form of pattern-matching, too. You could potentially try and match it to an approximate sine wave (of course, only nanos REALLY use a sine wave for oscillating motion) based on the times it turns around, and the distance it moves since the last peak. Once you have a period, an amplitude, an orientation (? unless you assume it's oscillating perpendicular to you, which may be reasonable), and an offset (implicit with the period sort of), you can make a mathematical function to estimate it. Hard to say if this is truly useful, though, but with simple oscillators and the occasional true sine oscillator, maybe it would work. -- Kawigi

That's about where I've ended up too, yeah, thanks Kawigi :) I guess you've confirmed what I feared, no easy way to do this. I'm instead going to avoid this part of the code for now and see if it'll simply work without, it quite possibly can. -- Kuuran

Fourier transformation of x(t) and y(t) will give you both: answer if opponents movement is based on oscillations and base for good anti-oscillator gun (if amplitude of fourier series is falling to zero fast: oscillator!) It is a drag to program it though. -- Frakir

Actually, the old averaged-velocity linear targeting may work well for your problem, Kuuran. -- Dil

You mean in the neighborhood of NanoDuelist? Or was it DuelistNano. Is there a difference between those, David? -- Kawigi

---

Q: What is the best way to find the right enemy direction? What alternatives are there? I want to use it for the right gun turn. --SSO

I'm not sure I understand the question. -- PEZ

By enemy direction, do you mean the enemy's heading? That's given in a ScannedRobotEvent by e.getHeading(). If you mean the enemy's bearing, that's e.getBearing(), and it's offset by your current heading. -- Vuen

I mean the clockwise (+) or counterclockwise (-). For instance in Tityus -Pez uses the abslute bearing diffrence. The flood mini uses lataral velosity sign. My problem is what others are there and under which conditions they are valid? My problem is I want to combine the direction with the stat gun. But my ranges are between -18 and 18. So if the direction is - and the best index is -10, than I got a diffrent result that index 10 . How to combine the direction and best index. --SSO

A rating of +18 would mean it's continuing in the same direction, -18 means turning around and going in the other direction. I think the easiest way to tell the direction is to have a global variable which stores the last known bearing to the enemy, and before you fire you compare the current bearing to the last known one, and then you know the direction it's going. (current>last then clockwise, else anticlockwise) -- Tango

Whether you use bearing difference or lateral velocity (if you use bearing difference, be sure to measure, like PEZ does, the bearing from your last position to the enemy's last position compared to the bearing from your last position to their current position), all you need to do is figure out the angle offset that the best index corresponds to, and multiply it by the direction. Then turn your gun right that much from head-on. -- Kawigi

---

What is a way to accurately find the time the bullet takes to travel to the enemy's predicted position, which requires the time the bullet will take? An obvious way is to continuously update the time in a loop until you have it close enough (add the change components to the vector representing the path the bullet will travel, then get the hypotenuse again). I know that the time the bullet takes to travel to predicted position and the predicted position after a certain time are dependent on EACH OTHER, but is there some kind of "magic formula" to do this? -Scoob

The most accurate way in general is to do what you described, in a loop calculate the next position and the distance to that position, and when the distance the bullet has travelled exceeds the distance to that position, that's the intersection. For different kinds of targeting there may be simplifications, though. For example: a linear gun can be simplified to a triangle between you, your opponent and the point of intersection, so a simple trig solution is possible. -- Kuuran

---

Hi, I'm new to this thing. I'm currently trying to implement something onto my corrupted version of Walls. I have HeadOnTargeting. What I'm trying to do is, if the other robot is disabled, my robot (Ziska) will stop, turn the gun to the enemy, and fire. What I currently have is

public void onScannedRobot(ScannedRobotEvent e) {
    if (e.getEnergy()<0.1) {
        stop();
        setTurnRadarRight(getRadarTurnRemaining());
        setTurnGunRight(720);
        fire(0.1);
        resume();
    }
    else {
        double absoluteBearing = getHeadingRadians() + e.getBearingRadians();
        setTurnGunRightRadians(robocode.util.Utils.normalRelativeAngle(
            absoluteBearing - getGunHeadingRadians()));
        fire(3);
    }
}

What will happen is, my robot will move in little jolts, moving its gun around, and firing sporadically. Eventually it will hit the thing but it doesn't work too well in melee, and wastes time and energy. I have experimented with various e.getBearings and e.getHeadings but nothing really works. What would be the best way to finish off a disabled robot in a single shot?

Thanks, PFVHanse /*/*/*/*/*/*/*/*/

I don't have much experience with ending turns in event handlers, but I think this is what you're trying to do (untested):

public void onScannedRobot(ScannedRobotEvent event) {
    double delta = robocode.util.Utils.normalRelativeAngle(getHeadingRadians() +
        event.getBearingRadians() - getGunHeadingRadians());
    if(event.getEnergy() < 0.1) {
        stop();
        turnGunRightRadians(delta);
        fire(0.1);
        resume();
    } else {
        setTurnGunRightRadians(delta);
        fire(3); // note that this bullet doesn't even get close if the gun
                 // is turned in the other direction
    }
}

-- Jonathan

Or probably, the gun turn in the first if statement should be turnGunRightRadians(delta + Math.PI*4);. The big distinction here is that you want the bot to finish turning the gun before firing, so you don't use a set call. -- Kawigi

---

I lifted some code from MyFirstTeam. It seems to work pretty well now. Thanks.

---

Couldn't you combine certain different ways of targeting, such as Neural Networks and say a GuessFactor Targeting, and use the ANN (artifical neural networks) to come up with the correct guessfactor for the gun to use based on ANN detection.. or is that how they do it already? -- Chase-san

Without a doubt, many of these concepts can be combined in interesting ways. For instance, the original GuessFactor guns were almost synonymous with being VisitCountStats systems; but both Lukious and Ali use log-based targeting methods that make use of GuessFactors, and the Lukious page even has a terminology discussion about it =). Many of us use VirtualGuns with 2 different high-powered guns, because targeting a WaveSurfer well can be so different than a non-AdaptiveMovement. I would bet Engineer does some combining of Neural Networks with other advanced Robocode concepts, though I have no proof other than it being such a powerful tank. -- Voidious

(edit conflict with voidious) I believe that is similar to how some systems work, such as Dynamic Clustering. I'm only lightly familiar with the subject, but I am guessing that gun segmentation can be considered to be a simple neural network. One "down the road" thing I've planned to do is to poll the opinions of more than one targeting methodology for set of multiple recommended firing angles each, and go with the most often recommended angle. That's probably similar in concept to dynamic clustering. -- Martin

Thanks Voidious. Engineer does indeed combine other Robocode topics with NNs. In fact, the network's output vectors are nothing more than arrays of bins, just as in a classical GF gun. The purpose of a Kohonen network is to classify input vectors and associate each general classification with an output vector (e.g. a set of hit stats); As opposed to other types of networks that try to reproduce exact patterns. --wcsv

(edit conflict with wcsv) Well I started thinking of Neural Networks once I saw it on wikipedia[1], and thought that the Reinforcement Learning[2] would be perfect for robot, but I thought about the complications of that and so I decided the easiest way would be for the networks to calculate the guessfactor which would make the entire wave system unneeded for the gun. (nods to wcsv) thats about what I was thinking -- Chase-san

I am trying to think of a way to remove the need for the wave class, though while the total removal of something like the wave class is something nearly impossible to accomplish, so i'm trying to come up with a "new" way to target which has the accurracy of segmented gf gun with all the do-dad's, but at the same time not have it degenerate into something like a pattern matcher. If I come up with anything that can do it I will be sure to put the idea to paper. However my chances are slim as almost everything has been done so far. -- Chase-san

Well, the wave idea seems like a really great tool for any 1v1 targeting method; you are the only real variable for the enemy, so aiming based on the current bearing between you and him is just very logical, and waves are great at collecting data for that. DisplacementTargeting comes to mind as a unique idea that you might be able to implement without waves. There's also the TronsGun / DynamicClustering family of guns, although some of those still make use of waves, too. -- Voidious

(edit conflict w/ Voidious) In order to gather any sort of useful info for targeting, you need to know something about the change in the target from the time that you fire (whether it's a real bullet or not) to the time that the "bullet" would pass the target. GF guns only care about the state of the target at the beginning and end of that period (the change in bearing) and PM guns keep track of the change over each tick in that period (generally the change in heading and velocity). A wave (as I see it) is basically just a convienient way to keep track of info about the beginning and end of that period. Your network still needs that info to be able to determine the GFs. --wcsv

Is there any way to hit sample.Crazy besides PM? (and lucky headon shots) --Starrynte

• Circular targeting does fairly well if not to far away. -- GrubbmGait
• Besides a PatternMatcher there are a few ways, you could make a gf gun(kinda advanced tho), or just make your bot stay close or even ram him. I find the best way to beat an enemy is to join them. So if you can't hit him, make sure he can't hit you either. (on a more general note, you could attempt a AverageBearingOffset gun, there are examples on the RaikoMicro page) -- Chase-san

Will random targeting hit Crazy? --Starrynte

The only time random targeting is as effective as another targeting method is when you're targeting a bot with perfect movement. Then, random targeting is as effective/ineffective as any other targeting. However, the rumble contains no bots with perfect movement; so you're better off trying something else. Crazy's movement is certainly not perfect. Try anything that uses probability - AverageBearingOffset, GuessFactors, PatternMatching, NeuralTargeting or best yet - GrubbmGrb pulls it off by deciding which simple targeting method (headon, linear, circular..) is best. --Corbos

I dont think so. Random targeting is better than HOT or LT vs good bots (they dont have to be perfect). You can easily dodge them, but you can't dodge random shots. --Krabb

• I am of the opinion that firing at random guess factors (i.e. the target could conceivably get where you are firing) is a good choice for the first shot, possibly a few of them. If you fire directly at a bot that hasn't moved they are likely just messing with you, so it is a wasted bullet. Ugluk doesn't fire randomly, but his first 6 shots in a battle are 0.1 power just to get the opponent moving around. -- Martin
• To me its seems best to use CT for the first few shots or, even better, fire at GF1. There are a lot of bots using sortof a MusashiTrick and you would nail them fast, forcing them to use their 'native' movement, before polluting the statistics too much. Krabb has a good point, firing random should hit equal against Dookious and SittingDuck. For firing peas (0.1) at the start of a battle (only first round I assume) is an interesting idea, I have to think about it if the advantages outscore the disadvantages. -- GrubbmGait

I had a rather inspired idea, well two in fact. The first isn't quiet to inspirious as it is manatorial. That is moving a good aprt of this to a /OldDiscussion page. Now for the real one, it was to make a sorts of a 'Dynamic' segmented gun. It would work like this.

First we would have a arraylist of arrays(the reason for an arraylist is because not all segmentation ahve the same range of data), each one containing a different segmentation, such as distance, acceleration, lateralVelocity, wall and reverse wall, and so on. Each of those arrays would count each time thier visited for targeting. Each time thier visited they would adjust a different set of arrays to be more accurate by adjusting the segmentation of a segment closest to it or by adding or removing a segment (thus would also require an arraylist or something simular).

I don't know if there is a type of gun that already does this, but if there is, could you enlighten be before I embark on attepting to make one. I'm sure someone at some time thought of something like this. -- Chase-san

I made a dynamically resegmenting gun. Grishnakh uses it. In addition to the regular segmentation, it would hold a variation that had one more division (data sliced more finely), one variation for each type of segmentation. When one of those finally had enough data so that each bin had at least one hit, it would recreate itself using the new segmentation, and a new variant with one higher in that bin. I had to set limits on each bin size, and it reached them fairly quickly. There are some lessons to be learned from such a gun. You are welcome to design one of your own and learn them. -- Martin (I certainly wasn't the first to do it either. I know Florent has.)

Can anyone tell me a targeting method that:

• Can hit all sample bots (well enough to win 90% of the rounds)
  
• Will work in melee
  

The only one i can think of is Melee PM. Can anyone think of more? --Starrynte

A 90-95% hit rate at what distance? And in a melee or 1 at a time? PM is probably the best against all sample bots, except maybe Crazy. But I don't think you need 90% hit rate against anyone in most situations. -- Voidious

I may be wrong on this, but I don't think there is a gun that can get 90-95% hitrates against all the sample bots, at least not in any realistic battle situation. ( My guns certainly can't hit Crazy 90% of the time :) ) --wcsv

How about a gun to hit well enough to win 90% of the rounds? --Starrynte

Well I assume that a patternMatcher would do the job, as long as you make it well. --Chase-san

Hey! You changed your post from before! Anyway, just about any of the more 'advanced' targeting methods (VG, GF, PM) should be able to win 90% of the rounds vs the sample bots as long as you've got a semi-decent movement, and all of them can be adapted to melee in one way or another. --wcsv

I had quite an amazing idea while building the raw buffer class for my new bot! What if in a GF gun (and maybe surfing too) you not only used different segments to aim, but different bin sizes aswell. Thus you could have 21 bins and 61 bins, and then compare the outputs by a compairison of guessfactors to find the best factor to shoot at, so that your aim is both general and specific. In fact I am implimenting this functionality in my bot as soon as I figure out how to correctly compare the guessfactors as they wouldn't be equal, and such even if they were close aiming at the average could be tricky. Only thing I can think of is a zoom like trick starting at the lowest sized bin (e.g. say 21), and slowly getting more specific for a better aim.

What does everyone else think of this idea? --Chase-san

As around 60 bins is all you need, most bots use between 31 and 55 bins, lowering the granularity would affect your precision. If there is not enough data yet in 60 bins to make a reliable prediction, groupings of f.e. 5 resulting in 12 'bigbins' could give satisfying results. On the other hand, temporarily dropping a less important segmentation gives the same and maybe even a better result. Your idea seems to have some similarities with ZoomTargeting. Only one way to tell if it works: trying it! -- GrubbmGait

I ran a TC 2k6, without any kind of anti-surfer aimer and achieved a amazing ~85.5% (not sure of the exact percent as I left it at home). In the original TC it got about a 92.2%, right below Raiko. I might use a version of nekoangels gun for the anti-surfer gun (which by itself got a 83 or there abouts on 2k6). But that would be a royal waste of my flexable buffer system. I'll compare anti-surf stats later. -- Chase-san

The idea itself seems sound, but I agree with Grubbm that dropping one segment might be preferable to decreasing the number of bins. For a really scientific comparison, I'd try a version of the gun with a fixed number of segments and a low segmented / fast learning buffer added into the mix. In any case, nice work on that gun, 85 is darn a good score in TC2K6. -- Voidious

VG worked well, except that it was painfully slow and sometimes i get stopped. (I am only doing it for the target). Unless, someone can think of a way to do VG and make it be quick. --Starrynte

What kind of guns did you have in your VirtualGuns system? A VirtualGuns system doesn't have to be slow to execute, but if you have multiple, completely separate slow guns in the VG, it is bound to be very slow. -- Voidious

Oh, if you want to look at a VirtualGuns implementation that is pretty quick to execute, check out GrubbmGrb. It's a VG of simple aimers that is quite effective. (I confess I haven't looked at the code myself, but Grubb knows his stuff and that bot rocks.) The latest versions of Dookious also have a good VirtualGuns system that is pretty quick, but it's wave based and might not be quite as straightforward as the one in GrubbmGrb. You can find the source code in the .jar files for both bots. -- Voidious

Those scores are without the zoom trick, which proved problematic when I used them with segments, instead I just use 5 buffers of different segmentations and combine the results dynamically based on a weighted system. --Chase-san

I had HOT,CT, and RT for the VGuns. --Starrynte

Btw, it seems like that GrubbmGrb uses waves also. Is 1.2.3 the latest version?

The latest version of GrubbmGrb is 1.2.4, it can be found at the RobocodeRepository and at my own webspace. Most of my versions are present there. Although it uses waves by name and even implementation, the result is much more related to VirtualBullets as only the specific angles of the virtual guns are compared. Each virtualgun has its own 'wave' with one angle to check. A real wave-based implementation would fire one wave and record all angles that would hit (like GresSuffurd). And Voidious is right, GrubbmGrb is a relatively fast bot as it only uses FastTargeting and simple movement. -- GrubbmGait

The VGuns are "fast" now, but it throws a concurrent exception. Let me check the exact details. --Starrynte

ntc.Smash: Exception: java.util.ConcurrentModificationException
java.util.ConcurrentModificationException
    at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449)
    at java.util.AbstractList$Itr.next(AbstractList.java:420)
    at ntc.Gun.checkHits(Gun.java:68)
    at ntc.Smash.doVirtBullets(Smash.java:330)
    at ntc.Smash.run(Smash.java:32)
    at robocode.peer.RobotPeer.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:595)

From http://java.sun.com/j2se/1.4.2/docs/api/java/util/ConcurrentModificationException.html:

public class ConcurrentModificationException extends RuntimeException This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible.

--Starrynte

No more ConcurrentModificationException, but now it's too slow again. I'll take a look at the MeleePatternMatcher and see if it's fixed yet--Starrynte

Help with MeleePatternMatcher plz! --Starrynte

Is there any open-source bot that uses a MeleePatternMatcher that worx? --Starrynte

Sorry for being new to this and programming in general(wrote my first bot/java program Jan 17), but i think this is the right place to put this. I've been working on my first bot, and it works pretty well for what i want it to do except for one thing: Whenever it starts, if it starts with the radar facing the enemy or sees the enemy before it has a chance to finish turning its gun, the gun stops turning halfway and cripples the robot. I tried putting the boolean stopWhenWeSeeRobot = false; from corners but it didn't help, I'm not sure if i'm using it the right way. Is there a way i can keep this from happening? Here is the code:

public class MagicD2 extends AdvancedRobot{
	
	public void run() {
		turnGunLeft(90);
		boolean stopWhenWeSeeRobot = false;
		setTurnRadarLeft(10000);
		
			while(true) {
			ahead(200);
		}

	}

	public void onScannedRobot(ScannedRobotEvent e) {
		double bulletPower =(400/e.getDistance()); 
		stop();
		turnLeft(-90-e.getBearing());
		fire(bulletPower);
		setTurnRadarLeft(10000);
	}
	public void onHitWall(HitWallEvent e){
		setTurnRight(20);
		back(300);
		setTurnRadarLeft(10000);
	}

-CrazyBassoonist

Being new is no reason to be sorry ;-). The stop method you call on the "onScannedRobot" event handler, not only stops the bot, it also stops the gun and radar. A quick way to fix your problem is to retrieve the remaining gun turn before stopping. Something like this:

	public void onScannedRobot(ScannedRobotEvent e) {
		double bulletPower =(400/e.getDistance()); 
		double turn = getGunTurnRemaining();
		stop();
		turnGunRight(turn);
		turnLeft(-90-e.getBearing());
		fire(bulletPower);
		setTurnRadarLeft(10000);
	}

As you can see, I turned the gun right and not left (as you do), this is because getGunTurnRemaining will give how much turn remains to the right, you could set it to turn left, but then use "-turn" instead. Although that should fix your problem, I recommend reading some of the basics on the wiki before you code to much, since information is being migrated from an older wiki to this one, there are still things that are better read from the old wiki. I recommend creating an account on this wiki, that would give a place where you can chat without being afraid of placing something on a wrong place. Have fun Robocoding, and beep if you need more help -Zyx 20:49, 19 January 2009 (UTC)

Thanks, i had realized that the stop() was the problem but I wasn't sure how to deal with it. I'll be sure to check out the old wiki. Also, there is another strange thing about this robot. Every now and then it will stop moving and begin to track the enemy with a narrow beam while constantly firing. I am not sure why it does this as I did not intend to make the radar track the enemy, just spin around and update the robot about the enemy's position. Luckily it seems to help the robot alot. Does anyone know why it might do this? -CrazyBassoonist

Your welcome. About the radar, I don't know exactly what makes your radar track the enemy, it may be just a little bit of luck. Check the [Radar] page for more information on how to code your radar lock, there is one looping radar as well. --Zyx 21:10, 19 January 2009 (UTC)