Tournaments!

Tournaments are coming!

This will be one of the biggest changes to the ButtonWeavers site that we've ever made in one hit. The initial commit, which only includes very basic functionality (rudimentary UI, single elimination tournaments), requires changes to 22 files and the addition of 44 files. It involves roughly 5000 new lines of code, including 3 all new UI pages.

The backend design of tournaments is intended to meet future requirements easily, including
  • new tournament types
  • button restriction
  • better display of tournaments, tailored to each tournament type
  • the ability to force the tournament to advance past idle games (no more bonefishing!)
  • automatic site generation of daily tournaments
I'm excited, but there's a lot of testing yet to happen, and the look and feel of tournaments is likely to change a lot as we start using them.

My hope is that tournaments will help people to get connected with others on the site more easily. I am looking forward to stumbling across new players who I may have otherwise not noticed, as well as reconnecting with players who I've lost contact with.



For those who are interested, details of the backend implementation follow, with text adapted from Issue 2131.

Each tournament type has a single file that specifies it, similar to BMTournamentSingleElimination.php. This file contains the logic to:
(i) create the games for each round
(ii) update who is still in the tournament after each round
(iii) check whether the tournament has completed.

For example, for the single elimination tournament, these look like this:
(i) Take pairs of players from those remaining in the tournament, create games between them using the first (and only) button that they have selected for this tournament, and add the game numbers to the tournament.
(ii) At the end of the round, all players who lost their game (or were forced to forfeit) in that round are removed from the list of remaining players.
(iii) The tournament is complete if there is one player remaining.

The changes to BMGame and BMInterface are minimal, basically just allowing a tournament ID and round number to be associated with a game. It may be necessary in the future when a game ends to trigger an update_state() for the tournament, but that's not in there at the moment.

The changes to BMInterfaceGame are mostly to allow games to be created by behind-the-scenes code.

BMTournamentState is the analogue of BMGameState customised for tournaments.

BMTournament does all the heavy lifting. Its structure is modelled upon BMGame. For anyone familiar with BMGame, the main iterative steps will look very familiar: do_next_step() and update_tournament_state(), which are run inside proceed_to_next_user_action(). The logic moves the tournament through the tournament states specified in BMTournamentState:
  • START_TOURNAMENT
  • JOIN_TOURNAMENT
  • SHUFFLE_PLAYERS
  • START_ROUND
  • PLAY_GAMES
  • END_ROUND
  • END_TOURNAMENT
  • (CANCELLED)

The abstract functions are the ones that need to be customised in different tournament types, as described in the previous post.

BMInterfaceTournament supports the creation and updating of the database state of tournaments.

Comments

Post a Comment

Popular posts from this blog

The thorny interaction between konstant and fire

Those who have been on the site for a while will know that there are quite a few buttons that are not yet playable. Mostly, this is because a die or button skill hasn't yet been implemented. But sometimes, the reasons are more subtle. Two of the US States buttons, Arizona [k(7) g(9) (12) F(15) (X)] and Hawaii [n(4) m(5) k(8) F(13) d(Y)] have been disabled for the entirety of the time that most of the other US States buttons have been playable, since January 2016. And on a first glance, it would appear that these buttons should have been enabled for play, since all the component die skills were already implemented at the time. The story really starts in September 2015, when devious and irilyth found a konstant bug while testing the button Hawaii on the dev testing site. It turned out to be caused by the underlying code not correctly determining whether an attack involving konstant requires fire support. I submitted a fix for this, and as usual, Chaos ran her automated testing bot o...
Read more

Phases of a turn

One of the first times I really thought about game states in a game was when I was learning Magic: the Gathering. There, it can be really important to know which phase of the turn is currently occurring, so much so that sometimes, you need to explicitly say things like "I'm beginning my upkeep phase" or "I'm about to end my main phase", so that opponents were given the opportunity to react during that phase. When I started working on Button Men, I thought that things would be much simpler, and that turn order wouldn't be nearly as important. Looking at the status of class BMGameState in July 2013, many of the game states were already present: startGame applyHandicaps chooseAuxiliaryDice loadDiceIntoButtons addAvailableDiceToGame specifyDice determineInitiative startRound startTurn endTurn endRound endGame Interestingly, we haven't yet used the game state set aside for allowing a handicapped game, it's just there as a placeholde...
Read more

Why PHP? A brief history of the resurrection of Button Men Online

For anyone who knows anything about web development, it may seem odd that we are using PHP for our back-end, especially since we made the decision in 2012, when there were many other feasible languages available. Here is the story of how we started out, and how we incidentally ended up being stuck with PHP. 12 Nov 2012 I broached the subject of resurrecting the Button Men Online site on the  Buttonmen Site Outage News  group, after nine months of downtime of the old site. One of the things that I left open was the choice of programming languages. 13 Nov 2012 After getting a bit of interest, I posted a suggestion on November 13 that we go with Python and PostgreSQL. Brooks chimes in that he is a Zend certified PHP developer, and suggests that Python frameworks may not be as robust as the Apache backend, and that the Apache backend is more widely supported on cloud architecture. He also mentions Pagodabox, which he uses for his PHP projects. Chaos posts that she knows Pyt...
Read more