イベント作成から公開まで
admin action
→
WebCoopSpark route
→
WebCoopHandlers / EventService
→
Db / Migrations
→
WebPages render
→
browser update
管理画面から見える変更は、route・handler・service・DB・ページ描画の 5 層を跨ぎます。フォーム項目追加時も同じ縦列を揃える必要があります。
イベント進行 / WebCoopEvent サブシステム
ゲーム内イベントと WebCoop の両輪を横断し、管理画面・チャット・参加処理・配点/報酬・Web表示がどう連携するかをまとめています。
このページは手書き密度を上げたサブシステム解説です。 クラス単体の一覧では見えにくい、モジュール横断の処理遷移を図と文章で読めるようにしています。
関連クラス
読むときの姿勢
- まず図で境界を把握する
- 次に関連クラスの章立て解説へ降りる
- 最後にメソッド詳細で個別実装を確認する
サブシステム解説
役割分担
ゲーム内の実ランタイム集計は EventRuntimeService 側が強く、WebCoop 側はイベントの Web 公開・参加管理・チャット・ページ生成の責務が濃いです。似た名前でも「ゲームの現在状態」と「Web 協力イベントの公開面」は別の重心を持っています。
読み方
まず EventRuntimeService のテーブル整備とランタイム更新を見て、その後に WebCoopSpark がどの route をどの handler / service へ流すかを読むと、ゲーム内と Web の接点が掴みやすくなります。
モジュール横断の処理遷移図
ゲーム内進行と Web 表示の接続
Bukkit side event
→
EventRuntimeService
→
score / payout state
→
WebDataServer / WebCoop page read
→
browser
補助
→
ChatRelayService
→
EventScheduler
ゲーム内の現在状態は runtime 側が主で、Web はそれを読む側です。Web だけ直しても集計が変わらない場合は runtime 側へ戻る必要があります。
チャット・参加者操作の流れ
browser post
→
auth / session check
→
ChatRelayService or EventService
→
DB / relay
→
Minecraft / browser 反映
WebCoop は読むだけでなく双方向操作が入るため、認証と relay の境界が壊れやすいです。参加操作やチャットが効かないときはまずこの列で止まる位置を見ます。
変更時の注意点
- EventRuntimeService と WebCoop の責務を混ぜると保守が難しくなります。ゲーム内状態の真実源がどこかを固定して読むのが大事です。
- Web 側のフォームや API 項目を増やす時は WebPages だけでなく handler / service / DB を一緒に更新しないと表示だけ変わって保存されません。