CLOSE

音ゲーにInputSystemを使ってみた(全1記事)

『プロジェクトセカイ』に導入されたUnityの新機能 フレームレートに依存せず入力を受け取る「InputSystem」

「CA.unity」は株式会社サイバーエージェントが運営するUnityをテーマにした勉強会です。 サイバーエージェントのサービス開発者と社外の開発者を交えて、Unityに関する知見を共有します。株式会社Colorful Paletteの橋本氏が発表したのは、「InputSystem」の導入について。既存の入力システムのリプレイスを目指したときの実装について話しました。

Unityの新しい入力機能「InputSystem」

橋本航 氏(以下、橋本):「音ゲーにInputSystemを使ってみた」というタイトルで発表します。よろしくお願いします。

まず自己紹介ですが、株式会社Colorful Paletteの橋本と申します。前職では業務用や家庭用のシステム開発を中心に行っていて、2021年に中途入社しました。現在、『プロジェクトセカイ』というプロジェクトでOutGame/InGameの担当を行っています。最近は趣味でゲームAIに没頭していて、その周辺ツールなどの開発もしています。

最初に、今回使ってみたInputSystemについての概要です。もしかしたらみなさんもご存じかもしれませんが、2020年4月に正式にリリースされた、Unityの新しい入力機能です。

ゲームパッド・キーボード・マウス・センサーなど、各種入力デバイスからの入力を、汎用的に、そしてキーマッピングを用いることで、ワンソースであらゆるデバイスに対応できるすばらしいシステムです。

今回はスマートフォンゲームのInputSystemの対応についてなので、簡単にタッチ入力の話をしたいと思います。

そもそも、なぜ今InputSystemを使おうと思ったのかというと、どうしてもスマートフォンというのは多種多様なデバイスや性能などがありますので、端末によってはフレームレートが常に低い状態であったり、「ちょっとカクついちゃうな」という悩みがありました。

そこで「InputSystemはフレームレートに依存せず入力を受け取れるらしい」という話を聞いて、「お、これはいいんじゃないか」「ちょっとやってみようか」と思うようになりました。

あと、それを使えば「フレームレートが低い端末でも」とか「仮に少し瞬間的に落ちてしまっても判定拾えるんじゃない?」「これはいいんじゃないか。もっとユーザーのみなさんにとってけっこうよい体験が届けられるんじゃないかな」となりそうなので、導入する話になりました。

既存のInputManagerのリプレイスを目指す

InputSystemを今回使うのですが、古いほうの入力システムである既存のInputManagerのリプレイスをまずは目指していたので、基本的にInputManagerと一番近いかたちで実装を進めようと思いました。

InputSystemの恩恵を得たいなという考えで進めて、InputManagerの現在のタッチ構造体に当たるものが、このInputSystem.EnhancedTouch.Touch構造体です。

これは、InputManagerがもっている入力座標や、現在のフェーズなど、基本的な情報プラス、「今、このタッチが何番目のタッチなのか」であったり、その指情報であったり。一番大事なのが、指ごとの入力履歴が取得できることで、優れものです。

TouchHistoryについて、簡単な説明にはなりますが、InputSystemのFinger構造体にあるTouchHistoryというパラメーターから取得が可能です。

指ごとに入力の履歴が取得可能ですが、どうしても端末によって挙動が若干変わってしまうところはあります。例えば、iPhoneのiOSだったらだいたい120ヘルツで入力を受け取っているので、(スライドを示し)下の図のような上の黄色い丸がメインフレームの更新タイミングだと考えてください。

従来のInputManagerでは、基本的にこの黄色い丸の部分で受けた情報のみを得られていたわけですけど、(スライドを示し)下の図のように、このピンクのフレームの中間情報部分も一緒に取れるようになっていますね。

この図はあくまでイメージ図のため、実際の挙動とはぜんぜん違うものになっているので、あくまで「あ、こんな感じで動いているんだ」とか、その程度に認識してもらえるとうれしいです。

実際にそれを試してみてどんな感じか、動画を撮ってみたので流したいと思います。

(動画を見せながら)左側はまず従来のInputManagerで、これはわざと処理を重くしてカクつかせるような、低スペックなシミュレーションを予行化している状態の挙動です。

最初、ノーツがない時の空打ち部分はもうガクガクです。実際右に4レーンぐらい広げてはいるのですけど、2、3レーンぐらいにしか反映されていないのがわかるかなと思います。

次に、それをInputSystemで対応してみて、入力の履歴を拾った場合のサンプルです。

同じような条件の低スペックシミュレーションではあるのですが、冒頭の空打ち部分であったり、このゲームを進めていくとノーツの取得具合であったり、ある程度のミスやBadであったりが少なく取れていることがわかるのではないでしょうか。

一番わかりやすいのは、やっぱりこの空打ち部分の挙動の違いかなと思います。単純に自分がポカしているところもあるので、イメージとしてこんな感じにできあがりました。

エディターでタッチ入力をシミュレーションする「TouchSimulation」

せっかくなので、ほかにもInputSystemの便利な機能を紹介したいなと思います。このTouchSimulationというクラスは、エディターでタッチ入力をシミュレーションする機能です。

今までのエディター用では、どうしてもマウスでの開発になってくるので、InputManagerを作って、それのインプットはGetMouseDownやMouseUpで疑似的にタッチ入力を作って、扱っていた人も少なくないと思います。

そのへんはInputSystemからTouchSimulationがやってくれるので、あくまで単入力に関してですが、InputManagerは作らなくて済むようになってきたなと思っています。

複数入力がないので、完全に自作のInputManagerとおさらばするのは、ちょっとできない感じです。

入力の録画や記録をしてくれる「InputRecorder」

次に「ここはすごく便利だな」って思っていたのが、InputRecorderという機能です。これは名前のとおり、入力の録画や記録をしてくれる機能です。

動画を撮ってもわかりづらかったので、今回は載せていませんが、例えば開発チームに譜面を作成する方々がいて、その方々にプレイしてもらった結果を再現する時や、その時に発生する不具合の特定原因などに非常に役立ちます。

さらにこのInputRecorder自体は、UGUIとの連携もしっかりできている機能なので、まだ試しの段階ではあるのですが、ゲームのタイトルからInGameまでのループであったり、指定部分をループして回るエージングデバッグも、けっこうやりやすくなるんじゃないかなと思っています。

この機能自体はまだリリースされていないのですが、今後もこれをどんどんブラッシュアップしていって、よりよい体験につなげられるようにやっていこうと思っています。以上で終わります。ありがとうございました。

司会者:橋本さん、ありがとうございました。InputSystemにはずっと興味はあったのですが、あまり自分で触る機会がなかったので、今回すごく勉強になりました。

あと、最近スマホゲームでもマルチプラットフォームなシステムや、またSwitchで出すものもけっこうあったりすると思うので、そういった時にすごく活きそうだなと思いました。ありがとうございます。

司会者:ではいくつか質問を拾っていきたいと思います。1つ目は「新しいInputSystemへのリプレイスで一番大変だった部分はどこですか」という質問です。

橋本:一番大変なところ。地味にInputManagerと挙動が変わっているところがありました。同じような操作をした時に、InputManagerとInputSystemで実際に取得できる座標の値に若干の差異が出て、手触りが変わっちゃうところがあって、そこの調整であったり。

あとはInputManagerのTouchesで、最後の入力が取れるようになっているのですが、InputSystemからは、その履歴情報から取れるようになっているので、例えば最初の入力で、beganが取れないことなどは発生していました。

それはTouchHistoryから、その1個前の入力情報を引っ張ってくるとbeganがあるので、ステージ内に行くみたいなことを書かないといけないという、仕様を理解するのに若干時間がかかってしまいました。

司会者:なるほど。メチャメチャ勉強になります。ありがとうございます。あとは「判定の部分もUnityのアップデートに依存しないようにしないと恩恵は受けられないでしょうか」という質問がありました。たぶん音ゲーの判定ですかね。

橋本:そうですね。基本的に音ゲーは、音楽の時間を使って判定するようになっていると思うので、それを元にしっかりと判定している前提で、あるいはそのInputSystemのTouchHistoryとか、あとTouch構造体には入力された時間があります。

なので、最後に入力された時間を基準として何秒ぐらいの差があるのかで、「じゃあ今この入力・音楽時間はこのAという地点にいるけど、そのAマイナス1の時間で判定を行うようにする」であったり、このあとしっかりと恩恵が得られていくんじゃないかなと思っています。

司会者:最後に「InputSystemの入力記録は、実際に業務でも活用しているのでしょうか」という質問です。

橋本:業務で活用しているのは、実はInputSystemじゃなくてInputManagerなんです。自分でちょっと必要になって、その履歴を保持するみたいなのをやっていたんですが、それをしっかりとInputSystemのに変えることもできるかなとは思っています。

そういう意味ではまだInputSystemの入力履歴の活用はできていないんですが、入力履歴があると、デバッグや、QAをする時に非常に強力だと思うので、どんどん使っていける機能なんじゃないかなと思います。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!