Talk:Teams

Credits - Teams Old wiki page: Teams Original author(s): Albert

Credits - Teams Old wiki page: Teams/IdentifyingTheBots Original author(s): Albert, David Alves

From old wiki

Well, that was quite a lot! One question. Five SandboxDT makes team, right? Do you know if it somehow can create Driods and stuff on the fly or is it just five AdvancedRobot on the team? The latter would mean they can't communicate, wouldn't it? -- PEZ

A droid is a robot that implements the interface "Droid", e.g. public MyBotClass extends TeamRobot implements Droid {}. Droids can still send and receive messages but they have no radar. Since a bot is defined as being a Droid or not in its class, you can't switch between being a Droid and being a regular TeamRobot on-the-fly. --David Alves

SandBoxDT is implemented on a TeamRobot. It is able to communicate. I think there is a recent post from Paul Evans in the RobocodeRepository explaining which information they exchange. -- Albert

What's LOS? --David Alves

LineOfSight (just guessing) --Dummy That's it -- Albert

I would just like to announce my team project, Project Ant Hill. -- Jabe2022

I have the idea of making a team that, because two teams = 5 vs 5, starts each round by assinging each teammate one or so enemy bot(s) to scan and give their position, energy, ect. As bots die each teammate will scan fewer or more bots. This way the entire team knows exact robot positions and energy levels, so information collection is complete. The bot that starts farthest from the enemys and has the least chance of dying is assigned leader and process most information rather than all processing the same information. A dying leader passes the processing torch to a higher-energy teammate.

I also have some questions. Would killing off a disabled teamate be a good tactic? Would friendly fire give the team points or only prevent the other team getting points for a kill? -- RobocoderDan

I've considered doing some team-based scanning tactics to get consistent data, but I typically get "enough" scans and the algorithms I've used have been robust against missed scans. I'm not sure about the points for friendly fire thing, it's worth experimentation. In general, what you really want to look out for is if that disabled teammate was your leader (although it's not likely to be unless your enemy specifically targeted it) ;-) -- Kawigi

A guy in my class is setting up a league for 5 bot teams with modified rules

• Gun Cooling Rate of 1
• For each Bot fully functioning at end of round winner receives 1 point, 1/2 point for each disabled bot

Anyone have any ideas pertaining specifically to such circumstances -- gimp

He he, it will allow fast kills. Cooling rate 1 means you can fire every 2 ticks and finish your energy in 33 rounds (not enough time to find a wall before dying). With 10 bots in the arena, it will probably create a big mess with more than 300 bullets at the same time in the air). But it can be interesting, being the most important thing to choice a dead by a lucky enemy burst or by firing and consuming the energy. -- Albert

I don't exactly understand what your last sentence was saying. Was it something about strategy needing to consider the choice between dying from enemy fire or lack of energy from you firing? I've got an idea for trying to eliminate friendly fire but I don't know how well it will work. I'll be spending the next bit of time evaluating the possibilities of its success. -- gimp

I´ve two questions:
1)Does every bot run in a seperate thread?
2)What exactly happens when a robot get killed? Is the run funktion simply no longer called?
-Krabb

I've got two approximate answers:

1. Aside from being in seperate threads, every robot runs even in a completely different class loader - but yes, they are in different threads, but they still basically run in sequence (Robocode just tells the others to wait while one does its stuff). What it means to have different class loaders is that not even static global variables are shared between robots.
2. Well, the run method only got called once - what happens when a robot gets killed is that they throw an exception or something to exit the run method and stop feeding you events.

-- Kawigi

Well at the moment my work with teams is solely based around Radar and gaining intelligence. This is actually a much bigger thing that it is with any of the other robots, because of the different possibilities (from everyone with radars to Droids). I am starting to think that we should have an ImplementsDroidCompetition, its amazing how much information you can get from events other than onScannedRobot, and I think that it would be rather amusing. -- Jokester

Thx Kawigi for the answers!
If you want Jokester we can make such a team and compete against each other and against dummy´s BlindFighters :) It will be realy funny!!! --Krabb

I have an idea that I would like to try it out. It is based off the book Ender's Game/Ender's Shadow. Anyway, each person creates a 40-person Army. The Army can be broken up into a bunch of little teams. Each team is called a Toon. Make sure your Toons don't fire at each other! Then, the armies face of on a 2000x2000 battlefield! The last army standing wins! I am working on an army now. If someone has questions, ask them. --Bayen

Could 80 tanks on a battlefield fit into any reasonable amount of RAM? Doesn't seem like it, but somebody else probably knows better than I. -- Voidious

I tried it before posting and it wasn't that bad. It went pretty slow for the beginning, but the whole round was over in less than 5 minutes. --Bayen

I tried it too, its possible! And it seems to be funny :) I would prefer a 5000x5000 Battlefield, but we´ll need a zoom function...

--Krabb

The new page for this idea is Battle School, named after Battle School from Ender's game! --Bayen

Is it possible to broadcastMessage(e); in the onScannedRobot? (I already have the try...catch block included) --Starrynte

nvm, i found out you can't broadcast a scannedrobotevent from broadcastMessage(). But why? --Starrynte

The broadcastMessage method takes a Serializable. You can only broadcast a method that implements Serializable - and anything it has instances of must also implement Serializable. So you need to do a little legwork to broadcast a scannedRobotEvent. -- Voidious

ok, i made a new RobotScannedEvent class that implements Serializable and set everything inside the ScannedRobotEvent into the RobotScannedEvent, then i just broadcast the RobotScannedEvent --Starrynte

Right now i am making a team of one of my robots. The leaders broadcast the RobotScannedEvent (see above) to the droid, and the droids use the RobotScannedEvent for their radar. However, the droids can't seem to hit sittingduck. Here is the code for the gunning method:

void doGunning(){
		if(target.location != null){
			double bulletPower=Math.min(Math.min(myEnergy/10, 1300/target.distance), target.energy/4);
			double absBearing=Math.atan2(target.location.getX() - this.getX(), target.location.getY() - this.getY());
			out.println(Utils.normalRelativeAngle(absBearing-this.getGunHeadingRadians()));
			if(target.energy>0){
				if(this.getGunTurnRemainingRadians()<0.01){
					this.setTurnGunRightRadians(Utils.normalRelativeAngle(absBearing-this.getGunHeadingRadians()));												
				}

				if(this.getGunHeat()==0 && this.getEnergy()>3 && target.live && this.getTime()-target.ctime<25){				
					setFire(bulletPower);
				}
			}else{
				if(target.distance<150 || this.getOthers()==1){
					setMaxVelocity(8);
					turnRightRadians(absBearing-this.getHeadingRadians());
					ahead(target.distance);
					waitFor(new MoveCompleteCondition(this));
				}else{
					setTurnGunRightRadians(Utils.normalRelativeAngle(absBearing-this.getGunHeadingRadians()));
					setFire(0.1);
				}
			}
		}
	}

I also set the droids to not fire at the teammates. Does anybody know what's wrong? --Starrynte

Have you tested it while not moving? Do all droids fire at the same location? In my opinion you should strike the test about gunturnremaining, you want to continuously update the gun to the latest known targetlocation, not just when the gun finished turning. When you move, you must update your gundirection to compensate your movement, otherwise you will indeed miss SittingDuck. -- GrubbmGait

Woo! I appear again for a brief moment! ;) Does anyone have ANY idea why the 1.5 message system seems to be a bit... broken? Unless it's my code (which it probably is.)

For some reason, MessageEvent.getMessage() is returning a RobotMessageManager - that's not even serializable!! And sending messages gives all kinds of errors... here's a printout from one of the bots:

1:*****End of Turn*****
2:Turn skipped!
2:Scanned sample.Crazy
2:Attempting to send scan of sample.Crazy
2:::Message not sent. java.io.EOFException
2:*****End of Turn*****
3:*****End of Turn*****
4:*****End of Turn*****
5:*****End of Turn*****
6:*****End of Turn*****
7:*****End of Turn*****
8:*****End of Turn*****
9:Scanned sample.Crazy
9:Attempting to send scan of sample.Crazy
9:::Message not sent. java.io.EOFException
9:*****End of Turn*****
10:Message recieved - robocode.peer.robot.RobotMessageManager
10:Scanned sample.Crazy
10:Attempting to send scan of sample.Crazy
10:::Message not sent. java.io.EOFException
10:*****End of Turn*****
11:Message recieved - null
11:Scanned sample.Crazy
11:Attempting to send scan of sample.Crazy
11:::Message not sent. java.io.EOFException
11:Turn skipped!
11:*****End of Turn*****
12:Message recieved - sendMessage
12:Scanned sample.Crazy
12:Attempting to send scan of sample.Crazy
12:::Scan of sample.Crazy sent toMyFirstCommRobot (1)
12:*****End of Turn*****
13:Scanned sample.Crazy
13:Attempting to send scan of sample.Crazy
13:::Scan of sample.Crazy sent toMyFirstCommRobot (1)
13:Turn skipped!
13:*****End of Turn*****
14:Scanned sample.Crazy
14:Attempting to send scan of sample.Crazy
14:::Scan of sample.Crazy sent toMyFirstCommRobot (1)
14:*****End of Turn*****
15:Scanned sample.Crazy
15:Attempting to send scan of sample.Crazy
15:::Message not sent. java.io.EOFException
15:*****End of Turn*****
16:Scanned sample.Crazy
16:Attempting to send scan of sample.Crazy
16:::Message not sent. java.io.EOFException
16:*****End of Turn*****
17:Message recieved - robocode.TeamRobot
17:Scanned sample.Crazy
17:Attempting to send scan of sample.Crazy
17:::Message not sent. java.io.EOFException
17:*****End of Turn*****
18:Message recieved - null
18:Scanned sample.Crazy
18:Attempting to send scan of sample.Crazy
18:::Message not sent. java.io.EOFException
18:*****End of Turn*****

It looks to me like it's getting random messages... non-serializable messages! Did something break??? --Bayen

I have no experiences with Teams....but have you tried on 1.4.9? If it works fine there, you should submit a bug report on the Sourceforge page so fnl can look into this. -- Skilgannon

I was about to do that, but then I saw the non-serializable field in my Message class. ;) --Bayen

Large teams

Are there any leagues for very large teams using the maximum size map, which would require the RADAR-equipped robots to be spread out so that you have an idea of what is happening, and the drones to be moved into formation around them as protection. Ther would also be room for more strategy, like using the bulk of your team to defend one side, and sending out radar-equipped skirmishers to find the enemies and allow your drones to engage them befpre they make radar contact with your defenders. There would be several different approaches to this: the first would be to use a regimented approach with drones attached to a specific leader and given a fixed role, which would be the simplest to program, but unlikely to be sucessful, a horde of largely independent melee bots with friendly fire checking and not much else, or thirdly, what I have been trying to implement. THis has the leader designated "captian", a pair of radar-eqipped leuitenatants, and two otehr radar-eqipped robots as scouts. I also have five droids, two attached to each Lt. and one as a meat shield for the captain. Each of the RADAR-equipped robots has the same code, and decides which is relevant to it. If the captain is killed, the best-palced robot is promoted, and if a Lt. was promoted or killed, a scout is used to replace him. If a droid is killed, nothing is done about it, although any robot can ask for droids, and wether tehy get one will depend on thier situation. There are probably other approaches as well, but I cannot think of them right now.

Lol, I am posting from school... Anyways, I don't think anyone has used your idea yet, but it will be interesting for a Battle School like league active again. --Starrynte

Is there anything in the rules that says if your leader is slain the remaining bots are disabled? I see it happening to my team but I don't see it happening to my opponents. -- Martin

• When the team leader dies, every member of the team takes 30 damage, I believe. Is that what's happening? (I actually didn't know about that until David told me about it recently...) Otherwise, no, that's not supposed to happen. -- Voidious
• That is probably the culprit. Hard to notice the pattern, especially when bots have already taken a sound beating by the time the leader is eliminated. Thanks. -- Martin

Is 1000x1000 the usual size for team battles in the RoboRumble? I couldn't find any information about that.

Teamrumble is 1200 x 1200. Meleerumble is 1000 x 1000. TwinDuel is 800 x 800. OneonOne is 800 x 600. This is what I remember, couldn't find it either.