Talk:PluggableRobot

I think all the big bots use something like this? I mean Shadow does, my (bigger) bots do, who else? Mine in particular handles paint and robot color functions, and in Genesis tracks time, data and properties loading. It overlays it own methods for onScannedRobot, handles the radar and does many many other things I mostly forgot about, and it all does this with the data from a interface called 'Constants' (meaning colors, propertie file name, property names and numbers, etc. --Chase-san

It's not too surprising that the same people that enjoy programming for fun would also tend to build their bots with more modular designs, though some are certainly more "pluggable" than others. (Dookious is pretty clean code, IMO, but it would be easier to implement a new Wave-based gun than a new PatternMatching gun.) In addition to all the usual reasons for doing so (ie, in a profession), with Robocode it has the additional benefit of keeping me more motivated to work on my bots. PrairieWolf is a classic (one of the Ancients) that uses some kind of pluggable design for its MultiMode strategies. -- Voidious

Yeah, it does not surprise me that modularity would be a popular topic. Here's a bit more about how PluggableRobot works. Basically, PluggableRobot allows you to register Listeners, Components and Painters.

• I define a listener interface for each of the Robocode events, and any objects which implement the interfaces and register themselves with the bot will be notified of those events. The really nice thing is that PluggableRobot gives much better control over the order in which notifications are given; listeners are notified of events in the order that they are registered, and each listener gets the events in the order that the corresponding listener interfaces are declared. So a class with a declaration like

  public class MyClass implements EventListener.ScannedRobot, EventListener.Death

  will get notified of the ScannedRobotEvent *before* the DeathEvent. Pretty handy. All of this happens inside a custom event test as discussed on the EventManagement page. I don't actually make the robot do anything at this stage; this is just for data collection and processing.
• Components are where I actually make the robot do stuff. Each component has a go() method that gets executed in the main loop of the robot. Like the event listeners, they get called in the order that they were registered.
• Similarly, painters have a paint() method that gets called when it's time to paint debug graphics. In the onPaint() method on the robot I inject the Graphics2D object into a custom object I've created called the Hud, which takes care of icky stuff that Graphics2D expects, like downcasting (Is that a word?) from double to int, translating angles to degrees, etc.
• Pluggable robot also defines initializeBattle() and initializeRound() methods.

-- RobertWalker

---

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)