ジョイスティックを何個も使う飛行機オタク向けのゲーム設定アプリを作った話 #2

さて、BMSのジョイスティック設定はどのように管理されているのか、その答えはインストールディレクトリのUser/Configにある。

まずBMSの初回起動時に現在接続しているデバイスごとのプロダクトGUIDとデバイス名がDeviceSorting.txtというテキストファイルに一行づつ記録される。2回目以降の起動時に既存のリストにない新しいデバイスが追加されれば、新たに同ファイルの続きの行に情報が追記される。

BMSのデバイスの割当はこのファイルに書かれたデバイス情報から現在接続されていないデバイスをスキップした並び順で管理される。ここにいろいろな問題が発生する(ついでに言うとこの管理システムすらv4.32あたりの初期バージョンには存在しなかった)

ジョイスティックの設定は2種類に分かれる。ON/OFFのデジタルな操作が行われるDXボタン入力の割当と、操縦桿の傾け具合やスロットルの位置などアナログ入力の割当を管理するAXIS(軸)の割当だ。

DX割当は一つのテキストファイル、AXISの割当は2つのバイナリファイルにて管理される。

DX割当はボタンの識別を連番で管理する。1つ目のデバイスのボタンはそれぞれDX0からDX127までのボタン割り当てを持ち、2つ目のジョイスティックはDX128-255までの番号が割り当てられる。(開発当時のバージョンは128ボタンの代わりに32ボタンまでの対応だった)

AXIS割当はゲーム内戦闘機のそれぞれの入力項目(操縦桿の傾けやスロットル、レーダーカーソル操作など)に対して、何番目のデバイスの何番目の軸入力が割当されているかを記録する。

問題は連番が現在接続されていないデバイスをスキップした番号で認識されることにある。

例えば私の友人の一人はレースゲーム用のハンドルコントローラを接続した状態で初めてBMSの割当を行い、別な日にはハンドルコントローラーを外した状態でBMSを起動した。するとBMSはハンドルコントローラをスキップした連番でジョイスティックを認識するため、ハンドルコントローラー以降のデバイスとして管理されていた番号が一つ繰り下がる。それによりDX番号も128ボタンずつ繰り下がることになる。

例えば384番は3番めのデバイスの最初のボタンだが、繰り下がりが起きれば同じデバイスは2番目、ボタンは255番目となる。しかしボタン設定ファイルには384番目の割当として記録されているので、2つ目のデバイスの1つ目のボタンを押しても前回と違い反応しなくなるか、別な機能が発動する。

軸でも同様のことが発生し、接続されているデバイス数より大きい番号が記録されていた場合にはゲーム起動時に設定がリセットされてしまう。

たとえマニュアルにどれだけ詳細に割り当ての設定方法が書かれていたとしても、ユーザーはまず触って試そうとする。その操作方法が直感的でなければソフトウェアとして出来が悪いと判定されてしまう。

コミュニティは「複雑な戦闘機の操作方法を覚えなければいけないゲームを遊ぶのに、そこでマニュアルを読まない人を助けても楽しめる人ではないと思うよ」と私に言う。しかし戦闘機の操作に興味があってもソフトウェア側の都合に興味があるわけないじゃないか。と私は考える。

ゲーム内容はどんなにマニアックでもいい、でもユーザーインターフェースがマニアックであってはだめだ。

この問題を解決するために、自分が開発したAlternative Launcher(AL)は次の管理方法をとる。

• ユーザーはAL上のUIでデバイスの割り当てを設定する
• AL上でのデバイスの設定内容はデバイスのIDごとに保存された個別のファイルに書き込まれる
• ALからBMSを起動する瞬間にALは自前の管理ファイルの内容をもとにBMSの一連の設定ファイルを正しい連携づけがなされるよう生成する

結果として期待される効用:
デバイスIDごとに割り当てを管理するため連番による設定の入れ替わりが発生しない

さて、それをどのように実装するのか、つづく！