Define the occupied interval
A match is not a point on a calendar. It occupies a period, and that period may differ for each resource. Players may need a check-in window before the advertised start. A referee may need to review settings. A room may remain unavailable after play ends because equipment must be reset. Represent these intervals separately where they matter. Otherwise, a solver can return a schedule that looks tidy while requiring a person or station to be in two places at once.
Start with a match list, a resource list and a dependency list. Give every item a stable identifier. A display name can change; the identifier should not. Record the source and approval owner for each rule so later revisions do not depend on someone remembering an informal conversation.
Make mandatory rules explicit
Hard constraints define feasibility. Typical examples include no overlapping appearances for a team, no double-booked station, an enforced minimum rest interval and access restricted to a venue’s opening hours. Match precedence is another hard rule: a final cannot start before its participants are determined and any required preparation interval has passed. Treat shared substitute players and coaching restrictions according to the actual competition rules, not an assumption that every team roster is independent.
A mandatory rule needs a measurable test. “Keep the evening manageable” is not testable. “All occupied room intervals must end by 21:00” is. If a rule has exceptions, document who can authorize them and whether permission must exist before publication.
Keep preferences in a separate register
Soft constraints express desirable outcomes: fewer room changes, more balanced early starts, a preferred broadcast window or a shorter overall day. Violating one can be acceptable, but the cost must be visible. Do not assign arbitrary weights and assume the result expresses policy. A large collection of small preferences can outweigh one important preference unless priorities are structured deliberately.
A useful approach is a priority sequence. First find a feasible schedule. Then minimize severe rest imbalance. Next reduce disruptive room transfers. Finally improve presentation preferences. Weighted objectives can also work, but inspect examples with stakeholders so they understand what one penalty is allowed to trade against another.
Represent uncertainty honestly
Match duration varies with the title, format, pauses and technical conditions. A best-of-three series in Counter-Strike 2 has a different duration structure from a single Rocket League game. League of Legends and VALORANT also have their own operational assumptions. These are reasons to collect relevant event evidence, not reasons to insert a universal duration into every model.
Use a documented planning duration, then test longer cases. Distinguish expected playing time from a reserved slot and from a worst-case operational scenario. If the venue cannot accommodate any credible overrun, the issue is a capacity risk, not something that disappears when the average duration fits.
Test the model before judging the timetable
A solver can only enforce what was encoded. Check the result independently against the source rules. In small events, a spreadsheet audit may be sufficient. Larger events may use constraint programming or mixed-integer optimization. Google OR-Tools provides examples of resource and sequencing models, but software choice does not replace correct event policy.
When no feasible schedule is found, distinguish a proven contradiction from a search that ended without a solution. Under a time limit, “no solution found” does not necessarily mean “impossible.” Review the smallest conflicting set you can identify: a player’s arrival window, a required predecessor and a room closure may already explain the blockage.
Use a small, inspectable example
The hypothetical example below is intentionally narrow. The room is available from 14:00 to 15:00, and the occupied match interval is assumed to require 60 minutes. A 14:00 start appears to fit, but the predecessor has not yet finished. A 14:30 start respects precedence and then exceeds room availability. Something outside the start-time choice must change.
| Candidate | Player window | Predecessor ready | Room clear by 15:00 |
|---|---|---|---|
| 14:00–15:00 | Pass, subject to check-in | Fail: ready at 14:30 | Pass |
| 14:30–15:30 | Pass | Pass | Fail |
Publish assumptions with the decision
Possible repairs include securing a later room, changing the earlier round or confirming a different availability window. Each repair needs authority and a fresh feasibility check. Reducing the reserved duration without evidence is not a neutral repair; it transfers risk into the live event. Keep the original assumptions, the approved change and the resulting timetable version together.
Before publication, ask another coordinator to explain why the schedule is feasible using only the written rules. If they need private context, the operating document is incomplete. The next step is not more automation. It is a clearer model that administrators, teams and venue staff can all interpret consistently.