Unityでリリース前に気をつけること For Windows

2018/1/24 編集　黄泉口製薬
本稿ではunityでスタンドアローンとしてリリースする際に気をつけることをまとめるものである。
また、いつの間にか追記で増えることがある。そしてコメント欄にて他にもあればご指摘ください。

筆者環境　unity2017.2.2　 MacOS high sierra

画像について

unityで使うsprite画像だが、こちらがインポートしたものは縦横ともに2のべき乗か4の倍数でなくてはならない。また、なるべく2のべき乗がよい。
2のべき乗例　10241024
４の倍数例 200200 px

もし2のべき乗か４の倍数でないならメモリを必要以上に大量に使用することになり、メモリ不足で死ぬ。
例（10MBの画像を使用　→　500MBくらいの画像になっている）
スタンドアローンとしてビルドしたときに起こるため、リリースし低スペックPCを使っている顧客のクレームで気づくことになる。
ちなみにwin7 32bit メモリ4G　の環境下だと上記1MBの画像一枚でも死ぬ可能性がある。
さらに補足するなら低スペでも動くようにしたいなら長辺の長さの最大は1024までがいい。

音について

BGMのような長めの音楽を扱う際にInportSettingの
Conpression Format（圧縮形式）は Vorbisがいい
もし圧縮形式がPCMでかつ　Decompress Onloadオプションの場合展開時に
10MB -> 30MB　になり
予想よりメモリが足らなくて落ちる場合がある。

Fontについて

日本語を使っている以上フォント周りのトラブルは絶えない。
ざっくり説明するとそのフォントのInportSettingで
フォント使用時にそれがDynamic設定にしていると一度全てのフォントデータがテクスチャとして開かれる。あと他多数。によってメモリ不足で死ぬ場合がある。
これに関しては説明すると長い上にプラットフォームに寄るため申し訳ないが略します。
公式のリファレンスをみて・・・・・・
https://docs.unity3d.com/ja/540/Manual/class-Font.html

DirectX

現在最新のWindows updateをかけていればDirectXのバージョンは11(win7,8)か12(win10)だ。
しかし世の中にはあえてDirectXのバージョンを9か10のしている人が一定層いる。
理由としてはやりたいゲームがそれにしか対応してないからというのが多い。で、そのゲームが終わった後もバージョンをそのままにしていて忘れているパターンが多い。とくにwin7などは更新がすでに自動でかからないためそのパターンが多い。
で、unityなのだがいつのまにかDirectX 9,10のサポートを打ち切っている。
その関係上スタンドアローン時に動いたり動かなかったりする。
うちの環境だと動くんだけどユーザーがわでは・・・という場合これを疑って見るといいかもしれない。
対処法は当方では分かりかねるのでユーザーにDirectXのバージョンアップを呼びかけるしかない。
一応その設定はPlayer Setting /Other Setting/Auto Graphics Api　for windows
のチェックを外すことで見ることができる。

ビルドしたいプラットフォームがない

あれ？android向け、Mac向けに、windous向けにビルドしたいのに・・・ビルドセッティングに表示されない・・？
というとき、もう一度Unityインストーラーを実行して見ると途中でビルドターゲットの欄があるのでそこでいれる。
ただ、色々いれるとビルド時間が若干伸びる。
また、アップデートによりAndoroid　sdkも現行Unityに含まれている。

圧縮

これはMac User向けだがMacでZip圧縮したものをWindowsで解凍すると文字コードの違いによってバグることがある。ただWindows8　以降だとこれの解消を担保されている。
そのため、たとえMacでビルドして作ったとしてもWindowsに未圧縮のものを入れて圧縮したほうがいい。
というかこれはunity以外でもだが

圧縮その２

マルチプラットフォームだからとWindows向けもMac向けもとフォルダに入れ（フォルダは別）圧縮するとバグることがある。
別々に配布するか、Mac用のファイルだけ別で圧縮しよう。

文字コード

Macでビルドしてwindowsで起動した時（またはその逆）Macでは動作する部分がwindowsでは動作しない、または文字化けしている時、文字コードが関係している可能性がある。
また、windows7では上記が起こるがそれ以降の8以降のOSでは上記が起きない場合も含まれる。
これはWindows向けにビルドする時Windowsで行えば一応回避できる。

Update

A機では正常、B機ではバグがでる。この機器二つにスペック差がある場合。
スタンドアロンにおいて例として以下のようなプログラムを持つ場合バグ・・というよりも
それぞれで動作が異なってしまう。
例
update内においてオブジェクトのトランスフォームポジションでまっすぐ移動するようにする。
コルーチンによってオブジェクトはX秒後に消える。

これだと機器スペックによって消えるまでの移動距離が変わる場合がある。
上記はあくまで例であり、その他にも考えられる。
とりあえず上記であればTween系ライブラリを使えば解決する。

とりあえず以上。