CHaser 大会の進行（対戦順・スコア・配信画面）は、これまでスプレッドシートによる人力運用で行われていた。 スコアの集計ミス、配信スライドのその場作成、進行担当の負荷集中が慢性的な課題となっている。
CHroS はこれを一部または全部自動化し、大会運営の人的負担を減らすことを目的とする。
一度に全体を作ると設計が破綻するため、以下の2ドメインに分離して設計・実装し、最終的に統合する。
| ドメイン | 責務 |
|---|---|
| スコア管理 | 参加者・対戦・得点の登録と集計、順位計算 |
| 画面管理 | 配信に載せる画面の切り替えと、進行状況に同期した表示 |
両者は「現在の大会進行状態」を共有する。統合時はこの状態モデルが接続点になる。
- 得点管理
- 対戦順管理
- 得点表示
- 対戦順表示
- 対戦状況表示
スプレッドシートで管理されていたものを、このシステムで管理できるようにする。
- 参加者の登録・編集
- 対戦ごとの前半/後半のスコア入力
- 勝敗判定（得点、PUT、通信切断などの条件を含む）
- 入力ミスの訂正（履歴が追える形で）
釧路大会は他大会と比べてスコア計算が複雑であり、規則は大会ごとに異なる。 計算式をシステムに固定すると、規則が変わるたびにエンジニアの改修が必要になり、可搬性を失う。
したがって、計算式を外部から与えられるデータとして扱うことを本システムの核とする。
- 計算式は非エンジニア（大会運営）が編集できること
- 曖昧な状態のまま大会に適用されないよう、検証の仕組みを持つこと
- どの規則で算出した結果なのかが、後から辿れること
編集手段は「コードを書かせる」形を採らない。どんな言語であっても非エンジニアには負担が大きいため、 ノードを繋いで組み立てる方式とする。実装方針は 技術要件 §1.2 / §5 を参照。
スプレッドシートで管理されていたものを、このシステムで管理できるようにする。
- 総当たり戦 / トーナメントの対戦表生成
- 現在の対戦、次の対戦の管理
- 進行状態（未実施 / 進行中 / 完了）の遷移
各対戦で、最終的に誰が何点取り、どのような勝ち方をしたかなどを一覧で表示する。 従来はスプレッドシートのデータをもとにその場でスライドを作成していたため、 得点管理から表示までをシステムで一元的に行う。
総当たり戦やトーナメントなど、一目で見て理解できるリッチな UI を作成する。
以下の内容を一目で理解できる UI を作成する。
- 誰と誰が戦っているか
- 前半戦ではどちらが何点取ったか
- どちらの方が有利 / 不利か
- 最終的な勝者はどちらか
| ロール | 画面 | 用途 |
|---|---|---|
| 運営（進行・記録） | Console | データ入力、画面切り替え操作 |
| 視聴者（配信越し） | Display (Viewer) | 配信に載る表示専用画面。操作は行わない |
Viewer はサーバーの状態に追従して表示を変えるだけであり、Viewer からサーバーへの入力は発生しない。 この非対称性が通信方式の選定根拠になる（技術要件 参照）。
- 同時接続数: 数十程度（運営端末数台 + 配信用ブラウザ数枚）。大規模スケールは不要。
- 可用性: 大会当日の数時間、無停止で動けばよい。ただし配信中の再起動は許容できないため、Viewer は再接続で自動復帰すること。
- ネットワーク: 会場 LAN での運用を前提とする。インターネット接続が不安定でも動作すること。
- セキュリティ: 認証・権限管理は設けない。会場 LAN 内に閉じた運用を前提とした 意図的な判断であり、前提が変わる場合は再検討する（技術要件 §1.3）。
- データ: 大会終了後にスコアを永続的に参照できること（後日の記録公開に使う）。
- 再現性: 過去の対戦結果は、当時適用した計算規則とともに再現できること。
- 自動抽選システム: 対戦組み合わせの自動生成。データ設計の段階で、 抽選結果を後から流し込める形にしておく。