New event management software

[StuartL]

I have no doubt but that is OK when the events are held in schools and universities, with lots of tech help, but many evants are run in village halls and scout huts with no access to projectors or little more than a laptop. We are in danger of making the running of AWS events to complex for individules to host as they have in the past.

This is a really good point. So we either need to accept that the paper charts/spreadsheets have their uses or (if it's essential that each event uses the same logic) have a distributable version which can run on a laptop?

I'd certainly never considered the smaller events...

[EpicentrE]

That is indeed what is happening, in that everyone has two "lives", however double elimination normally has players split into "winners" and "losers" streams. Everyone starts in the winners stream, in which they can only fight other people in the winners (until the grand final), and stay there until they've lost one match, at which point they join the losers. Players in the losers stream only fight other losers (until the grand final) and are eliminated if they lose a match.

This is currently unimplemented.

So, in effect, when I pick matches I should only match opponents if they have same number of lost matches as the player I'm picking for? That's pretty easy to do. When do you stop this behaviour? When you get to two players left or earlier?

Correct, however it appears that it is doing this already (unless the one draw I ran through just happened to randomize them in that way). There are essentially three finals in double elimination; the winners final is the final fight in the winners stream, where the two players who have not lost yet fight. The winner of this proceeds to the grand final, whereas the loser of this then drops down into the losers final, in which they fight the person who has come out on top of the single-elimination-esque bracket of the losers side. The loser of the losers final is eliminated, whereas the winner of the losers final meets the winner of the winners final in the grand finals. At this point, the player that qualified from the winners final has two lives, whereas the player that qualified from the losers final has one, so the losers qualifier has to win twice to take the tournament.

Edit: I'm going to have more of a play with this later tonight, but there are a few things I want to bring up first;

Firstly, we could do with a "team" field on the players side, so that the software could stop people from the same team fighting themselves unless it was absolutely necessary.
Secondly, we need to discuss whether this randomized system is actually acceptable. Almost every tournament that I know of creates randomized brackets at the start, but then players stay in the same relative positions in those brackets as they progress through the tournament. With this system, all possible matches are randomized in every single round. As far as I can see, there are advantages and disadvantages to this. As an advantage, it more easily allows you to ensure people don't have to fight their own robots, as I mentioned earlier, and also it ensures that people can't game the system if they know they have a bad match coming up in a few rounds (doesn't really happen to us, but can do in larger competitions). The disadvantages are that people are unable to know what fights may be coming past the next one, making them unable to plan and prepare - I don't even know if this is a disadvantage at all, really.

I certainly think it's an interesting discussion to be had.

Regarding smaller events, it's not like this has to replace pen-and-paper methods for event organizers unless they want it to. Personally I'm very excited to use this system at future events I run if it is up to par, but that doesn't mean we need to force everyone to do so. There's nothing wrong with having different options suited for different scenarios, as long as they all give fairly similar results.

[StuartL]

Note to testers: I've broken something trying to fix 'winners' and 'losers' brackets. By all means play but the match 'elections' are currently broken.

Teams were definitely already in my mind, that's not a problem at all.

Randomising the matches was deliberate, otherwise as you say someone could 'game' the system by sacrificing one fight to get a favourable battle next time. With the random chance every battle has to be fought to win because you don't yet know what's coming next.

The 'round-by-round' behaviour was deliberate too. The idea was that all the 'scheduled' matches from the current round are presented at once. When the current round is finished the system automatically selects all matches for the next round meaning that you can use this time as a 'comfort' break, where competitors can grab a drink or break before the next round starts. Competitors never fight more than once in any given round but, depending on their wins and losses, may skip rounds. This behaviour is the same as the double-elimination charts.

Got a few things to do this afternoon, when I'm done I'll fix what I've broken and re-post here.

[Rhys]

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.

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.

[StuartL]

I believe I've now fixed all outstanding issues. The losers/winners trees appears to be implemented and working and it now understands the concepts of 'teams'. You can't, at the moment, enter new team names.

[StuartL]

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]

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.

[EpicentrE]

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.

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.

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.

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.

[StuartL]

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

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]

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.