UIテクニカルデザイナー
ゲーム開発において、UIの実装は誰がどうやって行うか。いつもこれを決めるのにもどかしい思いをしていた。もちろんプロジェクトによってどうすべきかは違ってくるが、個人的にはできるだけデザインができる人に直接実装してもらいたい。だが、実装においてデザイナーの自由度を高くしようとするとどうしても作業範囲が広くなってしまいテクニカルなことが必要になってくる。そう思っていたところ、UIテクニカルデザイナーというエンジン上でUIの実装を行う職種に出会い、非常に理に適っていると感じたので、UIプログラマとしてバディのような形でUIテクニカルデザイナーと仕事をした結果の自分なりの理解について共有したいと思う。
1. Visual Scriptingについて
私が知っているUIテクニカルデザイナーの作業はVisual Scriptingありきなので、先にVisual Scriptingの有用性について簡単に説明する。
2012年だったか、私が初めてUnityについての説明をUnityの中の人にしてもらった時に「ゲームエンジンを使うことで手触りだったり、ユーザーフェイシングな部分の実装に集中できる」という説明を受けたのをよく覚えているが、誰がそこの部分を作るべきかということを考えると、UIデザイナー（or ゲームデザイナー）が作るべきだと思っている。プログラマはあくまでシステムの実装・保守に集中することでより堅牢なシステム・ツールを作りつつ、ユーザーフェイシングな部分はゲームやUIがどうあるべきかをデザインするデザイナーが作るというのが理想だろう。
それを実現するには、プログラマが何も新しい機能を実装しなくても、エンジンが持っている機能を使うだけでデザイナーがゲーム上に作りたいものを実装できる状況が理想だが、実際にUnreal EngineのBlueprint (Visual Scripting)を使えばそれができたりする。Visual Scriptingを行うことでデザイナーがエンジン上で自由に直接実装できるのだ。
では、誰もが簡単に実装できるのかというとそういうことではない。高い自由度を持っているということは自由に壊すこともできるということであり、ちゃんと制御するにはそれなりの知識と経験が必要だったりする。それを職種として担当するのがUIテクニカルデザイナーというわけだ。
2.UIテクニカルデザイナーの必要性
2-a. UIをVisual Scriptingで制御した方が良い理由
Visual Scripting自体の有用性については前述したが、UIをVisual Scriptingで制御した方が良い理由としては
- レイアウト構造の定義
- インタラクション制御
- 条件に応じた見た目の変化
- アニメーション/VFX/SFXとの連動
が、挙げられる。細かく説明しようとすると長くなるので今回は割愛するが、一番のポイントだと思うレイアウト構造の定義についてだけ軽く触れたい。
レイアウト構造の定義について、UIをエンジン上で実装する必要がある大きい理由の一つだと思っている。「どのパネルの上にどのリストが乗っていて、そのリストはどんなウィジェットを持っているのか」というデータはどこかで定義する必要がある。もちろんPhotoshopなどのデザインツールの段階で定義してそれをエンジン側にコンバートすることもできなくもないが、デザインツール上でレイアウト構造を構築しようとしつつデザインするとなると手間が増えるので、ビジュアルデザインと実装時のレイアウト構造は分けて作った方が良いだろう。分けて作るのであれば、エンジン上で直接定義した方がインタラクションやアニメーションなど、その他の要素との関連性が確認できる面で良いだろうと思っている。
2-b. UIの制御の難しさ
UIは実はスクリプトで制御しようと思うと難しい分野だと思っている。理由としては上記に上げた要素を制御しようとするとイベント駆動だけでなく、フレーム単位の処理も必要になってくる。が、フレーム単位の処理にすると制御しなければならないことが増え、Visual Scriptingで実装したとしても、考えなければいけないことはほとんどプログラミングと変わらない。
ただデータをUIで表示するだけならばあまり問題にならないが、ユーザーの操作に合わせてロードするデータを変えて、ロードが終わり次第ロード表示からデータの表示に切り替えるというようなことを考えていくと制御しなければならない処理がどんどん増えていく。それらの処理をシステム側に移せばスクリプトで制御することは減るが、その分自由に変更がしにくくなってしまうので、制御の難しさと自由度のバランスを取るのが難しいと日々感じている。
2-c. エンジン上でのイテレーションを早くする
ゲーム開発には欠かせないイテレーション（デザイン→実装→レビューのサイクル）をどう対応するか考えた時「デザインツール上でイテレーションしてそれをコンバートすればすぐ反映される仕組みを作ればよいのでは」という意見もあるかもしれない。たしかに、個人的にもXDなどのデザインツール上でプロトタイピングして確認できることは、できるだけそこで確認した方が良いと思う。
しかし、実際にはデザインツール上でデザインしたをエンジンに落とし込み、それが変わらないということはほとんどなく、他の要素との兼ね合いで実際にゲームに組み込んで確認してみて初めてわかることが多く、「ここの動きを変えて欲しい」「表示条件を変えて欲しい」「仮実装したものを見せて欲しい」のような細かい要望が多く上がってくる。であれば、エンジン上で直接イテレーションできるようにした方がより効率的だろう。
2-d. プログラマとの分担作業
プログラマはシステムの作成・実装するための環境を用意に集中し、その用意された環境でデザイナーが自由にプロトタイピングしたり、実装したり、ブラッシュアップしたり、仕様変更に対応したり。そうすることで、プログラマはシステムの作成・保守に注力でき、より使いやすいツールを作ったり、システムのバグを早めに直したりと、担当範囲を分けることでエンジン上での実装担当者にも良い効果を与えられる。
3. UIテクニカルデザイナーに求められる能力
3-a. プログラミングの素養
前述した通り、UIはスクリプトで組もうとするとプログラミングにすごく近い構造になってしまうと思う。ともすれば、求められる能力はプログラミングの素養があることである。
実際に、うちでテクニカルデザイナーとして雇われている人たちは総じてプログラミングの素養があり、多くは個人でゲーム開発をした経験がある人達だ。そのような人達がプログラマではなく、デザイナーとして雇われるということも驚いたが、「システム・エンジンの実装」と「ゲームの手触りや演出の実装」は必要な能力が異なるので、そこの職種を分けることについて非常に理に適っていると思う。
ただ、逆に言えば、テクニカルデザイナーとして雇われていない人達をテクニカルデザイナーとして振舞わせるのは非常に難しい。今のプロジェクトではある程度上手く行ったとも思うが、もともとスクリプティングの素養が多少あるデザイナーでも6か月以上の時間をかけて、やっと慣れたように見える。これは言い過ぎではなく、協業の海外スタジオの人とこの話題について話をした時に同じことを言っていた「UI TDのオンボーディングには冗談ではなく6か月以上かかる」と。
3-b. UIデザイナーの素養
そして、もちろんただのプログラマとしてではなく、UIがどうあるべきかというUIデザイナーとしての能力を持っていることが理想的だ。エンジン上での実装に落とし込む時に、UIデザイン通りに落とし込むには何が必要なのか、問題があるとすればどのような解決策が考えられるのかという話をUIデザイナーと擦り合わせることが多くなる。
とはいえ、上記の両方の能力を持っている人となるとWeb系でScriptを書いてた人のように結構限定されてしまうので、どちらかというとUIテクニカルデザイナーはプログラミングの素養を持っていて、デザインについてはUIデザイナー主導で行うということが多いように感じる。ちなみに、私のプロジェクトのリードUIテクニカルデザイナーは両方の素養を持っていて、それによって良いハブとなってプロジェクトに大きく貢献している。
3-c. UIチームの構成
私が使っているエンジンのコンセプトとして
- プログラマ 1人
- UIデザイナー 1人
- UIテクニカルデザイナー 2人
が理想の構成とされている。
これはすごく衝撃的だった。そもそもこれまでUIテクニカルデザイナーを見たことすらなかったのに、それが2人、しかもUIに特化した人が2人となると…英語圏だと職種が専門家しているとは聞いてたもののそれほどだとは思わなかった。と、当初はそう思っていたのだが、最終的には私のプロジェクトでもほぼこの比率でチームが構成されることになった。
3-d. プログラマによるサポート
私はUIプログラマだけど、UIテクニカルデザイナーと間違われたこともあった。それぐらいスクリプトを触っているし、スクリプト上で共通のシステムを作ることもよく行っている。前述した通り、実装の保守性や再利用性を高めることは難しいので、そこについてはプログラマがサポートした方が良いだろう。
社内のUIプログラマへのインタビュー動画で「UIエンジニアはスクリプティングのサポートを多くする機会が今後増えていき、リードUIテクニカルデザイナーのようになるかもしれない」という話もあった。つまり、エンジニアがスクリプティングをサポートして、垣根を作らずテクニカルデザイナーと密接に仕事をし、知識や考え方を共有していくのが大事だと思う。逆に、テクニカルデザイナーからはシステムの要望・何が必要かを明確に伝えられると開発がスムーズになるだろうと思う。
Visual Scriptingを中心に大規模開発を行ったことの経験談で「スクリプトは管理するのが難しくて、スクリプトベースで作ったことを後悔した」という話を聞いたことがある。たしかにコードの方がデバッグしやすいのはたしかだが、それ以上にイテレーションのしやすさや、担当範囲の切り分け/譲渡の効果が大きいと思っているので、管理する難しさをプログラマがサポートすることで補助してくのが良いだろうと思っている。スクリプトとはいえ、やっていることはプログラミングとさほど変わらないので相応の保守・管理が必要で、それこそペアレビューをする必要があるぐらいだと思っていて、実際やっている。
4. UIテクニカルデザイナーの今後
去年UnityにVisual Scriptingツールの「Bolt」が公式にUnityに統合されたのは記憶に新しい。ビジュアルスクリプティングを行うことでのプロトタイピング・イテレーションの高速化、役割の切り分け/譲渡による能力の最大化は今後も間違いなく発展していくだろう。
一方で、日本ではあまりVisual Scriptingを活用した開発事例、もしくはエンジン上でのUIデザイナによるUI実装の話を多くは聞かないので広まるかどうか正直わからない。また、前述したとおりプログラマの素養があるデザイナーも多くないし、それを期待した職種を設定する会社もまだまだないのではと思う。ので、UIテクニカルデザイナーという職種が広まることはあまりなさそうかなとも思っている。
5. まとめ
UIテクニカルデザイナーを開発のフローに入れることで、役割の切り分けによる能力の最大化の効果は大きいので、個人的にはこれからもっと流行っていくのではと思いつつも、プロジェクトによって何が最適なのかは異なるし、日本ではVisual Scriptingを使った開発が広まるかどうか正直わからない。しかし、専門の職種が会社にいなくても、UI実装する際にVisual Scriptingという手段があって、それを専門の職種がいる会社もあると認識しておけば、それだけコストがかかる、コストをかけてよいことだということも理解されやすいのではないだろうか。このことが、ゲーム開発におけるUI実装についての選択肢を増やし、UI実装についての議論の一助になればと思う。
この記事が気に入ったらサポートをしてみませんか？