Robocode 2 Brainstorm

This page is a discussion of how Robocode should evolve in the future.

Robocode 2

I am thinking of starting up the development of a real Robocode 2. The main reason being that it is almost impossible to add new features and rules to the game without breaking compatibility with existing robots. Hence, Robocode is currently maintained - not enhanced with new true robot features!

My idea is basically to make Robocode 2 based on Robocode (1), but replace the parts that is new for Robocode 2. Why start from scratch when lots of stuff is running just fine? Features will be added in increments instead of one "big bang". So there will be a Robocode 2 verson 0.1, 0.2 etc. until a real version 1.0, where all the minor versions are "just" previous of the features as they are being developed. --Fnl

What to change? (main ideas)

• Totally new API that makes it possible to change rules and features more dynamically, and which allow robots to have different abilities etc.
• Compass coordinate system instead of "Robocode" coordinate system.
• Robocode 2 should allow robots to have different weapons, firepower, turning rates, speed, shild, starting energy, etc.
• Various kinds of games, e.g. King of the Hill, Capture the Flag (for teams), Tank Race (requires racing tracks + obstacles) etc.
• Perhaps robot should run on "fuel", and pick up fuel on the battle field. Perhaps this should be one kind of game in Robocode 2 out of many?
• Simple obstacles on the battlefield, and some way of defining customized battlefield.

I know there as at least 1000 wishes for how Robocode could be. But we have to be realistic and stick to the stuff we know is possible to do. 200 new features might take 5-10 years to develop! ;-)

So what do you guys think. Is I missing something really vital in order to really enhance Robocode? --Fnl

I'll comment more later, but the first thing I want to say is this... For me, what will make Robocode 2 interesting isn't really the addition of various gun types and armor types (though those could still be nice additions), but things that present new programming challenges to the Robocoder, like obstacles or your "fuel" idea. These would both add a whole segment of algorithms for path-finding that are just not present in Robocode right now. Glad you're thinking about Robocode 2 =) -- Voidious

In my opinion, simpler is better. All of those things are just too overwhelming for me. Maybe you veterans have exhausted your ideas in the old world, but for now I guess I'll just stick with good 'ol version 1. Thank you very much for your work on in!! I don't know if anyone else feels the same, but I just want to make sure there will be an audience for your efforts before you log endless hours! -- Simonton

I second what Voidious said. The thing that I would be looking forward to the most in a more advanced version of Robocode would be the addition of obstacles. Radar/bullet blocking obstacles would bring a new twist to OneOnOne and even Melee. Also, this “fuel” idea, I think it would be better that moving would take away from your energy and not a preset fuel level. This way you could save energy be not shooting or various other strategies so that you can move more. Thank you again for the new versions of Robocode, all of the new features are really cool and great to have when testing. -- KID

Simonton: Even though I might start up developing Robocode 2, Robocode (1) will still be maintained like you are used to. Robocode 2 is seen as a kind of natural evolution introducing new game concepts, and the version 1 is thought of being the version where things are kept simple and where the rules will not change. --Fnl

KID: Regarding the "fuel" feature taking away energy points. You're right. Kawigi and John Villar also surgested this some time ago, and I think it's a good idea. So, should we have "energy pills" on the battlefield, that come after e.g. x turn in a random spot on the battlefield? --Fnl

The "fuel" feature is a good idear, and obstacles are intresting too! But I'm sceptic about new guns and tanks, like robocodeNG implements it. It is nearly impossible to balance them. But a quake like implementation would be intresting: You start with a basic gun and you can pick up better guns and ammo which are on the battlefield, like your "energy pills". They could be on static fields or just random. If the "energy pills" or wepons spawn on static places and in constant time intervals there will be a battle for them, which sounds really intresting!

EDIT: And i think we should distinguish robot energy (used to move and shoot) and health. If you have "energy pills" which increases your health, battles could last forever... --Krabb

I agree new game modes would make the game more interesting. A death match game like Krabb is suggesting would be really cool. But I also think Robocode2 should be considered more of an extension of Robocode than a replacement. It would be a shame disregarding the hundreds of good bots already made. Also, the simplicity of the current robocode has a precision that we might lose with all these fancy additions. Whatever comes next, I'll still see normal one on one and melee as being the "standard" form of competition. -- Kev

• I think that restricting it to compatibility with RC1 bots is a bad idea. I think it just makes you compromise too much on the improvements you can make to the game. I imagine that Robocode 1 will thrive for a while, so I don't really see the bots as being "lost" with the coming of Robocode 2 or anything. -- Voidious
• On the precision being important, I strongly agree - if multiple armors/guns/treads (or whatever =)) are added, I think it should be kept simple and very possible to program around. Robocode 1v1 is very much a game of precision, and it might destroy its appeal to change that. For instance, as long as you can see what parts the enemy tank has enabled, you could easily take that into account in your code (hopefully with some simple formulas). Your max escape angles in gun and movement could account for their max speed and bullet velocities, etc. I do see a beauty in the simplicity of Robocode 1, but I think if done right, you can add some new stuff to the game while keeping things elegant. (Not being able to change parts in the middle of a round seems like a good idea to me, too.) -- Voidious

I'd like to see some sort of a mass scale war (100 tanks vs 100 tanks or something). It would be a whole different game because communication between your teammates is key. Obstacles would be awesome for this, because they would allow for strategies like bringing in a small strike force and hiding behind obstacles so that they are not scanned. --Bayen

• It is not possible to calculate 200 bots at the same time, 5 vs 5 in team battles could be really slow... but with 200 bots it woult take ages to calculate one round ;( --Krabb

I think the primary obstactle you face with any addition to the game is the amount of dedication competitors need to code for it. I think TeamRobot is a good example. There are a dozen teams or so, compared to nearly 500 entrants in the Roborumble. Hell, I started doing Robocode over a year ago and my bot can barely break 1800, and that was only when I used hard-coded strategies for around 150 specific opponents. I'm not saying you should not try it, but you may be disappointed with how many people actually take up the challenge. -- Martin

I agree with Martin 100%. --David Alves

Personally I think that the game shoudl still be rather minimal, but here are a few ideas that could be added to robocode.

• GetX() and GetY() as part of the ScannedRobotEvent.
• Perhaps bullets that could maybe be fired along a curve instead of just a straight line. (This will make wave-surfers even harder to make, etc)
• Perhaps the ability to change the graphics of your robot so that you could spiff up your robot without alot of benefit, but atleast nice to look at.
• Make robocode 2, 3D, so that not only do the robots have to deal with all the 2D elements, but arc, terrain, and other 3rd Dimensional problems. this would make Robocode 2 alot harder but also allow more people to become interested in it, as people could design thier own 3D tank.

But remember the whole basis of robocode was having indentical robots with only different programming! That should remain the same! -- Chase-san

One more thing I'd like to see is Human Controlled robots built in, just for grins. It would be nice to see how a real person could stand up against bots. I know HCBot is out there, but it would be easier if it was built in to Robocode and you didn't have to mess around with the focus window..... Also, you could turn off visible bullets to make it fair. If bots can't see bullets, you shouldn't be able to if you're controlling a HCBot. Well... that's it. --Bayen

I had an idea today about weaponry in Robocode 2, and after thinking it over a bit, I actually think it's a pretty decent idea. Two issues with having various weapons to choose from when you build your bot are: 1) it sort of violates the "tanks are identical but programmed differently" tenet, although you both have the same pool of parts to choose from; 2) largely related to (1), it complicates the bot building process to choosing the right parts as well as programming the tank.

I was thinking it might be cool to, instead, just equip every tank with a second weapon, perhaps something like a "grenade launcher". You would fire it (by putting energy into it, like now) with a variable trajectory, and where ever it lands, the grenade just stays there, and explodes with some kind of blast radius after a certain amount of time (maybe based on its power). This would have several important effects:

• WaveSurfing would get a whole lot more complicated - for powers from .1 to 3, you wouldn't know if they fired a bullet or a grenade.
• Suppose these grenades could go over the obstacles on the course. Now, the obstacles do protect you from the original gun, but if you always hide for cover behind obstacles, an opponent could learn to lob grenades over the nearest obstacle instead.
• The melee implications could be drastic, from lobbing grenades into crowds, to having a much better chance at corner dwellers.
• There are a lot of subtleties in the implementation that would be important: what grenade powers are valid (could be more than 3, so those you could differentiate from regular bullets); how big is the blast radius; how long until they explode; do the blast radius and timer depend on the grenade power.
• Just occurred to me - rammers could be dropping grenades on the other side of you, instead of firing power 3 bullets...

Anyway, even if you all hate the idea, I hope it's food for thought. =)

A couple more unrelated thoughts:

• It would be cool to be able to record battles, in Robocode 1 and/or 2.
• It would make it possible to design a pretty spiffy RR@Home client for the masses which would display pre-recorded (or RR-recorded) Robocode battles in the foreground while running RR@Home in the background.
• I think we could get some good press for Robocode2 1.0 (er, 2.0? dunno...) when it's released. Robocode got some decent web / media attention when it was released...

-- Voidious

Well think, if there are different weapons or different parts then some of the old ways of dodging bullets goes out the window, as you have no idea what they just fired, so the bot wouldn't know how to react to it and thus total chaos insues.

• So, In my humble opinion, though while it would be my stand to continue the ways of the original robocode and have identical (atleast in function) robots, if differences are possible then I suggest give some way to allow the other robots distinguish those differences (be it in movement, shield, weapon, radar or otherwise) and react accordingly.
• I think there's a sweet spot in how much information you have available to you. One possibility is to be able to tell from the scan what type of weapon was fired; then again, if you don't know that, it leaves room for cleverness in guessing what they used. After all, in Robocode you can't see bullets coming at you, yet WaveSurfing movements can still dodge bullets quite expertly. If there were just two guns, I think it'd be cool to not be able to tell. But if there were a lot more options it might just be a headache to not have that info available. -- Voidious

-- Chase-san

I am of the opinion that any "Version 2" or "Next Generation" spin-off of Robocode does not need to be backwards compatible. However, that also means that all of the competition is starting from scratch. And you're back to the problem of commitment of active participants to build competitive (or not so competitive) bots. -- Martin

Another idea that I think would be kind of cool would be the ability to use some of your energy to gain a temporary boost in speed or to cool your gun faster. For example, you could move faster (say 12 units/tick or something) but it would consume a little energy each tick to do it. I think there are a bunch of things you could do with the idea of exchanging energy for some temporary performance boost. --wcsv EDIT: in case it's not clear; this would be something that you can activate/deactivate at any time in your code.

• I think that sounds like a very cool idea, too. -- Voidious
• Maximum rate of turn: 1 degree / tick. You'd probably want to limit the speed at 13 1/3. If you charged 0.1 energy per tick per unit above 8.0, it would get pretty expensive. If your opponent is hitting you one show in six at 3.0 power, you are burning 38.4 energy over the course of the 96 ticks (16*6) to avoid that. Not that you can even move 96 consecutive ticks at 12.0v with a 1 degree turn radius. Moving on .. -- Martin
• Well the way I though of it was that it would be something that you used in short bursts (for example to get out of a corner or other tight situation) rather than continuously. --wcsv
• Just a thought, you could also charge to accelerate to the high speed, but not charge for sustaining it. Or maybe you charge all at once for a specified "boost" over a number of ticks. -- Voidious
• Really nice ideas here! But how could you differ between an energy loss because of a speed improvement and a bullet shot? --Krabb
• Well, you know their velocity so you can account for energy lost to that. Aside from that, you can keep track of their gun heat to know when they can fire. The rounds when their gun is cool are the only ones you need to determine if they fired. -- Martin

- You could add chaff, which would prevent radar sweeps to penetrate a sphere of the battlefield until it wore off, giving a tank an opportunity to get out of a tight spot (e.g. being pinned in a corner), though an opponent could fire / ram blind.
- Oil / waterslicks which spin the tank (and turret / radar with it) or cause it to slide sideways if a turn is attempted while in it, requiring the tank to counter the spin with appropriate driving techniques (e.g. turn into the slide and accelerate). That would be a difficult feature to program with realistic physics.
- Allow tanks to turn faster than their maximum rate of turn, but cause them to slide and decellerate as a result. This would make their direction of travel independent from their heading.
-- Martin

You all got a lot of great ideas, and I am trying to merge all these ideas into a common feature set that makes sense compared to how Robocode is today. This is my current summary of the common features for RC2 for now:

• RC2 will not be backwards compatible with RC1 as legacy robots will not fit the new rules, even if it's minor changes. So yes, veteran Robocoders will have to use all their existing knowledge to build a new kind of robot with new rules for RC2.
• There will only be one kind of "fuel", and that is the energy pool as we already know it. Energy is earned by hitting enemies, lost when hit, and could be spend on e.g. boosting velocity, radar turning, scan radius (?), temporary shield etc.
• The idea of shooting over obstacles (or other robots for that matter) is quite good, and might require specifying a distance and of couse blast radius. Perhaps the damage performed by the blast depends on the bullet power AND the specified blast radius, i.e. the smaller radius the more compact explosion and hence bigger damage, the larger radius the lesser damage.
• Parhaps a very basic set of weapons. So far the classic liniar energy-gun from Robocode 1, and at least the "granat like" gun that can shoot over obstacles within a specified range and blast radius.
• One question I have is: Should we add some new way of gaining new energy, e.g. by some kind of bonus? --Fnl

Well I had an idea of different kind of ammo that moves at the same speed and do the same damage as other but for example a kind of ammo that bounces off walls (e.g. you could hit yourself with your own bullet) or changes direction once in midair(e.g. after traveling such and such distance it turns say 90 degrees clockwise), these would give a bit more difference to the game but. Also perhaps allow bullets to collide easier, e.g. if they intersect each other they explode, unlike in robocode where bullets can at most times travel right through each other. -- Chase-san

Voidious: I like the idea of recording the battles, and will add this as a feature request for Robocode on SourceForge. Of course we should also have a way of playing the recorded battles. ;-) --Fnl

I have an idea, though i'm not sure how the robot would look, how about flying robots, robots that have to maintain thrust against gravity, navigate around objects, and then fire bullets at other robots at the same time, the whole shabang, it would be alot more complex but it could be as simple as options like turnRobotUp(), turnRobotDown(), turnRobotUpRadians(), turnRobotDownRadians(), setTurnRobotUp(), setTurnRobotDown(), setTurnRobotUpRadians(), setTurnRobotDownRadians(), getRobotFallRate(), getRobotAltitude(). Or perhaps have options for hovering ones aswell, instead of flying ones(e.g. forward movement provides lift). This idea came to me while watching FutureWeapons onthe History Channel. I doupt this idea will even be considred but I throw it on the table for completency. Perhaps as a possibility for Robocode 3, if the game goes that far. -- Chase-san

Ahh, I have a doable (atleast I think) idea. Make it so you can run a robocode game in series. Say you have your normal list of bots, but include an option on that screen where instead of running it as a melee battle, you can instead run it those many rounds with each robot vs each other robot in a 1on1 battle. I think you can already do something like this in RR@H, but I could never stand to try and download all those bots over dial-up.

So say you have these bots and you want to run a 1 round battle:
chase.v1.Velshea
abc.Tron 2.02
jam.mini.Raiko 0.43

In tornament mode (as I would like to call it), it would run these battles:
chase.v1.Velshea vs abc.Tron 2.02
chase.v1.Velshea vs jam.mini.Raiko 0.43
abc.Tron 2.02 vs jam.mini.Raiko 0.43

Then it would output all these battles on the output screen (which could get rather big depending on the bots you use)

Battle 1
1st: abc.Tron 2.02		180	50	10	100	20	0	0	1	0	0
2nd: chase.v1.Velshea		0	0	0	0	0	0	0	0	1	0

Battle 2
1st: jam.mini.Raiko 0.43	180	50	10	100	20	0	0	1	0	0
2nd: chase.v1.Velshea		0	0	0	0	0	0	0	0	1	0

Battle 3
1st: jam.mini.Raiko 0.43	138	50	10	65	13	0	0	1	0	0
2nd: abc.Tron 2.02		56	0	0	56	0	0	0	0	1	0

You could place the battle type selector right under the number of rounds picker. --Chase-san

I do think it'd be cool to have this capability in Robocode, but RoboLeague already does exactly what you're looking for if you're interested. -- Voidious

It is a cool idea to put this into the existing Robocode. Perhaps it could be a new feature to be able to setup and run tournaments. If this is the case, then perhaps we should incorporate it from RoboLeague and/or RR@H? What do you guys think? --Fnl

I have one question for you. Do you want Robocode 2 as an independent projekt regarding home page, bug reporting, feature requests etc., i.e. an independent projekt page for Robocode 2? Or do you want it on the same page like the existing Robocode? --Fnl

I say just keep it in the current project, no need to make things hard to find. I also have another idea, a sort of secondary screen fro each bot simular to the output console but visual in nature, so we can draw data to the screen without the bots getting in the way and so on. This way we could make cnstantly updating statistics that don't dissappear from the screen as soon as our bot goes poof. It would be neat to have a adjustable background color and so on. This way it makes it even easier for us to debug. (Not that the normal screen isn't enough, its just that the normal screen adjusts in size reguardless of what the robots drawing settings are, a screen just for a bot would make it easier to interpolate text and drawings) --Chase-san

I submitted a couple feature requests on the sourceforge page, which I see you just prioritized. I just wanted to say that you can ignore the one about the pause button. I realized I could set the speed to "1" in the main window, then hover over it's button in the task bar to effectively pause the game when I saw strange output. That TPS slider on the main window is really nice!! -- Simonton

I had an idea that builds off of the 'fuel' idea. How about having an 'engine heat', like the gun-heat idea, so that you can only move so far in a certain amount of time. Not only this, but things like accelerating should count more than simply coasting along at constant speeds. Also I like the terrain idea, because you can have it so that it takes more 'engine' to go over certain areas. And then if your engine is above a certain heat, your life starts going down. My 2c. -- Skilgannon

I found myself reading the MovementChallenge2K7/PreChat, reminiscing, and realizing just how much we all love these types of Challenges. I'm not sure of exactly what shape the feature could take, but it seems like it would be cool to be able to design "challenges" that could be loaded right into Robocode. This feature could range from being very simple to very complex, so I'm not sure where the sweet spot is (and only Fnl does, probably :-)). Some things that could be cool with Challenge support:

• Much simpler to setup run challenges: You could download a Challenge JAR just like a bot, and when starting a battle, you could see challenges next to bots and teams. It could output the results, either in a wiki-compatible format or an easily parsed (for wiki table conversion) CSV format. Most of us run a lot of challenges anyway, so we all have our systems down. =) RoboResearch does the best job at simplifying running challenges, by far, but it still could be easier and built in. This seems like the most basic part of the Challenges support, and even with nothing else beyond this, I think it'd be nice.
• Modifying or lifting certain game elements (like a mod would). A TargetingChallenge might disable ram damage from occurring. A new kind of TC might only let you see the enemy bot once every 10 frames. I might design a "challenge" bot that can move twice as fast as you, but has a weaker gun; you might design a custom bot for this mode, or just give your "normal" bot a mode for this challenge.
• API calls: A bot could use API calls to tell what "Challenge" it is in.
• Challenges Rumble(s): Sometime down the line, we could even have a "challenge rumble" mode for the RR client that would run various challenges for bots that had entered them, and keep online rankings.

I'd be really interested to hear what people think of this. It's even the type of thing you could add in a point release (ie, not in 1.0) without breaking anything, which is cool, since I don't think it would be anywhere close to a high priority feature for Fnl and Pavel.

-- Voidious

I like some of what you're saying, and don't like other parts. One very cool feature would be to specify arguments that your robot could access through API calls (e.g. "challenge=MC2K7", "challenge=RoboRumble", "scoreType=survivalist", "preferredDistance=450", "diskSpace=200K", "numChallengeCompetitors=10"). If that could be provided through Robocode itself, and saved in the .battle files, there are great possibilities for research! I have to say, though, that I'm not a fan of the idea of changing game rules/physics (even if optionally). I have to imagine that the current rule set will continue to be the popular one, and I know I will want to run challenges that will help me get the best performance in that rule set. Think of this: the one rule we can change already is the cooling rate of guns, but aside from one obscure thread long ago on the wiki (that didn't generate much response), I've never heard of someone using it seriously.

Now - as for integrating challenges into Robocode - I stand by RoboResearch (big surprise). The benefits of integrating something into the Robocode interface would be 1) standardization and 2) user-friendliness (newcomers would be running challenges in no time). But using a separate interface has some strong advantages, such as running multiple battles in parallel (for multi-core machines) or automatically switching to run the rumble when challenges are done (or vice versa). I am working on the user-friendliness and flexibility of RoboResearch currently via a GUI, which will offer more options (such as interleaving battles from multiple challenges, "run the rumble in one thread and challenges in another", or "pop up the Robocode window for battles run in this thread") and pave the way for a networked version. The networked version will probably store all results on the server, making your idea of a "challenge rumble" as easy as writing a webpage to pull out the results.

Now you have my 2 cents. Did I do a good enough job selling RoboResearch? :) -- Simonton

Your point about modifying physics and such is quite well taken. To be honest, they weren't great examples of what I was thinking; I was more thinking of stuff that could be "transparent" but useful / necessary for the challenge, like the ram damage thing. The truth is very few such things can really be "transparent", since top bots will always be simulating the physics of as much as they can observe and basing behaviors off of it. Nevertheless, whether I'm able to clearly express this idea or not, I think the ability to change things about Robocode internals for a "Challenge" could be useful (even if those changes I brought up are lame reasons to have this support).

I have a very high opinion of RoboResearch, and have heard very high praise for it from people who really use it, but the truth is that I have used it very little. I ran into some weird Mac / JVM issue (which I readily blame Apple for before you, but anyway...) and didn't get very far last time I tried. (I'll try and get you some info on that when I try next.) To be honest, it's kinda tough to figure out my opinion on some of this ... I am a big fan of a powerful Unix CLI, but also a big fan of a big, simple button instead of tons of manual setup, and each has its place. Most Robocoders get addicted to (er... "into") Robocode enough that they probably prefer the CLI power over the "big button" simplicity in many cases. But I still get dreamy eyed at the idea of downloading "TC2010_1.0.jar", dropping it into /robots, clicking a button to let it run, and having the results when it's done. =)

It sounds like you're continuing to greatly improve RoboResearch, so perhaps I will have much of what I want before Robocode 2 even comes along. That would be fine by me. =)

-- Voidious

I totally agree about the benefits of a GUI over a CLI. The reason RoboResearch doesn't have one already is because it worked and I was more interested in developing my movement at the time. However I disagree that a CLI is more powerful. The reason I'm writing a GUI now is because controlling the things I want it to do would just be a pain in the butt with text commands. If I don't get distracted again, perhaps your dream will come true for TC2K9, but on both your CPU cores at once ... and maybe mine and 4 of David's too :). Results should be submitted to the rumble when applicable, too ... -- Simonton

@Voidious: I've been happily running RoboResearch on my Mac (Intel 10.4) for many months now. I did have to change the BattleRunner class to run Robocode minimized instead of using -nodisplay, but it was a simple hack. Unfortunately -nodisplay throws AWT exceptions just like you reported for recent versions of the rumble client. But that allows me to drop in on battles every once in a while to see what's happening. -- Darkcanuck