JGAP is an open source Java framework and can be found at https://jgap.sf.net. RobocodeJGAP is based on JGAP.
The RobocodeJGAP project can be downloaded from https://jgap.sourceforge.net/doc/robocode/robocode.html
JGAP and RobocodeJGAP are maintained by Klaus Meffert
Two modes of operation are possible: a) fight one of the three robots each evolution step (randomly chosen) in a one-to-one battle b)fight all of the three robots and calculate the average
Currently mode b) is set.
The fitness value of a robot is calculated after each battle. For that the ratio of the own score to the sum of both robots scores is taken. Thus, if the other robot wins the score is less than 1, if the evolved robot wins the score is higher than 1 (in good cases much higher, like 8000). To scale the score up, it is artifically multiplied by 1000.
If fighting against three enemies one after another in a single evolution round, and the difference between the best score of our evolved robot and the worst score is too high, the fitness average is reduced a bit. The idea behind that is that an enemy that could be quite good, may have a partial weakness we just explored. But that doesn't help much, normally, in fighting against 200 other robots, like in RoboRumble.
After having exchanged a lot of general ideas with Flemming, the hands-on person of the Robocode project, I hope this is the place where I can get a better understanding of how good and at the same time structurally robots as simple as possible can be built.
I call a robot’s structure simple if it’s easy to evolve by JGAP. For example, it’s more difficult to have global variables that are used in two or more event handlers for exchanging information, than to have variables local to handlers. It is also easier to start with a fixed run-method than to have variable parts in it. For your information, RobocodeJGAP is already capable of extending AdvancedRobot, not only Robot (both are supported optionally).
1) So, in which event handlers can I make what code blocks static without losing the chance of evolving good robots?
2) Is it OK to have something like the following in the run-method:
// variable block here … // fix block start do {
turnRadarLeft?(Double-INFINITY)while(true); // fix block end
3) What could be in the above variable block?
4) Which events can I ignore?
5) Is it necessary (does it bring benefits) to handle onHitWall? or onHitRobot? or onRobotDeath?? For the last one as well as for onWin I think it should not be necessary as RobocodeJGAP evaluates the battle result afterwards in any way.
6) Which custom events are useful (with a simple approach)?
Code size is not a matter right now. At first because this is expected to come in the fine tuning phase later on. At second because it takes a lot of time to evolve full Java code, and even longer to produce longer programs. So the code will be quite short itself by the nature of the algorithm (at least until the JGAP grid is coming up).
Another interesting question is reusable code blocks. I browsed the code snippets section in this Wiki and found some few useful blocks.
7) Which utility functions, code blocks and maybe sort of “micro patterns” would you recommend to consider? By “micro patterns” I mean something like: “In onHitByBullet? count the number of hits and in onScannedRobot evaluate these to avoid being hit again” (of course this sentence underlied with a concrete implementation).
For now I hope to get some helpful feedback from you as a Robocoder. Share your thoughts and help to evolve RobocodeJGAP itself!
Thanx for your help!
What are you using as a testbed (for the elimination part, whatever the terminology is)? You should use a selection of strong to weak bots (handcoded), if that's what you want it to do well against. -- Skilgannon
Please see above under Testbed? for my answer. --KM
I actually discovered Robocode through a link on the JGAP site... I am moderately familiar with GAs (I have written many), but not much with GP (never written one, but I know how they work)... I'm curious what you are using for your fitness function, are you basing fitness strictly on victory / difference in score? I'm not very experienced with Robocode myself, but I think that adapting to your opponent during a battle is probably quite an important trait to have (more experienced Robocoders could speak to this). I suggest writing some bots of your own, to explore how it works. There's no substitute for domain knowledge, after all there's no free lunch! --BenHorner
Please see above under Testbed? for my answer. After thinking about the fitness value, I think there is potential to optimize the process. Would love getting some input from you. In the meantime, I will try some alternatives coming to my mind. What I already did is selectively choosing enemies, depending on the maturity of the current generation going on. --KM
The really cool thing with JGAP and RobocodeJGAP especially, is that it already contains all the parts to start using GP, and we could use it as the common way of doing it, i.e. a platform for GP robots. This way people that wants to use GP for their robot would not have to write all the GP workers themselves, just to test if some ideas would work out the way they expect. What I mean is that the GP framework has already been set up and tested very carefully, so a GP robot programmer could start working with a GP robot almost immediately. If something is missing for RobocodeJGAP, then we should supply all the ideas and mention the things missing, so it could be put into RobocodeJGAP, at least in the future. ;-) --Fnl
Great to have your support, Flemming :-) Keep on rocking! --KM
If there were a way to evaluate parts of your program... for example if of the last 8 shots fired, 6 have hit, perhaps the decisions made recently have been good ones for the gun, if of the last 10 shots fired by your opponent, only 2 have hit, perhaps the decisions made recently have been good ones for movement. I know there is interaction between offense and defense (moving around affects how well you can hit an enemy with a bullet)... but perhaps, you could evolve them separately? --BenHorner
Hmm, yes, that sounds reasonable. We could use the events onBulletHit? (=hit enemy), onBulletHitBullet? and onBulletMissed? (=miss), onHitByBullet? (=hit by enemy). Whenever such an event is fired, the program increases a corresponding counter. These counter variables could then be evaluated in a movement strategy. I think there are robots out there that work exactly this way. --KM
![[Home]](/images/RoboWiki.png)