Talk:PluggableRobot

/Archive

Working on version 2.0

So I've been absent a long time, but I've been changing PluggableRobot some. Mainly because some changes to Robocode made it so PluggableRobot doesn't paint debug graphics anymore, and partly because I thought of some additional things I could do with it. When I'm finished, I'll update the source code on the wiki. RobertWalker 15:36, 4 May 2009 (UTC)

I'm very pleased to know how many Robocoders that isn't forgot robocode already. Hoping the robocode community will be as active as the past. May I asked you to merge the DrawingBot and User:Nfwu/Painter to the PluggableRobot? It seem far more effective that your Hud. And can make the ListenerDelegate class warning-free with generic under java5? » Nat | Talk » 15:43, 4 May 2009 (UTC)

Yeah, I was actually thinking about changing both of those things. I'm a little confused as to why exactly the ListenerDelegate is giving me the warnings; maybe you could enlighten me? Generics are awesome, but sometimes they give me migraines. I've tried various things to try to resolve it, but the warning either remains unchanged or I get a different one. As for the Hud class, I was planning on completely reworking that, but I didn't have any thoughts yet as to exactly how. I'll be sure to take a look at User:Nfwu/Painter and DrawingBot for ideas. Any other ideas for improvements while I'm at it? RobertWalker 15:23, 5 May 2009 (UTC)

I try to generic-ize you ListenerDelegate before, but I can't make it warningless. I have problem with some thing so if I generic-ize the Class<EventListener> and vice versa, I'll have an error in the processEvent() method so I revert to the non-generic version =( » Nat | Talk » 15:43, 5 May 2009 (UTC)

Well, the more I monkeyed around with it, the more I felt that generics were just making things unnecessarily complicated in this case. So I removed generics from the Invoker class, and changed it to have a consumesEvent(Event) method instead of an eventClass() method. This has cleared up all the warnings. The only bummer is that I lose some compile-time type checking, but the ListenerDelegate is built to ensure that the events get handed to the correct listeners in the first place, so I'm not terribly worried about it. Now to give it better painting support! RobertWalker 17:38, 8 May 2009 (UTC)

Wow! Thanks! I usually do @SuppressWarnings("unchecked") though. » Nat | Talk » 17:54, 8 May 2009 (UTC)

Yeah, I was considering that, but when I can, I prefer to solve warnings rather than ignore them. In any case, the code is easier to follow without the loads of generics stuff cluttering it up. Usually, generics make things simpler, but in this case.... Anyway, I'll post new source when I finish writing the other changes I'm working on. RobertWalker 02:33, 9 May 2009 (UTC)

I'm putting together the new debug graphics code. Like before, you register objects that are interested in drawing graphics with PluggableRobot, and they'll get invoked when it's time to paint. However, I'm also incorporating layering behavior similar to User:Nfwu/Painter. All debug code will be modularized for efficiency. For example, PluggableRobot will avoid wasting time on logic dealing with debug graphics if painting is disabled. It will also be easy to completely disable debugging code if you like before releasing your robot. (Although, if you release the source with it, it's also easy to turn it back on.)

Some other things I'm planning on for the new PluggableRobot revision:

• Some basic, optional components that could be used directly, extended, or used as example code for your own components. They would be things that a lot of robots would need anyway, like a data collection object or a 1-on-1 radar module.

• A tweaking framework that would allow you to declare properties for your robot, then run a separate application that would test a range of different values for those properties and report on the results in combat. For example, let's say your robot has a property that controls the preferred distance your robot wishes to maintain from the enemy, and you'd like to figure out what the best value for this property would be. You'd configure the tweaking framework to test a range of values for this property, and then it would run a bunch of battles, storing the results in an database. When it was done, you could then run a viewer that would display the results with fancy graphs and such.

I welcome your feedback. RobertWalker 15:30, 11 May 2009 (UTC)

Awesome! Actually I don't think it is easy to re-enabled it if you release the source code. =D

• I'd suggest you do release a plain version without it and release its extension which doing those thing. Anyway, I think that thing will be used by only your own =P
• I don't really get the point what you are going to do with that thing, really. Please explain more.

» Nat | Talk » 15:48, 11 May 2009 (UTC)

Okay, so when you're coding your bot, you will likely encounter places where you will create a constant. Let's say you need to set how many bins to use in your guess factor calculations. So you might write something like this:

private static final int BINS = 25;

But how do you know that 25 is a good number of bins? How do you figure out what the optimal number of bins is for your robot? This is where the tweaking framework comes in. I haven't fully coded it yet, but it would look something like this. First, you'd replace the hard-coded 25 with something like this:

private static final int BINS = Props.getInt("guessfactor.bins");

The Props class would statically load a properties file out of your data folder, which would contain a line like this:

guessfactor.bins=25

So now it's time to run the tweaker program. It would give you a list of the robots in your library, and you'd select the one you want to tweak from the list. It would then read the properties file and auto-detect the possible types of each (boolean, int, double or String). So you'd select "guessfactor.bins" out of the list and select int as its type. You'd then provide a range of values to test. You want to have an odd number of bins (so that a bin always falls directly at 0.0), so you configure it to test values between, say, 7 and 49, incrementing by 2. You'd then select what robots you want it to fight against and how many rounds to fight each bot.

Once you hit "Run", the program would back up your properties file, and write a new one with guessfactor.bins=7. It would then run battles between your bot and the others you selected, similar to RoboRumble, and store the results in memory. It would then increment guessfactor.bins to 9 and run the battles again, and continue in this way until it gets to 49.

Once it has finished, it will write a report of the results to a file, and restore the backed up properties file. You can open this file in a viewer that will show you a fancy chart of your bot's performance over the different values and show you which one did best.

What do you think? RobertWalker 18:43, 11 May 2009 (UTC)

I think it sounds great. I (like many others, I'm sure) have wished I had something like this many times before. The only other instance I know of someone really trying to do this was with AgentSmith (not migrated yet), but I don't think he had much success nor ever released his code. You might be able to pull some stuff from RoboResearch for automating the battles, by the way. Good luck! --Voidious 18:57, 11 May 2009 (UTC)

Great! I now understand. Hope I'll get it in .jar, not a brunch of .class files like RoboResearch :-) » Nat | Talk » 09:58, 12 May 2009 (UTC)

Hi. I'm using your PluggableRobot to make a new bot (my old one was ds.OoV4 and was horribly coded) and, as a not so familiar with java developer, I've had some trouble getting the debug graphics to work. So here is my solution in case someone is in the same situation. I added this in OnBeforeEventsProcessed() :

Vector<Event> events = getAllEvents();
for(Event event : events)
{
	if(!event.getClass().isAssignableFrom(PaintEvent.class))
		onPaint( getGraphics() );
}

I guess adding an interface for the OnPaint event in the ListenerDelegate and registering the main class as a listener would work too btw. Anyway keep up the good work you've got a fan ;) --f4 22:22, 11 May 2009 (UTC)

Thank you for your kind words. The debug graphics weren't working because of a change to Robocode. I'm working on improvements to PluggableRobot and I currently have graphics drawing again, though there are still some problems that I'm shaking out. Once I've got things settled down, I'll post the updated source. RobertWalker 02:32, 13 May 2009 (UTC)

Version 2.0 alpha released

I've just released version 2.0 alpha of PluggableRobot. There are some improvements to the Hud display code I want to make before I call it 2.0 final, but those changes are waiting on a couple of Robocode bug fixes to be released.

Also, I've decided to release the tweaking platform that I've been working on as a completely separate project from PluggableRobot. I didn't want to force people to extend PluggableRobot to get the benefits of the tweaking platform. Hopefully I can release an alpha version of the tweaking platform soon.

As always, I welcome your feedback and constructive criticism. --RobertWalker 21:37, 24 May 2009 (UTC)

Have you test it with 1.6.1.4, 1.6.0 or 1.5.4? Rumble client still use those version. I bet the painting this will fail with version older than 1.6.1 » Nat | Talk » 12:05, 25 May 2009 (UTC)