![note記事用画像](https://assets.st-note.com/production/uploads/images/16922839/rectangle_large_type_2_c8f1b0bb5bc35f891e7120e0191ac317.png?width=1200)
ゲームUIデザイナーのちょっと踏み込んだ実装フロー
初めまして!某ゲーム会社でUIデザイナーとして仕事をしているユムナギ(@yumu_7)です。
@tkm_ui さん主催のゲームグラフィックアドベントカレンダー「Game Graphic Design Advent Calendar 2019」に参加させていただき16日目の記事となります。
さて、そもそもゲームってどうやって作っとるねん!という話をたまに聞きます。
なんとなくは知ってるけどもうちょっと具体的にどんな感じなのか知りたい!という限定的なニーズ?に応えるべく、
今回僕からはゲーム開発現場においてUIデザイナーが実装面でどんなことを考えて仕事をしているか、実際のところプランナーさんから仕様をもらってUIデザインを行った後、フロントエンドエンジニアさんへどうやってデータを受け渡して開発を行なっているのかを大枠よりちょっと踏み込んだ形で紹介出来たらなと思います。
0.はじめに
まず前提として、以下の内容はUnityというゲーム開発エンジンを使った開発の話になります。
ゲームに限った話ではありませんが、プロジェクトや会社の文化の違い、ツールが一部独自ツールだったり途中で別のツール挟んだりと、ゲーム業界はプロジェクトや開発規模などによって色々な作り方があるので、だいたいこんな感じで作ってるんだな〜くらいで思っていただければと思います!
(とはいえ最近はUnityが多いです)
UIデザイナー視点での作業フローとしてざっくり。
仕様書が降りてきたら、画面設計→デザイン→Unity組み込み→フロントさんへ受け渡しという流れがあります。
その中でデザインが完成した後の実装の流れについてちょっと踏み込んで話していきたいと思います。
1.パーツ分け
突然ですがデザインが完成しました!(わーいパチパチ)
デザインが完成したら実装するために最適なサイズでパーツを切り分けます。
なんか武器とか書いてあるとこアイコンがラムネだし背景ないし色々ツッコミどころありますが今回は気にせず実装しちゃいましょう!
パーツ分けしました!(どっかの料理番組みたい)
こういった複数のパーツ画像を一枚の画像にまとめたものをアトラス画像と呼びます。
ゲーム内ではこのアトラスに入っているパーツを組み合わせて画面に描画、ゲーム画面にしています。(実際のアトラス画像はもっとパーツが沢山あって隙間なくびっしり詰まってます)
気をつけておきたいのがパーツを分けすぎても分けなさすぎてもダメだということです。
パーツを分けすぎると画面にたくさんの画像を端末に描画させることになってしまうためcall数も増え、端末のメモリをたくさん使ってしまいます。特に低スペックスマホだと重くなるので快適にプレイ可能なことが絶対条件のゲームにとっては非常に大切な部分と言えるでしょう。
逆に分けなさすぎても一枚の画像が大きくなりすぎてしまってアトラスが肥大化してしまったりアニメーションさせ辛くなってしまいます。
描画コストを抑えつつ動かしたい部分を動かすことができ、キャラクターのサムネイルなどのデータを入れ込む場所が用意できるようその画面に合った最適な切り分けを行います!
2.Unityへの組み込み
パーツの切り分けが終わったらUnityへ入れ込みます。
Unityというゲームエンジンの基本UIはこんな感じになっています。
初めて見る方は何が何だかわからないと思いますが、エンジニアとデザイナーはGitなどのバージョン管理システムを通してこの画面で実際にゲーム開発を行なっています。昔と違ってエンジニアとデザイナーの共通言語となるツールなのでUnityは本当に素晴らしいなと思います。
Atlasというフォルダにpngのパーツデータをドラッグ&ドロップしてUnityへ入れます。
ただ入れただけではこういう画面になるわけではありませんが、こんな感じで各種パーツを指定の画面に入れます。
画像を整えてレイアウト調整をします。
画面のサイズが変わった時にフッターやヘッダーがちゃんと画面の上下にくっつくようにしたり、端末毎に最適なレイアウトになるように設定するのも全てここで行います。(もちろん後に修正したりもする)
実際はこんな奥行きがあるわけではありませんがわかりやすいように大げさにZ軸入れました。画像の重なり順はこんな感じです。
こう見てみると階層がいくつもあって画像が重なっていることがわかります。この重なりが増えれば増えるほど重くなります。先ほど書いたようにパーツ分けを細かくしすぎるとここの階層が増えに増えて結果メモリの大幅使用に繋がるので分ける必要のないものは一つの画像としてまとめてしまうのが良いです。実際今見せている程度の重なりくらいでは重くはなりませんが、他に背景アニメや、ここにモーダルが表示されるなど様々な要素が乗ってくるので積もり積もってしまいます。
3.UIアニメーション作成
UIの配置が終わったら配置した画像に対してアニメーションを追加します。
アニメーションに関してはUIデザイナーがやるか演出の人がやるかはその時の忙しさや必要とされるアニメーションのクオリティによって変わってくると思います。遷移アニメーションくらいはUIデザイナーが作業することが多いです。
AfterEffectsやFlash同様キーフレームを打ってx,y座標やスケールなどでアニメーションを作成します。動かすオブジェクトを指定して、キーフレームを打った一連の流れをデータにしたものをアニメーションクリップと言います。ここでは例として左右に切り替えが出来るよ!と示すためのアニメーション(左右にぴょこぴょこ動くような感じ)を入れようとしています。
条件によってはもっと複雑な構造になる場合もありますが、シンプルな構造でUI遷移アニメーションを作成することにします。例えば、
【Open】この画面に遷移してきた時に再生する
【Idle】 この画面にいる間に再生する
【Close】この画面から離れた時に再生する
といったものです。
上のUIでこんなアニメーションを作ることにします。
【Open】
画面には背景とフッター以外何もない状態で開始(アルファ0にして消す)
タイトルヘッダーが左から右にスライドイン、続いて物語の黒い帯が右から順番に一つずつ連続してフェードインして今の並びになり、矢印が左右に展開する。
【Idle】
矢印がぴょこぴょこ動く、背景の雲がアルファと合わせてゆっくりと左右に動く。
【Close】
矢印が消え、物語の黒い帯が左にフェードアウト、タイトルヘッダーが左へスライドアウト。
これをそれぞれUnityでキーフレームを打って作成し、アニメーションクリップとして保存します。
4.アニメーションステート追加
さてさて、長かった組み込み作業もこれで最後です。
次に、先ほど作った【Open】【Idle】【Close】アニメーションクリップをどのタイミングで再生するか指定してあげる必要があります。これをやってあげないとゲーム側は作ったアニメーションをどこで再生すれば良いのかわからず、ただパッとUIが表示されるだけになります。
ここはフロントさんがやってくれる場合もあったりしますがこの工程までやってあげるとキリが良いかな〜と思います。
上の画像の明るい部分にアニメーションステートと呼ばれる長方形とその間に矢印が存在していると思います。
このステートが、今作っている画面にユーザーが入ってきてからEntry→Open→Idle→Closeという順番にアニメーションが再生されることを示しています。
そしてOpenステートとIdleステートの間の矢印にOpenTrigger、IdleステートとCloseステートの間の矢印にCloseTriggerをそれぞれ追加してあげることでOpenアニメーションが終わったらIdleアニメーションに移行し、他の画面に遷移するボタンをユーザーが押した瞬間にCloseTriggerが引かれてCloseアニメーションが再生されて別の画面へ遷移するという構造が出来上がります。
正確にはTriggerをただここに追加するだけではそうは動かないのでここまで作ったら作業を保存してフロントさんに渡せば(Gitにコミットし、プルリクエスト)スクリプトを繋いで実際のゲームの挙動のような動きになります。
5.最後に
いかがだったでしょうか。以上がゲーム開発におけるUIデザイナー視点でのデザインからフロントエンドエンジニアさんに渡すまでの、大枠よりちょっと踏み込んだフローになります。
正直、細かいことを言い始めるとまだまだ足りない部分が多いですし、プロジェクトのフローによっては作業領域も変わってくるのでUIデザイナー全員がこれをやっているというわけではもちろんありませんが、ゲーム開発に関わってない人やUIの領域じゃない人、UIデザイナーでもまだこれから実装周りやろうとしている人などのお役に少しでも立てれば嬉しいです!この記事でゲーム開発のUIデザイナーがどんな作業を行なっているのかなんとな〜くでも理解していただけたら幸いです!!
引き続き16日以降のアドベントカレンダーもよろしくお願いいたします!
この記事が気に入ったらサポートをしてみませんか?