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)