Summary

  • 2012年の Gamepad 草案は、ブラウザーのゲームにボタンと軸を直接渡した。パッドをキーボードやマウスのふりをさせると情報が失われ、追加のソフトも必要だった。
  • 2025年の W3C 草案では、実際のパッド操作を確認するまで getGamepads() は空の一覧を返す。機器の無言の点呼を防ぐためで、権限ポリシーは別の入口になる。

プレーヤーがパッドを接続してゲームを開く。キーボードはキーが押されたことを伝えられるが、トリガーがどれだけ引かれたかを表すのは苦手だ。マウスも、ハンドルを少し左に切る感覚をうまく伝えられない。2012年5月の W3C 最初の公開草案 は、この不自然な通訳をやめるためのものだった。軸、ボタン、機器の識別子、番号、状態が変わった時刻をページに渡し、接続・切断のイベントも用意した。コントローラーが事務用キーボードの制服を着ずに済む。

数値の扱いは明快だ。軸は -1 から 1、ボタンは 0 から 1。半分引いたトリガーは「押した／押さない」に潰されず、半分のまま届く。id は機器の種類を教え、番号は複数のパッドを並べる。ソファに四人いれば、誰が一時停止を押したかを知るのに役立つ。ただし、ページが遊び始める前に一覧を読めるなら、パッドを使わないサイトにも机の横の機材が見えてしまう。

そこで挨拶役を本人に戻す。2025年7月10日の W3C 草案 は、ゲームパッドによるユーザー操作が観測されるまで navigator.getGamepads() が空の一覧を返すと書く。理由は機器のフィンガープリント対策だ。パッドは物理的につながっていても、ページにはまだ紹介されない。人がボタンを押すか、戻り位置のあるスティックを意図して動かすと、会話が始まる。サイトの好奇心よりプレーヤーの手が先に来る。

ベルの仕組みには細工が要る。押したまま固定されるスイッチも、中央で少しふらつくスティックもある。その状態だけで「人が操作した」と判断すれば、ばねの癖が持ち主に代わって挨拶してしまう。2025年草案は中立状態からの変化を重視する。いったん離れていたボタンが押される、中央近くにいた軸がしきい値を越える。偶然の揺れにベルを鳴らさせない。

扉はもう一つある。活動中ではない文書には空の一覧が返り、gamepad の Permissions Policy で許されない文書は SecurityError を受ける。実際の操作は機器をスクリプトへ見せる条件であり、埋め込まれたすべてのページへ万能の許可を渡す儀式ではない。ブラウザーが文書のアクセスを決め、アプリがボタンの意味を決め、プレーヤーが最初の動作をする。三者の仕事は違う。

紹介が済んだら、ゲームは素早い状態の読み取りを続ける。getGamepads() は接続して操作された機器を配列で返し、抜けた番号の位置には null が残る。接続イベントは出入りを知らせる。番号は管理用で、永遠の身分証ではない。ボタンや軸こそジャンプ、旋回、ブレーキ、あるいは居間の画面をソファから動かすための入力だ。API は動きを渡す。ゲームの筋書きまでは書かない。

W3C の公開履歴 は2012年の草案から2025年版まで続く。これは仕様の節目で、すべてのブラウザーが同じ日に同じ作法になったという年表ではない。ゲームには豊かな入力が必要だった。無関係なページには、遊ぶ前の機器点呼は要らなかった。

プレーヤーがようやくボタンを押し、画面のキャラクターが動く。扉が開いたのは、コントローラーを持つ人が先にベルを鳴らしたからだ。