Movement

Jump to navigation Jump to search
Revision as of 30 August 2017 at 13:25.
The highlighted comment was edited in this revision. [diff]

Oculus's movement fails. I can't download any of the movement challenges(All of the links are broken or the site is closed). I don't know how to be sure that it is improved. Are there key bots to test against?

    Dsekercioglu (talk)12:20, 29 August 2017
    I found a proof that my movement is a failure. Here is a battle result against Raiko.
    dsekercioglu.OculusRaikoGun* 2437 (52%) 950 190 1151 147 0 0 19 16 0
    jam.mini.Raiko 0.43 2214 (48%) 800 160 1111 143 0 0 16 19 0
      Dsekercioglu (talk)12:54, 29 August 2017
       

      You can try to download them from archive.org even when they are broken ;) Hope the links are archived.

        Xor (talk)13:02, 29 August 2017
         

        Find the bot you think you're notably failing, enable some graphic debugging and watch some matches at different speeds. Go back to your code, wonder what the hell is going on. Repeat. That's how I fixed most of the bugs for my last release. Maybe It will work for you :P

          Rsalesc (talk)14:01, 29 August 2017

          I don't think that it is because of a bug. Every movement I make is really bad. My old bots were built on BasicGFSurfer so no bugs I think.

            Dsekercioglu (talk)19:45, 29 August 2017

            Hmmm, it's neural, right? Is there any case of success of neural surfing besides Darkcanuck's bots?

              Rsalesc (talk)20:20, 29 August 2017

              As I know Only Pris uses Neural Surfing. Even if this movement is one of the worst in top 100 it is my best movement=). I think that I should tune it more against mid-level guns so it would be better against general.

                Dsekercioglu (talk)20:31, 29 August 2017
                 
                 
                 

                Looking at your results, I was quite curious about bullet shielders. It's the first time I actually understand this strategy, just watched a game. You get almost zero score against DrussGT, for example. It just sit there and block your bullets. I think I may safely assume those were all head-on shots. One thing I noticed is that DrussGT can't block Roborio, even though it was supposed to shoot head-on for the first shots, while there is no data. Does that mean that I'm not shooting head-on at all, right? That's weird...

                  Rsalesc (talk)21:50, 29 August 2017

                  One thing that is very important is that a BulletShielder needs to know the EXACT firing angles of your targeting. Even if there is a little deviation, it just don't work. That's why SimpleBot and Roborio should has no problem with shielders.

                    Xor (talk)04:00, 30 August 2017

                    Yeah, what intrigues me is where this deviation actually come from, since there is a lot going under the hood, and why Oculus doesn't have such "problem". I know it makes perfect sense. It's just too obscure.

                      Rsalesc (talk)04:08, 30 August 2017

                      First, a BulletShielder would simulate a traditional HOT that is aimed from one tick before, not real fire position, as that position is your position when aiming (onScannedRobot). If it still hits, it would fallback to simulate a state-of-the-art HOT that is fired from real position, which means an advanced firer that predicts its own movement one tick forward on aiming.

                      However, if you are firing at real position, it is impossible for a BulletShielder to shield without moving. Therefore, for those who fire at real position, a shielder must move a little to be able to shield. And that's where the deviation comes from.

                      Therefore for a learning gun which fires from real position and is able to learn that tiny move, BulletShielders don't work.

                        Xor (talk)04:21, 30 August 2017

                        Hmmm, it should be obvious, right? Traditional HOT isn't actually going straight to the enemy's center, so the bullet's intersection has positive length. Anyway, I also thought that the condition for bullets intersecting considered somehow imprecise calculations and that this would be enough to catch traditional HOT bullets, like the use of some epsilon when checking for the intersection. But it seems it's more like the intersection of the segments having positive length or something.

                        Thanks for clearing it up!

                          Rsalesc (talk)04:50, 30 August 2017

                          No, the bullet intersection code of robocode is exact, and the deviation of traditional HOT must be calculated exactly as well.

                          What do you mean by "positive length"? I thought every length should be positive ;p

                          And I also thought an intersection of two segment (bullets are segments when calculating intersection) is a point ;p It has no length at all.

                            Xor (talk)05:06, 30 August 2017

                            Sorry for the confusion caused. I just named things the wrong way. When I say segment intersection, I mean the safe area generated by the intersection of those segments, like in bullet shadowing. What I wonder is if, in a perfect universe where computers can compute with perfect precision, two bullets laying on opposite rays would collide or not. Note that the lines actually intersect, so the segments. The safe area, though, degenerates to a single point. So my doubt was like: Robocode actually checks for an intersection of those segments or for a non-degenerate safe area?

                            Note this degenerated from an actually valuable discussion into a stupid curiosity. :P

                              Rsalesc (talk)05:26, 30 August 2017

                              Robocode doesn't care about that safe area at all. In segment intersection algorithm, The first thing is to determine whether they are on the same line. If so, robocode just ignores the intersection. This behavior look strange at first, but it is friendly to those who new to robocode. This way they (when trying two stationary robot, etc. sample.Fire) won't confuse — why my robot collides its bullet with another all the time?

                                Xor (talk)05:31, 30 August 2017

                                Yeah, I was just interested in the behavior. Thank you again, that was pretty enlightening and makes total sense, it would be stupid if those bullets collided. Gotta take some time to make sure I understand all the Robocode mechanics.

                                  Rsalesc (talk)05:46, 30 August 2017
                                   

                                  After a long night, I just have to say that Bullet Shielding is the hardest thing... ever. You deserve a huge prize, man.

                                    Rsalesc (talk)12:09, 30 August 2017

                                    Thanks ;) Anyway, are you trying to build your own BulletShielder? Worth mention that a lot of good shielders are open source (although I haven't looked into any of them yet).

                                      Xor (talk)14:51, 30 August 2017

                                      Yes, I was. I started reading the tutorial, but I found it really counter intuitive, so I decided to go by the bullet shadowing approach (or very similar to it). I looked at EnergyDome after struggling for a few hours, just to notice that the only difference was the use of Virtual Guns and the multi-movement thing. So it was doing pretty much the same thing I was for the intersection. I got happy and thought I was going to find where my bug could be. At this point I couldn't even shield a single bullet, so the VG thing was not a game changer. It turns out that I couldn't fix it. I'm just supposing it's in the actual intersection algorithm, since I can't even shield against Tracker after moving a fraction of a pixel. It should work easily if was doing things right, correct?

                                        Rsalesc (talk)15:17, 30 August 2017
                                        Edited by author.
                                        Last edit: 15:25, 30 August 2017

                                        Even if your algorithm is correct, it won't work with wrong target. You could try SimpleBot 0.022c, which uses traditional HOT (for stationary bot) with random fire power. If the algorithm is all right, it would at least shield a lot.

                                          Xor (talk)15:22, 30 August 2017
                                            Rsalesc (talk)15:24, 30 August 2017
                                             
                                             
                                             
                                             
                                             
                                             
                                             
                                             
                                             
                                            Oculus doesn't have such problem because it does some checking to be sure that the bullet would hit %100 if enemy movement predicted correctly.
                                            Something like this
                                            boolean fire = (gunHeat == 0 && a.getGunTurnRemainingRadians() < 18 / (currentBattleInfo.distance -18));
                                              Dsekercioglu (talk)10:23, 30 August 2017

                                              I would say just use getGunTurnRemainingRadians() == 0, as any deviation would decrease your hit rate if your statistics is right.

                                                Xor (talk)10:56, 30 August 2017

                                                In the next version I will make it even more precise(with anti-bullet shielding of course). This version uses the angular bot width.

                                                  Dsekercioglu (talk)11:11, 30 August 2017