Talk:Glacier

0.1

I know 4th place is no surprise after your GlacialHawk releases, but debuting at 4th place above Aleph is still a very nice job. Congrats. =) --Voidious 14:13, 26 September 2009 (UTC)

Thanks. Honestly, 4th place was a surprise for me despite the strong gun proven in the GlacialHawk releases. I'd only given Glacier's movement one test before release: Glacier 0.1, GlacialHawk 1.10, and 8 HawkOnFires. In that test Glacier outscored GlacialHawk barely, but that was somewhat unsurprising: Glacier's movement is a min-risk movement that is extremely focused on HOT dodging and will assume everyone fires HOT. In the case of a bunch of HawkOnFires, that assumption holds true, but I had serious doubts about how it would operate in the wider melee field. I expected it to fall at least behind Aleph in the ranks, but it seems that it turned out to rank a little better than GlacialHawk. --Rednaxela 14:25, 26 September 2009 (UTC)

Congrats for me also! Being able to dodge HOT is very important, using that you immediatly dodge some circular targeting when your perpendicular velocity=0 as well. :)--Positive 20:53, 26 September 2009 (UTC)

Wow, this looks like a really serious contender! I don't envy you trying to fine-tune your movement, given how strong GlacialHawk already is. --Darkcanuck 22:24, 26 September 2009 (UTC)

Thanks Positive and Darkcanuck... looks like my movement has a long road ahead... particularly with the way that Portia's score jumped when it gained wavesurfing ability there. By the way Positive, I consider it quite impressive how quickly you got some wavesurfing working there :) --Rednaxela 05:01, 27 September 2009 (UTC)

Wavesurfing at the end of the melee match

Here's a little question I have about wavesurfing at the end of the melee match for Voidious/Positive/ABC: When using wavesurfing in the 1v1 stage of a melee battle, do you only start learning any wavesurfing data after it becomes 1v1, or is there soem data you carry over from the melee stage? If not, any plans to maybe do so? --Rednaxela 05:05, 27 September 2009 (UTC)

I don't carry anything over from melee. I'd be very hesitant to learn surf data from the melee portion, since you never really know if an enemy was aiming at you when they hit you, but I have considered trying it. You can probably learn if they use HOT or not pretty consistently, but I default to HOT dangers anyway. --Voidious 05:10, 27 September 2009 (UTC)

I'm not using any melee data either, for exactly the same reason as Voidious. Portia does try to collect data during melee, but only for bullets that only fall in Portia's escape angle and not in anyone elses. Those are only about 3-12 hits for a 35-round match. --Positive 15:18, 27 September 2009 (UTC)

Angled Distance

What is angled distance? I try to follow your trig, but fail. Thank you in advance. --Nat Pavasant 13:51, 28 September 2009 (UTC)

Well, it's the way that Glacier characterizes the distances/directions to the bots surrounding eachother. How/why it works however, is not something I can really explain without a diagram. I'll draw one up to explain tonight. --Rednaxela 17:39, 28 September 2009 (UTC)

I'm waiting... --Nat Pavasant 05:43, 30 September 2009 (UTC)

I've been very busy with course work and class lately, I'll have the diagram to explain it in the next few days anyway --Rednaxela 05:48, 30 September 2009 (UTC)

Take your time, don't worry. I have plenty of time now for that I just finished my final. Nat Pavasant 06:10, 30 September 2009 (UTC)

It's like this

The green square is the bot being measured. The arrow is the direction it's moving. The blue squares are surrounding bots. The thin black lines are the lines between the bots, and the thick black lines go on perpendicular to them. The orange lines are the "angled distance" measures from fixed angles relative to the measured bot's heading. Note, they can be infinite when there is no other bot on the measured side. For a segment, I used 1/angledDistance, with a special case of 0 when angledDistance is infinity, since 1/inf=nan. Hope that explains it Nat. I find it gives a good and easily segmentable measure of what opportunities of movement are open to a melee bot. --Rednaxela 00:21, 11 October 2009 (UTC)

The angle from robot's heading to the orange line is fixed, right? --Nat Pavasant 02:01, 11 October 2009 (UTC)

Yep, that's what "fixed angles relative to the measured bot's heading" means. --Rednaxela 03:52, 11 October 2009 (UTC)

Thank you. Got it. --Nat Pavasant 04:04, 11 October 2009 (UTC)

Melee Segmentation

Reading old wiki page randomly, and ran across this page oldwiki:FloodHT/Hype. Kawigi said that he manage to create working antigravity segment. Have you read that page before? --Nat Pavasant 04:04, 11 October 2009 (UTC)

0.2.x

Ugh... a drop of over 1 in both APM and Survival... without making any changes that are expected to have any measurable impact... Will have to fix this before I get to building some melee surfing =\ --Rednaxela 16:31, 17 October 2009 (UTC)

Looks like I've discovered two things here: 1) Accepting predictions which are up to 0.1 units out of map bounds is measurably beneficial, and 2) Choosing an optimal radar direction to start hurts score for some reason (either I start moving too early, or early targeting data makes overall targeting worse). I didn't expect either of these things at all... --Rednaxela 12:49, 28 October 2009 (UTC)

That is really odd, particularly the radar thing. Stuff like this drives me insane sometimes. =) While I will usually just settle for the best performing setting, sometimes I stand strong and do what I feel is "correct", hoping it will pay off eventually. The radar thing strikes me as a situation where I might take that attitude. Obviously, maximizing your scans is objectively better (right?), so it could only be some deficiency elsewhere in the bot that makes it perform worse. Keeping the better radar and then using this situation as clues for future changes should (ideally) lead to better performance than leaving the sub-optimal radar. Then again, there are probably other areas of the bot where your time is better spent, anyway... And I'm probably just echoing your current thought process already. I feel your pain. =) --Voidious 19:21, 28 October 2009 (UTC)

Well, yeah. My current thought, is that perhaps I'd get better performance with the optimal radar starting direction if I implemented a rule of "don't start moving or recording data until all enemies have been found". Currently, it starts recording data and starts moving when it only knows the location of SOME enemies, which I can see as being problematic now that I think about it, particularly given how the gun's segmentation is highly sensitive to the relative position/orientation of enemies. After I make one more release to sort that out... my priority will be with begining implementation of my take on melee-surfing... --Rednaxela 19:28, 28 October 2009 (UTC)

Doh, turns out the real cause of the radar change losing points, was that I accidentally created a bug that caused the radar to get caught up on the 'ghost' of a bot and lose track every once in a while. Now I'm releasing 0.2.5 with some rather drastic/experimental radar changes.... It's a fun release to watch I think... :) --Rednaxela 04:45, 29 October 2009 (UTC)

Wowzers! 0.2.6 is really looking successful so far! "Glicko-2" and and "common % score (APS)" are both predicting this release to be about on-par with Shadow, and all it took were some experimental radar tweaks that I didn't expect to help very much. It's looking like this radar experiment is really letting me get far more scans when there are lots of enemies, meaning my gun gets considerably better data and my movement can react quicker... Hopefully I'm not speaking too soon :) --Rednaxela 15:01, 29 October 2009 (UTC)

Alright, now that is has 400 battles instead of 100, the results are settling down closer to 0.2.4, but it's still looking like a measureable improvement where I didn't expect much of one. --Rednaxela 16:12, 29 October 2009 (UTC)

Melee radar

So, care to share your idea of an optimal melee radar? Does it take into account the possibility of an enemy staying out of range for some time? That's the hardest problem I remember when I was optimising Shadow's melee/teams radar. A good melee radar may not be worth a lot of points, but where is the fun in coding those 1on1 one-liners? :) --ABC 14:00, 3 November 2009 (UTC)

Well, the main trick, is that I track how much 'uncertainty' there is in the angle to a bot that I haven't seen in the last tick. That is calculated via 2*asin((8*age_of_last_scan_data)/(2*distance)), with a special case of just returning pi when asin would return NaN (means total uncertainty). Better can be done with precise prediction but I don't think that's worth the bother. I calculated the angle the radar would need to turn to point at the last known location, and then add the uncertainty to the magnitude of that value. Then by using such turning values with uncertainty added on, if radar isn't going to keep spinning, I make sure to not turn any further than is absolutely necessary to ensure I see the bot. As far as enemies staying out of range, I don't have any explicit logic for this, but the radar's logic is designed so that if the uncertainty of a bot's location becomes completely uncertain, it will become a plain spinning radar which I think is safest if the location of any bot is totally unknown. I also make sure to adjust for where my movement plans my location boe be next tick, like done in some guns. I like how the result looks in 1v1, because it creates an incredibly narrow radar which somehow never slips :P Any comments? --Rednaxela 14:27, 3 November 2009 (UTC)

Cool! Portia ignores out of range robots and does a full sweep every 100 ticks. I added this logic into it because Portia often ends up in corners, and can't see the opponents in the opposing corners there. :) --Positive 14:52, 3 November 2009 (UTC)

Hm... that just made me think... maybe I should actually bother to make an effort to limit uncertainty based on walls, perhaps even by precise predicting... because the primary case of losing track of enemies is when in opposite corners from eachother... and if I'm close enough to the corner, it's sub-optimal for the radar to be doing a full circle no matter where the enemies are. --Rednaxela 15:40, 3 November 2009 (UTC)

Yes, that's true. I've actually been thinking about making some system that knows the approximate location of the opponents, so that although your bot does not know the exact position, it does know that opponent is not behind it in the corner. To implement that correctly is more challenging than I would have thought though. :) --Positive 16:04, 3 November 2009 (UTC)

I think you would agree that there is no "optimal" melee radar, then. There will always be compromises, have you tested your bot in a huge arena? I remember preparing Shadow's for a 5000x5000 melee competition, lots of cool radar and movement tweaks. And you guys should try some team battles, what if you don't need to scan all opponents because your team mates can share that info with you (with 1 tick delay to confuse things even further ;))? --ABC 18:12, 3 November 2009 (UTC)

Well... I was too impricise. Glacier's radar is "as optimal as possible without accounting for walls, when optimizing to reduce the maximum time between scans of a bot". Happy now, haha? About team battles, I already have a decent team radar system in Polylunar, though it could use a little work. --Rednaxela 19:54, 3 November 2009 (UTC)