New event management software

Place discussions about upcoming events here in this thread.

Moderators: BeligerAnt, petec, administrator

StuartL
Posts: 36
Joined: Sun Mar 24, 2013 12:38 pm
Location: Berkshire, UK

Re: How to run a better AWS?

Post by StuartL »

Joey wrote:the web-based script does look good but it won't work in a scout hut unless someone had mobile internet...
As I'm writing it I'm thinking about two solutions to that:

1) Ignoring the problem. The existing paper solution and spreadsheet solve this situation elegantly with little need to change anything. The website solves things for larger events where a degree of coordination is required.

2) Creating a standalone implementation. This shouldn't be too difficult. The coding exercise is about ensuring the logic is correct, from there I can build a 'real' app, whether that's PHP/SQL, MS Access, OpenOffice, etc.
Remote-Controlled Dave
Posts: 3716
Joined: Sun Apr 03, 2005 5:30 pm
Location: Antrim, Northern Ireland
Contact:

Re: How to run a better AWS?

Post by Remote-Controlled Dave »

All this programming chat gives me a headache. lol. I understand not one word of what it is on about and will probably revert to pen and paper if I end up running the next AWS, unless Scott brings his laptop and stuff along to speed up the draw.

Is there any way we could limit the computer stuff to a separate, more specific topic heading, rather than this one that was meant to be about more general ways of improving an AWS?

I may keep the next one fairly primitive on purpose, just so we can show people that they don't all need to be high-tech, slick affairs and that we welcome anyone to have a go at running one, no matter what your limits. I think the last thing we all want is for some kind of universal design to AWSs that make them all the same. If that was the case, we may as well just book the same venue three times a year and get one person to run it all the time.
Die Gracefully Robotics
Winner - AWS 39
EpicentrE
Posts: 831
Joined: Mon Jun 09, 2003 12:00 am
Location: Coventry
Contact:

Re: How to run a better AWS?

Post by EpicentrE »

Duff wrote:This all seems like a lot of effort to fix a problem we don't really have. Like Gary said in the first post, its not very broke, so don't over fix it. Building an entire new system seems a bit unnecessary, and messing with the format (ie. Randomising the next round) is completely uncalled for.
Unless there is actually a strong negative argument for the randomisation of fights per round, I honestly don't see it as a problem. I really only see it as being either advantageous, or having no real effect whatsoever.
Duff wrote:I thought the antlog did an admirable job of at AWS 40, and all we would need is someone to manually split up a teams ants at the beginning, and have an easy way of telling who is up next. We were fine up until the end of the group stages, as people knew what group they were in and when a fight was coming up. It was only after the group stages that things got a bit confusing.
I don't think anyone is protesting that the Antlog, and other tournament management systems, arn't also great. However, this system is clearly one designed for a web-connected high-tech event, and for that kind of event I believe it would be superior if it ends up with the features that we're told it will. That doesn't mean Antlog etc. will become obsolete; just that there may be a better option depending on the scenario.

In addition, please keep in mind that some people enjoy programming. This sounds like quite a fun system to develop, and if I'd had more knowledge it's the sort of thing I would've looked into making myself for AWS39. Don't assume that he's putting a lot of effort in in the hope that it will become the de facto standard, anymore than he might be putting a lot of effort in because he's enjoying building it.
Dave26 wrote:I may keep the next one fairly primitive on purpose, just so we can show people that they don't all need to be high-tech, slick affairs and that we welcome anyone to have a go at running one, no matter what your limits. I think the last thing we all want is for some kind of universal design to AWSs that make them all the same. If that was the case, we may as well just book the same venue three times a year and get one person to run it all the time.
Yes, this echoes the sentiment I made earlier in the thread. There's nothing wrong with doing an event the "old-fashioned" way, it has it's own set of advantages and disadvantages just like everything else. I know what I want for events I run, because I'm just that sort of person that loves to go super high tech and overcomplicate everything. But that doesn't mean I expect it, nor even wish it, from everyone.
Dave26 wrote:Is there any way we could limit the computer stuff to a separate, more specific topic heading, rather than this one that was meant to be about more general ways of improving an AWS?
This might be a good idea. It's probably worth making a new thread for the new management system so we can focus on just that in it, rather than mixing topics as we're doing here.

Edit: Until we do have another thread, here's some more feedback.

I've been playing this morning by setting up a standard double elimination bracket and comparing how things proceed through that compared to through the software, and I've noticed an omission. When doing the draw for double elimination, there will almost always be byes handed out, dependant on the number of entries. However, these byes are in the bracket against an opponent, and lose automatically, meaning the opponent progresses and the bye drops to the losers bracket. The bye is then up against another robot in the losers bracket, which it (obviously) loses, and then drops out. The end result is that a bye always go 0-2; and that after the first round of winners and the first round of losers, there are no more byes because they've all been eliminated.

However, in this system, it appears that it biases giving people a fight at the beginning to not giving them a fight. What this means is that, in my tests with 13 entries, there are 6 fights with 2 players, one fight with 1 player and a bye, and 1 fight with 2 byes. Because of this, a bye technically wins the first round and progresses to the second. While this isn't a massive problem with these numbers, consider the situation where you have, say, 18 entries. You need to use a 32-man bracket, meaning you get 14 byes. This means you have 7 byes proceeding to round 2, 3 proceeding to round 3, and 1 proceeding to round 4, and you end up with byes that actually "win" more fights than they lose. It also means you could end up with a situation where some players end up having to do substantially more matches than others, if another player keeps ending up against byes for round after round.

So, to resolve this, the opposite logic needs to be applied, and the bias has to actually be towards NOT having a fight. Thus, if there are 18 entries, there's only 2 fights in round 1, and the other 14 entries get through round 1 with a bye. Or, to put it in a formula, (round 1 fights = players - (bracket size / 2)). I think that's right at least.

Please let me know if this is unclear. It probably is. I do love my double elimination systems.
Scott Fyfe-Jamieson, Captain of Epic Robotics. Champion of AWS38/41/42.
http://www.epicrobotics.co.uk
StuartL
Posts: 36
Joined: Sun Mar 24, 2013 12:38 pm
Location: Berkshire, UK

Re: How to run a better AWS?

Post by StuartL »

EpicentrE wrote:Don't assume that he's putting a lot of effort in in the hope that it will become the de facto standard, anymore than he might be putting a lot of effort in because he's enjoying building it.
I appear to be shockingly transparent :D
EpicentrE wrote:Edit: Until we do have another thread, here's some more feedback.
(... snip ...)
All feedback is welcome, I'm happy to open a new thread if that's universally desired?

I'm quite confused by what you mean by a 'bye'. I've always interpreted a 'bye' to be when there's no-one for someone to fight and hence the 'bye' automatically gets through to the next round. If I interpret your description correctly your implementations of what I call a 'bye' automatically lose? But then I'm confused by what you're describing as 'bye's competing with opponents and losing. I'm clearly misunderstanding something in your terminology.

In my system each 'round' is played to maximise the number of fights. The only 'bye' (my terminology) is if there's an odd number of players. This player automatically goes through to the next round but is chosen first when allocating fights, balancing their fight count against everyone else in their bracket. The software tracks the number of bouts, the number of wins, the number of losses and the number of 'unplayed' bouts.

An 'unplayed' bout is one which is allocated the two competitors but has not yet reached a conclusion. Any participant allocated an 'unplayed' bout is ignored when choosing opponents, i.e. you can't be put into a new game until the result from your current game is in and you know which bracket you're in.

As players lose they are passed into a 'losers' bracket where they are allocated fights using the same logic, i.e. the one who has played the fewest games gets allocated a fight first, balancing the number of games the losers have played.

Within the winners bracket the same logic is also used, so as they continue to win they also fight the same number of times as other winners. If they lose and fall into the losers bracket they are often behind on the number of games they've played and hence will be repeatedly chosen first until the number of games even out. Note that they're not deliberately over-allocated games to catch up, they're just picked first when allocating games so that the one who has played the most games is the one most likely to get a 'bye' into the next round.
EpicentrE
Posts: 831
Joined: Mon Jun 09, 2003 12:00 am
Location: Coventry
Contact:

Re: New event management software

Post by EpicentrE »

Ok, I see. I need to think about this a bit more then. Having it run like that actually makes it quite different to double elimination, despite achieving the same result. I need to run through a few different scenarios and tests and let you know whether I find anything that could be considered unfair. I'll get back to you ^^.

As a sidenote, as a lover of logic, I'm probably enjoying helping test and scrutinise this almost as much as you're enjoying building it :p.
Scott Fyfe-Jamieson, Captain of Epic Robotics. Champion of AWS38/41/42.
http://www.epicrobotics.co.uk
User avatar
Rhys
Posts: 738
Joined: Tue Oct 29, 2002 12:00 am
Location: Caerphilly, South Wales

Re: New event management software

Post by Rhys »

As you said, I don't think there's any negatives to the randomisation, it's just a personal preference, and I like the idea of knowing how the draw will pan out from the start. And as far as I'm aware there has never been anything like this in previous AWS events, so it seems a bit odd to introduce it now. But having said that, I've got no objections to it. If the event organiser wants to randomise the draw then that's completely their call. As someone else has already said in this thread, as long as we can turn up and have a fair fight, no matter how high or low tech the organisation is, I'll be happy.
Image
Andrew_Hibberd
Posts: 1134
Joined: Tue Jan 20, 2004 12:00 am
Location: London
Contact:

Re: New event management software

Post by Andrew_Hibberd »

It would definatly be interesting to give the random fights an idea, although you won't know who you are fighting until the previous round is complete. In theory it should reduce the number of byes, repeat fights and team clashes, potentially also making the round clearer. I will try and sit down tomorrow and have a play.
TEAM GEEK!
Post Reply