ysis: ゲーム入力APIの3形態(同期 / 非同期 / フレーム型)
okuokuそろそろ入力を真面目に処理しようということで。。
Yuniframe Simple Input Service
一度最初から最後まで作ってみて仕様をまとめてみないと難しいかなということで、まずゲームやエディタにフォーカスして簡単な入力サービスを作ってみることにした。ysisは:
- キーボード
- マウス
- ゲームパッド
- 両手型 xR コントローラー
- xRヘッドセット
- マルチタッチ
- 9軸センサ
- ペン(筆圧)
をサポートする。ギター型コントローラとかはMIDIにしろって事で。。AppleTVのタッチサーフェスのような1品物は今回は無視する。要するに前身のWebGL-Nativeと一緒でWeb APIをベースにデザインする。
okuoku既存のAPIの分類
既存のAPIは、概ね イベントキュー型 / フレーム型 / 非同期型 に分類できる。また、キーボードにせよ何にせよ入力デバイスを "センサ" と捉えた場合、APIは イベント を返却するケースと 波形 (= 入力履歴全体)を返却するケースに分けられる。ただし、通常、ゲーム入力では波形は必要無いケースが多い。
イベントキュー型入力
MacやWindowsなど伝統的なGUI OSでは、windowやアプリが1つのイベントキューを持ち、デバイスがそのイベントキューにイベントの形でイベントを投稿する形を採ることが多い。
基本的にマルチスレッドの無かった時代のデザインなので、GUIにおけるウインドウの制御のためのイベントと 混ざって イベントがキューされることになる。このため、デザイン上の困難が割と存在する。
Web上(DOM)のAPIは更に抽象化を進め、イベント毎の コールバック をシステムに登録させるスタイルとなっている。
フレーム型入力
フレーム型入力はイベントキュー型入力のより制約の強い形で、アプリケーションには抽象化した "フレーム" オブジェクトを渡し、その中に入っている入力情報を採り出して使うことを想定したデザインとなっている。これは伝統的なゲーム機の処理に近い。
WebXRは XRFrame https://immersive-web.github.io/webxr/#xrframe オブジェクトのメソッド getViewerPose 等でヘッドセットのセンサにアクセスできる。ただし、コントローラや手入力を表現する XRInputSource は通常のDOM eventを出力するため、従来通りのイベントキュー型入力となっている。
Playdateはアプリケーションにフレームのコールバックのみを実装させている。このため、入力APIも必然的にフレーム型になる。
非同期型入力
OSが提供するイベントキューやフレームとは独立して入力を取得できる場合は非同期型に分類できる。
例えば、Xboxコントローラ向けのAPIである XInput は任意のスレッドから任意のタイミングで XInputGetState や XInputGetKeystroke でコントローラの現在の状態を取得できる。