ゲーム更新と現地の情報

ゲームの更新が発表されても、どの店舗で新バージョンを遊べるかすぐに分かるとは限らない。訪問の少ない店舗や遠い場所では古い情報が残りやすく、公式サイトでも各店舗の現在の版を確認できない場合があった。Musecatでは、この不足を埋めることを優先課題にした。

従来のバージョン確認画面。設置バージョンが正しいか確認し、以前の値に戻すこともできる。 英語の原キャプチャ。

運営者がすべての店舗へ行くことはできない。例えば旧版のまま掲載された筐体を現地で確認した人が、その結果を別の報告から転記する手間なく設置一覧へ反映できる必要がある。

そこでバージョン更新を期間と対象のあるキャンペーンにした。未確認の設置を探して旧版か更新済みかを確かめ、参加への報酬としてXPを提供する。既存のレベルシステムに現地確認という貢献方法を加えた形である。

flowchart TD
    accTitle: 対象の抽出と送信時の再検証
    accDescr: バージョン移行と筐体・国の範囲を現在の公開設置項目に適用し、確認送信時に再検証する。
    C["バージョン移行と範囲"] --> T["現在の公開ゲームから対象取得"]
    T --> U["利用者が現状確認"]
    U --> V{"送信時も対象が有効か"}
    V -->|"はい"| S["確認処理"]
    V -->|"いいえ"| E["競合または対象なし"]

対象範囲と送信時の確認

キャンペーンには移行先の版と筐体・国の範囲を設定する。店舗名を固定した一覧ではなく、公開され営業中の店舗の現在の設置から対象を求める。次の版に対応する筐体であることも確認する。

sequenceDiagram
    accTitle: 更新確認の原子的処理
    accDescr: 対象と訪問の検証後、必要なゲーム変更・確認記録・XPを一つのトランザクションで確定する。
    participant U as 確認する利用者
    participant A as キャンペーンAPI
    participant D as データベース
    U->>A: 更新確認
    A->>D: トランザクション開始と対象再検証
    A->>D: 訪問条件の確認
    A->>D: 必要なら次のゲーム状態と履歴を作成
    A->>D: 確認記録とXPを同時確定
    A-->>U: 現在の状態と貢献フィードバック

画面を開いてから送信するまでに、期間が終了したり設置が削除されたりすることがある。サーバーは送信時に期間、設置の存在、店舗と筐体の対象範囲を再確認し、条件が合わなければ競合や対象なしを返す。

現地確認とゲーム情報の更新

基本の信頼材料には同日の訪問認証を使う。許可された役割には位置確認の例外があるが、キャンペーンと対象の検査は省かない。旧版なら確認結果を残し、更新済みなら該当設置を次の版に変えたゲーム状態を作る。

flowchart TD
    accTitle: キャンペーン報酬の重複防止
    accDescr: 利用者とキャンペーン設置項目の付与種別を調べ、初回だけ合計と記録を同時更新する。
    R["報酬対象を確認"] --> K["利用者と付与種別を決定"]
    K --> H{"付与済み記録があるか"}
    H -->|"はい"| N["XP合計を維持"]
    H -->|"いいえ"| T["付与記録と合計を同時保存"]
    T --> L["レベルと貢献フィードバックを計算"]

ゲーム状態、変更履歴、確認、XPを一つのトランザクションで保存する。情報が変わらず報酬だけ得られたり、確認者が欠けたりする状態を防ぐためである。利用者・キャンペーン・設置ごとに付与種別も残し、同じ確認の再送でXPを重ねて加算しない。確認の追加と新しい報酬の付与は個別に判断する。

進捗と情報の再確認

確認結果がゲーム状態に反映されることで、利用者は更新済みの設置を探し、運営者は未確認の対象を把握できる。別の報告一覧と文書を照合する代わりに、進捗と確認履歴を同じ流れで読めるようになる。

すべての店舗が常に最新になるわけではない。誤った確認には訂正と追加確認が必要で、期間終了や店舗状態の変化も反映し続ける。報酬は参加を支える手段として使い、後から情報を見直せる仕組みも維持する。

関連する記事と資料：レベルシステム · Musecatの開発記録