|
|
| (131 intermediate revisions by 14 users not shown) |
| Line 1: |
Line 1: |
| − | == ELO inaccuracy ==
| + | For old discussions, see [[Archived talk:Diamond/Version History 20110905]]. |
| − | | |
| − | About "Note: Despite lower ELO, was about .3% APS better than 1.0.", that's not surprising to me at all. Glicko-2 seems to be far more true to a full-pairing APS than ELO was too. Things like this make me glad the new server doesn't just show ELO like the old one :) --[[User:Rednaxela|Rednaxela]] 22:02, 17 May 2009 (UTC)
| |
| − | : Although I had second thoughts about setting the APS as standard ranking decisor, I must agree that ELO is not as reliable as it was on the old server(s). Mind you that ELO is calculated slightly different on this server than on the old ones. --[[User:GrubbmGait|GrubbmGait]] 22:11, 17 May 2009 (UTC)
| |
| − | : ELO scores have recently taken a nosedive, for several reasons. There has been a lot of new activity recently with lots of bots being updated and a few new ones added in -- that tends to shake things up. Also, several long-running bots were removed within a short time period, notably pederson.Moron which once anchored the bottom end of the scale. It's safer to compare APS instead of ELO, especially right now. --[[User:Darkcanuck|Darkcanuck]] 15:18, 18 May 2009 (UTC)
| |
| − | : I only pulled Moron because it seemed fairly pointless. I don't mind if he is returned to shore up a ratings slide, but that seems like giving a cancer patient a Band-Aid. On a related note, a long time ago I got the notion that the average ELO rating of the old rating system was 1600. I dropped the ratings list in Excel and confirmed that the ratings averaged to about 1600. At the time, most people were wondering what I was smoking, dismissing 1600 as anything of relevance. I recently did another averaging of the ratings and found ELO to average at 1413 and Glicko-2 averages 1608. Dunno if it really means anything, but ELO certainly doesn't compare to the old ratings.--[[User:Pedersen|Martin]] 16:24, 18 May 2009 (UTC)
| |
| − | | |
| − | == Avoiding recent enemy locations ==
| |
| − | | |
| − | Well, I found a bug in my risk calculation for avoiding recent enemy locations (fixed but not tuned in 1.071). I really feel like this must be a good idea (because bullets are likely to be headed to those spots), but I hadn't found any rating boost from it yet. Hopefully I can find some points in a re-tuned, bug-free version of this... --[[User:Voidious|Voidious]] 17:25, 21 May 2009 (UTC)
| |
| − | | |
| − | == 1.11* bugs / fixes ==
| |
| − | | |
| − | Man, this [[Performance Enhancing Bug]] really drove me nuts, especially since I have so much trouble testing such a little thing. I think I can live with a .15% APS drop in my "bug-free" 1.115 (versus the "buggy" 1.111). I'm sure I'll continue tuning the randomness of his movement in the future, anyway, and I know there are more performance gains to be had elsewhere. This is long and boring, but I feel compelled to write it out, even if just to have the info "out there" somewhere.
| |
| − | | |
| − | The bug was with my random direction change timer. This timer influences the bot to reverse direction at a random interval (with a [[Minimum Risk Movement|risk]] added for disobeying the timer). If the timer trips while the bot is moving with negative velocity, there would be a risk associated with continuing in that direction, and the bot would soon change direction towards positive velocity. Before the timer trips, there's a risk associated with reversing direction.
| |
| − | | |
| − | With the bug, once the velocity went from negative to zero (or positive), it mixed up its directions and thought that negative velocities were the safer direction. This was caused by two things: it always considered zero velocity to be the same as positive, and it was comparing the possible future heading to the heading from one tick ago (instead of heading from the current tick). So here's the problem scenario:
| |
| − | * Diamond is moving with negative velocity.
| |
| − | * The timer trips, so now there's a risk in continuing in this direction.
| |
| − | * He begins to change direction, eventually hitting zero velocity (or, rarely, as high as +1).
| |
| − | * He notices he's changed direction (because zero is the other direction) and resets the timer, meaning now there is a risk with changing direction.
| |
| − | * But he compares possible movement direction against that of one tick ago, which is a negative velocity, so he thinks that way is the "same" direction.
| |
| − | | |
| − | In short, the direction changing worked fine when moving with positive velocity, but for negative velocity, it was more likely to just stop and then continue in that direction. At this point, I've just removed this timer and tuned the other randomizing factor (risk from recent locations) a bit more.
| |
| − | | |
| − | --[[User:Voidious|Voidious]] 15:32, 26 May 2009 (UTC)
| |
| − | | |
| − | == One thing at a time ==
| |
| − | | |
| − | The changes in 1.12 and 1.121 are a great example of why you should follow the "one change at a time" dogma. From 1.072 (best version at the time) to 1.08, I removed one thing: risk from recent enemy locations, and added another: risk factor based on damage given to enemy. 1.08 went down 0.1% APS, so I thought, "well that's barely beyond the margin of error, I'll just leave it". From 1.115 to 1.12, I restored the risk to recent enemy locations and saw a .25% APS drop. From 1.115 to 1.121, I removed the damage given risk factor and am seeing a .4% APS gain (pairings almost complete). Yay! --[[User:Voidious|Voidious]] 18:25, 27 May 2009 (UTC)
| |
| − | | |
| − | : Bah, a few more battles and it's not even above 1.115. I guess I should be patient (still only at 1,000 battles). Oh well... =) --[[User:Voidious|Voidious]] 21:14, 27 May 2009 (UTC)
| |
| − | | |
| − | == One-on-one ==
| |
| − | | |
| − | At least you start working with One-on-one! » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 14:49, 1 June 2009 (UTC)
| |
| − | | |
| − | Just a little bit to keep myself sane. =) Melee is really hard. Spending a day on 1v1 is therapeutic because I actually know what I'm doing. =) --[[User:Voidious|Voidious]] 14:56, 1 June 2009 (UTC)
| |
| − | | |
| − | Also, I know I've covered this topic ad nauseum already, but I just have to vent: [[Curve Flattening|flatteners]] are so evil!! They entice you with their 50+ scores against CC in the [[Movement Challenge 2K6|MC2K6]] and then they destroy your RoboRumble rating... =) --[[User:Voidious|Voidious]] 16:02, 1 June 2009 (UTC)
| |
| − | | |
| − | : Evil?!? Not if going for PL ;) --[[User:Rednaxela|Rednaxela]] 18:52, 1 June 2009 (UTC)
| |
| − | :: Yeah, yeah, that's what the devilish flattener always says! =) Just kidding, obviously I'll try to tune it better. But they sure are touchy buggers. --[[User:Voidious|Voidious]] 19:13, 1 June 2009 (UTC)
| |
| − | | |
| − | :: Once you get them tuned they can actually give you points. I know on [[DrussGT]] the flattener gives a good 5 ELO points at least. The trick is putting your bot against the enemy with the lowest hitrate that you would want the flattener enabled against ([[Ascendant]] comes to mind) and then putting the threshold just a tiny bit below that. --[[User:Skilgannon|Skilgannon]] 19:56, 1 June 2009 (UTC)
| |
| − | | |
| − | :: Yeah, I've tested removing the flattener from [[Dookious]] and it costs me points (I think it was about 5, too, not to mention killing PL score). The thresholds there are really well tuned and conservative. I'm just feeling greedy now. =) I think I'm going to try to come up with something more clever than just hit percentages (even my carefully normalized ones), like measuring the adaptation rate of the enemy gun, for enabling criteria. Turning the flattener back off when the enemy hit-% drops below the threshold (as I do in Dookious) seems silly from one perspective, because it could just mean the flattener's working, but I've always felt that permanently enabling it carried too much risk. --[[User:Voidious|Voidious]] 20:05, 1 June 2009 (UTC)
| |
| − | | |
| − | ::: Hmm... Normalized hitrates... I should compare those used in RougeDC's firepower selection with the ones you use for flattener enabling :) --[[User:Rednaxela|Rednaxela]] 01:10, 2 June 2009 (UTC)
| |
| − | | |
| − | ::: I tally bullets fired as normal, but bullet hits are weighted by distance and precise escape angle range. So a bullet hit from twice as far away or in a situation with twice as big a max escape angle would count as two hits. (''Edit: Oh yeah, I also subtract 1 from bullets fired for onBulletHitBullet.'') For my bullet power management experiment in Dookious 1.60, I normalized out the same stuff in a different way, but I didn't use precise max escape angles, because I was feeding the escape angle into a formula for testing 300 bullet powers each tick. =) --[[User:Voidious|Voidious]] 01:31, 2 June 2009 (UTC)
| |
| − | | |
| − | :: I've also been thinking about ways to make the flattener smarter, and one was by enabling it when entropy shows that it is predicting where they will shoot better than the regular hit surfing. I haven't tried it yet though. --[[User:Skilgannon|Skilgannon]] 20:33, 1 June 2009 (UTC)
| |
| − | | |
| − | Wow, nearly 1% APS improvement with Dooki's gun, meaning more than half the difference between Diamond and Dookious lies in the gun. I guess the movement is already capable of some pretty nice PL performance, too. Exciting! --[[User:Voidious|Voidious]] 13:59, 13 July 2009 (UTC)
| |
| − | | |
| − | == MeleeRumble cruelty ==
| |
| − | | |
| − | So I feel 99% certain that 1.196 is functionally equivalent to 1.183, but that's a big discrepancy: [http://darkcanuck.net/rumble/RatingsCompare?game=meleerumble&name=voidious.Diamond%201.196&vs=voidious.Diamond%201.183 1.196 vs 1.183]. I recompiled the source I had for 1.183 for a re-release, and it's coming in somewhere between: [http://darkcanuck.net/rumble/RatingsCompare?game=meleerumble&name=voidious.Diamond%201.183b&vs=voidious.Diamond%201.183 1.183b vs 1.183]. A binary comparison of the .class files shows that they are all the same besides one which I never update, so I'm confident the source is right. The MeleeRumble is a cruel, frustrating beast... --[[User:Voidious|Voidious]] 16:02, 10 July 2009 (UTC)
| |
| − | | |
| − | It does make a big difference score to one robot if you fight it under a set of sample robot (which exist in melee) and a battle full of ABC's, rozu's and justin's robots. Although the difference you point isn't as much as I expected. Perhaps we should have a better way to control the melee score. Perhaps we need to weight the score base on the opponent level (which can take from the ranking). But it's a work. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 17:29, 10 July 2009 (UTC)
| |
| − | | |
| − | == Multiple gun waves experiment ==
| |
| − | | |
| − | Well, I'm really surprised this worked, and now I'm wondering if anyone else has tried it before. Whenever I fire a gun wave in melee, I now fire an additional gun wave from the last known location of each (still living) enemy (besides the target). The idea is that I can easily collect gun data from the perspectives of all bots on the battle field, and that hopefully, I'll get a better/faster picture of the enemy movements this way.
| |
| − | | |
| − | A couple bug fixes and a bit of polishing later, I had a 0.74% improvement in my test bed from the new gun waves, on top of a 0.14% improvement with the tweak to the "number of bots" weight (also in 1.283). I'm now looking at a ~0.6% APS improvement in the rumble for 1.284 over 1.282, and not too far behind [[Aleph]]. Yay!
| |
| − | | |
| − | --[[User:Voidious|Voidious]] 15:35, 24 August 2009 (UTC)
| |
| − | | |
| − | I've thought about something similar before, but I've yet to build a real melee gun. Really nice stuff! What I wonder, is what the results would be like if you added other points like the corners to that list, since many bots move relative to the corners as well... --[[User:Rednaxela|Rednaxela]] 15:43, 24 August 2009 (UTC)
| |
| − | | |
| − | : Well, with the way my gun records and reconstructs firing angles, firing waves from the corners for that reason wouldn't have the same effect as if you were using GuessFactors. (The enemy movement isn't recorded relative to the wave source, but relative to the enemy's initial heading.) But indeed, firing waves from additional sources is a good idea to try, and you just gave me the idea to try a "heading relative to nearest corner" attribute... --[[User:Voidious|Voidious]] 16:03, 24 August 2009 (UTC)
| |
| − | | |
| − | Congrats, that's a huge and clever improvement! --[[User:Positive|Positive]] 15:58, 24 August 2009 (UTC)
| |
| − | | |
| − | : Thanks! Still a ways to go before I catch [[Aleph]] or [[Portia]] 1.13, and I don't even want to think about [[Shadow]] 3.83, but I'm very happy for now. =) --[[User:Voidious|Voidious]] 16:03, 24 August 2009 (UTC)
| |
| − | | |
| − | Very clever indeed! That kind of specific melee gun idea is exactly what made Shadow finally break away from Aleph in the rumble. You (and Positive) are not as far from Shadow as you might think, imo. --[[User:ABC|ABC]] 16:58, 24 August 2009 (UTC)
| |
| − | | |
| − | == MeleeRumble 2nd place ==
| |
| − | | |
| − | It seems that no-one noticed, due to the ....Hawk hype, that Diamond passed [[Aleph]] and reached second place. Congratulations [[Voidious]]! And do I read the results of DiamondHawk correctly if I state that your movement is better than [[Shadow]]s, but your gun is holding you back?? --[[User:GrubbmGait|GrubbmGait]] 05:38, 28 August 2009 (UTC)
| |
| − | | |
| − | Thanks for noticing. =) However, [[Portia]] 1.13 actually still has 2nd place by a small margin if he were un-retired. I'm still pretty excited about passing Aleph, though! And yes, I'm surprised by how many points I have left in my gun (and working on it now =)). If the *Hawk results translate linearly, this would put Diamond's movement ahead of Shadow 3.84, which is really exciting (even to be close!), but still a little behind 3.83. --[[User:Voidious|Voidious]] 05:44, 28 August 2009 (UTC)
| |
| − | | |
| − | : How about ask ABC to create Shadond? I'm curious if he will get to the throne (or even SHA3.83?) » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 13:47, 28 August 2009 (UTC)
| |
| − | | |
| − | Now you know what I meant by you and Positive being closer to Shadow than you thought ;). Shadow 3.83 melee movement is just a normal (and very old) Minimum Risk movement, the melee strategy page on this wiki has long contained all the tricks I use. Aleph's movement has probably always been slightly better than Shadow's, but my gun made the difference. At this time I suspect that the strongest combination would be my gun with Portia's movement. --[[User:ABC|ABC]] 15:00, 28 August 2009 (UTC)
| |
| − | | |
| − | Well, perhaps the very strongest combination would be... Shadow's gun, Portia's Melee movement, and Diamond's 1v1 movement, but the 1v1 part would only make a small difference I'm sure... :) --[[User:Rednaxela|Rednaxela]] 15:04, 28 August 2009 (UTC)
| |
| − | | |
| − | : Nah, DrussGT's movement is stronger than Diamond's 1v1. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 15:16, 28 August 2009 (UTC)
| |
| − | | |
| − | ShadowHawk and DiamondHawk gave me a pretty good idea where my gun and movement stand, so I don't feel a need to request Shadond. (That is a hilarious name, though.) I'm quite content to wait until I can challenge Shadow myself. =) ABC (or Positive) is free to make a hybrid if he likes - my code is very pluggable, as always. 1.30 is officially at #2 now, so maybe I'll focus on 1v1 for a bit. =) --[[User:Voidious|Voidious]] 15:21, 28 August 2009 (UTC)
| |
| − | | |
| − | : The only obstacle is RWPCL. So unless you officially gave them permissions, they can't =) » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 15:32, 28 August 2009 (UTC)
| |
| − | | |
| − | :: Oh bah, the statement "ABC (or Positive) is free to" is good enough for all intents and purposes :) --[[User:Rednaxela|Rednaxela]] 15:47, 28 August 2009 (UTC)
| |
| − | | |
| − | (Edit conflict) Diamond 1.30 has definitely passed Portia 1.13 now, so congrats on reaching 2nd place! It's interesting to think about what combination would be best. I think Shadow's movement and gun are quite good for the first few turns of a 1v1 fight, because they don't wait for waves to reach the target (something GF-targeting does have to wait for). In melee, you often only get a few shots while down to 1v1, so it's extra important to have a quick start. --[[User:Positive|Positive]] 15:27, 28 August 2009 (UTC)
| |
| − | | |
| − | : Thanks! I don't understand, why would GF targeting have to wait for waves to reach the target before firing? Diamond sometimes stays still for a moment when it gets down to 1v1, but I'm not really sure why, actually... I should investigate that. --[[User:Voidious|Voidious]] 19:51, 28 August 2009 (UTC)
| |
| − | | |
| − | :: What I mean is that GF-guns can only use a simple targeting method to aim before they have any data, and they only have enough data to make an informed shot after a few waves have hit. A pattern matching can already detect and simulate movement (for example, stop 'n go) before its first waves hit. --[[User:Positive|Positive]] 21:45, 28 August 2009 (UTC)
| |
| − | | |
| − | ::: Oh, of course. But in a Melee battle, you can still use the targeting data you collected during Melee when it gets down to 1v1, right? I don't see why a GF gun can't use that Melee data (as I'm sure Shadow does). Shadow is an awesomely quick learner, though, there's no doubt about that. --[[User:Voidious|Voidious]] 21:56, 28 August 2009 (UTC)
| |
| − | | |
| − | Oh, very nice - congrats! Perhaps this will trigger the release of Shadow 3.85? --[[User:Darkcanuck|Darkcanuck]] 15:56, 28 August 2009 (UTC)
| |
| − | | |
| − | : I sure hope not... =) --[[User:Voidious|Voidious]] 19:51, 28 August 2009 (UTC)
| |
