User talk:Skotty

I Hate Wall Avoidance

I hate it with a passion. I'm still trying to come up with an elegant solution. Since one of my main drive strategies is "orbital", I'm now toying with the idea of moving my orbit target to avoid hitting the wall, rather than trying to adjust orbit path separately. Though I'd prefer a solution that works regardless of drive strategy.

I still have a lot of work to get my drives working well in general. However, I may have to stop playing Robocode again soon. Too many other things I need to get done...

Have you tried Wall_Smoothing ? If you are not wave surfing, you will probably also want to have some explicit Dive_Protection . If you are having trouble implementing those elegantly I would suggest you take a look at the Wave_Surfing_Tutorial) --AW 21:37, 31 May 2011 (UTC)

Been awhile since I posted this, but I wanted to touch on it again. I am using the typical implementation of wall smoothing, but I don't consider it elegant. The path is a little irregular when cruising around the edges of the battlefield, and it's possible to run into a wall when approaching too quickly and at too steep an angle to turn in time. I still have working on a better solution on my TODO list. I may work on it in the near future. Now that I've built the ability to predict drive paths into my components, it should be easier to achieve a better solution that can get closer to the walls while running into them less. -- Skotty

FYI - I think this one's pretty elegant: Wall Smoothing/Implementations/Fancy Stick. --Voidious 19:23, 27 June 2011 (UTC)

That's actually very close to some pseudocode I already came up with. Mine also takes velocity into account, which I'm not sure if fancy stick was meant to or not (I kind of just skimmed it). I currently call mine dynamic wall arc. Instead of a stick, I use a 180-degree arc, and it's dynamic, because it changes based on robot velocity. Because it takes velocity into account, my the method for my approach returns both a smoothed angle and smoothed speed. I plan to have it finished in the next couple of days when I have some free time. It will be interesting to see if a better wall smoothing algorithm improves overall performance or not. I'm keeping my old wall smoothing code as well, as I think it is a closer approximation to what most robots do, and I want to continue using it for predicting paths of opponents. -- Skotty 23:06, 27 June 2011 (UTC)

I made a code implementation of the fancy stick on the talk page... it's not very neat but it's quick and dirty and it works =) --Skilgannon 19:14, 28 June 2011 (UTC)

I definitely know what you mean by the common form of wallsmoothing seeming inelegant. Interesting approach you're taking. As far as tuning the wallsmoothing goes, note that tighter and more accurate wallsmoothing won't necessarily be a good thing I think. The thing is, tighter and more accurate wallsmoothing means your behavior near walls will be more distinctly different than far from walls. The distinct difference will give adaptive guns aiming for you more accurate/distinct information to "home in on". (Errata: tighter and more accurate wallsmoothing on the other hand, expands the "wall doesn't affect movement" area, so... how it plays with adaptive guns has factors going both ways... The interplay with adaptive guns hard to predict without doing an in-depth analysis or just plain trying it... but either way, keep a close eye on how it affects performance against adaptive targeting)

Personally I'm hoping to avoid explicit wallsmoothing in my next surfer... sort of like how I already avoid explicit dive protection... (Maybe this is something Voidious would call me insane for, unlike about dive protection? Haha) --Rednaxela 13:33, 28 June 2011 (UTC)

I might have, but I think you already explained the details to me and it sounds pretty badass. =) --Voidious 14:28, 28 June 2011 (UTC)

I've finished a functional version of my fancy stick...trying it out in Rowdy. We'll see what happens... -- Skotty 22:30, 29 June 2011 (UTC)

Packaging Source Files

At the moment, my robot XanderCat is not packaged with source. This is fine, since the Xander framework is not entirely complete yet. Though when I am ready to package with source, I'm not sure how I will do it. I use Eclipse for development. I can add the bin directory under the developer options to run my robot while it is under development. But when I go to package it in Robocode, I'm not sure there is any way to tell it where the src folder is. I could also just check to see what all Robocode is putting into the jar files, and write my own Ant built script. Or I might just provide the source as a seperate download from the wiki page. Thoughts?

I'd also like to point out that not packaging your source doesn't necessarily keep people from checking out your code. Class files can be decompiled. Just a thought...

I too use Eclipse for development, and have never had trouble with packaging the source code. I have options -> preferences : development options set to my ...\workspace\robots\ directory which contains my ...\src\ and ...\bin\ directories, then I can package my robots in robot -> package robot for upload; this dialogue contains an "include source" check box (enabled by default). --AW 23:21, 27 May 2011 (UTC)

The preference dialogue on development options, it says that "If you are using Eclipse, you can enter the root dir of robot project inside robot workspace as well (recommend)". Robocode is able to parse Eclipse's project file to get /src and /bin dir (multiple source dir is also supported I think). That way the source code will be packed. --Nat Pavasant 02:43, 28 May 2011 (UTC) PS. I am the one who requested this feature. Before that, I have to either put the source in the jar myself (via WinRAR) or set output directory to /src

Ah...okay. I did not follow that it would automatically check for /src and /bin folders. Skotty 21:32, 31 May 2011 (UTC)

Rant on Lost Form Submissions

Bitten by poor web application design again. After having to pause one of my edits to take care of another matter, I returned a bit later, finished my edit, and submitted it. However, my session had timed out. Much to my surprise, MediaWiki did not preserve my edit. I thought MediaWiki was classier than that.

It is a newbie web developer mistake to have a web application lose someones edit due to a session timeout. The proper action is to save the edited data, give the user a chance to log back in, and then apply the edit or return them to the edit page without losing the edit. I'm often surprised at how many web applications exhibit this glaring flaw...so many, that I almost consider it my own mistake for not copying the text to notepad before submitting. But it is not my own mistake. It's the web application's mistake. A mistake that I am really growing tired of seeing again and again and again...

---

Eh? I have never had session timeout with MediaWiki. Are you sure it is really session timeout? I know for the fact that MediaWiki use token cookie for authentication. BTW, I know Chrome preserve form data on 'Back' button. I don't know about other browsers, but I think they do too.

On completely unrelated note, I found that FanFiction.net authentication system more frustrating: if I checked "Remember me for one day", it remember exactly one day i.e. if I start edit on 23.58 and finish on 24.01 hours after my login, my edit will be gone :( --Nat Pavasant 12:51, 27 May 2011 (UTC)

Robocode Bug

I like to print out some stats after each round, but I've been running into a problem. I may be limited to printing to the console. If I win, I get an Win event and a RoundEnded event. But if I lose, it appears as though I get no events. However, it may just be that the console dies before all events are fired/processed. Is that the case? It would be a pain to have to write results to a file every time. I'm running Robocode 1.7.2.2.

In my test, I do a System.out.println in each of the event methods on my main robot class (onWin, onRoundEnded, onDeath), but I only see them when I win. Thoughts? Skotty 21:39, 8 June 2011 (UTC)

I just figured it out. It happens when the main window is minimized. The events are always fired, but they can only print to the console if the main window is not minimized. Annoying, but I can live with it. Skotty 22:01, 8 June 2011 (UTC)

Certainly sounds like a bug - you should always get them, and I'm pretty sure it worked in the past, even when minimized. I have onWin and onDeath both calling a common method (maybe onRoundEnded didn't exist at some point). --Voidious 23:03, 8 June 2011 (UTC)

Painting on the Battlefield

I have been using the painting ability in Robocode to a large degree lately. It's great for debugging, and it's just plain cool. I have quite a few painting features built into XanderCat and the Xander framework now. I left them enabled in XanderCat 3.4, and I have even more cool stuff that can be turned on for XanderCat 3.5 (mostly gun stuff).

Who else out there is using the painting ability of Robocode? Are there any interesting robots to check out? Do you use it for your own bots? Skotty 15:20, 10 June 2011 (UTC)

Off the top of my head: Diamond (gun gfx need an udpate though), Phoenix (one of my favs, and one of the first to make really nice graphics), Shadow, Glacier (other Rednaxela bots?), DrussGT, GresSuffurd. Well, that should get you started. There are lots more though. Maybe Google: graphics site:robowiki.net would yield a more exhaustive list. =) --Voidious 16:24, 10 June 2011 (UTC)

• Specially Diamond is nice with its feature to turn on/off gun and movement graphics separately during battle (radar graphics does not show anything I think). That's something I definitely want to do too, because enabeling the graphics in the .ini file is just too much trouble. Tigger would be the first tank to have graphics, as stefw was the one who developed the possibility. --GrubbmGait 00:05, 11 June 2011 (UTC)
  • Radar (unless I broke it) shows last known location of each bot. In 1v1 this isn't very visible, but in Melee you can see the squares. And thanks. =) KID's menu system sounds a lot sleeker though! --Voidious 00:21, 11 June 2011 (UTC)

I've built in a lot more painting options into XanderCat and my Xander framework since I first talked about this. Right now, you have to turn painting for different things on and off by setting boolean flags. Sometimes I think it would be nice to turn painting options on and off during battle, but I haven't investigated the possibility. I know ther are interactive robots now, and it might be possible to take advantage of the mouse controls to be able to turn paint options on and off. However, the bigger issue I am working on solving, is that I built the painting ability into individual components, and I now want to seperate that code from the components. What I am doing for the moment is defining interfaces for different kinds of components with getter methods for the information that would be needed to paint. I then create a seperate painter class for that type of component. And for the moment, I register those painter classes with a single PaintManager class. So, for example, if I want to paint the factor arrays for a wave surfing drive, it would look something like this:

// the drive implements the interface

public class SomeWaveSurfDrive implements FactorArrayPaintable {
	...
}

// and in the main robot, where the drive is created...

	SomeWaveSurfDrive drive = new SomeWaveSurfDrive();
	PaintManager.addPainter(new FactorArrayPainter(drive));

Bug Exploits -- What's Fair, What's Not?

Thought I would share my thoughts on bug exploits, and see if anyone else cares to share their thoughts as well.

In my opinion, anything that attempts to exploit bugs or vulnerabilities in the Robocode engine itself is unfair, as it is not in line with the intent of Robocode. However, anything that attempts to exploit vulnerabilties in other robots is fair, and very much in line with the intent of Robocode.

The one case I see as debatable is whether or not it is fair to exploit bugs in other robots. I would categorize this in two flavors -- generic exploits, and targeted exploits. General being an across-the-board attempt to exploit a common bug, and targeted being based on recognizing individual robot names. I think both are fair and acceptable practice, as opponents are always welcome to update their robots to correct them.

Does anyone disagree with this assessment? What are your thoughts?

I agree that exploiting Robocode bugs is unfair and (even if we didn't police it) kinda stupid because they will be fixed eventually. I also agree it's fair to exploit flaws/bugs in other bots. Having bot-specific logic in your bot is definitely allowed in the RoboRumble - even pre-packaged data files. However, many of us (myself included) are not really into doing this ourselves, as we just don't find it as interesting, and doing so could hide the possibility of "real" improvements. (Eg, why improve your gun's learning speed if it can be pre-loaded with data offline?) That said, LittleBlackBook takes bot-specific logic to the extreme, and I find that bot very interesting! =) --Voidious 17:20, 27 June 2011 (UTC)

What brought this up is the x.x5 bug. I agree, it's more interesting not to have bot-specific logic. I like playing with bullet power, but I didn't want to lose ground against other top robots that take advantage of the x.x5 bug. My solution was to specifically target those robots I know to be vulnerable, allowing me to continue playing with bullet power however I want against other opponents. This type of targeted attack is the basis for my Red Eyed Monkey components, as I have been calling them. Generally, I haven't been using them, but this is a case where it made sense. The name coming from Toy Story 3, because it always makes me think of the monkey in the movie that watches the security cameras. -- Skotty 17:32, 27 June 2011 (UTC)

What I did in DrussGT was to do the bullet power choosing first, then round it to the nearest x.x5. --Skilgannon 13:33, 28 June 2011 (UTC)

In last versions of robocode enemy name can be hidden, so in long terms it's not very good idea to have special cases, based on enemy names --Jdev 06:18, 30 June 2011 (UTC)

Virtual Guns Equivalent To Virtual Hit Ratios?

I usually push myself to avoid looking at other's tactics, and come up with as much as possible on my own. I've seen "Virtual Guns" here and there around the wiki. I was thinking this is the same thing as my "Virtual Hit Ratios". With my virtual hit ratios, I have every gun provide it's aim for every time I can take a shot. I then record whether or not that aim would have hit the opponent after the wave passes the opponent. From that, I can track the "virtual hit ratios", and select which gun to use from those ratios. Is "Virtual Guns" the same thing?

Yep, "Virtual Guns" fire "virtual bullets" which can virtually hit or miss the opponent. Most hitratio's you see in the debugwindow when fighting an opponent are virtual hit ratio's. I do not even use the real hitratio, although I print it out at the end of each round. Mind though that the ratio's are not sacred, hitting with a real bullet can influence the behaviour of the opponent, hitting with a virtual bullet will not have influence. --GrubbmGait 07:58, 30 June 2011 (UTC)

I can't believe how long it has been since I was last active.

Life keeps me quite busy, but I still think about RoboCode from time to time. I'm tempted to come back for awhile and update RoboJogger (finally get it to a stable 1.0 version), and maybe even work on a robot (maybe take a new look at the missed turns issue XanderCat had in the first couple of rounds).

I hope everyone is doing well!

I'm honestly not too excited about trying to improve on XanderCat in 1:1 combat. Deminishing returns and all. I'm actually more interested in updating my robot framework to fully support melee combat, and then building my first real melee robot. Not sure if I will just expand XanderCat for this, or create a separate robot (maybe XanderClowder).

I did a quick review of XanderCat vs Spitfire. Spitfire is my bot that only does bullet shielding. If you do a compare of these two robots in the rumble, you can see that the bullet shielding implementation in XanderCat is still failing frequently. Spitfire outperforms XanderCat by wide margins on many robots vulnerable to bullet shielding. So while I was thinking of just doing melee work, I may also go back and see if I can fix this deficiency in XanderCat again, as doing so could make a significant impact on it's overall performance. There are two things I can do for this.

First, I may need to do another round of trying to cut some fat out of XanderCat to address the missed turns issue that was previously (and I assume still is) a bit issue related to this. First on the chopping block would probably be the scenario for ramming other opponents, which was just there for fun. I'm sure there are other places that can be improved as well.

Second, I may need to tweak XanderCat into sticking with the bullet shielding for longer before jumping to other modes. Possibly making it continue trying to bullet shield if the number of missed turns is enough to be interfering. There is a balance to be achieved there between improving against bullet shielding vulnerable opponents and degrading performance against opponents who are not vulnerable to bullet shielding. But based on comparisons, I think trying harder to bullet shield is probably the way to go, as XanderCat is some 20 to 30 APS points lower than Spitfire against quite a few opponents. That's pretty significant.

I find that it is convenient to treat my bot the same as enemies bot inside the code. I.e. each bot has full information on past and present battlefield situation. My bot would fire real bullets, enemies would make "virtual" decision on firing, which mine is dodging. That assumes that enemies using similar guns and strategies. So I might even have a rough guess at which opponent an enemy fires in melee (if they use same decision tactic) and dodge or not dodge such bullet.

One can even attemt to extend it, and predict which way the enemy would dodge in melee taking in account not only my bullets but other enemies too. But this is CPU expensive and leads to missed turns, so I do not use it. Though, I feel it can be done relatively fast.

In version 12.8 of XanderCat, I partially fixed my bullet shielding components that were being seriously hampered by skipped turns due to what we believe to be a garbage collection issue that occurs on some platforms for bots that produce a lot of garbage (yeah, XanderCat is a trashy bot). This partial fix now has me neck and neck with Gilgalad (up from 7th to roughly tied for 4th).

The skipped turns remains a problem, but the bullet shielding is working much better now regardless. Originally I thought the problem was due to the time loss, but the real culprit was with how the opponent waves were being generated. When XanderCat sees an energy drop from scan to the next in an opponent that cannot be explained by anything else, it logs it as the opponent firing a bullet and creates an opponent wave for the assumed bullet. This is fairly standard. However, what happens if your robot has missed scans in a time period when the opponent has fired a shot (in my case, due to skipped turns)?

XanderCat would just assume that the opponent bullet was fired on the previous tick. For example, assume you have a scan from time 40, then have skipped turns, then the next scan you get is from time 50. XanderCat would assume the bullet was fired at time 49, when it could have been fired at any time between ticks 41 and 49. This resulted in incorrect opponent waves often being created. This error doesn't affect other strategies all that much, but it does break bullet shielding quite badly.

My initial fix for XanderCat 12.8 is fairly simple. If the scans are not back to back, the wave is just flagged as "estimated". Any components that then rely on processing opponent waves can take that flag into account if needed. I just have my bullet shielding controller ignore "estimated" waves so that I do not attempt to shield those waves and don't count misses against those waves in whether or not to continue shielding.

A better solution, which I may consider, is to try to actually figure out what missed tick was the tick when the shot was actually fired, and then use that tick in the opponent wave creation. This could be done by analyzing opponent gun heat. Most bots will fire as soon as their gun heat reaches 0, so if you know when the previous shot was fired, you can figure out on which tick the next fired shot should have happened on. How much additional help might this be?

Now, most 1v1 bots don't have problems with missed scans or skipped turns, so concerning oneself with this issue may not be worth the trouble. But it's something interesting to think about.

Nice work and congrats!

It's hard to guess how much the gun heat tracking would help, but to me it seems to have potential for a decent gain and thus seems worth trying. Even if it just lets you shield one more wave once in a while, that can be a big APS difference when you're holding opponents to so few points (as I'm sure you've noticed =) ).

Nice improvement indeed. In my opinion, gun heat tracking and assuming they shot as soon as possible will gain you approx the same amount of APS you got with this update, say 0.25. Not enough to threaten #3 yet, but surely a noticable jump. I think that the "improved estimated wave" can safely be regarded as "true wave", but that is something for you to test and decide. Note that such an improved estimated wave not only helps your shielding, but also your regular surfing.

Good job, you finally pushed past my bot (and 2 others for that matter). I was wondering when that would happen. I might have to get back to work on that one robot I never finished and just stole the gun from instead.

Everyone -- I've been pretty busy with work and home stuff lately, and have had little time for Robocode. I left RoboJogger in a reasonably stable state, though not entirely finished. I will get back to it in time. If anyone wants to get a hold of me for any reason, since I'm not checking this site very often right now, make use of the "email this user" function (assuming that works?). I checked to make sure my email for the site is one I actually check regularly.

I look forward to getting back to Robocode and the Robocode community in time, but feel free to poke me from time to time if you haven't heard from me in awhile.

I think everyone that's been into Robocode long enough has had long hiatuses at times, so I didn't really think much of it. But definitely good to hear you're not permanently checked out. As far as I know the email feature works - I certainly get email notifications for page updates and stuff, and I have to think it all uses the same mechanism.

Hey everyone. I've been away, busy with other things in life. Just thought I'd ping the site and let everyone know I still think about and really appreciate the Robowiki/Robocode community. I might have a chance to do a little robot work again early next year. I was somewhat stuck with improving XanderCat any further, but there are plenty of other things I never got into that could be fun (like melee or teams). Best of luck, and see you out there...

Hey, good to hear. :-) I've also been working on other stuff. Things seem to go in waves around here. Will look forward to you triumphant return. ;)

Anyone played around with trying to use an AffineTransform when painting on the battle field? If I so much as make an exact clone of the existing AffineTransform associated with the Graphics2D object and set the clone as the transform, nothing gets painted to the battlefield. Not sure what is going on there. Maybe something weird Robocode is doing. Example:

public void onPaint(Graphics2D g) {
	AffineTransform clone = new AffineTransform(g.getTransform());
	g.setTransform(clone);
	// paint something here
}

This will result in nothing being painted. Remove setting the transform, and it paints fine.

I'm trying to figure out how to shift the paint position for a paint framework I am trying to write. The general idea in play here is developing a means for moving informational displays around on the screen. I can't get the AffineTransform to work. I also tried to cheat and use graphics from a BufferedImage, then draw the image onto the battle field, but Robocode doesn't allow the use of the drawImage methods.

I would appreciate any information anyone has on using AffineTransform in Robocode, or any other ideas on how I might accomplish what I am trying to do.

FYI: I worked around this problem by creating a proxy class for the Robocode Graphics2D object called WindowGraphics2D. The proxy class uses a subset of delegate methods to support many of the Graphics2D paint methods; in those methods, it manually shifts the text or shapes to the appropriate screen positions. To use a window, you extend the abstract WindowPainter class, which in turn allows painting through an abstract method with signature paintWindowComponent(WindowGraphics2D graphics, T paintable).

My alternate robots, currently named Fiona, Mikey, and SamAxe, are meant to demonstrate different gun ideas (they replace my obsolete robots Nissa, Simon, and Rowdy). However, on my first release, they were more competitive than I was expecting. In the latest versions I will be rolling out over a period of hours today (versions 1.2, 1.1, and 1.1 respectively), I have swapped out the drives in each for something simpler. The old versions had poorly segmented wave surfing drives, while the new versions have simple anti-linear drives. This should tone them down enough to not cause ripples in the ranks and hog top 100 spots, while still being good enough to show off their different gun skills. The only robot of mine I want making ripples in the ranks is XanderCat.