uGUIのInput System

Question

前提・実現したいこと

こちらのサイトを見て、
Input Systemには、下記3つの実装方法があることを知ったのですが、uGUIの場合、どれに該当するのでしょうか？

新しいInput Systemの利用（InputControl）
新しいInput Systemの利用（InputAction）
新しいInput Systemの利用（InputActions）

また、こちらのサイトのOn-Screen ButtonとOn-Screen Stickに関しても、質問させていただけたらと思います。

試したこと

まず、uGUIのInput Systemの受付処理ですが、
基本的には、InputSystem.inputsettingsを作成して、Event SystemをInputSystemUIInputModuleに変換しただけで、
あとは今まで通りの実装方法で、受付処理ができてしまいました。

  using System.Collections;
  using System.Collections.Generic;
  using UnityEngine;
  using UnityEngine.UI;

  public class MyInput : MonoBehaviour
  {
    [SerializeField]
    Button button;

    [SerializeField]
    GameObject cube;

    void Start()
    {
      button.onClick.AddListener(MyClick);   
    }

    void MyClick(){
      cube.transform.localScale *= 1.2f;
    }

  }

Unityエディタのマウスの左ボタンのクリックによるuGUIのボタン押下と、
Android実機上でのタップによるuGUIのボタン押下、それぞれでボタンのクリック処理が反応することを確認しました。

・質問1。
Input SystemのuGUIの入力受付方法はこれでよいのでしょうか？
そうすると、下記3つのどれの方法にも該当しないような気がするのですが、uGUIの場合は、第4の実装方法ということになるのでしょうか？
それとも、この後、下記3つのどれかの方法について、何か追加しなければならない実装があるのでしょうか？

新しいInput Systemの利用（InputControl）
新しいInput Systemの利用（InputAction）
新しいInput Systemの利用（InputActions）

・質問2。
On-Screen Buttonや、On-Screen Stickはどういった仕組み、使用用途になっているのでしょうか？
どちらも実装してみましたが、やっていることがよくわからなかったです。
仮想パッド、仮想ジョイスティックの意味がわかってないのかもしれないです。
まず、On-Screen Buttonですが、質問1の方法でButtonのクリック処理は実装できるので、
On-Screen Buttonの必要性がわかりません。

On-Screen ButtonのControl Pathというのは、uGUIのOn-Screen ButtonがアタッチしているButtonをクリックすると、
On-Screen ButtonのControl Pathで設定している入力が発火したことになるという仕組みになっているのでしょうか？

OnScreenStickもControl PathをLeft Stick[GamePad]に設定して試してみました。
ゲームパッドのデバイスを持っていないので、実機で試すことはできなかったのですが、
ゲームパッドのデバイスの左スティックでも、moveActionが動くということですか？
とすると、OnScreenStickは、ゲームパッドのデバイスを使わないで、左スティックの動きを試すデバッグ用みたいな用途になるのでしょうか？

逆に、ゲームパッドのデバイスを使わず、スマホのジョイスティックとして、OnScreenStickを使いたいのですが、
その場合でも、Control Pathには、Left Stick[GamePad]を設定しなければならないということでしょうか。
そうすると、スマホのジョイスティックだけでなく、ゲームパッドのデバイスのジョイスティックでも処理が動いてしまうということになりますか？

Answer 1

質問1については、ご質問者さんのとった方法で問題なさそうに思われます。UI support | Input System | 1.0.0によればInputSystemUIInputModuleはStandaloneInputModuleの代替物として動作するようで、このインプットモジュールよりも先の入力取り扱い処理は従来通りの仕組みで動いているみたいですね。
InputSystemUIInputModuleにはインプットアクションアセットをセットするための欄がありますので、テラシュールブログさんの紹介されている3つの分類のうちでは「新しいInput Systemの利用（InputActions）」に該当するんじゃないでしょうか?

質問2のOn-Screen Button、On-Screen Stickの挙動については、おっしゃる通りControl Pathに設定されたパスでの入力として扱われるようです。試したところ実際のゲームパッドと画面上のバーチャルスティックの両方で反応しました。
メニューの「Window」→「Analysis」→「Input Debugger」でデバイスの状況を見てみたところ、バーチャルスティックも一つのデバイスとして認識されているようでした。ですので、あたかも2個のゲームパッドを同時に接続したような状態になっているようです。
異なるデバイスとして区別されているため入力が混線することはないようですが、たとえばAuto-SwitchがオフのPlayer Inputで入力を受け取ろうとした場合、これら2つのデバイスのうちどちらか一方とペアリングされてそちら側からの入力だけにしか反応しない...みたいな状況にもなりうるようでしたので注意が必要かもしれません。

On-Screenコントロールの存在意義ですけども、おっしゃるようにデバッグ用としても使えるでしょうが、必ずしもそのためだけに限られるものではないような気がします。確かにInputSystemUIInputModule経由で入力を受け付けることも可能でしょうが、それは意味付けとしてはあくまでも「UIコントロールの操作」であって、それをゲームパッドからの入力と同等に扱うためには入力に応答する側...たとえばキャラクターを動かすスクリプトの側に「UIからの入力」と「ゲームパッドからの入力」をそれぞれ認識して適切に処理するコードを書く必要があるように思います。
「ゲームパッド、あるいはバーチャルスティックはスティック操作イベントをInput Systemに送る」「Input Systemはスティック操作イベントに反応し抽象的な『Move』イベントを発生させる」「キャラクターを動かすスクリプトは『Move』イベントに反応して移動処理を行う」という風に役割分担されたモデルならば、キャラクターを動かすスクリプトの側は実際のインプットデバイスが何であるか気にせず本質的なロジックを記述することに専念できるんじゃないでしょうか。
モジュール同士の結合度を低く保てる...とでも言うんでしょうかね?「依存性逆転」だとかいう概念とも関係があるような気がしますが...勉強不足につきいまいちうまく説明できずすみません。

「ゲームパッドのデバイスを使わず、スマホのジョイスティックとして...」、「スマホのジョイスティックだけでなく、ゲームパッドのデバイスのジョイスティックでも処理が動いてしまうということになりますか？」の件については、おそらく前述の結果からそのようになってしまうと思われます。
On-Screenコントロールのデバイス名はControl Pathから判断されたレイアウト名と同じになるようで、「Left Stick [Gamepad]」なら自動的に「Gamepad」という名前のデバイスが作られるようです。そこで、アクション側のバインディングパスを「<Gamepad>/leftStick」のようなレイアウト名でマッチさせるのではなく、具体的なデバイス名をつかった「Gamepad/leftStick」みたいな形にすることでバーチャルスティックからの入力だけに反応させることもできるのかもしれません。
とはいえ、これはこれで何だかごちゃごちゃしてわかりにくい気もします。先ほどモジュール同士の結合が云々申し上げましたが、あれはあくまでそういう考え方もあるだろうと思って言及しただけで、無理に固執する必要はないでしょう。実際のゲームパッドとバーチャルゲームパッドを明確に区別したいのであれば、InputSystemUIInputModuleを使った方がむしろわかりやすいかもしれませんね。

Comments

[退会済みユーザー]

ご回答ありがとうございます。

InputSystemUIInputModuleにインプットアクションアセットをセットするための欄があるので、
「新しいInput Systemの利用（InputActions）」に該当するということですね、理解できました。

質問して少し時間が経ってから、
通常のuGUIのボタンではonClickしかクリック処理の実装はできず、
仮想ボタンの方は、Started、Performed、Canceledのフェーズを持たせることができるので、
これが両者の違いなのかもと思っていたのですが、
ご教示いただいて、通常のuGUIのほうでも、InputActionsの実装ができるとわかりましたので、
通常のuGUIのボタンでも、InputActionsの実装をすれば、
Started、Performed、Canceledのフェーズを持たせることができるので、
その両者の違いはなさそうですね。
勉強になりました。

すみません、今更ながら簡単なことに気づいたのですが、
私はバーチャルパッド(OnScreen～の方)を実装するときは、
おそらくモバイル開発でしか利用しないつもりですが、
モバイルで操作するとなった場合、
通常、エンドユーザーは、モバイル(スマホ)をゲームパッドと接続して使うなんていうマニアックな使い方はしないはずなので、
ゲームパッドとバーチャルゲームパッドを明確に区別しなくても、
その両方から入力が取れて反応してしまう状態のゲームでリリースしても問題ないですよね？
(Auto-Switchがオフのときは片方だけになってしまうことは気を付けたいと思いますが、
そもそもエンドユーザーがスマホにゲームパッドを接続しないという想定です。)

[Bongo]

そうですね、おそらく「スマホにゲームパッドを接続する」みたいなことをやろうとする方はレアケースでしょうし、そのようにしてかまわないだろうと思います。それにAuto-Switchがオンなら、どうやらそのようなケースでも外部接続したゲームパッドからの入力を自動的に受け付けてくれそうな感じですので好都合かもしれません。もしスマホにゲームパッドを接続したがる方が無視できないほど大勢出てきたらじっくり動作確認する必要があるでしょうけど...

[退会済みユーザー]

ご回答ありがとうございます。
ご教示いただき、ありがとうございます。
とても勉強になりました。
ありがとうございました。