Game

Games, like Teams, should be simple objects that are easily representable in the DataStore. In general, a Game specifies a collection of Teams that are competing against each other in a within a Tournament. In this sense, a Game can be identified with the Wikipedia definition of "fixture". The NCAA men's basketball championship tournament has a single-elimination, single-match, head-to-head format, so the Game object specifies both the fixture and the single "leg" within the fixture.

Games also hold static information about the fixture, such as when the legs of the fixture are played, the venue for the legs, and so on. Optionally, the Game could also hold dynamic information about the fixture, such as the score of the legs, time remaining in the legs, the outcome of the fixture, etc..

Discussion

Game as a virtual parent class

In general, a Tournament does not need to follow the NCAA men's basketball championship tournament format of single-elimination, single-match, head-to-head. Some different tournament formats lead to different definitions of what a Game is. For example:

• Round-robin: in this type of tournament, every team plays every other team at least once, and the winner is the team with the most wins after all legs have been played. This format has a single fixture, so each leg would be considered a Game.
• Grouped round-robin: in this type, teams are grouped together into more than one fixture, and within each fixture, all teams play each other at least once. This format has multiple fixtures with multiple legs within each fixture. Each fixture could be considered a Game, with the team records at the end of the round-robin legs determining who wins.
• Head-to-head, best-of-N matches: in this type of tournament, teams are matched together head-to-head in each fixture, but multiple legs are played between these two teams to determine who is the winner of the Game.
• Hybrid: each round or each fixture of a tournament could compete in a different format, leading to a hybrid tournament type where the games do not strictly follow any of the above conventions uniformly.

For this reason, a generic tournament management and simulation application, like what braket-o-matic strives to be, should be able to handle all of these types of games. One way to do this would be to make the Game class generic enough to deal with any of these eventualities. Another way would be to make Game a parent class (or interface) for child classes that handle the specifics of the game types. An example hierarchy could look like this:

• Game
• RoundRobinGame
• HeadToHeadGame

The Tournament class could then be used to differentiate elimination types.