Robowiki - User contributions [en]

RoboRumble

2010-05-13T03:27:39Z

Bostonvaulter: fixed link

{{stub}}

The ultimate collaborative effort to have a live, up-to-date ranking of Robocode bots. It uses the power of available Robocoders' computers to distribute the effort of running battles and building the rankings. Currently RoboRumble@Home is hosted on [[Darkcanuck/RRServer|Darkcanuck's RoboRumble server]].

To submit a bot to Darkcanuck's server see [[RoboRumble/Starting With RoboRumble|Starting With RoboRumble]]

== Current Rankings ==
* [http://darkcanuck.net/rumble/ RoboRumble Server Home]
* [http://darkcanuck.net/rumble/Rankings?version=1&game=roborumble 1-vs-1 Rankings]
* [http://darkcanuck.net/rumble/Rankings?version=1&game=meleerumble Melee Rankings]
* [http://darkcanuck.net/rumble/Rankings?version=1&game=teamrumble Team Rankings]

== News ==
<div style="float:right;margin-top:-2.65em;margin-right:2.85em">[[{{fullurl:Template:RoboRumble@Home/News|action=edit}} Edit News]]</div>
{{RoboRumble@Home/News}}

{{Navbox RoboRumble}}
[[Category:Competitions|RoboRumble@Home]]

RoboRumble

2010-05-13T03:26:55Z

Bostonvaulter: added link about submitting a bot

{{stub}}

The ultimate collaborative effort to have a live, up-to-date ranking of Robocode bots. It uses the power of available Robocoders' computers to distribute the effort of running battles and building the rankings. Currently RoboRumble@Home is hosted on [[Darkcanuck/RRServer|Darkcanuck's RoboRumble server]].

To submit a bot to Darkcanuck's server see [[Starting With RoboRumble]]

== Current Rankings ==
* [http://darkcanuck.net/rumble/ RoboRumble Server Home]
* [http://darkcanuck.net/rumble/Rankings?version=1&game=roborumble 1-vs-1 Rankings]
* [http://darkcanuck.net/rumble/Rankings?version=1&game=meleerumble Melee Rankings]
* [http://darkcanuck.net/rumble/Rankings?version=1&game=teamrumble Team Rankings]

== News ==
<div style="float:right;margin-top:-2.65em;margin-right:2.85em">[[{{fullurl:Template:RoboRumble@Home/News|action=edit}} Edit News]]</div>
{{RoboRumble@Home/News}}

{{Navbox RoboRumble}}
[[Category:Competitions|RoboRumble@Home]]

Random Targeting

2010-05-10T21:10:20Z

Bostonvaulter: /* A simpler solution */ added link to musashi trick

A method of [[targeting]] that simply chooses a random angle among the angles that could possibly hit the opponent. Some successful [[NanoBots]] use this firing method. Its implementation is very small and for unpredictable movements, it will give a consistent hit percentage.

== Example ==

<pre>
// Add import robocode.util.* for Utils
// This code goes in your onScannedRobot() event handler.

public void onScannedRobot(ScannedRobotEvent e) {
double randomGuessFactor = (Math.random() - .5) * 2;
double bulletPower = 3;
double maxEscapeAngle = Math.asin(8.0/(20 - (3 * bulletPower)));
double firingAngle = randomGuessFactor * maxEscapeAngle;
double absBearingToEnemy = e.getBearingRadians() + getHeadingRadians();

setTurnGunRightRadians(Utils.normalRelativeAngle(
absBearingToEnemy + firingAngle - getGunHeadingRadians()));
fire(bulletPower);
}
</pre>

== A simpler solution ==

A simpler method is to assume that the enemy is traveling in a circle around you (see [[Musashi Trick]]), which is often true among NanoBots and [[:Category:1-vs-1 Bots|1-vs-1 bots]]. If the enemy is traveling in a circle around you, the maximum distance it can cover before a bullet reaches it is <code>enemy velocity / bullet velocity</code> (in radians). For example, a power 3.0 bullet fired at an enemy going at full speed should be fired at a [[Bearing Offset|bearing offset]] between -8/11 and +8/11.

== Selecting firepower ==

The advantage of a random gun is that it should have a roughly equal hit rate on any type of movement. This makes ideal firepower selection pretty easy to pre-calculate. In the following equations x is the choice of firepower. It is assumed that damage output per tick is the quantity you're interested in maximizing, it may not be.

Bullet damage, assuming firepower > 1:
<pre>D=4*x+2*(x-1)</pre>

The smallest size of a robot, in radians:
<pre>S=36/distance</pre>

The total escape area, in radians:
<pre>A=2*asin(8/(20-3*x))</pre>

Probability of a hit, assuming uniform spread of bullets over A:
<pre>P=min(1,S/A)</pre>

The expected damage from a shot:
<pre>E=D*P</pre>

The heat created by a shot:
<pre>H=1+x/5</pre>

The firing frequency:
<pre>F=1/ceil(H/0.1)</pre>

Expected damage per tick of combat:
<pre>DPS=E*F</pre>

Back substitution to get the expected damage per tick in terms of distance and x and optimization of DPS are left as an exercise for the coder.

== See also ==

* [[Maximum Escape Angle]]

[[Category:Simple Targeting Strategies]]

Guess Factor Targeting

2010-05-10T07:51:09Z

Bostonvaulter: Redirected page to GuessFactor Targeting

#REDIRECT[[GuessFactor Targeting]]

Guess Factor Targeting

2010-05-10T07:50:33Z

Bostonvaulter:

[[#REDIRECT GuessFactor Targeting]]

Guess Factor Targeting

2010-05-10T07:50:21Z

Bostonvaulter: Created page with 'REDIRECT GuessFactor Targeting'

[[REDIRECT GuessFactor Targeting]]

EscapeEnvelope

2010-05-10T07:47:53Z

Bostonvaulter: Redirected page to Escape Envelope

#REDIRECT[[Escape Envelope]]

GuessFactor 2D

2010-05-10T07:47:41Z

Bostonvaulter: added a link

A variation of GuessFactorTargeting which uses elements DynamicSegmentation and [[EscapeEnvelope]] targeting to both enhance exactness of EscapeRadius based GuessFactorTargeting and to give PatternMatching like results against bots not using PerpendicularMovement.

The system works by taking into account maximum distances achievable in all directions in a certain amount of time given its current velocity (EscapeEnvelope / EscapeArea) and rotates that in accordance to the targets current heading. The field is then segmented two dimensionally, which starts at a very low level of segmentation and which proceeds to become finer as more data is collected (DynamicSegmentation). By segmenting this data by velocity and heading if the target appears to be not traveling perpendicularly, a result quite similar to PatternMatching is then achieved.

Firing takes place by selecting the angle which will pass through the highest probablility areas.

While this proves to be just as effective as regular GuessFactorTargeting against RandomMovement, has a much better hit rate against basic patterns, and is easy to modify to attack high or low guess factors.

This is a combination of me being tired of getting only average hitrates against most patterned bots, and the conclusion that the wave surfer vs guess factor challenge is just going to end up in a method of constant second guessing of yourself (he will think I will use guess factoring, so he will move to the low factors, but then he will think im thinking that, and so he will move to the high factors, but he will think im thinking hes thinking that so he will move to low, etc...).
-- [[Jokester]]

Have you tried running a TargettingChallenge with this type of targetting? I am very curious to see the results. -- [[Alcatraz]]

Ah, you just reminded me what my hangup was on this before - if I don't calculate things based on the current heading of the enemy rather than on the angle to me, I didn't see a consistent way to project it back for targeting if the enemy was facing a different direction relative to me.

However, if that proves to not really matter, or there is a good way to map back to the differently proportioned escape envelope, then I think the whole algorithm is MiniBot-able by using AffineTransform cleverly (maybe, unless that way to map it back makes it unhelpful). -- [[Kawigi]]

Well I really need to try using this AffineTransform class. I am currently mapping the escape area as a rectangle (it works fairly well because the unreachable areas just never get incremented) and then basically rotating the entire battlefield so that the enemy has a heading of 0, only changing my relative point. I then calculate the best angle based on that, and reverse the process to get the exact angle I need to fire at. If I can change this around and be able to rotate a polygon around a position I will be able to drastically reduce code size and use my algorithms for the definitive shape. -- [[Jokester]]

Ok, so I basically have GF split into 3 sections:
# Getting information
# Segmenting information
# Selecting angle

In my opinion, 2 is the heart and soul of a good GF gun, and so that is what I am working on. At the moment, I have a Factor class which is basically my wave, but which contains all information I might want to segment on. A major plus of my 2D system is that it removes the need to segment on heading, velocity, etc, since that is directly applied on my information (although I am still keeping track of them in my Factor class just in case). I am incredibly fond of the [[WikiTargeting]] idea, and am currently trying to implement it, but I need to come up with a good way to decide which segment is best. The three ideas that I have been working with are the most even split (closest to 50/50), the best entropy split, or there is the obscure point split that is mentioned on the WikiTargeting page (choosing the one with the highest sum peaks??? 865 vs 687?). my current segmentations are:
* Bullet Power
** Probably unnessecary
* Distance
** Probably unnessecary
* Target Velocity
** Probably unnessecary
* Target Heading
** Probably unnessecary
* Target Acceleration State
* Time since last reverse
* Time since last bullet
** Used for my every tick factors
* Near center/wall/corner
If you can think of any other good ones that would be great. Then all I do is select the best suited factor and fire on it.

All this work with segmentation has made me think about an exploitation of highly segmented guns. To try to flatten your profile not just by GF but by segmentation, so the main aim is that they dont have enough data in their segments. It will probably turn out to be wildly inefficient and not give much return (mostly because to have best effect you need to know the segmentation of the opponent), but it could be interesting to watch the bot go around through all possible velocities, acceleration states, headings, etc.
-- [[Jokester]]

This (segmented flattening) is actually what most WaveSurfer's do. -- [[PEZ]]

It would be *very* interesting if you were able to find a practical implementation of WikiTargeting. I'm following this with great interest. Keep us posted! --[[Vic]]

Well I am still toying with the efficiency problem, but I have a few ideas. The processor power required is exponentially related to the number of segments there are to deal with, and the way you decide which implementation to use. I am currently working on two versions together, an ideal version of WikiTargeting if it had all the processing in the world, and a very basic version which splits data as equally as possible and doesnt go back to check the accuracy of early segments. One thing that I will need to test is how nessecary segmentation is in the face of GuessFactor2D, because it is mapping guess factors based on all of those variables. Ive currently been splitting my time between about 12 different projects, so over the next week or so I am going to spend my robocoding time just on this targeting to try to get it finalized. --[[Jokester]]

Looking back at my own WikiTargeting ramblings, the 'ideal world' version (as you call it) *is* available if you are willing to use prepopulation. You can write an offline program that converts raw data into a bunch of dynamically segmented SuperNodes. This is in fact the initial WikiTargeting way. The existence of SuperNodes has allready been proven, so this should work. Although there are those in this community that do not approve of prepopulated guns.

I think your second version may not work so good, unless you have come up with an ingenious solution. I have thought about such an implementation too and using that scheme you will either segment too slowly, or you do not have enough waves per node. --[[Vic]]

[[Category:Targeting Discussions]]

Melee Strategy

2010-05-10T07:46:12Z

Bostonvaulter: /* Melee radar */ added link to melee radar implementations

{{cleanup}}

Building a successful [[melee]] bot can be much harder than creating an effective [[1-vs-1]] bot. This page outlines some of the strategies you can use to make your melee bot stronger.

== The timeline of a melee battle ==
=== 10 bots on the field ===
; The bots in bad starting positions die right away. Hope you're not one of them.
If there is someone close to you, it had better die before you. Most good bots will turn and move away from other bots or from the center in general right away, so if you have some kind of targeting that shoots at the path of least resistance, this is where you'll notice it, but a semi-linear targeting will probably work for that first few seconds in the match.

=== 6-7 bots on the field ===
; Fighting over corners and trying not to get pushed into crossfires.
You'll be happier if you're targeting one bot and no bot is targeting you. You should be able to hit most of the bots you'd reasonably want to target at this point, and you won't be successful with a hit rate of less than maybe 25-30% at this point.

=== 3-4 bots on field ===
; Everyone stays in their corners and snipes at each other. Try to get the other guys to target each other instead of you.
This is where you'll be the happiest with solid targeting. Here's why: when you're down to 4 bots, as David pointed out, there's a ''really'' good chance that you're all in corners. If the next bot who dies is the one across from you (the one you probably weren't targeting), you are probably next, because you're the most obvious target for ''both'' of the remaining enemies.

=== Duel ===
; The [[1-vs-1]] fight at the end of a melee battle.
It should be obvious why targeting is important here. It's your gun against their movement.

=== What it means ===

In reality, these stages aren't something you normally put into code when making a melee bot, they're observations about what a battle will look like between several good melee bots. The fact that these stages are defined in terms of position and movement says a lot about what is important in melee. The reason these stages are important to understand is really so that you can analyze your melee bot's performance if you put it in a battle with other bots of a similar level.

== How to put together a good melee bot ==
As with any kind of new robot, the main thing that's useful when making a new melee robot is to have some kind of idea you want to try. It can be original or not, it can be a spin-off of what other people have done, or it could just be in general that you want to try making a melee bot.

Nowadays, most people have some experience with 1-on-1 bots before they go too deep into melee. In reality, melee is just like 1-on-1, except that there's something that supersedes 1-on-1 movement (which is moving in such a way as to not be hit often) - moving in such a way that you aren't being shot at!

=== The theory of melee movement ===
You'll dodge every bullet if no one is firing at you, and so most melee movement is centered in one way or another around not getting attacked. This is what makes melee movement so dang interesting. If it is inevitable that you will be targeted, then you can start worrying about just not being hit.

In discussions with (melee legend) [[ABC]], I remember summarizing these two movement goals combine into the balance between "being in the right place" (not being shot at) and "moving in the right direction" (not being hit). Since you can only move in one direction, sometimes you have to choose to either mov toward the right place or move in the right direction. Since different bots prioritize these differently, some will be extremely predictable and easy to hit, but it doesn't matter until someone shoots at them. In fact, in theory, as long as no one is shooting at you, the only reason you really have to keep moving is to make sure they keep not shooting at you (until they're shooting at you again, which would be nice to be able to magically determine).

=== Common ways of implementing melee movement ===
There are lots of ways people accomplish the goals of not being targeted and not being hit. Some common examples:

* [[AntiGravityMovement]] 
:In AI I've heard this generalized as using "repulsive fields". You could also combine it with attractive fields if you want, but there's rarely a real reason (same goes for tangential fields, for which there is a reason, but the actual implementation is hard to really get right in a pure anti-gravity force-vector sort of way). The basis of it is just like in physics - you define a set of points that have an antigravitational (repulsive) force on them, you add all the force vectors together, and you let them "push" you in whatever direction they push you in. Normally other bots and walls are assigned forces. Sometimes the center of the field has a generic force as well, or even the guessed positions of bullets. A classic example of [[AntiGravityMovement]] is [[TheArtOfWar]]. A simpler implementation is [[Graviton]], but simpler in this case doesn't necessarily mean more clear (same goes for [[Escape]], which is a more convoluted bot based on [[Graviton]]). [[Hanji]]'s page has a very stereotypical, very clear implementation of antigravity which might be helpful if you are trying to get into it. The biggest challenge in getting [[AntiGravityMovement]] right is weighting all the forces effectively, especially when there are more or fewer points on the field (maybe the walls have to push harder when there are more bots on the field pushing you toward them?).

* [[CornerMovement]] 
: In the early days of Robocode, one of the frustrating things about trying to excel in melee was that the bots that seemed to do the best in battle did stupid little patterns in the corners of the battlefield. This came from the general observation that the bots that lasted to be one of the last standing were the ones that got to the corners the fastest. While this isn't really always true, there are probably fewer bots near you in a corner than in the middle, so the technique works - just go to the nearest corner, keep moving, and kill anything that's trying to take your corner from you. I experienced frustration with this movement when I would watch [[SandboxLump]] with his stupidly simple movement kill [[Coriantumr]] in so many of my tests. Out of my frustration came [[Lib]], the most complex [[CornerMovement]] ever put into a [[NanoBot]] (I assume that's still true, it at least was at the time). Traditionally, using [[CornerMovement]] will make you specialized as a melee bot, because it tends to work better against the best melee bots than against mediocre ones.

* [[Pattern Movement]] 
: Alot of quite good nano melee bots just dance around in a star shape, or triangle or square. Some of these go in a straight line for awhile first (until they hit a wall or something), so it's closer to a type of corner movement than anything. The virtue of this movement is that you don't move around too much, so you are less likely to have new bots start targeting you because you move into their range, and it does well against the horde of melee nanos with something related to linear or circular targeting (because you change directions relatively often). [[Gem]], [[Infinity]], [[KomoriNinja]] and [[Trigon]] are good examples of this movement.

; [[MinimumRiskMovement]] >
: On the surface, this looks like just an implementation of [[AntiGravityMovement]], and maybe the difference is just nitpicky semantics to some, but I think the way it is implemented is different enough that the only similarity is really the basic fundamentals of melee movement. It also seems much more versatile than [[AntiGravityMovement]] and is also less likely to converge at some "happy" local minimum. As I am biased, I think that the best, clearest implementation of [[MinimumRiskMovement]] is in [[Coriantumr]] and [[Shiz]], although [[HawkOnFire]]'s implementation is also available now and it is just as effective and maybe slightly more basic. There are two basic parts to [[MinimumRiskMovement]]:
:* A Risk Function - Determines how good or bad a point is to go to.
:* A Point-generating function - generates candidates to try in the risk function.
:Then you just go to the candidate point with the lowest risk (or highest benefit, although MaximumBenefitMovement probably has more place in [[Teams]]). Randomness can assist in either function just as effectively. Also, as an interesting tweak, you need to decide to look for a point to go to constantly rather than only when you reach the last point you were going to. Both strategies have merits - you might get into a rut if you keep changing your mind on points, but you can also more quickly react to changes in the battlefield.

; [[1-vs-1]] Movement
: If your bot is good at close combat, you might consider chasing one robot at a time with that movement. Chances are that if you are close to one robot, you're far from others (because who's going to go running towards two other robots?) [[DoctorBob]] is very successful in this, and it's also one of the reasons [[Tracker]] doesn't do too bad in a battlefield full of sample bots at least.

=== Things to think about in your movement ===
; Being far away from other bots
: This one of the easier things to test for, of course, once bots are so far away, it doesn't matter as much if they get further. That's why using the inverse square of the distance to each robot works so well (the threat approaches zero at some point). This will likely keep you out of the action.

; Moving perpendicularly/one-on-one-like to other bots
: Especially bots that are close to you.

; Don't hit walls or other bots too much
: It might be tempting ;-) This is possibly a bigger deal in melee, just because you're going to be close to other bots and to the walls alot more than in one-on-one.

; Stay out of the middle
: People always say this, but in reality it's ok to be in the middle if the battle is still big and all the other bots are on the outside. However, if you're still in the middle with 4 or 5 bots left, you won't likely last long.

; Don't stay in the same place for too long
: Just as in 1-on-1, this can be quick death. I don't care how great that spot is, someone will get close enough to it to put you in danger in not too much time.

; Battle dynamics change constantly
: Be capable of adjusting and changing quickly, and don't try to plan too far into the future.

=== Guess who will fire at you ===
''Note - This is a little more advanced of a topic in melee movement, and it's a little hard to explain clearly, but it's also not impossibly hard to implement. It's also the main secret of the movement in [[Coriantumr]] and [[Shiz]]. [[FloodHT]] does it as well, but its point-generating function is bad, so it doesn't really matter :-p I'm not sure if anyone has really tried too hard to do this before.''

Looking at the list of ways one could pick a target, the one you have the most potential control over is whether you're the closest target for any other bot. If I want to pick which point is the best one to be at, a big part of that is counting for each bot how many other bots are closer to them than me. If 0 or 1 bot is closer to that robot than it is to me, that means it's likely to be aiming at me. Combine that with the possible knowledge that that bot has hit you recently, or that you're shooting at that robot, you have a pretty good guess as to whether that bot is likely to be firing at you if you were (or are) at that point.

There are at least two applications of this information:
# You want to be at the point where the fewest robots will target you.
# You only have to worry about being hard to hit to the robots that are likely to target you (in other words, the direction you move in to get to a given point only matters relative to bots that are likely to target either that point or your current location).

== Little melee tweaking notes ==
A few things that might just get you up a few spots in the rankings:

=== Melee radar ===
''For Implementations see: [[Radar#Melee_radars]]''

What you do with your radar really depends on what your targeting strategy is, and whether or not you want to fire blind (firing blind means you don't fire when you can actually see your enemy, but rather in your general run loop or something). If you just spin your radar constantly, you almost need to fire blind, otherwise your gun won't have time to turn before you fire. However, I find (again, if your gun doesn't depend on a spinning radar, like some melee pattern-matchers do) that firing blind reduces my hit rate by a little. I suggest (particularly if you're using a guess-factor gun in melee) using a melee radar lock, which is a trick I learned from [[PaulEvans]] (so it must work!) A melee radar lock is spinning your radar until you're getting close to firing, and then lock on your target as if they were the only bot on the field for a couple ticks until you fire. Plus, if you have a radar lock in your code, you can also use it for one-on-one :-)

=== Melee firepower ===
Alot of hitting happens early in a melee match, but by the end you can be pretty well drained of energy. Some people take the survivalistic element of melee to mean they should always fire low-powered bullets. This is only partly true - you will likely start the melee battle close to other bots. So close, in fact, that you are very likely rack up alot of hits (either for or against you) in the first 5 seconds of a match. Don't be shy about firing bullets that are more than powerful enough to finish a bot off if they're really close to you (because you still want to finish them off if they hit you or someone else before your bullet reaches them, and if you're REALLY close, that's likely to happen). I've seen some smaller melee bots (I think [[Graviton]] and [[Troodon]] were two of them) that even multiply their firepower by getOthers(). I also think that you shouldn't make the mistake of having too "merciful" of firepower in the final stages of the battle (meaning you should be aiming to kill when you're shooting at a low-energy target at any point of the battle).

=== Picking a target ===
There are so many heuristics that can be dreamed up for this, but one of the easiest and most effective is to simply target the closest enemy. While this is the best ''general'' guideline, it might be beneficial to take a few other things into consideration:

''Who has the lowest energy?'' There are a few reasons you might want to target them:
* To get the kill bonus.
* If they are at least sort of close to you, and they are in a "safer" part of the battlefield, you might be able to take their place if they die :-) If your movement allows you to get closer to robots with lower energy, you might be more likely to do this.
* So you can outsurvive them! You get something like 100 points for every bot you outlast in a round. You'd hate to see a robot that had 5 energy when you had 60 end up dying after you because no one shot at it when you could have.
* If you have a good risk function your bot will attack a low energy bot in case it has a good position on the field so that your bot will get there (important if there are around 4 to 6 bots left).

''Who keeps shooting at you?'' There are two ways to avoid getting shot at - get them to shoot at someone else, or take them out. Yes, killing someone can help you conserve energy!

Try not to thrash between enemies too much, especially when you're ready to fire. If you're only using distance to pick a target, try only switching targets if the new target is 100 pixels closer, or 10% closer, or something. If you have some other kind of "score" technique to picking a target, something similar could be used. Thrashing can cost you, especially early in a battle. Another good technique is to not switch targets if your gun is almost cool (unless your target is dead, of course).

There's a theory that the reason you pick the robot closest to you is because you're more likely to hit them. If you're more likely to hit someone else, maybe you should shoot at them. Of course, don't forget the advantages of having only low-energy (or dead!) bots close to you.

== Enemy management ==
If you're trying to convert a 1-on-1 bot to a melee bot, you'll find out quickly that all the little assumptions you used to make when you coded your 1-on-1 bot are wrong. It can be a big challenge to effectively store volatile information about your enemy (like current position, heading, velocity, etc) as well as persistent information about your enemy (like targeting information). One of the big challenges is how to specify that a given enemy is dead. I stumbled on a great way to do this when I was working on [[Coriantumr]], which was to have an volatile object (class EnemyInfo) in a Map that has position, heading, velocity, and all the obvious stuff in it, as well as a list of waves (note - all these things ''should'' go away between rounds). This map doesn't have to be static (although it probably is for codesize reasons), because it's recreated every round. In onScannedRobot, I check to see if the robot I'm scanning is in the map, and if it isn't, I put it in there. Then I get the EnemyInfo object and operate on it all over onScannedRobot. onRobotDeath removes that robot's object from the map if they exist (so the robot no longer exists when I don't care about it anymore). Meanwhile, I have a different map which maps the name to the guess factor stats which is static and isn't reinitialized between rounds.

== Targeting algorithms in melee ==
=== [[HeadOnTargeting]] in melee ===
Always a good place to start. On a related note, I've heard of melee targeting which targets the rolling average of the robot's position, since it is common for a robot to stay near the same place for awhile. Not sure how this really compares in general to just firing right at the target.

=== [[LinearTargeting]]/[[CircularTargeting]] and variants ===
You can go far with some kind of percent-of-linear targeting, or using circular targeting in melee. It has been observed that if you are close to an enemy, you have really good odds firing with linear targeting, and if they're further away (say moving around in a corner or something), you have pretty good odds with head-on or somewhere near that. Take a look at [[Infinity]] for a really elegant solution to this observation. Another thing that might work well is velocity-averaging. Some more observations could certainly be collected to create a generally good melee gun that is simple to understand and code and is *very* resiliant to missed scans.

=== [[PatternMatching]] in melee ===
Be careful to make your targeting algorithm resistant to not having constant scans. If you spin your radar, you will get a scan on a given robot every 8 ticks on average. Occasionally (ok, actually somewhat often), you'll scan a bot two ticks in a row, and that should throw your targeting off. Often, you'll scan the robot again after 7 or 9 ticks. If your targeting algorithm absolutely requires scans every 8 ticks, you'll have to make it realize that the world isn't perfect. In my opinion, pattern-matching has been slowly becoming obselete in one-on-one in its purest form (note that there are ways of making it last in the realm of random movement), but is still definitely alive and kicking in the melee world, if only because melee isn't as well developed.

=== [[GuessFactorTargeting]] in melee ===
[[FloodMini]] from the start has had a wave implementation that was really good about missed scans, mainly because its radar was far from perfect. The same idea is in [[Coriantumr]]'s gun, which is to interpolate missed scans linearly and check at each interpolated position/time if the wave hits. This is probably the trickies part, along with how to store the waves (see the Enemy Management section above). In general in melee, you're pretty safe firing a wave on every scan of a robot, not just when you fire at them, but realize that robots might be moving different relatively to you if you're not shooting at them (or likely to shoot at them anwyays). Segmenting on distance and possibly battle size can help compensate for this problem, as well as segmenting on lateral direction (are they moving roughly perpendicular to you, toward you, or away from you?) Acceleration segmentation can be a little harder to do in melee, since you aren't getting consecutive scans for all of your waves, but I've observed that if the sign of the enemy's velocity is opposite of the previous scan, they're probably accelerating (unless they are already at velocity 8).

Also, I recommend using a melee radar lock for [[GuessFactorTargeting]] (see Melee Radar above).

For any of these techniques, you should consider making sure you don't fire off the battlefield at a or in a direction that can't possibly be reached by your target. This sounds obvious, but I don't know how many times I've seen a robot aiming at another robot that was moving toward a wall, and the shooting robot just shot right into the wall, which is a complete waste of a shot. This is one of the improvements I made in [[Coriantumr]] from 1.0 to 1.1.

== Evaluating your Melee bot ==
Before I get too far into this, I want to emphasize that the number one way of figuring out where you can improve is by critically watching the battles. The first thing to do is to create a test bed. Find a bunch of bots that are at least in the same neighborhood as you as far as ability, some better and some worse. I also make a text file where I log battles and what tweaks I made between them. Of course, don't give too much credit to the scores, since they often vary wildly. If you start to beat your test bed consistently, upgrade it.

It is a good idea to keep track of how long you're staying alive. I like to add this code into my bot for testing:

<pre>
//global declarations:
static int[] finishes;
.
.
.
//beginning of run():
if (finishes == null)
finishes = new int[getOthers()+1];
.
.
.
//somewhere:
public void onWin(WinEvent e){onDeath(null);}
public void onDeath(DeathEvent e)
{
finishes[getOthers()]++;
for (int i=0; i<finishes.length; i++)
out.print(finishes[i] + " ");
out.println();
}
</pre>

This will print out a list of wins, 2nd places, 3rd places, etc. at the end of each match. Obviously, you want to maximize the wins ;-) Of course, what you want to do first is make sure this gives a regular, smooth distribution over time. You can analyze where some of your weaknesses (relative to the stages to a melee battle at the top) by where the highest numbers are. For instance:
* If you have alot of last and next-to-last finishes, maybe you don't do well at close quarters or get out of tough starting situations very well. Try to get to the best place you can and get other bots to target each other instead of you.
* If you are dying alot in a part of the battle where there are still alot of bots, but it's not the beginning really, you might just need to be more random/harder to hit. In a standard 10-bot battle, this is probably about 6th-8th place finishes.
* If you tend to have hugely more 5th and 6th places than 3rd and 4th, it could be you don't get out of the middle soon enough.
* If you have way more 3rd places than 4th or 2nd, it probably means that you're not good at getting rid of one of the guys closer to you at the end of a battle.
* If you have way more 2nd places than 1st, it could be that you have lower 1-on-1 strength than the other bots. On the other hand, it could be that you're barely surviving before that. Watch a few battles to figure it out. I see HawkOnFire finishing off Shadow at the end quite a bit simply because it has 4 times as much energy when they get down to 1-on-1.

Some tips:

* Just like in 1-on-1, every tweak counts, even the tiniest change to your power management can be catastrophic or miraculous.
* Make up other techniques to help you test the parts of a battle that you're not as good at. For instance:
** If you do well getting into the last 4, but have trouble making into the last 3, you could try tweaking in 4-bot battles, or you could try tweaking in 10-bot battles on a 2000x2000 battlefield (which might have a similar strategic effect). This can also expose what your bot does if it can't see anyone (which only rarely happens on a 1000x1000 battlefield, probably only when it gets down to 1-on-1).
** If you have an abnormal amount of last place finishes, you could try testing on a point-blank melee (10 bots on 400x400? That's just like doing the start of a battle for the whole battle). If you try that with today's top melee bots, you'll find that [[Coriantumr]] and bots with iterations of his movement are the best at this, hands down (let me know if you can find anyone who can beat it). Again, this also might expose some of the other problems you have with your movement that make your bot too specialized (or just less versatile).
** If it's that stage between the beginning and half way that gets you down, the point-blank melee thing can also help. Try even upping the stakes and see how you perform at close range (say 20 bots on a 400x400 battlefield. This can be pretty funny to watch).
* You might want to delete saved data if you test with bots that save data to disk ([[SandboxDT]] or [[SandboxLump]], for instance).
* If you're looking at your [[RoboRumble]] problem bots, realize that some of them might be a problem bot for you because they do better against lots of other bots than you do, not because they're a direct problem for you. Also, PBI's are deceptively low in melee, because there are 8 other bots in every battle who affect the performance for each of you.
* '''''WATCH YOUR BOT.''''' Get a feeling for your bot's behavior. Worked fine for [[Aleph]].
* Make a battle with 10 of your bot. If the scores are somewhat similar, that's good. If the scores are hugely different, luck might play a factor in your bot's score. You might want to tweak a little bit in that case.

== Understanding Bots ==
I think we should add a few tutorials or in-depth descriptions of a few good melee bots (especially the open-source flavor). Maybe a few pages like:
* [[/UnderstandingCoriantumr]]
* [[/UnderstandingHawkOnFire]]
* [[/UnderstandingGruweltje]]
* [[/UnderstandingNimrod]]
* [[/UnderstandingInfinity]]
* [[/UnderstandingLib]]
* [[/UnderstandingTroodon]]
* [[/UnderstandingDoctorBob]]
These can be filled in by the authors or anyone else who has taken time to understand them (or feel free to describe your own).

[[Category:Strategy]]
[[Category:Melee]]

GITS/Targeting/Source

2010-05-09T09:48:29Z

Bostonvaulter: removing source code category since this currently doesn't have any source code

'''GITS Targeting (Source)''' - from version 0.5-051509
----
I took down the source because I'm going to rewrite the GhostGun using classes to extend the plug-ability. I will post that when I get a (most likely horrible) working version.

Radar

2010-04-25T03:49:17Z

Bostonvaulter: /* Gun Heat Lock */ Made it more clear that it is checking if this robot has low gun heat

'''Radar''' is one of the most vital components of your robot. Without it, [[targeting]] is effectively impossible and [[movement]] is purely random. Just as with movement and targeting, there are many simple and complex algorithms for radar control. In most robots the radar takes up the smallest portion of code.

[[Image:Radar.jpg|thumb|right|300px|Radar in [[Robocode]]]]

== Technical Information ==
A radar in Robocode can turn a maximum of 45° or π/4<sup>rad</sup> in a single tick. The radar scans robots up to 1200 units away. The angle that the radar rotates between two ticks creates what is called a radar arc, and every robot detected within the arc is sent to the <code>onScannedRobot()</code> method in order of distance from the scanning bot. The closest bot is detected first, while the furthest bot is detected last. By default, the <code>onScannedRobot()</code> method has the lowest [[event priority]] of all the event handlers in Robocode, so it is the last one to be triggered each tick.

== 1-vs-1 Radars ==
1-vs-1 radars are the smallest of the bunch and many can get a scan in every turn, producing a perfect lock.

=== Spinning radar ===
A simple spin of the radar, this is very ineffective in one on one, but still used in [[NanoBot]]s.

Here is an example of this type of radar:
<pre>
public void run() {
// ...

do {
turnRadarRightRadians(Double.POSITIVE_INFINITY);
} while (true);
}
</pre>

=== The infinity lock ===
The infinity lock is the simplest radar lock and it is used frequently in [[NanoBots]]. It has the disadvantage of "slipping" and losing its lock frequently. But is a much better alternative to the Spinning radar in one on one combat.

Here is an example of this type of radar:
<pre>
public void run() {
// ...
turnRadarRightRadians(Double.POSITIVE_INFINITY);
}

public void onScannedRobot(ScannedRobotEvent e) {
// ...
setTurnRadarLeftRadians(getRadarTurnRemainingRadians());
}
</pre>

=== Perfect radar locks ===
There are several "perfect" radar locks that will not slip once they have a lock.

==== Narrow lock ====
Point the radar at the enemy's last known location. This results in a thin beam which follows the enemy around the battlefield. Many recent one on one bots use this type of radar. This radar lock is similar to, and considered an enhancement on the wide radar lock described below.

If implemented correctly, it is not possible for the enemy escape this lock. A robot's width is 36px (that's 18px from the middle) and it can only move at up to 8px/turn, so if your beam is pointing at its centre, it won't be able to move entirely out of it in one turn. However, a robot will only automatically scan for enemies if its radar is turning, which might not happen if you are using a Narrow Lock and your enemy decides to stay still for 2 turns. For this reason, if you decide to use an unmultiplied Narrow Lock, you must call <code>scan()</code> yourself to avoid losing lock. Furthermode, if you skip turns, your enemy might be able to move out from your radar beam before you recover.

To overcome these issues, a Narrow Lock is often multiplied by a factor (as described below) to keep the radar moving and ensure the enemy does not escape the scan arc.

Here is an example of this kind of radar:
<pre>
import robocode.util.Utils;

public void run() {
// ...

turnRadarRightRadians(Double.POSITIVE_INFINITY);
do {
// Check for new targets.
// Only necessary for Narrow Lock because sometimes our radar is already
// pointed at the enemy and our onScannedRobot code doesn't end up telling
// it to turn, so the system doesn't automatically call scan() for us
// [see the javadocs for scan()].
scan();
} while (true);
}

public void onScannedRobot(ScannedRobotEvent e) {
double radarTurn =
// Absolute bearing to target
getHeadingRadians() + e.getBearingRadians()
// Subtract current radar heading to get turn required
- getRadarHeadingRadians();

setTurnRadarRightRadians(Utils.normalRelativeAngle(radarTurn));

// ...
}
</pre>

The following factors affect the behaviour in the following ways (eg. <code>factor * Utils.normalRelativeAngle(radarTurn)</code>)
* 1.0 - Thin radar lock. Must call scan() to avoid losing lock. God help you if you ever skip a turn.
* 1.9 - Radar arc starts wide and slowly narrows as much as possible while staying on target.
* 2.0 - Radar arc sweeps through a fixed angle. Exact angle chosen depends on positions of enemy and radar when enemy is first picked up. Angle will be increased if necessary to maintain a lock. Most used corrective factor.

==== Wide lock ====
The Wide Radar Lock tries to scan a fixed distance to either side of the enemy. It was to the best of knowledge created before the Narrow Radar Lock. Its constant motion means the radar will not slip as long as you don't miss any turns.

Here is an example of this type of radar:
<pre>
import robocode.util.Utils;

public void run() {
// ...

do {
// ...
if (getRadarTurnRemaining() == 0.0)
setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
execute();
} while (true);
}

public void onScannedRobot(ScannedRobotEvent e) {
double radarTurn = Utils.normalRelativeAngle(
// Absolute bearing to target
getHeadingRadians() + e.getBearingRadians()
// Subtract current radar heading to get turn required
- getRadarHeadingRadians() );

// Distance we want to scan from middle of enemy to either side
double extraTurn = Math.min(Math.atan(36.0 / e.getDistance()), Math.PI/4.0);

setTurnRadarRightRadians(radarTurn + (radarTurn < 0 ? -extraTurn : extraTurn));

// ...
}
</pre>

You can replace <code>36.0</code> with any distance you want covered.

== Melee radars ==
Melee radars are more complex and take up considerable more room inside a robot. Since the field of opponents does not usually fall within a 45° area, compromises must be made between frequent data of one bot (e.g., the firing target) and consistently updated data of all bots.

=== Spinning radar ===
Just as with one on one, there is the generic spinning radar. This is the most used melee radar as it is by far the easiest to implement.

<pre>
public void run() {
// ...

while(true) {
turnRadarRightRadians(Double.POSITIVE_INFINITY);
}
}
</pre>

==== Corner Arc ====
A variation on the spinning radar, if the robot is in a corner it scans back and forth across the 90 degree arc away from the corner, as not to waste time scanning where there cannot be any robots. Typically, this is used only in smaller melee robots, which do not have room for a more complicated radar system. Melee bots with room tend to use one of the implementations below.

=== Oldest Scanned ===
This type of melee radar spins towards the robot it hasn't seen in the longest amount of time. Here is an example of this type of radar.
<pre>
import java.util.*;
import robocode.*;
import robocode.util.*;

// ... Within robot class

static LinkedHashMap<String, Double> enemyHashMap;
static double scanDir;
static Object sought;

public void run() {
scanDir = 1;
enemyHashMap = new LinkedHashMap<String, Double>(5, 2, true);

// ...

while(true) {
setTurnRadarRightRadians(scanDir * Double.POSITIVE_INFINITY);
scan();
}
}

public void onRobotDeath(RobotDeathEvent e) {
enemyHashMap.remove(e.getName());
sought = null;
}

public void onScannedRobot(ScannedRobotEvent e) {
String name = e.getName();
LinkedHashMap<String, Double> ehm = enemyHashMap;

ehm.put(name, getHeadingRadians() + e.getBearingRadians());

if ((name == sought || sought == null) && ehm.size() == getOthers()) {
scanDir = Utils.normalRelativeAngle(ehm.values().iterator().next()
- getRadarHeadingRadians());
sought = ehm.keySet().iterator().next();
}

// ...
}
</pre>
With above code, the radar will spin past every bot, and then reverse it's direction until its passed all bots, then repeat. If the spin takes more than 4 ticks, the radar will continue spinning like the spinning radar above. This kind of radar is used in many top bots include Shadow and Phoenix. This kind of radar should be used unless you need a melee radar lock or your targeting system requires you to have enemy scans every 8 ticks.

=== Gun Heat Lock ===
A technique developed by [[Paul Evans]]/[[Kawagi]] for [[SandboxDT]]/[[FloodHT]]. This radar locks onto a target when this robot has low gunheat. Normally this is best for melee robots which use GuessFactor Targeting.
<pre>

public void run() {
// ...
setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
}

public void onScannedRobot(ScannedRobotEvent e) {
// ... your own target selection
double absoluteBearing = getHeadingRadians() + e.getBearingRadians();
if (isCurrentTarget && getGunHeat() < 0.5) { // Lock for 5 ticks
setTurnRadarRightRadians(3.5 * Utils.normalRelativeAngle(absoluteBearing - getRadarHeadingRadians()));
else
setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
}
</pre>
The code above uses a Narrow Lock but the simpler Infinity Lock works just as well. For a narrow lock, it is recommended you multiply by a large factor to continue scanning other robots while locked.

== Notes ==
For most of these radar locks, you will need to add one of the following to your <code>run()</code> method:

<pre>
setAdjustRadarForRobotTurn(true);
setAdjustGunForRobotTurn(true);
setAdjustRadarForGunTurn(true);
</pre>

[[Category:Code Snippets]]
[[th:เรดาร์]]

Robocode/FAQ

2010-04-07T09:41:32Z

Bostonvaulter: /* Installing and using */ fixed numbering issue

Frequently asked questions about Robocode.

== [[Robocode/Download|Installing]] and [[Robocode/Getting Started|using]] ==

; '''I can't install Robocode.'''
: First make sure you have [[Robocode/System_Requirements|Java installed]] on your computer. To check it, run the command: <code>java -version</code> It should execute and show a version 1.5 or higher. If not, go to Sun site and download the last version. After, make sure you have downloaded the correct file (<code>robocode-setup-X.X.X.jar</code>, where <code>X.X.X</code> is the version number). Execute the file by double-clicking on it, or if you want to do it manually, execute the following command: <code>java -jar robocode-setup-X.X.X.jar</code>. It will launch an installer that will install Robocode. The installer creates the icons to execute Robocode, but you can execute it manually by running the <code>robocode.bat</code> or <code>robocode.sh</code> file in the <code>/robocode</code> directory.

; '''I have downloaded a robot from the Web, but I don't know how to use it, because it doesn't appear anywhere.'''
: By default, robots are read from the <code>/robocode/robots</code> directory. You can select "Robot -> Import Downloaded Robot" to copy a robot JAR to this directory from another location. Also, you can configure Robocode to read robots from additional locations using the Properties dialog.

; '''What do I have to do to see the source code of a robot?'''
: You can do two things. The first option is to open the Editor Window in Robocode and use the command in the File menu. The second option is to open the robot ".jar" file with a zip utility and find the source code there (assuming, of course, the robot is open source).

; '''Can I play Robocode online?'''
: Robocode is not an "online" game, so you can't, for example, share a battle with your friends in real time over the Internet. But you can upload your bots to places like [http://sites.google.com/ Google Sites] or [[RobocodeRepository|Robocode Repository]] and join any of the [[:Category:Competitions|existing competitions]] such as [[RoboRumble@Home]], or organize one with your friends.

; '''I have seen that many bots are packaged into ".jar" files. How do I package my bot?'''
: Select, "Robot --> Package robot for upload" from the menu, then enter your robot's details when prompted.

;''' When I test my bots, Robocode is slow. Is there a way to execute the battles faster?'''
: When you are testing your robot, you want to execute many battles in a short time. Minimize the Robocode main screen to make it execute the battles at full speed.

; '''I get this error when trying to start Robocode: "'JAVA' is not recognized as an internal or external command, operable or batch file"'''
:
:# Find where you installed Java. The default position at: <code>C:\Program Files\Java\jre6\bin</code>
:#: Yeah, find the path to the bin directory in the java directory.
:# Copy all that.
:# Right click on My Computer and select Properties. The System dialogue should have appeared. On Vista, choose "Advanced system settings" in the sidebar. On XP, choose 'Advanced' tab.
:# Now, click on "Environmental Variables" which is a button at the bottom right.
:# Under the category "System variables" which is the lower box, scroll down to "Path" and double click on it.
:# In "Variable value", go to the end of all that text and paste in the path of your java\bin directory. The one you copied earlier. Then put a semicolon <code>;</code> Here's what my Path value looks like: "set PATH=%PATH%%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Java\jre6\bin;"

== [[Robocode/Game Physics|Game physics]] ==

; '''What is the difference between frames and ticks?'''
: A tick refers to one unit, which is also called a Turn in Robocode. During one turn, you may perform one action as a Robot, or multiple (independent) actions as an AdvancedRobot. A frame is a unit of drawing to the Robocode client interface. If you are processing turns slowly, you will get one frame per tick / turn. However, if you up the turns per second beyond your computer's ability to render the frames, you will miss some frames of animation. This won't affect the robots' behavior, unless you foolishly added code in your <code>onPaint(Graphics2D)</code> method that alters your bots behavior. In that case, your bot will behave differently depending on whether or not the Paint button has been enabled, and if the framerate can keep up with the turnrate.

; '''Can I fire bullets with power higher than 3.0 or lower than 1.0?'''
:No and yes. You can't fire bullets with power greater than 3.0, but you can fire bullets with power as low as 0.1. If you call a firing function (i.e. <code>setFire()</code>) with a value greater than 3.0, Robocode will adjust it to 3.0, and if you call it with a power lower than 0.1 (except 0.0 which will not fire) it will adjust it to 0.1. Additionally, you can fire bullets with power less than 0.1 under one condition: when your robot has less than 0.1 energy left, in which case a bullet is fired with however much energy your robot had left.

; '''How fast does a bullet travel?'''
:A bullet travels at a speed between 11.0 and 19.7 depending on the power. The more powerful the bullet, the slower. The formula to calculate it is <code>velocity = 20 - (3 * power)</code>.

; '''Does the robot velocity get added to the bullet velocity on firing?'''
: No, bullet velocity is not affected by robot velocity. It's kind of like the speed-of-light thing. =)

; '''Which is the range of a bullet?'''
: A bullet has no range. It keeps going until it hits a robot or a wall.

; '''I want to fire a bullet every turn, but I can't. Why?'''
: Every time you fire, the gun generates some heat. You must wait till it is cool again to fire. If you give a fire order when your gun is hot, it will do nothing. The heat generated by a shot is <code>1 + (firepower / 5)</code>. The gun cools down at a default rate of 0.1 per turn (note that you can change this parameter when you run the battle, but nobody usually does). It means you can fire a 3.0 power bullet every 16 ticks.

; '''How much damage does a bullet do? How do I gain or lose energy?'''
: You lose energy every time you hit a wall, you are hit by an enemy bullet, ram an enemy, or you fire your gun. The amount of energy you lose by being hit is <code>4 * bullet power + 2 * max(bullet power - 1 , 0)</code>. So the maximum amount is 16.0. When you fire, you spend a quantity of energy equal to the power of the bullet fired. When one of your bullets hits an enemy, you collect back <code>3 * bullet power</code> energy. When you hit an enemy bot, each bot takes 0.6 damage. If an [[AdvancedRobot]] (but not a [[Robot]] or [[JuniorRobot]]) hits a wall, it will take <code>max(abs(velocity) * 0.5 - 1, 0)</code> damage.

; '''Some times I get disabled. What happens?'''
: You can't kill yourself, so when your energy drops to zero because you hit a wall or you fire, your bot gets disabled. It will not be able to move nor fire. If you are lucky enough and one of your bullets in the air hits an enemy, you will get some energy back and recover from disabled status.

; '''I get disabled, but I my energy > 0. Why?'''
: There are a few possible causes. You may have called a getXXX() function - such as getVelocity() - too many times a turn. The limit is 10000 getXXX() function calls per turn. To avoid disabling in such situations, either store returned values in variables for future use or use a [[RobotStatus]] object obtained from [[StatusEvent]]. Another case in which you can get disabled is throwing an exception, which may disable your bot, even if you catch the exception. Also, if your bot gets stuck in an infinite (or very long) loop and skips many turns, it may also get disabled.

; '''How fast do I move?'''
: You can move at a maximum speed of 8.0 units/tick. You can modify (down) your maximum velocity by using <code>setMaxVelocity(...)</code>. Note that your bot will always accelerate to reach its maximum velocity.

; '''How fast do I accelerate?'''
: You accelerate at 1 unit/tick, and you decelerate at 2 units/tick. For example, if you are moving at an speed of 8.0 and reverse your direction your velocities will be [6.0, 4.0, 2.0, 0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0].

; '''How fast do I turn?'''
: The faster you go, the slower you turn. The formula to calculate it in degrees is <code>10 - 0.75 * abs(velocity)</code>.

; '''What is the size of a bot?'''
: The size of a bot is 36x36. Note, this is slightly smaller than the image of the bot. It is modeled as a non rotating square, so it's always the same regardless of its heading.

; '''It seems that Robocode doesn't follow standard physics. If my velocity is 0 and I accelerate (acceleration = 1) my final velocity is 1, but it should be 0.5. What happened?'''
: Time in Robocode, rather than being continuous, is in discrete "ticks". First acceleration is calculated, then velocity, and then position. So if you are stopped at a position 0 and you accelerate 1, your velocity next turn will be 1 and your position also 1.

; '''How can I detect when an enemy has fired?'''
: There is no direct way to detect when an enemy fired, but you can deduce it by monitoring the enemy energy drop. A drop between 0.1 and 3 usually means that it fired a bullet (there can be other reasons, such as a low energy bullet hit or a wall hit). Wall hits are (more or less) detectable as well. A deceleration > 2 means the bot hit a wall (or another bot). A deceleration <= 2 may be simple a bot hitting the brakes, or hitting a wall at velocity = 2, but since hitting a wall at that speed won't cause any damage, you can ignore that. AdvancedRobots take <code>abs(velocity) / 2 - 1 (Never < 0)</code> damage when hitting a wall, so by detecting (significant) wall-hits and adjusting the enemy drop accordingly, wall hits can be filtered out most of the time. This method fails when the enemy hits another robot.

; '''How can I detect the position and heading of an enemy bullet?'''
: You can't. There is no way to know it, directly or indirectly. But of course, you can always [[GuessFactor|guess]]...

; '''How fast can I turn my gun?'''
: The gun turns at 20 degrees per tick.

; '''How fast can I turn my radar?'''
: It turns 45 degrees per tick.

; '''Can I know the heading of the enemy gun/radar?'''
: No.

; '''Can I specify the initial position of my bot?'''
: No. The bots are randomly placed in the field at the beginning of each round.

== Programming your robot ==
; '''What is the difference between the setXXX() (e.g. <code>setFire()</code>) and the XXX() (e.g. <code>fire()</code>) methods?'''
: Basically, the setXXX() methods just notify Robocode to take some action at the end of the turn. The XXX()-type methods end the turn when you call them, and they block your robot's thread until the command finishes. Unless you have a good reason, you should almost always use the setXXX() version when writing [[AdvancedRobot|AdvancedRobots]].

; '''How can I avoid my gun/radar turning when my bot turns?'''
: You can use <code>setAdjustGunForRobotTurn()</code>, <code> setAdjustRadarForGunTurn()</code>, and <code>setAdjustRadarForRobotTurn()</code> methods to control this. If you call <code>setAdjustGunForRobotTurn()</code> and <code> setAdjustRadarForGunTurn()</code>, you don't need to call <code>setAdjustRadarForRobotTurn()</code>.

; '''Why are there two functions for <code>getBearing()</code> for example - one in radians and one in degrees? Is there any performance gain if I use radians instead of degrees?'''
: There is no real advantage to using one or the other. Just use the one you prefer. Often, people start using degrees (just because they feel more comfortable with them) and later they switch to radians (because calculations are easier since you can use the built-in Java trigonometric functions). Just remember to use always radians or always degrees; mixing them up is not a good idea.

; '''I need to trace my bots actions and variables. I saw that everybody uses <code>out.println("...")</code>, but where is that printed?'''
: It prints to the [[Robocode/Robot Console|robot console]]. When you execute the battle, just click on the button on the right of the screen that shows the name of your robot to open its [[Robocode/Robot Console|console]].

; '''How do you get your radar to stay focused on a robot that you have defined as your target?'''
: You just turn the radar the other way around when you scan the bot. You lock your radar by not turning it 45 degrees, but only the arc needed to stay focused. See the [[Radar]] page for some example code.

; '''How can I know how many enemies are in the battle field?'''
: You can use the <code>getOthers()</code> method to know how many live enemies are in the battlefield.

; '''I'm trying to recognize an enemy/teammate from its name (using <code>e.getName()</code>) but the condition always fails. What's happening?'''
: Because of Java's funky way of interpreting references to Strings (not to mention a lack of operator overloading), you can't use an expression like <code>if (e.getName() == testname)</code> to check for equality. You have to use the <code>String.equals()</code> method, as in <code>if (e.getName().equals(testname))</code>.

; '''How do I keep data from round to round and battle to battle?'''
: The easiest way is to save data between rounds of a battle is to make the variables in the bot class static. Because Robocode uses a separate classloader for every robot, the variables will not conflict even when you have more than one copy of a robot in a battle. Note that this will save data between ''rounds'', not between ''battles''. To save between battles you will have to save to a file. The maximum allowed disk space for files is 200k. Look at the [[:Category:Robocode API|Robocode API]] for more details.

; '''I get the following message when I run my bot, and I don't know how to solve it.'''
<pre>
SYSTEM: You have made 10000 calls to getXX methods without calling execute()
SYSTEM: Robot disabled: Too many calls to getXX methods.
</pre>
: Robocode prevents you from calling functions like <code>getX()</code> or <code>getVelocity()</code> too many times during a single tick. So if you are using them in a long loop, it will raise this error. Actually, 95% of the time, this error is a symptom of an infinite loop in your bot. If you know you have a long-but-finite loop and you get this error, either just assign the values you want to use to a variable or use a [[RobotStatus]] object obtained from [[StatusEvent]].

; '''I'm using <code>bulletObject = setFireBullet(power)</code> to fire, and then I want to get the bullet coordinates. But when I try to print them using <code>System.out.println(bulletObject.getX() + bulletObject.getY())</code> I get an error. What's wrong?'''
: <code>setFireBullet()</code> creates a Bullet object, but the bullet doesn't actually leave your bots gun until the next tick, so you can't do <code>getX()</code> or <code>getY()</code> on the bullet until then. If you change it to <code>fireBullet()</code> you should be OK, because the function won't return until the bullet is in the air. If <code>fireBullet()</code> won't work for you, you'll have to devise another method of making sure that you don't do <code>getX()</code> and <code>getY()</code> on bullets until the turn after you fire. For example, you could store Bullets in an ArrayList, and print out their coordinates before you fire in your main loop, so that a given bullet will be added to the vector on one turn, but won't be accessed until the next turn when your main loop starts over. Alternatively, your bot can attempt to predict/simulate it's own location on the next tick, to know where the bullet will be created.

; '''I want to reverse my direction when my movement is about to finish. I use something like <code>if (getDistanceRemaining() < minimum)</code>, but the bot behaves in a strange way.'''
: The <code>getDistanceRemaining()</code> method (and in general all methods returning remaining movements of the body, gun, or radar) can return a positive or a negative value, depending on the direction of your movement. Use <code>if (Math.abs(getGetDistanceRemaining()) < minimum)</code> instead.

== See also ==

=== Robot API ===
* [http://robocode.sourceforge.net/docs/robocode/ Robot API]

=== Tutorials ===
* [[Robocode/System Requirements|System Requirements for Robocode]]
* [[Robocode/Download|How to download and install Robocode]]
* [[Robocode/Robot Anatomy|The anatomy of a robot]]
* [[Robocode/Getting Started|Getting started with Robocode]]
* [[Robocode/My First Robot|My First Robot Tutorial]]
* [[Robocode/Game Physics|Robocode Game Physics]]
* [[Robocode/Scoring|Scoring in Robocode]]
* [[Robocode/Robot Console|Using the robot console]]
* [[Robocode/Downloading_Robots|Downloading other robots]]
* [[Robocode/Learning from Robots|Learning from other robots]]
* [[Robocode/Package Robot|Package your robot]]
* [[Robocode/Articles|Articles about Robocode]]
* [[Robocode/Console Usage|Starting Robocode from the command line]]
* [[Robocode/Graphical_Debugging|Graphical debugging]]
* [[Robocode/Eclipse|Using Eclipse as IDE]]
* [[Robocode/Eclipse/Create_a_Project|Creating a project for your robots]]
* [[Robocode/Eclipse/Create_a_Robot|Creating a robot in Eclipse]]
* [[Robocode/Running from Eclipse|Running your robot from Eclipse]]
* [[Robocode/Eclipse/Debugging Robot|Debugging your robot with Eclipse]]

=== News and Releases ===
* [http://sourceforge.net/export/rss2_project.php?group_id=37202 RSS Feeds for the Robocode project]
* [http://sourceforge.net/project/showfiles.php?group_id=37202&package_id=29609 Robocode file releases]

=== Home pages ===
* [http://robocode.sourceforge.net/ Classic homepage]
* [http://sourceforge.net/projects/robocode Robocode project at SourceForge]
* [http://robocoderepository.com/ Robocode Repository]
* [[wikipedia:Robocode|Wikipedia entry for Robocode]]

[[Category:Robocode Documentation]]

Robocode/Eclipse/Create a Robot

2010-04-07T07:54:17Z

Bostonvaulter: /* Creating a Robot in Eclipse */ added link to my first robot tutorial

This page describes how to create a robot in [http://www.eclipse.org/ Eclipse], and assume that you already now [[Robocode/Eclipse/Create a Project|how to create a project in Eclipse]].

== Creating a Robot in Eclipse ==
Ok, so we have a project now, and it's time to create a robot (or many robots!) in it.

First, right-click on the '''MyRobots''' project, and select New -> Class:

[[Image:Eclipse-NewClass.png|Shows how to select a new class by right-clicking on the MyRobots project]]

Next, fill in the package name (Robocode suggests your initials), a Robot Name (here I have '''FnlBot'''), and change the '''Superclass''' field to '''robocode.Robot''':

[[Image:Eclipse-NewJavaClass.png|Shows the dialog for creating a new Java class named FnlBot, which is inherited from the robocode.Robot class]]

Click '''Finish''', and you'll see your robot class, like this:

[[Image:Eclipse-FnlBotEdit1.png|Shows editing the newly created FnlBot.java source file, which is empty and needs to be filled out with some code]]

You can now edit your robot however you like.

[[Image:Eclipse-FnlBotEdit2.png|Shows editing the newly created FnlBot.java source file, which has now been filled out with a bit more meaningful code]]

You can save your robot as often as you like by hitting '''CTRL-S''', or selecting '''File->Save'''. There's no need to explicit select '''Compile''' (as in the Robot Editor for [[Robocode]]) anymore, since Eclipse automatically takes care of this task for you, when you make changes to your files.

Have fun playing around with Eclipse. Since there's no better way to learn than by playing around, I'll leave you to it!

If you want help starting a robot you should check out the [[Robocode/My First Robot|My First Robot]] tutorial

The only thing left is to make sure that [[Robocode/Add a Robot Project|Robocode sees your robot]].

== References ==
* [http://www.eclipse.org/ Eclipse.org - Eclipse home page]
* [http://www.eclipse.org/downloads/ Eclipse Downloads]
* [http://download.eclipse.org/eclipse/downloads/ Eclipse project downloads - latest releases]

== See also ==

=== Using Eclipse IDE ===
* [[Robocode/Eclipse|Using Eclipse as IDE]]
* [[Robocode/Eclipse/Create_a_Project|Creating a project for your robots]]
* [[Robocode/Add_a_Robot_Project|Add robot project from an IDE into Robocode]]
* [[Robocode/Running from Eclipse|Running your robot from Eclipse]]
* [[Robocode/Eclipse/Debugging Robot|Debugging your robot with Eclipse]]

=== Robot API ===
* [http://robocode.sourceforge.net/docs/robocode/ Robot API]

=== Tutorials ===
* [[Robocode/System Requirements|System Requirements for Robocode]]
* [[Robocode/Download|How to download and install Robocode]]
* [[Robocode/Robot Anatomy|The anatomy of a robot]]
* [[Robocode/Getting Started|Getting started with Robocode]]
* [[Robocode/My First Robot|My First Robot Tutorial]]
* [[Robocode/Game Physics|Robocode Game Physics]]
* [[Robocode/Scoring|Scoring in Robocode]]
* [[Robocode/Robot Console|Using the robot console]]
* [[Robocode/Downloading_Robots|Downloading other robots]]
* [[Robocode/Learning from Robots|Learning from other robots]]
* [[Robocode/Package Robot|Package your robot]]
* [[Robocode/FAQ|Frequently Asked Questions (FAQ)]]
* [[Robocode/Articles|Articles about Robocode]]
* [[Robocode/Console Usage|Starting Robocode from the command line]]
* [[Robocode/Graphical_Debugging|Graphical debugging]]

=== News and Releases ===
* [http://sourceforge.net/export/rss2_project.php?group_id=37202 RSS Feeds for the Robocode project]
* [http://sourceforge.net/project/showfiles.php?group_id=37202&package_id=29609 Robocode file releases]

=== Home pages ===
* [http://robocode.sourceforge.net/ Classic homepage]
* [http://sourceforge.net/projects/robocode Robocode project at SourceForge]
* [http://robocoderepository.com/ Robocode Repository]
* [[wikipedia:Robocode|Wikipediaentry for Robocode]]

[[Category:Robocode Documentation]]
[[Category:Tutorials]]
[[Category:Eclipse IDE]]