Yesterdy i talked with Kawigi about laid-back robocode competitions and i had the idea of a ExtendsTeamBasicRobotCompetition?. Its like a normal team, but with ExtendsRobot robots. I want to know if anyone else is intrested in such a competition and if anyone is willing to programm such a mod!
feel free to add your comments!
I'd be interested in participating in such a competition, but I don't think we need a mod to run it. What we do need is a mod to make running leagues easier. RoboLeague is nice, but counting victories based on total score isn't really fair. Kawigi, I'm thinking about your RobocodeLittleLeague program somehow tied into Robocode and the idea makes me happy. -- Alcatraz
If you have a team bot the robot is automatically a ExtendsAdvancedRobot? so you need a mod!
I think it would be nice, if something like RoboLeague could be directly implemented in Robocode, so that you could test your new robot versions easily. Maybe with different score systems.(I do not realy understand the actual score system -_-)--Krabb
Krabb's point is that you'd need a mod (or a new robot class to inherit from!) to make a robot that could do team communication but not use blocking calls.
Robocode's scoring system is fine, the problem Alcatraz is pointing out is using sums of scores over several battles for ranking, since some robots tend to just fight higher-scoring battles even if they lose (think FloodMini or VertiLeach), while others fight more conservatively or at a longer distance and tend to run lower-scoring battles. Since these lower-scoring fighters still may beat the suicidal close-range bots, it's not quite fair to base rankings on the total score accrued in several battles, which is what RoboLeague does by default.
A fine tournament format might be to just use average (or total) % score in all battles, maybe in combination with a MiniBotChallenge pairing engine (one that puts you against similarly-ranked robots each round). The MiniBotChallenge actually used total difference in score, which is at least more fair. The interesting thing about it is that over just a couple seasons, it sucked to be paired up against only other good bots after the first one, but after the 7 or 8 seasons that were run, if any bot poked up because of having only easy bots to battle against, they would quickly be put in their place in the next season ;-). I wonder if the MiniBotChallenge version of RoboLeague is sitting around still anywhere... -- Kawigi
I followed the Robocode community for a while and i am very glad that it actually went open-source. I like programming in java (nearly graduated)So i also got some experience with java. But what i like to do and i may need some very active members is to make some kind of "framework" for futher extensions, and setup an development enviroment etc... to support development by many users. But we have to beware for like 30 incompatible versions. So my preposale is. Develop with a few other ppl a framework for futher extensions and make some kind of development plan. Feature list etc... i already have so nice ideas like adding obstacles etc... to the field to make the game more dynamic. But this are only just ideas, and i need ppl to help. I am already building my knowledge of the robocode framework. maybe we could use this wiki for feature request etc... but my main point is that "we" need some kind of centralization. please feel free to contact me at gerben(dot)fds(at)gmail(dot)com, our add comment to this page.-- Retonator
Some kind of plugin framework would be cool. That way people could do something like go to to a "Plugins" menu, and enable or disable plugins on the fly from within robocode to mod they game to how they want it.
I would also love to see a proper graphical debug output that does not rely on something like GL4Java or somesuch. I have actualy modified my own version of Robocode so that it uses the normal Java2D api to draw graphical output on the battlefield. That, combined with Java 1.5 (5.0) with its OpenGL rendering pipeline gets me around 400-500 FPS while drawing debug output to the screen! Of course, I don't know of a fast solution to the problem with other versions of Java!
Along with drawing to the battlefield it would be nice to be able to draw to a seperate debug window so that for debug we could have real time graphs and such without obscuring the battlefield! --wolfman
That are some nice ideas wolfman, i think we also have to split up development in branches like drawing improvment, Utility feature, and simulation features, and maybe some "tournament" intergration like RoboRumble. But we really have to get some good discussions about it make plans and do it. Because i know from the past that ppl have 1001 ideas and that maybe 1 our 2 ideas get implemented. btw what did you changed to get robocode compiled against the 1.5 api jar because i get an ambigous constructor error in the Classloader.java i know it is because of the null there that java can't discide which constructor to use because there are actually two in java 1.5 (don't know if you know what i am talking about if not ask me and i will get the details). If we can get some motivated ppl to develop that would be verrry nice and some expercienced robocoders because they know what is missing, needs improvement. --Retonator
Change the error line to:
protectionDomain = new ProtectionDomain(new CodeSource(f.toURL(),(java.security.cert.Certificate)null),p);I have some proposed contributions that I sent to Mat Nelson this week that also include that ;-) I think the more experienced Robocoders, for one thing, don't want to see the battle engine significantly changed, but a mod API would be pretty cool. The challenge there is figuring out what it needs to include and how to allow it to work in Robocode. -- Kawigi
Thanx Kawigi i tryed to cast it with (Certificate) but i think it is missing an import then ;). Tonight i will write a Global Module loader for jar file's. Just found an intresting way to do it the first step i make is Building some Gui extension because that is quite static and nice to test with. I don't know much about the formal way, our if there is yet a centralized point for development. If the extension framework works(and i try to get as close to the robocode api as i can by using managers etc..).Then the next step will be to extended the "in-game" artwork, and after that maybe the battle-engine, and a way to pipe serveral extensions. But i want to make an extension framework because ppl can choose to stick to the old code. I also thought about a versioning system so that bots can specify which kind of extensions they need (if it concern's battle-engine features). But al of this is just in "think-about" stage at the moment im code a little extension system for fun.learning and testing i hope in the near future we can make some kind of team and ppl can help me :D i would like that. --Retonator
Dynamically loading the mods and making UI for it is the easy part (although it takes a pretty comprehensive understanding of Java, and will probably require a different security manager or something) - knowing what hooks the mods will need and where to put them is the hard part. -- Kawigi
Hey Kawigi to answers some of your questions, yes making UI is the easy part i already build something yesterday night but it isn't finsihed at all :D, i really like the way robocode is coded because all classes got nice getters and that makes hooking up to the "old" code very easy. I agree with you that define the hooks is the hard part hooking up in the code isn't actually, i thought to do it this way. ExtensionManager? contains a list or vector with plugins, it also contains an update() statement in which it get's all the battle engine plugins and update them, but i/we need to figure things out like threading and synchronization. But i really like to test etc... for fun and profit. --Retonator
I'm not sure how much we need to worry about synchronization really, but I'll trust you (if we allow the plugin to spawn its own threads, it can deal with anything it needs to be doing asynchronously). You're right about the getters at least in the UI code, but I haven't looked elsewhere much and we don't really need it for the UI so much ;-)
What needs to be considered is how to manage security settings (what kind of rights to we give them, or do we just give them what they want pending user approval?), and what Robocode things we give access to. Then we just need to load stuff (maybe have a directory with plugin jars or something?). As far as what a plugin is, I'd propose having something like a series of getters that are all options and run through a proxy class if they exist (if we can just hook into existing getters in Robocode, we can go to the plugin if such a method exists for that particular getter, or use the current value otherwise). If at all possible, we will save pain if we can have things only use/return primitives and built-in types. For now you should probably stick to some basic reflection in the same directory structure and an interface or abstract class to inherit from for a plugin just to get a proof of concept going, and I can help you with dynamic loading and such later if you get it to that point. -- Kawigi
I was thinking the same way Kawigi, considering security we can try to use the robocode.security classes. For loading i found some nice examples on the net in combyouination with xml which exposes the interface of the plugin. The only thing i am now think of is how to support dynamic user-difined function because they are not known @ compile time you could try something like
PluginGraphics plugin = new PluginGraphics();plugin.getFunctionByname("drawLine");our you have to create an interface from the xml to make some kind of proxy like COM does. Anyway i have now one basic class plugin, and three kinds of plugins derified from it PluginGraphic? PluginDialog? PluginBatlleEngine?, and some loader class to load jars. A version class to keep versioning. remind that it is only in desing fase im just trying didn't code much just some class with basic functionality. Maybe you can help me because i think it is an intresting idea.Iam currently at work so i can't do much now only little bt of thinking ;) maybe tonight i will code some things. btw i little bit of ripped the modular idea from Click --Retonator
That's what I was basically talking about. In some ways, it's easier than it sounds, but when you get into it, getting it to work properly is harder than it looks (particularly if you have non-built-in objects being passed around, which is why I mention it). -- Kawigi
Hey Kawigi i think i will drop the plugin(not complete i think i will still make an extension module to load and unload extensions.) idea because the orignal robocode isn't designed around a modular design, the security model is very tight so loading classes etc... from the outside calls the needed for a new classloader securitymanager etc... so i think we most stick to plain feature adding in the code it self, maybe add some well known things to it to extend te platform (RR@H, RobocodeGL(don't know if the author is busy with it, and the analyses tool you made i thought.)in this way i think development and extension will be much faster and more secure but we need a well definend feature list and a plan what to include in which release, because if 10 different ppl start adding 10different implementation of some feature it will be a mess. So i would still ask for some way of centralization maybe make a list of plans and releases,we have to keep the robocode alive and kicking --Retonator
On a related note, I just got an email reply from Mat about my UI changes for Robocode - he said that he doesn't really have spare time at the moment to review and try out my changes, and said it might be best to start my own derivative project or use David Alves's Robocode2 project to publish it. I'd, of course, rather have it in the official release, and the problem I see is that if he doesn't have any other trusted developers working with him, he won't have time to review people's changes so they can go into the build, but if he doesn't take time to review people's changes, then he won't gain any trusted developers to help him (vicious cycle, eh?). Anyways, agreed that we need some organization, and a gateway into *some* kind of official build. Meanwhile, I have a modified robocode.jar with all my UI and editor enhancements, if people want to try it out, I can upload it somewhere :-) Maybe if enough people test it (particularly the new editor features), we can at least convince Mat that he only has to code review it. -- Kawigi
Well, upload it! -- Alcatraz