ラベル Unity 3.5 の投稿を表示しています。 すべての投稿を表示
ラベル Unity 3.5 の投稿を表示しています。 すべての投稿を表示

2013年3月24日日曜日

Unity でソースコードに書いたリテラル文字列の文字コードを調べてみた

Unity3.5.6においてソースコード上にリテラル文字列として日本語を置いた時、時々ログ出力が上手くいかないことがあるということがわかり、ちょっと調べてみました。するとリテラル文字列を置いたソースコードの種類に応じて文字コードが違うということがわかりました。
  • C# (.cs) はUTF-16
  • JS (.js) はUTF-8
  • Boo (.boo) は不明
  • ネイティブのiOSはUTF-8
また出力する側、要するにDebug.Logメソッドは基本的にUTF-8のみを受け付けられるようになっているということがわかりました。まとめると以下の図のようになります。



最終的にJSファイルに全ての日本語リテラルをまとめて回避しましたが、そもそも日本語リテラルは使わず国際化文言ファイルみたいなものを別途用意しておいたほうが筋が良いと思います。iOSならLocalizable.stringsがありますしね。
投稿時間：
タグ： , ,

2012年12月3日月曜日

Unity Asset Server でブランチ切ったりタグつけたりする方法

弊社のUnityプロジェクトではUnity Asset Serverを使ってソースコードやアセットの管理を行なっているのですが、以前ブログに書いた通りこのUnity Asset Serverさんは標準でブランチもなければタグもサポートしていないというCVS以下の素敵なシロモノです。しかしながらやはり開発のニーズ上、継続的に開発するためにはブランチやタグが必要になってきます。そこでUnity Asset Serverを使っていかにしてブランチやタグを運用するかという方法を考えてやってみましたので共有いたします。


■基本方針

基本方針は要するにSVNのやり方をパクります。すなわち、
  • タグやブランチはリポジトリのコピーとして表現する
  • リベースやマージは気合でなんとかする
以上二点です。

さてリポジトリのコピーですが、一応Unity Asset Serverではリポジトリのコピーの作成が可能になっています。



こちらをクリックしてリポジトリをコピーしてください。注意点としてはこのリポジトリコピーは他のユーザーが一人でもAsset Serverに接続しているとコピーが出来ないので、社内に呼びかけて全員のUnityをシャットダウンするなり何なりしてください。誰が接続しているか特定したい場合はUnity Asset Serverが動いているサーバで
ps aux | grep unity
とか叩けばなんとなくわかります。


■タグを付けたい

これは簡単です。Asset Serverに接続して、タグが付けたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはコピーしたリポジトリに触らないようにすればタグの完成です。

注意点として、タグが付けたいバージョンがヒストリの奥のほうにあると基本的には綺麗にタグが切れません。そのようなコミットをする前にタグを切ってください。


■ブランチを切りたい

これもまだ簡単です。Asset Serverに接続して、ブランチの根っこにしたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはこちらのリポジトリに作業者全員が接続先を切り替えて、新しいコミットを重ねていけば良いです。

注意点として、タグと同様に例によってバージョンがヒストリの奥のほうにあると綺麗にブランチが切れず苦労することになりますので、コミットの重ね方には最新の注意を払う必要があります。

それから各作業者がブランチを切り替える際の手順にも注意する必要があります。
  1. Asset Serverに接続してdisplayを選択。
  2. 新しいブランチとなるリポジトリを選択してconnect。
  3. リポジトリの切り替えが終わったらupdateを行う。
  4. マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。

■ブランチをリベースしたい

ここからがちょっとした地獄の始まりです。まずはリベースから。例として1.0.1ブランチのブランチ元である1.0.0をリベースする手順を示します。
  1. Asset Serverに接続して、リベース元となるブランチ (1.0.0) にconnect。
  2. リポジトリの切り替えが終わったらupdateを行う。
  3. マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。
  4. Asset Serverに接続して、リベース先となるブランチ (1.0.1) にconnect。
  5. リポジトリの切り替えが終わったらupdateを行う。
  6. マージするかどうか聞かれたら、リベース元のコードをすべて新しい接続先のブランチに上書きしたいという処理になるので、ソースコードとシェーダーコードについてはMergeを、その他のシーン、プレファブ、テクスチャ、モデル、音などはすべてIgnore server changesを選択する。
  7. このままだとなぜかコードは変更されているのに変更差分をUnityが認識しない悲しい状態になるので、メニューからAssets > Reimport allを選択して変更差分をUnityに認識させる。
  8. マージに失敗したコードおよびシーン、プレファブ、テクスチャ、モデル、音などを手でマージする。
  9. コミットして完了。
これで何とかリベースっぽいことができるようになります。


■ブランチをマージしたい

ブランチのマージは単にリベースの逆をやるだけです。例として1.0.1ブランチをmasterにマージする手順を示します。
  1. Asset Serverに接続して、マージ元となるブランチ (1.0.1) にconnect。
  2. リポジトリの切り替えが終わったらupdateを行う。
  3. マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。
  4. Asset Serverに接続して、マージ先となるブランチ (master) にconnect。
  5. リポジトリの切り替えが終わったらupdateを行う。
  6. マージするかどうか聞かれたら、マージ元のコードをすべて新しい接続先のブランチに上書きしたいという処理になるので、ソースコードとシェーダーコードについてはMergeを、その他のシーン、プレファブ、テクスチャやモデルや音などはすべてIgnore server changesを選択する。
  7. このままだとなぜかコードは変更されているのに変更差分をUnityが認識しない悲しい状態になるので、メニューからAssets > Reimport allを選択して変更差分をUnityに認識させる。
  8. マージに失敗したコードおよびシーン、プレファブ、テクスチャ、モデル、音などを手でマージする。
  9. コミットして完了。
見ての通り、リベースとほとんど同じですね。

投稿時間：
タグ： ,

2012年11月12日月曜日

Unity 3.5 以下でプリプロセッサ定義を上手く使う方法

C/C++/Objective-Cベースのプロダクトのビルドシステムを構築するときに大変便利なのがプリプロセッサのdefineマクロです。defineマクロを使って環境を切り替えたり不要なログコードを削除したりなどは皆さんよくやってるかと思います。C#にも同様のプリプロセッサ定義が用意されているみたいですので、こちらを使ってUnityプロジェクトのビルドシステムを構築できないかと思ってやってみました。


■プリプロセッサ定義の使い方 (Unity 4以降)

Unity 4.0よりプリプロセッサ定義がUnity本体によってサポートされるようになりました！ビルドスクリプトからも自由にアクセスが可能になっており、非常に簡単に扱うことが可能です。
詳しくはけいごさんのブログに完璧にまとめられていますのでそちらをご覧ください。
http://anchan828.tumblr.com/post/32669868103/define


■プリプロセッサ定義の使い方 (Unity 3.5以降)

ここからが本題になります。Unity 3.5以前はプリプロセッサ定義を公式にサポートしていません。そこで以下の４種類のファイルをAssetsフォルダ直下に置くことでプリプロセッサ定義を読み込ませます。
/Assets/smcs.rsp (C#用)
/Assets/gmcs.rsp (C#エディタスクリプト用)
/Assets/us.rsp   (UnityScript、俗にJSと呼ばれている物用)
/Assets/boo.rsp  (Boo用)
このrspファイルにはC#コンパイラのコンパイラオプションとして渡すオプションが記述できます。ですので http://linux.die.net/man/1/mcs などに列挙されているコンパイラオプションであればひと通りなんでも使用可能です。今回はプリプロセッサ定義をやりたいので、以下のように書けばOKです。
-define:DEBUG
複数の定義が書きたい場合は、
-define:DEBUG -define:USE_DEV_SERVER
のようにスペースで空けて複数記載するか、
-define:DEBUG
-define:USE_DEV_SERVER
のように改行して複数記載するか、
-define:DEBUG;USE_DEV_SERVER
のようにセミコロンで列挙して書くことができます。注意点として、C/C++/Objective-Cのdefineマクロと違って
-define:DEBUG=1
のように値を定義することはできないみたいです。あくまでシンボルを作るだけみたいですね。

以下Twitterでのやりとりです。

さて、これでプリプロセッサ定義はバッチリできるようになったのですが、問題はこれをビルドごとに書き換える方法です。最初はビルドスクリプトでこのrspファイルを書き換えていたのですが、どうもこれをUnityが全く認識しないのです。普通にファイルをただ書き換えてもダメなようです。

そこで黒魔術を導入します。以下のスクリプトで使われているコードを利用して、無理やり書き換えた後のrspファイルをUnityに認識させます。
https://github.com/prime31/P31UnityAddOns/blob/master/Editor/GlobalDefinesWizard.cs#L131
AssetDatabase.Refresh();
reimportSomethingToForceRecompile();

private void reimportSomethingToForceRecompile()
{
 var dataPathDir = new DirectoryInfo( Application.dataPath );
 var dataPathUri = new System.Uri( Application.dataPath );
 foreach( var file in dataPathDir.GetFiles( "GlobalDefinesWizard.cs", SearchOption.AllDirectories ) )
 {
  var relativeUri = dataPathUri.MakeRelativeUri( new System.Uri( file.FullName ) );
  var relativePath = System.Uri.UnescapeDataString( relativeUri.ToString() );
  AssetDatabase.ImportAsset( relativePath, ImportAssetOptions.ForceUpdate );
 }
}
これでC#で書かれたコードに対しては無事にrspファイルへの変更が反映されるようになります。

しかしながら更に落とし穴があります。UnityScript(JavaScript)で書かれたファイルに対してはこの黒魔術が効きません。したがってUnityScriptで書かれたファイルに対して動的にus.rspファイルの定義を適用することができないようです。すべてのJSファイルに対して上記の黒魔術を適用しても効果がなかったため、おそらくダメだと思われます。


■結論

UnityScriptは使わないようにしましょう。
投稿時間：
タグ： ,

2012年9月26日水曜日

Unity の PostprocessBuildPlayer を使って Weak Framework を追加する方法

※2013/11/27追記: 第二版を公開しました。

UnityでiOSのアプリを作っていて困ることの一つに、iOSが提供するシステムフレームワークへのリンクをプロジェクトに追加するのが超面倒くさいという問題が挙げられます。UnityがiOSアプリを書きだした後、手動でXcode上からシステムフレームワークを追加してもいいのですが、これはとんでもなく面倒です。

そこでUnityジャパンの伊藤さんという方が PostprocessBuildPlayer という仕組みと Ruby の xcodeproj ライブラリを使ってビルド時に自動的にシステムフレームワークを追加する仕組みを公表してくださいました。お陰様で随分とはかどっていたのですが、その方法では実はシステムフレームワークをWeakリンク（Optionalリンク）することができなかったのです。これでは例えばSocial.frameworkを使うアプリをビルドしてiOS5で動かすと起動時に問答無用でクラッシュしてしまいます。困りました。iOS6/5両対応ができないと話になりません。

というわけで作りました。システムフレームワークをWeakリンクできるPostprocessBuildPlayerを。こちらです。


ライセンスはMITライセンスにしておきました。
使い方は大体見ればわかるかと思いますが、まず最初にgem経由でxcodeprojをインストールしておくこと。
sudo gem install xcodeproj
あとは上記のPostprocessBuildPlayerをUnityプロジェクトの /Assets/Editor 以下に配置して、コード中のフレームワーク名を指定している箇所をご自身のお好きなように変更してやればオッケーです。
投稿時間：
タグ： , , , ,

Unity 3.5.5 以下で Game Center / iAd / UIImagePicker などを使用したアプリが iOS 6 でクラッシュする問題

現在 Unity 3.5.5 以下でビルドしたiOSアプリが、以下の条件をすべて満たしているとクラッシュしてしまう問題が発生しているようです。
  • UnityのiOSアプリビルド設定で、画面方向を横向き（Landscape Left/Landscape Right）のいずれかのみに設定している。
  • Pluginなどを経由してGame Centerを使用している。またはiAdやUIImagePickerなどのiOSが提供する特定のView Controllerを使用している。
  • iOS 6を搭載したiPhone/iPod Touch上で動作させる（iPadは大丈夫）。
詳細はこちら。
http://developer.coronalabs.com/forum/2012/09/17/ios-6-orientation-crash





すでにUnity側で問題は把握しているようで、現在修正版の3.5.6を用意してくださっているようなので、続報を待ちましょう。・・・といっても、すでにUnity 3.5.5以下でビルドされたiOSアプリをリリースしていて、しかもAsset Bundleを使用していたりすると、Asset Bundle間の後方互換性問題のためかなり厄介なことになると思われます。最悪過去のバージョンのサポートをすべて切る必要が出てくるかもしれません。


さて、ここからは技術話の余談です。

このクラッシュ問題なのですが、原因はiOS 6で変更になった画面回転（Auto Rotation）APIにあると思われます。iOS 6からはなんとこれまで画面回転に使用されていた
UIViewController shouldAutorotateToInterfaceOrientation:
が完全に廃止になっており、基本的には全く呼び出されないようになってしまっています。その代わりにより体型だった画面回転の仕組みが導入されています。iOS 6からの画面回転は、「アプリが対応する画面方向」と「各View Controllerが対応する画面方向」の２つによって画面の回転する方向が決定されるという仕組みになっています。

ここで、アプリが対応する画面方向は以下のように決定されます。
以下優先順位順に、
1. UIApplicationDelegate application:supportedInterfaceOrientationsForWindow: が返す向き。iOS 6以降のみ。
2. UIApplication supportedInterfaceOrientationsForWindow: が返す向き。iOS 6以降のみ。
3. Info.plist で指定されている UIInterfaceOrientation の向き。
各View Controllerが対応する画面方向は以下のように決定されます。
各ViewControllerが supportedInterfaceOrientations を実装しているなら、それが返す向き。
していないならば、
iPhoneだと UIInterfaceOrientationMaskAllButUpsideDown
iPadだと   UIInterfaceOrientationMaskAll
この２つの積集合をとって、両方が一致した向きに画面回転が行われる仕組みになっています。

では、ここで両者が全く一致しない場合はどうなるでしょう？答えは簡単でクラッシュします。ワオ。素敵。ふざけんなバカApple爆発しろ。

それを踏まえると、今回の問題でクラッシュしてしまう仕組みはこう考えられます。
  1. Unity 3.5.5以下が書き出すiOSアプリは当然ながらiOS 6に完全対応していない。
  2. Game Centerなど、Appleが提供しているUIコンポーネントは全てiOS 6の画面回転に対応しているが、それらのうち幾つかのものはiPhoneだと縦向き画面にしか対応していないものがある（iPadは基本縦横どちらでも表示できるように対応する必要があるとされているため、無事のようです）。
  3. Unityが書きだしたアプリは横向き画面にしか対応していないのに、上記のView Controllerは縦向きにしか対応していないと言い出すので、クラッシュする。
やれやれですね＞＜
ちなみに対応策としては、アプリ自体は縦方向にも横方向にも対応しているというふうにapplication:supportedInterfaceOrientationsForWindow:メソッドを使って値を返すようにした上で、コンテンツを表示するUIViewをUIViewControllerに管理させるようにして、UIViewControllerのsupportedInterfaceOrientationsで横向き画面の値だけを返すようにするといいかんじになると思います。しかしながらiOS 5/6両方で上手く回る画面は結構大変そうです。
投稿時間：
タグ： , , ,

2012年8月19日日曜日

Unity のプラグインで iOS の bundle を使えるようにする方法

OS XやiOSには Bundle という仕組みがありまして、 NSBundle というBundleを扱うためのクラスが用意されています。皆様も一度は
[[NSBundle mainBundle] pathForResource:@"MyMusic" forType:@"mp3"];
みたいなコードを書いたことがあると思います。このBundleの仕組みを使うと、
  • 複数の画像や文言、JSONなどのデータファイル、音楽などを一つにまとめて扱うことができる。個別のファイルとしてプロジェクトに加えなくてよいので利便性が良い。
  • Bundleには最初から多言語化リソースを扱うための仕組みが用意されているため、多言語化が非常に簡単にできる。
  • OS Xだけになりますが、Bundleにはコンパイル済みのコードを含められるので、プラグインの仕組みが簡単にできる。
以上のようなメリットがあります。例えば実例を上げると、Facebook SDKなどがBundleの中に画像や文言などのリソースを格納して配布するようになっています。実際には確認できていないのですが、おそらくmobage, GREEのSDKもそのようになっているのではないでしょうか？ということでSDKなどを配布するときには非常に便利です。

で。このBundleによる配布はなかなか便利なので、UnityのiOSプラグインとして配布するときにも是非使いたいのですが、そのまま/Assets/Plugins/iOS以下にBundleを配置しても正しくBundleが認識されませんし、iOSのアプリにインストールされません。

そこでBundleを配布するときは、/Assets/Plugins/iOS/以下ではなくて、/Assets/StreamingAssets/以下にBundleを配置するようにしましょう。実は/Assets/StreamingAssets/以下のパスには隠し要素があって、このパス以下のファイル・ディレクトリは全てアプリケーション自身の/Data/Raw/ディレクトリに配置されるようになっています。
参考: http://sehm.blog48.fc2.com/blog-entry-159.html

あとはプラグインとして用意したiOSコードの中で以下のようにしてBundleを取得すればOKです。
NSBundle *bundle = [NSBundle bundleWithPath:[[NSBundle mainBundle] pathForResource:@"MyBundle" ofType:@"bundle" inDirectory:@"Data/Raw"]];
これでUnityプラグインを多言語化したり画像リソースを使ったりするのが楽になると思います。

将来的にUnityのバージョンが上がって、/Assets/Plugins/iOS/以下においたBundleも扱えるようにしてくれると楽なんですが・・・Unity 3.5の地点ではどうもダメっぽいです。
投稿時間：
タグ： , ,

2012年5月5日土曜日

Unity でシステムが使用しているリソースを一覧表示したい

簡単なEditor拡張機能を書くときとか、デフォルトでUnityのエディタが使っている画像とか借りて表示したいときが多々あるんですが、これが実は公開されていなくてそのままでは使えないのです。ということでデフォルトでUnityのエディタが使っているリソース一覧を暴くスクリプトを用意してみました。



実行するとログに全てのリソースの一覧が表示されますので、あとはそれっぽい名前のやつを適当に拝借すればOKです。
投稿時間：
タグ： ,

自作の Unity Editor Script を github に公開してみた



最近は仕事の関係でUnityばっかり触っているのですが、中でも今お気に入りなのがEditor拡張機能です。これは自分で簡単なスクリプトを書くだけでUnityのエディタ上の表示を自由にカスタマイズできる機能なのですが、コイツの出来がなかなか素晴らしいのです。これまでいろんな開発環境を触ってきたのですが、ここまで簡単にエディタ上の表示を自在にカスタマイズできる環境は他に類がありません。

ということで調子に乗って自作のEditor拡張機能を書いて公開してみることにしました。まずは簡単なものからということで、シーン上に配置できる定規を作りました。


■機能
  • 原点からの距離(u)、高低差(u)、対象位置地面の水平方向傾き(度）を測定可能 ※1u=Unity上での長さの単位1とします
  • イメージを見ての通り全数値がエディタ上に表示されるので一目でわかる
  • Raycast飛ばしてるので確実に地面位置を基準にして判定してくれる、Raycastが外れても空中の座標がきちんと出る隙を生じぬ二段構え
  • 画面上の色/フォントを自由にインスペクタから変更可能
  • すべてEditorScript/Gizmoなので万が一何かの間違いでリリース版のシーンに残っていてもMesh Rendererが走って画面に表示されるという悲しい思いをしない
  • 操作は原点を選択してAdd Pointボタンを押して出てきた点を任意の位置に移動して配置するだけ
  • Clear Pointボタン付き
ひと通り基本的なのは揃えてみました。


次は高低差メッシュをTerrainの上に表示する機能とか作ってみたいっすね。
投稿時間：
タグ： ,

2012年5月4日金曜日

Unity の GUIStyle でデフォルトで指定できるスタイル一覧

今回は完全に自分用メモになってしまいますがご了承ください＞＜

UnityのGUIStyleはname文字列を指定して生成する事が可能ですが、Unityがデフォルトで持っているGUIStyleの一覧を見つけたので列挙しておきます。
  • box
  • button
  • toggle
  • label
  • textField
  • textArea
  • window
  • horizontalSlider
  • horizontalSliderThumb
  • verticalSlider
  • verticalSliderThumb
  • horizontalScrollbar
  • horizontalScrollbarThumb
  • horizontalScrollbarLeftButton
  • horizontalScrollbarRightButton
  • verticalScrollbar
  • verticalScrollbarThumb
  • verticalScrollbarUpButton
  • verticalScrollbarDownButton
  • scrollView
大文字小文字は関係ないみたいです。たとえばboxのところをBoxと指定しても問題なくそのまま通ります。

参考URL: http://answers.unity3d.com/questions/9844/copypaste-guistyle-in-the-inspector.html
参考URL: http://unity3d.com/support/documentation/Components/gui-Customization
投稿時間：
タグ： ,

2012年4月22日日曜日

Unity Asset Serverを導入してみた

先日のiphone_dev_jp東京の勉強会での発表資料に書いた内容と同じなのですが、結局あの場では発表できませんでしたので、改めてUnity Asset Serverを触ってみた感想などを書いてみようかと思います。


■Unity Asset Serverって何？

Unity社が提供している、Unityのエディタと完全に統合されたバージョン管理システムです。
http://unity3d.com/unity/team/assetserver/
ソースコードだけではなく、プレファブやシーンを含めたUnityのプロジェクト全体のリソースを管理してくれます。Unityのエディタと統合されているため、Unityのエディタから一切外に出ることなくバージョン管理ができるというのが売りです。実はUnity Asset Serverは完全に普通のPostgresSQLのサーバーをそのまま利用しているだけになっていますので、SQLを経由してバージョン管理の履歴を操作したりも出来ます。


■Unity Asset Serverを使う理由は？

なんといっても以下の３つがUnity Asset Serverの魅力でしょう。
  • 導入するのが非常に簡単。サーバー側はインストーラーをぽちぽちするだけでWindows, Mac, Linuxどの環境でも一発です。クライアント側はUnityにそのまま付属されてくるためインストールなんぞ一切不要です。Team Licenseをアクティベーションしたらすぐに使えます。
  • 運用するのが非常に簡単。管理者側もユーザー側も、バージョン管理未経験の人でもUnityエディタのGUIを経由して誰でも簡単に使用することができます。
  • 動作がそこそこ高速。バックエンドがPostgresSQLなおかげだと思うのですが、LAN環境で最大10MB/s程度の速度でコミットしたりアップデートしたりできています。これはテクスチャや音楽、3Dモデルなどの巨大なバイナリファイルを大量に扱うゲーム開発においてはかなり重要です。

■でもお高いんでしょう？

はい。お一人様5万円となっております。

お一人様、5万円です。

マジです。

なかなかボッタクリ挑戦的な価格設定だと思います。


■よかったところ

実際に２ヶ月間ほど運用してみてよかったところはこんな感じです。
  • だれでも超簡単に使えます。とにかく超簡単。これはプログラムなんて全くわからないデザイナーさんや、バージョン管理未経験の人、はたまた入社２日目の人でもなんの問題もなく使えている事実から裏付けされています。Asset Server導入前はgitを使っていたのですが、GUIクライアント付きでもトラブルだらけの毎日でした。これがAsset Serverになるやいなや全く教育もトラブルシュートもしないまま一日80コミット以上をコンスタントに記録するような素晴らしいバージョン管理体制が構築できたのです。
  • Unityのプロジェクトをバージョン管理するとき固有で発生するトラブルが一切ありません。まぁ具体的には先日書いた記事の通り、metaファイルなんですけど。前にも書きましたが、とにかくトラブルが発生しづらいです。簡単で単純なので。

■いけてないところ

さてもちろん良いところがあれば悪いところもあるわけで。以下のような点が問題点としてあげられます。
  • 高い
  • 高い
  • 高い
  • 高い
  • バージョン管理に必須とも言える機能が大幅に欠落しています。Subversion以下程度の機能しかありません。
  • 具体的にはブランチがない、タグがない、外部ツールがないのでJenkinsみたいないUnity以外から触ろうとすると超面倒くさいかPostgreSQLに直接SQL発行するしかない、基本コミットとアップデートとlog見てrevertするぐらいしかできることがないです。
  • みんなが一番期待するであろう、シーンやプレファブのマージですが、出来ません。一切できません。したがって作業範囲が衝突した時のトラブルはSubversionやgitと何ら変わりません。むしろスクリプトのマージを自動解決してくれるぶん、gitやhgのほうが優れています。
  • Unityのプロジェクト固有の問題は一切ないのですが、一般的なバージョン管理システム的にありえないバグが時々（週に１度程度）発生します。
  • 具体的にはファイルを変更したのに変更差分が認識されない（特にスクリプトを外部ツールでマージした際に顕著に発生）、updateしたのにローカルのファイルが古いまま、Historyから復元しようとしたら復元元のディレクトリが無いとか言われて復元できなくて死亡して愚痴愚痴愚痴愚痴愚痴...
  • 大人数で使うことを開発元が想定していないフシが多々あって、一番わかり易い例が最大同時接続数。これ最初の設定だと20人が限界です。PostgresのデフォルトがTCP接続40本までで、Asset Server Clientは1クライアントあたり2本TCPを貼るので。更に悪いことにこの設定を変更するにはPostgresSQLの設定ファイルを自分で操作する必要があります。簡単だからという理由で導入してここで躓いたチームは地獄を見る（むしろほぼ解決不可能になる）ことになります。
  • ところどころ完成度の低い機能があったりします。例えば既存リポジトリのコピーが可能なんですが、誰か一人でもどこかのリポジトリにクライアントが接続していたらコピーが出来ないと言われてしまいます。・・・えーと、全員帰った後にコピーしてくださいってことでしょうか＞＜

■結論

Unity Asset Serverは、状況次第では非常に強力な選択肢になりえます。例えばチームメンバーのほとんどがバージョン管理システムを使ったことがないとか、グラフィックやサウンド担当の人が多くて彼らがSubversionやgitを覚えるのは不可能というとき、社内でSubversionやgitのサーバーを運用するノウハウがない少人数のチームのとき。こういう時にはAsset Serverの導入しさえすれば誰でも使える簡単さが大いに役立ちます。

しかしながらこの内容で1ユーザー5万円という値段はどう考えても暴利と言わざるを得ません。またできることが浅く、機能が少なすぎる弊害が簡単さによる生産性向上度をだんだん上回っていきます。とくにJenkinsと組み合わせる際の相性の悪さが辛いです。シーンやプレファブのマージができるのであればまだ5万円の価値はあったのですが・・・ということで、すでに他のバージョン管理システムを使えているチームでしたら、ぶっちゃけそのバージョン管理システムを使ったほうが良いと思います。


■こぼれ話

Unity Asia Bootcamp Tour東京で聞いた話など。まずGREE（というか@splhackさんの部署）はバージョン管理にgithubを使っているそうです。gitでは無理だと思っていたのですが、チーム全体の習熟度が高ければ問題なく回せるものなのかと感動しました。それからUnity Japanの大前さんにUnity Asset Serverに関する不満を申し上げたところ、やはりUnity側でもそのあたりは問題点として認識されているとのことでした。改善に期待するしかないですね＞＜
投稿時間：
タグ： ,

2012年3月4日日曜日

Unity 3.5でバージョン管理をする


およそコンピュータを使った仕事に該当するものでしたら何でも、複数の人物が同時に作業するための何らかの仕組みが必要になるのは、コンピュータを使った仕事に関わっている人でしたら皆ご存知かと思います。特に開発業務といえばgitやhgといったバージョン管理システムの出番になります。そういうわけで今回は Unity プロジェクトでのバージョン管理について一ヶ月間ほどやってみた結果をご紹介したいと思います。


■Unity 3.4以前の場合

そんな暗黒時代のことは忘れましょう。


■Unity 3.5以降の場合

Unity 3.5から新しい仕組みが導入され、 Unity Asset Server というビルトインの ボッタクリ バージョン管理システムを使う以外に、好きなバージョン管理システムを使ってUnityのプロジェクトをバージョン管理することができるようになりました。これを使わない手はありません。まずは公式のガイドを見てみましょう。
http://unity3d.com/support/documentation/Manual/ExternalVersionControlSystemSupport.html

これによると、以下の手順を踏むのが良いようです。
  1. メニューの Edit -> Project Settings -> Editor から、 Version Control の Mode という項目を探し、 Metafiles を選択する。これで外部のバージョン管理システムが導入できるようになります。このチェックを入れると、
    • Libraryディレクトリが重要なメタデータを管理するディレクトリではなくただのキャッシュディレクトリになり、バージョン管理をしなくてよくなる。
    • 新たにAssetsディレクトリ以下のすべてのファイルとディレクトリについて.metaファイルが生成される。
    • 新たにProjectSettingsディレクトリが生成される。
  2. メニューの Edit -> Project Settings -> Editor から、 Asset Serialization の Mode という項目を探し、 Force Text を選択する。この手順はどちらかと言うとおまけです。これを実行すると、ほとんどのAssetファイルがバイナリではなくテキスト形式で保存されるようになり、diffやmergeが行えるだけではなく差分だけをコミットするようになるためバージョン管理システムが扱うデータ量が減ります。
  3. プロジェクト配下のAssetsディレクトリとProjectSettingsディレクトリをバージョン管理システム配下に追加する。それ以外のファイルは追加しなくて良い。
たったのこれだけです。なかなか簡単そうですね！ということで早速やってみました。

・・・ところがぎっちょん、実際にやってみると出るわ出るわ問題の山。


■.metaファイルがどこからともなく勝手に生成される

これが最大の問題です。外部バージョン管理をするためにUnityが.metaという名前のメタファイルをテキスト形式で生成するのですが、コイツがトラブルを起こしまくります。
  • ファイル削除時に.metaを消すのを忘れて、同じ名前のファイルをあとから作成しようとして.metaがぶつかりトラブルになる
  • ファイルも.metaもバージョン管理下から確かに消したはずなのに、なぜか.metaファイルだけが勝手に復活している
  • ブランチを移動すると急に.metaファイルが湧いてきて、ブランチのマージ時に衝突する
主要な原因はUnityが空のディレクトリから.metaファイルを生成しているためです。 以下のようなケースで、中身が空のディレクトリというのは容易に生成されてしまいます。
gitの場合
gitはディレクトリをバージョン管理対象に含めないため厄介なことになります。通常はgit pull時にmerge/rebaseが実行され、その際に空になったディレクトリは削除されるのですが、merge/rebaseの最中に衝突が発生したりすると問題が大きくなります。merge中に裏でUnityが動いていると空ディレクトリの.metaがその場で生成されて、考えるだけでも恐ろしいことになったりします。
通常はこれで問題ないのですが、merge/rebase時に衝突が発生していて、裏でUnityが動いていたりすると酷いことになるみたいです。
hgの場合
hgはgitと同様にディレクトリがバージョン管理対象外なのですが、hg update時に空になったディレクトリをきちんと削除してくれます。これはupdateがworking directoryの中身を指定されたリビジョンの状態にするから、という認識です。gitと違いpullやupdate時にmerge/rebaseを実行しないためトラブルになりづらいのか？などと考えてますが実際に苦労したわけではないのでよくわかりません。おそらくgitよりはトラブルになりづらいとは思います。
1および3にupdateすると、きちんとFolderやOtherFolderが削除されてくれます。いい感じ。
svnの場合
ディレクトリもバージョン管理の対象にするので問題ありません。以下の図を参照。
r2のような削除の仕方をするとFolderが残ってしまうためFolder.metaが生成されてしまうのですが、普通はディレクトリを消したときはr4のような削除の仕方になるので問題がないはずです。
また中身が事実上空なディレクトリ（すでに使われていない.metaしか入っていないディレクトリなど）が亡霊みたいにさまよっていて延々と自身の.metaを書き出し続けたり、善意で予め作っておいた空ディレクトリが.metaを吐き出していることを知らずコミットされては削除されを繰り返していたり、二人が同時にディレクトリを削除しようとして片方のコミットが衝突して結果が壊れてしまったりなど、枚挙に暇がありません。

元ファイルを移動したり削除した際に.metaを消さなくてはいけないというだけでも極めて面倒で、相当なトラブルになりました。そもそもがUnityを使っているプロジェクトのメンバーが全員バージョン管理システムに慣れていないため、とりあえずバージョン管理システムのGUIツールがいうがままに変更を全部コミットするだけという具合の運用に。.metaだけが延々と残って衝突が繰り返されるという悲惨な状況が発生してしまうこととなりました。これはUnityのせいではなくメンバーがバージョン管理の考え方を正しく理解していないのが問題なのでツールは何を使っても発生しうるのですが、.metaがなければここまで問題は拡大しなかったと思います。

いっそignoreしてしまいたいぐらいなのですが、この.metaにファイルごとのメタ情報が全て詰まっているため、当然ignoreするとプロジェクトがブッ壊れます。これはひどい＞＜

本家のドキュメントで例にされているのがgitでもなくhgでもなくsvnであるあたりを見ると、なんだかsvnで動作させることしか考えてなさそうな印象です・・・


■.unityファイルがマージできない

.unityファイル自体はテキスト形式にできるのですが、中で使われているAssetのIDがちょっと触れただけでものすごい勢いで変化したり、他人の環境では別の値になったりするため、殆どの場合マージできません。iOSプロジェクトのxcodeprojファイルみたいな感じです。こればかりはマージを諦めるしかありません。


■まとめ

最初はgitを使って管理をしていたのですが、上記に挙げたような問題が多発しまくって回らなくなってしまいました。別のバージョン管理システムを使うことも検討したのですが、そもそもメンバーのバージョン管理に対する知識が足りていない上に.metaが存在する以上hgやsvnに変えても問題が根本的に解決しそうにないと判断し、結局社長に頼んでAsset Serverを購入して試してみることになりました。がっかしです＞＜ ですがAsset Serverならば.metaを使わないでバージョン管理できるので問題を根本的に解決できそうです。

逆に言えば.metaに気をつければそれ以外の箇所ではgitでもあまり問題になりませんでした。バイナリを大量に扱うため重いのではないかと懸念されていましたが、github経由ででも問題なくpush/pull出来る程度の重さにしかならなかったです。ということで.metaとうまく付き合えるチームメンバーが揃っているのであれば、Asset Serverなしでも十分やっていけるのではないかと思いました。

個人的にUnityでバージョン管理をする際におすすめする外部バージョン管理システムはsvn、可能であればPerforceです。git/hgのようにブランチを主体とするバージョン管理システムはブランチを切り替えた瞬間に.metaに殺されるケースが多々あるため、ブランチの使用そのものが非推奨となり、力が発揮できません。mergeについてもバイナリファイルやmergeできないテキスト形式のファイルが多くて結局意味がない気がします。どうしても分散VCSを使いたい！というならhgをお勧めします。ブランチ切り替えは常にupdate -Cすることで対応できるかなと。bazaarはわからないのでノーコメント。gitはpull時の衝突の最中に裏でUnityが動いていて大爆発するケースがあったのでやめておいたほうが良いです。hgなら少なくともpull/update時に爆発することはないはずですからね。

次はAsset Serverを試してみて、使用感を書いてみようかと思います。果たしてお値段に見合った効果は得られるのか！？乞うご期待です！
投稿時間：
タグ： , , , ,
登録: 投稿 (Atom)