【 講演者 】
樋口 雄一
株式会社セガネットワークス アート＆デザイン部
リードデザイナー
ジェットセットラジオシリーズ、龍が如くシリーズを担当 デーモントライヴではデザインリーダー及びテクニカルアーティストを担当。
【 講演内容 】
Unityを使ってハイエンドなモバイルゲームを制作することがどういうことで、どんな問題点が生じやすいか、といった内容をメインとする事例紹介。シェーダー制作に関するTIPSもあります。Unity上での工夫についての事例も多数紹介します。
【 詳細情報 】
トラック会場4:学生・団体
http://www.android-group.jp/conference/abc2013a/conference/academic/#anc_sess34
Summarize this content in Japanese はじめましてセガネットワークスの樋口と 申します 今回はセデックから 要望を受けましてメイキングオブデーモン ドライブ Unityによるハイエンドモバイル政策 というセッションこれはセデックの 2013で先日発表したのとほとんど同じ 内容なんですけれどもそちらの再演をさせ ていただくことになりましたよろしくお 願いします 早速自己紹介なんですけれども私 株式会社セガネットワークスのアート アンドデザイン部でリードデザインがやっ ております樋口と申します 業界歴結構長いんですけれども デーモンドライブの中ではデザイン リーダーとおよびテクニカルアーティスト というプログラマーとアーティストの 橋渡しのような仕事をやっております 具体的な内容としましてはデザイン業務の フローの構築 シェーダーの作成それからデザインの アセットのクオリティチェックなどを行っ ています 業界結構長い16年目ぐらいなんです けれども昔のハード向けの開発からまあ サターンとかから始まって今はモバイルの 方までやってるような感じになりますつい この間はでは 龍が如くのチームにいてイベントシーンと かをやっておりました 今回の内容なんですけれども Unityで開発をするにあたりまして 欲しかった情報でありましたり Unityを使ってこれはどうやって作っ ているんだろうこうするといいよみたいな 情報を集めておりますでメイキングなん ですけれどもどっちかっていうとゲーム 制作のデータをどうやって作って るっていうような内容はかなり少なくなっ ておりますで下にも書いてあるんです けれどもセデックでの同盟公演の再演なん ですけれども今回ちょっと時間が出てくれ は60分いただいたんですが今回ここ40 分ということでしたのでいくつか資料を 割愛して公園となります 先行して公開している資料は 非表示として全ての資料を公開しており ますのでこちらご報告で見ていただければ なと思います 中身につきまして マザッド全ての内容に関して 触れていくような感じですねデーモン ドライブというゲームの紹介から始めまし
てスペックそれからのキャラクター モーションバトルの背景エフェクト ユーザーインターフェースそれから シェーダーの最適化なども含んでおります そういったものに触れてどんなふうにやっ ているかご紹介していきます まずはゲームの中身を相当 あくまで戦い エージェントを選び デルモンを頂いた 仲間と 敵を駆逐する レーモンのケチッとなる 巨大な力もありました 京急本拠地を破壊せよ 今世界を揺るがす戦いが 幕を開ける 以上のようなゲームになっているんです けれども こちら今 iOS 版も出ておりまして 2013年の2月28日からAOS版が先 に先行でリリースしておりましてつい先日 の8月からですね Android版を含めてバージョン 2.0として配信中です無料でフリーズ プレイの ビジネスモデルとして展開中のタイトルと なっております 開発自体は 昨今話題になっておりますUnityで 開発しております開発がちょっと 最近はもう4.0系列が 唯一使われている方も多いと思うんです けれども開発始めた頃にはまだ3.5系列 でしたのでそのまま3.5で継続して いる感じですゲーム内容としましては ポリゴンモデルで作られましたデーモンを 集めましてそのデーモンをいくつか 答えまでデッキに入れることができまして そのデッキを持ってバトルに進んでいき ましてバトルの中でそのデーモンに プレイヤーが変身してデモ同士で戦うと いうような協力バトルのゲーム 協力バトルのゲームになっております対戦 もできるようになっております 3G回線とかwi-fiとかを通じて配線 が行うことができます ゲームのスペックなんですけれども だいたいこのような感じの 装填数枚があまりと目標に作っております これ自体は 以前オートデスクさんで行っていただいた 3DCDツールとUnityによるゲーム
開発実践セミナーというものがあったん ですがそちらで発表されていた内容が かなり役立っておりますその時点での情報 をスタートとして プログラマーと 環境の 検証を行いながら数字を具体的に決めて いったという感じになっております 骨の数はここでかなり少なく設定している んですけれどもこれに関しましては ドリームキャストなどの ロースペックハードが主流だった頃の経験 が生きております この辺を目標として開発を進めていたん ですが実際どんな感じかと言いますと これは UnityPlayerでの 実際の数字ですね Unityでは プレイヤーそのPC上のプレイヤーで再生 するときに その描画がどのように行われているか数字 で見ることができるんですけれどもこれが そのアップになってる部分がその実際に 描画されている数字です先ほどの4万頂点 が1フレームを原動っていうようなところ に関しましてここの数字で言うと 書いてある3行目のところの22.5計 22,000500ですね頂点が描画され ていることになっております ドローコードというのがだいたい100を 目途に 考えておりましたけれどもここですと69 になっておりますこの辺の数字は描画の 行われているキャラクター数であったり エフェクトの数によって リアルタイムに前後するんですけれども だいたいまあ目標に沿ったような形で構築 できているかなと Android上でどのぐらいのスペック で動いているかはあまり細かく検証できて ないなとも言えないんですけれども IOSを例にしますと iPodtouchの第4世代とかで ギリギリ 遊べるかなっていうような感じのフレーム レートで動いております スペック決めの中身に関しまして 同時制御のキャラクター数に関しましては 実機でベンチマークテストをしながら数を 決めていったんですけれども当初の最終的 には プレイヤー系が6体 合計が20体というような形に 収まったんですけれども当初はもう
ちょっといっぱい出したかったなという ところでしたがこれに関しましては Unityの中でのナビメッシュという もので 地形とのコンタクトを取りながら目的の 場所にナビゲートされてキャラクターが 移動するというコントローラーがあるん ですがそこのコントロールがかなりCPU を持ってきてしまうので最終的にこの数字 しか出せなかったかなと 現在出てるハイスペックカードを使うと もうちょっと人数出しても大丈夫なのかな と思いますしあるいはナビメッセージを 使わないで動かせばもうちょっとでもいい のかなと思いますそれから一層点あたりの 防音数キャラクターの中に入ってるボーン 数が頂点に当たって保安が何本入ってる かっていうようなちょっと専門的になっ ちゃいますけれどもそれに関しましては 当初2ボーン つまり 日本の骨で1頂点を動かしますので割と 滑らかに動かせるような最低限の設定を 考えていたんですけれどもこれも無条件の 音と関係しましてキャラクター数を なるべく出したいというところでCPUの それを開けたいというために 1本にしましたでなのでこれをかなりこれ 以上軽い計算はないぐらいのところの設定 なんですけどそこまで やってなるべくキャラクターが出るように 設定したという感じになっております ちなみにナビメッシュによるコントロール でCPUが辛いのは iPodtouch4ぐらいのかなりロー スペックなハードでどっちかっていうと それ以降のもうちょっとCPUが早くなっ てくるハードになってくるとそうでもない のかなと すいません逆ですね CPUもかなり持ってくんですけど ロースペックハードだと描画の方でも持っ てかれちゃっても似たようなものですねで ハイスペックハードになってくると描画は 回るんですけどCPUの方はどうやっても 重いっていうような感じでどっちかって いうと足かせになるのはCPUになったか なと いう キャラクターのシェーダーにつきまして キャラクターが売りとなるゲームなんで 専用のシェーダーをかなり多く用意して おりますちょっと文字だけで分かりづらい んですけども次に絵が出るのでちょっとお 待ちください機能的には
リアルタイムライティングとテクスチャー のライティングを組み合わせて リアルタイムのライティング結果をもとに テクスチャーをピックアップして色付けを するようなものいわゆるトゥーン レンダリングみたいなをメインとしまして それに加えて送り状系の情報を テクスチャーのアルファに埋めることで 凹凸の表現を入れています マークマップの会話みたいなものです もしそれに加えて 地面からの反射光表現を入れてもう ちょっとリッチな感じにしたかったので これに関しましては 0地点からの グラデーションで下から上に グラデーションを入れることで 反射光風に入れて見た目を良くしています それとまた 独自のもので UVスクロールを入れてキャラクターの見 た目を良くするとかですねそれから特定の α8部分を指定の色に置き換えることで パレットチェンジのようなことをやったり それから グリーンによる簡易計算ですけれども スペキュラのものを入れたり 基本的な半透明それから 洗濯時にキャラクター選択時に輪郭線を 出したかったので本線 プッシュによる 輪郭線表示それから先行現代人これはまあ 素材レンダリング用のちょっと重いもの ですけれどもそれから リムライト式で輪郭線を 検討した時の持つ点もありましたけれども いくつかの機能を 検討しながら最終的に20種類程度になっ たかなというところです こんな感じですね 左上の1番というのが 割と一般的なグローのものでこれ比較対象 としてみてくださいで2番目のものがその Googleにテクスチャーが貼ってある もので この辺もまあ基本的なものでうちのゲーム では使ってないですねで3番目になって いるものこれが テクスチャーライティングのロックアップ を使ったものでややトゥーン気味なという か通常のグローとは違ってもうちょっと はっきりとした陰影のといったものになっ ておりますで4番が地面からの グラデーションがついてよりイラスト チックな見た目に
なって5番のものが輪郭線をつけたもの6 番目も輪郭線のバリエーションで 体の部分が透明になって線だけが描画さ れるような星団ですねそれから7番が スペキュラライジングがついてるもの8番 が 抵抗権のランキングがついてるものって いうような形で 昨日別にいくつかドライビングの関数を 作りましてそれを取捨選択するような形で 周りを作ったという感じになっております 続きましてこれが特定のアルファー値を 好きな色に設定可能なセーターです これ正座によって色付けをしているので テクスチャーこのキャラクターに設定して いるテクスチャー自体は共通のものになる んですけれどもシェーダーに与える パラメータを変えることでこのように体に 入った線がいろんな色に変わっているのが わかるかと思いますこれを使って同じ テクスチャーを使ったキャラクターなん ですけれども 敵陣と味方人によって青だったり赤だっ たりというようなチームカラーを反映する ような感じにしておりますゲームで実際に 使っているのは左上2つの青と赤だけなん ですが バリエーションとしてどんな色でも出せる よというような状況を作ってみました キャラクターのシェーダーにつきまして Unity用で星座を書いていたんですが 作業自体は3Dツールのソフトイメージの 上でモデリング作業などを行います 3Dツール上でもUnity側と同じよう な見た目をできた方が作業効率がいいので そのためにglslレーダーというもので 正座を作りましたでこれがですね Unityは サンプルコードを見るとCGでのソースが 多いですけれどもglslでもセーター かけますので本当であればglslで正座 を用意してソフトイメージ柄とも共有した 方が良かったかなと後から気づいたんです けれどもそのように思いました が ネットで検索するとCGのセーターコード ばっかり出てくるんで 解きやすさで言ったらCGの方かなという 感じですね それからこれはちょっとUnity側の 機能になるんですけれどもキャラクター 選択時の輪郭線を別シェーダーで用意し て 輪郭線ありと輪郭線なしのマテリアルを 用意しておいてそれをキャラクター
選択した際に輪郭線ありのマテリアルに 切り替えるというような風にして制御して いますこれは何でかと言いますと シェーダーのアサイン出た要素を直接行動 で切り替えることもできるんですけれども そうしますとマテリアルに与える パラメータ自体もコードから 即で指定しないといけなくなるので 設定が複雑になってしまうという問題が ありますなのでシェーダーの差し替え自体 をプログラムでやるよりかは 静断設定がされているマタイによるを複数 用意してマテリアルを切り替えると言った 方がアーティストも幸せになれるし プログラマーも単純になるかなという ところです それからあともう1点シェーダーの 差し替え自体はですね正ラーメンをモデル 数として与えて切り替えるというような Unity側の命令になってますのでそれ もちょっとあまりスマートではないかなと マテリアルを切り替える場合には マテリアル名を与えるんではなく マテリアルの何ですかね アサインを変数で与えておけばそのまま それを入れられるので名前を使わないでも いいかなというものです キャラクターの星座でもう一つ 障害物に隠れた時にシルエット表示をして いるんですけれどもこれは Unityの星団の中にはなかなか ちょっと良い機能がありましてテストを 使って 描画パスを切り替える機能があるんですね そうしますと Zテストの今これグレーターって書いて ありますけれども 障害物に 隠れてずっと値が 当該物によってキャラクターよりも手前に あるか奥にあるか手前にある場合にはこの 今書かれてるパスで描画をすると 奥になってる 障害物に隠れてないベッド値の場合には 本来のセーターで書くというような感じで 設定しておくとこのように分岐した感じで 絵を描くことができますそうしますと シルエットの時のパスワードとか シルエットになってない時はこのバスって いうような形でこのように違う結果を出す ことができますこれやると結構 隠れてもキャラクターの位置がわかるので なかなか良かったかなと思っております これはコメントアウトしてあるカラーの 部分で直接色の指定をして描画することも
できるんですけれどもシルエットを使う シェルターが複数にわたっている場合には ここで直で変えてしまうとまとめて シルエットの色を変えたい時にちょっと 面倒が出ますので 一応最終的にはここまでプログラム プログラムCGプログラムのインクルード が書いてありますけどここのインクルード の方に色設定をしたシェーザーコードを 書いてそれをみんなで 参照するような形でまとめて色を変え られるようにしておきました キャラクターにつきましてテクスチャーな んですがこれと多分1個前のセッションで 同じように pvrの圧縮に関してのセッションがあっ たかと思うんですけれども pvrで圧縮する際に αを含んだテクスチャですと αの 圧縮精度が 著しく欠落することがありましてその場合 このアルファに重要な情報が入っている テクスチャーを圧縮する場合には アルファーの部分とそれ以外の部分を 切り替えて 素材を作った方が綺麗に出してできると いうことがありましたので 先ほどのアルファーの特定値の部分の色を 変えるっていう 星座に使ってるものに関してはそういう 切り替えた設定をしてシェーダー側で元に 戻して 解釈するようにしまし たこれをやることで全然ビット数が違うん ですね登録されている ということでこのようにしていますただ Androidの場合はpvrを使うこと がほとんどないのであんまり関係ないかな という感じですね Androidでやる場合にはETCとか 使っちゃうとαは関係なくなってますし αスカートと思ったら16ビートで上がっ てしまうかなと思うので 切り替える意味もなくなってくるかなと 思いますけれども このようにしておりました モーションのインポートに関しましてこれ はUnity側の話なんですが Unity側の注意としてカーブのタイプ がインポートできないですね3Dツール上 でカーブの形式を リニアであったりとかコンスタントであっ たりとか設定することがあると思うんです がその通りに入ってこないですね
デフォルトはオート+フラットというよう な設定の 今ここの図で言うと一番左側に近いような 形でインポートされてきますこれで 場合によってはコンスタントに変えたりと かした場合があるんですが コンスタントの設定が壊れる場合があるの でちょっとご注意ください一番右側のよう にカーブが上に飛び出たような感じの壊れ たものになりますこれは トランスやスケールのカーブの場合には 正しくコンスタントの設定もできるんです けれどもローテーションに設定しますと右 のように壊れてしまいますので ローテーションカーブをコンスタントに するときはこの3頭は諦めた方がいいかな と思います モーションのインポートでFBXから モーションをインポートするというような 作業が結構多いんですけれども 3Dツール上からFBX形式を通して アニメーションをインポートしますその時 にインポートされたアニメーションは リードオンリーになってしまうんですね そうしますとUnity側でその アニメーションを編集することができなく なってしまうのでちょっと注意が必要です でこの場合エディターのスクリプトを用意 してそのアニメーションをコピーすると 編集が可能になります コピーを作ってしまう以上をFBXとの リンクが切れちゃうんですけれども そのあたりご注意して作業すれば良いかな と思います コピーを生成する スクリプトに関してはここのURLにある ものが割と 有名です これを見ていろいろいじるといいと思い ますでこれを若干改造することで モーションの 濃度管コピーであったりとか名前を変えて リアサインするような作り方も作りやすい と思いますので これ見てみるとよろしいかと思います ゲームにつきものもゲーム情報を アニメーションに埋め込むというような ことがありますよくあるんですと例えば 攻撃の ダメージ値が発生するフレームはこの モーションでは何の略ですよとか 足音が鳴るフレームは何フレームですよと かっていうようなゲーム的に必要な情報を アニメーションに埋め込むことがあるん ですけれどもこれに関しては
Unityのサンプルでよくあるものは アニメーションにイベントを追加して イベントの方で関数をコールバックする ことで何らかの 処理をするっていうものがよく紹介され てるんですけれどもこれがちょっと手間が かかっちゃうんで面倒くさいですね 問題としてはアニメーションをコピーして 編集可能にした上でイベントを追加してっ ていうようなことが必要になる部分が問題 になりますで先ほどのFBXのもとデータ とのリンクが切れるという問題がありまし て何度もアーティストがアニメーションを 直すというような作業が発生しやすい ゲームの場合にちょっと見てないかなと いうことでデーモントライブではどうした かと言いますと別のコンポーネントを用意 しましてそちらにモーションの開始 フレームから7フレーム目に音が鳴ります よとかダメージが発生しますよというよう な情報を入れることにしましたこうします とアニメーションのコピーを作る必要も ないですし リンクも消えないただちょっと面倒くさい のがあるとすればその別コンポーネントに 設定した情報を拾ってでその時間に合わせ て何か何らかの処理をするっていうような 別の行動を作る必要があるというところが めんどくさいかもしれないんですけれども ただまぁ作業効率は上がるのかなという 感じがしています 背景の話ですけれども 昨今Unityの新任切り替えが 遅いという話がよく取り沙汰されて んですけれども シーン5を複数作ってシーンデータを 切り替えるというような作業がUnity ではその際にダメージコレクションが動作 してしまいますので 遅くなってしまうのではないかということ で作り始めた頃はその情報がちょっと あまりなかったんでっていうのもあって シーンデータで作っていたでもあったん ですが他にも理由がありましてライト マップの機能を使っているそれから先ほど 説明しましたナビメッシュの機能を使って いるという2点がありましたので デーモントライブとしてはやむを得ず 仕入れデータでゲームを構築してい ます主にバトルのシーンがステージごとに 変えるようになってましてバトル 以外のものはワンシーンでそこにユーザー インターフェースのプレハブを読み替える ような形で高速に動作するようにしてい ます
でですね 労働レベル時労働 信用労働する労働レベルの関数の時に ラベージコレクションが動作するのが遅い 原因なんですけれどもこれを動作させない でロードレベルアジティブというのものを 使う方法もあるんですけれどもこの場合に はライトマップのデータの更新に問題が あったりナビ飯のロードがされないという 問題もあってこれはちょっと使えてない 状態です プレハブとしてマップのデータを用意して おけばよかったかもしれないんですけれど もこちらもナビメッシュが使えませんので 今回は使えなかったという感じになります ライトマップに関してはデータの作り方に よって シーンデータに埋め込まない方法もあり ます そちらがこれなんですけれども 通常ライトマップをUnityで生成し ますとライトマップのテクスチャーへの スクリプト情報というものが 遅延データに保存されましてそれを使って モデルのUVと考慮してどのテクスチャー のどの場所のライトマップを 参照するかというようなことになってい ますこれによって市民データに 紐づくということになるんですけれども この紐付きをまたモデルに書き戻して あげるように改造すれば新データにライト マップが依存することはなくなりますので テストしたコードがコードじゃないなとし たシーンとかデータの説明がこのブログの 記事にありますのでご興味のある方は 後ほど見ていただければなと思います の問題で今回は使えなかったという感じ です エフェクトにつきまして ほとんど Unity標準の手裏剣のパーティクル あるいはモデルで作ったものを再生して いるというような形ですね1ドルから 2ドルをねかなり限界まで軽くしたような 形で作っていますこのサンプルの絵で言い ますと左と右に書いてあるものがパーティ クルですね真ん中のものがモデルの エフェクト になってモデルエフェクトの場合はワン モデルのエンベロープを使いますとワン ドローで描画できますのですごく軽いです 見た目が結構凝ってる割に軽く作ることが できます単純な形状の拡大縮小というよう な感じ 球状のものが明確であるとかそういうもの
に関してもパーティクルを使わないで モデルエフェクトを使った方が軽いかと 思います マテリアルのアニメーションは別物別物に SRTとして入れ込んでFBX以降ともに コンバートするようなことにしています 直接 Unity上で生成してもいいですけれど もデータをどこをですねソフティイメージ 上とかそのDCCツール側をソースにする のかNT側の作業をしたものを送信するの かというので作業効率変わりますので状況 によって モデルエフェクトの例なんですけれども これがパターン チェンジのシェードとモデルエフェクトを 使ったもので これ自体は手裏剣も絡んでるんですけども 手裏剣にワンモデルだけ生成するっていう のはパーティクルの設定をしましてその上 でパターンチェンジ自体は手裏剣の機能を 使っていますテクスチャーのパターンが 切り替わることで何かが集まって弾け飛ぶ というような テクスチャーが貼られるというような感じ にしています 真ん中の球状のものが膨らむのは スケールが入ってるからです ねというようなこんな表現力が書かれる ことが 組み合わせるとできます パーティクルだけの場合にはこのような 感じなんですけれども 融資の発生が少なければ少ないほどCPU が軽いですで1個を使ってるものが ほとんどで多くても10個同時に出す ぐらいになっています 1分1秒間かな1秒間に対する発生数を 設定するレートというものがあるんです けれどもこれはあまり使わないでバースト という機能を一度に一度にいっぱい出すと かっていうような方は設定が多かったかな と思います パターンチェンジを多用しましてそうし ますと1個しか粒子を出さなくても見栄え の良いエフェクトは作れる感じになります テクスチャーの面積を多用してしまうのは 問題にはなるんですけれども例えばこの左 で書いたような 駒 コマアニメのようなものを書きましてこれ をバラバラのテクスチャに並べましてこれ が切り替わるように設定しますと一番右 から動いても動いてませんけれども Unity以上でこういうエフェクトが
出せるという感じになり ますテクスチャーをいっぱい食ってしまう 問題の 対処法としまして同じテクスチャーの色 変えに関してはシェーダー側で色変えを サポートすることで対応しました 手裏剣で 標準に使われているパーティクルの シェーダーでは冗談で色を変えることも できますしそれ以外にこのサンプルの絵で 出てるような適度部分の色を変えるような 星座を 独自に用意しましてそれによって多少 フラグメントシェーダーに負荷はかかるん ですけれどもメモリーに関しての圧迫は 軽減されるかなり 綺麗な色のバリエーションが作れるという ことでテクスチャーがこれ同じエフェクト じゃないその色違いのエフェクトですけど 使ってるテクスチャーは同じというような ことはできるようにしまし たこんだけ綺麗なものが作れれば テクスチャ同じでもいいかなというところ です エフェクトの星座で小ネタなんですけど キャラクターに埋まっちゃうような エフェクトが出た場合に 埋まらせたくないとか 思う場合があると思いますでこれはそれを 解消する方法なんですが Unityの星団の機能で 描画順を設定したりあるいはその描画の際 に Zテストをオフにするその奥行きのテスト しないで一番手前に書いちゃうとかって いうような機能が簡単に設定できますこの 囲ってる部分ですねベッドテストをオフに してさらに描画を トランスペアレント+1 トランスペアレントが書かれる瞬間よりも 1個後の段階で書いてくださいという風に しますとかなりの確率で一番手前に書かれ ますのでこういう設定をするとエフェクト はかなりきれいに出せるんじゃないかなと 思います それからエフェクトのシェルターで パーティクル用の星座を作る時には頂点 カラーを使って色変化が与えられますので その点からを使って何らかの変化が起こる ように 星座を設計しておくと手裏剣側の設定が いろいろ使えていいですこの左側の図版 手裏剣の画面ですけれども スタートカラーとかですね一番下の方に カラーオーバーライフタイムとかっていう
部分で時間に対して色を変えたりすること ができますでこの値自体は頂点からに入り ますのでそれを考慮してセーラー側で頂点 から右の図では乗算をかけていますけれど も色を拾ってきて真ん中の処理をすると いうことで色のコントロールができやすい 集団になります ユーザーインターフェースにつきまして ですけれども時間大丈夫か もう終わりですか どうしようか 進めますユダインターフェースNGYを 使ってやっております フロー自体は作業フロー自体はクラシック なゲームの作りと同じような感じ でこんな感じの 縦に積み上げてスクロールするようなもの で設定しました 素材を作るフローが あんまり 確立しませんでしたのでいろいろこう ボタンはどういう風にした方がいいとかっ ていうのが先に考えておいた方がいいかな と思います 例えばボタン用の機能としてネーブルとか どうとかよくあると思うんですけれどこの 時にどういった効果が起きてどんなような 色変化が起きるとかどういった機能が 起きるというのを先に設定しとかないと 右だとボタンのUIとかを全部作り直して コード自体も書き直すことになっちゃい ますのでこの辺り決めとかないと配送構造 であったりが決まらないので作業が進んで やり進んでこっちへ行くこと Photoshopで作業しましてそれを 切り出したアトラスにして lgiでコンポーネントを作成して これの使い方 プレハブの使い方をプログラマーへ渡し ましてプログラマーでコリジョンの設定で あったり制御行動を含んでるっていうのは 作り方になってますなので Unityらしいのですかねこう インテリジェントな分業体制っていう感じ ではなくどっちかっていうとデザイナーは 絵だけ作って動かすのはプログラマーの 仕事っていうようなちょっとクラシックな 作りをやっておりました こんなような素材を作りましてこの濃度は どうなってますよって書いてその通りに プログラマーにお願いするっていうような 感じになっております ここの画像とプログラムの方多いと思い ますのでそんなこと言われても大変だよと かって思うかもしれないんですけど
ちょっと時間の関係でこのように作業して おりました これだと使い回しがあるような素材ですね あんまり頭いい感じではないんですけど それぞれ赤枠で作ったような素材を個別に 作ってこれを1個ずつ並べて UI作ってくださいねっていうような感じ でお願いしておりました Unityだとこのあたり個別に作った やつをいちいち並べていかないといけない ので機能的にはちょっと貧弱なんじゃない かなと思います 結局何でもできるんでしたっけ 20分まで ですね この辺りは飛ばしまして 星団の最適化に関してだと レーザーはシャドウバンのシェーダーが Unityの方式で 上がっていますけれどそれを 参考にされていくかとかをしてい ますなるべく枚数少なくすることが重要で さらにSurfaceshaderって いうUnity独自の製造構造があるん ですけれどもこれはちょっと使わない方が 最適化しやすいんじゃないかなと思います それから当たり前なのかな変数の精度を なるべく低いものを使うことで計算量を 減らして高速化していますモバイル用の 星座の設計はこの辺りが 重要になってき ますとだいたいフィックス動画ほとんど ですねただそのこの変数の Androidだとあんまり関係ないん ですけどIOSだと結構変数制度が大きく 実機とPC上と異なりますので実機 チェックやらないと結構ひどい目になり ますので正座を設計して作ったら 必ず実機で チェックした方がいいです このあたりは読んどいてください ということで最後なんですけれども すいませんね1本やるといろいろ見えてき ましたよくあの Unity系の発表で1本やるとわかり ますよということがあるんですけれども それは本当でした事前に聞いていても なかなかうまくいかないこともあったん ですけど情報あった方がいいと思いますの でこのような感じで情報をまとめており ますスマートフォンに対する基本的な知識 は別途必要でそれ プラスチックなハードディゾールと動かす かっていう部分が必要になってくるかなと で
昔のハードの開発経験がかなり活かせて いると思いますのでこんな感じで発表資料 はお役に立つと何よりですということで すいませんちょっと時間ぴったりで終わっ ちゃいましたけれど 質疑応答ですか何かご質問ある方 プログラマーなんですけど lgiの 画像と 画像のアーティストプログラマーの やり取りこうすればよかったなとか 思うんですけどはいもうちょっとここが 良くなくてこうすればよかったんですけど もうちょっと 詳しく教えていただければと思います Unityのngoiでのやり取りに関し ましては事前の資料のところで そこにあの慣れた時に基本的なコリジョン 設定だったりとか制御コンポーネントの 追加とかをアーティスト側で事前にセット してそれでプログラマーとデータの やり取りをした方がプログラマの作業を経 てよかったかなというふうに思って そうじゃない形でデータだけ作って絵だけ 作ってですねそれでデータを渡してはい 動かしてというような感じでしたのでこの 階層構造だと動かしづらい用途がっていう ことも何度かあってプログラマーの方で 制御構造とかこう階層構造を作り直して これでやっぱり直してっていうような やり取りも何度か発生したりしてましたの で 事前にそうですねプログラマーとどういっ た形で作業してどのようにデータを作っ たらいいかっていう相談をした上で作業 するのが一番いいのかなと思います アーティストさんがngaの行動だとかを 連絡だとかを触るまでは活かすとも細かい ギターで合わせが大事とかそうですね事前 のその階層構造自体の設計から大きく 変わってくると思いますのでそこのどう いった釣り構造でデータを作るのでどうし ましょうっていう相談をした上で作業を 始めた方が無駄はないかなと思います ありがとうございました 5時間となってしまいましたこれにて出力 の方法だったりコラボレーションの 応援をしようとさせていただきます次の セッションは5時35分よりmcpcの 樫山様にご相談いただきますそれでは樋口 様へコーチ長くしようお願いいたします
