User talk:Rednaxela/BotBase
"Got no status event! Dying now! :(" -- I love this quote =) » Nat | Talk » 23:52, 8 August 2009 (UTC)
Haha, yes. That bit of code was from the rumble didn't check the version, but people used versions older than the recommended one anyway. I therefore used that to ensure my bot got 0 score on those clients, and thus had the bad result rejected by the rumble server. I should probably remove that hack since the rumble server now checks versions, AND doesn't ignore 0 results. --Rednaxela 00:17, 9 August 2009 (UTC)
Please update. My current robot base (framework) use a lot of design from yours. Thanks a lot for sharing anyway =P --Nat Pavasant 14:48, 2 February 2010 (UTC)
The current changes are fairly minor really. I think I'm going to re-engineer the framework a bit before I updating here actually. There are a few aspects I'm somewhat unsatisfied with. For one thing, I'm considering setting up a framework for bot components based around dependency injection (perhaps using picocontainer) --Rednaxela 15:10, 2 February 2010 (UTC)
Isn't Robocode blocked the use of Reflection which is the heart of PicoContainter? I'm not really sure it will work. But funny thing is that we need not to attach any dependency to a robot =) But from what I have read about DI, if one's codebase is not large and complicated, using no DI will result in smaller and easier to read code. And I consider Robots a very small codebase (compare to Robocode's 2,200,000 lines of code) --Nat Pavasant 15:52, 2 February 2010 (UTC)
I've not yet fully decided, and if unable to use PicoContainer for that reason I would consider writing an extremely lightweight purpose-built system that doesn't use reflection. I'm not yet sure, but I would consider a large bot meant for both melee, 1v1, and teams, to perhaps be large enough to be worth it. Particularly if I have multiple bots built in the same framework using different combination of components, then it could perhaps be especially be worth it. Really though, I'm not sure. I'm still evaluating whether it's worth it and may need to flesh out some quick before/after proof-of-concept code before deciding for certain. --Rednaxela 16:17, 2 February 2010 (UTC)
After further consideration, I think I'm going to use manual dependency injection (via constructors) more completely. I already kind of did actually, but not entirely consistently or completely. This means the framework will 1) be cleaned up a bit, and 2) will include various interfaces and abstract classes for common bot components, with consistent accommodations for manual dependency injection. I'm also thinking of replacing the passing of an event list, with making all of the bot components into event listeners, with one interface per event they could listen to, and the bot framework would automatically dispatch events to any bot components implementing the listening interface. Basically make the components similar to the new interface based bots in a way, but more granular so that individual bot components don't have to implement boilerplate empty methods. The reasoning is that I'm tired of the for/intanceof pattern in all the bot components, when they really just listen for one or two events. --Rednaxela 18:48, 2 February 2010 (UTC)
My framework which took base idea from you have all that, so it seems that the robot framework never escape single design =) --Nat Pavasant 22:52, 2 February 2010 (UTC)
I just took a look inside PallasHawk and indeed what you have there is somewhat similar to what I have in mind. :P --Rednaxela 23:27, 2 February 2010 (UTC)
- Well, PallasHawk is just a poor design. I have improved event delegater that delegate all events to one listener first, and then asecond and so on. I need ScannedRobotEvent delegated to the RobotManager before process the gun =) --Nat Pavasant 05:06, 3 February 2010 (UTC)
What do you mean by reflection being disabled Nat? I've successfully used "String.class.newInstance()" and "SomeInterface.class.getMethods()" in a test robot and Robocode 1.7.1.6 did not complain in the slightest. In addition to it working, I see no reason why Robocode would disallow reflection anyway, since Java's SecurityManager is designed to allow reflection to be secured and safe. --Rednaxela 03:15, 3 February 2010 (UTC)
Pavel has mentioned sometimes ago about it, but I haven't test it yet. --Nat Pavasant 05:06, 3 February 2010 (UTC)
Component System
After some thinking, I think I've decided to use a "whiteboard pattern"ish component system actually. Designed to allow effortless extension to support adding custom events to the event bus, and encourage very strong decoupling between components.
Any comments? :) --Rednaxela 23:44, 24 February 2010 (UTC)
I'm not really understand what is 'read only'-service or the design of event dispatch system, but it looks good to me [if you are talking about component system =)]. I have actually thought of this design before, but I choose what I have done in messy Pallas's framework (the Gun, Movement and Radar interface (or abstract class I don't remember)). Mainly because with my design allow easier creation of multi-mode robot, because by separation of main component system and event dispatching system it allow, for example in multi-mode robot, every gun/movement/radar registered get the event and process, and can perform immediately when chosen. And with my design it allow only single Gun/Movement/Radar component to act at any time, but if you use full component system in some case with wrong synchronisation you may have more than one Gun/Movement/Radar in the queue at the same time. I know it is confusing especially with my English, but hope you get my point. --Nat Pavasant 12:17, 25 February 2010 (UTC)
