|
null trihedral mealtime quarries adventurers sportswriting Capricorn spunk cosines.McMillan?.[phentermine ] Lauren |
|
I apologise for being negative, but it seems to me that RC2 would lose the beauty of RC1, which is its simplicity. As soon as you add complexities like armouring, speed and bullet customisations, you move the game away from its basic simplicity in the direction of those complex computer games that have so many rules and parameters that the fundamentals, ie moving and shooting, get lost. 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 The more I think about it, the greater the task seems to me. I don't feel that building RC2 from scratch is worth it, considering the effort it will need. To be honest, I prefer you people coding bots and enhancing the competition, rather than coding the machine that will execute the bots. Maybe we should first: a) Try to get the RC1 source. Matt said he would try to release the code. b) Instead of building RC2, building additional functionalities (pe. team battles) outside robocode (a kind of roboleague). -- Albert Ssss! I was half way to get the large parts of the competition occupied by other things than coding robots! =) -- PEZ My $0.02 Canadian, for what it's worth: * This is a huge undertaking. Don't underestimate it. Define the API's, get the engine working, and worry about everything else (GUI, backwards compatibility, bells and whistles) later. * API: there are at least 3 to consider -- one for robot developers, one to allow the GUI to interface with the engine, and another to allow automated running of robocode tournaments. * I would simplify the robot developer API -- forget backwards compatibility for now. Drop the Robot/AdvancedRobot? distinction. One Robot class, with one method each to turn, move, fire, turn the gun, and turn the radar. One method to specify radians or degrees. A simplified API was on Mat's TODO list for RC2 anyhow... * KISS. -- Ray Vermette Now that Robocode is beeing finally opensourced, we should think what to do next. I guess the first step is to release FAST a new version that fixes the bugs detected so far, and probably packages RobocodeGLV014 with it. -- Albert 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? -- Sunnychan Yeah. Keep the API. It's totally awesome and deeper than one could ever had imagined at first sight. I'm only using the OneOnOne part of it and I am still learning. -- PEZ 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 * Why not may it a plugin to eclipse :-D -- jim * Because Eclipse is the root of all evil?? :) -- Brainfade ** Use your hate. Strike down your editor and your journey to the dark side shall be complete. -- jim *** Try Eclipse and you will not use anything else again! -- Sunnychan 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 What's exactly going to happen with the SecurityManager?? -- Jonathan This is the current order of things: # Display # 'Run' the bots # Update the battlefield If you exchange 2 with 3 bot debug graphics (like with RobocodeGL) will be in sync. -- Jonathan |
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
-- Albert
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?
-- Sunnychan
Yeah. Keep the API. It's totally awesome and deeper than one could ever had imagined at first sight. I'm only using the OneOnOne part of it and I am still learning. -- PEZ
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
What's exactly going to happen with the SecurityManager?? -- Jonathan
This is the current order of things:
![[Home]](/images/RoboWiki.png)