The dreaded "draw"

[Remote-Controlled Dave]

Hi, I'm Dave, long time builder, first time poster.

I want to flag up a couple of things. Firstly, if we take Peter's sheets, it was voted on before if the top 16 should be re-drawn so people are kept apart before and the vote came up as no. I'm not expressing an opinion on that yet, just stating it happened.

Second, Scott, you are dealing in a state of pure logic, which I applaude, but to state that teams that enter 4 robots have put in 4 times as much effort/cost/time on the day etc...it just doesn't work like that. I always enter 4 robots. As now does Gemma. To state that I have spent 4 times as much of these factors (for the 8 bots I'm responsible for) then you, with your two bot team at the last event, is just not true. I don't design, spend a fraction of the time building them and cant remember the last time I bothered to charge or fix a robot at an event, yet always come with the full quota. Quantity does not equal effort or quality.

Thirdly, when a robot is drawn upon its fight path...should that path have the option to change? When I won my AWS, my opponents right through to the final were pretty easy, and I won, but my robot that came 4th at the same event is a much more satisfying result to me because of who it took out along the way. Alasdair had to lose to himself twice at one, and you had to lose a life at the last one, but that's just the luck of the draw isn't it? You happened to win the two groups that were then destined to meet each other in the final group...that's just how things go. Would we rather have a team get two robots into the final, then the final is never fought because they only have one transmitter? I had to fight 'myself' when I won too. I picked one to go through who ended up winning and added to the ease of the path.

Having made these points, I completely agree with the logic that, if you're not going to try and keep the same teams apart in the final group, why bother in the earlier groups, as it conflicts the random vs fair debate. However, I'm not sure a purely logical approach is the best way to deal with it. Keeping your robots apart in the group stages is more fun, more interesting and, yes, fairer. If all four of my team were drawn into one group, I could top the group without having to fight! Where's the fun in that?
However, when we reach the final group, if someone has been good/lucky enough to get all 4 of their robots out of the group, or 3, or 2, then to have a fair, even chance of meeting their own bot there is both a disadvantage (one loses a life without a fight) and an advantage (one progresses without having to fight and risk fatigue/damage etc). Also, if someone has got that many robots out of the groups, then its probably fair to suggest that their robots possess a certain degree of quality, at least enough to make them a worthy opponent. Removing the chance that they may meet their own robot means that all of their robots get to fight ones from other teams, increasing the chances of meeting a robot that may have scrapped through on luck or an easy draw. You could argue that a robot like this should be granted as much chance of meeting another robot that has been lucky as it has fighting a quality machine that has breezed through.

Personally, I like the current system. Yes, its a little less logical, and can be a little less fair, but its only less fair when it works out that way. It can also provide your robot with an easy route to the final, like mine had when I won. Entering four robots increases your chances of being granted an easier road, just as much as it increases your chances of meeting yourself come the finals group.

Its just the luck of the draw.

[EpicentrE]

As I said above, I think a few people would definitely side with Scott on this.

But even I'm not siding with myself anymore .

Dave; Thanks for your post. I wasn't aware that what you mentioned had been voted on before, and if I was I would surely have mentioned it previously. Regarding the 4 robots = 4 times the effort thing, that was assuming all other factors being equal. Not that that's any comment against your robots, etc. etc. We're both mature enough that I don't think I need to clarify that .

I won't reply to the rest of your post in too much detail, but I think given my earlier response it's needless to say that I agree with you. My initial arguments were wrong, which I didn't realise as I'd overlooked a key point.

I no longer have any intention of moving away from the currently-accepted system (which is to separate robots from the same team in group stages only). Unfortunately I do think almost purely in logical terms; that's just how my brain works. That said, I completely recognise and accept the arguments against the purely logical path in this case and agree that it would be unwise to follow it.

Thank you all for taking the time to post, though. It makes me happy to be in a community that will so vehemently condemn malformed ideas, even if they were my ideas in the first place .

[Remote-Controlled Dave]

You'd make a fantastic lecturer Scott. And even I don't believe my robots are worth much

[BeligerAnt]

Arriving very late to the party...

Scott, have you been looking at the AntLog code? The algorithm you describe is almost exactly what it implements!

I believe that most of your concerns are actually already addressed by AntLog and the paper charts (which implement the same algorithm).
The AWS has some particular attributes which make it far more complex to administer than most other competitions:
1. We allow any number of entries. We don't enforce a power of two, or even an even number!
2. We allow one person (team) to enter up to 4 times. Does any other competition do this???

The manual draw system devised by Peter, James and me and implemented in AntLog randomly distributes robots between groups much as you describe. There are some limitations to make the system "fairer":
1. Group sizes only vary by one to keep the number of fights in each group similar (see Peter's post above).
2. Byes are carefully distributed around each group to ensure that they always fall out of the losers' bracket as soon as possible. In fact, all groups from 16-way to 4-way can be seen as 16-way groups with an increasing number of byes.
3. Robots from the same team are allocated to different groups. This is to avoid non-fights and maximise the number of fights (and therefore fun!) for everyone.
4. We tweaked the algorithm some time ago avoid the problem of repeating fights as much as possible. It's not possible to completely eradicate this in double-elimination but it is now quite unlikely and doesn't seem to be the problem it used to be.

The AntLog underlying logic is actually quite simple (once you get to running the competition!) and it was decided (by the community) that there should not be any "massaging" of the last 16 to avoid teams meeting themselves. The discussion of this has been done above so I will not comment further. Leaving the logic as it is suits me!

The idea of dividing the field into 4 was quite interesting but I think the consensus of the discussion above is that it is not actually desirable. It wouldn't actually be that difficult to implement though...


And for anyone that has bothered reading this far...
AntLog 3.0 has been in the "thinking" stage for a year or two already!
I believe that AntLog 2.0 takes the spreadsheet-based system as far as it can reasonably go. The big-screen display works OK but has its limitations. I don't think there's anything wrong with the logic, given the discussion above.
My ideas for AntLog 3.0 involve using a web server to run a database which entrants can log into via laptop or smartphone to track their own (or anyone else's) team's progress. My thoughts had not extended to how this might integrate with a video stream.
However, it's important to remember that the system must not rely on an internet connection. This would mean setting up a local webserver and (possibly) wireless network. It's not particularly difficult but it does significantly raise the IT bar for event organisers! The internet is a fickle thing and the last thing we want is the entire competition disappearing because of a network problem or remote server fault. If we are in charge of our own infrastructure at least we have a chance of fixing it!
The reason for this remaining at the "thinking" stage is that it will be a big project, probably too big for one person. I would need to find some volunteers to help with this, but not until I have had time to put some sort of plan together. If anyone fancies learning PHP...

[EpicentrE]

Gary, it's interesting to hear that you're working on a new version of AntLog. I'm the first to admit that my coding skills are extremely rusty, but I really want to push the streaming side of events and to do that I need good integration with the tournament software. I also don't see any point in us both working separately on systems that are attempting to do the same things. However, it doesn't sound like AntLog 3 is a project which could be finished by the time I run my AWS, so I'm not sure what to do.

What I will ask is if I can provide you with the streaming-related features that I want, can you look at the possibility of including them in the plan for AntLog 3? I believe most of them would be fairly simple to implement for a competent coder, as they don't have to actually deal with the complicated matter of doing the stream, merely writing values to text files for the streaming software to display, and some UI changes to allow everything to be controlled from one place.

If AntLog3 were to include these features, then I could just look at bodging them into AntLog 2 (if I have your permission to make changes to it) for the time being.

[BeligerAnt]

AntLog 2 is inherently open source and anyone's welcome to "improve" it or otherwise adapt it for their own needs. I would reserve the right not to merge changes back into the "official" AntLog - I'm not keen on having to single-handedly maintin other people's code.

That said, the OpenOffice macro/scripting API is truly horrible so I wouldn't expect anyone to rush to add to AntLog!

AntLog 3 would be written in PHP with a mySQL database to hold all the fight, team and robot data for the competition (or possibly several competitions).
There would be a "front end" for competitors to track their (and others') progress, and a "back end" for the event organiser to enter data and run the competition.
Adding a feature to the software to write current fight data to a text file(s) should not be a big deal. Alternatively the streaming software could query the database directly? This would be my preferred solution as it would not affect AntLog itself.

Sadly, I can't see AntLog seeing the light of day in the foreseeable future. It's one thing having some idea of how it might work, quite another finding the time and inclination to fully develop a fairly significant application.

[EpicentrE]

I've never touched the macro or scripting part of OpenOffice, but hopefully I can find a way to bodge in what I want to do .

Unfortunately the stream software I use doesn't have any functionality which would could query a database. Outside of essential features it's fairly simple, but it's also open source, free, and reliable, which is why I use it. You can display text from a text file on the stream, which is why that's the only method of getting the robot names from the software to the stream. That said though, if it's not something you wanted to include in the core of AntLog 3, it would probably be possible to make something simple externally that would query the database and then write the relevant text files.

I'll investigate my options and decide what to do.

[Hogi]

on the subject of robots being drawn against each other, i usually hold a competition between my robots to see which one gets the furthest in the competition so two of them facing each other directly in combat occasionally wouldn't bother me as it would just prove that one of my robots was better and therefore deserved to progresd more than the other. however, if i was being repeatedly drawn against myself or if i was twice in one round EG: hogi vs thunder strike and then ant 2D2 vs language timmothy cluster, that would be significantly damaging to my chances of success as a team. i do apreciate though that it is a tournament between robots and not between teams so i think it's swings and roundabouts whichever way you do it. my suggested solution is to separate robots of the same team in the group stages but randomize the later stages. i know this has already been suggested and i think it would be good because you get a chance to see how all your robots fare against other people's robots and only the very competitive teams ( not me then...) would progress to the stages of the completely random draw and anyone good enough to get two or more robots into the play off stages will probably stand a good chance whether they get drawn against themself or not.