Archived talk:Musashi 20090522

From Robowiki
Jump to navigation Jump to search
Musashi Sub-pages:
MusashiArchived Talk 20090522
       Archive        This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.     

Way to go with 2.14. You sliced the number of positions to the top in half and passed Marshmallow, Aspid and Tron! Was it movement changes this time? -- PEZ

Thanks, u can't imagine the smile in my face. Yes, it was a movement change. I was working trying to flatten it's movement, just like u suggested. It's quite crude yet, but i think that i'm in the right path. (I am writing this and looking at my to-do list above. I can't believe that i actually beaten one of my favorite bots: Tron. That to-do list was to be a joke). :-)))))))))))))))))))))))))))) -- Axe

Great work, keep it up! Shadow needs a portuguese speaking bot in the top 10 to chat with. :) -- ABC

Oh, I can imagine that smile. Believe me I can. The day David Alves wrote me on the wiki that Marshmallow had reached top-10 in EternalRumble I was walking on clouds! Few things can compete with that emotion. And today the fight near the top has tighten up considerably so your top-25 spot is definatley comparable to that. You have quite a few of the top-10 bots of those days behind you now. -- PEZ

There's something very predictable about your movement. GloomyDark has an easy time hitting it for some reason. I haven't analysed it very closely but I suspect it might be Gloomy's segmentation on the time the enemy has kept traveling without changing speed. You might want to make a modified version of RoboGrapherBot that segments like GloomyDark does and see if you can find the predictable element. -- PEZ

It looks to me like you have a problem with power 3 HeadOnTargeting. Your problem bot list is very similar to Shadow's: bots like kawigi.sbf.Barracuda and jep.Terrible are much more of a problem than they should. From what I observed of Musashi's movement, you are taking a very similar path to Shadow's, so, if you find a good solution to avoiding those bots while still remaining unpredictable to the better guns, please tell me! :) -- ABC

But Barracuda doesn't shoot with HeadOnTargeting, does it? -- PEZ

It surely looks to me like it does, maybe it is a bug? -- ABC

Could be that against your movement it ends up shooting head on. Looks like MakoHT is also on your problem bot list (and, to a lesser extent, also on Musashi's). MakoHT and Barracuda have similar targeting systems. Does MakoHT also seem to fire head on? Then maybe you can get some clues on how to adjust your movement by studying the pages about AngularTargeting/Factored and MakoHT's code. -- PEZ

Yes, MakoHT is also a big problem bot of mine. If I change my movement to never invert the circling direction, I go from 45% survival to 80% against MakoHT. My problem is that I never was able to optimise a "stop and go" movement as good as a "always on the run" one. I have movement variations that can defeat both Barracuda and MakoHT, but those degrade my performance against the other top bots (including other versions of Shadow). I'll keep searching, though... ;) -- ABC

Indeed. I think it's quite impossible to tune a stop-and-go movement that generally performs better than a keep-moving one. At least as long as stop-and-go means changing direction unfrequently. But you might come away with starting out with Shadow's regular movement and then keep an eye on how frequently you are being hit in GuessFactor 1.0. And if this is unfrequent you can tune your movement to change direction less often. This should fool both Barracuda and MakoHT, and possibly also FloodMini. -- PEZ

Thanks for the incentive words. The Musashi's new flat movement it's quite simple:

  • It moves in a circle aroud the enemy.
  • It haves 3 distance management modes: Get closer, Get away, and Hold off (the seed of a future DistanceManagement system).
  • If it is closer then 400 (empiric), Get away; If it's near a wall, Get closer; Otherelse, Hold off.
  • The flat factor: takes the last fired enemy's bullet power, and calculate the time it would take to hit me (lets call it time_to_hit_me). At each tick i use the following formula to decide if it will invert the direction: ((Math.random()* time_to_hit_me * 0.45) < 1)

As i said, it's quite simple, and it's yet very crude. That formula, for example, is based on tests with PEZ's RoboGrapher, and didn't understood the reason of the 0.45 factor, i originally started without that factor, but RoboGrapher pointed a huge spike near 1.0 GF, so i introduced that factor, and the 0.45 came to be the best. I think that the HeadOnTarget weakness can be avoided if i start to track down how frequently it's being hit in GF 0.0, indicating a HeadOnTarget gun. And then just stop inverting it's direction (as PEZ said). My tests confirmed what ABC said, if I stop changing direction, Barracuda is defeated easily. By the way: can anyone explain me the reason of that 0.45 factor? When i think about it, it doesn't make sense... (but the fact is that it works). -- Axe

I can't explain it. But it is the same factor I empirically use to end up at. -- PEZ

It's a mysterious world of magic numbers... There is also something about 0.85 that makes it special. If you always run for time_to_hit_me * 0.85 and then invert direction, GF guns (non-segmented) will have a hard time hitting you, while PM guns will hit you 100% after the first inversion. -- ABC

@Paul: Can the master explain it? -- Axe

Have you tried this movement vs. another graphing robot (such as FloodMini)? I have implemented it myself and was not having much success with it so I went ahead and downloaded Musashi for testing. I think you would do well to look at it this way too. I was getting the same results with Musashi as I was with my attempt to clone it. Against bots which fire Waves at actual shot time (like Jekyl for instance) the spike at zero is very pronounced at ranges above 300 or so which is not good. I do think this line of research holds promise as I think that at ranges between 200 - 300 this movement was pretty flat but a little too narrow for my liking. I have been searching for a way to define reverse probability as a function of target distance for quite some time now but I have not been able to find it yet. If you can find a way to vary your .45 factor as a function of distance I think you will be golden. Then if you add some functionality to vary the reverse probability based on being hit by the enemy at some guess factor I think you will truly have something. I will be watching Musashi a bit more closely to see how well you do with this. =^> -- jim

Very good observations, Jim. About another graphing bots, the fact is that i didn't knew about existing others, and i still don't know how to use for example FloodMini (Is there somewhere anything explaining how to use it?). PEZ's RoboGrapher is an amazing tool, but other sources of info would shurelly be usefull.
About the function of distance, that was my intention in the first place whith the time_to_hit_me factor. But u are correct, i didn't analized the curve in the ranges, i have only payed attention to the general curve (stupid, stupid, stupid...). Probably when i analize every range segment, i will find that the 0.45 factor is not a constant, but depends on the distance. And also if and when i implement a "beeing hit at GuessFactor", that should introduce another factor too. Thanks a lot. -- Axe

Jim, haven't u meant FloodGrapher? I have just "discovered" it. Let's see how it works... -- Axe

Axe, you are correct. You need both FloodMini and FloodGrapher. PEZ's RoboGrapher is a derivitive of Kawigi's FloodGrapher. They share many of the same characteristics. There are many pull downs to choose from (range, acceleration, velocity, proximity to wall). You should quickly be able to isolate your weakest elements and then be able to make adjustemnts. Be aware that a fix to one will most likely affect another. The trick is to try and balance them all. Also keep in mind that FloodMini fires a wave every tick. This can lead you to a movement profile that is mostly good overall and yet not all that good against bots that fire waves only at shot time. When I testes Musashi vs FloodMini, I noticed it had a very flat profile at the 200 - 300 range. But when I test Musashi vs. Jekyl, I notice that the 200 - 300 range is not that great either (Jekyl fires waves at shot time and is able to find a dodger a bit better than FloodMini). Right now I think you are about to enter the stage that I am in: Subtle tweaks and massive rounds against FloodMini followed by pouring over results followed subtle tweaks followed by massive rounds against FloodMini folowed by......... I hope you have a fast computer. You are going to need it =^> -- jim

What needs to be done is to make a FloodMini development kit. (That having been said, I all of a sudden realize why more bots keep beating mine). Package an updated version of FloodGrapher (the only difference from the current version would be to change the labels on the distance to be projected bullet flight time in increments of 10 ticks) with a couple variations of FloodMini - one could be FloodMini 1.4, one would be FloodMini 1.4 who only fires a wave when it fires a real bullet, one would probably be a stationary (TC) version, there could be one that always fires power 3 bullets, one that fires lower-powered bullets, one that disables DynamicDistancing, or has configurable distancing... -- Kawigi

I for one would love to see this as you well know. I have said it before and I will say it again: FloodMini is the best bot in the world to test against as it provides such valuable feedback. If I might suggest: Perhaps a Properties file that allows the behaviors to be specified (ie: distance=200 dynamic=[true || false] behavior=[normal || reference || challenge] waves=[every_tick || shot_time]). You would not have to worry about being a mini anymore so byte count would not matter. It would save me from maintaining the hacked versions that keep laying around for all of this too =^> -- jim

The other cool thing to do would possibly be to make a more readily extensible version of the bot altogether - based on FloodMini but certainly not strictly FloodMini. The feature I see here is to also specify in the properties file the very nature of the segmentation - and even add classes to represent new segmentation divisions. -- Kawigi

Subclassing works for this stuff. It's quite easy if you make all configurable stuff into abstract methods of the super class. The implementation bots get really small. But I would leave this as an exercise to the users of FloodGrapher. =) -- PEZ

There it is. A very rustic attempt to avoid Musashi's movement weakness against those HeadOnTargeting guns. The fact is that is so rustic that i'm too embarrassed to explain now (even knowing that if it works, no need i'll have to be ashamed). The major problem is that i'm been in a lack of time these days, so ugly (and fast) is beautifull... -- Axe

It works man. Please let us know what it was you did. Musashi is now top-10 material! Must feel great, huh? -- PEZ

I have to thank u all people again. Getting advices from people like PEZ, ABC, jim and others is surely a good short cut to the top. Thanks.
I think that it is too soon to talk about top 10, Musashi tends to fall a little once the GF guns gain data about it, it happens allways... Right now it is at 13th (rating 1815.69), but i doubt that it would stay there.
My intent in v2.15 was to get rid off the HeadOnTargeting weakness, however maintaining a reasonable flat moving against the top bots. I think that it was achieved successfully, as an example, against Barracuda v2.14 was rating 43.2%, v2.15 beats it by 84.7!! Similar bots are not a problem now too. Quoting jim: "Beat everyone else as well as they do, then beat them".
This was achieved as i said, in an ugly way - althout simple (I just can't decide if it is ugly because is ugly or if it is nice because is really simple...):

  • It was introduced a static boolean named "flat", initialized false. This property is used to decide if it will try to invert the direction (as explained above as "flat factor"). Since it is initialized as false, it will start orbitting the enemy at full throttle, inverting the direction only when is about to hit a wall.
  • When it inverses the direction (about to hit walls), stores the current time at a property named "last_inversion".
  • Now comes the trick: When hitten by a bullet:
    public void hitByBullet(double pw) {
        long lastRevDelta= getTime() - last_inversion;
        long hitAtMaxSpeed=
            (long) ((him.getDistance() + 100) / RoboMath.getBulletVelocity(pw));
        if ((him != null) && (him.getDistance()>200)&&(hitAtMaxSpeed < lastRevDelta) && (!flat)) {
            flat= true;
	}
    }
   

My intention is to do this in the future by getting a record of Hitten GFs, and use this data to adjust the "flat factor" (fixed at 0.45 by now). But since I'm short on time to robocoding... That was the fastest way to get it done. -- Axe

To ABC: U asked me to let u know if i find a solution... There it is. -- Axe

Cool. Thanks for sharing this. -- PEZ

Hey!!! I was quoted. This might be a first. Congrats on entering the top of the table. -- jim

Amazing how such a simple solution can work so well... Of course now Musashi gets most of its ranking points from the weaker bots (see the LRP graph), it's still most impressive how you can improve your ranking so much just by taking care of some "simple" problem bots. Great work, and congrats! -- ABC

I already saw it. One good thing here is that we see how much we can gain paying a little attention to the weaker bots.
In the LRP develop discussion i once saw this Paul's frasis: "A positive gradient would indicate a good gun is being let down by relativley poor movement.". At that time i thougth it was a little strange (not entirely wrong, althout)... Now i think that a positive gradient just means that you aren't paying attention to the weaker bots. And if your bot is at a top position, it means that you are loosing a lot of easy points.
Musashi proved to me this since version 2.14 had a negative gradient, and after improving it's movement with v2.15 it now has a positive gradient. Against strong bots, it's movement is probably one of the most weak among the top 30 (maibe even among the top 50). But against the weaker bots (in particular the HeadOnTargeting ones) it is probably the strongest movement (even strongest than DT or Lacrimas).
The good news is that i have now a strong moving against weaker bots, the bad news is that i'll have now to improve against the tough ones... (good and bad to me, of course) -- Axe

I also thought you could interpret an LPR graph like Musashi 2.14's like that. That's why I created Swiffer. It tries to move strong against the weak and against the strong too. -- PEZ

You'll notice SpareParts doing exceptionally well against head-on targeting, too (of course, it was built on some of the same ideas as Swiffer). If I were to do it again, I'd probably have some kind of random stop-and-go movement, and if I got hit try just vibrating for a minute, and if I got hit again, go to more advanced movement. -- Kawigi


Sweet. Top-10! Congratulations! -- PEZ

Thnx. The gun was broken, can u imagine that? There is a moving change in 2.16, introducing some of that "No fear from the walls", but what really made difference was the gun's major bug (i was using radians in a point that i was supposed to be using degrees :P). I'll have now to spare a lot of time tweaking it again... -- Axe

Sun of a beach!! Those mirror moving bots are giving me a really bad time:

eat.HumblePieLite_1.0    46.2%
non.mega.NaN_0.1         39.3%
(does any one knows any other MirrorMovement bot?)

NaN beeing my third worst result, behind only of RaikoMX 36.3% and DT 37.7%. I think that i am putting together a anti-mirror system. I made mine Jim's mantra: "Beat everyone below u. Then beat the top.". -- Axe

I doubt you need an anti-mirror system really. Lots of good bots eat humble pie for lunch (pun intended) without anti mirror guns. Though it doesn't hurt having one, but the time spent on it is probably better spent on figuring why those bots hit your movement better than you do. Funny that you pick up Jim's mantra now when ABC has gotten to the top by making sure his bot beats DT and Lacrimas. =) -- PEZ

  • You make it sound as if Shadow was not beating the bottom of the ladder badly already. As I recall he was. -- jim
    • Yeah, I know. But I do think that if you create a movement that DT can't hit you are almost in the clear. -- PEZ

I am not saying that i won't work on top bots, but that i'll work first on the low ranked. MusashiTrick came from that mantra. I don't matter that much rating 37% with DT, but rating 39% against NaN really bothers me. You are obviously right about sparing some time on figuring out why they hit my moving better than me. I think that the reason is that my move is strong against PM guns (see results against Shadow, Tron & me), but very weak against GF and other guns (let me know if u have a better analisys).
About the anti-mirror system, isn't really that difficult to make it (actually i'm in the verge of getting it done). And is also a funny kind of revenge against the MirrorMovement bots (they are really obsessing me). Do they want to steal my moving? Go ahead, be my guest... -- Axe

Good. Obsession is the key to Robocode success. -- PEZ

Out of interest how many Rumble bots use mirroring? -- Paul

I know the three: HumblePie, HumblePieLite & NaN. -- Axe

Ok. It's done. Version 2.17: a 4-hours implementation of an AntiMirrorSystem, it should be the "ultimate death" to MirrorMovement bots. Hopfully i didn't introduced any bug in the hurry... -- Axe

Maybe DogManSPE is a mirror too, version 2.16 scores:

sgs.DogManSPE_1.1 53.2%

With v2.17 i have just beaten it by ~97%... This or i've got a crashed down DogManSPE. -- Axe

  • He isn't a mirror. Just crashes with a NullPointerException sometimes. -- Axe

Version 2.17 was buggy, replacing with 2.18 -- Axe

It works man! Care to share the details? I don't think we have a page about AntiMirrorTargeting in general. -- PEZ

  • Sure, just give me a few days. But i'll call it AntiMirrorSystem, if u don't mind. Actually is a combination of MirrorDetecting + AntiMirrorTargeting + AntiMirrorMoving. By the way, i know that the idea of a anti-mirror system isn't new, actualy is very obvious and there is a lot of different possible approaches, but am i the first to implement something in that way? Let me know if u know someone else, afterall, there is a special flavor on beeing the first :) -- Axe

Very good work, top10 with 1850 points, congrats! I believe Prairiewolf and Swiffer also sometimes use mirror movement. Tron and Shadow can also be used as testers if you put "behavior=sandboxkiller" in their properties files. -- ABC

  • fantastic! There is a way to beat Shadow! 35 rounds: 83.79%, 35 wins for Musashi! I think that for Shadow, taking that he already kills DT, it would be more appropriated if u call that setting "musashislunch" :) -- Axe
  • lol, I used to have to resort to mirrorMovement to win against DT 1.91, it was a great morale booster. Glad to hear that it works for you now. ;)

Btw, I can't test against Musashi at home because it is incompatible with java 1.3. Would it be too hard to fix? -- ABC

  • I will try, but expect some days, i'm downloading the 1.3.1 sdk now. -- Axe

You're probably doing indexOf() on a String instance. Make it a StringBuffer and things should work on 1.3.1. If it is not that you are using regular expressions which are not supported by stock 1.3.1. Then you'll have to include a regexp packagein your jar. -- PEZ

  • probably that indexOf(). and probably a lot others in List, Collections... -- Axe
  • I don't think the Collections farmework changed all that much between 1.3.1 and 1.4.1, did it? -- PEZ

I think PEZ has some things backwards - the StringBuffer indexOf is new, the String indexOf has been around since the stone ages (I was teaching students how to use it before 1.4 was released). -- Kawigi

If it takes too much work never mind, I'll eventually be forced to upgrade... Btw PEZ, Tityus 0.9.1 also crashes, here is what the console says:

pez.mini.Tityus 0.9.1: Throwable: java.lang.NoSuchFieldError: YELLOW
java.lang.NoSuchFieldError: YELLOW
    at pez.mini.Tityus.run(Tityus.java:52)
    at robocode.peer.RobotPeer.run(RobotPeer.java:616)
    at java.lang.Thread.run(Unknown Source)

-- ABC

Stupid me. I just didn't like using lower case constants... I'll fix that for T 0.9.4. -- PEZ

I'll fix mines too, it isn't polite to leave your bot prostrate in others computers :) -- Axe

I was running Musashi vs NaN and while the AntiMirror was working nicely for the most part, at one point Musashi turn and ran straight into the corner, then sat there unmoving except for a bit of rotation and not firing at all. I assume that's a bug? -- Kuuran

Probably (I have already saw this against OldManXP), thnx for notice it! But ain't sharp that killing against NaN? That 3.0 pwr bullets are the testimony of faith that i believe in the slaughter. There should be only one. -- axe

Indeed, very, very, very impressive the 98 percent of the time it works. Just solve the issue with that corner bug and maybe get some work in on looser mirrors and you're gold. Also, I suggest detecting mirrors who only flip one axis. That is to say mirrors going to {BattleFieldWidth - yourX, yourY} or {yourX, BattleFieldHeight - yourY} instead of {BattleFieldWidth - yourX, BattleFieldHeight - yourY} all the time. I believe the only production one of these is VertiLeach, but myself and many others have played with these, and if -x, -y mirrors start being ruined by these AntiMirrorSystems you might see a resurgence of mirroring in mirrors like this as well as "looser" mirrors like OldManXP. -- Kuuran

That's the idea, it's like chess, every attack have a counterpart, and also every defense. By doing this, all the robocoding comunity will take a step further. -- Axe

So I checked to see how good this bot really is, I took a tough rammer boot called SniperBot and put it in a duel with Musashi, at first, SniperBot simply rammed it to death, then at the third round, it figured that it's a rammer and simply moved away from it while shooting at it, brilliant learning! - Avihoo Ilan

Banzai! v0.5 (rambot)Score %BattlesLast BattleExpected %Problem Bot Index
axeBots.Musashi_2.1878.776-3-2006:13:1130.148.6

While he may catch on to the ramming technique, he still gets his lunch money beaten out of him by a superior rambot. -- Martin / Banzai!

There are no threads on this page yet.