|
|
| Line 1: |
Line 1: |
| − | Greetings! Welcome to the Robowiki Zyx! Feel free to ask any question you might have! Btw, [[Newton]] seems pretty strong, care to tell us about it or [[AntBot|Ant]]. Best wishes in your robocoding adventures! --[[Rednaxela]]
| + | {{Navbox small |
| − | | + | | title = Archived Talks |
| − | Thanks [[Rednaxela]], I was just writing my "story" when you posted, I will expand [[Newton]] and [[AntBot|Ant]] in a couple of minutes. -- [[Zyx]]
| + | | namespace = User |
| − | | + | | page1 = Talk Archive 20090506 |
| − | Wow, how did you find [[Stormrider]]? It's been out of action for ages.... If you want a version that is slightly newer, and much stronger, take a look at DrussGT, it's download link is on the RoboRumble/Participants page. Anyways, welcome to the wiki, and good luck with your coding =) If you have any questions feel free to ask. -- [[Skilgannon]]
| + | | title1 = 2009/05/06 |
| − | | + | }} |
| − | Hehehe [[Stormrider]] was on the new wiki in the [[Bots]] section, and it said it was very competitive so I downloaded it. I was really new to everything at the moment, now I'm more settled, I'm running RoboRumble so I have [[DrussGT]], BTW congrats man, it seems to be very comfortable at the top place :). Thanks for the help and for killing my bot so I'd be interested in learning more. -- [[zyx]]
| |
| − | | |
| − | :(Oh he may be comfortable at the top for now, but I'm determined to topple [[DrussGT]] eventually... Can't have it's reign last as long as Dookious's did... :) --[[Rednaxela]])
| |
| − | | |
| − | :Sounds like a neat goal, good luck at it :-). -- [[zyx]]
| |
| − | | |
| − | :I've still got a few tricks up my sleeve, I just haven't had time to implement them. Involving both guns and movement. And new types of stats. But come on, I'm studying Mechanical Engineering and you're doing Computer Engineering, surely you should have passed me ages ago? ;-) And I've been hearing that you were working on RougeDC's replacement in little snippets here and there, are you ever going to release that to the rumble? -- [[Skilgannon]]
| |
| − | | |
| − | :Haha, RougeDC's younger and stronger brother doesn't have much done yet... but I'll probably make a hard drive to get at least the gun working in winter break... and my hope is that current generation surfers will be in for some hurt... ;) -- [[Rednaxela]]
| |
| − | | |
| − | Oh, and sorry for cluttering your talk page with rivalry Zyx :) --[[User:Rednaxela|Rednaxela]] 21:39, 26 November 2008 (UTC)
| |
| − | | |
| − | :That's what talk pages are for ;) -- [[zyx]]
| |
| − | | |
| − | == Dynamic Weighting ==
| |
| − | | |
| − | Do you know of any bot that calculates the weights for [[Dynamic Clustering]] during a battle? Actually if it calculates it's segmentation, or something like that on real time is enough for me. I want a bot that ''learns'' how the enemy is learning. I'm currently working on a DC based bot that uses VCS to adjusts the weights for the ''distancer'' with very promising results. I know many people have used offline methods to do this, I want to know if there is a bot that actually does it during the battle. --[[User:Zyx|zyx]] 21:06, 12 April 2009 (UTC)
| |
| − | | |
| − | Me, [[Voidious]], [[Simonton]], [[ABC]] and I'm sure others have tried, all without any real success. My methods have included: 1) finding entropy between profile-peak height and any of the attributes (running during non-firing ticks), 2) pulling clusters with each weight modified both directions and seeing which clusters are most accurate with the VG, 3) checking which attribute has the least variation in the last X GFs which were within a certain window and increasing that attribute's weight. So far what we've all found is that a hand-tuned set of weights performs just as well and runs many times quicker. I'm actually dealing with a similar issue in [[Wintermute]], except in the movement, where I'm reluctant to use anything except BulletHitBullet events for changing the weightings because the HitByBullet is affected by what your weights already are. In fact, because the bot probably moved to a safe place for the highly weighted system, it will decrease the weighting for that system (because it got a hit in an area where there shouldn't be any danger), making it cycle between systems that might not be optimal. I know you use something similar in [[YersiniaPestis]], did you take this into account? Did you manage to find a way around it? --[[User:Skilgannon|Skilgannon]] 21:38, 12 April 2009 (UTC)
| |
| − | : For the movement I haven't come up with anything better than hand-tuned yet, for the gun I'm doing the following. I keep evenly segmented VCS for each attribute I have in the tree, and then have the following algorithms in a VG array to adjust weights, I run this every time a wave passes the enemy.
| |
| − | | |
| − | :* Visits/TotalVisits. Where Visits is the number of visits I have for the spotted window in the wave segment for each attribute and TotalVisits is the sum of all visit counts in a single segment(all segments have the same amount bins updated so is the same for each one).
| |
| − | :* Visits/WindowVisits. Visits is the same as above, and WindowVisits is the sum of all visits in the current factor window across all segments.
| |
| − | :* Each attributs weight is the sum of the standard deviation of all it's segments.
| |
| − | | |
| − | There has been many others, but these 3 have the best performance. The first two are kept in rolling averages. And all three, are kept as mentioned and later normalized to have a unit vector of weight. I have this on a new bot, because I wanted to get [[YersiniaPestis]] in the DC party, so I can't compare one to one yet, but after the tests are done and I decide the best numbers for rolling depths, number of bins, number of slices, etc. I will add the best one to [[YersiniaPestis]] and see if it performs better with no other change. But the new gun has over 2 points on (my slightly modified) TC index, the problem is that the weighting system is not the only difference. --[[User:Zyx|zyx]] 23:11, 12 April 2009 (UTC)
| |
| − | | |
| − | Another thing, what you say about the way I update my movement on HitByBullet makes a lot of sense, I will try a version that only updates on BulletHitBullet to see. But on the other hand, it was hit on place where there seemed less danger, then real question might be, why did he think there was not a big danger. In any case, my biggest learning experience in Robocode is that guessing what is good is nonsense, trying is the only way to realize the truth. --[[User:Zyx|zyx]] 23:15, 12 April 2009 (UTC)
| |
| − | | |
| − | * I've also pondered over both, but my conclusion was that there will always be 'random noise' that your movement cannot account for, and that the HitByBullet will *ONLY* give results that depreciate the highest weighting system. The big disadvantage is that the learning speed goes down a lot when only using BulletHitBullet.--[[User:Skilgannon|Skilgannon]] 06:28, 13 April 2009 (UTC)
| |
| − | | |
| − | Quick question, I'm currently testing about 7 versions of a modified [[YersiniaPestis]] 1.3.7 to use dynamically adjusted weights, I still don't know if any of them will be better. But in case I found a better version should I upload it to the Rumble? I wouldn't be keeping it in the rumble because I want him to be a pure DC bot, but my new bot is probably not going to be ready to release in a couple of days, and even if it is, is not a good comparison because is a different bot in many other ways. I will anyway post download links to better versions using the new system so you can all see how it does, but would it be politically right to upload it to the rumble just to ''prove'' that dynamic weights are good? I would of course be running a client if I upload it, but since I don't feel that uploading should be taking so lightly, I don't know if it would feel right. Also I test again only a handful of bots, my current test bed is the MC2K7 reference bots, plus the top 6 bots, 3 pattern matchers, and 3 very simple bots. I've found that this tests have been very accurate to a bot being better than another one compared to the real rumble results, but I'm sure you all agree that the real rumble is a bit unpredictable sometimes. I'll let you know about the test results sometime when I have them, I have too many bots being tested right now, so results take hours to finish a single season. --[[User:Zyx|zyx]] 01:45, 13 April 2009 (UTC)
| |
| − | | |
| − | : I say go for it. I don't think it's a big deal to post a test version to the rumble, especially if you're running a client and doing all that local testing. Though I almost feel like an outsider to the RoboRumble at this point, so take my opinion for what you will. =) --[[User:Voidious|Voidious]] 02:07, 13 April 2009 (UTC)
| |
| − | :* You've done too much for Robocode to be an outsider. The new bots have completed one test season and the best one is 2 points over in APS, I know 1 season is not close to accurate, but if it is actually that much better I'll drop the ''pure DC'', I already got into the DC party with a pure DC bot, there is no good reason to dismiss a seemingly good improvement. What I think now I would do if the new system is measurably better, I'll make a mixed one with some hand-tuned and some dynamic weights in the VG array and release it as the next version instead of just test bot. --[[User:Zyx|zyx]] 04:51, 13 April 2009 (UTC)
| |
| − | : You can change it to start using VCS any time you want, you've made top 10 with DC so you're part of the party now =). I removed [[Stormrider]] from the rumble because I felt it was too similar in code to [[DrussGT]], but as far as I know I'm still a member =) --[[User:Skilgannon|Skilgannon]] 06:28, 13 April 2009 (UTC)
| |
| − | | |
| − | Just entered YersiniaPestis 1.3.7.2 in the rumble, the only real difference is I added 5 new Distancers to the gun, all from the types I explained above, 2 of the first type, 2 of second type and 1 of the third. The ones that have two of same type is because one have a lower rolling depth than the other. My initial guess is that it will be better APS-wise, but it may lose the PL-crown. I still kept my hand-tuned ones, but they have lower priority than the new ones, and those were tuned to beat top bots rather than simple ones, hopefully it will still hold it's ground, we'll see. --[[User:Zyx|zyx]] 02:23, 14 April 2009 (UTC)
| |
| − | : Removed version 1.3.7.2 from the rumble, results were bad, but I still think there is potential here. I'll keep working and post if find something interesting. --[[User:Zyx|zyx]] 04:59, 16 April 2009 (UTC)
| |
| − | | |
| − | == Sneak Attack ==
| |
| − | I just realized there are ways to shoot completely undetected bullets, I tried to make a bot based on that but I can't find an easy way to use the exploit and be competitive at the same time. So I decided to just post how to fire undetectable bullets, I haven't really searched, so maybe this has been said elsewhere.
| |
| − | | |
| − | I think most surfers have some way to detect (as good as they can) when their enemy hits a wall so they are not confused by that energy drop. So if you run towards a wall at some speed, let's say full speed (8), and when you are just about to hit the wall you decelerate and a fire a 1 power bullet. Your enemy will calculate your damage as 8 / 2 - 1 = 3, but you were actually going at 6 at the hit time, so you got 6 / 2 - 1 = 2 wall hit damage, but since you shot a 1 powered bullet they won't see anything strange as your energy dropped 3. And even if someone has thought of that, and took the guess that maybe the bot decelerated you can shoot only sometimes, and make him surf bogus waves.
| |
| − | | |
| − | This bot shows how to shoot the invisible bullets, it bounces on and off from the top wall (sometimes the bottom) and shoots head on, so it will lose to almost every(if not all) bots. But I challenge anyone to try and detect accurately when he fires. My bots detect some of them, but is not even close to accurate.
| |
| − | <pre>
| |
| − | package zyx.nano;
| |
| − | | |
| − | import robocode.AdvancedRobot;
| |
| − | import robocode.HitWallEvent;
| |
| − | import robocode.ScannedRobotEvent;
| |
| − | import robocode.util.Utils;
| |
| − | | |
| − | public class SneackAttack extends AdvancedRobot {
| |
| − | static int direction = 1;
| |
| − | private boolean nh;
| |
| − | private int t;
| |
| − | public void run() {
| |
| − | while ( true ) {
| |
| − | if ( getRadarTurnRemainingRadians() == 0 ) setTurnRadarRightRadians(Double.POSITIVE_INFINITY);
| |
| − | execute();
| |
| − | }
| |
| − | }
| |
| − | public void onScannedRobot(ScannedRobotEvent event) {
| |
| − | double bearing = getHeadingRadians() + event.getBearingRadians();
| |
| − | setTurnGunRightRadians(Utils.normalRelativeAngle(bearing - getGunHeadingRadians()));
| |
| − | setTurnRightRadians(Utils.normalRelativeAngle(-getHeadingRadians()));
| |
| − | setTurnRadarRightRadians(Utils.normalRelativeAngle(bearing - getRadarHeadingRadians()) * 1.99);
| |
| − | double v = getVelocity();
| |
| − | if ( v < 0 ) v += 2; else if ( v > 0 ) v -= 2;
| |
| − | double nx = getX() + Math.sin(getHeadingRadians()) * getVelocity() + Math.sin(getHeadingRadians()) * v;
| |
| − | double ny = getY() + Math.cos(getHeadingRadians()) * getVelocity() + Math.cos(getHeadingRadians()) * v;
| |
| − | if ( nh ) {
| |
| − | if ( Math.random() < 0.8 ) setFire(1);
| |
| − | setAhead(0);
| |
| − | } else {
| |
| − | setAhead(100 * direction);
| |
| − | }
| |
| − | nh = false;
| |
| − | if ( t == 5 ) direction = -direction;
| |
| − | if ( --t <= 0 && (nx < 19 || ny < 19 || nx > 781 || ny > 581) ) {
| |
| − | nh = true;
| |
| − | } | |
| − | }
| |
| − | public void onHitWall(HitWallEvent arg0) {
| |
| − | direction = -direction;
| |
| − | t = 20;
| |
| − | }
| |
| − | }
| |
| − | </pre>
| |
| − | Have fun. --[[User:Zyx|zyx]] 07:13, 18 March 2009 (UTC)
| |
| − | | |
| − | Haha, perfectly accurate detection is impossible. It has been discussed [http://robowiki.net/cgi-bin/robowiki?EnergyDrop here] (see some of ABCs notes) why one can at best guess the wall damage with an error between +0.5 and -1.0. The only possible real countermeasures I believe are: 1) Fire low-weight waves whenever the enemy hits the wall or 2) Detect if you got hit by a wallhit-concealed bullet, and if so presume they always make wallhit-concealed hits so long as gunheat indicates that they could have. A truely accurate countermeasure? That's impossible. --[[User:Rednaxela|Rednaxela]] 07:25, 18 March 2009 (UTC)
| |
| − | * Heheh, I assumed someone realized this, that's why I said I didn't search for it (it is 3:30 am here). I thought about you 1st counter option, but I guessed it was not worth the trouble(at least not yet) since I don't see how a bot can use this and actually become strong against a top bot. My current surfing algorithm surfs fake waves when he doesn't have at least 2 real waves, I did that mostly to avoid getting in dangerous spots for a bullet that hasn't been fired yet, but I think it will dodge some of those invisible bullets. And there many more important things that can be improved still. --[[User:Zyx|zyx]] 07:41, 18 March 2009 (UTC)
| |
| − | * There are nearly no surfer detecting it, also many surfer do not even detecting wall hit since the bots that hit wall usually a simple robot that can take out easily, and I think it have only little advantage. Say, if you hit, you will get back 3 LP, meaning no change to your LP (firing and hitting cost 3) but if you miss, you will lost 2 energy without doing anything! At distance 300, you have ~12% chance, at distance 400 only ~9% chance! You may said that you have brilliant gun, but ot hit surfer it need more than that! » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 13:49, 18 March 2009 (UTC)
| |
| − | * Actually, a fair number of surfers will behave VERY simplistically when they don't know of any waves. I know of one that will just sit still maintaining a certain distance. I know of others that will just orbit in one direction. Given how many surfers do that, I bet you could beat a fair number of them with hidden bullets IF you had a strong gun AND were able to make youre movement unpredictable while still only firing when it can be hidden. --[[User:Rednaxela|Rednaxela]] 14:42, 18 March 2009 (UTC)
| |
| − | * Oh! I forgot about that! Anyway, try hitting DrussGT with hidden bullet :) » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 15:16, 18 March 2009 (UTC)
| |
| − | * Yes I'm sure there are bots that can be affected by them, but I don't believe it can be used to make a bot perform better than having a good surfing with nearly zero wall hits. About hitting DrussGT, I don't think top bots can be harmed much by this, so I will not try to hit him :) --[[User:Zyx|zyx]] 15:21, 18 March 2009 (UTC)
| |
| − | * From what I remember, DrussGT doesn't have any wallhit detection. I might have added it in once, but I'm not sure if I kept it or if it was too buggy. Anyways, it just fires a wave if your gunheat is at an allowable level, so would get the bullet power wrong but would still surf a wave. --[[User:Skilgannon|Skilgannon]] 21:48, 12 April 2009 (UTC)
| |
| − | | |
| − | Another way to fire hidden bullet is to move toward walls will slow velocity (say 6), then a tick before hitting, accelerate to 7 and fire(3), enemy ''without'' wall hit detection will see energy drop of 5.5, therefore they don't care since almost every surfer have <code>if (bulletPower > 0.09 && bulletPower < 3.01)</code>. Enemy ''with'' wall hit detection will see energy drop of 3.5, therefore they don't care, too. But this way is easier to detect than one you mentioned. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 03:29, 13 April 2009 (UTC)
| |
| − | * Hehehe, that's a nice one, actually yes I believe is even more effective than the fire(1), I will at some point try a bot with a smaller wall stick, setMaxVelocity(7), and when wall hit is unavoidable accelerate and shoot, not as a main targeting strategy but as a part of a normally behaved good bot. --[[User:Zyx|zyx]] 04:43, 13 April 2009 (UTC)
| |
| − | ** There's no need for setMaxVelocity(7), you can move at velocity 7 and hit wall at 8, too. Or you mean to setMaxVelocity(7) two ticks before hit and setMaxVelocity(8) a tick before hit? That way you need super precise prediction that can handler wall hit. Anyway, this way is easier to detect from enemy than one you mentioned, because accelerate always 1, but decelerate can be 1 or 2. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 05:14, 13 April 2009 (UTC)
| |
| − | *** I mean setting setMaxVelocity(7) for normal behavior and set it to 8 when the wall-hit/hidden bullet is to come. Because that way I can keep a normal movement the rest of battle, using 7 as my max velocity. I think it would be needed a more precise and complex prediction to make the bot go at 7 before the wall-hit and at 8 at the hit time, so I would setMaxVelocity(7) to avoid caring about it myself, and only set it to 8 when I want to hit the wall, if the enemy uses my last acceleration or it keeps track of my max velocity (I don't but maybe some bots do) they will never guess I hit at 8 because they will never see me go at 8 during the battle :p. But I will do this only after I'm bored with trying to make real good bots. --[[User:Zyx|zyx]] 05:55, 13 April 2009 (UTC)
| |
| − | ** Moving with a max speed of 7 will hurt you more due to reduced MaxEscapeAngle, than you will gain with these 'hidden' bullets. Most good bots do take into account wallhits, even when de/accelerating, but it is true, perfect prediction does not exist in this case. --[[User:GrubbmGait|GrubbmGait]] 10:49, 13 April 2009 (UTC)
| |
| − | *** I agree that most good bots do take into account wallhits, but not current DrussGT. And, which bot do take account de/accelerating? » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 11:15, 13 April 2009 (UTC)
| |
| − | **** [[GresSuffurd]] takes into account de/acceleration, but not when in the last tick as mentioned above. GresSuffurd is not a topbot though, because of its limited features and simplicity. (But I like to think that it is bugfree in the things it does do). --[[User:GrubbmGait|GrubbmGait]] 12:56, 13 April 2009 (UTC)
| |
