View source for Talk:RoboRumble/Participants/Melee

DemonicRage naming/package issues

Sorry, I assumed it was the package name that was wrong, since justin.DemonicRage made sense and that was the .jar name given. Justin, did you mean to use DemonicRage as your base package name? Generally we keep each keep all our bots in the same package (for sake of rumble flags and such). Anyway, I fixed it back to DemonicRage.justin.DemonicRage and the URL is right, so it should work... --Voidious 22:07, 11 August 2009 (UTC)

To add to this: if you want to change version number/packagename/etc you need to upload a new version to robocoderepository. http://www.robocoderepository.com/BotFiles/3732/justin.DemonicRage_1.5.jar is not correct, you can't simply change the name. --Positive 23:07, 11 August 2009 (UTC)

Hey Justin - Looks like DemonicRage is still messed up. The file is still located at DemonicRage.justin.DemonicRage_1.6.jar (current URL is wrong), and it looks like it was really packaged as DemonicRage.justin.DemonicRage (the directory structure and .properties file reflect that). Are your Java package names "DemonicRage.justin"? You'll need to change those (back?) to just "justin" to have it packaged like you did before. Unless there's some bug in Robocode's packager or something? What version are you using? --Voidious 01:00, 12 August 2009 (UTC)

stelo.Moojuk 1.3

Just to double check, are other people also seeing things like the following when stelo.Moojuk runs?

stelo.Moojuk 1.3 stopped successfully.
stelo.Moojuk 1.3 has been stopped.  No score will be generated.

and

stelo.Moojuk 1.3: Exception: java.lang.ArrayIndexOutOfBoundsException: 5

--Rednaxela 05:18, 20 September 2009 (UTC)

Frequently, and some other bots occasionaly also give sortalike messages. Seems like Moojuk was not ment to be a meleebot. --GrubbmGait 11:42, 20 September 2009 (UTC)

Has anybody else noticed the strange results of Caan, especially when you look at the KNNPBI scores? https://literumble.appspot.com/BotDetails?game=meleerumble&name=apc.Caan%201.0&order=KNNPBI

It seems like it depends on who executes the battles. If I let Caan fight some melee battles on my computer, it is a relatively strong bot, but in the meleerumble it has 15.40 APS? Maybe it depends on the Java version? Maybe on other computers Caan just doesn't move at all and dies?

I would like to fix this because the rankings are distorted by this issue and a single bot can make a big difference if you are fighting for every APS point ;)

I am not sure that we can put this bot to a strong category. I looked at a few battles with it. It has worse hit rate than HawkOnFire with its head on targeting. Also, its motion does not look strong as well. However, it might perform well against several bots if its gun somehow tuned to hit them, than KNNPBI would be abnormal.

Yes, it is a mediocre bot. When I put it in a battle with some random bots, it usually ends up somewhere in the middle. But in the rumble Caan has 15.22 APS, which makes him the third worst bot in total, just before SittingDuck and WasteOfAmmo. This can't be right.

Furthermore, if you order Caan's scores by number of battles (like this), you see that those high KNNPBI scores only happen with new bots with less than 50 battles.

This means that in a lot of old battles Caan was probably disabled and didn't move at all like a sitting duck, whereas in new battles it performs normally.

I see now.

While ago back, when java switched from version 6 to 7, this bot was probably compiled with java 7, and whoever ran battles (very likely me, since I was mainly the only rumbles runner for a couple of years) probably used 6. In this case, such bot was disabled.

We about to experience it again with java switching from 7 to 8.

Maybe Skilgannon can somehow check not only the rumble client version but also the java's jdk version at the LiteRumble server side.

I've been running some battles in the melee rumble today, but I cannot fill my bot's pairings, because nz.jdc.nano.GridFu 1.0 is on the Robocode Repository, which seems to be down right now. I would gladly appreciate if someone could either give me the jar, or run some melee battles. And thank-you very much to everyone for such a great wiki.

You should be able to get hold of it from robocode-archive.strangeautomata.com, and feel free to update the participants page to point at the version that is hosted there.

Yeah, I just started running my client again a couple days ago and robocoderepository.com has been down the whole time. I'm missing a bunch of bots. Might have to switch everything to Rednaxela's archive if it doesn't come back soon...

Sure, it sounds like it would just mess up the strong bots and possibly aid weak bots, which is really no different than what a 1v1 rambot does.

I don't have any problem with rambots in 1v1, but in melee if you depress the score of a particular bot it also depresses their score against everybody else. Ie. it doesn't just affect your pairing, but also the pairings of all other bots in that battle. So, while I wouldn't mind it being added as a temporary fixture to see where it scores, I would prefer it if it didn't stay, because it skews scores in other pairing as well and we would have no way of isolating that it is just Grudge causing these scores.

I wonder if there isn't some way of figuring out each bot's contribution to the score over a large number of battles, and then award the appropriate score? If we had something like that instead I would have no problem with Grudge being entered, because then it wouldn't affect other pairings.

Hi mate. There is nothing wrong with putting the bot in the rumble. As long as it has no 'hard coded' names, and it does not look like you did this, it is a completely valid concept. Beside, it effects the score not like you guessed, in fact it is quite the opposite.
Generally ram bots have a very hard time in melee match ups and your bot will have an even harder time to survive. Most bots (even the strongest) target the nearest target (especially at round start) and so it depends who is the nearest bot to you at start. This effects the score in no way so it is valid. The next round you run all the way through the field to reach your first target - let me say this, you never reach the target because you will die on your way with a very high probability. This also effects the score no more than every other bot would. And you start a new list for every battle, most bots maintain a 'danger/target' list to decide which bot might be worth to engage.

I had some test runs with my usual melee test battle files and could not see any influence at all. Maybe you can say something about your test run with Shadow, there might be something i don't see right now.

Anyway, I woud say 'bring it on' and good luck :)

Well it depends on who hits it first. If a bot that usually does well hits it first (it prints out a grudge list, so you can see the order of who it is going after), it tends to greatly lower their score.

Since it will go into blind rage and go after it. Sometimes yes, it has to cross the field and will die. But other times it is right near the enemy, or far enough away that the said robot targets other robots first, but there are no other robots between it and its target (this seems to happen a good amount).

But I saw it get quite a few kills of Shadow, since it didn't care one way or another about dying and just wanted to harm Shadow. Shadow has other problems to worry about usually. So while it ends up dicing up Grudge pretty quickly its lost 50% of its health, which greatly harms its battle.

Yes, but this is no difference to any other RamBot that enter the rumble. The question should be how much (more?) change your bot the score compared to any other RamBot. Any RamBot tends to lower the score for most bots. I would say your bot is less of a threat than 'normal' RamBots because he has to move to much to harm other bots even a short straight line movement at round start generally means a great loose of energy. And the odds are very small that you find the same bot over and over again as first target in your 'grudge' list and even if so this could also happen with normal RamBots.
I once tried to maintain a 'weak' list in Numbat and it turned out that it is not rewarding to shoot, lets say always at SittingDuck first. The problem is you shoot 3.0 bullets at the other side of the field and if the first bullet hits the target all other bots near SittingDuck have killed him already. Basically this means you wasted quite a bunch of energy with almost no gain and the bot next to you hits you in the meanwhile for free - gains energy and you have a harder time to bring him down. If Shadow had a few kills at you, could this also mean he targets you if you are at low energy. You should look out if he is more often as usual the first in your grudge list.

I also have no problem with any behavior that doesn't involve hard-coding opponents to go after. As far as bringing down scores of top bots, a few thoughts. First, I'm skeptical of how much it will bring their scores down, for the reasons Wompi said. I'm also skeptical it would bring any of them down more than the others, which is what really matters. And even if it does bring some down more than others, that just means there are strategies to deal with the Grudge strategy that are better than others, which is fine and totally legit.

I get your point. The only robots that won't be effected by it are the ones who don't fire at it. Actually the best way to deal with grudge is to put another robot between you and it. It isn't intelligent enough to go around other robots to get to its target. So it will ram and fire right through some other robot.

Vengeance melee targeting strategy. Interesting.

How well it works depends on how many bots are also doing the same in the battlefield. If many competitors start using it, swarm targeting will no longer be the most effective strategy in melee.

I've actually tried that, by introducing a factor into the enemy's targetability which increased the better their survival was and the bullet damage they cause (to everybody, not just me, since I track that). This way I hoped to take out potential threats before they reached the endgame, but it ended up giving me less energy reward, so hurt my score overall.

Hi mates. can i suggest to remove the new 'SittingDuck'. Its probably the worst that could happen to the melee rumble. Someone stated why it is, but i can't found the thread right now. And beside, there is no competition on the end by just raising an exception to disable the bot as fast as possible.

Feel free to remove them yourself. I think it is best if we actually remove all except the regular 'SittingDuck' from the melee rumble, because it affects all other pairings as well in melee battles. Having them in 1v1 is not so bad though, because individual pairings do not get affected.

If you think the competition for the bottom is screwing up melee ratings, then remove the weak bots, but I prefer if they all stayed.

Actually, it IS possible to have a lower rank than my SuperSittingDuck. And I need to change the name as there was already another SuperSittingDuck from the super sample bots set.

See? http://darkcanuck.net/rumble/BattleDetails?game=roborumble&name=mn.SuperSittingDuck%201.0.2&vs=conscience.Suicidal%201.0

Ok i remove all bots that have no 'valid' behavior (like throwing an exception to disable). Not sure about the 'waste energy as fast as possible' - i guess i will let it in for now.

More matter how low the codesize is, ranking lower than SittingDuck requires a bit of insight and should have its merits.

I agree, and if it causes some issue with the MeleeRumble scoring, it's a problem with the scoring system (which definitely has its issues), not the validity of the bots. But I also agree that throwing an exception is an unfair approach to getting a low score and don't mind if we ask folks not to do that.

Well, not sure, but i guess there is no scoring system that can handle an unevenly distributed advantage of fighting against 8 instead of 9 opponents. The more 'ducks' the competition gets the more will the score spread and it will take ages to get a settled score. Its clearly a difference to fight 8 (or even less) instead of 9 opponents. Not to speak about the 'free' energy gain for the lucky bot who starts near the duck.

More ducks will reward prey-on-the-weak strategies more. Although this kind of strategy will always be rewarded to some extent in battles with 3 or more bots, with or without ducks.

As a note, there are intentional biases in robocode's score system that work to reward certain types of behavior anyway. Note the bullet damage and kill bonuses. Any way you do score will have some kind of biases or "value judgements" in it really. Even with the most pure "survivalist" scoring systems, a subjective judgement about what makes a "good bot" is being made.

With the scoring system as it is in melee, the action of adding and removing sitting ducks is a bigger problem than their presence or absence. Due to how melee scores are based on battles with a random sampling of robots in the rumble at the time, a change in the probability of a sitting duck being in the battle affects newer bots more than bots who already have most of their battle count. Adding the ducks gives a bias in favor of newer robots, and removing them gives a bias in the favor of older robots.

Of course... this problem happens in the melee scoring system for addition/removal of any bot. It's just a more blatent with sitting ducks than more "typical" bots...

ELO Rating system suffers less from this addition/removal problem in melee.

Not really. ELO doesn't take into account which other bots were also in the battle for each pairing, which is the problem with our melee ranking system.

ELO has a behaviour similar to Rolling Averages. It gradually forgets the past, so, past battles with retired bots stops affecting the ranking after some more uploads are made.

ELO was designed taking in account a changing environment. i.e. chess players improving their skills over time, new players, retired players...

The changing environment in this case is a bit different from chess though due to how there are many participants in each match, and it's known which participants that may have changed, versus not changed. This extra information could be leveraged.

I haven't looked deeply into it yet, but I imagine that it would be possible to construct a melee scoring system with greater immunity to this type of distortion, by considering the full list of partipants in each battle instead of tossing out information by splitting it into pairings. (Of course, the rumble client doesn't even give the necessary information to explore improved melee scoring systems, because the splitting into pairings is done at the client rather than the rumble server)

The current upload protocol is heavily ELO oriented. Splitting into pairings is how ELO is calculated in games with more than 2 participants.

I'm unsure if it was done that way with ELO specifically in mind... or if it was more "1v1 oriented" with melee as an afterthought.

Firing in a melee and not hitting anyone is an art of itself :-)