Talk:XanderFramework

A ran a new test tonight on static data handling. Tonight it appears as though static variables are not shared -- as if each robot runs on it's own JVM. This is fascinating, as I sware I have had problems with this before, and I even ran a test not that long ago that seemed to confirm the issue. I will need to do more testing to fully understand what is going on. Maybe it was an issue for an older version of Robocode. Not sure. I will have to run more tests. Skotty 05:10, 2 June 2011 (UTC)

I suppose it's time to dig deeper into Java class loading. Not something I've ever had to dig too deep into in the past, but Robocode seems to be doing some strange things with it, presumably to isolate robots from each other. Again, I can sware I've seen static variable sharing problems before. The last version of Robocode I used before 1.7.x was 1.1.3 -- could that particular version have had some bugs related to this? (note: I tried version 1.0.7 and couldn't duplicate the issue; version 1.1.3 is not available for download, and I no longer have a copy of it on my system to try). If indeed Robocode manages to completely sandbox every robot, it would seem I have wasted a lot of time working on a problem that doesn't really exist. Robocode informational pages should state this upfront, as it is atypical behavior for a Java-based system. Skotty 06:21, 2 June 2011 (UTC)

A little note on drives and guns in the Xander framework -- a CompoundDrive or a CompoundGun allow multiple drives or guns to be chosen between using a DriveSelector or GunSelector respectively. It should be noted that CompoundDrives or CompoundGuns can be nested. What this does is creates a decision tree, with CompoundDrives or CompoundGuns being the branches. This might look something like the following (and is the general plan for drives for XanderCat 3.2). (Although I don't show it in the example, a CompoundDrive or CompoundGun can have any number of drives or guns immediately below; it is not limited to only having two)

             __________________
            [  Compound Drive  ] 
            [                  ]
            [ [Drive Selector] ]
            [__________________]
          ____________|____________
 ________|_________        ________|_________
[  Ideal Position  ]      [  Compound Drive  ] 
[     Drive        ]      [                  ]
[__________________]      [ [Drive Selector] ]
                          [__________________]
                        ___________|____________
               ________|_________       ________|_________
              [   Anti-Mirror    ]     [    Stat Drive    ]
              [     Drive        ]     [                  ]
              [__________________]     [__________________]
              

Assuming I can really carve out enough time for this, I am planning a new version of my Xander robot framework. This will be a new major version, as it will make a few fundamental changes to how it works. The primary purpose of this overhaul is to add melee support.

Originally, I had developed a small amount of multi-opponent support, but it was rather limited. For instance, the snapshot history can save histories for multiple robots by storing them in a map with robot names as key values, and their snapshots as values. However, I will not be finishing out this approach for all parts of the framework. There are a lot of framework components that contain information for both self (my robot) and the opponent. I would need to expand these in a way similar to the snapshot history, and be able to store info for all opponents. But I'm not going to do this.

Instead, I think I am going to divorce storing information for self and opponent in the various framework components, and just store information for a single robot. Doing this for self might be a special case for this, but I still think it will work. Thus, there will not be a single snapshot history, and a single wave history, etc. Instead, there will be one of each of the components for every robot in the battle. Then I will add some higher level management that dishes out information for each robot to the correct components for that robot. I believe this approach will ultimately be more elegant, simplify the individual components a bit, and provide more flexibility.

I may also provide a few other tweaks, but the melee support will the primary focus.

This will be Xander framework 3.0.