Event共通ルール・大会進行仕様案
部長2026年8月16日 (9日前) 更新
コメント
この記事ではコメントを受け付けていません。
ページを読み込んでいます。
ページを読み込んでいます。
この記事ではコメントを受け付けていません。
このページは開発用資料です。「ダゴンさまとこんなことを相談しながら仕組みを作っています」というもので、確定した仕様ではありません。どの機能もだいたいこんな風な文書を作りながら開発しています。
確定仕様ではないので、この文書を直接参照して「ここに書いてあったから、そう処理します」という扱いはしないでください。今はただのメモ、チラシの裏に過ぎません。今のところはリーグ戦のルールタブ、もしくはらくらく式をご覧ください。ここに書いてある内容は、まだ適用範囲外とします。
内部語出まくりなので読みにくいと思いますが、ルールや大会仕様についてツッコミ所を探すのが好きな方におかれましては「こういう時はどうなの？」とご指摘いただけると助かります。
おそらくこれを材料に検討を進めて決めた内容が、今後のセプト部のスタンダードな大会仕様になっていくと思います。
カルドセプト部の大会機能は、League / Cup / Tour / Fest / Meet等でCompetition Contextを中心とした共通基盤を利用する。
Eventのルール表示についても、Event種別ごとに独立した文章入力機能を作るのではなく、既存の大会設定・競技設定・運営設定を正本として利用するEvent共通基盤を設ける。
本仕様では、以下を定める。
Leagueを最初の適用・検証対象とするが、原則としてEvent共通基盤として設計する。
Event Rulesは、大会設定そのものをもう一式保存する場所ではない。
現在すでに正本が存在する以下の情報は、既存の正本を参照して参加者向け文章を生成する。
Event Rulesが新たに保持するのは、既存の正本が存在しないEvent固有policyと、公開ルールのversion管理を中心とする。
以下は別の責務として扱う。
大会設定
大会運営
ルール表示
全文自由入力を選択しても、大会設定や自動運営機能は無効にしない。
Eventごとに次の3方式から選択する。
標準方式。
構造化されたEvent設定・既存runtime policy・Event Rules policyから、参加者向けルール文章を自動生成する。
自動生成されたルールを表示したうえで、主催者が補足文章を追加できる。
自動生成部分と補足部分は責務を分離する。
自動生成されたルール本文を公開面には表示せず、主催者が用意した文章を表示する。
ただし、ranking、締切、進出、切断policy等の構造化設定は通常どおり有効であり、システムによる大会運営にも使用する。
「文章を自分の言葉で書く」ことと「大会を手動運営する」ことは別である。
Event Rulesはversion管理する。
下書き中は自由に編集できる。
Event公開時に、公開時点のRules Versionを確定する。
公開後に変更した場合、既存versionを書き換えず、新versionを作る。
Event開始後に変更した場合は、
変更後に新しく開始するMatchから新versionを適用する。
すでに開始済みのMatchは、開始時点のeffective rules versionを維持する。
過去Matchへルール変更を遡及適用しない。
Event終了後の訂正は、過去versionを書き換えるのではなく、監査可能な訂正・注記として扱う。
Event設定で次の5方式から選択する。
標準の「4R以内再戦、5R以降継続」では、
とする。
2回目の切断、または5R以降に切断した参加者は、その対戦に復帰しない。
標準では、再戦policyによって再戦となる場合を除き、全員が同意すれば再戦できる。
再戦しない場合は対戦中断として扱う。
標準では、
とする。
既存のBook submission / Match Book snapshotを正本として利用し、同じ情報をEvent Rulesへ二重保存しない。
2回目の切断、または5R以降の切断により、その対戦に復帰しないことが確定した参加者は、操作エリアから切断報告を行える。
切断報告後も元卓の参加記録は保持するが、元卓の結果確定を待たず、
できる。
実際に別卓へ参加・作成した後は、元卓の切断報告を取り消せない。
切断者については、代理操作したCPUの順位・総魔力等を対戦結果として記録し、切断事実を別途記録する。
ranking上の切断時得点等はEventのranking ruleを正本とする。
選択式にしないEvent共通policyとする。
バグによって参加者に有利・不利が生じても、対戦が継続している場合はそのまま続行する。
ゲーム中に発生したバグはゲームの仕様として扱う。
選択式にしない。
実際のResult Reviewおよび結果訂正機能を正本として、現在利用可能な訂正手順をルールへ表示する。
文章用の独立した結果訂正設定は作らない。
Eventごとの選択式にはせず、共通policyとする。
現在の基本方針は以下。
卓チャットの追加マナー施策については、現在のplaceholder
やさしい言葉で話しましょう。
で一旦完了とし、本仕様で追加施策は設けない。
Event設定で次の3方式から選択する。
「参加者全員の許可が必要」の場合、1人でも反対すれば配信できない。拒否理由の説明は不要。
「配信可能」の場合、個別許可は不要。ただし対戦開始前に卓の動画登録へ配信を登録し、それを参加者への告知とする。
Eventを公開する主催者には、通常Accountより一段高い連絡可能性を求める。
次の少なくとも一方が直近30日以内に有効であることを公開条件とする。
両方無効の場合、
とする。
これはAccount Tierや信用評価とは別の「主催者として連絡可能か」という資格である。
正常なXログインを有効性確認として扱う。
正常にXログインするたび、有効期限をその時点から30日延長する。
確認メールの受信確認から30日間有効とする。
通常ログインだけでは延長しない。
メールアドレスを変更した場合は、新しいメールについて再確認を必要とする。
有効な、
から選択する。
両方有効なら2択。
片方だけ有効ならその方法に固定し、もう一方をdisabledとする。
メールを選択した場合、メールアドレス自体は公開しない。ルール欄に簡易問い合わせフォームを表示し、サイトから主催者の登録メールへ送信する。
master開催のLeagueのみ例外とし、問い合わせ先はXの @weathering に固定する。
成績集計はEvent Rules独自の計算実装を持たず、既存のranking基盤を正本とする。
Event Rulesは、Eventで設定されている集計方式・成績要素・順位決定方法を参加者向けに説明する。
現在のrankingで正式に利用できる成績要素は次の11種類である。
「魔力」という曖昧な名称は使用しない。
以下を明確に区別する。
魔力点は現行実装では、各試合について概ね
自分の総魔力 − 1位の総魔力 ＋ 目標魔力
を基礎とし、0から目標魔力の範囲へ収めて算出する。
順位表では、Eventで指定されたranking columnを順番に比較する。
最初の列を主たる順位要素とし、それ以降の列を順番にtie-breakとして使用する。
設定された正式な比較要素がすべて同一の場合は同順位を認める。
一方、次Blockへの進出者選抜など、一意の順序が必要な場合にはadvancement用の比較規則を使用する。
順位表のtie-breakとadvancementのtie-breakは同一の仕組みではないため、Event Rulesでも混同して説明しない。
順位ごとのpoint tableを設定できる。
同着の場合は、同着者が占有する順位枠のポイントを平均する。
切断時のポイント処理もranking ruleを正本とする。
Event Rules側へ同じpoint tableを複製保存しない。
集計対象となった全試合の順位ポイント等を合計して成績を決める方式を利用できる。
最良連戦は、
成績の良い任意のN試合を拾い集める方式
ではない。
同一Block内で、時系列上連続するX試合を1つの窓として比較し、その中から最も良い連戦区間を採用する。
現行実装では、最良窓そのものを選択する際の基準点として、
の固定値を使用する。
これはEventごとのpoint tableとは別である。
同点の窓が複数ある場合は、
の順で決定する。
最良連戦の対象として現在backendが扱える成績要素は、
である。
ただし切断数については、backendは対応済みだが、現行frontendの型・設定UIには未接続部分がある。
単独勝利数を基礎として、
○勝に到達した
という規定勝利数方式を利用できる。
規定勝利数そのものは独立したranking成績列ではなく、単独勝利数に対するthresholdである。
内部実装では星の現在値をrankingの points へ投影するが、参加者向けには独立した「星方式」として扱う。
Event開始時に星を持ち、試合結果に応じて星が増減する。
利用者に対して「ポイント方式」と表現するのではなく、そのEventが星制度を採用している場合は、
星方式
として明確に表示する。
内部保存形式を理由に、利用者向けのルール表現まで「ポイント」と統一しない。
トーナメント等では、ポイントを集計せず、Matchの勝敗・advancementだけを使用する方式も選択できる。
これも成績要素ではなく、集計方式の一つである。
ボーナス点は独立して確認できるが、最終的な順位ポイントにはすでに加算されている。
そのため、順位ポイントとボーナス点を同時にranking比較へ使用する場合は、同じ加算要素を二重に評価するような設定にならないよう注意する。
以下は現在の正式ranking要素には未実装だが、過去の大会で使用された実績があり、必要になった場合に実装を検討する候補として残す。
2〜4位でゲームを終了し、その試合の総魔力が、
目標魔力 − 1000以上
だった場合を「惜敗」とする。
惜しくも勝利へ届かなかった参加者に対して、わずかな加点を行う制度として利用することを想定する。
将来実装する場合は、
をranking ruleの設定候補として検討する。
2〜4位でゲームを終了し、その試合の総魔力が、
目標魔力 − 5000以下
だった場合を「惨敗」とする。
大きく負けた参加者へ、わずかな減点を行う制度として利用することを想定する。
将来実装する場合は、
をranking ruleの設定候補として検討する。
惜敗・惨敗はいずれも、現時点では実装済み機能として扱わない。
過去資料で不採用扱いとなっていた場合でも、本仕様ではその裁定を引き継がず、
過去に採用実績があり、必要に応じて再実装を検討できる候補
として位置づける。
Blockは独立した競技フェーズである。
例:
Blockごとにranking、Stage、Condition、operation settings、advancement等を持てる。
StageはBlock内の進行単位。
例:
開始・締切・進行方式・Match等を管理する。
進出は、
ranking snapshot
→ advancement candidate
→ eligibility
→ decision
→ 次Block / Stageへのentry
という既存責務を利用する。
Event Rulesは進出結果そのものを保存しない。
標準の総合順位では、予選順位を基礎とする。
後続Blockへ出場したという事実だけでは総合順位を上げない。
後続Blockで最下位ではない順位を獲得した場合、その順位に相当する競技結果を示したものとして総合順位へ反映する。
後続Blockで最下位だった場合は、出場した事実だけでは昇格させず、それ以前の順位関係へ戻す。
他の参加者が後続Blockの結果によって昇格すれば、その分だけ順位番号は後ろへ動く。
これは、参加可能性による繰り上げと競技実績による昇格を区別するための考え方である。
決勝進出者全員を自動的に非進出者より上位にする方式は標準としない。
現行 final_non_last_promotes がこの思想を実装している。
長期間の予選と、特定時刻に集合する決勝Blockを組み合わせる大会では、予選成績だけで出場者を確定しない。
予定変更・辞退・当日欠席等を考慮し、事前に参加意思を取得する。
予選で1戦以上した参加者は、予選期間中から回答・変更できる。
標準の回答締切は決勝Block開始1時間前。
ただしEvent設定で変更可能とし、予選終了時・予選終了直後等も指定できる。
リザーバーのみ希望する選択肢は設けない。
「今回は参加しない」を選択した場合、この質問はdisabledとする。
標準的な4人戦・16人制では、
を選ぶ。
選抜には予選成績を使用する。
準決勝出場者16名は、質問Aで準決勝への参加が可能と回答した参加者のうち、まず積極参加希望者を予選成績順に採用し、16名に満たない場合に限り、協力可能者を予選成績順で追加する。
同点の場合はEventのranking tie-breakを使用し、それでも同一なら抽選する。
リザーバー最大8名は、質問Aで「準決勝でもリザーバーでも参加できる」を選択し、準決勝出場者に選ばれなかった参加者のうち、まず積極参加希望者を予選成績順に採用し、8名に満たない場合に限り、協力可能者を予選成績順で追加する。
質問Aで「準決勝に出場できる場合のみ参加したい」を選択した参加者は、準決勝出場者16名から外れた場合、リザーバー候補には含めない。
チェックインは、
まもなく対戦を開始できる状態で待機していることの表明
である。
単なる事前参加表明ではない。
標準では試合開始予定時刻の10分前から受付する。
19:00開始予定を例とする。
正規出場者のみ入室可能。
開始予定時刻までは正規出場者の席を保証する。
が入室可能。
空席は実際にオンラインルームへ入室した者が取得する。
リザーバーが先に席を得た後、遅れてきた正規出場者がその人を追い出すことはできない。
部内Account所持者へ一般開放する。
空席は先着順。
この仕組み自体を事前に参加者へ明示し、遅刻防止を促す。
リザーバーマッチについては正規出場者の席保証がないため、開始予定時刻から一般追加募集を開放してよい。
事前リザーバーが最大8名に満たない場合、決勝集合時刻まで追加募集できる。
追加募集者は予選参加者でなくてもよい。部内Account所持者を対象とし、即時参加可能性を優先する。
追加募集者は、事前リザーバーだけでは人数が足りない場合の補充要員として扱い、必要であれば準決勝の正規欠員にも補充できる。
追加募集段階では予選成績を持たない参加者もいるため、選抜は予選成績ではなく希望者先着順とする。
空席が一般開放された場合はルームIDを対象者へ公開し、実際にオンラインルームへ入室できた者が席を得る。
リザーバーマッチについても、事前リザーバーだけで4人単位の卓を構成できない場合、その場で追加参加者を募集してよい。
ただしリザーバーマッチはサイドイベントであり、何が何でも成立させるものではない。希望者が集まらなければ、不成立としてよい。
リザーバーマッチには二つの目的がある。
第一の正式な目的は、準決勝後に正規決勝の欠員が発生した場合の優先補充候補を決めることである。
第二の目的は、リザーバーとして大会運営に協力するため、出場可能な状態で時間を確保して集まった参加者へ、大会内で意味のある競技機会を提供することである。
正規ルートの進行だけを考えれば、補充が不要になったリザーバーは解散しても大会は成立する。
しかし、協力して集まった参加者を何もせず帰すのではなく、可能であれば単なるフリー対戦ではない、大会内の名誉につながる競技機会を提供する。
そのため、リザーバーマッチと銅賞戦を設ける。
事前リザーバーは最大8名とする。
原則として予選成績順に、
へ割り当てる。
8名残っていれば2卓、4〜7名なら少なくともAの1卓を開催できる。
5〜7名でBが成立しない場合、残った1〜3名のために追加参加者を募集してよい。ただし集まらなければ、その1〜3名は解散としてよい。
リザーバーが最初から1〜3名しかおらず、リザーバーマッチAを開催できない場合、銅賞戦まで1時間以上待つ可能性があることを説明する。
それでも待機して銅賞戦へ参加したいと回答したリザーバーは、全員を銅賞戦候補とする。
これは、リザーバーとして大会運営へ協力してくれた参加者への競技機会を優先するためである。
準決勝とリザーバーマッチの終了後、正規決勝および銅賞戦の候補者を決定する。
ここから先の進出判断は、原則として予選順位ではなく、準決勝およびリザーバーマッチで実際に得た競技結果を使用する。
予選順位の主な役割は、
までとする。
決勝戦および銅賞戦についても、準決勝と同様に開始予定時刻の10分前からチェックインを行う。
これは、準決勝を終えた参加者であっても、その後の決勝・銅賞戦の時刻に実際に参加できるとは限らないためである。
準決勝各卓の1位には、決勝戦へのチェックインを求める。
次のいずれかを回答する。
候補になり得る全員を対象とする。
リザーバーにも同じ選択肢を表示する。
これにより、決勝欠員には協力できるが銅賞戦までは参加できない、といった意思も反映できる。
決勝補充と銅賞戦候補には、共通して次の優先順位を使用する。
実際の選抜では、その用途について参加意思があり、かつチェックイン済みの者だけを候補とする。
同じ区分内で優劣が必要な場合は、そのBlockのranking / advancement用比較項目を利用し、可能な限り順位を確定する。それでも同一なら抽選する。
正規決勝の基本出場者は、準決勝各卓の勝者とする。
決勝前チェックイン等により欠員が発生した場合、前節の優先順位に従って補充する。
リザーバーマッチ勝者は、銅賞戦より正規決勝への補充を優先する。
リザーバーマッチ勝者を使っても決勝人数が不足する場合は、準決勝結果等による次の候補へ進む。
リザーバーが存在しない場合でも、準決勝の未進出者から成績順に補充できる。
決勝へ補充された者は、同時に銅賞戦へは出場しない。
銅賞戦は、通常の意味での「総合3位決定戦」だけを目的とするものではない。
リザーバーとして大会運営へ協力した参加者に、大会内で意味のある競技機会を提供する役割を持つ。
同時に、準決勝で正規決勝へ進めなかった参加者にも追加の競技機会を提供する。
正規決勝とは別ルートで開催し、原則として決勝戦と同時進行する。
原則4名で開催する。
前節の候補優先順位に従い、チェックイン済みかつ銅賞戦参加希望の候補から4名を選ぶ。
通常、リザーバーマッチA/Bがともに成立して両勝者が決勝へ補充されなかった場合は、
などの構成になる。
ただし固定的に「準決勝2位○名」とは定義しない。
チェックイン状況によっては、準決勝3位・4位や、リザーバーマッチ2位以下が出場することもある。
本人たちの相談により、次のいずれかを選べる。
対戦条件を変更した場合は、卓の設定も実際の対戦条件へ変更し、その条件で行った結果を正式な銅賞戦結果として認める。
参加予定者が途中で辞退したい場合、その人だけ抜けてもよい。
2人戦・3人戦等であっても、その対戦の1位を正式な銅賞とする。
4人戦でなかったことを理由に、銅賞の価値を下げない。
資格外参加者は、
銅賞戦という楽しい対戦を成立させるための協力者
として扱う。
資格外参加者またはCPUが勝利しても、
この場合、資格者の最上位者を繰り上げて銅賞とはせず、銅賞該当者なしとする。
資格を持つ参加者が勝利した場合は、通常どおり銅賞とする。
銅賞戦は開催しない。
原則として銅賞該当者なしとする。
ただし、次節のリザーバーマッチ勝者に関する例外を適用する。
リザーバーマッチ勝者は、すでに大会内の正式な競技で勝利している。
その参加者が銅賞戦への参加意思を示したにもかかわらず、他の出場者が集まらず対戦を成立させられなかった場合、それは本人がコントロールできない事情である。
したがって、
場合、銅賞戦を開催せず、その参加者を銅賞として認定する。
最初から候補者が1名しかいなかった場合も、他候補の辞退等によって最終的に1名になった場合も同じ原則を適用する。
一方、1名だけ残った参加者がリザーバーマッチ勝者ではない場合、銅賞該当者なしとする。
参加希望者が0名の場合も銅賞該当者なしとする。
銅賞戦勝者は、単なる別表彰ではなく、正規決勝3位と同格の総合3位として扱う。
したがって、一つのEventで、
の双方が総合3位となり得る。
銅賞戦勝者には、正規決勝3位相当のSeason Pointを付与する。
リザーバーマッチ勝者を対戦なしで銅賞認定した場合も同様とする。
ただし、
は総合順位を変更しない。
正規の予選→準決勝→決勝等については、
後続Blockへ出場しただけでは総合順位を上げず、そこで最下位ではない順位を獲得した場合に、その競技結果を総合順位へ反映する
という標準policyを適用する。
この規則は、
には適用しない。
リザーバーマッチの成績は、決勝補充・銅賞戦進出候補を決めるために使用するが、それ自体で総合順位を変更しない。
銅賞戦について総合順位へ影響するのは勝者のみであり、勝者を明示的に総合3位へ昇格させる。
リザーバーは単なる人数合わせではない。
大会を円滑に進行させるため、
必要になればすぐ出場できる状態で、自分の時間を確保して待機してくれる協力者
である。
補充が必要なければ本来は解散しても大会は成立する。
しかし、せっかく協力して集まった参加者を何もせず帰すのではなく、可能であれば大会内で意味のある競技機会を提供する。
単なる対戦であればフリー対戦で十分であるため、リザーバーマッチには、
という大会内の意味を持たせる。
ただし、この目的のために大会進行を無理に止めたり、参加者を何が何でも集めたりはしない。
成立しない場合は不成立・解散を許容する。
Eventは通常、構造化設定に従ってシステムが進行・集計を支援する。
一方、特殊な大会や想定外の状況へ対応できるよう、必要な箇所について主催者による手動操作も認める。
手動操作を行っても、
を黙って書き換えない。
必要なoverrideは理由・操作者・before/after等を監査可能にする。
「全文自由入力」と「手動運営」は別の設定であり、相互に依存しない。
Event Rulesは、少なくとも次の既存domainを正本として参照する。
これらの値をEvent Rules用fieldへ重複保存しない。
Event RulesはEvent共通基盤として設計する。
ただし、最初の完全な適用・検証対象はLeagueとする。
現在League 1へ手動掲載されているルールを、Event Rulesの構造化設定と既存正本から再生成し、
ことを検証する。
その後、League 2について、手動本文入力なしでルールタブが完成することを確認する。
実装時には、既存のCompetition Context基盤を拡張する。
新しいEventシステムを並立させない。
特に、
について、Event Rules側で独自実装を作らない。
新規実装は、既存正本に存在しないEvent Rules固有policy、表示projection、主催者連絡資格、Rules Version等に限定する。
管理UIについても、内部のraw JSONや任意graphを直接操作させるのではなく、既存runtimeが安全に扱えるpreset・選択肢を中心とする。