Competition Software

At the competition, we like to have various bits of software to help us run things. Currently this is provided by the SRComp suite.

History

This page relates to the actual running of the competition. For other related ideas, see CompetitionProjects.

In the past, this has been called compd, but we're moving away from this, as there doesn't appear to be a compelling reason for it to be all-encompassing, or to be a daemon.

For SR2013, we ended up using poltergeist.git as the core piece, which, despite still being developed on the day before, was possibly the most ready piece of competition software we've had, and now provides a solid core we can build upon.

These requirements have previously been discussed in the thread Competition Software, and others linked inline below. As of 2016 they fall under the remit of the Competition Software Coordinator, with many of the aims being prescribed by the ops-manual.

From SR2014, we have used the SRComp suite of systems. This provided most of the requirements this page detailed (at the time), and showed issues in the specifications.

Definition of terms

• publicly visible: Visible to anyone that happens to want to see it, presented in a manner that is easy to consume. In general, this means that the data should be available on our website.

• game score: Points earned from either actions or state of game-play in a given match, also a total of all such points earned. These are calculated based on the rules of the game for the year.

• league points: Points earned from the ranked position earned in a league match, also a total of all such points earned. These are calculated based on the objective of keeping all matches worth the same total points. The calculation method is in the rules, and an implementation exists at ranker.git.

• shepherds: People who fetch teams for their upcoming matches.

• shepherding area: An area within the venue which a given shepherd is responsible for.

Features

This is a list of requirements based on the features that were present in the SR2016 competition software, as well as links to where each is implemented. This list is not expected to form a single piece of software, rather it should form the basis of a suite that has a common user experience, and can inter-operate.

Match Scheduler

• Teams must have gaps between any arena appearances. In the past we've required a two-match gap (ie, two non-entry matches between appearances), though this should be considered a bare minimum.
• Teams must have their matches spread throughout the league.
• All teams (that make it to the competition) must be scheduled matches.
• The number of matches that teams have must have a maximum variance of 1 match.
• Must support multiple arenas
• The output format must be a standard format, ideally one that is readable by both humans and computers. The current scripts use one line per match, with pipe characters '|' separating entrants represented as TLAs, this seems suitable to stick with. Since currently all matches start at the same time, support for multiple arenas is done by having all competitors on the same line, pipe separated, and then chopping the line into groups of four entries when loaded.
• Teams should face as many other teams as possible.
• Teams should not face the same team in more than half of their matches. (Can we improve on half -- is it possible to get this down to a quarter?)
• The schedule may be balanced such that a chunk of matches can be dropped due to a time constraint without biasing the league.
• The output may be reproducible. (This makes debugging easier.)
• Each team's appearances must be well distributed across all zones and arenas. (It may be that there are subtle advantages or disadvantages to being in one particular location.)
• Currently Being Discussed on the list Matches must be scheduled in rounds. A round is a block of matches that contains all teams exactly once.

For 2014-2016 schedules based on those from 2014 have been used. These are currently stored at https://github.com/PeterJCLaw/srobo-schedules.

Publicly Accessible Match Schedule

A publicly visible display of the match schedule.

• Including team TLAs, match ids & times.
• It must shown which arena and zone a team is in.
• Must be able to be adjusted for delays that occur on the day.
• For the league stage:
• Should include team names.
• Could link to more info about the teams.
• For the knockout stage:
• Must update with placings as the matches occur.
• A full listing must be available.
• An up-next listing (next 10 matches or so) may be available.

Currently implemented at comp/schedule and the outside.html page within srcomp-screens.git.

Publicly Accessible Match Schedule for a Given Team

A publicly visible display of the match schedule for a given team.

• Must comply with the schedule requirements above, except that:
• It must only include the matches that the team is in
• It could highlight the next match the team is in

Currently implemented at comp/team, though also at comp/schedule.

Team Location Display

A display of where teams are located within the venue.

• Must include all teams.
• Must be physically portable. (It is expected to be use by people running around).
• May be arranged by team, rather than location. (It is expected to be used by people searching for teams).
• May be colour-coded by location.

Currently implemented by the floorplans.git repository which has folders for each year. PDFs are generated then printed for those in the venue and linked on the website.

Currently this is not arranged by team, though the venue is broken into smaller shepherding areas reducing the amount of searching a single shepherd has to do.

Portable Schedule with Team Locations

A display the locations of teams overlaid onto the schedule. This is expected to be used by the shepherds.

• Must include all matches.
• Must be physically portable. (It is expected to be use by people running around).
• Should be colour-coded by location.

Currently implemented by the print-schedule command from srcomp-cli.git. Various PDFs are generated to support the Shepherds and printed on the day.

Shepherds Timing Display

A display for use by the shepherd in charge of timings:

• Must show the teams for the current and upcoming matches
• Should show the previous match's allocations
• The differences between the previous, current and upcoming matches Must be clear
• Must be colour-coded to match the shepherding areas within the venue
• Must show when the staging closes for each match
• Must have a status field which issues instructions when key events occur:

• Teams should be fetched for a given match
• This should be broken down into shepherding areas if they are different distances from the arenas
• Staging opens for a given match
• Staging closes for a given match

Currently implemented by the shepherding.html page within srcomp-screens.git

Staging Area Display

A display in the staging area:

• Must show the teams' arena and corner allocations for the current and upcoming matches
• Should show the previous match's allocations
• The differences between the previous, current and upcoming matches Must be clear
• Must be colour-coded to match the arena corners
• Must show when the staging opens & closes and when the match starts for each match

Currently implemented by the staging.html page within srcomp-screens.git

Arena Corner Display

A display in each corner of each arena.

• Must show the team in that corner
• Must show the time remaining in the current match
• If not current match then Must show the time to the next match
• Should show the colour coding for the given corner
• May show the teams in the other corners (clearly separated)

Currently implemented by the arena.html page within srcomp-screens.git

League Point Scoreboard

A publicly visible display of the league points.

• Must show the most recent match id that the points include.
• Must list teams in points order.
• Must show the cut-off line, below which teams will not be entered into the knockout.
• Should show tied positions.
• Should remain up-to-date with the scores available to the system (ie, clearly it can't do anything about a delay in entering the data).
• A full listing must be available.
• An top 10 (or so) listing may be available.

Currently implemented at comp/league.

Match Scoreboard

A publicly visible display of the game scores.

• Must allow teams to see how many game scores they scored from each match they competed in.

Currently implemented at comp/points and comp/team.

Game Points Scoreboard

A publicly visible summary of the game scores.

• Must show the most recent match id that the points include.
• Must list teams in team order (this view is expected to be used when resolving ties).
• Should show tied positions.
• Should remain up-to-date with the scores available to the system (ie, clearly it can't do anything about a delay in entering the data).
• A full listing must be available.
• An top 10 (or so) listing may be available.

Currently implemented via a combination of comp/league and comp/points.

Scoring Data Backup

A redundant copy of the scoring data.

• Scores should be stored in a format that can easily be cloned en-masse from one device to another for backup & scrutiny.
• Said format should be easily readable by both humans and computers.
• If the system includes its own database, it must be able to import this data from fresh.

Competition state information (which includes scoring data) is currently stored in fresh git repository for each year. The competition software includes validation checks and deployment mechanisms for this repository.

Score Entry System

A game score entry system.

• Must be possible to enter detailed game scores for each entered team (Eg: points for movement, points for collection of blocks, etc.)
• Must be able to render the entered scores in a form which looks like the score sheets (for easy input checking).
• Must be able to mark which teams were in the match (even when those teams were not scheduled to appear).
• Must be possible to mark a team as disqualified from the match.
• Should provide an entry form which looks like the score sheets (for ease of entry).
• May verify that the teams for which scores have been entered were in the given match.

Currently implemented by srcomp-scorer.

Score Checker

A mechanism to check the entered scores.

• Must check that only teams in a given match are awarded either a score or league points for the match.
• Must check that all teams scheduled for a given match are awarded either a score and league points for the match. (Even if those scores/points are 0).
• Must show matches that are missing scores
• Must show complete results on every run (ie, can't just bomb at the first check-fail).
• Should show missing or extra teams in any matches that fail the above checks.

Currently implemented by srcomp-scorer and the validate command of srcomp-cli.git.

Public API

A public API for accessing scores and the match schedule (Allowing volunteers, competitors, etc. to do neat hacks)

• Should be Javascript compatible
• A mechanism for determining what the current competition state is -- i.e. are we currently playing game N, or between matches?

Currently implemented by srcomp-http.