Twin Duel/Origin Discussion

Twin Duel Sub-pages:

Twin Duel - Participants - Results - Strategy Guide - Tourney Runner - Origin Discussion - Archived Talk 20090807

---

An idea for a new regularly held competition, probably weekly or bi-weekly. Here's a potential rule set, written as though it's a real rule set.

• Competitors will be 2-bot teams on an 800x800 field.
• CodeSize of teams must be under 2,000 code bytes. That means two of one bot that is under 2,000, or two bots that total under 2,000. (Note that they can share classes / code.)
• Battles will be 75 rounds, with the winner being the team with the most survival firsts. (Yes, this is a Survivalist competition.) In the event of a tie, the match will be run again.
• Initial seeding will be round robin style, where every team fights every other team 3 times. Based on win / loss records, with percentage of survival firsts (throughout all matches) as a tie breaker, teams will be seeded for a bracket style tourney. Byes will be given to top seeds, if necessary.
• Battles will be run by Voidious, who will then post the results.
• If there is interest, there will be both AdvancedRobot and ExtendsRobot divisions.

We might as well get official about it...

Name	These rules are good	I'm OK with these rules	Rules still need changes
Voidious	X
David Alves	X
Loki	X
GrubbmGait	X
Krillr	X
Kev	X
Krabb		X
ABC		X
Chase-san		X
Add your name...

Of course, please comment if you choose that third one!

---

I have heard what great fun, and what a great influence on bot development the MiniBotChallenge was. David mentioned to me recently how much fun the weekly competitions were, too. Would there be interest in having some new weekly competitions? I would certainly be willing to organize things and run the battles; it sounds like a lot of fun.

If we did, I'd want to try some new styles of competition that would force us to create new bots, instead of just entering our best 1v1 / melee bots into a tourney style competition. The best idea I've had is to try some 2v2 team battles, on maybe an 800x800 field, maybe restrict them to MiniBots and count the winner as the team with the most number of Survival 1sts. But that's just a thought that sounds cool to me - I'm open to suggestions on the format.

In any case, would there be others that might be interested in this type of thing?

-- Voidious

Sounds fun. How about a normal 2v2 team battle and an ExtendsRobot 2v2 team battle? That'll force some new thinking for sure. =) --David Alves

Sure! And how about the MiniBot restriction for the AdvancedRobot division? I think it would keep us from adapting our MegaBot duelists, and force us to forfeit general bot logic for team work. (I would also say you could have 2 of the same or 2 different bots, as long as they're both MiniBots.) -- Voidious

Sounds fun. Or.... how about a HaikuBot competition? -- Greywhind

Well, I'm willing to run the battles for it if others are into it, but I don't think HaikuBots would really keep my interest, personally. That's just me, though =) As for the competition itself, what would be a good format? I had been thinkng just like a bracket style tourney (Face 2 Face?), but I'm up for anything, really. -- Voidious

Another idea that could be cool for the 2 on 2 team challenge would be instead of requiring that both bots be minis, just require that total codesize for the team be < 3000. Just an idea. --wcsv

Yeah, that would certainly change things - do you mean that if it were 2 copies of the same bot, it could just be under 3,000? Or just that you could split it up like 2,500 / 500 instad of both under 1,500? If you could make two of the same 2,999 size bot, it seems like nobody would ever make two different bots, which I think would be an interesting thing... -- Voidious

• What I mean is that the combined codesize of the bots on the team should be < 3000 (or whatever limit we set) whether they are the same bot or not. So it could be 2 different bots split like 2500/499 or two of the same 1499 sized bot. It may be a bit harder to keep track of this way though.--wcsv
• I would like that setup best, but from what David says (and it makes sense) we couldn't really enforce this unless we forced OpenSource. Two 1499 bots could be using each other's code to increase the amount they could each do. -- Voidious

We've had the how-is-codesize-for-teams-defined discussion before, with people arguing that mini teams should be allowed with 2 (or more) different minibots, each under 1500. The problem is that it's too hard to regulate, especially if bots are closed source. For example, BotA contains only a static gun function and BotB contains only a static movement function. BotA calls BotB.doMovement() and vice versa. It's way easier just to set a limit on the codesize for the whole jar and be done with it. Also, I think a total limit of 3k is too high. It doesn't really put much codesize pressure on people, and bots become too big to make changes to them quickly. Just my two cents. Face2face style sounds good. The old minibot challenge style was fine too. HaikuBots aren't well defined enough for a competition. It's just sort of a blanket term for small bot. --David Alves

Ok, good points - I didn't know and hadn't thought about those types of logistics. How about a 2k code size? I think that should be fairly tight for any kind of team messaging, but still plenty of space to do interesting stuff. Another thought for the tourney would be round robin to determine top 2 or 4, then semi-finals / finals. What do you guys think of using "1st place finishes" as the score instead of the Robocode score? Should be easy enough to parse out of a RoboLeague XML, and I really like the idea of writing some survivalist strategy instead of score-based. -- Voidious

Don't make me bring out the PerceptualSurvivalist code... --David Alves

My favorite tournament format is pool play followed by bracket play. The results of the random pools determine seedings for final brackets and can also be used be used for elimination to make the brackets more prestigious. Also agree with 1st place finishes being a good score. --Alcatraz

---

Ok, four of you have commented on this so far. How many of you would actually be interested in participating? =) I'd like to think at least 2-3 other people will participate, to start, before spending too much time on this. So far, it sounds like these are a rough draft of the possible rules:

• 2v2, team codesize less than 2,000 codebytes.
• Score is based on team with most Survival 1sts. So an odd number of rounds - 35? 51? 101?
• Initial rounds will be round robin, with top teams being seeded for semi-finals and finals.
  • Win/loss as main seeding, with %-1sts as tie breaker?
  • For initial round robin, I think more than 1 season would be good - maybe 3 or 5.
• I'm thinking weekly or bi-weekly events, although of course you need not update with new versions every week.

Heck, I may even have multiple teams entered, too. What do you guys think of this? And is anybody else interested that hasn't commented yet?

-- Voidious

I'm definitely up for this. It'll give me a chance to show off my team management skills. Though you may want to think about doing more than just relying on survival... this would most probably result in a lot of very good bullet-dodging bots and not very many cooperative teamwork or good shooting bots. Here's what I think.

• Weight the different scores, Bullet Damage, Ram Damage, Survival as so.
  • score += (bulletDamage*.5)+(ramDamage*.5)
  • score += survival

Also, we should do either 70 or 140 rounds. What do you think?

-- Krillr

Well, I don't know the exact formula for Robocode's scoring, but I would probably just stick with that if we're going to use calculated scores. I like the survivalist idea, because I think it's intuitive to think that's how battles should work, but it isn't in Robocode. =) And what number would "survival" represent there, by the way? I do like the idea of doing more than 35 rounds, but it should definitely be an odd number if we end up making survival 1st's the main scoring. -- Voidious

Survival would be equal to the survival column on the robocode score output. Take a look at it, its column 2. As far as it being survivalist, it would be very easy to make a bot that just dodges bullets and really eliminates the purpose of it being a 2v2. As far as the rounds being odd, its my opinion that they shouldn't be so there can be a possibility of a tie. Making it odd would allow some teams to win out of sheer luck on the last round. This is also a flaw in the current rumble. -- Krillr

Well, the current rumble isn't based on survival, so how is it a flaw there? There is certainly a lot of chance in a single battle, no matter how many rounds there are, but it usually evens out over 1,000 battles / 400 bots for your rating. I've found I need 50 to 100 35-round battles to start to get really accurate results in 1v1, but 50 * 400 = 20000 battles just isn't reasonable for the RoboRumble...

But anyway, right, Robocode does custom calculate a survival score; forgot about that. And about dodging bots, what's wrong with that? It makes RamBots a reasonable strategy. On the whole, it changes the entire strategy of a match from what we are used to, which I think would be a lot of fun. Not that I'm married to the Survivalist scoring, but it certainly has my vote. Didn't anyone ever play Rocket Arena? (Well, for Quake 1/2, for me.) =)

-- Voidious

I am interested, although I can not guarantee a worthy team from the start. A 800x800 battlefield sounds good, it will prevent some of the sniping from the opposite walls. Any number of battles is fine with me, 75 seems a nice number if you have the cpupower to process it. Note that there is no guarantee that a f.e. 75-round battle gives a total of 75 nr1's, it could add up to more. Score on pure survival is oke with me (meaning nr1's, not survivalscore). I want to know if my team had the last man standing, not if it was good at reaching the last two. This also gives room for teams with different strategies for each bot. I have always found a tournament competition interesting, the outcome is not as predictable as the RR@Home ranking. I propose that datasaving between battles should not be allowed (although it probably would not fit in a team that also wants to be competitive) -- GrubbmGait

Awesome, glad to hear you're interested, Grubbm! I can't guarantee a worthy team either =) I think David is gonna destroy us at first, but we'll see. Willing to agree with the data saving, although I don't have a strong opinion either way. I know that the Survival-1st stuff is kinda weird sometimes - I think we should just rerun a battle if it's a tie. I'm pretty sure I have enough CPU power to run this pretty easily in an evening on my current machines. -- Voidious

---

Summed up a potential rule set at the top, and further input is still quite welcome. I really like what we have there as of now. And what would be a good name for this? It could be something more generic than this specific idea, as I'd be up for trying some other styles of bots at some point. -- Voidious

Started playing around with bots last night - 2v2 seems like a pretty cool and unique format! -- Voidious

Rules sound good to me. --David Alves

Alright, posted a little voting thing at the top. I don't want to rush things since I know not everybody checks the wiki multiple times a day, but we might as well keep the ball rolling. -- Voidious

Whoah, looks like RoboLeague cannot do teams? Might have to get down and dirty to modify it to do that :-\ Anybody have another option? Running everything by hand might be possible the first week, but with more than 3-4 entries that could get to be a real pain... -- Voidious

• I found this runbattles.zip utility that Mue posted a while back. I've taken a brief look at it and some of the Robocode source, and it shouldn't be too hard to adapt it to run our tournament. But if anyone knows of a way to run it that would save me that work, that's welcome, too. Anyway, please take a look at the rules and the vote at the top, and we can get this show on the road! -- Voidious

You think I'm gonna kill you at first? I'm flattered. =) I think "Based on total wins and losses, with percentage of survival firsts as a tie breaker..." could use a little clarifying, other than that sounds good. First competition scheduled for next Saturday? --David Alves

Sounds like a fun competion! And yet nother excuse not to work on my wave surfing :) But a survivalist competion should also benefit my (understanding of) movement. And i like the idea of sharing code amongst bots, this should result in some innovative coding ideas. --Loki

Just to check if I understand: Two identical bots with a codesize of max 2000 each, or two different bots with a codesize of max 2000 together, right? -- GrubbmGait

• i understood this rule as: "Two identical bots with a codesize of max 999 each, or two different bots with a codesize of max 1999 together". So two different bots would give you 1 byte extra :). But reading the line "That means two of one bot that is under 2,000" i am in doubt again. --Loki
  • To simplify, the total codesize for the team jar file must be 2000 or less. You could feasibly put a 500 codesize and a 1500 codesize bot in there, but not a 501 codesize and a 1500 codesize. Or, if you want, you can have two bots running of the same codebase, so you can have 1 2K bot in the jar running twice. But, to make sure you're in the legal limit, just jar it up and run java -jar codesize your_team_jar_here.jar :-p -- Krillr
    • Yes, the .jar must be under 2,000 bytes. Any distribution of codesize is fine within that. You could have a 1,250 byte base class with two classes that derive from it for some different functionality in your team members. This is really the only fair way to restrict code size, since classes within your package could access each other's methods, anyway; so restricting individual bot sizes is not possible unless we force OpenSource, which I don't want to do. (Though mine will probably be OpenSource.) -- Voidious

@ Voidious: how/where can we submit our entries? --Loki

You can just e-mail them to me, my address is on the ContactInfo page. My only other note on the rules is this: depending on number and slowness of entries, we might have to make the round robin portion less iterations (1 or 2). Shouldn't be a huge deal, though. Next Saturday 8/12 doesn't work too well for me, since I am making the trip home from where I've been staying all summer that day. Unless you mean 8/5, which would be OK, but I don't generally want to be running them on Saturdays (after that). =) What about like next Wednesday, 8/9? Or will people be ready this week? -- Voidious

How about 'TwinDuel Tournament' as a name? You are fighting a duel with twins that can be identical, but can also look similar to Arnold Schwarzenegger / Danny de Vito. I will start with a team this evening when staying in a hotel, so tomorrow I will have a working not very good twin ready. -- GrubbmGait

This looks like a cool blend of melee and one-on-one strategies. It's also interesting (for the first round at least) building a bot from scratch without any examples to look at or test against. I'll be able to get a team in by next Wedensday, but I won't be able to update it continuously (I'm sepending two weaks in Hawaii soon). -- Kev

A 2on2 competition is a good thing, but i don't like the codesize restriction. It's no fun for me to minimise the code. But if you gyus like it i'll force myself to create my first "mini" bot.

EDIT: A Droid/AdvancedRobot 2on2 team(1 Droid and 1 AdvancedRobot) competition would be intresting too :) --Krabb

I think the reasoning behind the codesize limit is to prevent people from just adding an if(!isTeammate()) to Phoenix or Logic or whatever and entering it. Without the limit, the top melee bots could just add a few lines of code and win. As for the droid thing... in 5v5 it's pretty cool, but in 2v2 it might suck. It's very easy to detect droids based on their initial energy, so all you'd have to do is kill the lone non-droid bot and the team would be pretty helpless. Although if the droid was also the team leader, that would be 220 energy... might be pretty good. --David Alves

Glad to see all those positive votes for the rule set :) What David says about the codesize limit is basically what I had in mind, too. I'd like everyone (myself included) to be forced to do something original. I was quite resistant to MiniBots for a while, too, but once I did it a bit I found it really a lot of fun; it's not even that hard to keep your codesize relatively small, and it's king of a good exercise to do something in as little code as possible.

So, when for the first event? I don't want Saturday to be "the day" permanently, but I could do it this Saturday (8/5), I think. Or Wednesday or Thursday, if some of you will be ready - I will be. Or we can just wait until next week to start. I gotta look into the automation of the battles, in the meantime.

-- Voidious

Great idea for a competition, should make for some very interesting tactic decisions. I voted in the "ok" column because , like Krabb, I don't have a codesize optimized code base to start from, unlike most of you. I'll be away for 3 weeks, I'll try to come up with something when I get back. -- ABC

@Voidious: You should pick a day and time that you can consistently run it. Makes for better coding (working toward a defined deadline) and makes it easier to say which submissions are on time and which are late. @ABC: I lost the source to DuelistMiniMelee and DuelistMini, so I don't really have a code base to start from either. Although, they honestly wouldn't be ompetitive at all today and they weren't very optimized in terms of reducing codesize, so I'd probably be starting from scratch even if I did have the code to them. --David Alves

Ok, let's make it Thursdays for now, and weekly. Glad you are giving us a head start, ABC =). And I'm sure a quick ShadowDuo would dominate a MegaBot version of this competition if we had one right now, but maybe not after we explore the possibilities in 2v2 strategy. Let's make the deadline Thursday at 5 pm EDT / 9 pm GMT. -- Voidious

So round one is on for this Thursday? --David Alves

Yep ... depending on entrants, may not have final results posted until Friday, but I'll try to have everything up Thursday evening. Good luck =) By the way, I like the name "TwinDuel", so I'll setup the official page for it in a little bit. -- Voidious

No droids allowed? I disagree. Just like in a normal team battle, the captain will almost always be the last one to die, and it is dangerous to target him specifically. More, there is always an advantage in killing the captain first, even without droids, because the surviving member(s) of the team will suffer a 10-20 (can't remember) energy drop. People should be able to decide if they want to use a droid, is the loss in radar info worth the 20 energy points? -- ABC

Yes droids could be really intresting, and I sure will create a team with droids! Who said thy aren't allowed? --Krabb

David said droids would suck in 2v2 (in this page), I don't agree. -- ABC

The rules don't say that droids are not allowed, so go ahead and make a team with one if you want. I think a team with a droid leader would be bad (just kill the other bot and you win) but a droid non-leader would be ok I guess. I don't know... I think a 2 bot team with a droid is weaker than one without, but feel free to prove me wrong! =) --David Alves