|
A while back I considered having a cross between partial linear targeting and my bearing offset gun. My partial linear gun defaults to 70% of present velocity, and for some opponents it is my best gun. For some it is the best gun at a different fraction of velocity. It would great if it turned out to be a formidable gun against many folks, if only I could teach it how to calibrate itself. If I can figgure out a practical means of determining after the fact what percentage range would have hit my opponent and track it like bearing offsets, I'll have what I want. I don't know how well it will do, but it's one more option in the battery. -- Martin The actual code wouldn't be much different than your standard GuessFactor gun - you would just make GF1 = linear aim for each wave instead of GF1 = max escape angle. Then GF0.7 would be 70% of linear aim, GF0 would still be head on, and so on. I think the idea of using linear aim as the "reference angle", instead of direct aim, in a GuessFactor gun might have some merit, too. (Like GF0 = linear aim. I think I've seen a mention of that somewhere else on the wiki.) -- Voidious You basically just described the idea behind Stampede's gun, Voidious. --wcsv Oh yeah? Which idea, GF1 = linear aim, or GF0 = linear aim? -- Voidious It uses GF1 = linear aim, GF0.5 = 50% linear aim etc. It uses virtual bullets though, so I could probably improve on it by converting it to use waves. --wcsv 100% linear aim would have to assume the target hits the gas this turn, or you wouldn't be able to hit people who accelerate from 4.0 to 8.0, for example. I could do it with virtual bullets for a discreet set of bins. I was hoping to have a wave-like means of determining what the linear projection percentages were that would have worked after the fact. It's probably a lot simpler than I am making it out to be, but I keep getting too distracted by other things to focus on it. -- Martin Well, if you assume a maximum velocity, you're pretty close to how "traditional" GuessFactorTargeting already defines GF1, which is just the maximum angle they could possibly get to before your bullet intercepts them. (Assuming they accelerate to 8.0 doesn't seem like "LinearTargeting" to me, it seems like "GF1", but it's really just a label anyway.) -- Voidious I don't really use guess factors, so I'm not the expert, but it seemed to me that those represented a fraction of movement tangental to the firing position. I'm looking at the target maintaining heading, going forward or reverse. The problem with not normalizing to the maximum velocity is that your percentages can easily exceed +/- 100. If they are stopped and hit the gas you've got an infinite ratio. It would be nice to scale it off of whatever the present velocity is, perhaps with a cap (like 800%). That might be better handled by segmentation. I dunno. I just want to get a prototype working. I've been sketching it out and I think I can make it work. I just need to check if I remember the Law of Sines correctly. -- Martin You're right that it wouldn't quite be a normal GuessFactor, but it'd be pretty close, especially in duels where perpindicular movement is the norm. Good points about zero velocity, though, and you are probably looking for a gun useful in melee battles, too (throwing perpendicular-ness out the window). In any case, good luck, I look forward to seeing how it turns out (and then hearing the explanation, maybe =)). -- Voidious I've tried several times now to get a profiler working with Eclipse, and evidently I need a lot of hand holding with it because I've tried 4 tools and none of them have worked. They keep throwing errors about missing files or otherwise calling me a schmuck. So.. I've decided to do the 'brute force' method of creating a stop watch mechanism for timing subsections of my tank. I decided to use a JRE 1.5.0 introduced System.nanoTime() to get more accuracy than the millisecond alternative. A cross section of my tank's operation looks like so:
Indicating that my targeting is the main culprit of my speed issues, but movement is not far behind. I'll add similar timer support to the base classes to get a per-implementation profile. -- Martin Once again I've mangled my rating by removing range segmentation on my hit statistics. It's pretty crude but obviously effective. Still, I'm not happy with it, and I am going to try implementing segmentation like I have in my bearing offset gun. -- Martin Well, I've tinkered with quite a few things lately, and done a few overhauls. I'm happy with the new segmentation of hit statistics. It worked out pretty smoothly. -- Martin Ugluk v0.10.5 is purely an opponent tuning change compared to v0.10.4. All existing profiles are on, with many new ram opponents, including all rambots. I compared Ugluk v0.10.4 to Banzai v0.5, but that version of Banzai does not have the new segmented targeting statistics. I do not know how the new statistics will help or hinder Banzai... -- Martin For some reason ramming wasn't as effective for Ugluk as for Banzi, using the same code. But I'll have to track it down later since I've already reworked yet another section, dealing with waves. - Martin It's very early to speculate, but Ugluk v0.10.7 has been climbing steadily and after 40 battles is at 1774 with 108 momentum. In addition to fixing an issue with Ugluk's ram mode, I re-implemented an old feature in a new way, which I suspect is more to blame for the promising rating .. Ugluk v0.10.7 peaked at 1789 before his momentum finally reversed, after 90 battles. I expect it will flatten out somewhere between 1780 and 1800. -- Martin Good to see that you finally entered the top-75. Next is to beat the 1800 (top-50) barrier! -- GrubbmGait Ugluk was really struggling to make any progress. Part of it was that I'd remove stuff that didn't work well but I wouldn't replace it. I'm still missing some 'features' that were slow, but the reduced functionality allowed me to focus on better performance of the systems that mattered. Right now I'm trying to squeese the rest of the rating points (to 1800) out of performance tuning. My attempt to ram rammers to minimize my losses didn't work out well enough, so I'll be fiddling with anti-rammer stuff as well. -- Martin I'm working on the new gun and I've hit a slight snag, though I think I know a way around it. Here are some diagrams I threw together: http://home.comcast.net/~kokyunage/robocode/diagram1.jpg The target begins at known position [1] and has a known direction of travel (factoring in negative velocity). Ugluk has a bead on it (bearing offset 0). It travels to position [2], and the hit arc is projected through the original direction of travel line. Points A and B are scaled to the percentage of maximum velocity that would have taken the vehicle to those points, giving you your range, and you can drop the interval into bins. As you collect more data you get a smoother picture of where the target tends to be on that scale. Walls would tend to be at 100%, but also has some lower range values due to stopping at corners. http://home.comcast.net/~kokyunage/robocode/diagram2.jpg Above is one of the problems with this technique. The points of intersection are behind the firing position because the direction of travel has changed drastically. You may have noticed that point [A] is further from position [1] than point [B], so we can detect this situation and may be able to accomodate and even use the data for future firing solutions. -- Martin Man, it's scary to think how that gun would react to Tron's wiggling... -- Voidious It's gone through a few revamps already and still isn't working as well as my Linear and Partial Linear (fixed percent) guns. I think I'll have to add some graphics to debug it. It looks like I'm storing and returning legitimate percentages (of straight linear), so I'm either not projecting correctly or my partial linear gun is using max velocity. I forgot to bring in the code to work today so it will have to wait. -- Martin I've backed out some code changes, including the gun I was working on (which was ineffective). I am also working on using virtual waves again, but only when they prove more effective (such as against opponents that don't take their enemy's firing into account). -- Martin Ugluk finally penetrates the 1800 barrier. -- Martin Congratulations, you're getting closer and closer to v1.0, only three bots left to beat. As for melee, your current version has a better 'domination' than your best sofar. Due to the late flood of (sub)topmeleebots, the ratings are dropping and the former top-20 bots (like PulsarMax, Troodon, Ares) have a hard time to stay in the top-30. I'll try to put some more effort in my WaveSurfing, just to stay ahead of you in OneOnOne. -- GrubbmGait My client can't download the newest version of your robot. -- Kinsen Yeah, sorry Kinsen. I am 'teaching' Ugluk what movement and targeting sytems don't work against rumble opponents. It's best if I only allow one machine to process the battles, otherwise I just have to keep making new bots because of the 1200 battle limit. If many people are processing battles I'm still only learning on one machine, where I'll grab the results. I'd do this with RoboLeague but I've never figgured out how to get the cannon caches thing disabled with it. So for now 0.13.1 and one or two more versions will just be available to my machine. Then he'll be public again. One thing I've observed this morning is Ugluk has challenged bayen.Squirrel and stelo.WangRobot about 30 times each but keeps scoring 100%, so the score is invalid. I wish they'd him me just once. -- Martin edit: and Grubbm, your wave surfing intimidates me. I will have to achieve my stated goals for v1.0 before you have time to polish it. * I know my surfing is quite impressive, that is the result when the best parts of BasicSurfer and my own bots are put together ;-) -- GrubbmGait ** I haven't actually seen your surfing in action yet. I just know you have a highly competitive bot without it. I expect when you add in some guess-factor style targeting you are going to make me cry. -- Martin By the way, I have a line in my roboleague/launcher.properties file that says: user.cmdline=-Dsun.io.useCanonCaches\=false -Xmx512M ... Florent tipped me off to it, and I have used RoboLeague to collect data like that (for that Dookious version testing pre-loaded data). -- Voidious I have spent quite a bit of time developing a object-based bearing offset gun with dynamic resegmentation. As more data became available, the segments would determine if it was time to increase the 'buckets' by 1, and reprocess all previous scenarios and resulting enemy positions. At first there are maybe 9 total buckets, accounting for cominations of positive-only and positive and negative segments. After growing sufficiently, there may be hundreds of buckets. The premise was that initially you have very little data and you want to be able to take an educated guess as soon as possible. What I'm finding out though is that slicing your data finely isn't really making your guesses more educated. At least not in a 35 round battle. I also moved my virtual gun statistics to use the same dynamic segmentation. I think I'm going to make the gun a lot simpler, cut way down on the segments, and add in some randomness in situations where the odds of picking the right angle are slim to begin with. -- Martin Definitely agreed that more segments is not always good, and finding the sweet spot can be tough. I've been wondering for a while - why would you use bearings instead of GuessFactors in your statistical guns? To me, GuessFactors seem like an evolution of bearing offsets, and I see no advantage in using the latter. (GF1 at bullet power = 3 is a much different angle than at bullet power = .1, but they will both hit the same type of movement, generally.) -- Voidious Gut feeling. And it's easier. And I don't have a good mechanism for wall smoothing, so I cannot predict how an opponent will behave in that situation. And I'm presently not using rolling averages. For post 0.13 I've gutted a good chuck of the code, including inferior guns, segmentation, and my dynamicaly recalibrating bearing offset gun. I've a fresh simpler gun with fixed segments, and only 4 of them so far, with 625 elements, each holding a bearing offset bin array. I'm going to toy around with implementing (and debugging) various segments and try them out. To support this effort I'll also need a means for collecting bin hits across hundreds of battles to see if there are any consistent patterns for each segment. That should give a relative worth of considering that aspect of an opponent's situation in the gun. I think I'll revisit the Entropy discussion next.. -- Martin I didn't intend to hide my posting of 3 bots at once, but after 4 failed attempts to save the participants page, I started fiddling and it worked as a minor edit. /shrug This selection of Ugluk bots all have preloaded profiles disabled, 5 movement options, and one gun, with the same segmentations. The way the bearing offset is determined is the only difference.
-- Martin I'm not sure where the "rule" might be written, but RoboRumble/ParticipantsChat has a bit of talk of only having one version of a tank in the rumble at a time. Not that I'm one to talk, with my daily Komarious releases, but it was kinda uncool to see "Ugluk...a vs Ugluk...c" come up as the first match in my RR@H client. -- Voidious You are right that you are not one to talk. It isn't very cool, but since I entered them at 10:30 at night and had 3 cpu's cranking the rumble throughout the night, it didn't impact much. And now there are three cpu's cranking through the daily Voidious release... -- Martin Indeed, it didn't cause much of a clog, so no harm no foul... but if there is a "rule" about not having multiple versions in at once, I think it should be followed. I do post releases often, but between them I also run lots and lots of tests, instead of letting the RR be my testing grounds. In other news, with my three clients as well as yours, this version of Komarious might stabilize faster than any bot I've ever seen in the rumble. -- Voidious Komarious is a pretty fast bot. I give it two hours. -- Martin I just noticed that my MC2K6 rating againt the Circular Targeting bot (C) is second only to Engineer. Linear Targeting (B) is still very high. I dunno why I am getting nailed by the head-on bot so much. Ah well. -- Martin Indeed an impressive score against botC, but I still stay the best non-surfer in the MC2K6. Btw, I released my first WaveSurfer with GF-gun, I propose that it does not count for v1.0 of Ugluk. -- GrubbmGait The very first undertaking with Ugluk (v0.0.1) was a wall collision avoidance algorithm. His movement was fairly simple (mostly straight with a little sine wave added to throw off targeting) but he stopped short of running into walls. Sometime later I revamped the movement engine to use vectors, and I have used wall repellant vectors ever since. I also added robot repellant fields and some others I toyed with. Subsequent movement methods have all boiled down to a suggested movement vector, and the sum of all vectors was where Ugluk wanted to go. With the wall repellant fields in place, I ditched the costly early wall collision avoidance algorithm. It has worked fairly well for a long time. One thing I didn't have though, which became very apparent when I introduced a grid go-to system, was that I didn't have a way to determine the fastest way to get from point A to B for any initial heading. For example, if Ugluk was heading north at a velocity of 8.0 and wanted to arrive 40.0 units to the east, Ugluk would bank right and go in a circle until the point ended up behind him, at which time he'd hit reverse and try backing into the position. He's rock his way to the destination as long as it took. Well, no more. I finally figgured out how to find the shortest path to my destination, and I'm pretty proud of it. I also take into account the location of walls that I may run into along the way, and avoid them fairly well - but not well enough yet. I still need to work out some kinks in that department. My most recent test had about 1.5 wall hits per round. I need to check the speed of those hits to see if they are really relevant. If I am hitting at less than 2.0 velocity then it doesn't really matter. Edit: about 80% of the hits are at 1.0 velocity. Must be a simple algorithm issue. -- Martin I've worked out the kinks in the 'least time from point a to b' movement, complete with wall avoidance and my own version of smoothing. My score isn't stellar, and not my highest, but Ugluk is damned fast and getting it done with very few tools. I'll be reviewing the poorly performing movement styles of the past (i.e every one I've made) and trying to make them work as I envisioned. -- Martin Got some decent wave surfing results finally. Hopefully this transfers to the Roborumble... -- Martin *While the wave surfing challenge scores were much improved, the other challenges saw sharp declines. Consequently, the rating didn't climb much overall. -- Martin I figgured I'd add some eye candy related to my movement engine overhaul. The first two screens are related, the third is from a different round. After the first wave options get more limited. I haven't begun to tackle multiple wave surfing yet. Yet.. http://home.comcast.net/~kokyunage/robocode/ugluksg001.jpg http://home.comcast.net/~kokyunage/robocode/ugluksg002.jpg http://home.comcast.net/~kokyunage/robocode/ugluksg003.jpg The green box is the destination I am trying to reach. The orange box is my present direction of travel's intercept with the wall. The green wavy lines are my 'optimal' tangental paths of travel. Given my wall avoidance I probably need to make more than one pass after determining that my ending direction of travel is rather different than the tangent. The grey lines denote the original dead center bearing as well as the present maximum clockwise and counterclockwise rotations (as calculated by the tangental path prediction). The rings are my wave representation (as previously described on the RobocodeSG page). -- Martin Nice eye candy. Debugging graphics are enabled in Phoenix too, you can turn them to draw projected clockwise / ccw motion, enemy waves, values of various surfing components, and other goodies. =) --David Alves With regards to the WSC scores / RoboRumble correlation, I would add that I think the score vs BotA? (HeadOnTargeting) is by far the most important one. (Komarious gets relatively bad scores against BotB? and BotC?, but still gets a lot of rating points out of her WaveSurfing.) Nice graphics, too, they really do help a lot in the WaveSuffering process. -- Voidious Ugluk v0.14.6 kicked Grishnak's ass 2:1 in my first (and so far only) test of 35 rounds. It lost to GrubbmGrb and GrypRepetyf but not nearly as badly as it has been. I expect some decent results (as always). -- Martin Nice graphics, I should try to visualize some more than just the wave. It seems that 0.14.6 is your strongest Ugluk sofar, being relatively better against the high-end and midrange bots, well at least better than GrubbmGrb does. That bot is not exceptionally strong with about 100 losses, but will ruthlessly exploit any weak spot in movement and/or targeting. Examining the details, it almost looks like a combination of Grishnakh and Ugluk is able to get into the top-50. -- GrubbmGait At present Ugluk only has one gun, which was a few hours of re-writing my bearing offset gun nearly from scratch to be far simpler. It is still my most effective gun in terms of the targeting challenges (which is odd since I haven't even begun to toy with the segmentation) but I don't have any simpler targeters backing it up. The simple targeters tend to kill the simple bots far more quickly. It is possible that re-introducing some simple targeting methods will nudge me into the top 50, but right now there's still some nagging movement behavior that I'd like to iron out. For example, my Grid movement should never get hit by head on targeting, especially against a stationary bot. Yet sometimes it just crashes right through the middle of one. I need to figgure out just what is happening. Once I get that nailed down, I'll add some guns that reflect the LT and CT wave surfing challenge bot targeting algorithms, and I will produce a bot that gets 100% score in the wave surfing challenge (even if it is just a novelty bot). While coding to distract me from staring at the Roborumble client churning my results, I added a pre-turn-30 movement style that gets me out of pinned positions, and that should help my wave surfing challenge scores across the board. -- Martin Edit: And yes, Ugluk v0.14.6 is my best bot to date. Somehow I keep treading water in terms of "domination", though my rating is increasing. People are turning out strong bots lately. -- Martin Recently all of my bot design has been focused on movement. Some of the design is similar, but there has been a lot of overhaul and rewriting of the core system. A while back I made a grid walking movement that had some flaws and was terribly slow, so I shelved it. I recently got it working fairly well and then got it working really fast. And through it I've managed to track down some annoying issues. There are still some more to go though. Ultimately I expect the Grid movement style to get 100% across the board in the wave surf challenge, even though it isn't doing any learning like other wave surfers do. -- Martin Well, in playing with the collision detection I have managed to disable the registration of hits against my opponents, causing my gun to act as a head-on targeting gun, hence the dismal scores of 0.14.7's brief stint. I'll fix it tonight... -- Martin I got the gun somewhat functional, but there's some strange behavior going on. For example, I'm determining all the points at which the wave (circle) intersects the target hit box (square) which should be 0 or 2-4 times. (A wave could intersect the firing tank's hit box at as many as 8 points.) I am getting some results of 1 intersect point, which should be extremely rare. Anyway .. more work to be done. I was making general changes to the bullet / wave collision detection system and focused on testing movement so I didn't notice the gun failure. -- Martin I was getting some nice test results with my gun modification and the work day was nearly done so I packaged it. A nice 10 point boost. I have some more gun tricks to refine that should push Ugluk even further along the path to glory. I'll run some targeting challenge tests tomorrow. -- Martin Ugluk took a performance hit with 0.15.2, but his targeting challenge scores are getting a nice boost. As I get higher on the targeting challenge list it is more and more evident that my movement really needs improvement. My initial attempt at learning wave surfing was less than satisfactory and has been disabled. I need to tune it some more so that it looks like it is really surfing. As always, there is more work to be done... -- Martin It seems that 0.15.7 is the 'Release-Candidate' for v1.0, if you can improve that 49.9% score against Mjolnir! And you are threatening my position }:-\ -- GrubbmGait * I was expecting some goodness, but I expect that every release =/ I ended up defeating Mjolnir enough in the secong battle to bring the average to 52.2%. I ran Ugluk overnight and didn't see any battles until this morning. He's in 57th place, right behind GrubbmGrb at 56th. No PL ranking yet. It's going to be a good morning. And yes, I think I shall release this bot as Ugluk v1.0, over a year in the making. * Congrats! =) -- Voidious *Thanks. Upon reflection while driving into work, there is wave surfing movement style that I've been developing but just haven't gotten to work right yet. If I switch to melee now (per my stated goals of about 8 months ago) it will collect dust, since wave surfing has little business in melee (until it comes down to 1v1). That and how could I accept being right behind GrubbmGrb? Freya maybe my melee white whale, but GrubbmGrb is surely my standard for duelling excellence. Ugluk v1.0 should be a reality within a week or two though... I have been having a problem with graphical debugging. I was building lists of line segments to draw, but by the time they are drawn they are one turn late. So with a few tweaks this morning I made the onPaint method process my robot's turn (and if it wasn't called for that turn the normal run() cycle will process it, and execute the instructions). Snag #2 is that onPaint is called before any events are processed. So now I am remodelling the event handlers so that I grab them off the queue manually at the beginning of the round and process them all before making any decisions. This will have the side effect of improving the handling of onDeath and onWin events. With my new movement I have nearly nailed my goal in the wave surfing challenge. But .. about 4 rounds in 500 I get killed. I dunno what the situation is that causes it, and watching for something that occurs once every 125 rounds on average is not really practical. I guess I'll just have to store some notes about my starting position, the opponent's first scan position, and what my energy was at the end of the round. On the whole though I've really made some progress in getting out of tight situations at the beginning of matches, allowing for more flexibility as the round progresses. Still some work to be done though, it seems. -- Martin Ugluk v0.15.8 does not contain the wave surfing movement that I have been developing. I am trying to get the grid walking nearer to perfect. I should probably add segmentation to it, which will be a single line change. -- Martin *The RoboRumble sure is a frustrating proving ground. Down 18 points. I think I may know some of the issue though. 0.15.9 will be along shortly... Ugluk v1.0 released. Already I've found an error with the 2K6 challenge mode .. I misspelled the (rather large) Cassius Clay version numbers. I don't think anyone will be doing that testing for me so it's fairly moot. -- Martin I'm getting serious about tuning my gun now. The trouble is I have 4 styles of gun and 3 segmentations. (Really there are 4, but two are the same type of measurement). So in order to get a baseline for tuning I need to test all guns with no segmentations and each segmentation individually, for 16 total runs. I am using the Fast Learning style test, so 5250 rounds per test, ~2.7 hours. It's gonna take a few days. It is really long overdue though. I rewrote the base gun to be very simple a while ago (compared to my dynamically re-segmenting one) and took an educated guess at some practical segmentations and number of them, with no attempt to verify that they made sense. The gun has performed pretty well, but it is unlikely that it won't benefit from some tuning. -- Martin |
|
|
![[Home]](/images/RoboWiki.png)
