ゲームバージョンと筐体モデル

同じゲームの同じバージョンが見つかっても、希望する機材で遊べるとは限らない。筐体の種類で店舗を絞り込みたいという要望が繰り返し寄せられたのは、この違いがあるためである。ソフトウェアのバージョンだけではハードウェアの仕様を表せなかった。

分離前：シリーズと設置機種を同じ一覧から選んでいたフィルター。 英語の原キャプチャ。

キャビネットはゲームを動かす筐体のモデルを意味する。例えば同じバージョンが複数のモデルで動く場合、利用者は両方の条件を選ぶ必要がある。バージョンと正規の筐体に別々のIDを持たせ、対応する組み合わせを互換関係で結んで検索と編集に使った。

flowchart TD
    accTitle: バージョンと筐体の互換関係
    accDescr: バージョンと正規筐体を互換関係で結び、設置項目がその組み合わせを参照する。
    V[ゲームバージョン] --> C[互換関係]
    B[正規筐体] --> C
    C --> I[店舗の設置項目]
    I --> P[実際の台数と価格]

対応筐体と料金の初期値

カタログには対応筐体ID、地域別の表示名、筐体ごとの料金初期値を用意する。編集画面はそれを使って選べるモデルと初期料金を案内できる。ただし現地の価格を保証する値ではないため、設置情報にはその店舗で確認した価格を保存する。

分離後：シリーズの下で設置機種を選ぶフィルター。 英語の原キャプチャ。

モデルが未確認の設置はnullのまま残す。一般型で埋めると確認した値と推測を見分けられないためである。名称が似ているだけで決めず、互換性のある正規IDが分かった場合に選び、不明な項目は今後確認する対象として扱う。

flowchart TD
    accTitle: 確認状態に応じた筐体保存
    accDescr: 確認済み筐体は正規IDを選び、不明な筐体はnullの意味を維持する。
    Q{筐体を確認できたか} -->|確認済み| C[互換性のある正規ID]
    Q -->|未確認| N[null]
    C --> S[設置revision]
    N --> S

設置項目と過去データの移行

製品カタログは複数の店舗が共有するが、設置項目には店舗固有の台数、料金、設置場所がある。価格やバージョンが変わっても設置IDは維持し、各revisionに当時のバージョンと筐体を保存する。故障報告と編集履歴が同じ設置を指し続けるためである。

ゲームバージョンと筐体を分けて選択する。 英語の原キャプチャ。

移行には確認済みの対応表と固定したマニフェストを使う。変換候補に対して、現在一覧だけでなく過去の参照、台数、対応範囲も調べる。モデルを特定できず未確認のまま残しても、その設置に結び付く履歴まで失ってはいけない。

flowchart TD
    accTitle: 過去の参照を保つ移行
    accDescr: 確認済み対応表から変換候補を作り、過去の参照・数量・網羅性を検証して新状態を作る。
    M[確認済み対応表とmanifest] --> T[変換候補]
    T --> V[参照・数量・網羅性を検証]
    V --> S[新しい設置状態]
    H[過去の履歴] --> V

フィルターの改善と現地確認

同じバージョンの中から筐体を選んで探し、編集できるようになり、機種別の料金も提案できる。カタログの名称変更を実際の設置交換と混同する可能性も減らせる。

一方、モデルを分けただけで過去情報の不確かさは解消しない。未確認筐体には現地確認が必要で、料金初期値も変更され得る。対応表と参照検証の負担はあるが、確認できた情報と今後確認する情報を明示して扱えるようになった。

関連する記事と資料：Musecatの開発記録

関連アップデート

• beatmania IIDX 34 ZINRAI バージョン追加のお知らせ
• ゲームラインナップ更新 (4月28日)