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 (UT
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)
A 'read only'-service means some interface that a component provides, which either gets data or calculates something. One could have one for 'list all enemies', 'get enemy by name', 'predict where the enemy is going to move', 'find out the day of the week', or countless other things. Then the event bus is used for countless things besides the standard Robocode events, such as wave endings, the enemy firing, or an intended path of travel being determined. Really this is just an underlying layer for a component system which is not specific to Robocoding, meant to encourage highly decoupled components. The issue I have with a system more like what you talk of, is that it encourages strong coupling, by how it encourages putting the 'enemy predictor' and 'list of waves from self' inside the 'gun', and so on in a very hierarchical manner. That is quite inflexible in many ways and leads to problems.
This type of component system encourages one to instead make things like the 'enemy predictor' a separate component which listens for events (like WaveEnd type events) to gain information on the enemy, and provides a 'service' to predict the enemy. Or the 'list of waves from self', would listen for 'I fired a bullet' events and broadcast 'wave started' and 'wave ended' events, and probably also provide a 'service' to get a list of the active waves. To do a 'multi-mode' gun bot, instead of having multiple 'Gun' instances, one should probably do something like have a 'predict enemy service' implementation that delegates to one of multiple other ones depending on the mode.
Outside the context of Robocode, this type of component/service/event oriented architecture also has advantages in that it allows things like distributing components across multiple threads or computers (if one follows the good practice of making the necessary data serializable) in a very finely grained way, with only changes to the container around the components, not the components themselves. --Rednaxela 16:37, 25 February 2010 (UTC)
- Just a note, even my design provide strong coupling between component in each Gun/Radar/Movement (the Operator), it still provide loosely coupling between each Operator, which I feel, for Robocode, the only need of loose coupling. Outside of Robocode, I wouldn't do this anyway. --Nat Pavasant 01:34, 26 February 2010 (UTC)
Also, anyone else have any other thoughts on this type of architecture? I'd be interested to hear it. I'm currently debating whether to change things to allow multiple implementations of a 'service' at the top level with a way to select between them, or whether it's better to require duplicate service implementations to go through a 'multiplexing' implementation. Any other suggestions for how to set this up, or comments on how people would want to use a bot architecture based on this would also be valuable. --Rednaxela 17:46, 25 February 2010 (UTC)
License?
Hi Red, you probably have noticed a change in my user page indicated that my robot framework is completed. Well, at first I designed it from scratch, with somewhat-complicated event system and so on. Then I abandoned it, for it was too complicated, and rewrote my framework base on your (the same fate as my php framework really). I want to release it under The MIT License (except your kd-tree, which is included in the framework, but under zlib license). Now I have two question.
- Which license your BotBase is under? Am I allowed to release my framework which contains your code under The MIT License?
- Can I put your name (Alexander Schultz, right?) as the 'original' author?
Thanks =) --Nat Pavasant 12:30, 5 May 2010 (UTC)
Sure to both questions :) --Rednaxela 15:26, 9 May 2010 (UTC)
