今まで出来なかったxlsxのインポートですが、出来るようになりました。
特に設定するような事は無く、xlsと同じような感じでxls importer makerを開いて貰えばインポーターを作れます。
（ブランチ切って改良してくれた方に感謝）
それと、WindowsでExcel開いている時にScriptableObjectが更新出来なかった問題も解決しました。これで、excel編集したら即座に反映されるをWindowsでも使うことが出来ます。
次はexcel importer makerの生成コードやexcel imporeter maker自体のコードをもう少し綺麗にしたい所です。
Excel Importer Makerは本当はExcel > Scriptable Objectしてくれる機能ではなく、Excel > ScriptableObjectするコードのテンプレートを作って、後は自由にカスタマイズして下さいなシステムなのです（予定話
（このために、xls毎にインポーターを作るという、割と無駄な事をしています）
今回はUnityの標準UIシステムであるuGUIの改造方法についてです。
uGUIの各コンポーネントの挙動に＋αするだけであれば、uGUIの挙動を改造する必要が無いケースも多々有ります。
例えば、Textコンポーネントに少し追加して、テキストコンポーネントの参照先を元にローカライズする等のシステムを考えた場合、Textを継承したコンポーネントとUnityEngine.UI.TextEditorを継承したコンポーネントを用意すれば、追加アクションを行うコンポーネントを用意出来ます。
但し、これでは十分でないケースも多々あります。例えばスクロール中のイベントに少し手を加えたいとか、そんな感じ。
uGUIのコード自体はオープンソースとして公開されているので、そのコードを利用してuGUI自体を改造してみます。
作業を始める前に、バックアップを用意しておきます。
今回の手順ではUnityの中身を改変するので、もしバックアップを取っておらずに事故を起こすと、最悪再インストールになります。
MacはUnity.app/Contents/UnityExtensions/Unity/GUISystemをどこか適当なフォルダにコピーしておきます。
WindowはUnityのパス\Data\UnityExtensions\Unity\GUISystem\です。
今回の手順でおかしな挙動をしたら、このバックアップを元に戻します。
uGUIのコードはBitbacketのUnity Technologies/Unity/UIにて公開されています。まずはコレを取得します。
取得する場合ダウンロードではなくクローンをお勧めします。何故かと言えば、Unityのバージョンアップ時に変更点を追うのが比較的楽になるからです。あとバグがあった時に治しやすいです。
という事で、クローンします。...からのクローンで、SourceTreeにクローン。
次にブランチを自分の使用しているバージョンに合わせます。これ合わせてないと変な動きとかするかもしれないので、一応。
早速、ソースコードを開いてビルド・既存のuGUIを自前のuGUIで上書きしていきます。
まずはUISystem.slnを開きます。ただ単純に開いた場合はUnityでコード編集時にプロジェクト開き直してくれちゃうので、別プロセスとして開きます。
open -n UISystem.sinのパスで開きます。Monodevelopは。
この後、UI Systemのソリューションを選べばUISystem.slnが起動します。
続いて、DLLの出力先を設定します。
まずはUnityEditor.UIを右クリックして、オプションを選択。
ビルド＞出力タブを選択してUnity.app/Contents/UnityExtensions/Unity/GUISystem/Editorを選択します。
同様に、UnityEngine.UIはUnity.app/Contents/UnityExtensions/Unity/GUISystem/Standaloneを設定、
UnityEngine.UI-EditorはUnity.app/Contents/UnityExtensions/Unity/GUISystemに設定します。
後はCommand Bでビルドすれば手前のuGUIでUnity標準のuGUIが更新されます。
手っ取り早く、実際に更新できているのか確認します。
ButtonコンポーネントのOnPointerClickに適当にログ出力を追加、Unityでボタンを作って押してみます。
やっている事は昨日紹介した物と同じなので、mdbさえ作れるならデバッグも可能です。
改変の方法は以上ですが、２つ問題があります。
一つ目は、プロジェクト単位ではなくエディタ単位である事。つまり、別プロジェクトで改変前のuGUIを使いたい場合、バックアップから戻してやる必要があります。
もう一つは、多くのプロダクトや開発者は改変前のuGUIを想定しているという事。特にAssetStoreのアセットを使用する場合、uGUIの改変具合によっては不具合を起こすかもしれませんし、プロジェクト内でも意思疎通に問題を起こすかもしれません。
今回はC#のビルド時間を短くする方法についてです。ｆ
Unityでゲームを開発する上で、コンパイル時間は必ず発生します。例えばソースコードを少し変えてからUnityエディタに戻ると、右下に処理マークが出てきます。
これ、規模が小さいならばそれほど気にならないのですが、costを使用していたり規模が大きくなり複雑になってくると、非常に長い時間を要求してきます。
これでは何度もコードを修正しながら開発出来ません。
今回はその辺りを何とかする方法について考えてみます。
Unity公式のこの問題を解決する手段です。
Unity 2017.3から利用可能です。
まず思いつくのが、Pluginsフォルダに既にfixした（自身が触らない）コードを配置してしまう事です。Standard Assetsフォルダでも可。
PluginsフォルダやStandard Asstesフォルダ以下に配置したアセットは、通常のコードよりも先にコンパイルされます。また、コンパイルが不要な場合はコンパイルされません。*1
なので、確定したコード群はサクっとpluginsフォルダに移動することで、現在編集中のコード部分のコンパイル時間分は短縮出来ます。
次点で思いつくのが、コードを事前にDLL化してしまう事です。
コードをコンパイルし既にDLL化しているのであれば、コンパイル時間はまぁ減るだろうという目論見となります。
まずひとつ目は、元々Assetsフォルダ以下に配置したコードをDLLに変換する場合、dll化する事で参照が剥がれてしまう事です。
例えばC#にてコードを作成し、プレハブを作成していた場合、DLL化に伴いGUIDが変化するためmissingになってしまいます。
対策というか、自分のコレに対する基本的な考えは、コンポーネントをDLL化しない事です。
コンポーネントはDLL化せず、コンポーネントはUnityとの接点・DLLは機能に集約するような感じの実装してるなら、多分問題にはならなそうです。
もう一つの対策は、変化したGUIDを元に再設定する方法です。
field idとguidを差し替えてやれば、prefabやsceneに設定したコードの参照先を差し変わります。
field idとguidは 【Unity】AssetBundleのManifestファイルに書かれている内容について で紹介した変換を使えば取得出来なくはないですが、手っ取り早いのは指定のコンポーネントをプレハブに設定してfield idとguidを確認する事です。
なおPluginsに移動する手法の場合、その辺りの心配は要りません。
以前に書いてますが、改めて書き直しておきます。Monodevelopを使用しています。
プロジェクト > （プロジェクト名）のオプションを選択
ビルド > 一般のTarget Frameworkを.NET 3.5に設定
ビルド > 出力の出力パスを、Assets以下にでも指定しておく
コレでコンパイルすると、出力パスを指定したフォルダにdllが生成されます。
コマンドラインを使用した方法もありますが、個人的にはデバッグが容易なコチラの方が気に入っています。
dll化する事でソースコードが見られなくなります。DLL化したコードが何らかの問題を起こした際にも、非常に追いにくいです。
実際にはmdbがdllの隣にあれば、dllの中でもブレークポイントを貼る事が可能です。
dllを配置後プロジェクトを動かしていなければ、デバッガにてエラーを起こしたコードへジャンプなり、ブレークポイントなりを設定・追跡出来ます。
またブレークポイントを設定したい場合、ブレークポイントを設定したいコードをUnityと接続しているMonodevelopで表示して、ブレークポイントを設定すれば出来ます。
この記事、元々windowsでやっていたのですが、途中からmacに変更しています。これはwindowsでコンパイルするとpdbが作られmdbが作られない為です。
一応pdb2mdbなる物で変換出来るそうなのですが少し試した感じ上手く動かなかったので一旦放置で。
pluginsフォルダの手法も事前コンパイルの手法も共通した注意点があります。それはコンパイル後のコードはコンパイル前のコードにアクセス出来ないという事です。
例えばpluginsフォルダの場合、assetsフォルダに配置したスクリプトはpluginsフォルダに配置したスクリプトにアクセスが可能です。しかし、plusingsフォルダに配置したスクリプトからassetsフォルダに配置したアセットへアクセスする事は出来ません。
今回はパーティクルを生成する際、サイズや回転速度や移動速度をある程度ランダムにしたり、ある程度の法則性に従い制御する方法についてメモします。
御存知の通り、パーティクルシステムの生成（Emit）やサイズ・回転・速度はParticleのコンポーネントから制御します。設定できる項目は、色々です。
さて、例えばStart Speedで5と設定すれば、パーティクルは５の速度で移動します。常に。これは例えば一括で生成した場合、同じように扇状に広がることを意味しています。時間差で生成すればもう少しバラけるのですが、場合によっては宜しくないかもしれません。
パーティクルの値をある程度ランダムにしたい場合、Random Between Two Contentsを使用します。このパラメータを使用すると、生成するパーティクルの範囲を指定する事が出来ます。
例えば下のGifでは、Start Speedを１～５に、Start Sizeを0.2～0.5に設定しています。そうすると生成タイミングが同一のパーティクルであっても、バラバラな感じで持ち上がるようになります。
もう一つ面白い機能が、時間軸にそって生成の法則性を決める機能です。
例えば下のGifアニメでは、大きさの異なるパーティクルを交互に出現させています。
この手法のキーとなるのが、Duration（持続）とCurveと名前のつくパラメータです。
Durationは１サイクルの長さを決めるパラメータです。Curveを使用する場合、Durationが横軸となります。縦軸は大きさです。
つまり、下の例では１秒毎にサイズの大きなパーティクルを生成するようにカーブを設定しています。そうすると、上のGifアニメのように、１秒毎に大きさの異なるパーティクルが生成される訳です。
ちなみに生成間隔の制御はRateではなくBurstsで制御。
Curveだと大きさは時間軸に依存するだけになります。ので、その範囲でランダム値を与えたい場合はRandom Between Two Curveを使用します。
上手く使うと、トップのGifアニメのような、一定間隔で吹き出す噴水的な奴も作れたりします。
