[Home]Rednaxela

Robo Home | Changes | Preferences | AllPages

Difference (from prior major revision) (no other diffs)

Added: 0a1,2
NOTE: This page is now replaced by [User:Rednaxela] on the new wiki. Note that bot pages have yet to be migrated, but the user page on the new wiki is more up to date.


NOTE: This page is now replaced by [User:Rednaxela] on the new wiki. Note that bot pages have yet to be migrated, but the user page on the new wiki is more up to date.

A first year engineering student and relative newbie Robocode. I discovered Robocode in late 2007, and have spent some late nights trying my luck.

My released robots

My unreleased bots

My planned bots

Utilities and Code

Various brainstorms

Current Status

Working on my upcoming bot 1v1 bot.

Goals


Welcome. Among the good reasons for releasing your bot periodically to the Rumble is that it's a convenient time to back up your source code. Sometimes I'll go on a major refactoring campaign or start hacking out pieces that I am frustrated with, only to find out that I was making a big mistake. It's good to be able to go back and take parts (or start over) from an old bot. My latest work (which I haven't been releasing but still make periodic backups) has had three prior versions of my bot to use as a reference for how I was doing things, and I've copied code back in from them. -- Martin

Hi. Yeah, periodic backups are good things and I'll probably start using a local SVN server to store revisions at some point, but I haven't gotten to that yet and just want to get Gwynfor to a non-embarrassing state (i.e. doesn't blindly get stuck on walls) before releasing it. Also, I've been avoiding deleting code in favour of keeping old classes for movement patterns and such things around but unused. But anyways, it shouldn't be long before I release Gwynfor into the rumble, as my todo list before that just consists of first some refactoring/cleanup, and then finishing my new 'secret sauce' of movement. Thanks. --Rednaxela

Welcome! Glad to see you went ahead and made yourself a page. I know I already said it, but don't worry about the RoboRumble uploads - we've all run into such issues and it's not a big deal. We've had bad clients, bad bots, bad server (running out of disk space), and bad versions of Robocode. =) Feel free to post questions, I think this community is a pretty helpful bunch. If you're interested, there are a lot of OpenSource bots on the site, and if you're not, there's plenty of good (codeless) information / discussion. Best of luck with your bots. -- Voidious

Hey Voidious. Thanks. Yeah, I know about the multitude of OpenSource bots out there, but I've been thus far preferring to make my own code (what better way to understand the algorithms, than coding it yourself? :)) but I have indeed been inspired by many discussions/ideas I've seen on the wiki here. I'll probably add some comments to the relevant topics I've been inspired by once Gwynfor is out on the battlefield, once I have a better idea of how my variations/implementations are working. Thanks alot. --Rednaxela


Well, lately I seem to have taken a liking for the battlefield of teams. It's relatively fresh, and as shown by LunarTwins you don't even need learning to compete yet. Lots to be explored really. I may come back to 1v1 eventually, but I refuse to do it without SOME level of originality in either my targeting or movement, and I don't expect that to happen any time soon. -- Rednaxela

How about figuring out a new algorithm for WaveSurfing? We already have WaveSurfing/TrueSurf and WaveSurfing/GoToStyle. I'm sure there are other ways of doing it. -- Skilgannon

Well perhaps, but one thing I've found for sure, is that ideas can't really be forced and sometimes good ones are just stumbled upon. After all, LunarTwins' movement was actually an accident at first, a side effect of an experiment of how to get into position for close-range synchronized orbiting, however it ended up having good results so I sort of "purified" the essence of why it appeared to be working. In terms of ways to do WaveSurfing, I would say the broad definition of WaveSurfing could be simplified as "Movement that attempts in some manner to move to GuessFactors statistically less likely to be fired at" (essentially the reverse of GuessFactorTargeting). While most WaveSurfing seems to be focused around perpendicular movement, as that maintains a stable distance, I would say that that it could be applied to all sorts of concepts, such as TrackMovement for instance. Actually many implementations of WaveSurfing I would also call MinimumRiskMovement at the same time, as they certainly fit the line "The idea is to pick a series of points that you could go to next, and rate each one with a 'risk factor', then move to the lowest-risk location." and it's just that the risk factor is primarily based upon how likely it is for the enemy to fire in certain directions. WaveSurfing/TrueSurf in particular I would call a form of MinimumRiskMovement. Often the only thing about many WaveSurfing implementations that differs significantly from "classic" MinimumRiskMovement besides the source of the risk factor, is that the points at which the risk is evaluated are focused around perpendicular movement. The way that WaveSurfing implementations often like to keep constant distance, and that GuessFactorTargeting works best at constant distance, in my opinion is a weakness of a number of WaveSurfing implementations as it gives GuessFactorTargeting that doesn't segment distance at easy day, and GuessFactorTargeting that does segment distance a quicker time learning. Of course, there's the issue of how to move over a wide enough range of GuessFactors. One interesting note, is that to move over the very widest range of GuessFactors you shouldn't move perpendicular, instead you should be perpendicular when the wave is fired at you, but don't turn after that, as that will move away slightly increase the time till you are hit and thus increase your escape angle. That's basically how you get the extreme +1 -1 GF movements. Of course, the drawback to this, is this movement causes your distance from the enemy to increase every time you dodge a wave. Now this may be a good tactic if your bot is deciding to adjust it's distance further away, however as the battlefield is not limitless you must keep your distance close enough that you're not constantly having to mess with wallsmoothing. Now, if you don't need those extreme guessfactors, how much you turn away/toward the firing point can result in a decrease to the escape angle. Using this mechanism, instead of accelerating/decelerating to get to different GuessFactors, one could keep a constant velocity and just turn towards or away from the enemy to control their GuessFactor. Also, I believe that it may be possible to tune the timing of when the bot using this movement fires, to fire when it "swoops" in closer and thus has a better hit rate and potential for triggering anti-dive mechanisms. Also, this movement could be extended to in some cases "swoop" in even closer to the enemy when they're GunHeat is still high, in hopes of getting a good shot while the risk is low, as well as again possibly triggering anti-dive mechanisms. In some ways this is kind of similar to that "Dive Surfing" idea I was thinking about except it's more defensive. I suppose I'll call this idea "SwoopStyle WaveSurfing" due to how it would have a tendency to "swoop" inwards frequently. Who knows if I'll be able to implement this successfully, but heck it's an idea. Well that was an interesting brainstorm-rant, I started talking about how ideas can't be forced, then in my rambling I came up with a bit of an idea. Wow what a long rant/blob of test, I feel sorry for anyone who goes and reads the whole thing. Well this was amusing :) -- Rednaxela

It's funny that you should classify WaveSurfing/TrueSurf as a minimum-risk movement, and WaveSurfing/GoToStyle as not as much. I would classify the other way around: In True Surfing you only evaluate points once you have eliminated the majority of them from your evaluation, ie. only the points you would arrive at when going maximum forward, maximum reverse, and (possibly) stop. In Goto Surfing you take a whole bunch of points(it doesn't matter where you get these points from), and feed them through your evaluation method. This evaluation method may involve precise prediction, but the essense is that you don't only evaluate a limited number of points, you evaluate all points, and it doesn't matter where these points come from. I could change the predictPoints() method in DrussGT to return every single point on the battlefield, and it would still work fine, albeit slowly. It would still find the point with the minimum risk according to evaluation method, and would still go there. A True Surfer would have a tough time knowing where to go if you asked it about a point. A True Surfer evaluates a direction of movement for danger, not a point. Thus I would classify True Surfing not as MinimumRiskMovement, but MinimumRiskOrbit?. Movement implies a destination, but with True Surfing it is not about the destination, but about the direction you are moving in.

About your concept of moving closer or further away to confuse guns, I think this would be very susceptible to segmentation on AdvancingVelocity, or even LateralVelocity. It might be very effective against guns without this segmentation, but so is regular surfing =). Currently, I think choosing a 'best distance' is a balance between staying far enough away that you are a small target, and not being limited by the walls. Predicting your movement forward for several waves with different 'best distances' and finding which distance would give you the safest bins would be the best option, but limits on CPU prevent that. Of course if Fnl ever does this whole 'average CPU' thing... DrussGT wouldn't skip turns when I quadruple the number of points ;-) -- Skilgannon

Well, I don't think it would be too vulnrable to AdvancingVelocity and LateralVelocity segments, because 1) I thinking it could be implemented as to try to be return to perpendicular at the point in time the enemy fires making it's options wide open (similar to how a squash player returns to the T of the court after hitting), and 2) even if at a given advancing velocity at the time the enemy fires, it should still have quite a wide range of potential GuessFactors particularly considering direction reversals. I think point #1 there does reduce how dramatic the "swooping" motion can be, however I still think could have some merit, particularly in terms of being a little closer when shooting and a little further when being shot at. -- Rednaxela

Just a couple thoughts from me here. I like the idea of imagining distance as a fluctuating value (like a sine wave) and timing your shots so you're always closer when firing than the enemy is when firing. It seems really hard to implement, but it's a great idea on principle, and even a little difference would help I think. As for actually moving towards / away the enemy frequently in the Swoop idea, I am really skeptical of the value there. You're cutting down on your max escape angle a lot when you do anything too far from perpendicular. You mentioned "going back to perpendicular when they fire", but it seems you're imagining a battle where there's only 1 enemy bullet in the air at a time, when there are usually 2 or 3. You can't really swoop in without affecting the max escape angle of all those other bullets in the air. That's also why moving perpendicular to the abs bearing at fire time isn't practical, despite the fact that it gives the max theoretical escape angles - by the time you're dodging a given bullet, you've already moved quite a bit to dodge the previous ones that were still in the air at fire time. Moving orbitally is a good middle ground that doesn't require many sharp turns.

Always good to see some fresh and interesting thoughts on WaveSurfing. =) I too have long thought of it as a form of MinimumRiskMovement. I think there's more room for innovation than there might seem at first, even within algorithms that could be classified as TrueSurfing or GoToSurfing?. They are actually really broad definitions, IMO. I think what happens a lot of times is that the wiki doesn't truly reflect how much innovation and variation there are among bots (like TrueSurfing or GuessFactorTargeting bots), because the authors get more obsessed with working on their bots than documenting their ideas and brainstorming on the wiki. =)

-- Voidious

Well, "going back to perpendicular when they fire" does fix the issue of being limited by the number of possible escape angles at least as far as one-bullet-at-a-time goes, but yes, it's true that I was primarily just considering when there's one bullet in the air. Of course, to deal with multiple bullets in the air, it could make sense to plot a curving path wich results in a desirable GuessFactor, and is perpendicular again at all intervals of time at which their GunHeat is expected to be 0. This would be in some ways, a complex variety of "Goto Style" movement, and would only need to be re-evaluated when another bullet is fired. In some ways, when choosing a desirable path of movement, I think the following (ordered) priorities are what should be considered: 1) Getting to a desirable GuessFactor, 2) Being perpendicular or close to it with enemy GunHeat is zero, 3) Being closer to the enemy when our GunHeat is zero, and 4) Varying various segments about us as to slow enemy learning (i.e. vary distance). Traditional WaveSurfing does very very well at #1 and #2 and it achieves #2 with extreme simplicity, however the constant-distance virtually-always-perpendicular thinking doesn't deal with #3 and #4 ideally in my opinion. I think it would be a superiour movement if you can achive qualities #3 and #4 provided you don't sacrifice at all in terms of #1 and #2. It's true that qualities #3 and #4 can be harder to achieve in significant quantity without sacrificing ability at the more important #1 or #2, when multiple bullets in the air are involved, however, this makes me wonder if it may be interesting to experiment with a closer range surfer of the style I propse, which tries to keep a range where there's only one or occasionaly 2 bullets in the air at a time. I think such a bot wouldn't dominate by as big a margin against weaker bots in the rumble due to the closer range giving simpler targeting an easier time, however I suspect that this tactic might not work bad for a PremierLeague score. Another thought, is that at sufficently close range, quality #3 outweighs #2 probably. If you're in close range, and time your firing so when they have medium gunheat when you have zero gunheat, you could get to nearly point-blank range when firing and be further away by a significant amount (albit still very very close compared to Traditional WaveSurfing's prefered ranges) when they fire. I think that if you can successfully achieve such tricky distancing, even if you won't dominate weak bots by as big margins, you'll have a notable hit rate advantage aginst strong bots which are unable to counter the distancing techniques. This method could also be potentially be countered by opponants with a less predicable firing rhythm, or by movement that can evade this distancing, however I think that close-range wavesurfing using these distancing methods, could just maybe come out on top of some strong traditional surfers. I suppose you might even be able to abandon the WaveSurfing part and make a movement purely themed on matching a distancing rhythm to the firing rhythm, however I think it could certainly be combined with WaveSurfing too and used as a way to vary one's distance segment to slow learning too. -- Rednaxela

One thought I just had, about how to really nicely make a version of WaveSurfing/MinimumRiskMovement? that accounts for firing rhythm, would be by:

Have a WaveSurfing style system that evaluates the danger of different locations, importantly including accounting for botwidth (importantly, using botwidth for the expected distance from the firing point WHEN the wave will pass through you)
Interact with a GuessFactor gun's targeting code to estimate the probability of hitting the opponent, accounting for botwidth (importantly, using bodwidth for the expected distance of the enemy from your firing point WHEN the wave will pass through them)
Instead of purely avoiding danger like normal WaveSurfing, calculate a risk-benefit ratio
Instead of calculating for orbital points only, calculate for points moving in close to the enemy, or far from the enemy, too.
I think a variation on WaveSurfing using this method, of maximizing a risk-benefit ratio, would produce a strong movement that would dodge effectively, move closer when firing and further when being aimed at, and automatically decide a smart distance (Which I suspect would be very very close distance against stronger targeting bots). I think the tricky part, would be predicting the opponent's botwidth in the future, which would probably require future path projecting to do, and thus to do with quality would require either a PatternMatcher type method, or keeping statistics on their distancing too alongside their GuessFactors.

And the more I think about this idea. the more I feel confident that it would both achieve that movement matched with firing rhythm as well as smart DynamicDistancing and BulletDodging? all in a statistically sound way. Not only would it be controlling it's GuessFactors, it will be controlling it's botwidth and it's opponent's botwidth. I think this is definitely the way I'll go if I move back to the 1v1 arena. -- Rednaxela

I'm curious, in the DynamicDistancing page, I see talk about bots learning good distance experimentally over battles, however I wonder, has anyone tried to implement DynamicDistancing before by estimating hit rates from GuessFactor/WaveSurfing? stats, accounting for the effect of distance on the angular bot width? -- Rednaxela

I'm pretty sure Phoenix does some sort of dynamic distance, but I couldn't say what. But doesn't this really just equate to getting as far away as possible? -- Skilgannon

Getting as far away as possible is good for your movement, but getting closer is good for your gun (hitrate). The point however is, that movement is much more important for your score than your gun is, so mostly getting far away is better for your score. -- GrubbmGait

@Skilgannon: If you only take the enemy's predicted hitrate on yourself into account it equates to getting as far away as possible, however, if you also take into account your predicted hitrate against the enemy (data obtained from a GuessFactor gun's stats) while using accurate angular botwidth for both, then I think it would provide distancing which would often not be as-far-as-possible. For example, if you used this with a gun configured to always fire with LinearTargeting (but still kept track of GuessFactor gun stats, to predict how likely the LinearTargeting is to hit), then this method of DynamicDistancing would be likely to very quickly learn to move into close range combat in order to narrow the gap between the gun hitrates of each bot.
@GrubbmGait: I suppose, though currently I'm thinking more of from a survivalist perspective, in which the ideal distance is most certainly the distancing which optimizes the ratio of our hitrate to their hitrate. Of course, when your gun is stronger than the enemy gun, the method I propose would choose such very far away distances away naturally, as that would hurt their hitrate more than our hitrate.
-- Rednaxela

The trouble I see with this is that it could work the wrong way. Let's take an example of a bot with strong movement, but weak targeting (eg. linear). It will tell you that there are a lot of very low risk areas to move to, especially in the negative GF range, so increasing your botwidth wouldn't matter much. Your targeting will tell you that if you get closer you will have a much better chance of hitting them. So you move closer, and suddenly they *are* able to hit you with their simple targeting, because you haven't yet learned how their targeting reacts at that distance. It only takes a couple hits for it to be nearly impossible to get that 95% score against linear bots. Staying at a single distance can drastically decrease the learning time of your movement. Rather than finding a 'best distance' from your targeting and movement stats, I think the time would be better invested improving the gun and movement accuracy =). Who knows, perhaps it would be possible, even effective, but the warning bells for a dead-end idea are going off in my head =). For 500 round battles I would definitely consider this, but 35 rounds doesn't give enough time IMO. -- Skilgannon

Well, I don't think that's too large a worry, because, even if it gets hit just once ever by a very weak targeting such as linear targeting, which tends to aim at about the same GuessFactors a lot of the time, it's movement would from that point on would strongly avoid getting close enough to get hit again due to a large angular botwidth. LinearTargeting shouldn't really be affected by distance anyways, as I'm pretty sure the GuessFactors it would aim at, are just determined by lateral velocity and not distance. If it is a problem though, I could do a variation on the MusashiTrick (in spirit anyways), where until it gets hit, it would pretend it's gotten hit by linear, circular, and head on targeting, and dodge any GuessFactors those three would aim at. This would also motivate it to keep a distance just far enough away that it could avoid those three targeting methods. But really, even if it still has troubles getting those 95+ scores against weak bots, I more have my eye on a Survivalist approach and the PremierLeague than plain score ranking. -- Rednaxela


Well, before starting on a more serious 1v1 bot (possibly using some tactics I was thinking of above), I decided to give some thought to DynamicClustering, one of the more successful statistical techniques I've seen used. Firstly, from what I've read on the technique, the predominant form of it is as "K nearest neighbors" that evaluates the kernel density of the nearest neighbors. What I'm thinking now though, is what might be able to produce more precise results than merely nearest neighbors, would be adding a variety of "function detector", that would look at those nearest neighbors and attempt to detect consistent correlations between any segmentations and the GuessFactors of those neighbors. If such a correlation is detected strongly enough in any segment, then the detected "function/correlation" would deal with that segment, and the other segments where a strong correlation is not detected, would be left to kernel density methods. I'm still mulling over exactly how to combine detected "functions" in some segments with with kernel density in other segments, but I think I have a bit of an idea of how to do it.

What could be used as a "function detector" could vary and I'm not sure what would be best yet. One possibility is just doing a few types of function regression (linear, exponential, etc.) and evaluating if any produce good enough correlations. Another option would be using a neural network, which may work well for taking in the multiple segments, and are often characterized as a type of "non-linear function approximation generator" and that could simply be evaluated after training on the neighbors to see how strong correlations it found in each segment.

The reasoning behind this, is that I think this could produce more accurate results when there are fewer really close neighbors to go by. For instance, if this is used in a WaveSurfing bot, and the enemy is a LinearTargeting enemy, this method very quickly detect, after getting hit fewer times,that the GuessFactors the enemy is firing at are purely a linear function of absolute value of LateralVelocity and extrapolate that function. Common variations of DynamicClustering would indeed over time learn how where the enemy tends to aim depends on LateralVelocity, however, if the bot has been hit by LinearTargeting when it's initial LateralVelocity was, for example 8, 6.6, 2 and 7.2, and only has those 4 data points to go on, normal DynamicClustering may not predict exactly where the opponent will aim if your LateralVelocity becomes 0. This "function detection" extension to the idea however, would very very quickly be able to guess the exact relationship between the GuessFactor and the LateralVelocity and be able to make accurate predictions that would hold true even at LateralVelocity values it has not seen before. Any thoughts on this idea of extending DynamicClustering with "function detection" techniques?

-- Rednaxela

Well, after mulling over it a little, I think I've revised/clarified how to accomplish my idea. It would work as follows:

I'm pretty sure, that whenever the neural network finds no significant correlations (in which case the neural network would tend to output the average) this should essentially behave like a normal DynamicClustering method, however, when the neural network does find significant correlations (as it would tend to when doing things like predicting the firing of a linear targeting bot) it should give better data I think.

-- Rednaxela

Well, for simplicity and speed, I might instead try "Multivariate Linear Regression" which while only capable of mapping linear correlations, I think should provide some useful results. At least as far as learning LinearTargeting goes, adding "Multivariate Linear Regression" would enhance DynamicClustering just as much as the more complicated neural network. -- Rednaxela

An added side effect would be that it automatically adds a sort of dimension weighting...maybe you could use the results of the outputted values of the neural network to adjust the dimension weights on the DC gun? -- Skilgannon

Well, the "function approximation algorithm" (whether it be the neural network, multiple linear regression, or something else) would indeed decide it's own weightings for itself, however while getting some DC dimensioning weights from those would be possible, it would limit it to /only/ putting weight on dimensions which the function approximation finds correlations in, and it's important to note that the function approximation wouldn't detect ALL possible correlations which might turn up in the DC. After all, I want this to be able to fall back on strong traditional DC results whenever the function approximation is failing to find correlations. Therefore, I'd have to use fixed dimension weights or adapt them with some other heuristics (that entropy talk sounds interesting) just like everyone else. Of course, this function approximation enhancement I'm planning to implement could certainly still improve results when there the neighbors are smaller in numbers or further away (which means things like, it should dodge LinearTargeting perfectly before taking as many hits as plain DC would need to take to learn it well enough), even if it doesn't help with weighting. -- Rednaxela


Hmm, funny. I was testing my GuessFactor calculation code in my latest bot, with my bot sitting still and calculating the GuessFactors of bullets that hit it. For some reason I was getting these odd discrepencies when the other bot should have been targeting me at the 0 GuessFactor. So, I spent a long time debugging. I then switched from Horizon to Shadow to test it. Turns out nothing was wrong with my code at all, and that all that debugging time was because Horizon didn't (couldn't?) target perfect head-on while it moved. In any case, yes, debugging is fun, particularly when you end up spending time only to find your code is working as it should. :)
Edit: Hmm, I think I once saw ABC mention accounting for how your own movement will change the angle when targeting, in other words, account for how rotating the turret happens after firing happens on a tick and not before. I'm guessing this is what Shadow does differently than the others in order to get perfect head-on while moving. It's interesting how Shadow does this yet many other top bots do not and they still do very well. I suppose this small inaccuracy isn't large enough to be a big disadvantage practically.
-- Rednaxela

Well, tonight I managed to hack up enough code to make a very simple surfing for Rouge around the complex components I already built. It uses that precise botwidth, dynamic clustering, but that doesn't by any means mean it works good. Currently it has the following points of being horrible:

So all those factors make it REALLY horrible. On the other hand, it can outlive some of the weaker nanobots without even firing, by cheekily dodging their poor targeting at the last moment. Actually I'm surprised how long it can live against Shadow despite being so horrible. It's actually kind of amusing how many near misses Shadow has against it though, which I suppose indicates it's able to at least learn something of how Shadow targets it, even if it's movement is one of the worst I've seen. I really really hope I can figure out why the heck it's dodging so late... -- Rednaxela

Well, I just made it account for multiple waves, weight all of it based on a formula of 1/t where t is the time till the hit, and fixed a bug that caused it to be indecisive about what direction to move. This seems to have made it work significantly nicer. Even so it still has many deficiencies noted above. On the other hand, I just saw it get very lucky and and survive a lucky round against Shadow without firing a single bullet. It also seems I'm able to survive 100% of the rounds against RaikoNano without firing a shot, and also win in score despite having no ramming or bullet scores. I suppose it is surfing decently now. Now I just have to fix other bugs, and then add more features (distancing, avoiding walls, and some other stuff) to make it somewhat decent. -- Rednaxela

How about releasing a preliminary version with a standard gun, like Raiko's? Often releasing to the rumble can help you identify more bugs by seeing who your problem bots are. -- Skilgannon

Perhaps in a bit, however I first want to get at least a few of the deficiencies fixed. Just now I fixed one bug that was making it's "perpendicular" positioning be rather wobbly. When I did that though, it's performance against RaikoNano became far far worse and started losing every round, yet it's performance against Shadow increased a bit. I suppose that fix created nicer movement in some ways but got rid of a wobble that caused RaikoNano problems. Anyways, I at very least want to get distancing and some form of wall avoidance in before making a preliminary release as such, and probably add a little more segmentation. Thanks for the tip in any case. -- Rednaxela

If you like I can run a couple seasons on the movement challenges (I still have access to the distributed setup here at tech). --Chase-san

Thanks for the offer, though it's not quite ready for that yet I think. First I hope to at least get some WallSmoothing set up, and possibly some more proper distancing (currently it doesn't really distance, and just factors "prefer to be far away" and "perfer not to hit walls" into the dangers). In other news, I threw the Raiko gun onto it and tried a few bots around the place. I'm yet to beat any top bots using my movement and the Raiko gun, however in one trial it was giving WaveSerpent a very tough match, scoring 43% over 35 rounds, but up until about halfway it was about a 50:50 split. In order to get this far, I since added a "tolerance" factor to make it dodge by larger margins (before it was too precise and imprecision in the opponants was messing with it), made it assume waves are targeting head-on until it gets hit, and I replaced perpendicular/advancing movement, with kinda Tron-like horizontal-vertical movement. The reason I did the horizonal-vertical movement, is that easily gets around the issue that it was getting stuck in corners before with perpendicular. Once I add WallSmoothing I may go back to some kind of more perpendicular movement though. -- Rednaxela

Well, it's looking like that good result against WaveSerpent was mostly luck, but in any case I think I've made some improvements. Currently the movement is only segmented on LateralVelocity with a weak segmentation on total time (including time from previous rounds) to bias lightly towards new data. I got WallSmoothing working using a slightly modified version of Voidious's example on the WallSmoothing page and it seems to be working. Just in case anyone is curious, or if you run the movement challenge on it Chase-san, here's [[the current state of it]]. Unfortunately, while it accurately surfs simple things well so far as I can tell, it apparently is somewhat predictable to more adaptive targeting. -- Rednaxela

I know that with my DC-surfing attempts I weighted scans by the inverse of their distance to the current scan. This was a huge improvement. Also, I built these inverse weighted scans to a set of VCS bins, using a similar algorithm to what BasicSurfer uses for BinSmoothing. All this was courtesy of ABC, BTW, who shared this info of what he did on Shadow-- Skilgannon

Yes, I haven't heard of how people are doing that but, I imagine doing that would certainly help. I have a similar but more elaborate idea I plan to try with some interpolation some time. In particular, using function approximation (i.e. multiple linear regression) and and making a "fake" scan that is where the function approximation guesses it would be, and weight that fake scan by how closely the function approximation matches the real scans. I then use the normal scans and weight them by how much they deviate from the function approximation divided by their distance from the current scan. The advantage of this I think, is that if there's a very well-fitting correlation in the scans, this will only dodge the /exactly/ the point the enemy would aim at given those scans (i.e. a linear targeting enemy would show a strong correlation on lateral velocity). If there is less of a correlation, it would dodge the real scans more because it has nothing better to go on. -- Rednaxela

Well, I had a stupid bug where it didn't properly account for how one part of the bot shadows other parts of the bot, during precise wave hit prediction. That caused some parts of the bot's surface to be weighted excessively in the danger calculations. I just fixed that now and it's performing far better. I also fixed a major inefficency and now it's running nearly 10x faster (still not a terribly fast bot though). Now that those issues are resolved, I guess I'll get to that weighting of the scans :) -- Rednaxela

Hmm, I tried the weighting you suggested, and it reduced my score against WaveSurfingChallengeBotB from 78.252 to 73.382, so I'm not sure weighting by distance as such is too effective. I'm curious, about how many nearest neighbors are you looking for when doing DC-surfing? For the aforementioned results I've been using 10 nearest neighbors. I just changed it to 100 though now and it appears to be getting somewhat better results but the 500 rounds aren't quite finished yet so I'm not sure. After this I'll probably try 100 points again, without your weighting, and see how that works to compare. -- Rednaxela

Well, hmm, I can't seem to break 80 points against WaveSurfingChallengeBotB... Perhaps whatever is going wrong is not related to weighting at all... perhaps it's that silly wall issue. I'm not sure if that would fully account for it though. I wonder how well some of the high up bots in that challenge would score if they set their preferred distance to be as far away as possible... -- Rednaxela

Hmm, well here's how I do against WaveSurfingChallengeBotB in a few different configurations of weighting and number of neighbors to find (note, in 1/d, d is the elucidian distance between situations):
10 neighbors 50 neighbors 100 neighbors
No weighting 78.252 78.120 79.554
1/d weighting 73.382 82.472 78.604
So it seems the weighting doesn't make a significant difference here. Against a version of bot B, that is modified to not fire if it predicts out of map bounds, and I score 98.200. A similarly modified version which plain ignores map bounds, I score a little lower but similar against. So, I think that really, my biggest problem is that I either need to avoid sticking so close to walls, segment against them, or better yet, both. -- Rednaxela

Hmm, I was trying it out with the Reiko gun against some of MC2K7, though unfortunately I can't do the full thing as the link to download the modified bots is broken. I seem to get scores about the same as Firebird against CassiusClay and Ascendant, however I seem to get a far worse performance against Chalk. My score against GrubbmThree also seems respectable compared to other bots in that challenge. I can't try the other parts of the challenge yet as they involve modified bots I don't have avaliable, and nor did I try many seasons for the bots I did test with, however things are looking fairly promising. Against an unmodified HawkOnFire I score about 99.2% or so, which isn't too great compared to what ones in the challenge score, but perhaps the modified HawkOnFire being less conservative with it's energy would improve the result a little. Here's another [[snapshot]] of it for archival purposes. One change I did in addition to what was talked about before, was I made it also use BulletHitBullet? events to get an idea of the enemy's aiming. I'm thinking I may switch to perpendicular movement and add some distancing... -- Rednaxela

I was meaning to upload my copy of that zip file when I got home, but never got around to it =). I'd be interested to see what you get. -- Skilgannon

Thanks, now I just either need to get RoboResearch working (bah, stupid exception) or find time to manually deal with all of it. In any case, thanks :) -- Rednaxela

Well as you're interested to see what I get in MC2K7 fast learning:
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha2 Rednaxela DC WS 97.75 85.39 69.86 84.33 60.84 68.33 68.81 68.57 32.52 32.26 32.24 32.34 61.52 7.0 seasons
In other words, not so great really, and some of my earlier data was based on some lucky trials for some part. I'm pretty sure my biggest issues are because RougeDC doesn't have a proper concept of distancing and is always up against a wall which makes it considerably more predictable and also makes the enemy targeting less predictable to it (i.e. linear targeting that accounts for walls). I'll make some changes to it's movement choices (perpendicular based, as opposed to it's current horizontal/vertical scheme) and try to integrate some kind of distancing. -- Rednaxela

Hmm, well my first attempt at making the movement perpendicular didn't work out so well. I think I'm going to revret back and try to add distancing to my old movement instead.
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha2 Rednaxela DC WS 98.21 84.26 70.67 84.38 63.29 68.39 68.91 68.65 33.17 33.83 33.07 33.36 62.42 15.0 seasons
RougeDC Alpha3 Rednaxela DC WS 90.88 79.74 68.49 79.70 59.61 66.34 68.43 67.38 30.34 30.68 33.68 31.57 59.56 15.0 seasons
-- Rednaxela

Unless you add some sort of distancing I think a Tron-style vertical/horizontal movement will be superior. Keeping your distance is VERY important. -- Skilgannon

Yeah, and it seems to help Tronish movement too to distance. I reverted to Tron-ish surfing, and then added a light distancing danger that prefers 600, and increased the wallsmoothing factor. The results is kind of interesting. There is a consistent increase in score against the advanced targeters with the exception of Waylander and including GrubbmGrb (for purposes of this discussion, the way it accounts for wall interaction counts as advanced), and a notable decrease against all else. I think the problem that's happening here, which I confirmed by watching it battle HawkOnFire, is that now it's frequently diving into the enemy when dodging bullets. While it no longer has the old high level of wall interaction and prefers a distance of about 600, it is tending to dive as close as 120 distance due to how the danger of individual waves overrides all else. I'm thinking I might need to switch distancing strategies, to throw out movement options which as too far from the desired distance. I'm also thinking it might be interesting to give it both Tron-ish and perpendicular movement as simultaneous options to evaluate. It shouldn't hurt so long as I fix distancing to throw out the worst movement options for distancing completely.
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha4 Rednaxela DC WS 94.40 77.24 73.22 81.62 62.75 52.16 70.16 61.16 36.01 36.57 35.48 36.02 60.39 6.0 seasons
Update: Well, I just gave it a test with this distancing but without the wallsmoothing change, and performance decreased notably. It appears my wallsmoothing change was what caused those improvements, not distancing. Anyways, it's still true that the main issue with this distancing is that it keeps diving to short distances. So in any case I'm going to try setting up distancing that's stricter about not using movement options that are particularly bad for distancing, and possibly using perpendicular options at the same time

-- Rednaxela

Well, both to clean up things, and to prepare for simultaneously supporting "tronish" and perpendicular movement, I refactored some things. Now I think it's in the same state as RougeDC Alpha2 except without the behavior of running away when there are no waves (note it's lowish score against GR3), and cleaner more flexit to pass up better options that it might have saw if it started by first moving in the other direction, but really I don't think that's too big an issue. Also, I really think that applying the "Voidious-style surfing of multiple waves" method of letting True Surfing recursively evaluate options of changing it's path when one wave passes (or in the case of this discussion, a virtual gunheat wave is fired), could really mitigate this disadvantage. -- Rednaxela

Well here's another <ble surfing code.
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha5 Rednaxela DC WS 98.78 83.62 70.47 84.29 66.43 45.33 73.61 59.47 30.81 35.85 36.15 34.27 61.11 11.0 seasons
In my next update I'll have added perpendicular movement and added stricter less dive prone distancing than I tried before.
-- Rednaxela

By the way Skilgannon, I just realized that my surfing code actually lends very very well to your idea of "Tracking the enemy gunheat throughout the prediction, and firing off 'virtual' waves for when their gunheat is zero. These waves can then also be surfed, and factored into the danger for a direction.", so that will probably the next think I implement after I add perpendicular movement and get distancing working decently. I'm particularly thinking this will be interesting for cases when there are no real waves in the air and may make it possible to dodge a little better better in close range due to getting pre-accelerating to what would be needed to dodge. Come to think of it, this could work really well probably if I took a page out of Voidious's book and give it the option of chosing a different direction after the wave is fired (based on the technique that Voidious uses to surf two waves). Hmm, this could also allow a bot to take advantage of the 1 tick delay in the other bot's scan data, by starting to dodge 1 ticks BEFORE they fire, which is 2 ticks before most surfers would detect the bullet... This could allow it to dodge with similar safety at up to 22 units closer to the enemy, as this would basically give two extra ticks to dodge in... One thought though, is it would probably be necessary to keep track of if the particular enemy does indeed actually fire as soon as it's gunheat is 0. Hmm, for this to be accurate though, you would probably need to keep segmented stats on what firepower the enemy uses, probably segmented on distance, hit rate, their energy, and your energy. Just some thoughts on that gunheat idea of yours and how to expand on it...-- Rednaxela

The thing is, I don't think True Surfing lends itself to this idea very well, because you may need to change direction, and the 'firing off virtual waves' depends on segmentation data that could be incorrect if your movement decides, say in 3 ticks, to try going in the other direction. If I ever find the time I'll implement this in my Goto Surfing, and I think it would be more accurate than True Surfing due to being able to predict with 100% accuracy what the enemy will be seeing, and thus getting the attributes/segmentation correct. -- Skilgannon

Well, one thought, is you could actually fire off such 'virtual waves' in your main loop instead of in precise prediction, 2 ticks ahead of when you would detect the energy drop, and since at that point you know the scandata the enemy would see, it could be done unambiguously. This may not have as much potential benefit as doing it during precise prediction also, but even so, could be applied to ANY movement which reacts to enemy firing to gain 2 ticks of dodging time, which I think could be significant. Secondly, while True Surfing does change it's mind and thus wouldn't know the segments they see as accurately, it only changes it's mind when it sees a "better" option. Now, sure, this may cause it to pass up better options that it might have saw if it started by first moving in the other direction, but really I don't think that's too big an issue. Also, I really think that applying the "Voidious-style surfing of multiple waves" method of letting True Surfing recursively evaluate options of changing it's path when one wave passes (or in the case of this discussion, a virtual gunheat wave is fired), could really mitigate this disadvantage. -- Rednaxela

Well here's another RougeDC update:
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha5 Rednaxela DC WS 98.39 83.67 71.46 84.50 66.16 46.00 73.33 59.66 32.40 35.68 34.95 34.35 61.17 15.0 seasons
RougeDC Alpha6 Rednaxela DC WS 95.38 72.85 72.24 80.16 57.05 49.06 29.67 39.37 26.21 37.17 37.78 33.72 52.57 10.0 seasons
In Alpha6, I'm still just using tron-ish movement, and added distancing with a policy of "if the distance from the enemy is more than 50 from the preferred distance, discard movement options which lead further from the preferred distance", with a preferred distance of 425 for now. In effect, this meant that most of the time, the only 2 "Tronish" movements are available plus a stop movement. This seemed to lead a performance drop across the boards, except against GrubbmGrb, CassiusClay and Chalk. Particularly distressing is the decrease in performance against RaikoMicro score and HawkOnFire score. So, to sum up some of what I think I've discovered:

I plan to add perpendicular options now to see how that works out. Either way though, one thing concerning me are my less than stellar scores against HawkOnFire even before with the 98.39. When I observe it battle I notice that sometimes it on rare occasion seems to get stuck and then hit. At first I suspected my precise prediction wasn't detecting me getting hit when it should have detected it, however when I looked at the danger logs of movement options, it knew ahead of time that it was going to get hit for sure, so it was clearly predicting the hit. I'm not really sure what's going on and suggestions are welcome, but I'm currently suspecting my WallSmoothing may breaking things and I'll add some debugging graphics to help diagnose that.
-- Rednaxela

Hmm, I have a bit of question about distancing when surfing if anyone with some experience might be able to answer. Well, while there is much information around about how to surf waves and such, and I seem to have the basics of predicting the danger of movements down pretty solid, there seems to be very little information around on distancing and I can't for the life of me figure out how to make a half-decent distancing mechanism. The only explation I've seen of how people do it, was Voidious mentioning that he uses a method of modifying the angles of perpendicular movement to dive towards the enemy or move further back. What I wonder about that though, is what is that distancing is relative to? You could use the distance to the origin of the nearest wave, however that would not be an accurate reflection of current distance to the opponant. Alternatively, you could use the current distance to the opponant, however it's future values are unknown and thus it would throw off precise prediction quite notably possibly. So my question is... how the heck to people get around those issues when distancing? :) -- Rednaxela

Well, I just took a look at the code of CassiusClay and Dookious. I couldn't find the distancing code in CC for some reason, but I quickly found it in Dookious. It seems Dookious does the first option of what I said: distance relative to the origin of the wave it's surfing. So I suppose that wouldn't be too big of an issue I guess then. My question is still open though if anyone has any comment: Anyone do it differently? -- Rednaxela

checking the (inscrutable) movement code... Garm moves perpendicular to the line from the origin to its position (at the tick when the bullet was fired). If there are two bullets it surfs perpendicular to the average of them. I have no explicit distancing, but generally Garm moves slightly away from the enemy with this method. The intention of this is to reach the maximum possible escapeangle. In comparison to the normal way of surfing Garm moves in straight lines around the enemy while the traditional Surfer moves in curves. If there is no wave at all it tries to get at its preferred distance of 450. --Krabb

IIRC, Shadow orbits the closest wave's origin. It moves slightly closer/away from that origin if the distance is out of a 200px "safe zone". -- ABC

Take a look in Cunobelin, the distancing is a very simple formula that I think is very effective, it is virtually the same as in DrussGT and Waylander. -- Skilgannon

Thanks for the tips everyone! Anyways, I made another version, which orbits oldest moving wave and distances relative to that (I know the wave to first hit me is better, I'll deal with that later), and started distancing by a method of smoothly adjusting the attack/retreat angle based on my distance from the desired distance, but never deviating more than 45 degrees from perpendicular (unless wallsmoothing does it). When there's no wave, just use plain advancing/retreating movement to get to the desired distance, and using a desired distance of 400 for now. Here's the results:
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha5 Rednaxela DC WS 98.39 83.67 71.46 84.50 66.16 46.00 73.33 59.66 32.40 35.68 34.95 34.35 61.17 15.0 seasons
RougeDC Alpha7 Rednaxela DC WS 97.43 85.23 79.01 87.22 61.95 66.12 67.47 66.80 28.14 35.91 34.58 32.88 62.21 7.0 seasons
So not too bad, I'd say my best result with proper distancing yet, big gains on GrubbmGrb compared to any of my previous tries. I'm still puzzled though... how do people get those last few percents against HawkOnFire? I wonder if it's necessary to do as Dookious and X2 do, with giving the precise prediction the option of changing direction after the first wave has passed, or if there is some bug causing many of the times HawkOnFire is hitting me... I wonder if I'm begining to understand WaveSuffering... -- Rednaxela

I don't think you need the multiple waves at all to do better against HawkOnFire - try Komarious against HOF and see how she fares, which I think is pretty well. She only surfs the closest wave. -- Voidious

The thing about HOF is that it doesn't always shoot completely Head On. HOF doesn't have setAdjustGunForRobotTurn(true);, so if it is turning the body of the robot while it fires it will be quite a bit off. I suggest you make the BinSmoothing on your surfing algorithm smooth wider, so that your bot keeps away from the center better. Also, you mentioned something about random freezing - this is the surest thing to reduce your scores in challenges, and unless you get rid of this completely that last percent or 2 is going to be impossible to get. -- Skilgannon

Well, actually Shadow is about only bot I've seen actually be capable of doing absolute perfect head-on when moving (even other top bots don't seem to consider the delay between turning the gun and firing). In any case, I already pretend the range of guessfactors hitting me is 0.09 wider than the actual from my ultraprecise botwidth, in order to account for inaccuracy as you're noting Skilgannon, and I think 0.09 should be more than enough for that. Also, I'm 95% sure that random freezing was fixed many versions ago back when I fixed a very major inefficiency (now I spend about 1/30 of the available time processing my surfing, as opposed to over 1/2 before). One thing I am noticing though from new debugging graphics... is that on very very rare occasion, the wall smoothing is getting the direction to smooth in wrong and very occasionally it seems to get hit then due to that restricting movement options, and also, for some reason, on very very rare occasion, I'm not detecting the waves of very small/fast bullets fired just as they die... Those two events are extremely rare, but I wonder if those could be the primary problems... -- Rednaxela

0.09 is not enough - if you have debugging graphics to see where GF0 is and watch about 10 battles between you and HOF you'll see a few bullets that are at about GF +-0.3. My latest versions of DrussGT score higher than the earlier incarnations, particularly against HOF, because they have the option of keeping moving at full speed to get out of tricky situations. My BinSmoothing weights any position as the sum of the inverse GF distances squared from all the shots in that segment. So the further away the less dangerous it is (the same idea as in BasicSurfer - take a look at the code for the BinSmoothing, it works very well). This effectively pushes my bots right to the edge of GF 1 against Head On bots, keeping them far away from wobbly guns. This could also improve your scores against Splinter and GrubbmGrb. -- Skilgannon

Hmm... you're right... I ran 66 rounds againt HOF, and the lowest GF I detected it aim at was -0.4553 and the highest was 0.2444. Note, those are not what my bot got hit at necessarily, as most of my targeting data against HOF is from BulletHitBullet? events rather than bullets hitting me, but indeed this shows where HOF is aiming. So yes, this does certainly seem to be a factor that I will have to deal with. Note "binsmoothing" exactly literally doesn't apply as I don't have bins with my use of DC, but indeed equilivant smoothing should be put on the data samples. So yes, this does need fixing, I'm not sure this is the biggest factor though, because the majority off the hits I do actually take are still within GF +-0.09, and in fact within GF +-0.03... so there's something else at play... -- Rednaxela

I would check that you're actually moving where your precise prediction thinks you are. Make sure you're rotating around the wave you're surfing, wallsmoothing using the same limits, going in the same direction, that sort of thing. This is the primary reason I chose Goto Surfing, because once I get the simulation correct I just say goto(point); and all the rest of the work is done for me =). Welcome to WaveSuffering =) -- Skilgannon

Well, to simplify that, I made a "RobotDriver?" interface, which, for a given robot state wave list state will always output the same results, and also a "VirtualRobot?" interface that it runs on, and I have implementations for my status, the enemy status, and then I have a "VirtualRobotPredictor?" abstract class that implements "VirtualRobot?" and handles perfect robocode physics, and then I have "SurfingPredictor?" that's a subclass for that, which controls the VirtualRobotPredictor? based on a RobotDriver? that I give it, and it gets the danger of using that RobotDriver?. In any case, I do have a nice architecture in place to promote code reuse and ensure exactly the same code is steering both the predictor and the real robot. That said, that there could still be holes in it of course. Anyways, I know my wall smoothing is sometimes using the wrong orientation (i.e. clockwise counterclockwise), and that should be fixed regardless of if it's the main cause. Also, I'm not sure exactly the circumstances but sometimes I'm not detecting waves of the opponant they fire at the same tick as they die... Welcome to WaveSuffering indeed... -- Rednaxela

I think you fire bullets with a power less than 0.1 if your energy is below 0.1. And you probably have a conditional like energydifference=>0.1D somewhere in your detection code. But I'm not sure :)--Krabb

Nope, I use energydifference => 0.01 instead. Reason being, in the code of Robocode itself, it counts a robot with less than 0.01 energy as dead :) -- Rednaxela

HAH! I fixed the wall smoothing to use the right orientation, and now I had a big performance increase!
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha7 Rednaxela DC WS 97.43 85.23 79.01 87.22 61.95 66.12 67.47 66.80 28.14 35.91 34.58 32.88 62.21 7.0 seasons
RougeDC Alpha8 Rednaxela DC WS 98.70 84.79 82.53 88.67 64.65 71.66 73.77 72.72 29.47 37.49 38.50 35.15 65.30 7.0 seasons
Hahaha! I also appear to have made a record score of how well anyone has done against GrubbmThree in MC2K7! So, things still aren't perfect, but fixing that bug was a big help! Finally this score is becoming somewhat respectable. So... now need to figure out where I'm still losing points to HOF. I'm thinking I'm going to try smoothing to keep further from danger like Skilgannon is saying... It's a little more complicated to make smoothing as such work with the way I'm using precise per-tick botwidth and DC, as opposed to single botwith and bins, however I think I know how to do it. -- [Rednaxela]

Well, I implemented the suggestion Skilgannon had to make it try to get as far as it could from the danger points. Not really an overall improvement though. So... now that I've broken the 99.0 barrier against HOF, I need to figure out what is preventing me from getitng past the 99.5 mark...
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha8 Rednaxela DC WS 98.56 84.99 80.25 87.93 65.37 70.94 74.59 72.77 29.29 37.22 35.77 34.09 65.04 15.0 seasons
RougeDC Alpha9 Rednaxela DC WS 99.12 84.82 82.61 88.85 64.52 71.86 74.52 73.19 28.45 37.39 34.47 33.43 65.00 15.0 seasons
-- Rednaxela

Hmm, to figure out what's happening now, I decided to watch more HOF battles in real time.... after what seemed like half an hour of watching RougeDC not getting hit at all, it finally got hit. The circumstances of getting hit, were that wallsmoothing had caused it to dive in too close to HOF. So, I suppose some kind of DiveProtection is what I need next in a quest for perfection against HOF? :)
Update: Huh... or not... I was running my earlier manually run tests using HOF 0.1, however when I switched to HOF OS MC2K7 like RoboResearch was using... It suddenly became prone to not continuing forward after it thought it dodged the wave... so I guess I need to figure out what the heck is happening differently with the MC2K7 version of HOF that could cause this... -- Rednaxela

Heh, well, made some slight changes to how it "smooths" the hit data in 9a.... Then in 9c I made further away waves weighted exponentially less as opposed to linearly less...
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha9 Rednaxela DC WS 99.12 84.82 82.61 88.85 64.52 71.86 74.52 73.19 28.45 37.39 34.47 33.43 65.00 15.0 seasons
RougeDC Alpha9a Rednaxela DC WS 99.07 84.01 82.59 88.55 65.95 72.48 73.14 72.81 28.57 37.48 36.34 34.13 65.36 15.0 seasons
RougeDC Alpha9c Rednaxela DC WS 99.08 83.26 82.00 88.11 65.66 72.04 70.97 71.51 26.24 36.66 37.09 33.33 64.65 15.0 seasons
Not too successful... The ideas I have currently to move further are DiveProtection, and giving the precise prediction the option of changing direction after the wave passes. It's hard to find where the problem is after passing the 99 mark it's seeming... -- Rednaxela

Haha! I just implemented the idea of tracking enemy gun heat, and firing virtual waves the turn before they fire (the last turn they get a scan of me on before firing), inspired by Skilgannon. Unlike what Skilgannon was thinking, I don't fire these virtual waves in the precise prediction, however I fire them in the main loop 2 ticks before I'd see the energy drop. In order to support this, I also made a KDTree keep track of stats of enemy firing power, segmented on my energy, their energy, and distance. So what's the result? I'd call the following a success :)
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha10 Rednaxela DC WS 99.41 85.28 84.35 89.68 63.88 72.57 75.96 74.27 30.44 37.60 37.72 35.25 65.77 15.0 seasons
It appears that these virtual gunheat waves gave me the ability to surf safely notably closer than otherwise! I think what's happening, was that my biggest area of point loss against HOF was when I dived towards it due to lack of dive protection, however these gunheat waves made the diving considerably less dangerous because two extra ticks means a lot at close range :) -- Rednaxela

Hmm... well... I've felt pretty good today with how I've gotten close to the 99.5 mark on HOF and have a record score against GR3, however... now I'm getting frusturated again and it's feeling like WaveSuffering some more... It's being difficult to figure out what's causing these last few hits of HOF on me due to how rare they are. I wish it were possible to save the replays that Robocode can do, and then replay specific moments when my bot was hit. Actually.... perhaps I should go to all the massive trouble of making my own bot construct custom replays exported as an animated gif file... but that's a pain because I'd need to store a lot of history for that to work... bah stupid WaveSuffering... -- Rednaxela

Wow, it seemed that firing the waves 2 ticks earlier really helped, especially against the close-distance fighters. I'll have to give that a try =). How about simply recording, when you get hit against HOF in ticks from the beginning of the round, where you are, where he is, where the wave was fired from, what GF you were hit on (or the minimum and maximum GF of your bot on the wave), what the bullet power is, what the distance you are from the wave center (this can be calculated afterwards, I guess), that kind of stuff. Then look for trends in the data, rather than watching all 50 rounds. Oh, another usefull one might be what the danger at the point you are at is, or perhaps an entire 'range' of dangers on the wave at different GFs. But before you draw too many conclusions, another 35 seasons wouldn't go amiss :-). I've seen bigger deviations than that after 15 seasons, although this does seem fairly across the board improvement. -- Skilgannon

Well, more seasons would indeed be good, but I tend to be fairly impatient. Even when running two battles at once taking advantage of my duel core processor, it still takes an hour to run 15 seasons. I suppose I will run a longer trial some time though. As far as debugging, one neat thing I added, was a code snippet that takes a "screenshot" of my debugging graphics whenever I get hit (if anyone wants I could paste the code snippet somewhere), making a different graphics context passing to my onPaint() and saving the image in my robot's data directory. So far I'm still not sure what's going wrong, though some things look a little wonky. I think I'll need to add more information to these graphics in any case, but I am really liking this debugging method of automatically taking snapshots of my debugging graphics whenever I'm hit :) -- Rednaxela

    public void writeImage() {
        java.awt.image.BufferedImage image = new java.awt.image.BufferedImage((int)getBattleFieldWidth(), (int)getBattleFieldHeight(), java.awt.image.BufferedImage.TYPE_INT_RGB);
        java.awt.Graphics2D g = image.createGraphics();
        g.setColor(java.awt.Color.BLACK);
        g.fillRect(0, 0, image.getWidth(), image.getHeight());
        onPaint(g);
        try {
            System.out.println("Writing image!");
            
            robocode.RobocodeFileOutputStream stream = new robocode.RobocodeFileOutputStream(getDataFile(getRoundNum()+"_"+getTime()+".png"));
            javax.imageio.ImageIO.setUseCache(false);
            javax.imageio.ImageIO.write(image, "png", stream);
        } catch (Exception e) {
            e.printStackTrace(System.out);
        }
    }
Wow.... all this time I had a really stupid bug where I would often match the wrong bullet to the wrong wave, when they were of the same power, and the one I was matching was not the oldest wave (happened a lot when my bullets hit their bullets). I'm very surprised I did as well as I did with that error there, because not only would that cause me to get hit sometimes when getting rid of a wave too early, but it also intefered with my data on the enemy targeting. Anyways... that really dumb bug is now fixed I think... I guess I'll run some seasons, maybe a few more seasons this time if I have the patience. -- Rednaxela

So you're now matching on distance traveled as well as bullet power? -- Skilgannon

Before I thought I was matching on source bot name, bullet power, and distance traveled. Turns out "distance traveled" was completely broken though... I think I have it fixed now. -- Rednaxela

Well, since that bugfix, I now seem to have a HOF score I can be rather proud of, even if it's not quite up to Dookious's 99.90+ score.
Bot Name Author Type HOF SPL GRG Sub 1 WAY (Sub 2) GR3 RKM Sub 3 ASC CC CHK Sub 4 Total Comments
RougeDC Alpha12 Rednaxela DC WS 99.85 84.95 87.93 90.91 65.80 72.81 76.26 74.54 29.26 37.74 37.49 34.83 66.52 31.0 seasons
So now that HOF is basically conqured and I trash GR3 better than anyone else does, I wonder what to work on next... will it be SPL, GRG, WAY, RKM, or the advanced trio... -- Rednaxela

What about releasing a version with Raiko's gun to the rumble? I think you got the worst bugs out now...and I want to see how it does =) -- Skilgannon

Well... there's one bug that's really bugging me that I want to fix before considering a preliminary rlease to RoboRumble. In particular, it still freezes very very occasionally. Unfortunately this is so ridiculiously rare that I haven't been able to pin down when it's happening (i.e. 1 in 1000 rounds or so). If anyone has any suggestions to figure out where this bug is, that would be welcome. I wish that Robocode had an option of pausing the battle as soon as a robot freezes, giving me a chance to figure it out in a debugger... -- Rednaxela

Do you know if it's stopping from timeouts or exceptions? Some of the trig functions can throw exceptions in rare circumstances, for example Math.tan(PI/2) and so on, if you take the result and pass it to something else. If it's timeouts look for loops that could possibly not terminate in time due to special circumstances, wallsmoothing comes to mind. But release it anyways! When you find the bug you can see how much of a difference it actually makes. -- Skilgannon

It's a timeout that's happening, but I'm not sure what loops I have which could be doing that... Anyways, yeah... fine, it's in the rumble now. I'll keep versioning in "Alpha" while using the Raiko gun, change to "Beta" when I have my own gun, and then toss the prefix once both movement and gun are something that mildly satisfy me :) -- Rednaxela

Um....this might be a bit premature, but welcome to The2000Club ;-) -- Skilgannon

It's looking like it'll make it... but... I won't consider it entry to The2000Club until I do it with my own gun :) -- Rednaxela

Well it's doing alright... now I wonder what it's weaknesses are that are most in need of improvement...

Not sure what I'm most in need of, but those are ideas that come to mind.... I'm not sure what to work on first... -- Rednaxela

Well, or instead I could:

Those might be a nice break from WaveSuffering.... -- Rednaxela

Well, I took a look at GrubbmThree's details in the RoboRumble, and it confirmed regardless of gun, I'm GrubbmThree's worst enemy. Some of Kev's high level bots come close, but nobody in the whole rumble can beat GrubbmThree better than I am :)
Update: Oh, and bayen.UbaRamLT, benhorner.PureAggression, demetrix.nano.SledgeHammer, jab.micro.Sanguijuela, mz.NanoDeath, and every single rambot I've fought that I've looked at the details of... In some cases I'm getting about 80% against rambots where nobody else can get past 75% or even much past 70%! It looks like I've created the best ever surfing aginast RamBots and I'm not even using DiveProtection that some people seem to think is so important :) -- Rednaxela

Well, RamRod seems to be an exception... it's the one RamBot I'm not trashing better than everyone else. All signs seem to be that RougeDC does very well against things with basic targeting, however for the most part I horribly fail against anything with even simple segmented GF targeting. Oddly, I have some weird exceptions like trashing Firebird or GrypRepetyf, but for the most part, if the enemy targeting is decently adaptive my movement sucks. I'm suspecting that my stat handling and lack of flattener is really my problem... I am happy though that I seem to be the king of RamBot trashing with the sole exception of RamRod :) -- Rednaxela

How about having your nearest neighbors number vary depending on the size of your log. Giving the surfing the option to change direction definitely can't hurt. Also adding distance as a attribute to your surfing stats, and maybe (time-since-direction-change)/(bullet-flight-time), limited at 1.5. Of course, a poetry generator to rival DrussGT's insulter would be fun =).

I'm guessing its those extra 2 ticks that give you such nice scores against RamBots - I gotta give that a try. DrussGT 1.1.0 will be here soon to challenge your RamBot supremacy! =). I need something like this to give me a few more points between me and Dookious, I'm worried that Voidious will come back with a tweak and reclaim the crown! =) -- Skilgannon

Bah! I like my RamBot supremacy! Besides DrussGT is already one of the better contenders for that place without that 2 tick edge! ;-) Thanks for the suggestions there also. One other thought, is I might want to make my distancing switch to what people would consider an abnormally close range for a surfer, whenever I'm losing, which could prove effective against better bots because that 2 tick advantage would let me do better close combat surfing than them. Of course, that wouldn't work against the ones that have strong enough distancing to avoid letting me get close, but it might be interesting to try some time. -- Rednaxela

I also thought of that, and was plannning to release a special version of DrussGT that moved in close whenever my hitrate was below a certain percentage =). Also, when you are close in, it is fairly easy to 'shepherd' bots into corners, reducing their maximum escape angles. <evil grin> -- Skilgannon


Well, I've been quiet in the last week or so, but I haven't abandoned Robocode. I got a bit tired of endless failed experiments with RougeDC so I just took a bit of a break. After a few days break, I started on Polylunar, a RR team based around LunarTwins tactics. So far, I have the data sharing, distribution of radar locks, and LunarTwins-style tag team movement working. I just stuck LinearTargeting/NanoLinearTargeting in it as the gun for now but I plan to move to something a bit more full fledged in a bit. Anyways, here's a little big of hype. It's not even close to as good as LunarTwins did against twins of Shadow, but of course, Polylunar is still an infant and not even remotely close to as well tuned as LunarTwins.

Rank Robot Name Total Score Survival Surv Bonus Bullet Dmg Bullet Bonus Ram Dmg * 2 Ram Bonus 1sts2nds3rds
1st Team: ags.polylunar.MoonFive 54231 28050 2450 19426 3333 853 119 13 22 0
2nd Team: abc.ShadowTeam 41657 15650 2000 20246 2781 907 73 22 13 0

Interesting constrast between surival as TwinDuel defined it ("1sts" column) and the "Survival" column. The first of which is survival of the team as a whole while the later of which is per-bot. Part of the reason this is probably like that, is that this current revision or Polylunar has members of the team do absolutely nothing whatsoever when they are not paired a tag team. This means that if I have one bot left it will stop moving/firing and lose no matter what which might explain part of the weird score chart. I plan to add solo-strategies for the bots soon, but that's just one item on a big todo list. I'm thinking I'll use AntiGravityMovement for un-paired bots except for 1v1 situations where I'll use something else. Anyways, it's my goal to take the crown of the team roborumble primereleague in the near future ;-)
-- Rednaxela

If that result is consistent you already have the teams PL crown, just release the team already :). Well done, finally someone comes up with a team strategy that beats the brute force approach. -- ABC

Well, Polylunar doesn't fare as well against AlephTeam? as it does against Shadow though it still wins, and TeamDeath? is even more problematic:

Rank Robot Name Total Score Survival Surv Bonus Bullet Dmg Bullet Bonus Ram Dmg * 2 Ram Bonus 1sts2nds3rds
1st Team: ags.polylunar.MoonFive 50908 25900 1300 19602 3219 790 98 10 25 0
2nd Team: rz.AlephTeam 45191 17800 2350 21155 3162 622 102 25 10 0
1st Team: ags.polylunar.MoonFive 45900 24500 2700 11748 1588 4801 564 21 14 0
2nd Team: amz.TeamDeathTeam 43093 18650 1200 12406 1522 7962 1352 14 21 0

In any case, thanks for the complement. I guess I'll release an early version pretty soon, but I want to make unpaired bots just a little better than SittingDuck before releaseing :) -- Rednaxela

It's pretty awesome to see a successful new team strat show up after all these years. Can't wait to see your team released! I'll save my real "congrats" for then. =) -- Voidious

Thanks! Well, now it's released. Just need to see how it will actually perform in the rumble. :-) -- Rednaxela


Robo Home | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited November 26, 2008 0:50 EST by Rednaxela (diff)
Search: