|Released||September 21, 2007|
|Current Version||2.0 alpha|
- What's special about it?
- It's not a standalone robot, really, but a base robot which you can extend. It provides a pluggable architecture and sophisticated event management. I developed it in parallel with my robot that is based on it, RabidWombat.
- How competitive is it?
- That's up to you! You extend it to make it whatever you want it to be.
- How does it move? How does it fire? How does the melee strategy differ from one-on-one strategy? What does it save between rounds and matches?
- It's just an architecture upon which a robot can be built. Without extension, it's pretty much indistinguishable from SittingDuck.
- Where did you get the name?
- It's a robot design for a pluggable architecture. PluggableRobot made sense.
- Can I use your code?
- Sure, help yourself to the source code. I would like to be able to make this into a JAR that can just be dropped into another project, but Robocode doesn't seem to let you do this in development mode. :(
- What's next for your robot?
- Since the last time I touched Robocode, Java annotations have become a thing. So I'm currently overhaulting PluggableRobot so that event management is done through annotation-based registration instead of formal listener interfaces. This should vastly simplify things.
- Does it have any white whales?
- Since it doesn't fight on its own, no.
Extending PluggableRobot allows you to create reusable components to control the robot's behavior. There are three types of pluggable objects: listeners, components and painters. An object can be one or all three of these types.
- Listeners: Every Robocode event has a corresponding listener interface in PluggableRobot. Any object that wishes to be notified of an event needs only implement the corresponding interface and register itself with the bot by calling PluggableRobot.registerListener(). 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. Listeners should not perform any blocking actions in their event handling methods; that's the job of components.
- Components: Components are where the robot actually does stuff. Any object that wishes to have a chance to act in the execution loop should extend the Component class, implement the go() method, and register itself with the robot by calling PluggableRobot.registerComponent(). PluggableRobot will call go() on each component in the order they were registered, after all the events have been processed. This separation between listeners and components ensures that when it's time for the robot to act, it has all the intel available.
- Painters: Objects which implement Hud.Painter and register themselves via the PluggableRobot.registerPainter() method will have their paint() methods invoked when it's time to paint debug graphics. Painters will get a reference to a Canvas object, an object similar to Graphics2D, but with some convenience methods and which accepts doubles for many arguments where Graphics2D requires ints.
It wouldn't be totally accurate to say that PluggableRobot is an original creation. Though it's not directly based on any other bots, I've culled some ideas from the wiki. Most of the discussions useful to PluggableRobot have not yet been migrated from the old wiki, though.