質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Unity

Unityは、Unity Technologiesが開発・販売している、IDEを内蔵するゲームエンジンです。主にC#を用いたプログラミングでコンテンツの開発が可能です。

Q&A

解決済

1回答

4150閲覧

uGUIのInput System

退会済みユーザー

退会済みユーザー

総合スコア0

Unity

Unityは、Unity Technologiesが開発・販売している、IDEを内蔵するゲームエンジンです。主にC#を用いたプログラミングでコンテンツの開発が可能です。

0グッド

0クリップ

投稿2020/09/11 18:59

前提・実現したいこと

こちらのサイトを見て、
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に変換しただけで、
あとは今まで通りの実装方法で、受付処理ができてしまいました。

C#

1 using System.Collections; 2 using System.Collections.Generic; 3 using UnityEngine; 4 using UnityEngine.UI; 5 6 public class MyInput : MonoBehaviour 7 { 8 [SerializeField] 9 Button button; 10 11 [SerializeField] 12 GameObject cube; 13 14 void Start() 15 { 16 button.onClick.AddListener(MyClick); 17 } 18 19 void MyClick(){ 20 cube.transform.localScale *= 1.2f; 21 } 22 23 }

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]を設定しなければならないということでしょうか。
そうすると、スマホのジョイスティックだけでなく、ゲームパッドのデバイスのジョイスティックでも処理が動いてしまうということになりますか?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

質問1については、ご質問者さんのとった方法で問題なさそうに思われます。UI support | Input System | 1.0.0によればInputSystemUIInputModuleStandaloneInputModuleの代替物として動作するようで、このインプットモジュールよりも先の入力取り扱い処理は従来通りの仕組みで動いているみたいですね。
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を使った方がむしろわかりやすいかもしれませんね。

投稿2020/09/13 02:16

Bongo

総合スコア10807

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2020/09/13 04:55

ご回答ありがとうございます。 InputSystemUIInputModuleにインプットアクションアセットをセットするための欄があるので、 「新しいInput Systemの利用(InputActions)」に該当するということですね、理解できました。 質問して少し時間が経ってから、 通常のuGUIのボタンではonClickしかクリック処理の実装はできず、 仮想ボタンの方は、Started、Performed、Canceledのフェーズを持たせることができるので、 これが両者の違いなのかもと思っていたのですが、 ご教示いただいて、通常のuGUIのほうでも、InputActionsの実装ができるとわかりましたので、 通常のuGUIのボタンでも、InputActionsの実装をすれば、 Started、Performed、Canceledのフェーズを持たせることができるので、 その両者の違いはなさそうですね。 勉強になりました。 すみません、今更ながら簡単なことに気づいたのですが、 私はバーチャルパッド(OnScreen~の方)を実装するときは、 おそらくモバイル開発でしか利用しないつもりですが、 モバイルで操作するとなった場合、 通常、エンドユーザーは、モバイル(スマホ)をゲームパッドと接続して使うなんていうマニアックな使い方はしないはずなので、 ゲームパッドとバーチャルゲームパッドを明確に区別しなくても、 その両方から入力が取れて反応してしまう状態のゲームでリリースしても問題ないですよね? (Auto-Switchがオフのときは片方だけになってしまうことは気を付けたいと思いますが、 そもそもエンドユーザーがスマホにゲームパッドを接続しないという想定です。)
Bongo

2020/09/13 05:16

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

退会済みユーザー

2020/09/13 05:34

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問