Creating a sports schedule programmatically is done in three steps. First, parameters are developed by the client with the aid of the programmer. Then the programmer develops a model that reflects those parameters. Lastly the model is input to an application that employs sophisticated algorithms to solve the model and produce a schedule. In practice, the programmer models and solves iteratively until the schedule is complete and satisfactory. If during that process it becomes clear that a satisfactory schedule can't be produced due to incompatible parameters, those parameters are modified with the input of the client, and the overall process begins again.
The first step in building a sports schedule programmatically is putting together a specification. This begins with the client presenting a list of needs for the schedule(s). The programmer will then work with the client to clarify and complete a list of parameters for the project.
The parameters, once finalized, will be transformed into constraints, the mathematical code that makes up the model that describes a schedule to the computer. Common examples of parameters include minimizing streaks of home or away games, minimizing travel during weekdays, and reversing venues from the previous season. Other parameters describe the teams, dates, and mileage between venues. A more extensive list of parameters tied to specific kinds of schedules can be found here.
Modeling a sports schedule involves formatting input from the client such as teams and dates, converting parameters to into constraints, and formatting output that the solver application provides. Writing constraints, though, is the most important aspect of the process.
Constraints are mathematical statements that are the essence of the model. They dictate the features and boundaries of the schedule. In models of sports schedules, there are often one or two thousand of them. Programming all of those constraints individually would be a long, tedious process, but there is an alternative - writing constraint families. A constraint family acts like a template for a set of related constraints. To build a model is to program a series of those templates that in turn produce many constraints on behalf of the programmer. Often, one parameter in the specification for the schedule corresponds to one or two of these constraint families.
Once a model is built, the next step is to solve it.
Models are turned into schedules with any of a variety of solver applications. Some are very mathematical in nature. Others derive their capabilities from computer science. Regardless of the kind of solver employed, it will read the model and spend seconds, minutes, or even hours computing a solution which is then output in a format specified by the programmer.
Obtaining a solution form the solver is not guaranteed, however. There are two ways for a solver to fail. The first is called infeasibility which means that the parameters supplied by the client are mutually incompatible. In that case, finding a solution that meets all of the parameters is mathematically impossible. The second way to fail I'll refer to as unmanageability. This occurs when a model has so many variables that the solver can't finish in any reasonable amount of time. It could take years or even centuries to solve an unmanageable model assuming the computer would not run out of memory first.
If solving fails, the programmer will have to rework the model. Sometimes this involves changing or dropping parameters which is done with the input of the client. Occasionally reformulating the model for a different solver can fix the issue without having to compromise any parameters.
If you have questions regarding the process of building a sports schedule that you have in mind, please contact me.