はじめに

Unityのコンパイルに成功したのに、
XcodeでMultiple commands produceを起こしました。

うわあ〜

stack overflowでも見つからず、バグの解決に何時間もかかったので記録しておきます。
環境は以下になります。
Xcode 11.7
Unity 2019.4.10f1

原因

Product Nameに日本語が入ってると発生するようです。
そりゃstack overflowでは見つかりませんね。。。

はじめに

あるとき、Unityのプロジェクトを開こうとすると、以下の画像のように「Failed to load window layout」と表示されてプロジェクトが開けなくなりました。

この時、
「Revert Factory Setting」
「Quit」
「Load Default Layout」
のどのボタンをクリックしても解決しません。
どうやら、開こうとしているプロジェクトのウィンドウの現在のレイアウト設定のデータが壊れているようでした。レイアウトの設定は下の画像のように、Window>Layoutsで設定するやつです。

試した環境

Unity 2020.1.4
Unity 2020.1.6
OS:macOS Mojave

試した対処

以下の方法を試しても変化はありませんでした

• プロジェクトを新規作成する
• UnityHubと、インストールされている全てのバージョンのUnityをアンインストールする
• OSを再起動する

解決方法(Windowsの場合)

Widdowsの場合は、こちらの動画がわかりやすいです。
要は、デフォルトのレイアウトの設定ファイルDefault.wltを探して、そのテキストデータをコピーし、現在のレイアウトの設定ファイルプロジェクト名/Library/CurrentLayout-default.dwltのテキストデータを、コピーしたやつで上書きすればいいわけです。

解決方法(macの場合)

https://www.youtube.com/watch?v=bUscnPvXsew
http://nakamura001.hatenablog.com/entry/20120504/1336137776
を参考にして以下の方法を試したら、ちゃんとプロジェクトを開けました。
Windowsの場合とやり方は一緒です。しかし、macの場合はDefault.wltファイルがどこにあるのかわからないと思うので（僕がそうでした）、その場合は以下の手順を試してください。

1.Finderを開き、「Shift+Command+G」の３つのキーを同時押しする。

2.すると、以下のような画像が表示されるので、
~/Library/Preferences/Unity/Editor/Layouts/
上記のパスを入力する。

3.移動をクリックすると、

Editor-5.x/Layouts/default
の中にDefault.wltファイルがあります。

4.Default.wltファイルをテキストエディタで開いて(開くと下の画像のようなテキストが出てくる)、そのテキストを全てコピーする。

5.開きたいプロジェクトのCurrentLayout-default.dwltを探して、それをテキストエディタで開いて、さっきコピーしたやつで上書きして保存する。

CurrentLayout-default.dwltファイルの場所は、

UnityProjects/プロジェクト名/Library/CurrentLayout-default.dwlt

にあるはずです。

6.これでプロジェクトを開けるようになるはずです。

参考にした記事、動画

https://qiita.com/KazuyaSeto/items/2a97ae452214af50108d
https://www.youtube.com/watch?v=bUscnPvXsew
http://nakamura001.hatenablog.com/entry/20120504/1336137776

Unityにおいて古いC#しか使えない時代もありました。しかし、それは過去のことです。本稿執筆時の最新LTSであるUnity 2019.4ではC# 7.3がサポートされています。また、本稿執筆時の最新Beta版であるUnity 2020.2ではC# 8.0がサポート予定です。

長らくUnityで古いC#しか使えなかったことで、「C#にこんな機能あるのか？知らなかった！」となることがある方も多いのではないでしょうか？この「Update your C# in Unity」シリーズでは、「C#の比較的新しい機能をUnityでこんな風に使えるよ！」という紹介を行います。

---

言語機能名: nameof
追加バージョン: C# 6.0
説明: 変数名、型名、メソッド・フィールド・プロパティなどのメンバ名を文字列リテラルとして取得する機能

利用例としては

• SendMessageの第一引数など、メソッド名を求められる箇所で、文字列リテラルべた書きではなくて、nameofを使う
• SerializedObjectのFindPropertyの第一引数など、フィールド名を求められる箇所で、文字列リテラルべた書きではなくて、nameofを使う

※ 個人的にはSendMessageの利用は避けるべきだと思っています。しかし、どうしようもない理由があって避けられない場合や、漸進的に改善をしていく必要がある場合、まずnameofで小さく改善するのがオススメです。

using UnityEngine;

public class EnemyLauncher : MonoBehaviour
{
    public void LaunchEnemy()
    {
        Debug.Log("Launched");
    }
}

using UnityEngine;

public class GameController : MonoBehaviour
{
    public void Start()
    {
        SendMessage(nameof(EnemyLauncher.LaunchEnemy));
    }
}

---

SendMessageやFindPropertyのように、メンバ（メソッドやフィールド）の名前を文字列リテラルとして引数にとる場合、コード中に文字列リテラルを直接埋め込むのではなく、nameofを使いましょう。

nameofを使うメリットは、「型名やメンバ名が変わった時に、対応する文字列リテラルの変更を変え忘れることが防止できる」ということです。

仮に、次のように文字列リテラルを直接引数として渡していて、使ってSendMessageを使っていたとします。

using UnityEngine;

public class GameController : MonoBehaviour
{
    public void Start()
    {
        // このように直接文字列リテラルを埋め込むのは避けるべき
        // EnemyLauncher型のLaunchEnemyメソッドの名前が変更された場合、実行時エラーになってしまう
        SendMessage("LaunchEnemy");
    }
}

この時、EnemyLauncher型のLaunchEnemyメソッドの名前が変えたとしましょう。同時に、GameControllerに直接埋め込まれている"LaunchEnemy"という文字列リテラルも変更しないといけません。しかし、これをうっかり変えそびれてしまうことがありえます。その場合、実行時エラーになってしまいます。このような実行時エラーは非常に厄介です。

---

一方で、次のように今回紹介するnameofを使っていた場合はどうでしょう？
EnemyLauncher型のLaunchEnemyメソッドの名前が変えた場合、GameController内のnameof内でコンパイルエラーになり、問題があることにすぐに気が付けます。
「メソッド名を変えたことが原因」の厄介な実行時エラーになる可能性を排除できます。
また、もしVisual SturioやRiderのリネーム機能でEnemyLauncher型のLaunchEnemyメソッドの名前が変えた場合、nameofの内部も自動的にリネームされ、非常に円滑にコードを編集することができます。

using UnityEngine;

public class GameController : MonoBehaviour
{
    public void Start()
    {
        // EnemyLauncher型のLaunchEnemyメソッドの名前が変更された場合、コンパイルエラーになり、厄介な実行時エラーの原因を事前に気付ける
        // また、IDEのリネーム機能を使った場合、↓の内容もリネーム対象となる
        SendMessage(nameof(EnemyLauncher.LaunchEnemy));
    }
}

このようにnameofを使うメリットは、「型名やメンバ名が変わった時に、対応する文字列リテラルの変更を変え忘れることが防止できる」ということです。

---

この投稿ではnameofのUnityでの利用例とそのメリットを説明しました。
なお、nameofのC#におけるより一般的な使い方は、INotifyPropertyChangedの実装や、ArgumentExceptionの引数に使うという利用方法です。
Unityにおいても、エラー文・警告文などでも使う場面があると思います。
変数名、型名、メソッド・フィールド・プロパティなどのメンバ名を文字列リテラルとして必要な場面では、積極的にnameofを使っていきましょう。

※ この投稿では、SendMessageを例にnameofを紹介しましたが、個人的にはSendMessageの利用は避けるべきだと思っています。しかし、どうしようもない理由があって避けられない場合や、漸進的に改善をしていく必要がある場合、まずnameofで小さく改善するのがオススメ。

---

関連・参考

• C# 公式リファレンス
• ++C++ nameof 演算子

はじめに

AssetGraphを使って AssetBundle を作成した際、出力ディレクトリに関して混乱していたのでまとめます。

AssetGraphの使い方は、公式のドキュメントに記載されています。

AssetBundleドキュメント

AssetBundleの出力ディレクトリ

出力するAssetBundleのディレクトリは、「Build Asset Bundle」ノード(赤色のノード)で設定されています。「Output Option」で形式を指定できます。
最初の1つ目が既定で、残り3つがディレクトリ指定型です。

Build In Cache Directory

規定のディレクトリです。ディレクトリ名は以下となります。

/Assets/AssetGraph/AssetBundles/Cache/AssetBundles/(id)/(platform)

platformには Windows などが入ります。

Error If No Output Directory Found

ディレクトリを指定できますが、存在しないディレクトリを指定するとエラーになります。

Automatically Create If No Output Directory Found

ディレクトリを指定し、存在しないときは自動的に生成します。

Delete And Recreate Output Directory

ディレクトリが存在すれば一旦削除し、再生成します。

ディレクトリの指定のコツ

Webを使わない場合、 Output Directroy を /Assets/StreamingAssets に指定しておけば、手間を掛けずに AssetBundle ファイルを設置できます。

また、Output Directory に (Platform) を指定すれば、プラットフォーム単位で出力するファイルのディレクトリを変えることができます。

例： /Assets/StreamingAssets/(Platform)

まとめのまとめ

このように設定方法を理解することで、AssetBundleの管理にかける手間が省けるので、AssetGraphを活用するきっかけになればと思います。