Difference between revisions of "PluggableRobot"
Jump to navigation
Jump to search
RobertWalker (talk | contribs) (Updated infobox) |
RobertWalker (talk | contribs) (PluggableRobot version 2.0 alpha has been released) |
||
| Line 4: | Line 4: | ||
| extends = [[AdvancedRobot]] | | extends = [[AdvancedRobot]] | ||
| released = September 21, 2007 | | released = September 21, 2007 | ||
| − | | current_version = | + | | current_version = 2.0 alpha |
| license = [[RWLPCL]] | | license = [[RWLPCL]] | ||
| − | | source_link = http:// | + | | source_link = http://robowiki.net/w/index.php?title=PluggableRobot/Source |
| isOpenSource = true | | isOpenSource = true | ||
}} | }} | ||
| Line 34: | Line 34: | ||
== Usage == | == 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. | 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:''' 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. | * '''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 | + | * '''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. |
== Credits == | == 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. | + | 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. |
[[Category:Bots|PluggableRobot]] | [[Category:Bots|PluggableRobot]] | ||
Revision as of 22:31, 24 May 2009
| PluggableRobot | |
| Author(s) | RobertWalker |
| Extends | AdvancedRobot |
| Released | September 21, 2007 |
| Current Version | 2.0 alpha |
| Code License | RWLPCL |
| 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. 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.
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. Most of the discussions useful to PluggableRobot have not yet been migrated from the old wiki, though.
