Difference between revisions of "PluggableRobot"

From Robowiki
Jump to navigation Jump to search
m (Added subpage link)
m (Normalized redirect)
Line 26: Line 26:
 
: Maybe some some persistence code.
 
: Maybe some some persistence code.
  
; Does it have any [[WhiteWhale|white whales]]?
+
; Does it have any [[White Whale|white whales]]?
 
: Since it doesn't fight on its own, no.
 
: Since it doesn't fight on its own, no.
  

Revision as of 18:21, 12 December 2007

PluggableRobot
Author(s) RobertWalker
Extends AdvancedRobot
Current Version 1.0
Code License RWLPCL

; Sub-pages:

/Source

Info

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?
Maybe some some persistence code.
Does it have any white whales?
Since it doesn't fight on its own, no.

Usage

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. (You can easily handle ScannedRobotEvent before DeathEvent if you like!) Listeners should not perform any blocking actions in their event handling methods; that's the job of components.
  • Components: Components are 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 the Hud object, which takes care of icky stuff that Graphics2D expects, like using doubles instead of ints, translating angles to degrees, etc.

Credits

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. Probably most significant for Pluggable robot is some of the discussion on the EventManagement page.