テラシュールブログ

旧テラシュールウェアブログUnity記事。主にUnityのTipsやAR・VR、ニコニコ動画についてのメモを残します。

【Unity 】Unity Collaborate のScene・Prefab マージ機能テスト日記

以前グローバルゲームジャムでCollaborateを使用したのですが、単一のシーンをみんなで一斉に弄りまくってたのに競合が起こらなかったので、少し実験。

詳しくは後日まとめる予定。

 

オリジナルなシーンとPrefab

f:id:tsubaki_t1:20170330032358j:plain

f:id:tsubaki_t1:20170330035825j:plain

同一シーン・別オブジェクトの変更

ユーザー1による改変。

具体的にはステージの物を配置しまくる。

f:id:tsubaki_t1:20170330032548j:plain

ユーザー2による改変。

具体的にはUIを編集。終わったらPublish。

f:id:tsubaki_t1:20170330032620j:plain

ユーザー1、更新が来たので反映。

反映後シーンのリロードを要求されたのでリロード

f:id:tsubaki_t1:20170330032811j:plain

f:id:tsubaki_t1:20170330032906j:plain

ユーザー1の環境にユーザー2の変更したUI情報が反映される。

f:id:tsubaki_t1:20170330032916j:plain

同一シーン・同一コンポーネント別パラメータの変更

ユーザー1、文字の色が気に入らないので変更

f:id:tsubaki_t1:20170330033142j:plain

ユーザー2、文字の内容とフォントを変更

f:id:tsubaki_t1:20170330034140j:plain

ユーザー1、合体。

f:id:tsubaki_t1:20170330032811j:plain

f:id:tsubaki_t1:20170330032906j:plain

ユーザー1のカラーとユーザー2のフォント・テキストが反映

f:id:tsubaki_t1:20170330034752j:plain

単一Prefabの同時編集

同一のPrefabを同時編集。

 

ユーザー1、Colliderは要らないと主張

f:id:tsubaki_t1:20170330035912j:plain

ユーザー2、Playerコンポーネントを追加

f:id:tsubaki_t1:20170330035940j:plain

合体

f:id:tsubaki_t1:20170330032811j:plain

Colliderが削除されPlayerコンポーネントが追加された物が残る

f:id:tsubaki_t1:20170330040010j:plain

単一コンポーネント別パラメータも似たような感じ

同一のオブジェクトの同一のパラメーター編集

f:id:tsubaki_t1:20170330041129j:plain

デデーン。要マージ(そりゃね)

f:id:tsubaki_t1:20170330041814j:plain

オブジェクト構造の変更

ユーザー1、こだわりのUI色変更

f:id:tsubaki_t1:20170330041622j:plain

ユーザー2、UIの一括操作を可能にするためにUIに親オブジェクトを配置

f:id:tsubaki_t1:20170330041652j:plain

f:id:tsubaki_t1:20170330032811j:plain

ユーザー1の色とユーザー2の構造が反映

f:id:tsubaki_t1:20170330041736j:plain

同一メッシュやテクスチャのインポーター設定同時操作

f:id:tsubaki_t1:20170330044118j:plain

f:id:tsubaki_t1:20170330041129j:plain

異なるパラメータであっても、多くのものが追加・削除されるっぽいのでコンフリクトを起こす。

YAMLマージ範囲外?

注意点

マージはファイルに対して行われるので、他の更新を反映する前にProject Save。

保存してないシーン・保存してないPrefab等があると値が巻き戻る事がある。特にPrefab等のアセット。

マージ作業はYAML直編集。構造変わってても競合部分だけ提示してくれるので作業自体は楽だが、文字ベース。

関連

tsubakit1.hateblo.jp

tsubakit1.hateblo.jp

【Unity】公式の「テキストベースなアドベンチャーゲーム」を作るチュートリアル

f:id:tsubaki_t1:20170328221244j:plain

先日、ついにUnity公式のテキストベースなアドベンチャーゲームチュートリアルチュートリアルムービー一覧に追加されました。

「テキストベース」なアドベンチャーゲーム

テキストベースなアドベンチャーと言えば、現状日本製のモバイル・コンソール(AAAは除く)の殆ど全てのゲームで搭載されてしまっている、あのシステムを思い出すでしょう。

f:id:tsubaki_t1:20170328224300j:plain*1

とにかく「テキストを読む事でゲームが進行する」奴です。
「ノベルゲーム」「テキストベースゲーム」「ダイアログゲーム」「ビジュアルノベル」「エロゲー」「ダイアログゲームフォーティーンエイジャー」「ノベルモード」「会話シーン」等々、名称は様々です。最近ではこういったシステムはRPGとかにも普通に積まれてたりするので個人的には驚きです。
 

このチュートリアル、名前に「テキストベース」と付いてるのは、以前に公開された3D アドベンチャーゲームとの対比なんでしょうか。

tsubakit1.hateblo.jp

何にせよ、早速チュートリアルを覗いてみます。

Creating A Text Based Adventure Game

Creating A Text Based Adventure Gameは、テキストベースのアドベンチャーを作るチュートリアルみたいです。

 

動画は下のリンクより見れます。ちなみに全文英語

 

 このチュートリアルを通すと、
こんな感じのテキストベースアドベンチャーゲームが作れます

f:id:tsubaki_t1:20170328221201g:plain

 

違う、そうじゃない。

 

チュートリアルの内容

思ってた物と450度くらい違いましたが、まあ一応テキストベースゲームです。

一応この内容はScriptableObjectを活用したテキストベース(選択肢にテキストを打つ系の)ゲームのチュートリアルみたいです。

ScriptableObjectにテキストや状態、アクションを格納してゲームの進行を管理する感じの方法を紹介するんじゃないかなと思います。*2

 

内容としては、多分こんな感じっぽいですが、実際には不明。

  • ゲーム内での(テキストの)入力とリアクションについて
  • 文字列を始めとした、ゲーム内データの運用方法について
  • デリゲートパターンを使った柔軟なゲームの作り方

f:id:tsubaki_t1:20170328225740j:plain

ざくっと動画飛ばし見した感じ、ほとんどスクリプトを編集する画面に終始します。色々と応用は効きそうではあるので、気が向いたらチェックします。

関連

そういえば自分の以前作った適当なやつも粗が目につくから作り直したい感

tsubakit1.hateblo.jp

unity-chan.com

そういえばAngryBots(Unity 3系の同梱ゲーム)の性能不足時の隠しモードも、こんな感じでした。

tsubakit1.hateblo.jp

ビジュアルノベルアセット

https://www.assetstore.unity3d.com/jp/#!/search/page=1/sortby=popularity/query=category:157

 

今日の教訓:虫歯治療は痛みを伴うので歯を大切にしましょう*3

*1:画面は脳内で妄想中の物です。今回紹介してるチュートリアルとは余り関係がないかもしれません

*2:まだちゃんと見てない

*3:奥歯は麻酔が効きにくいとか聞いてない

【Unity】ゲームのビルド直前に "ファイルの退避" や "シーンの最適化" 等の処理を挟む

今回はUnityでゲームをビルドする前にプロジェクトやシーンに何らかの処理を行い、、ビルド完了後に戻す方法についての紹介です。

Unity 5.6以降で動作します。

f:id:tsubaki_t1:20170328003531g:plain

作る際に便利なものとパフォーマンスに良いもの

ゲームを作る上では、多くのパラメータが露出し細かく分割出来ている方が良いです。しかし、作りやすい構造がパフォーマンスに良いとは限りません。

 

例えば、ゲームオブジェクトをシーン内にばら撒くのは良くないのでGameObjectをフォルダのように使い構造化する手法はよくやることですが、これはパフォーマンス的に良くありません。

f:id:tsubaki_t1:20170327225059j:plain

またUIのEvent Systemのような物は各シーンについていると検証が何かと容易ですが、ビルド後にWarningを発行したりしますし、SingletonMonobehaviourを使用している場合も「生成・破棄」のコストがかかります。*1

 

同様に、ResourcesやStreamingAssets等、入れとくと何かと便利だがビルド時には必要ない…といった物も存在します。

例えばMovieTextureはVideo Playerと異なりiOSAndroid といったモバイル環境では動作しない為、Handheld.PlayFullScreenMovieを使用し、ハードウェアのムービー再生機能を直接叩く必要がありました。その為、基本的にStreaming Assetsフォルダに直接格納する必要がありました。

しかし逆にStandaloneやWebPlayer(故)といったプラットフォームにはフルスクリーンで動画を再生する機能が無いのか、Handheld.PlayFullScreenMovieは使えませんでした。

f:id:tsubaki_t1:20170327230522j:plain

で、5.6から

PostProcessBuildAttributeというAttributeとは別に、

  • IPreprocessBuild
  • IProcessScene
  • IPostprocessBuild

というInterface が追加されました。

ビルド前とビルド後に処理を行う(全体)

ゲームのビルド前後に処理を行う場合、IPreprocessBuildIPostprocessBuildを利用します。

このインターフェースが定義しているAPIを実装すると、ゲームをビルドする際、ビルド前とビルド後に処理が実行されます。

 

例えば下のコードでは、StreamingAssetsに格納されている01.pngというファイルをビルド直前にStreamingAssetsから取り除き、ビルド完了後に元の場所に戻しています。

 

gist.github.com

f:id:tsubaki_t1:20170327232006j:plain

この処理ではファイルを直接操作しているため、ビルド完了後に巻き戻さないと元に戻りません。これはPrefabやScriptableObjectを操作した場合も同様です。

 

例えば下の画像では、PrefabのTextをResorucesに格納し、ビルド時に内容をTextからHogehogeに更新しています。これで変更された項目はUndoで戻せないので、OnPreprocessBuildで変更した物はOnPostprocessBuildで巻き戻す事にするのが良さそうです。

f:id:tsubaki_t1:20170327233323j:plain

ビルド前にシーンの変更

シーンの場合は、IProcessSceneでシーンを構築する前に各シーンの内容を更新できます。対象は、ビルドに含まれるオブジェクト群です。

この処理では、この場でシーンに対して加えた変更もビルド終了後に変更前の状態に戻るみたいです。なお、呼ばれるのは少なくともライトが焼かれた後みたいです。

 

下の例ではビルド時に以下の処理を行ってみました。

  • bakedなライトを全て排除
  • 親子関係で整理されているオブジェクトをシーンにばら撒き
  • コンポーネントの無いルートオブジェクトを削除

gist.github.com

この結果、GameObject数は減り、子を動かした際にかかっていた負荷が減る(規模によってはシーンロードの高速化も)訳ですが、見た目にはほぼ違いはありません。また、ビルド後に元の状態に戻っています。

場合によってはコンポーネントの削減やメッシュの結合等も有りかもしれませんし、missingを探す処理を入れても良いかもしれません。他にも色々とアイディアがありそうです。

f:id:tsubaki_t1:20170328002307j:plain

この手法の問題点は、シーン構築の際の中間状態が見えないという点です。

上のビルド後は「予想」となっている通り、シーン構築時に行う処理を取り出して現在のシーンに投げてみた結果です。ビルド後の結果は「正しく動いたかどうか」でしか判別出来ないので、注意しながら処理を実装する必要がありそうです。

処理の実行順

処理の実行順は当然下の順です。

  1. IPreprocessBuild
  2. IProcessScene
  3. IPostprocessBuild

ただし、複数合った場合、callbackOrderで呼ぶ順を制御します。小さいものから順に呼ばれます。

f:id:tsubaki_t1:20170327223847j:plain

関連

tsubakit1.hateblo.jp

tsubakit1.hateblo.jp

qiita.com

*1:意外と知られてない事ですが、パラメータの多い項目は生成・破棄のコストが割高です

【Unity】知っておくと少し便利な Profiler に関する小技集

今回はプロファイラーの小技についてです。

プロファイラー小技集

プロファイラーを使うとゲームのボトルネックになっている場所を探したり出来ます。
今回は、その機能に関しての幾つかの小技についてです。

tsubakit1.hateblo.jp

CPUとGPUの使用時間を確認

CPU UsageとGPU Usageが出ている時に、CPUとGPUの使用時間が確認出来ます。

これが16.msを超えてたら60FPSを割ってますし、33msを超えてたら30fpsを割っています。超えてない方を減らすことは(消費電力以外では)意味が無いので、FPSが欲しいなら超えてる方を削ります。

f:id:tsubaki_t1:20170326204417j:plain

表示する項目を増やす・減らす

プロファイラの項目右上にある「☓」ボタンで、プロファイラの項目を閉じる事が出来ます。逆に Add Profilerトグルボタンで、消したプロファイラの項目を表示する事が出来ます。

 

プロファイラの項目の高さは拡縮出来ないので、よく中身を見たい時等に便利です。

なお、表示していないと情報がたまらないプロファイラの項目もあります。

f:id:tsubaki_t1:20170326194646j:plain

CPUプロファイラの表示項目を隠す

CPU Usageの項目では、プロファイラが表示しているカテゴリを有効・無効にする事が出来ます。

Others等は条件によっては無視しても良い(しかも上下しやすい)項目なので、非表示にしても良いかもしれません。

f:id:tsubaki_t1:20170326194951g:plain

また表示項目も減らせます。項目を右クリックすると表示する項目一覧が表示されるので、チェックされている項目を減らせば非表示になり、スッキリします。

特に現状ほぼ機能してるとは言えない Warningの項目は、無くても良いです。

f:id:tsubaki_t1:20170326200035j:plain

CPUプロファイラの表示順を変更する

CPU Usageに表示しているグラフの項目順序を変更します。

VSyncのような「CPUの余り時間で上下する項目」がグラフの下の方にあるとグラフが非常に見難くなります。こういった項目は順番を上の方にして置いたほうが良いです。

f:id:tsubaki_t1:20170326195214g:plain

負荷のあるオブジェクトがドレかを確認する

Referenced Objectの項目で、オブジェクトを選択すると、どのオブジェクトが負荷を計上してるのかを確認出来ます。

当然、オブジェクトが消滅してしまったら追えません。

f:id:tsubaki_t1:20170326203138g:plain

Timelineで表示する

CPU Usageの項目をタイムラインベースで表示します。

一見負荷が高くても別スレッドで処理しててメインには少ししか関係無かったり、逆に処時間が少なくてもコア全て使って一斉に計算してたりする項目が見つけられます。

f:id:tsubaki_t1:20170326201451j:plain

選択項目に合わせてTimelineの範囲をズームする

項目を選択してFキーを押すと、選択中の項目が画面いっぱいになるようにズームします。逆に何も選択していなければ1フレームになるようにズームします。

f:id:tsubaki_t1:20170326201643g:plain

アセットを参照してるオブジェクトを探す

予定にないアセットがロードされてる時、どのコンポーネントがロードしているのかを確認出来ます。

tsubakit1.hateblo.jp

Pforilerのプロファイリング内容をSave&Loadする

たしか5.6から、PforilerにSaveとLoadが追加されました。

以前はリモートのプロファイリング内容は実機側で保存する事しか出来ませんでしたが、SaveとLoadが付いたのでエディター側でも保持出来るようになったっぽいです。

f:id:tsubaki_t1:20170326203632j:plain

qiita.com

関連

tsubakit1.hateblo.jp

tsubakit1.hateblo.jp