The new RobocodeNG project began at the [Open Discussion] at the Robocode site at SourceForge?. It seems like the development with Robocode has somewhat stopped or gone into it's stagnation phase. At least, there have not been any major changes in Robocode regarding introduction of new features for a long period. In addition, David Alves has also stopped working on Robocode2 (which is a shame). So this was also a dead end.
Our intention with Robocode is simple:
We think it is vital to add new features to the game in order to ensure that the game is still attractive, especially to veteran Robocoders. We know that you guys have a lot of great ideas for how to evolve Robocode, and we are more than happy to receive [Feature Requests] and of course [Bug Reports] from you. In fact it's quite vital that you guys support us, as our motivation for continuing RobocodeNG is that people have a lot of fun with playing Robocode and wants it to evolve.
Interesting, keep us posted. Strange that the current project doesn't allow (?) more developers than Mathew. -- Pulsar
Sounds pretty cool, I would love to know what kind of changes you have in mind. One thing that I have always been interested in is a 3D robocode. It would add alot of new dimensions to the game, although it wouldnt allow for the continuation of existing bots... Anyways, sounds good, and let us know what goes. -- Jokester
We will try to put new features in the game so the robots gain new abilities. For example, this could be a shield feature, which means the robot gets lesser damage when it's hit, but it cannot fire while the shield is up. Such a change is possible to add without breaking compability with old robots. Regarding the 3D feature, this will for sure be considered at least for the visualization part. We are thinking of making it possible to have various kinds of visual renders on top of the core engine of Robocode. But please, summit all your ideas at [Feature Requests], so we can gather all the ideas and wiches for the next generation of Robocode. At first we intent to concentrate upon making the existing game better, but who knows, we might do a Robocode II as well. :-) -- Fnl
You should definitely take a look at my stuff on OpenSourceRobocode/Contributions - several people around here are already using that version. Also, if either you or John uses instant messengers, you should get in contact with me (we have an InstantMessenger page as well). -- Kawigi
I will for sure have a look into your code, and thanks for notifying me about it. I will keep in contact with you. :-) -- Fnl
Actually, the [todo list] was one of my personal reasons for getting involved with continuing Robocode. ;-) In this TODO list there are a lot of cool ideas, and I should like to have as many of these features added that are feasible without breaking compatibility with legacy robots. -- Fnl
Hmm, one idea. To add some more features to it, you could have a LegacyBot? that they can extend (or have new bots extend something else). And then you can provide NewBots? with an additional bonus to counteract other aspects. For instance, in order to introduce some of the more complex physics and 3D ish aspects (firing requiring a distance...) it would throw off the old bots, but to have bots with new physics competing against the old, the old bots would be at an advantage. So what you could do is have the newBots start with like 150 energy and the other aspects. That way at the beginning of development the old bots would still be on par or at a slight advantage, but as people come up with greater techniques for the new bots they will have a decided advantage and more bots will use this new platform. I make this reccomendation because, while we want to still use the old bots, making everything backwards compatible greatly reduces the scope of this project and it would be far more difficult to make a bot competitive with current bots when they are at such a great advantage. -- Jokester
fire() will require a distance, where bullet will detonate for radius damageThis is probably the coolest idea I've seen. But this in fact would break those current bots and change the game too much. So I would propose to do that as a CLEAR and SHORT set of weapons:
BTW - the Edit Conflict prevention is also way cool =) --lRem
On the second thought - RobocodeNG should be 100% compatible with Robocode robots. So the homing missile is not a good idea - it would make the oldies die. The same about obstacles and so. Even the howitzer could make WaveSurfers confused about the angle they were fired at. So my suggestion is to split efforts into 2 projects - Robocode2 and RobocodeNG. Robocode2 would be for implementing all the new features, while RobocodeNG would include only those features, that don't break any bots. --lRem
The ranged weapon was to be the basis for Robocode2 that Mathew Nelson was planning. I would love to experiment with it, I believe it would mean the end of the GF era and the start of the PM era, true 2D targeting. -- ABC
The first truly effective learning gun was a PatternMatching gun. But ever since Paul Evans described his GF gun, the top spot has been reserved for the one who optimises it best. The longest reigning Robocode king ever was his own SandboxDT, and was only dethroned when I turned his idea against him ;). My gun is, in many ways, an "evolution" of PatternMatching, no GF's used, and there are few GF guns that beat it (specially in the TC-fast), I just wish I could unleash it's true 2D power... -- ABC
But making GF work with distance shouldn't be that hard. You just stofe GFs for advancing movement, not only for lateral. No real magic included, should work as well as works now. --lRem
But the advantage of simplifying statistics by reducing the data to 1D would be lost. You can't do separate lateral and advancing statistics and shoot at the most probable of each of them because they are interdependent. -- ABC
Ah, now your getting into what Ive been doing. Theres a few tricks to set this one up, one is that I keep track of the 2D sections for my GuessFactors, . I also have a system that fires at the angle that hits the most GuessFields?. Now this definitely kills the simplicism of GuessFactors, but given advanced segmentation it can get PatternMatcher esque hitrates on alot of simpler bots. -- Jokester
Not independent, another dimension I'd say. But that would require a lot of bin smoothing, and maybe some other smart things that I don't know of. But yes, pattern matchers could regain ground for some time before people would get GFs work right again.
Another argument against leaving only the ranged gun would be that rammers would become really powerfull. As for now they're easiest targets and still can cause problems. When they become able to ram without narrowing the escape area... Or imagine that by yourself. --lRem
@Jokester: I'm sure it does. From what I've read, your approach is similar to mine. Ever watched Shadow in a sample bot melee? ;). But when you start using guessFactors you lose some of the PM-like performance, since you assume the enemy will "scale" it's movement pattern acording to the distance from you. That is another characteristic of GF guns, after simplifying the data to 1D (guessAngles) it goes even further and simplifies is to scalable factors (% of the max escape angle). It loses PM-like accuracy but gains in random movement tendecy detection. And the majority of the bots in the Rumble use distance scaled random movement.
@lRem: The escape area would still be narrowed by close range fighting, the bullets would still have a shorter flight time...
@Jokester: Your idea with the LegacyBot? and NewBot?, and also giving 150 to new bots in Robocode NG is a good idea, and we will definitely consider it in Robocode NG. Actually, we are already considering an idea where all new bot types has e.g. 200 energy point, must slower movement, less firepower etc. compared to old bots. But with the new bots you are able to spend energy points on new abilities, e.g. you "buy" more speed for 77 energy points, and will then be down to "only" 123 energy points before the battle starts. However, it should not be possible to adjust the abilities when the game is started. Also, it should be possible to buy for 100 energy points in total so you will have exactly the same abilities as legacy bots. This way is still compatible with the old Robocode. However, it will have impact on hardcoded fixed values in old bots as e.g. maximum speed, escape angle etc. Another thing we consider is to let the gfx of the bot change with the abilities you buy. For example, if you buy a more firepower, the gun will look thicker, less firepower and it will look thinner. :-) -- Fnl
@everybody: Thanks for all your input regarding ideas for Robocode NG. We are now going into the design & review phase, where we try to combine all ideas into one solution that does not break Robocode compability. At least, not too much! :-) -- Fnl
Great initiative this one of evolving Robocode! My opinion: It's good to make RobocodeNG backwards compatible with Robocode, but don't even try to design it so old bots have a competitive edge (even give them any chance). Robocode as it is has reached its maximum. It was more than a year ago that the las truly new idea came (ie. WaveSurfing) and now its all tweaking and optimizing... really boring. Put new ideas into RobocodeNG, so people can put new ideas on their bots. It will (may be) spark interest in new people that now is just afaid of never catching up (Robocode as it is has reached such a level of sofistication that it can take a lot of time to develop a decent bot for a newcomer). -- Albert
I agree with Albert, if we design RobocodeNG to give old robot advantage to fight in competitions, you'v seen, it is hard to add new features, if i keep tweaking my old bot and then i can get a high rank in rumbles, it must be boring. So my hoping is that, design new cool features, keep old robot runnable, but may not with advantages. -- iiley
And if you're about to hack Robocode, I have a request. As I've finaly failed to install RobocodeGL (gl4java to be specific) on my box, it would be great if you do add graphical debugging over the standard renderer. Just a wish... --lRem
First off, I heartily agree with lRem, a graphical debugger is a big must. Also, from my point of view, I think that adding features should be more important than keeping it old bot safe. There are alot of things that just cant work with old bots, but that I know many people want to see (realistic physics, obstacles, different guns). I think its more important to make those additions than to be able to use the old bots. I am a big fan of this upgrade system (although i feel it needs to be really well balanced), but I think that people who want to keep the old robots will be able to use the old robocode, while people who are still coding can start with the new system. I dont think it will be losing all that much to not keep legacy bots, considering what wed lose if we did. -- Jokester
I think, that this should be done in a way that allows old bots remain competitive. This is my list of ideas how to do this:
Hope most people agree with my sugestions ;) --lRem
Mmm, I feel that that would be a good way to deal with most of the issues. One thing that I question would be realistic physics. I guess that it could be toggleable or maybe on a bot by bot basis, but I think its something that would be really cool to have but which legacy bots could not deal with. If you have it on, it messes with legacies, but if its totally off then the new bots will be making wrong calculations... -- Jokester
Keep up giving all those cool ideas and comments. They are highly appreciated. You guys might be right that we should concentrate on new features rather than keeping everything completely compatible with old bots, which might not be possible after all. I should also like to remind you that we should like to have your feature request put on our forum at [Feature Requests]. However, this does not mean that we'll not collect all the ideas and comments from this site. ;-) -- Fnl
Hi everybody, this is my first entry in this page (what a shame!, i'm the project administrator and didn't do it for a long time :'-( ). Thanks everybody for the massive feddback. We're working hard on getting an excelent Mod system to give you all the pleasure to play with new kinds of robots and guns. All sugesstions are really apreciated and will be considered/reviewed. Our main goal to this is challenge robocoders' creativity and push the limit a bit further ;-) We'll have a page with a sinopsys of the suggestions made until now at Robocode NG's [home page] (watch out, spoilers everywhere ;-D ). Any other comment, please use this Wiki or any other form of contact you feel comfortable with. --John Villar
Hello! I'm Asc, supposed to be the graphic editor. So I'm working on some ideas, new weapons, turrets(diffrent kind), and base tank (like holitzer and spike). I'm posting my prototype (even if they are not at the level yet) in an assigned page on my university here: [spoiler!], and some are being upload in the homepage right now -- AscJr
I have one request, don't make it compatible with the current version of roborumble@home so the stats don't get screwed up there by accident. In fact to make sure noone accidently runs battles with new guns etc perhaps we/you should make sure it is incompatible? Meaning the internal robocode api should be (however slightly) different for example. Swapping robocode.jar for robocodeng.jar (?) shouldn't be possible in a rr@h environment. Keep up the nice work! -- Pulsar
Although speaking of that, it would be very cool to include roboleague and the RR@H client within RobocodeNG, so that rather than having seperate applications for Robocode, it will all be combined together (like options being, new battle, load battle, new league, load league, Operate RR). I think there might be some more people running these things if it was directly incorporated into the program. -- Jokester
Oh yes definately, I could contribute to such a thing in RobocodeNG but I will only commit to spec/design parts for such a thing at this time if so :) Simply not enough time. Maybe I can get some time to get the rr@h screen saver project started too. -- Pulsar
Sounds good, however, we would have to modify rr@h to specify what version of robocode the ranking belongs to. -- John Villar
Funny you should ask, right after the similarly-named RobocodeSG page came up - Fnl is actually also working on a grahpical debugging addition to RobocodeNG. John Villar is getting about done with the beginning of his bot-type mod system, and it's in the process of being merged. Fnl has also updated all the sources to have better formatting, and, of course, my UI changes have been added. Also, browser.bat has been fixed ;-) (and I think -Dsun.io.useCanonCaches=false MIGHT have been added to robocode.bat). -- Kawigi
Hi everyone, it's me John Villar, we've finally implemented a mod system that is expandable and very useable, i hope everyone out there will be happy to play with it. Currently there are a few mods that do some nice tricks (like heating an enemy or making your tank bigger) and we're open to everyone's ideas. Visit the [Homepage] to look at the [Robopaedia], it has partial information on what's been done recently. It resembles a bit (not in the graphical aspect, for now :-D) the X-Com Ufopaedia, so players familiar with this style will be happy with this new resource. Coming soon (or not so soon) is the following: Non tiled background, scrollable view (instead of scaling, matthew wanted to do this as i've read in the code), real-time scoring system, new mods for team players, an strategic mode where players will be able to put their bots in any place they want in their play zone, GRAPHICAL DEBUGGING!! (we have some of it in place by now, altough the method implemented is a bit harder to use than SG because we want to expand later to support different kind of views) and a new addition that will add up some spice to the mod users (something like the action points on fallout tactics, only that this will be better :-D). Regarding the evil bugs: i'm aware of MANY bugs currently in the code, and it should be considered a very early alpha release, just to get an impression of what is the current state of Robocode NG, for example, the new bullets trash a lot the battle view, and it happens when you start a new battle (not a new round) that sometimes it hangs up when loading the bot's images, it is a problem with thread handling, something i'm not very expert with, however, the graphics handling part will change soon, so don't hold your breath with the current state (i want to add something called Shaders :-D just to implement the beloved Railgun everyone wants and two more weapons i won't tell you! X-P). Any questions can be directed to kawigi.... joking... anyone of us are open to questions, ideas, rants, love/hate letters and of course contributions (code and tests, for now we aren't accepting shineys as a project). Thanks everyone for your attention and reading this long... -- John Villar
The Robopaedia looks very good. I'm getting excited. -- Alcatraz
Hi, there are two little updates, the first one is on the robopaedia, i've just uploaded the new contents (the specifics of all the bodies and most guns) and a guide that explains how to use mods (however, it is quite simple). The other update is that Fnl has put in our site (not as an sf.net download) the RobocodeNG setup jar, it is [here]. Check it out and give comments!!! -- John Villar
The "unofficial" files on on our site is a kind of integration test, but not the real thing yet. As soon as everything runs correctly a real release will be shipped on our site and you will be the first ones to know! ;-) -- Fnl
BTW, something NOT in the robopaedia nor in Mods, enjoy yourselves :-D -- John Villar
StefW: I will be very happy to include your stuff into RobocodeNG. As Kawigi already mentioned, I am working on exactly the same feature. However my method was called debugPaint() and not onPaint(). But I think I'll change that. In my version you will be able to control which bots you want to see the painting. In addition, I am transforming the coordinate system so that the Robot developer does not need to do this in his/her onPaint() method. That is, the coordinates fits nicely to the coordinate system of Robocode. I will soon get into contact with you in order to align this feature! :-) -- Fnl
How about guided missiles (or similar violent objects) with a custom guidance object? There should be enough control to increase hit rate, but it should be possible to evade. -- Jonathan
That's one of the ideas we have... look at the previous sets of two images, those two missiles attached at each side of the turret are missiles (however, they would acquire their "heat seeking" capabilities or any other behavior according to a Strategy class that implements the movement, much like that of a robot). Probably there will be a way to access Mod's specifics (i.e. the shield will be "like" a gun, but won't be the main gun, much like the Battery SAM and the Tractor Beam). However, this will need the inclusion of a concept i call Power Generators (they are a similar concept to the Action Points on Fallout Tactics in realtime mode, only better) to balance everything. BTW, here's a poll
What should we strive for:
Put your comments with the number you vote prepending them.
-- John Villar
I saw the images, but I wasn't sure how they would be guided (didn't look at the file name).
How about being able to write code for missiles. You could have a custom missile that you could make home or what have you, and that would cost energy proportional to codesize. -- Jokester
Speaking of proportional to codesize, will there be a way built in way to get the codesize of a bot for use in modding, etc.? In regards to the poll, I'd say 1 and 4 are the most important. -- Alcatraz
That is one good idea!! however, if that imposes a restriction on running the game somewhere it probably won't be included in the game... BTW, Fnl has become a father for second time!!! Congratulate him!!! -- John Villar
Some buttons, so that you can communicate with your robot would be a good debugging feature!
That's one idea that i think would be very interesting, it could lead to some other kinds of gameplays, i'm thinking that it also would be interesting to enable bots to receive mouse clicks on the battlefield :-D or even the cursor position 8-D. Btw, i've implemented three new mods: FlameThrower?, Railgun and Sonic. Those are, as you can guess, a weapon that send heating flames, the famous railgun with a BIG delay to fire and maybe too much heating, but an incredible firepower and the Sonic Wave, that resembles a bit the Railgun in the fact that it isn't stopped by hitting a bot and does humongous amounts of damage, however, it is a slow bullet and will do some other effect in the near future. In the [screenshots] there is a new shot whit flame, railgun and sonic working in the same battlefield (however, sonic isn't very notable because it is an effect that looks very well on action, like the sonic wave on dune 2). I'm giving all this to Fnl to enable him to integrate it to the main CVS Head and do a file release pretty soon.... we're moving a lot to get our first release, however, it has been delayed a bit because Flemming (fnl) has become a father for second time and he's attending his wife and baby girl these days. -- John Villar
Hi everyone, there hasn't been much activity with Robocode NG recently because we've been a little occupied with this and that. However, there's an almost beta release (we have classified it as an alpha stage integration test) on the (non-official) [files] repository. There are setup and code packages, so you can download both and play a little with it. Main changes are: a little debugging on the graphics area (it was eating memory like hell) and stability tweaks. It has currently implemented the weapons mentioned in the previous paragraph, however, they are being drawed incorrectly (when i posted the availability of those mods, they weren't being drawed at all). CVS is very up to date!! check it out too!!! Also, there's a feature i have been playing recently that will be a debugger's favorite :-D -- John Villar
I tried CVS but it doesn't compile, because it tries to use some nonexistant classes like robocode.battlefield.Drawable? -- Jonathan
Those files you downloaded aren't the cutting edge, so please, be patient... soon we will update everything to have the latest changes. Also, use the [robopaedia] to understand the underlying Mod system. Btw, i would like to know your impressions about the snapshot you downloaded -- John Villar
I noticed. It's indeed eating tons of memory. I haven't tested it much yet. -- Jonathan
Yep, it is a version that ate lots of memory... the files have been updated since you downloaded that archive, update yourself :D -- John Villar
Yay, it's using regex stuff not available in 1.4.2 (still using that on this Mac, and last I checked the checksum of Apple's 1.5/5.0 was incorrect. Appears to be OK now, I'll give it a try). -- Jonathan
I have just updated the alpha files and CVS again, and now some of the stability issues are gone! Yes, the CVS was not updated correctly some days ago, but now it's totally up-to-date. -- Fnl
Yes jonathan, regex stuff eases a lot the coding.... and it is very fast... btw, the alpha files have a little bug that is already solved but the fix isn't on CVS :( -- John Villar
I have just downloaded the alpha files and I could not resist trying the mods on my bot. I found that using the shotgun and the gun cooling mods at the same time to be quite effective, but it slows down the game a lot.
@Jonathan 1.5 works fine on Mac now.--Florent
@Jonathan and Florent: Is everything installed correctly on Mac with the recent alpha-files? If not, let me know. --Fnl
I downloaded and installed everything on my xp machine and it works great. I did have to add robocode.jar to the new robocodeng directory. Then I ran a battle with a whole bunch of Crazy's and it looked great. So many flames everywhere! However, the flames don't seem to do any damage, and the flame thrower is on the side of the bot. Also the big gun didn't appear on TrackFire. All in all though, I'm getting very excited. Hopefully we can get an NG competition going soon. --Alcatraz
Oh, never mind, I see how the flame thrower works. I still think it looks awkward on the side of the bot. Other comments. The standard gun does not appear, and occasionally there are problems redrawing the screen. -- Alcatraz
@Fnl the installation on Mac worked fine, but all the mods does not appear on the screen (e.g. the shotgun is not there) and the armor appears on the side of the bot. I had to remove -Xmx256M to launch RobocodeNG otherwise there was a memory problem when launching. The memory problem also appears sometimes during the game. --Florent
@Alcatraz Yep, you can help out tracking bugs!!! also, ideas are greatly welcomed!! -- John Villar
@Alcatraz With the recent alpha files the gun is not painted beside the body anymore. We should love to get feedback from you and the rest of you as well. You are also wellcome to give [feature requests] on our [official site]. :-) -- Fnl
@Florent Previously we got some SecutityExceptions? that caused the images not to appeas on the screen. This should be fixed with the recent alpha files. John Villar and I should like to hear if you still have memory problems with the newest alpha files? How much memory do you have available on your Mac? Have you tried to increase the mount of memory needed for the game by using e.g. "-Xmx384M"? -- Fnl
@DanielF? The short term roadmap is make a file release that is not a BETA anymore. Currently, there are a lot of bugs in the BETA 2 release that we are working on removing. E.g. the robots are not painted correcly yet with our new rendering system, and there are some other issues with the new robot types regarding behavior.
We do not have a long term roadmap yet, but should like to get surgestions from you guys on how to proceed. Otherwise we'll take as many good ideas from the TODO list from the classic Robocode and put them into RobocodeNG. One thing we are discussing right now is to make it possible to change the entire rendering engine. This way it can be "easily" modified to render SVG, 3D or whatever, and people will be able to do their own rendering engine. Of course we also need to balance the new types of Robots in RobocodeNG (notice that you can make new Robot types (Mods) for RobocodeNG yourself already). As a last thing we want to put networking support into RobocodeNG and should of course also like to have sound! :-D
But you're right, we should have a road map for RobocodeNG. We'll make one when the development for Robocode 0.7 has finnished and has been released (not BETA!).
So please everybody, make your [Feature Requests] on our official SourceForge? site if you have a good idea or desperately want a specific feature in RobocodeNG! :-) -- Fnl
I keep getting an error that says "Could not find main class file. Program will exit", when I run the setup JAR. WHY!?!?! --Bayen
@Bayen: Normally you get this error when Java cannot locate the main() method in the class specified by the manifest file of the JAR archive. Perhaps you are using an older Java version. You should use Java 1.5.0 as minimum. Have you downloaded the BETA3 version of downloaded the file from http://robocodeng.sourceforge.net/files/? -- Fnl
For those of us with Mac OS X versions prior to 10.4 (I have 10.3), which don't allow Java 1.5, can you make the program compatible with Java 1.4? If it's not possible, don't worry about it, but otherwise it would be a nice gesture. -- Greywhind
@Greywhind: It is possible to go back to Java 1.4. However, we'll have to reintroduce a lot of wrapper classes that have been removed because of Java 1.5's new Generics facility. In addition, we are using Java 1.5 classes and methods that we'll have to "reinvent" for RobocodeNG. Java 1.5 has come to stay and sooner or later we'll see Java 1.6. We wanted the new generation of Java to follow the trend, and also make it easier to develop and maintain RobocodeNG. I am wondering, isn't it possible to change the Java Runtime Environment in Mac OS X 10.3 to Java 1.5 somehow? What do the rest of the you guys want? Do you prefer the ageing Java 1.4 or newer Java 1.5, because we could go back to Java 1.4 if most of you want this. -- Fnl
I appreciate your willingness to change the code - but I believe the -target 1.4 switch on the javac compiler (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/javac.html - see the section on cross compilation.), and comparable switches using other compilers, should be able to quickly fix the problem without any code modification. I would take a look at those before changing any code. -- Greywhind
I got RoboCodeNG? to download after I updated my JAVA and created UbaNG?! It is exactly the same as regular Uba except it has a Shotgun, gun cooling pads, and a scout base. This allowed my robot to take apart the regular robocode bots that I have on my computer (including Freya). This means that NG allows even bad robots (like mine) to beat amazingly good robots from old robocode (like Freya). Is this a good thing? --Bayen
I belive it is. This new mod system will allow robocode bots to not only be good/bad based on their aimming and movement, but also on the author's ability to design a system of pro's and con's. If we make it a requirement that new versions of robocode must allow older bots to be competitve, we will seriously hamper any atempts to evolve Robocode much beyond its current system --UnderDark
I agree with UnderDark. While I have my doubts that I will be converted to RobocodeNG very quickly, I do think it is the right move to discard the competitiveness of "legacy" bots. Even if the creators tried to keep older bots competitive, it would very likely fail (in whole or in part), or the new options for bots would become hardly worth the effort. -- Voidious
@Greywhind: The current version of RobocodeNG is using new Java 1.5 classes and take advantage of the new features of the Java 1.5 language. So it must use 1.5 in order to run. However, it really is possible to change the new stuff back to Java 1.4, and I am seriously considering to do this! -- Fnl
The robots mods in RobocodeNG are not very balanced, so the legacy robots do not stand a chance. Even worse, I have had some competitions with friends of mine trying to build moded robots with RobocodeNG. It seems like the shotgun always win. In addition, the robots keep gaining energy, and in some situations the battle keeps going on "forever" as the robots keep gaining energy as no robot is dying. This is a very bad scenario. I am considering to remove the mods from RobocodeNG, and merge the new features as e.g. the new rendering system, editor improvements, bugfixes, graphical debug facilities with Robocode 1.0.7 and only make use of Java 1.4. Then I will make a new version of RobocodeNG without the mods (that is a branch in the CVS), and concentrate on optimizing the internal engine for faster RoboRumble and stuff. Later, I will design a totally new mod system where mods are plug'ed in in a new "mods" folder similar to the "robots" folder. With this new mod system the legacy robots will have a fair chance as increasing robot abilities will "automatically" cost/decrease other robot abilities. -- Fnl
The shotgun is the obvious way to go when making bots, or so you would think, but it is not the only good mod for guns. The Flamethrower can completely freeze up a bot if you can catch them in a continuous stream of fire. A good rammer equipped with the UV laser can be better than any Legacy rammer. I think the current mods give a good challenge! However, it would be a good idea to balance them better. --Bayen
Somehow, I can't imagine an auto-balancing system working as well as a hand-tuned set of balanced mods, but I'm sure it's possible. I just think there may be ways to still exploit the auto-balancing no matter what you do. Good luck, though! While I said I wouldn't be "quickly converted" to NG, I am definitely interested in making bots for it at some point. -- Voidious
I've realized that the Railgun and the Gun Cooler allow for almost continous shooting with extremely high-damage bullets. I can't find a way to beat that combo on a circular targeting gun (with a turret base). Is there a way to kill this? --Bayen
I tested robocode06 the "Debug Paint" button its a nice feature, but it is buggy :( I started a new battle and everything works fine (exept that my grafics are upside down) when i start a second Battle and turn the debug grafics on every thing is turned upside down, my grafics are now like they should, but now the bots and the bot labels are turned. Looks realy strange... After the first round robocode06 crashes completly. I dont know if it is bot specific, but i think it isn`t. -- Krabb
@Krabb: Thank you for the report. I will start investigating the problem(s), and release a new version when the issue is resolved! --Fnl
This strange problem occurs some times, when i switch between the robocode main window and an other window, but only when the degub graphics are on. And i discouvered a new bug, the robot labels are bumping some times.-Krabb
@Krabb: I have made a couple of bugfixes with Robocode 2006 v1.0.1, especially in the debug graphics part, which is now available for download. I should like you to try this new version, and tell me if the bugs has been fixed, as I'm not able to reproduce them anymore. --Fnl
I replaced the old robocode.jar with v. 1.0.1 (i hope this is enough), but this bug still occurs. When i start a new battle and turn the "Debug Paint" on and then focus the main robocode06 window everything is turned upside down :( Im sorry for the delay, but i was a bit busy in the last few weeks. If you want me to do more test contact me at mf-crab(at)web.de or with msn (same address). --Krabb
Maybe some teleportation as in you go to a specific (hidden) place, which instantly teleports you to another (hidden) point, vice versa. Or, different ground color! (other than blue, or black (no ground)).
Also, make it be able to set wheel color --Starrynte
@Krabb: This probably isn't the problem, but in java, x,y coordinates start from the *top left* instead of the bottom left, so the y coordinate will be reversed. I don't think that will make the text upside-down though. --Starrynte