Of course RC1 can be improved on - bug fixes should be made (eg I wish it wouldn't crash on XP, it would be nice if cut and paste worked properly in the editor) and inconsistencies should be removed, features like debugging and a progressive scoreboard would be great. Having said this, I realise that no-one is going to put in the effort required to rebuild Robocode from scratch unless there are major functionality changes. There is no glory in fixing bugs and tidying things up.
The constraint of RC1 bots being "competitive" in RC2 is probably much more stringent than people realise. Even minor changes to how RC works can have a huge impact on how bots perform. Just as there are many ways of unintentionally making your bot weaker, there are equally many ways, and probably more, of making it weaker by changing the rules. So realistically I think that any bot author who aims for the top of the league will have to rework his (are there any females in Robocode?) bot so that it is optimised for the new rules, physics, scoring etc. In other words, I am against the compatibility requirement unless all the rules remain unchanged. --Tad
I totally agree. Leave the game rules and features as clean and beautiful as they already are. Jazz up the environment. Custom renderers, improved IDE, watch windows for debugging (single stepping would be a dream!), and so on. But this are just my preferences. The beauty of these kinds of projects is that they go wherever their contributors take it. Or they spawn off other projects where a particular design idea can be carried out. As long as RC2 contains a "Fully RC1 compatible" option, I'm happy. =) -- PEZ
I'm starting to think that you're right. In fact, if you look at the forums, you'll see I made the same argument for simplicity several times vs. people who wanted to add terrain, lasers, etc. However, you're very right about there being no glory in fixing things. I'm not interested in spending that much time if the only thing I'm going to do is enable team battles to be automated. The problem is that if I introduce a new set of rules which spawns off a whole new generation of bots, what happens to sites like the Eternal Rumble? The Robocode Repository? Robocode has so many sites, leagues, etc. running Robocode bots that a completely incompatible set of rules would have a hard time finding an audience I think - most people would just go with writing bots for Robocode. Kind of like the VHS vs. Betamax fiasco, if you're familiar with it. Betamax was technically better, but it disappeared anyway.I don't really have a good answer for this dilemma, but I'd welcome your thoughts. It's probably asking too much to try and add all kinds of new features to the game and expect JollyNinja to still put up a good fight. So what should I do?
-- David Alves
I don't think you can compare to Betamax. The big problem with Robocode is that it seems that there is no more development going in to it. That would be your projects big contribution. The open source model would ensure that there would be developer on the project for as long as there is interest from the audience. There would be plenty of glory in that I would say! If your Robocode is just like RC1 but with better automation and debugging features most Robocoders would switch is my guess. And new Robocoders would rather choose a living project than a dead. -- PEZ
There are a couple of features that I think would make Robocode better that would also break compatibility with all existing bots. The most obvious of these is better physics. Specically: Using bounding boxes that represent the shape of the robot, bouncing off of walls/other bots when there is a collision and having bullets inheirit the velocity of the bot. A version with these features would be better (IMHO) but would not be compatible, so that's why I'm using the Betamax/VHS comparison. --David Alves
Ssss! I was half way to get the large parts of the competition occupied by other things than coding robots! =) -- PEZ
-- Ray Vermette
I agree, a quick bugfix for R1 could be done quite quickly, and should be. We need to set up some kind of organised way to do everything. There is a sourceforge project set up, which we should probably use, and start discussing stuff over there. Mat says he is redesigning the website, so he might be intending to take a significant role himself, so we should wait and see what happens there, before making too many decisions. -- Tango
Perhaps more importantly, we need to try and find some way to have a final arbitor of what goes into the "official" code base. One of the reasons Linux is so successful is that although there are potentially millions of contributors, there is a very select group of people that have commit access or the ability to decide what goes into the finished product. -- jim
Yes, we need someone (or maybe a small commitee) who is(are) well known in the community, and knowledgeable enough for the job. Any volunteers/nominations? -- Tango
David -- Kuuran
Mat -- FnH
I have worked with current R1 source code and I think once we open sourced it we should refactor it so that the presentation layer is seperated from the robot fighting engine. Then we can expose the interface and let those Grapchics guru with better graphics while those hard core can work on the physics of the robots.
The R1 has not been work on for a while - maybe we should rewrite the engine, but sticking to the published API so exsiting robot should work?
I've told a few people this privately, but just so it's in the open - I'm likely to revamp the editor when the source is released. -- Kawigi
To make robocode into a Eclipse plugin should be easy - we just need to revamp the launching intereface so that you can launch from inside Eclipse -- Sunnychan
In Robot.java I found that R1 uses Math.toRadians(degrees) for set degrees methods, but radians * 180 / Math.PI for get degrees methods. Why not simply Math.toDegrees(radians)? (Robot.java is included in robocode.jar)
I also noticed that headings are minimized in getHeading(), but doesn't the battle manager already do that? -- Jonathan
This is the current order of things: