TacticalTeamSetting - Robo Wiki -= Collecting Robocode Knowledge =-

I played some team battle but I think that there's almost no place for global team strategie or collaborative strategie. I think that we should define some rules so it become more interesting. In Quake it's a little bit similar : In teamdeathmatch you have no strategy appart from being together because you could be in different rooms, but it's not the case here. Real collaborative strategy are in "capture the flag" or fortress.

So i would like to add some rules or something else in order to have a real team play. SoccerRobocode was a attempt to do this. --Synnalagma

Please post any idea you have about it even the crasiest one:

We could set rules as Albert suggest in CoopRobot/Chat, we limit function like moveTo(x, y), shootHeadOn?(TargetName?), shootLinear(TargetName?), we just must decide wich one....

Another idea comes frome Quake it's the "freeze mod". If you are hit (power doesn't matter) you can't move anymore, you are freezed. If one of your teammate stay for some times (like 10 frame) near you (maybe a distance of 50) you are "defreezed" wich mean you can move again. When all ennemi bots are freezed you get 1 point. --Synnalagma

I've been thinking about this one, and i think i know how to do it quite easilly, so i will give it a go over the next couple of days, and get back to you. -- Tango

That would be cool, I also thought about it. I think it can be a really cool mod because you must decide between freezing enemies or defreezing your teammate. --Synnalagma

Ok, here's a page, it's not ready yet though: RobocodeFreeze -- Tango

I was just telling Jim the other day that the first thing I'm doing when Robocode goes open-source is to make free-for-all Death-match robocode. A little off topic, but just a fun thought. -- Kawigi

: What's the difference between that and the current robocode? Melee is free-for-all death-match, isn't it?

Or do you mean mutliplayer human controlled ? --Synnalagma

Melee is last-man-standing, primarily. The way a true robocode death match would work would be as follows:

When you die, you are 'respawned' in a random location
You don't get survival points. Damage points, maybe. But your score should ultimatly be a count of how many opponents you finished off.
You would lose a point if you 'suicided' (maybe there would be something to this, or maybe not. Maybe we could call it a death and respawn if you get disabled, or maybe we'll just ignore this aspect of death-match-type games.)

The fundamental difference is that the focus is on killing more than surviving. Maybe, while I'm on the idea of putting FPS concepts into Robocode 'mods', we could add an "Instagib" version :-p -- Kawigi

Ah, i see. Sounds good. How about simply +1 point everytime you kill, -1 point everytime you die? -- Tango

I think this can be quite easy to implement (just take a look at the EnergySetter? class in SoccerRobocode) the whole thing is how assembling the results, maybe by setting up a referee (a bot) with coordinate (-500;-500). We can make it much simpler if there's a time limit (and no frag limit) so each bot can check for a finish without connecting each others. --Synnalagma

This kind of communication can be done by simple file i/o; when a bot hits the frag limit, a file could simply be created called endround; all robots simply check if this file exists every tick, and if it does, they end the round. A configuration deathmatch.txt file should be available which the bots read to initialize themselves and retrieve game parameters such as timelimit or fraglimit; they should all block and wait for the file so that they each read it one by one.

I am an extremely big fan of this deathmatch mode; I had never thought of this before. I'd love to participate in the development of this, and I'd love to play it as well. My vote for scoring is that we have various scoring types; the of course classic +1 for a kill, the survival -1 for death, the +1 kill -1 death, etc.

-- Vuen

I think either mode has some merit, although I'd say for team deathmatch, it should just count kills and then count negative kills when you kill a teammate. About detecting if the round should be over, it seems like you could modify the Battle class to figure that out for you, and the RobotPeers? could get the info from their reference to the Battle. -- Kawigi

Just made a first test (little set of class) with no communication so you don't have real result. The finish is decided by time limit (7000). You can get it here https://www.geocities.com/synnalagma/dm.html but note that's only the basic idea and not a release. The problem with file is that you must change the SecurityManager? (otherwise you can not acces file out of your directory) --Synnalagma

I think it's time for a new page RobocodeDeathMatch, There's an alpha release, fixed the communication stuff. --Synnalagma

I completely agree with the need of setting some rules that allow for a real team play.

A very simple setting would be:

Head-on targeting only.

Seems really stupid, but since head-on targeting is easily avoidable, it would create the need to coordinate bots to attack the enemy so it can't avoid all hits.

One issue is how do you fire at a bot using head-on targeting, if you don't know where the bot is (because you haven't scaned it). A possible solution would be to add an additional rule stating that you must have you radar locked and your gun correctly pointed to the bot before firing. It would create also the need to deal with bots firing and bots gatering intelligence (spining the radar).

It could be implemented using a class that extends TeamRobot:

public class RestrictedTeamRobot extends TeamRobot {

   public void lock(target) { ... }
   public void setFire() { ... would override the normal setfire ... }
   public bullet setFireBullet() { ... would override the normal setFireBullet ... }

}

-- Albert

Sounds good. How about altering the getOthers() method to return a list of bot names and exact locations. No radar. Then everyone has the same info. Remove the turnGun() and turnRadar() methods, and alter the fire() method so it takes a name and a power. Then it automatically fires directly at the enemy bot. I'm not sure if the gun would have to turn first, or it we should make the gun turn instantly... -- Tango

I think it would not be a good idea to remove the radar, gathering data is an important part of robocode. --Synnalagma

Very simple: just don't let the robot control his gun. He can control every other aspect of his bot (including radar), but for gunning only has the method

 pointGunAt?(name)

This points the gun head-on at the indicated robot. The setFire(power) method would only fire if the gun is already pointed directly at the enemy (so you can't be clever and switch targets and fire while switching to lead :). So simply make a class extend TeamRobot and override all gun control methods and make them blank, and add the above method. -- Vuen

That's pretty much what i was saying, i just couldn't work out how to move the gun. It seems like you've got it! But would you use gunTurnCompleteCondition?, or would you actually check if it's pointing at the enemy? If you just check it's finished moving, then you will always fire behind where it is when you fire, so after it's moved (unless it has a -ve guess factor) you will always miss by a very large amount. -- Tango

The robot should only be allowed to fire if the gun had completed the turn from last turn; this means it is currently pointing at where the enemy was last turn. Alternatively, if the gun is within a few degrees of head-on, fire should be allowed; I would opt for the latter because it allows an extra tick in front where the robot can fire head-on. A boolean method isGunReady?() and a GunReadyCondition? or GunReadyEvent? could be created to inform the robot of when it can fire. -- Vuen

While coding SoccerRobocode, I understood that we can made all thinkable change to the game (almost). So I thought about another idea : we can make different class (like in team fortress for Quake) like medecineBot (it heal bot when it hit it), radarBot (can't fire), and gunBot (like droid). Maybe too complicated... --Synnalagma

Would it not be a good idea to wait until robocode is open sourced before making *too* many changes? -- Tango

I don't think so, when robocode will be open source we can redo it properly, but I don't want to wait until this (we don't know when). I just wrote this so we can feel free to implements any idea... --Synnalagma

Wich class would be cool (feel free to add any idea):

RadarBot?
GunBot?
Maybe an interface for slow but lot of energy bot

Just put your name below a mod with I for "interesting", M for "maybe" and F for "forget it"

Freeze Mod I-Synnalagma I-Tango M-Albert F-? M-Vuen

Restricted Head On M-Synnalagma I-Albert I-Tango F-Kawigi M-Vuen

Class Based M-Synnalagma I-Albert I-Tango I-Kawigi F-Vuen

Death Match I-Tango I-Synnalagma I-Kawigi I!!!-Vuen