ゲーム・エンターテイメント事業部（SGE）で発足された横断組織「UI Frontier」の大庭（オオバ）です。「UI Frontier」とは、各子会社のUI開発に知見のあるエンジニアメンバーが集まり、議論、共有をする組織です。ベストプラクティスの議論、実装、普及を行い、各社のノウハウをSGE組織内に貯めていくこと目的に活動しています。

ところで、新規スマホゲーム開発で、UIをどう作ったらよいか悩みますよね。

最近のスマホゲームは予算規模も大きく、システム自体も複雑化し、リリース時に100画面超えることも普通です。UI開発だけでも多くのエンジニアやクリエイターが携わります。このようにUI開発は大規模化しやすく、関わる人も多くなります。私が重要だと感じることは、多くの方が開発に関わったときに、その分、早く開発が進むことだと思います。ただ、それが難しいわけです。

例えば、「メンバーはたくさんいるけど生産性は上がっていないかも？」といったパターンなどです。原因の1つとして考えられるのは「UI設計」です。設計は失敗すると地獄。設計力は楽器と同じで、すぐに上達するものではありません。

そこでUI設計の初心者向けに、今回はUI開発の醍醐味の1つである「画面遷移」にフォーカスして、失敗しないUI開発について紹介します。どんなゲーム内容でも、共通して考えておいた方が良いものをピックアップしました。UI設計が初めての若手エンジニアの方にも伝わるように、わかりやすく解説していますので、本記事を通してUI設計の考え方の学びになれば幸いです。

画面遷移は「共通機能」とすることが必須

画面遷移を実装するときに最も大事なことは共通機能としてつくることです。ここを外すと破綻します。繰り返しになりますが、リリース時に100を超える画面数を1つずつ作っていては、いつまでも終わりません。共通機能として提供して、少ないソースコードで安全につくれることが大事になります。共通機能として画面遷移をつくる上で気をつけたい3つのポイントを紹介します。

1.多人数の同時開発
2.直接遷移
3.画面づくりの共通化

ポイント1. 多人数の同時開発

画面遷移をつくる上で外せないポイントの1つは複数のメンバーが同時に開発できることです。この思想を外すと、作り直しレベルでシステムは破綻します。繰り返しになりますが、最近のスマホゲームは画面数が多いです。また、個人的には、人海戦術で乗り越えることが大事だと感じます。

「UI Frontier」で議論した結果、1画面を1パーツで分ける構造をベストプラクティスとしています。

1パーツとはUnityに置き換えるとPrefabです。

1画面につき1Prefabつくり、複数の画面を複数人で同時開発できるようにすることをオススメします。

ポイント2. 直接遷移

直接遷移とは、その名の通りどの画面にも遷移できること。もう少し具体的に説明すると、例えばクエスト画面は、必ずホーム画面を経由しないと遷移できないという制限を禁止しているということです。つまり、クエスト画面はホーム画面からでも強化画面からでも「どこから」でも遷移できるということ。

これは必ず意識しておきたいポイントです。

理由は仕様変更に強くするためです。ゲームをつくっている最中、より良いゲームにするため仕様はよく変わります。例えば「ホーム画面からのみクエスト画面に遷移できる実装をした」場合を考えます。

プロジェクトが進行する中で、イベント画面からも直接クエスト画面に遷移できる方がユーザー的に便利。
継続率アップにつながる。
だから修正したい。

という、もっともな改善にも簡単には答えられません。つまり要望に答える際の修正コストが大きすぎるのです。直接遷移をベースで作っていた場合は、一行ソースコードを足すくらいの軽微な修正で対応できます。

// クエスト画面へ遷移する
System.Goto(Quest);

直接遷移は見落としがちな重要機能です。エンジニア以外のメンバーにとっては、できて当たり前の機能だと思ってしまいがち。開発現場で、「遷移を変更したい」という声は簡単に出てきます。つまり仕様が変わりやすい部分ということで、必ず「直接遷移」は実装しておきましょう。

ポイント3. 画面づくりの共通化

最後に紹介する重要ポイント「画面づくりの共通化」。言い換えると、画面の作り方にルールを設けることです。

100画面を20人で5画面ずつ作ったとします。ルールが無いとどうでしょう。
20通りの思想をもった100画面が出来上がります。恐ろしいですね…。何が問題なのかというと、あとから参加したメンバーの生産性が上がらないこと。つまり画面ごとに作り方が違うと、何が正しいつくり方なのかわからないことが問題なのです。

開発で最も時間がかかることは「迷うこと」。迷うと生産性は大きく下がります。いかに単純作業レベルに持っていけるかがUI設計者の腕の見せ所です。思想は1つに統一しましょう。1つの思想をもとにルールを制定していくのです。もちろん画面ごとに機能は違うため、完全なつくり方の共通化はできません。

「UI Frontier」で議論した結果、全ての画面で以下の機能を共通で持つことをルールとし、また拡張できるようにすることをオススメしています。

• 画面表示前の処理
• 画面表示
• 画面非表示
• 画面非表示後の処理

これら各メソッドを親クラスで定義しておき、オーバーライドして実装していくイメージです。これで大半の処理はルール化されます。あとから入ってきたメンバーも読みやすく、生産性を維持できるでしょう。

まとめ : Unityで失敗しない画面遷移システムの作り方

画面遷移は共通機能として提供することが大事です。共通機能としてつくる上で3つの重要ポイントを紹介しました。

1.多人数の同時開発で効率化
2.直接遷移で仕様変更に強くする
3.画面づくりの共通化で生産性アップ

このような感じです。

画面遷移は設計を誤ると大きな事業損失を生みます。ちょっとした修正も多くの時間を要してしまうのです。冒頭の通り、最近のスマホゲームは予算も大きく、大規模化しています。その中でもUI開発はゲームの大半を占める大きな機能。その重要な機能を効率的に作るための設計は重責です。

だからおもしろい。

自分が設計したシステムで、多くの人が円滑に作業が進むのを感じるのがUI設計の醍醐味のひとつだと思っています。この記事を通してUI設計の参考になったら幸いです。今後も「UI Frontier」ではUI機能実装についての発信を継続しますので、次回の記事もお楽しみに。

Tweet

Pocket