Difference between revisions of "Talk:Diamond"
m (typo) |
(→Gun work: about 1.5.33) |
||
(34 intermediate revisions by 7 users not shown) | |||
Line 115: | Line 115: | ||
::: Yes of course, (0 < gun heat <= 0.1) is the special tick, I don't even track non-firing waves. --[[User:Zyx|zyx]] 18:59, 22 August 2009 (UTC) | ::: Yes of course, (0 < gun heat <= 0.1) is the special tick, I don't even track non-firing waves. --[[User:Zyx|zyx]] 18:59, 22 August 2009 (UTC) | ||
+ | |||
+ | :: Actually, I always aim based on gun heat=0, no matter what the current gun heat is, since it will be 0 when I fire. But yeah, it's basically to give more weight to firing waves. I also measure "distance away from nearest firing tick", so gun heat = 0.1 is the same as 1.3 (or whatever, based on current bullet power). --[[User:Voidious|Voidious]] 20:28, 22 August 2009 (UTC) | ||
== Names == | == Names == | ||
Line 121: | Line 123: | ||
: Thanks, though I like "DiamondFist" a lot better. =) It's always a fun (and embarrassing) time trying to come up with new movement / gun class names. --[[User:Voidious|Voidious]] 02:22, 22 August 2009 (UTC) | : Thanks, though I like "DiamondFist" a lot better. =) It's always a fun (and embarrassing) time trying to come up with new movement / gun class names. --[[User:Voidious|Voidious]] 02:22, 22 August 2009 (UTC) | ||
+ | |||
+ | == Best Overall Megabot? == | ||
+ | |||
+ | Hmm... Diamond has 4{{sups|th}} place in both RoboRumble and MeleeRumble now. I wonder if this consider as best overall megabot? Right now Shadow took this place. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 11:48, 23 August 2009 (UTC) | ||
+ | |||
+ | : Well, Shadow leads with 2.4 APS points in melee, and only lies back 0.65 APS in one-on-one. Next to that, ShadowTeam is the best team. In my opinion Shadow is still the best allround megabot. This apart from the fact that Diamond really is a hell of a bot. --[[User:GrubbmGait|GrubbmGait]] 14:59, 23 August 2009 (UTC) | ||
+ | |||
+ | Thanks for the kind words, guys. =) I quite agree that [[Shadow]] is still the best overall bot at the moment. He's incredibly dominant in Melee and a PL monster in 1v1. --[[User:Voidious|Voidious]] 16:26, 23 August 2009 (UTC) | ||
+ | |||
+ | Almost, almost there. If ABC won't update Shadow soon, you will get this position in short period of time. Cheer! » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 23:56, 29 August 2009 (UTC) | ||
+ | |||
+ | Well, thanks Nat, I am flattered you think so. =) I may just be a [[Shadow]] fanboy, but I still feel I have a ways to go with Diamond before he could challenge Shadow for that title. Shadow 3.83's lead in melee is still substantial, ~1.3% APS. In 1v1, Diamond outranks Shadow, but Shadow is still 1st or 2nd in PL and crushes Diamond head-to-head. And Shadow is also the best team, whereas I don't yet have any teams code. But unlike rumble scores, "best overall bot" is subjective, anyway, so I'm honored to even be in the conversation... --[[User:Voidious|Voidious]] 04:39, 30 August 2009 (UTC) | ||
+ | |||
+ | Shadow 3.83 is ''retired'', so we now count on 3.84a. Oh, and it would be awesome if the stable result is the same as now (Shadow 3.84a hasn't get enough battle yet so Diamond is currently first =)) About the team, you can easily done it! ABC said that ShadowTeam is just five shadows work together and avoid friendly fire. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 07:33, 30 August 2009 (UTC) | ||
+ | |||
+ | : avoid friendly fire and lose horribly to PolyLunar... ;) --[[User:Rednaxela|Rednaxela]] 16:14, 30 August 2009 (UTC) | ||
+ | |||
+ | : Nah, that's silly. Obviously ABC can revert to 3.83 whenever he wants, or use the 3.83 source code to make 3.85, so it's only realistic to compare to the best version of Shadow. --[[User:Voidious|Voidious]] 17:33, 30 August 2009 (UTC) | ||
+ | |||
+ | == Diamond's Precise Intersection == | ||
+ | |||
+ | Just a note that if you only care the x=''c'' and y=''c'' line segment, which only needed for intersecting wave with robot bound, your code will be much smaller and slightly faster I believe (like Rednaxela and Skilgannon did). Just put plug ''x'' or ''y'' into <math>(x+h)^2 + (y+k)^2 = r^2</math> and solve with single sqrt() to get ''y'' and ''x'' respectively. No need for those dot product and complicated formula use with y=ax+c line =) --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 03:37, 18 April 2010 (UTC) | ||
+ | |||
+ | == Body Color == | ||
+ | curious Observation; I've been running some battles with Diamond lately and notice once in a while it has a red body color...-[[User:Jlm0924|Jlm0924]] 05:23, 22 May 2010 (UTC) | ||
+ | |||
+ | Yeah, in one of his recent updates Voidious wrote in the version history that every now and again the body color is set to a different color =) --[[User:Skilgannon|Skilgannon]] 12:52, 22 May 2010 (UTC) | ||
+ | |||
+ | Yeah... Diamond is named after a comic book character and the alt color schemes are in homage to two of his other identities/costumes. Probably seems really cheesy to everyone else, but I think it's cool. =) --[[User:Voidious|Voidious]] 01:31, 24 May 2010 (UTC) | ||
+ | |||
+ | == Congradulations! == | ||
+ | |||
+ | Diamond continues to take the crown in the Melee Rumble! Congragulations Voidious! -[[User:Jlm0924|Jlm0924]] 15:54, 20 December 2010 (UTC) | ||
+ | |||
+ | Hey, wait a minute - we can't both claim second place! :-P Well, .03 APS in the MeleeRumble is well within the margin of error, and I think your best version was barely ahead of Diamond before, so it's probably just a tie for now. But I can re-release so we can have a clearer picture. --[[User:Voidious|Voidious]] 16:27, 20 December 2010 (UTC) | ||
+ | |||
+ | :LOL :) -[[User:Jlm0924|Jlm0924]] 17:06, 20 December 2010 (UTC) | ||
+ | |||
+ | This talk makes me raaaaather tempted to do a quick hack of a passable 1v1 movement on Glacier... ;) --[[User:Rednaxela|Rednaxela]] 07:24, 21 December 2010 (UTC) | ||
+ | |||
+ | == Gun work == | ||
+ | |||
+ | While I generally assume there are more points to be gained in movement than in targeting at the top of the rumble, I'm just having too much fun in the Gun Lab with [[User:Voidious/WaveSim|WaveSim]] lately to care. Though I've also been finally abandoning the idea of "no points left in improving our guns", which has been repeatedly proven wrong. | ||
+ | |||
+ | I've been back to exploring a new clustering technique (the one inspired by QT clustering), and after a nudge from [[User:Rednaxela|Rednaxela]] I've gotten onto some genetic algorithms to try and tune it. Now turning the GA onto my normal DC (KNN) gun instead. I'm not sure if he wants to keep it a secret until release =), but the updated WaveSim he's working on freaking flies. I can test Diamond's main gun on 1000 battles of data in ~3.5 minutes on my MacBook Pro 2.8GHz (dual core). Sadly, the new clustering is 5-10x slower... But if I can find real accuracy gains with it, I may be able to live with that. | ||
+ | |||
+ | --[[User:Voidious|Voidious]] 17:08, 7 February 2011 (UTC) | ||
+ | |||
+ | So far I'm about 300 generations in. My full data set is 10 seasons of 96 mid-range bots (which Diamond scores ~68-79% against). Each generation runs 50 members (KNN configs) against a random 10-battle data set and fitness is energy ratio. The top third are allowed to breed or mutate into the next generation, then I add some totally random configs too. (Currently it's a 2/2/1 split across those.) I was stopping once in a while to do a full run on the top few of the latest generation, but now my code does a full run of the top 5 every 50th generation (about every 2 hours). | ||
+ | |||
+ | Current Diamond gun (1.5.30) gets 18.44% against the full data set. The best I've seen so far is 18.88%. Shockingly, that config had a zero weight for bullet flight time. I've seen a lot of low or zero weights for that and <nowiki>[time since velocity change / bullet flight time]</nowiki>. Not to conclude that any of that is optimal just yet - my mutation might have been a little weird, and I'd certainly try hand tuning with them added back in first. | ||
+ | |||
+ | So I'm pretty confident this system works well for optimizing against a target data set. The next question will be if I've chosen the right target. And then if I need to re-tune Virtual Guns, or add my Anti-Surfer gun / Virtual Guns to my WaveSim runs. I'll probably try one of these configs in the rumble soon, then turn back to the "Dynamic QT clustering". The clustering uses the same distancing formula, and the gun is really a hybrid with KNN, so it's good to get the KNN stuff optimized first. | ||
+ | |||
+ | --[[User:Voidious|Voidious]] 15:30, 8 February 2011 (UTC) | ||
+ | |||
+ | : Using zero wieghting on bulletFlightTime.. that's interesting... DR uses bulletFlightTime (at the lowest weighting of 1) in melee only... and in Demon, I've been leaving it out.. someTimes I replace it with the bot's closest bot distance... though I've never used any utils to test so far.. (sounds like a sweet testing setup :) To help tune my wieghting I was thinking of doing a similar (simpler version) in Demon.. Run the gun on ticks the gun is hot, to test and tweak the wieghting per individual bot.. Saving the individual wieghts to file. Anyways some of us have some slow and painful testing to do :P Demon's movement operational, but completly out of wack. ( heres where the fresh re-write really hurts) -[[User:Jlm0924|Jlm0924]] 23:53, 8 February 2011 (UTC) | ||
+ | |||
+ | :: Well, the eventual best config (that I put in 1.5.31) had almost a max weight for BFT. But it has gotten me questioning long held beliefs about what attributes are best. Yeah, I'm kind of in love with this testing suite I have going now... WaveSim is super fast and makes it really easy to do crazy stuff with optimizing your gun. Simulated targeting for 265,000 battles on my laptop in like 1.5 days, with only occasional intervention to tweak the GA settings and such. WaveSim only works for 1v1 right now, but I have been wondering about how we could support Melee. Could patch Robocode to somehow let the data collector bot cheat and scan everyone every tick, otherwise you might have to trust interpolated scans checking for hits. --[[User:Voidious|Voidious]] 17:51, 9 February 2011 (UTC) | ||
+ | |||
+ | ::: Robocode can record battles, you could just combine that in with your scans. — <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 17:01, 10 February 2011 (UTC) | ||
+ | |||
+ | So 1.5.31 was no good, but it wasn't any worse than the hand-tuned versions (.26 - .28) that came out of that same test bed. Gonna do another round against a slightly lower ranked test bed, similar to what I used for .25. Also optimized my clustering system by about 15% with the help of some kd-trees. Had to modify it to include findFarthestNeighbor. :-P And so grateful for that iterator in Rednaxela's 3rd gen! --[[User:Voidious|Voidious]] 17:51, 9 February 2011 (UTC) | ||
+ | |||
+ | : Now that I think about it.. with guess factors and displacement Vectors (correct me if i'm wrong, its been awhile since i touched gf) BFT is critical to be matched to your recorded waves and reproduce the firing angle... PIF has no such relationship. If the case of PIF, BFT only serves the same purpose as 'wallDistance' for example... Just thought I'd mention it :) Happy tweaking ! -oh , and 265,000 battles? I wonder how many I've watched the lasted 3-4 years? :) -[[User:Jlm0924|Jlm0924]] 23:30, 9 February 2011 (UTC) | ||
+ | |||
+ | :: Interestingly, no, not even if you were just using raw bearing offsets. The ratio between bullet speed and bot speed determines the range of firing angles that could hit, while the distance cancels out. Bullet power itself matters, though. So it's equally relevant (or irrelevant) for bearing offsets or GFs, I'd say - just an attribute categorizing the situation, like wall distance. If anything, I'd say it's more relevant to DV or PIF because it determines how far you project the movement... --[[User:Voidious|Voidious]] 23:57, 9 February 2011 (UTC) | ||
+ | |||
+ | :: Yes BFT determines how far to project the movement.. but in PIF I measure it seperately. and have no need to use it as an attribute, unless I want to categorize the situation. Am I wrong about DV (and GF)? Don't you need that BFT attribute to determine how far to project the movement ? (I'll check a GFTargetingBot in a sec... Yeah..I think I'm right :P ) -[[User:Jlm0924|Jlm0924]] | ||
+ | |||
+ | :: Well, as far as GF, distance definitely does not matter, so BFT (distance / bullet speed) doesn't. Bullet speed (and thus bullet power) dictates the MEA, so it matters for GF. And BFT matters for DV in the same way. But in both, you don't need to store value explicitly - it goes into the calculation of the GF/DV that is recorded, and then you use the current situation's bullet speed or BFT as part of the firing angle projection from that GF/DV. Maybe we're talking about different things here... =) But it seems to me that distance or BFT are equally un/important to all 3, just useful for categorizing. --[[User:Voidious|Voidious]] 01:48, 11 February 2011 (UTC) | ||
+ | |||
+ | :: yah you hit the nail on the head... and yeah ultimately the same effect.. My one track mind has been buried in my own code to long :) -[[User:Jlm0924|Jlm0924]] 07:31, 11 February 2011 (UTC) | ||
+ | |||
+ | :: My mind has been too buried in all this stuff for too long. :-) --[[User:Voidious|Voidious]] 16:25, 12 February 2011 (UTC) | ||
+ | |||
+ | So, same old story with 1.5.32 - improvement in the lab, .3-.4 APS drop in the rumble. Now moving on to a ~500 bot test bed from nearly the full range of the Rumble population. (Excluded the top 5 and the bottom 20.) Fixing some WaveSim bugs and tweaking my GA stuff in the process. Hopefully I'm closing in on real improvement! =) --[[User:Voidious|Voidious]] 16:25, 12 February 2011 (UTC) | ||
+ | |||
+ | Fairly happy with 1.5.33, which is about tied with 1.5.30. That's a config (cluster size, how fast it ramps to max, and all the attribute weights) evolved with GA in less than a day, seeded with just my current config and 49 random ones. I think fixing one bug in the new WaveSim's min/max angle recording had a big impact. I've now identified bugs in my distance formula (not WaveSim itself) for BFT and time since velocity change, which explains how they could get zero weights so easily. (They were always evaluating to zero.) Now I'm pretty optimistic for this next round of self-optimizing! --[[User:Voidious|Voidious]] 03:41, 14 February 2011 (UTC) |
Latest revision as of 04:41, 14 February 2011
I can't believed it, it almost the same thing I'm doing in my TheRiver! (I have the ideas about displacement vector, but never known that it is called displacement vector) Anyway, nicely done! Here are my result that I just ran if you want (EDIT: more, and the debugging graphics is the exactly same as one I'm creating)
The one problem of this robot is lack of one-on-one performance (or you will never see 9 2nds). I saw it lost to Shadow and Phoenix a lot.
» Nat | Talk » 06:16, 15 May 2009 (UTC)
Rank | Name | Score | Surv. | Bonus | Bullet Dmg. | Bonus | Ram | Bonus | 1st | 2nd | 3rd |
---|---|---|---|---|---|---|---|---|---|---|---|
1st | voidious.Diamond 1.0 | 14361 (13%) | 10850 | 540 | 2807 | 164 | 0 | 0 | 6 | 9 | 5 |
2nd | abc.Shadow 3.83c | 13453 (12%) | 10100 | 630 | 2633 | 89 | 1 | 0 | 7 | 3 | 5 |
3rd | rz.Aleph 0.34 | 12804 (12%) | 9600 | 270 | 2861 | 73 | 0 | 0 | 3 | 4 | 5 |
4th | abc.Tron 2.02 | 12261 (11%) | 8450 | 630 | 3052 | 127 | 2 | 0 | 7 | 3 | 3 |
5th | kawigi.mini.Coriantumr 1.1 | 11909 (11%) | 450 | 360 | 2998 | 101 | 0 | 0 | 4 | 3 | 3 |
6th | florent.XSeries.X2 0.7 | 9472 (9%) | 695 | 90 | 2349 | 84 | 0 | 0 | 1 | 4 | 2 |
7th | ags.surreptitious.MiniSurreptitious 0.0.1 | 9411 (9%) | 6550 | 0 | 2785 | 68 | 8 | 0 | 0 | 4 | 5 |
8th | tzu.TheArtOfWar 1.2 | 9240 (9%) | 6750 | 90 | 2355 | 42 | 2 | 0 | 1 | 3 | 4 |
9th | abc.tron3.Tron 3.11 | 8050 (7%) | 5400 | 360 | 2245 | 42 | 4 | 0 | 4 | 2 | 1 |
10th | davidalves.Phoenix 1.02 | 7443 (7%) | 5550 | 180 | 1679 | 32 | 2 | 0 | 2 | 0 | 2 |
Not so bad... 6th place. Lost to Mellaris, Shadow, Tron and Aleph. But it used to win them in battle full of top melee bots! » Nat | Talk » 10:03, 15 May 2009 (UTC)
I haven't focused on the 1v1 movement much yet, because it doesn't matter as much as other things and I don't want to get distracted by it. (There's no hiding what a 1v1 nut I've been so far in my Robocode career.) But the 1v1 performance is pretty decent, I think it's mainly that the gun has trouble hitting surfers (no accounting for firing waves or gun heat yet). --Voidious 13:38, 15 May 2009 (UTC)
Decent? It's very strong in 1v1! It's 1v1 pairings are nearly complete and it's sitting in 11th place. Though... it does get beat by the top mirror-bot in the rumble :)
Man... all these new bots are not only topping RougeDC which used to be in 12th, but are also causing shifts in ranking of old bots so they're now above RougeDC... damn... I really got to get my new stuff out of the garage to join in on this fun! --Rednaxela 15:38, 15 May 2009 (UTC)
- Thanks! The gun doesn't segment on firing waves or gun heat or anything, so it's not a huge surprise that a mirror movement that is reacting to bullet fire ('cause I'm surfing) works well against it. What kind of gun is on PolishedRuby? And why is there no page anywhere for it? --Voidious 17:38, 15 May 2009 (UTC)
- PolishedRuby is just the gun of the latest RougeDC version, on top of a basic 'goto location' based mirror movement, with very slight alterations to energy management. No page for it because 1) Not much to say about it 2) I'm lazy. Diamond is the highest ranking bot I can see that it beats I think, so it shows well how Diamond's gun is notably lacking (in 1v1) against it's own surfing movement. Of course, I'm considering making a second version of PolishedRuby, which mirror's the enemy's firepower and firing time as well... that might demonstrate it even more clearly... ;) --Rednaxela 18:21, 15 May 2009 (UTC)
Wow -- takes me over a year to make a decent gun and you churn out a brand new top melee and 1v1 bot in what, a month or less? --Darkcanuck 15:46, 15 May 2009 (UTC)
- Thanks, but that's so not a fair comparison. =) Basing anything off the Dookious movement would yield a really nice rating in 1v1, and I've got plenty of experience with DC and Minimum Risk Movement from Lukious and BrokenSword. --Voidious 17:38, 15 May 2009 (UTC)
It lost to a LOT of surfer, count from lowest score: Phoenix, Dookious, Ascendent, RougeDC, CassiusClay, Chalk, Shadow, YersiniaPestis, Gauss, DrussGT, Garm, WeeksOnEnd, Hyperion, LifelongObsession, CunobelinDC, MathcupAGF (not a surfer actually) and PolishedRuby (mirror, as Rednaxela mentioned) Perhaps some weight on firing scan will make you score better. » Nat | Talk » 16:12, 15 May 2009 (UTC)
- Don't remind me, I'm trying not to focus on 1v1 here... :-P --Voidious 17:38, 15 May 2009 (UTC)
I'll give you some time before I resume working on a melee bot :-D Seriously, nice work! And it seems strong in 1v1 too! Are you also using your displacement targeting in 1v1? Or do you switch to regular GFs? --Skilgannon 16:14, 15 May 2009 (UTC)
- I also use the displacement targeting in 1v1, getting about 87 in the TCRM right now (full results soon). One point of note is that I invert the vectors depending on the enemy's orbit direction, just like GFs, but I calculate orbit direction relative to the bot closest to the target (whether that's Diamond or another enemy). In 1v1, it's probably not acting much different than GuessFactors, but in Melee, I think it should work better than GFs. If nothing else, it seems far more "right" to me. I was actually considering "wall smoothing" the vectors instead of throwing out ones that would end up off the battlefield, then it would act even more like GFs. ;) --Voidious 17:38, 15 May 2009 (UTC)
Awesome (re)entrance you made in melee! You and justin really shake up that rusty top-10 there. Seems that in melee the gun is more important than in one-on-one. Maybe it is time to say farewell to my old CT-gun . . . --GrubbmGait 17:29, 15 May 2009 (UTC)
- Thanks. I was surprised how much the gun mattered in Melee. I had it in my head that HoT is OK in Melee because of bots like HawkOnFire. This is partly true, of course. But I developed the basic movement first using only HoT, and when I upgraded the gun, the performance in my test beds shot up dramatically. --Voidious 17:38, 15 May 2009 (UTC)
Just asking quick, does this robot select enemy or do the thing like the one describe at Shadow/ShadowsMeleeGun? » Nat | Talk » 06:42, 18 May 2009 (UTC)
- Nope, nothing like that. I actually don't remember ever seeing that page. Maybe I'll save that idea for when I run into a wall with other improvements. Which might be soon. =) --Voidious 14:07, 18 May 2009 (UTC)
Congrats with going up to 7th in melee (again)! I'm guessing all those red arrows probably have something to do with it. :) --Positive 09:58, 28 July 2009 (UTC)
- Isn't the red arrow present the vector of the displacement vector? » Nat | Talk » 11:35, 28 July 2009 (UTC)
- Thanks! I actually have no idea what caused it. =) I've just been working on the gun for 1v1. The red arrows are just some new graphical debugging in the gun, indicating the firing angles for the most similar situations. The yellow arrow is the chosen firing angle, and the yellow line through the yellow arrow indicates the "bandwidth" used in the kernel density estimator. --Voidious 13:59, 28 July 2009 (UTC)
- Since you said you want these things pointed out to you Nat, "don't you?" would probably be more correct than "ain't you?" in this case I believe. The words "gain the last survivor bonus" behave as a verb, which means it's a matter of "do" or "do not". Well the wikipedia article does say that "ain't" is sometimes used for "do not" in some dialects, but I'd call that a rather obscure and that "don't" would make more sense. --Rednaxela 15:43, 28 July 2009 (UTC)
- Yes, the 1v1 changes can help in Melee, but I've had a lot of 1v1 improvement already and not much of it helped the Melee rating. My best guess is that one of my gun fixes just affected Melee way more than I realized it would... --Voidious 19:16, 28 July 2009 (UTC)
--Rednaxela 02:33, 3 August 2009 (UTC) Nice stuff Voidious! Hm, thinking about this just made my realize that my new surfing code I'm about to begin could also work as a good codebase to build melee movement on. Hopefully I can catch up to this melee activity, because even after I get that movement working I'll need to get a working melee gun since my past guns wouldn't work at all. Nice debugging graphics too btw :) --Rednaxela 15:43, 28 July 2009 (UTC)
- You mean you actually watch battles with interesting new bots/versions? Last time I did that was . . . eh . . years ago. Did you notice btw that in the last few months 4 bots passed the old nr 4 Tron 2.02, which held that place for, well, years? Time to convert my ideas for GraafDracula to real code, so I can take advantage of the momentum and enter the top-3. ;-) --GrubbmGait 18:01, 28 July 2009 (UTC)
- Thanks. =) That Melee top 3 has been the same since I started Robocoding, so I think we all have some catching up to do. :-P If you start work on the Melee movement, you can add simple radar, target selection, and power=3 Head-On Targeting and do surprisingly well. Early dev versions of Diamond were like that. From there, working on the gun and the Wave Surfing was very fun and familiar.
- And I hear you, GrubbmGait. I've watched some battles recently and I find myself thinking stuff like, "whoah, DrussGT is yellow?" =) --Voidious 19:16, 28 July 2009 (UTC)
Woah 6th place! And you made your survival rate a lot higher. Damn, what are you doing to that thing? :) --Positive 01:03, 3 August 2009 (UTC)
- 1.241 through 1.243 have just been changes to bullet power. It's always amusing how the simplest stuff can be worth so many points. =) 1.242 actually had even better survival, but less rating points, so I made it a bit more aggressive in 1.243. I was actually getting pretty discouraged until 1.24... I had barely improved melee performance since 1.0. But now I'm excited and thinking of some new ideas to try. =) --Voidious 01:14, 3 August 2009 (UTC)
- Nice stuff Voidious! Mm... bullet power... I wonder how the adaptive bullet power techniques I used in RougeDC will apply in melee. All this excitement is making me want to stay up very late tonight working on my new melee engine... If only I didn't have to wake up for work tomorrow :) --Rednaxela 02:33, 3 August 2009 (UTC)
Congrats, 4th place now! I'm very curious what you changed this time. :) --Positive 12:29, 12 August 2009 (UTC)
- Thanks! I'm pretty stoked. =) Hope I don't ruin it with an immediate new version, but I realized a bug in the new code (while laying in bed). Basically, I added a "mathematically correct" way of adding a damage taken risk factor (noting that enemies closer to you and enemies that are alive are more likely to do damage, and trying to account for that). --Voidious 12:34, 12 August 2009 (UTC)
- Do you mean that Diamond now tries to never be the closest opponent to any enemy? --Positive 12:48, 12 August 2009 (UTC)
- No, he already did that. =) What I mean is Diamond weights enemies by how much damage he has taken from them (similarly to how Minimum Risk Movement usually weights enemies by their energy, which Diamond does too), but in a slightly less naive way than just using the raw "damage taken from this enemy". --Voidious 12:52, 12 August 2009 (UTC)
- Ahh, okay, that's pretty clever. :) --Positive 12:58, 12 August 2009 (UTC)
- Would I be so bold to guess, that the 'slightly less naive way' would involve normalized hitrate calculations? :) --Rednaxela 13:09, 12 August 2009 (UTC)
- In that spirit, yes, but slightly more naive than what I'd do in 1v1. =) I just account for distance and the time that the enemy was actually alive. --Voidious 13:16, 12 August 2009 (UTC)
- Ahh, I see why the word slightly was used in that case, haha. --Rednaxela 13:26, 12 August 2009 (UTC)
- Since 1.271, which is a slightly bug-fixed version of 1.27, is back to 1.262 rating, I think it's safe to say 1.27 was just luck. =) Oh well... --Voidious 15:28, 12 August 2009 (UTC)
Just a silly question. In Diamond's version history is written that in 1.02 you did "A bunch of gun tweaks, including a gun heat dimension". I believe I've read this in other places too, but never saw an explanation, what exactly do you mean by gun heat dimension? --Navajo 17:39, 22 August 2009 (UTC)
This is basically a measure of how close the measured scan is to an actual firing scan. It an easy way of taking into account bots that react to when you fire, because when you fire your gunheat is 0, so your aiming will be clustered around 0 for the gunheat dimension. I hope this makes sense =), it's not the clearest explanation. --Skilgannon 18:01, 22 August 2009 (UTC)
- Also note, this only applies when one is recording every tick, not just the firing ticks. Essentially, what a 'gun heat' dimension is, is a way to still include data from waves that you didn't actually fire, but bias against those results in proportion to far away they were from the actual firing tick. --Rednaxela 18:05, 22 August 2009 (UTC)
- I think in the gun heat dimension does a bit more than that, because if your gun heat is 0.4 makes you aim considering waves with gun heat at 0.4 more strongly, which makes the gun to aim accordingly to how many ticks it has to turn before firing. --zyx 18:34, 22 August 2009 (UTC)
- Yes, except... at 0.4 gun heat, you're not firing, you're still rotating your gun. It's that last tick of rotation before firing that makes 99% of the difference of if you hit or not really. It's rare that the aim is so far off in the last tick before firing that it won't be able to aim at the optimal location. --Rednaxela 18:48, 22 August 2009 (UTC)
- Yes of course, (0 < gun heat <= 0.1) is the special tick, I don't even track non-firing waves. --zyx 18:59, 22 August 2009 (UTC)
- Actually, I always aim based on gun heat=0, no matter what the current gun heat is, since it will be 0 when I fire. But yeah, it's basically to give more weight to firing waves. I also measure "distance away from nearest firing tick", so gun heat = 0.1 is the same as 1.3 (or whatever, based on current bullet power). --Voidious 20:28, 22 August 2009 (UTC)
Contents
Names
I just looked inside Diamond for the first time, and "DiamondWhoosh"? Nice :) --Rednaxela 01:23, 22 August 2009 (UTC)
- Thanks, though I like "DiamondFist" a lot better. =) It's always a fun (and embarrassing) time trying to come up with new movement / gun class names. --Voidious 02:22, 22 August 2009 (UTC)
Best Overall Megabot?
Hmm... Diamond has 4th place in both RoboRumble and MeleeRumble now. I wonder if this consider as best overall megabot? Right now Shadow took this place. » Nat | Talk » 11:48, 23 August 2009 (UTC)
- Well, Shadow leads with 2.4 APS points in melee, and only lies back 0.65 APS in one-on-one. Next to that, ShadowTeam is the best team. In my opinion Shadow is still the best allround megabot. This apart from the fact that Diamond really is a hell of a bot. --GrubbmGait 14:59, 23 August 2009 (UTC)
Thanks for the kind words, guys. =) I quite agree that Shadow is still the best overall bot at the moment. He's incredibly dominant in Melee and a PL monster in 1v1. --Voidious 16:26, 23 August 2009 (UTC)
Almost, almost there. If ABC won't update Shadow soon, you will get this position in short period of time. Cheer! » Nat | Talk » 23:56, 29 August 2009 (UTC)
Well, thanks Nat, I am flattered you think so. =) I may just be a Shadow fanboy, but I still feel I have a ways to go with Diamond before he could challenge Shadow for that title. Shadow 3.83's lead in melee is still substantial, ~1.3% APS. In 1v1, Diamond outranks Shadow, but Shadow is still 1st or 2nd in PL and crushes Diamond head-to-head. And Shadow is also the best team, whereas I don't yet have any teams code. But unlike rumble scores, "best overall bot" is subjective, anyway, so I'm honored to even be in the conversation... --Voidious 04:39, 30 August 2009 (UTC)
Shadow 3.83 is retired, so we now count on 3.84a. Oh, and it would be awesome if the stable result is the same as now (Shadow 3.84a hasn't get enough battle yet so Diamond is currently first =)) About the team, you can easily done it! ABC said that ShadowTeam is just five shadows work together and avoid friendly fire. » Nat | Talk » 07:33, 30 August 2009 (UTC)
- avoid friendly fire and lose horribly to PolyLunar... ;) --Rednaxela 16:14, 30 August 2009 (UTC)
- Nah, that's silly. Obviously ABC can revert to 3.83 whenever he wants, or use the 3.83 source code to make 3.85, so it's only realistic to compare to the best version of Shadow. --Voidious 17:33, 30 August 2009 (UTC)
Diamond's Precise Intersection
Just a note that if you only care the x=c and y=c line segment, which only needed for intersecting wave with robot bound, your code will be much smaller and slightly faster I believe (like Rednaxela and Skilgannon did). Just put plug x or y into <math>(x+h)^2 + (y+k)^2 = r^2</math> and solve with single sqrt() to get y and x respectively. No need for those dot product and complicated formula use with y=ax+c line =) --Nat Pavasant 03:37, 18 April 2010 (UTC)
Body Color
curious Observation; I've been running some battles with Diamond lately and notice once in a while it has a red body color...-Jlm0924 05:23, 22 May 2010 (UTC)
Yeah, in one of his recent updates Voidious wrote in the version history that every now and again the body color is set to a different color =) --Skilgannon 12:52, 22 May 2010 (UTC)
Yeah... Diamond is named after a comic book character and the alt color schemes are in homage to two of his other identities/costumes. Probably seems really cheesy to everyone else, but I think it's cool. =) --Voidious 01:31, 24 May 2010 (UTC)
Congradulations!
Diamond continues to take the crown in the Melee Rumble! Congragulations Voidious! -Jlm0924 15:54, 20 December 2010 (UTC)
Hey, wait a minute - we can't both claim second place! :-P Well, .03 APS in the MeleeRumble is well within the margin of error, and I think your best version was barely ahead of Diamond before, so it's probably just a tie for now. But I can re-release so we can have a clearer picture. --Voidious 16:27, 20 December 2010 (UTC)
- LOL :) -Jlm0924 17:06, 20 December 2010 (UTC)
This talk makes me raaaaather tempted to do a quick hack of a passable 1v1 movement on Glacier... ;) --Rednaxela 07:24, 21 December 2010 (UTC)
Gun work
While I generally assume there are more points to be gained in movement than in targeting at the top of the rumble, I'm just having too much fun in the Gun Lab with WaveSim lately to care. Though I've also been finally abandoning the idea of "no points left in improving our guns", which has been repeatedly proven wrong.
I've been back to exploring a new clustering technique (the one inspired by QT clustering), and after a nudge from Rednaxela I've gotten onto some genetic algorithms to try and tune it. Now turning the GA onto my normal DC (KNN) gun instead. I'm not sure if he wants to keep it a secret until release =), but the updated WaveSim he's working on freaking flies. I can test Diamond's main gun on 1000 battles of data in ~3.5 minutes on my MacBook Pro 2.8GHz (dual core). Sadly, the new clustering is 5-10x slower... But if I can find real accuracy gains with it, I may be able to live with that.
--Voidious 17:08, 7 February 2011 (UTC)
So far I'm about 300 generations in. My full data set is 10 seasons of 96 mid-range bots (which Diamond scores ~68-79% against). Each generation runs 50 members (KNN configs) against a random 10-battle data set and fitness is energy ratio. The top third are allowed to breed or mutate into the next generation, then I add some totally random configs too. (Currently it's a 2/2/1 split across those.) I was stopping once in a while to do a full run on the top few of the latest generation, but now my code does a full run of the top 5 every 50th generation (about every 2 hours).
Current Diamond gun (1.5.30) gets 18.44% against the full data set. The best I've seen so far is 18.88%. Shockingly, that config had a zero weight for bullet flight time. I've seen a lot of low or zero weights for that and [time since velocity change / bullet flight time]. Not to conclude that any of that is optimal just yet - my mutation might have been a little weird, and I'd certainly try hand tuning with them added back in first.
So I'm pretty confident this system works well for optimizing against a target data set. The next question will be if I've chosen the right target. And then if I need to re-tune Virtual Guns, or add my Anti-Surfer gun / Virtual Guns to my WaveSim runs. I'll probably try one of these configs in the rumble soon, then turn back to the "Dynamic QT clustering". The clustering uses the same distancing formula, and the gun is really a hybrid with KNN, so it's good to get the KNN stuff optimized first.
--Voidious 15:30, 8 February 2011 (UTC)
- Using zero wieghting on bulletFlightTime.. that's interesting... DR uses bulletFlightTime (at the lowest weighting of 1) in melee only... and in Demon, I've been leaving it out.. someTimes I replace it with the bot's closest bot distance... though I've never used any utils to test so far.. (sounds like a sweet testing setup :) To help tune my wieghting I was thinking of doing a similar (simpler version) in Demon.. Run the gun on ticks the gun is hot, to test and tweak the wieghting per individual bot.. Saving the individual wieghts to file. Anyways some of us have some slow and painful testing to do :P Demon's movement operational, but completly out of wack. ( heres where the fresh re-write really hurts) -Jlm0924 23:53, 8 February 2011 (UTC)
- Well, the eventual best config (that I put in 1.5.31) had almost a max weight for BFT. But it has gotten me questioning long held beliefs about what attributes are best. Yeah, I'm kind of in love with this testing suite I have going now... WaveSim is super fast and makes it really easy to do crazy stuff with optimizing your gun. Simulated targeting for 265,000 battles on my laptop in like 1.5 days, with only occasional intervention to tweak the GA settings and such. WaveSim only works for 1v1 right now, but I have been wondering about how we could support Melee. Could patch Robocode to somehow let the data collector bot cheat and scan everyone every tick, otherwise you might have to trust interpolated scans checking for hits. --Voidious 17:51, 9 February 2011 (UTC)
So 1.5.31 was no good, but it wasn't any worse than the hand-tuned versions (.26 - .28) that came out of that same test bed. Gonna do another round against a slightly lower ranked test bed, similar to what I used for .25. Also optimized my clustering system by about 15% with the help of some kd-trees. Had to modify it to include findFarthestNeighbor. :-P And so grateful for that iterator in Rednaxela's 3rd gen! --Voidious 17:51, 9 February 2011 (UTC)
- Now that I think about it.. with guess factors and displacement Vectors (correct me if i'm wrong, its been awhile since i touched gf) BFT is critical to be matched to your recorded waves and reproduce the firing angle... PIF has no such relationship. If the case of PIF, BFT only serves the same purpose as 'wallDistance' for example... Just thought I'd mention it :) Happy tweaking ! -oh , and 265,000 battles? I wonder how many I've watched the lasted 3-4 years? :) -Jlm0924 23:30, 9 February 2011 (UTC)
- Interestingly, no, not even if you were just using raw bearing offsets. The ratio between bullet speed and bot speed determines the range of firing angles that could hit, while the distance cancels out. Bullet power itself matters, though. So it's equally relevant (or irrelevant) for bearing offsets or GFs, I'd say - just an attribute categorizing the situation, like wall distance. If anything, I'd say it's more relevant to DV or PIF because it determines how far you project the movement... --Voidious 23:57, 9 February 2011 (UTC)
- Yes BFT determines how far to project the movement.. but in PIF I measure it seperately. and have no need to use it as an attribute, unless I want to categorize the situation. Am I wrong about DV (and GF)? Don't you need that BFT attribute to determine how far to project the movement ? (I'll check a GFTargetingBot in a sec... Yeah..I think I'm right :P ) -Jlm0924
- Well, as far as GF, distance definitely does not matter, so BFT (distance / bullet speed) doesn't. Bullet speed (and thus bullet power) dictates the MEA, so it matters for GF. And BFT matters for DV in the same way. But in both, you don't need to store value explicitly - it goes into the calculation of the GF/DV that is recorded, and then you use the current situation's bullet speed or BFT as part of the firing angle projection from that GF/DV. Maybe we're talking about different things here... =) But it seems to me that distance or BFT are equally un/important to all 3, just useful for categorizing. --Voidious 01:48, 11 February 2011 (UTC)
- yah you hit the nail on the head... and yeah ultimately the same effect.. My one track mind has been buried in my own code to long :) -Jlm0924 07:31, 11 February 2011 (UTC)
- My mind has been too buried in all this stuff for too long. :-) --Voidious 16:25, 12 February 2011 (UTC)
So, same old story with 1.5.32 - improvement in the lab, .3-.4 APS drop in the rumble. Now moving on to a ~500 bot test bed from nearly the full range of the Rumble population. (Excluded the top 5 and the bottom 20.) Fixing some WaveSim bugs and tweaking my GA stuff in the process. Hopefully I'm closing in on real improvement! =) --Voidious 16:25, 12 February 2011 (UTC)
Fairly happy with 1.5.33, which is about tied with 1.5.30. That's a config (cluster size, how fast it ramps to max, and all the attribute weights) evolved with GA in less than a day, seeded with just my current config and 49 random ones. I think fixing one bug in the new WaveSim's min/max angle recording had a big impact. I've now identified bugs in my distance formula (not WaveSim itself) for BFT and time since velocity change, which explains how they could get zero weights so easily. (They were always evaluating to zero.) Now I'm pretty optimistic for this next round of self-optimizing! --Voidious 03:41, 14 February 2011 (UTC)