User talk:Khanguy

WallHugging

I need help fixing my wallhugging code. Everytime I reverse direction or when getHeadingRadians() nears 3pi/2 or pi/2 It seizes up(it won't move). I'm stick and can use any of the help I can use. Here is the code:

static double direction;	//1 for clockwise or -1 for counterclockwise
.
.
.
//in the onscannedmethod
wallHugging(); //Dunno why I did this, but it works!
.
.
.
//whenever I want to change direction
direction = -direction; // reverse direction when hit
.
.
.
// this is the absolute heading I want to move in to go clockwise or
// counterclockwise around my enemy if I want to move closer to them,
// I would use less of an offset from absBearing (I'll go right toward
// them if I move at absBearing)
public void wallHugging(){
//Pez's wall smoothing code with adaptation
double goalDirection = getHeadingRadians() + Math.PI/2 + direction*Math.PI/2; // I want it to go straight
Rectangle2D fieldRect = new Rectangle2D.Double(18, 18, getBattleFieldWidth()-36,
 getBattleFieldHeight()-36);
while (!fieldRect.contains(getX()+Math.sin(goalDirection)*160, getY()+
        Math.cos(goalDirection)*160)){
	goalDirection += direction*.1;	//turn a little toward enemy and try again
}
double turn =   robocode.util.Utils.normalRelativeAngle(goalDirection-getHeadingRadians());
if (Math.abs(turn) > Math.PI/2) {
	turn = Utils.normalRelativeAngle(turn + Math.PI);
	setBack(100);
} else {
	setAhead(100);
}
setTurnRightRadians(turn);
}

Skipping Turns?

Question: what makes bots skip turns and how do you fix it? --Khanguy 00:12, 15 May 2011 (UTC)

A bot is allowed a certain amount of time each tick for processing. The actual time limit is relative to the CPU and stored in robocode.properties (CPU constant, in nanoseconds). If you take longer than that, you are forced to skip the next tick - or possibly multiple ticks, depending on how far you went over the limit. If you take a very long time, Robocode will stop your bot for the rest of the round (I think?).

So fixing it means keeping the amount of CPU time your bot uses under that limit. The limit on your computer should be very close to the same on all computers because of the CPU constant, but there could be some variance with different JDKs and CPU architectures. In general, a few skipped turns (say 1 every 200 ticks) is not a huge deal, but obviously you want to avoid them as much as possible. --Voidious 00:20, 15 May 2011 (UTC)

what about skipping some 300 ticks consecutively? My nanobot that I working on was skipping a lot of turns nearly every round. --Khanguy 01:21, 15 May 2011 (UTC)

Do you use pattern matcher? Nano-size pattern matcher usually can have at most 45 pattern depth, otherwise it usually can't match fast enough. --Nat Pavasant 01:24, 15 May 2011 (UTC)

actually no, just a reduced linear gun with a nano sized wall hugging movement(its based on wall smoothing). --Khanguy 20:09, 15 May 2011 (UTC)

If you have a version of robocode between version 1.7 and 1.7.2.1, and are running with "-Ddebug=true", then this bug could be what you're hitting. Otherwise, I'd guess it's something in your bot. Add some timing code in your bot to report how long different sections of code take? --Rednaxela 22:03, 15 May 2011 (UTC)

I think I fixed it. The problem here was not an old version of robocode (I run version 1.7.3.0b) but with my class file. I tried to name my robot by only changing the classname. What I did not rename was the .java file. After fixing this I found that my bot stopped skipping turns. I'm now at a loss on how this mistake made me skip so many turns. --Khanguy 23:42, 15 May 2011 (UTC)

A Million and One Questions

I'm learning about the different targeting/movement systems out there, and despite all the research I'm doing I'm left with a ton of questions and I dont have much time to answer them. So, if anyone would take the time to answer my questions it would be greatly appreciated.

1. in segmentation, does the order of segments really matter? in other words, does putting distance before velocity make a difference than if velocity was the first segment in the array?
2. what is the best anti-pattern matching movement out there?
3. can "velocity surfing", as introduced by Savant VS, be as effective as guessfactors when implemented with waves?
4. is pattern matching the best "general" targeting method against wave surfing?
5. is genetic programming or ANN more successful in robocode?

I suppose that these are the most important ones. I'll have more questions up when these get answered. --Khanguy 12:17, 2 August 2011 (UTC)

In reply:

1. No. Put them in any order you want, they are just locations in memory.
2. Simonton's LifelongObsession has a dedicated anti-pattern matching. However, I've tinkered with this myself and it tends to have a detrimental effect on surfing against other targeting mechanisms. If you want to improve your surfing against pattern matching try adding time-based segments, such as distance-last-10, time-since-deceleration and time-since-direction-change.
3. Not sure, there hasn't been an extremely competitive implementation yet so I'd hazard a guess at 'no'. Feel free to give it a try though... I'd love to be proven wrong and there to be another element of robocode that we don't know about yet =)
4. If you go by the scores on the anti-surfer challenge page, then Neural Networks or a virtual gun system made up of several types of guns.
5. ANN definitely, although genetic algorithms can be useful for tuning parameters in code. The main problems with genetic programming (IMO) is that it can take thousands and thousands of generations to achieve a reasonably competitive bot, and you need to run against the entire testbed for each individual in each generation, making the amount of processing power required prohibitive.

Hope this helps. --Skilgannon 14:10, 2 August 2011 (UTC)

On question 1, I have a slightly different answer:

1. in movement: No. Usually the attributes (velocity, distance etc) are in parallel. In targeting, as attributes are put in serie, it can make a difference in case you only regard segments with a minimum number of data. In my bot, I use unsegmented data if the appropriate segment of my first attribute does not have enough data. If it has enough data, I take this, 1-segment deep, data. If the subsegment of my second attribute within the segment of my first attribute has enough data, I'll take that data. The more data you get, the deeper the segmentation becomes. F.e. I have colleted 40 data, evenly distributed over 4 velocitysegments. In velocitysegment 0 the distribution over de distances is 0,2,8,0. If the opponent is in velsegment 0 and distsegment 1 (2 data) I will take all 10 data from velocitysegment only. If he is in distsegment 2 (8 data), I take the better fit data from velocitysegment plus distancesegment, ignoring the 2 data which were recorded at a different distance. As your data get build up, more and more finegrained segmentation will happen, making the gun (hopefully) more accurate. However, this is the situation for me, others have multiple segmentations (light and/or heavy) in parallel, choosing the most succesfull ones based on history. Short said: Choosing the most important attribute for the first segmentation can give a small advantage in the beginning to the middle of the battle, but to the end there will be no noticable difference anymore. --GrubbmGait 18:33, 2 August 2011 (UTC)

Thanks for your quick replies. As I said before, I have a ton of unanswered questions. Here are a few more pertaining to "learning" that constantly pops up on the wiki.

1. what is learning? I believe it to be machine learning in that a gun tries to learn the best firing angle possible in that situation. Am I right?

2. How do you measure the speed of learning?

3. How do you make a targeting method learn fast?

RSVP --Khanguy 19:15, 2 August 2011 (UTC)