Tron/Archived Talk
- Sub-pages:
- Tron - News - Archived Talk
|
For the past year Tron has been the only bot I've consistently been impressed by, and the trend continues. I knew you'd knock DT off the melee throne, nicely done! -- Kuuran
Very impressive. Well done!!! (it's nice to see DT out of the top position). I never expected pattern matchers to be useful in melee. How are you dealing with the problem of not having continuous information? -- Albert
Thanks! It uses a very "loose" pattern matcher: every frame (scan) it computes a number, currently speed+distance traveled over the previous 15/30/60/120 ticks "projected" onto the enemy's current movement direction. It then finds the 20 (ATM) most similar scans from the last 3000 (a simple subtraction), and computes the firing angles that would have hit the enemy's center then. From those angles it chooses the one that would have "hit", with a tolerance of 2*bot length, in most of those ocasions... hard to explain, but it works :) -- ABC
Great done ABC,You killed the DT's melee legend,Tron get 200 score more than DT,I think DT would harldy to get champion back.:) Hi,Albert,Nimrod is useing PM for a long time,you can check its code(code is in Nimrod's jar file). -- iiley
I've always been a fan of Tron. Simple movement, yet hard to hit. Excellent in melee and pretty good at 1-on-1 too, and judging from recent results, getting better every day. Keep up the excellent work! -- Ray Vermette.
Again, I can't say enough that I've always thought Tron was brilliant, and it's ability to adapt to the times has exceeded that of any other bot I've ever seen.
That said, I have something strange I've noticed. While the Trons trash DT 1.71 quite painfully in melees, if I include 1.61 everyone seems to drop somewhat significantly. Tron 1.5 still usually wins, and Tron 1.4 does better than it would otherwise, but DT 1.71 seems to drop like a stone, DT 1.61 wins the ones that Tron 1.5 doesn't. Try tossing in DT 1.61 to a few of your tests and tell me I'm not crazy? -- Kuuran
Thanks, I guess it pays to be different... ;) About the strange results, did you clean both DT's data files before your test? I just ran a 500 round battle, Tron 1.5 won, DT 1.61 got 2nd, very slightly ahead of 1.71. I think Paul Evans didn't change much (if anything) of DT's melee strategy from v1.61 to v1.71, it's just that DT's long term learning is very powerfull. ABC
Just like to point out something to you - Tron 2 is outstanding! -- Kawigi
Why thanks a lot, I'm very happy with my latest improvements, I think my new targeting has a lot of potential. With some movement improvements I believe I can make Tron a melee king contender again and maybe a 2nd place 1on1... I'll be on holidays for the next 2 weeks, development will be slower, but I'll bring my laptop with me. ;) -- ABC
GARR! In planning the new segmentation axis I just added to the development version of Fractal, I was sure it would give it a definitive edge over Tron (not that I built it specifically against Tron, but it was sure to be an advantage! :D). So what do I see when I finally test it out against Tron? It doesn't work in the slightest!! It's Tron's little jiggling motion as it moves around that tears the segmentation axis to pieces; in watching Tron jiggle Fractal continuously toggles back and forth across the span of the axis, only serving to confuse Fractal way more. It's quite funny to see a match between Tron and Fractal though, because Fractal's gunning isn't so much the problem as is its movement; while Fractal can hit Tron a semi-reasonable amount of time, Tron doesn't miss. The round barely lasts a couple hundred ticks. In any case, at least it does enlighten me onto a flaw in the axis, which some bots like Tron automatically capitalize on (Fractal itself for example, another being SandboxDT of course). I need to rethink and rebuild the axis from scratch to compensate for this problem; luckily, most of what I'll rebuild for it will be useful when I rebuild Fractal's movement. Anyway, keep up the good work with Tron! :D -- Vuen
I have a flag to turn it off (zigzag=true/false), I have tried many times to optimise the movement without it, but everytime I reach the conclusion that it's better to leave it on. :) -- ABC
This v3 movement for Tron. Is it WaveSurfing? -- PEZ
Yep, no more HeadOnTargeting problem bots... I just finished the first 500 rounds test, a tie against RaikoMX 0.29, slightly better than I expected. ;) -- ABC
Cool! I started a Tron-moving wave surfer some weeks ago, but never finished it. It's not Tron if it's not Tron anyway. =) -- PEZ
Well, this version of Tron is not very Tron, the fist sentence on this page reads "Tron is a melee speciallist"... --- ABC
Yeah. But wave surfing in melee could get pretty confused I guess. -- PEZ
BlestPain is trying to do it, though. -- Kawigi
I think maybe an APM movement would work better in melee, I'll see if I can come up with something after I optimise the 1on1 movement. For now I'll just plug Tron's old melee code into it's new structure, afterall it still ranks pretty high in the melee rumble... ;) -- ABC
I've been playing around with MeleeAPM with little success. I've been trying to encorparate it into a minimum risk type movement, avoiding the predicted point by adding a gravity to it. It may just be because my PM works purely on absolute position change, but it seems to make my bot oscillate and not flee big groups of angry robots as i'd like it to. This is probably due to my implementation. The other problem is the number of turns i skip. predicting my position for each enemy on the battlefield is really really slow, so i narrowed it down to whether i was the closest opponent or whether they had fired at me in the last 150 ticks. Even searchign 7 scans over a 1000 scan record i skip 30+ turns a round. I may just trying pattern matchign from the target. the only good thing is taht at the moment i can beat the current Tron in melee. YAY!! --Brainfade
My client is complaining about version 3.02, it can´t download it:
F:\Java\robocode\robots>java -Dsun.io.useCanonCaches=false -Xmx256M -cp .;../rob ocode.jar;../codesize.jar; roborumble.RoboRumbleAtHome ./roborumble/roborumble.t xt Iteration number 0 Downloading participants list ... Downloading missing bots ... java.util.zip.ZipException: error in opening zip file Downloaded file is wrong or corrupted:abc.tron3.Tron_3.02.jar Could not download bot abc.tron3.Tron_3.02.jar Ignoring abc.tron3.Tron_3.02.jar: .\abc.tron3.Tron_3.02.jar (O sistema nÒo pode encontrar o arquivo especificado) Ignoring abc.tron3.Tron_3.02.jar: .\abc.tron3.Tron_3.02.jar (O sistema nÒo pode encontrar o arquivo especificado) Downloading rating files ... Preparing battles list ... Using smart battles is true Executing battles ... Fighting battle 0 ... mz.FemtoGod 1.1,cx.nano.Smog 1.5
-- Axe
Strange, can you manually download it from http://robocode.aclsi.pt/tron/abc.tron3.Tron_3.02.jar? I'll upload a new version as soon as the repository goes back online.
Btw, i´m trying SilverSurfer version 2.12 without any saving data. It is similar to version 2.07, that scored 2009.46... Let´s see the difference. -- Axe
Looks like it makes a big difference in your case, is that version exactly the same as 2.07? Pre-saved data should probably make a difference if your adapting speed is slow... -- ABC
~ 25 pts. difference, exactly the same code as 2.07. This makes a lot more sense to me than your zero pts... But it depends, probably, in how u segment the hitten GFs. I am using 27 segments (3 for distance, 3 for acceleration & 3 for absolute velocity). Without the saving, a HeadOnTargeting (for example) can hit me at least 27 times in each match... Btw, (if u dont mind telling us) how do u segment your WaveSurfing? If you have less segmentation, it can explain the zero diff without saving. I don't think that the pre-saved data make all that diff, although i'll try a version today with saving and without pre-saved... -- Axe
It might be that Shadpw doesn't only surf on hits. It also surfs on visits, making it flatten its curve quite fast. At least I think this is so. Bots that only does adaption (like Pugilist and I think SilverSurfer?) only learn the hard way and thus can gain quite a lot with data saving. Hmmm. Maybe I can break the 2K barrier by making a mega P that saves EnemyWave data? Tempting to try... But then if I succeed I might not be hungry enough to push my mini P beyond that dream limit. -- PEZ
Like I said, I tried countless wavesurfing variants. The 2.48 to 2.49 jump (that put me in the 2kclub) consisted in the removal of the flattener. Shadow 2.49 surfs hits only, segmented by distance (9), acceleration (3), speed (3), and using 19 bins. I also increased the data smoothing (adapting speed) a lot, smoothing the data not only across bins but also across segments. That way Shadow only needs to take 1 hit from a HeadOnTargeting bot to instantly dodge it "perfectly". And that's where, imo, most of the ranking points come from. -- ABC
YES! That's how to do it! Thanks for sharing! -- PEZ
Bloody brilliant. That way you can have more segments, without "paying the cost" for it. Now it makes a lot of sense the zero diff without saving. Highly adaptive. Congratulations, and thanks for sharing... -- Axe
(edit conflict) You are (both) welcome, glad I could help. I wouldn't go the data saving way, I'm sure it is possible to reach 2k points with a mini without it, and you (PEZ) are just the guy to do it (Rozu seems to have given up). Good luck. :) -- ABC
I sure will try! And rozu might wake up now when his minibot is challenged. =) I have no idea how to smooth across segments with my 34 bytes though. Data saving is out of the question too of course. Even if I might be able to fit data restore... But it's much more fun without all that data saving stuff so I won't go that path just yet. -- PEZ
An implementation question for you. I don't know if you have noticed the problems I had with smoothing the edge bins? (The edge bins don't have neighbours on boths sides so they presumably get a too low smoothed count.) Do you think this is a real problem? And if you do, what strategy do you have for countering it? If it is a real problem I guess it get even more important to deal with it when smoothing across segments. -- PEZ
OK, there's no way I can fit segment smoothing. But I now try with using two sets of visit counts. One unsegmented and one segmented (5 distance, 3 bullet power) using the unsegmented one when the segmented one is unvisited. I doubt this will make a huge rating difference, since P already avoids head on fire as perfect as it can while still wall bouncing as much as it does. -- PEZ
I don't have a definitive answer for the edge smoothing problem... I thought a lot about it, but I don't remember how (if) I solved it. How do you deal with it in your GF gun?
Another kind of solution for the learning speed problem I used in some versions of Shadow is to compute the danger of each set of possible segmentations by either using multiple sets of visit counts or just summing the sub-segments. It also worked very well, I did something like this:
gfDanger = danger2 * dists * acels + danger1 * dists + danger0
where danger2 is the most segmented visit count, and danger0 is the sum of every visit to the current bin (no segmentation). With this kind of solution you only need bin smoothing to garantee the fastest possible learning rate against simple guns.
I would expect veteran GF gun coders to know how to solve these problems better than me. :)
-- ABC
I don't smooth my gun GFs. Not that I haven't tried. I have tried it in at least five different ways. But I have never seen it result in better performance. I have now removed the edge smoothing in Pugilist. It doesn't seem to make a difference against my fav test bot (Lacrimas).
Your suggestion for learning speed improvements is about what I ended up doing. Well, as much of it as I could fit in 35 bytes that is. =)
-- PEZ
