Unity に関する投稿を表示しています

Inspector拡張の話、MFUのコンフィグの

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

参照: http://sourceforge.jp/projects/mmd-for-unity/scm/svn/commits/149
※r149が最新のコミットでもリリースされたものでもないので間違いないようおねがいします。

 InspectorBase.cs で [CustomEditor(typeof(Object))] を引っ掛けて、PMDInspector/VMDInspector に振り分けています。もし、他のスクリプトなどでも [CustomEditor(typeof(Object))] を使っている場合は、どちらかが動かなくなってしまうので、動かさなくてもいいほうをコメントアウトするとよさそうです。
 そのために、InspectorBase.cs の先頭あたりの#defineの1行をコメントアウトするだけで、InspectorBase.cs全体を無効化することができます。

 PMDInspectorでは、PMDLoaderWindow相当の機能を提供しています。EditorGUILayoutを使ってGUIを組んで、PMDLoaderScriptに投げているだけですけれども。

 VMDInspectorも大体同様で、VMDLoaderWindow相当の機能を。こちらもEditorGUILayout使ってGUIを組み上げ、MMDLoaderScriptに投げています。


 ここまででInspectorの話はおわりまして、追加してみたMMD.Configの話を。

 作った経緯としては、何度もインポート作業をするような場合、設定が毎回リセットされててつらぽよーとかなりそうなので作りました。ほんとうは、Inspectorを使うか使わないか、の設定を載せたかったのですが、そんな高等なことはできなさそうだったので無しです...

 中身は、ScriptableObjectを継承したConfigクラスを中心に、あとは保存したいフィールドを用意しているだけです。なので、あとで設定が増えた、項目が変わった、といったことが起きても対応しやすい、と、思います。

 Inspectorで表示したり共通設定を用意したりと、のために ConfigBase というクラスを用意しており、これを継承することで折りたたみがついているGUIを形成できます。やっていることは簡単なので、継承しなくてもいいと思いますが...(決してラムダ式を使ってみたかっただけ...ではないですよ、決して。ええ、戻り値をboolにしても行けますけど、まあ、はい。)

 で、Configクラスのメンバで、このConfigBaseを継承したクラスを放り込むことで、保存、読み込み、Inspector表示、ができるわけです。

 どこかで使うときは、Config.LoadAndCreate() で、得られます。

// Sample: PMDLoaderWindow
20 public PMDLoaderWindow()
21 {
22     // デフォルトコンフィグ
23     var config = MMD.Config.LoadAndCreate();
24     shader_type = config.pmd_config.shader_type;
25     rigidFlag = config.pmd_config.rigidFlag;
26     use_mecanim = config.pmd_config.use_mecanim;
27     use_ik = config.pmd_config.use_ik;
28 }

 保存は意図的に行わなくても、多分大丈夫です。多分。
 Config.csと同じフォルダにConfig.assetとしてバイナリが保存されます。
 Config.csファイルが他にもあると、そっちに保存されてしまう可能性があります。という部分だけ注意をしていただければ....(直したい

 あとは....r149で追加したものはすべてMMD名前空間に放り込みました、というぐらいですか。
 思えば、MMD.Editors とかの名前空間の方がよかったかも..?

 他は...とくにないですかね。
 追加したInspector周りにバグがあるっぽいので、上の件と合わせて検証して直します。

Inspector拡張の

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

先日書いた https://gomiba.co.in/blog/?p=94 この記事の続報。

以前質問した場所は流れてしまったっぽいので、そのまま削除しました。
で、同じような質問をFacebookの「Unityユーザ助け合い所」の方で質問しなおしました。
すると、いまEditor拡張がアツく最近Unityの中の人になった @kyusyukeigo さんがサンプルコードつきの回答を出してくれました。

 

"UnityEngine.ObjectのCustomEditorを作成する"
http://anchan828.hatenablog.jp/entry/2013/06/24/024425

 

ありがとうございます!

やはり以前の記事にも書いたように、[CutomEditor(typeof(Object))] をもつたった1つのクラスを作ってそこから振り分けていますね。じゃあ、まあ、いいか。あとはなんか設定項目みたいのでON/Offできるとよさそうですよね。

というわけで、MFUのInspectorでどうこうするのやっていきます。
なお手元はすでにこの状態な模様:うん、おっけーだろ on Twitpic

enabled=false なスクリプトに対して SendMessage

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

1. 適当なオブジェクトについてるスクリプトをInspectorから無効化します。

2. スクリプト内の Start() とかその他のメソッドが走らないことを確認します。

3. 無効化したスクリプトに向けてSendMessageします

4. SendMessageで指定したメソッドが走ります

5. 楽しい!✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌

MMD for UnityのIKスクリプトのパフォーマンス計測もどきをしてたらめっちゃアラート出てきました。
ルートオブジェクトについたMMDEngineからSendMessageしてCCDIKSolver.Solveを呼び出していまるので上記に該当してたわけですね。

無効化したスクリプトに対しても何事もなくSendMessageを呼べてしまうの、んっ!? となったけどいいんでしょうかね

ともかく、髪IKがどうこうみたいな問題もありますので、一旦これでコミットしま(す|した)
(CCDIKSolver.Solveの先頭に if(!this.enabled) return; が増えただけですが)


追記

3.5のときはこの問題(?)はなかったような気がしますけど、多分気のせいですね。
その内確認するかもですが、別にやったからといって、うぅん・・・


Inspector拡張の

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

MMD for Unity (http://sourceforge.jp/projects/mmd-for-unity/) で、メニューアイテムからじゃなくてインスペクターでPMD->PrefabとVMD->Animationが出来たらいいなー、と思ってあれこれ弄って詰まったのでその話を。

 

Unity拡張ってどうやんねん!という話はしないので、http://www.slideshare.net/lucifuges/extending-the-unity-editor とかみてください。ほぼすべてなんでも出来るようになるので、ここ設定するのに使いづらいなーというポイントがあれば、改善できる可能性があります。
試しにやってみましょう。

本題です。まず必要なのは、Projectウィンドウで選択されたものをInspectorウィンドウに表示する方法です。

通常のInspector拡張であれば、

[CustomEditor(typeof(MyScript))]
public class MyScriptEditor : Editor
{
  public override void OnInspectorGUI()
  {
    EditorGUILayout.LabelField("Its MyScript");
  }
}

というような感じでできます。

 

このときのCustomEditor属性の第一引数に適当なクラス型を入れることで、そのクラス型に対する拡張になります。この場合は、MyScriptというクラス専用のエディタ拡張になります。
(実際に試していないのですが、)MyScriptを適当なオブジェクトにくっつけてやると、MyScriptEditorのインスタンスが勝手に生成されて、Inspectorには"Its MyScript"というラベルが表示されているはずです。

で、これを、Projectウィンドウにどう引っ掛けるか。
色々試した結果、typeof(UnityEngine.Object)を指定すればいいようです。
但し、これは全てのアセットを対象に出来ないようで、Unity側でInspectorが用意されていないもの、が該当になります。
(例えば、認識されない拡張子、*.unityファイル(シーンを保存したもの)、フォルダ、など)

CustomEditor属性の第二引数にtrueを指定することで、そのクラスを継承した子クラスにも適用されるらしいですが、その指定をしてもMaterialだったりTextureだったりには設定出来ませんでした。

 

さて、[CustomEditor(typeof(Object))] と指定すれば引っ掛けられることがわかったので、後はPMDLoaderWindow.csに含まれるGUI部分を移すだけで出来ました。

 

が!! 問題はここから。
別のファイルに分けたほうがよさそうなのでVMD用InspectorをPMD用Inspectorからコピーして作ったところ、VMD用Inspectorが動作しないじゃありませんか。

コンストラクタでDebug.Logをするように書いてもVMD用Inspectorのインスタンスが作られる雰囲気もないので、うーん。
推測として、CustomEditor属性の挙動が、最初に読み込まれた(実行された)方が優先されて、どうこう、みたいな。

MMD for Unityの中に閉じた問題なら、InspectorBaseみたいなものを作って、そこからPMDorVMDに振り分ければいいと思います。ですが、もし他のエディタ拡張スクリプトを導入なり自作なりで、そちらでも同様に[CustomEditor(typeof(Object))]が行われていた場合を考えるとぐぬぬ。

 

Editorを継承すると、"target"という変数が使えるようになるのですが、Unityに認識されない拡張子またはフォルダの時に、これに入ってくる値の型が、UnityEngine.DefaultAsset という内部型みたいです。
グーグル大先生に聞いてもなにひとつそれっぽい答えがでてこなかったので、それが分かっても問題解決への鍵にはなりませんでした。

 

某所になんかいい方法ないですかと質問を投げたのですが、「そもそもの話、そんなことしようとする人口数~w」という気がするのでうーん。諦める方向ですかねー…

あ、カスタムインポータを書いて、UnityにPMDが放り込まれたら自動的に読み込むというのもアリ...?
どちらにせよ、現状で特につらぽよポイントは無さそうなので、それが出来なくても、あ、はい、程度な気がしますね。

 

参考URLとか:

  • http://docs.unity3d.com/Documentation/Components/gui-ExtendingEditor.html
  • http://docs.unity3d.com/Documentation/ScriptReference/CustomEditor.CustomEditor.html
  • http://answers.unity3d.com/questions/11680/how-can-i-make-a-custom-inspector-for-this-object.html
  • http://forum.unity3d.com/threads/101654-Showing-Unknown-Extensions-in-the-Inspector

 
 

そうだそうだ、「Materials」「Materials 1」「Materials 2」「Materials 3」....と増え続けていくバグは直ったので、r143でコミットしました。

Unite Japan 2013のまと

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

量が長すぎるので、この1記事で簡単にまとめます。

Day1

  • ◆ 基調講演
    ゲーム開発はインディーズにもやさしくなってきている。
  • ◆ "Unity for Wii-U"とWii-Uでのゲーム開発
    WiiU向けゲームをUnityで作れます ※ただし法人に限る
  • ◆ Nintendo Web Framework のご紹介
    既存Web技術でWiiU向けゲームを作れます ※ただし法人に限る
  • ◆ シリアライズ徹底解説
    ScriptableObject!ScriptableObject!
  • ◆ Editorスクリプティング入門
    エディタ拡張楽しいですし、ゲーム開発する上で必要になるのでやりましょう
  • ◆ Androidでコンテンツを守る方法 -Unity,Androidでのプログラムとデータの暗号化、およびハッキング対策-
    重要データは自分(開発者)自身で暗号化・難読化を施して守ること。
  • ◆ モバイル向けShuriken活用法
    EmitSharpは使わない!Speedも使わない!現実を見よう!

Day2

  • ◆ Mecanim徹底解説 & 最新機能アップデート
    アニメーションすごいので使いましょう
  • ◆ Unityでのメモリープロファイリング
    OnGUIはダメ、Disposeしろ、オブジェクトプールしろ
  • ◆ 2Dコンテンツのためのワークフロー
    最高に使いやすいツールを使おう。
  • ◆ iPhoneでリアルタイムマルチプレイを実現!
    PhotonCloudは無料枠あるので試しにやってみて。
  • ◆ AssetStoreマニアクス2nd
    高速な開発に必要なスクリプトセットだったり高機能なエディタだったり色々あります
  • ◆ 自動車と飛行機は何が違うのか? ~コンシューマーゲーム開発者から見た Unity~
    ワークフローの違いがあるので、そこを考えずに自社エンジンやらからUnityに移るとしぬ

いやはや、Unite2013参加してよかったです。
Unityにがっつりと触っている人ではないですけど、そんなことできたんだ、そんなテクニックがあるんだ、などなど新しい発見が多くありました。

ここで得た知見はぜひとも MikuMikuDance for Unity での活用や、個人でちらほらやるときに活用したいです。
例えば Mecanim のアニメーションはとても強力ですし、Unity4時代のキャラアニメーションはあれが主力になっているんじゃないですかね。これは必ずMFUに導入したいです。現状がどうなっていたか、ここ最近触っていなかったのでわかりませんが、対応が微妙だったような...
他にもエディタ拡張。現在別ツールになっているIKBakerをUnityに内蔵したり、PMD/VMDのインポータをかっこよくしたり、というのもありですよね。あとFBXファイルなどのように、そのファイルを選択するとInspectorからプレファブにできたりというのもできると良さそうです。

これからUnity触るのが楽しみすぎる!

Unite Japan 2013 Day2の

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

正直なところ、それぞれのセッションのまとめだけ書いておわり~としたいです。
ですが、まあ、なんといいますか、自分用のメモとしてもちゃんと残しておきたいのでちゃんと書いてあります。

◆ Mecanim徹底解説 & 最新機能アップデート

Mecanimとは? => Unity4から搭載された新しいアニメーションシステム(http://docs.unity3d.com/Documentation/Manual/MecanimAnimationSystem.html)
Humanoidであれば腕や足、胴体、頭などがあり、それぞれに該当するオブジェクトを設定することで、Humanoid向けに作られたアニメーションがなんでも使える。
(例えば、テストはわかりやすい様な人型モデルで、本番は着ぐるみだったりヒラヒラしてるようなモデルだったり)
アニメーションのステート制御ができる。などなど、続きは公式で。

このセッションは始めにちょこっとだけ説明があって、あとはデモベースで進んで行きました。

プロジェクトウィンドウでアニメーションを選択すると、プレビューウインドウから動きを確認できます。
そのとき、0.3秒~1秒までの間をほげほげアニメーションとしてインポートというように範囲を選ぶことができます。
インポートはAnimatorウィンドウにドラッグアンドドロップでできます。

デモでは既にアイドル、走るのステートが登録されていました。
ここに"スライディングでフェンスの下をくぐるアクション"を追加をしていきます。

1.走るアニメーション時にキー押下でスライディングフラグを立てる
2.スライディングアニメーション時に特定パラメータがしきい値を超えた時にColliderを無効にする
3.Animatorウィンドウにアニメーションを放り込む
4.スライディングフラグがON(事前に自前のスクリプトで定義していた模様)なら遷移するように設定
5.Inspectorウィンドウからブレンド具合を確認
6.ブレンドに不満があったら自分で調整をする
7.特定のパラメータのカーブをアニメーションに合わせて調整する

という流れです。

Inspectorで確認したときに、足付近にIKピボットが表示されます。
これはUnityが内部で自動で計算し、アニメーションが不自然に見えないように調整してくれています。
しかし、アニメーションによってはそのミスマッチが発生することがあるので、その場合はブレンド具合を調整して直します。

さらに"フェンスに手をついて飛び越えるアクション"を追加していきます。
ターゲットマッチングを使うことで実現ができます

1.先ほどと同様にアニメーションを追加する
2.RayCastを行い、フェンスと一定の距離でのみアニメーションをする
3.その時のRayCastのデータを利用して、フェンスに対しての手とターゲットのマッチングを行う
(animator.MatchTarget(ターゲット位置、ターゲット回転、部位、MatchTargetWeightMask, 開始時間, 終了時間))

これはドアの開け閉めや武器を取り出す時のモーションなど、なんか色々使えそうです。
(武器の場合は後述するIKリグの方がよさそう)

新機能として、2Dブレンドツリーがあります。
これは向きと速度のブレンドをスマートに行うときなどに使えるようです。

そして、アニメーションのレイヤを追加して"ダメージを受けて倒れる"動きをつけていきます。

1.Animatorウィンドウから新規アニメーションレイヤーを作成する
2.Maskオプションに、足、胴体、頭のマスクを設定
2.Syncオプションの有効

Maskオプションは、アニメーションの適用されるオブジェクトを指定します。
Syncオプションは、別のレイヤーとアニメーションの同期をすることができます。
要するに別レイヤーのステートマシンをまるまるコピーされてくるような具合です。
これら2つを組み合わせることで、走りながら倒れていく、というような表現が簡単にできるようです。

最後にIKリグを使った武器の装備を行います。

1.武器をプレイヤーオブジェクト内に内包する
2.アニメーションレイヤーを増やして、IKpassをONに
3.AnimatorIKメソッドを定義して、そのなかでIKのポジションを設定する

なお、このデモで使用したファイル一式はアセットストアよりDLできるようです。
が!どれだか分らなかったので、それっぽそうな公式ファイルを列挙しました。
http://u3d.as/content/unity-technologies/mecanim-locomotion-starter-kit/4jU
http://u3d.as/content/unity-technologies/mecanim-example-scenes/3Bs

◆ Unityでのメモリープロファイリング

Pro限定の機能ですが、UnityにはCPU時間やメモリ使用を確認できるツールが付属しています。
これを正しく使うことで、どんなオブジェクトまたはどんな処理に対してCPUやメモリが割かれているのか、
また、メモリリークなども分かり、どこがネックなのかというのがすぐにわかります。

この講演では、タイトルにあるようにメモリの使い方について焦点があてられていました。

まず、マネージドとネイティブがあります。
マネージド:Mono、GCあり、アセットやゲームオブジェクト、スクリプトなど
ネイティブ:Unity、GCなし、メッシュだとかエンジンの中身にかかってくるあたり。

マネージドはヒープ領域が使われ、いっぱいになるまでもぐもぐしていきます。
いっぱいになった所でGCが走り、解放されていきます。
その際、フラグメントなどが発生し、その後のパフォーマンスに影響を及ぼす可能性があります。
そのためプロファイル機能で確認できる"メモリアクティビティ"を低く保つことが重要だと言っていました。

では、メモリアクティビティを低く保つにはどうするか。
・メソッド内で大きな領域を使う一次変数をクラス変数にする
・クラスではなく構造体を使う
・弾丸などたくさん使うものはオブジェクトを生成し、非アクティブを活用し使いまわす => オブジェクトプール
・"OnGUI"は定義すら許されない
・IDisposableが付いたものは自主的にDisposeメソッドを呼び出す
・参照が残るようなことがないようにする => メモリリークに繋がる
・Resources.UnloadUnusedAssets()を使用する

例えば、WWWクラスを例にあげると、これは確実にDisposeを呼ぶ必要があります。
何故ならば、マネージド部分はシンプルですが、内部のネイティブ部分ではあれこれとしているので、インスタンスを作るとググっとメモリアクティビティが増えます。
Disposeを呼ばずに、nullを代入や放っておくのもよいですが、いつ解放されるかわかりません。

AssetBundleで考えてみます。
WWWから読み込み -> AssetBundle(非圧縮/圧縮,ファイル/データ) -> GameObject化
これをプロファイラで確認すると、
WWWインスタンス、AssetBundleインスタンス、内部のWebStreamインスタンス、テクスチャ等データ
という4つのものが発生します。

そのためAssetBundle.Unload(false)およびWWW.Disposeを確実に呼び出す必要があります。
また、テクスチャ等のデータが不要になった際には、UnloadUnusedAssets()を用いて排除する必要があります。

以降は質疑応答で出たものですが、

・モバイルでのメモリープロファイリング
Unityエディタではモバイル端末実機におけるメモリの状態を知ることができない。
Unity側ではさっくりとプロファイリングし調整、実機を使ってより詳細なプロファイリングを行なう必要があります。

・アセットストアにある"AsttroDude"
オブジェクトプールを上手くつかっているので、ぜひ見てください
=> http://u3d.as/content/unity-technologies/astro-dude/24Y

・使っていないスクリプトがメモリに影響するか
スクリプトに限らず、アセットで不要なものは除くのがオススメ。
もしかしたらUnity側にバグがあるかもしれないので、再現性や情報があればバグレポートを出してください。

・なぜ"OnGUI"がダメか
OnGUIが定義されているだけで、GUI関連の様々なクラスがロードされてメモリもぐもぐしてしまう。
それも毎フレーム実行されてしまうので、メモリだけでなくCPUももぐもぐされます。
仮に空っぽのOnGUIでも、ifで処理をしないようにしたOnGUIでもダメです。
どうしてもOnGUIが必要な場合はプリプロセッサを上手く使って有効/無効を切り替えてください。

◆ 2Dコンテンツのためのワークフロー

・2Dアートツールとして、あなたにとって最高に使いやすいツールを使ってください
・メタデータを上手く使用し、Unity側であれこれ度々追記することが少なくなるようにするといいでしょう
・2Dのためにぜひともエディタスクリプティングをしてみてください。

ということでした。
えっと、お昼直後で眠たかった、というわけではなく、最前列近辺だったので首がいたかったのです(白目

◆ iPhoneでリアルタイムマルチプレイを実現!

マルチプレイには「リアルタイム」と「非同期」の2種類があります。
「非同期」
ソシャゲや将棋など、リアルタイム性の少ないもの。
Web技術の応用でできるので、オープンソースのライブラリなども多く扱いやすい。
コストは少なめ。

「リアルタイム」
FPSや格闘ゲーム、今ここでオンラインの人がいるんだ!というもの。
TCP/UDPの様に低レイヤの話であったりNAT貫通とかとか小難しい話が出てくる。
遅延が許されない(=> クソゲー化、波動拳が入力後1秒で出て勝てるか)
オープンソースは少なく、費用がかかってしまいがち。

Unity標準のNetwork機能は

  • ・クライアントがホストになる必要がある ≠Dedicatedサーバー
  • ・便利な機能がたくさんあり、未経験でもデモはすぐに出来た

という特徴があるようです。
(一度あれこれ調べたはずなのですが、すっかり忘れてしまってました...)

モバイル端末がホストになることは帯域や安定性からして非常に難しいようです。
そこでゲームサーバを外部に用意して行う方法が求められ、条件に合うのがPhotonだったようです。

PhotonはUnityとほぼ同じNetwork郡の命令を持っており、また料金もさほど高くないとのこと。
Photonの構成はこうなっているようです。

  • Windowsサーバ:.NET -> C/C++コア -> ReliableUDP/TCP
  • クライアント:PhotonSDKライブラリ

ライセンス形態はこうなっています。
PhotonCloud:同時接続人数や転送速度に応じて金額が変わる。サーバの用意が不要。無料枠あり。
PhotonServer:サーバ用のプログラムの販売。Windowsサーバが必要。
サーバ側のプログラムをちょっといじりたい、という場合にはPhotonServerでないと出来ないとのこと。
ただし、Windowsサーバが必要ということに加え、情報がそんなに多くなく英語ばかりということなので、構築は"イバラの道"

Photonクライアントを利用して同期を取るには、"StateSync"と"RPC"の2つが用意されています。
"StateSync"はそのとおり同期してくれ、"RPC"はメソッド呼び出しの同期が取れます。

PhotonNetwork.offlinemode = true;
とすることで、オフライン状態への以降も特に障害なく行なってくれるようです。

手間を考えると常に複数端末でオンラインでテストをするわけにもいかないので、Unityエディタの拡張を上手く使って、オフラインからテストできる仕組みを用意するとよさそうです。
また、Macがメインの会社なのでMac版Unityならでは?の複数起動の裏ワザも使っていたとのこと。

◆ Unity Hacks

そういう使い方があったか!とか、データの使い回しやあまり知られてなさそうな事など、生産性を挙げるアイデアの生まれる種になれば。
というような趣旨の講演でした。

・AnimationCurve
入力の向きに応じた速度変化やカメラの移動量など、"2D的に変化のあるデータ"を表現するのに使えます。
アニメーション用途以外にも活用できるので、いまの開発現場に活かせる箇所があるかもしれません。
また、ビジュアル的に見えるので、キーフレームを打ちつつデータを取る、といったデバッグ用途でも使えます。

・データの使い回し
例えばステルスゲーム、ライトの当たらない暗闇に入るとキャラが影にかかって薄くなる、みたいなものですね。
その場合は LightmapSettings.lightProbes.GetInterpolatedLightProbe(とrender.transform.positionなど)を使うとライティング情報が取得できるようです。
つまり、ライトが気に食わなかったら移動してベイクして、それだけでスクリプトの編集は不要になります。

・ReflectedState
enumとAction、Dictionaryを使ってステートマシンを作る、というテクニックです。
enumは列挙型、Actionは.NET frameworkにあるメソッド参照、デリゲートです。Dictionaryはkey-valueペアが作れるリストです。

enumで定義して、StartメソッドでDictionaryに放り込む。
呼び出したいところでUtillity.Get~~~(メモ書きがここで途切れている)

でこうなんかうまいことつくるとちょっと便利になる、ということだそうです。

・WebPlayer
これは過去に闇鍋プログラミング勉強会#2で話してきたのでめっちゃ理解してます(多分)
-> http://stersblog.blog15.fc2.com/blog-entry-427.html スライドの37-45あたり。

Unity → WebBrowser
Application.ExternalCall(func_name, data)
Application.ExternalEval(js_string)

WebBrowser -> Unity
Unityオブジェクトに対して SendMessage(game_object_name, func_name, data)

・Rapid Game Devlopment
ゲーム開発の高速化、みたいな話かな?
昨年のUnite2012で話していた内容なので録画した動画をみてくれ、とのこと。
-> http://angryant.com/videos/

・Importer/Exporter
プログラマーとデザイナー、企画管理などいろんな人がゲーム開発に参加して、それぞれで共有しておきたいデータがあるはず。
例えばプロジェクトファイルそのものだったり、テクスチャ・モデルなどのアセット、オブジェクトの設定などを共有する必要がある。
そこで、インポータ・エクスポータの拡張などをしたほうがよい場合がある。

ScriptableObjectを継承してシリアライズ~なんてのをうまく使えばできるはず。

・ワークフローの自動化
なぜ? -> 生産性の向上

例えば、Androidのネイティブコードを追加したい。
でもJavaコードの編集して、コンパイルして、Unityに追加して、バグがあれば編集して、コンパイルして、Unityに~~~と毎回繰り返すのはつらい。
そこで、javaコードをUnityでコンパイルできるようにしてしまおう、というもの。
コンパイルできればADKだって不要だし、煩わしいコマンドを叩く必要もないし、なによりUnityに統合できるのがつよい。
(コンパイルだったかEvalだったか少し怪しいですが...)

やり方としては、CodeProviderとか?Microsoft.JScriptとか使うんですかね(よくわからなかった..

・マニフェストファイル
アップデート(?)の時に厄介なことになるらしい。
なのでアセットとして放り込んでおきたいよな、ということ。
バンドルしてプレファブを生成するとで可能になるらしい

・プレファブバンドル
データをシリアライズすることで可能になる。ScriptableObjectの有効利用とのこと。
これをすると、独自のエディタ拡張で設定した値やら何やら、はたまたGameObjectのプロパティなんかをプレファブとしてどんどん保存できる。
ただ、もちろんのことだけども、ゲーム中に読み込むならそれを読むプログラムを書く必要がある。
・・・でもシリアライズの逆をするだけなのでそんなに難しいこともない...?

・スクリプトバンドル
外部のエディタであれこれ書いてビルドし、~~.dllに相当するものを生成。
これをUnityスクリプトからAssembly.Loadなんかを使うといい感じに使える。
Day1の暗号化の話でも触れていたはず。

このように色々なTipsがある。
これらを利用して、みなさんのゲーム開発現場に置いてなにか改善できるひらめきが生まれるといいでしょう。

今年は昨年の講演に比べて、より実践的なことを話しました。
ではでは、みなさんはどのようにして生産性をあげていきますか?

◆ AssetStoreマニアクス2nd

・iOS/Android Etcetera Plugin
モバイル端末を扱う基本的なスクリプト集
わかっている人なら不要では?

・CutScene Creator - uSequencer
高機能なカットシーンエディタ
つまりはオブジェクトアニメーションをシーン全体でやるようなもの?

・Play Maker
ステート制御により、スクリプト不要でゲームが作れる。
状態遷移やパラメータ変更などができる。
SendMessageを利用することでスクリプトと連絡が取れるが、やりすぎると複雑化してダメ

・Rage Spline
スプライン曲線が書けるやつ。
横スクロール型2Dゲームでの曲線なマップを視覚的につくることができる。

・Smooth Moves
2Dスプライトのボーンアニメーションを簡単にできるやつ。
1枚の画像から切り出したり、タイムラインがあったり高機能。

・Pool Manager4
プレファブの事前生成やプリロードの仕組みを提供する。
「メモリープロファイリング」の時に聞いた話を簡単に実装できる。

・FxMaker
エフェクトツール。
ゲームビューでコントロールできるという(いい意味で)わけの分からないプラグイン
エフェクトを作ったりプリセットを利用したり、コピペできたりなんかもうすごい。

・結論
エディタ拡張すごい。ここまで出来るのか、というのを教えてくれる。
なかなか有料アセットに手を出しづらい(がっつりゲーム開発してるわけでもない)ので、実際に動かして紹介してくれるというのはありがたい。

◆ 自動車と飛行機は何が違うのか? ~コンシューマーゲーム開発者から見た Unity~

>コンシューマ
変更が度々起こると、コストがすごいので仕様・仕組みをがっちり固める。
ゴールに対して直線的に、最短距離で進んでいくので早い気がする

>Unity
変更・調整を少人数・低労力で行うことができるので、低コストで繰り返せる。
最初はぶれぶれかもしれないが、完成に近づくにつれでどんどん固まっていく。
"道具を正しく使い": 1つずつ進めてゴールへ向かっていく
"より早く目に見える形で": 納得が行くまで試行、イメージの統一。
これがUnityではできる。

つまりはワークフローの違い。
CEDEC2011で、自動車と飛行機の違いという講演があり、まさしくここで感じたことと同じだった。

Unityは、そのシステムがイテレーションを意識しているので、開発手順だったりアプリだったりも合わせないといけない。
>パラメータをエディタから読み込む
>Unityで編集できないのでUnity外で管理はしない
>オブジェクト間の依存性を減らす
>コンポーネントベースなのでスクリプトを細分化する
などなど、Unityを邪魔しない設計が重要。

このようにUnityはラピッドプロトタイピングに力強さがある。
けど、それだけ、という理由でUnityを使うのであれば、元々の自社エンジンだったり、他のツールでもいいのでは。

Unityを選ぶなら他の強みを活かす。
>マルチプラットフォーム
>すべてを変えられるエディタ拡張
>意識せずともリッチなグラフィック


◆Unity for WiiUとNintendoWebFrameworkについて

あと、Day1に聞きそびれた任天堂のやつ関連で質問してきました。

法人向けしかないようで、個人で使えないのはなぜか。

任天堂は今までのノウハウを生かして、ビジネスとしてこういったツールを出している。
個人相手ではどのようにビジネスを展開するか、ということがまだ考えられていないため、個人向けにはまだ出せない。他にも、任天堂としてはWiiUでアプリ・ゲームを出して欲しい。そうなると必然的に販売ルートを確保できるような相手じゃないと難しい。
たとえばGooglePlayのようなアプリを配布するプラットフォームの準備が出来れば個人開発者の可能性も大きく高まる。
任天堂としてWiiUでアプリ・ゲームを出して欲しいので、法人向けと書いてあるがその法人の規模は特に問わない。
どうしてもツールを触ってみたい、WiiUでゲームを出したい、というのであれば起業するのも1つの手。
非公開のAPIを叩いたりアヤシイ事をするのは、そもそも開発者登録を済ませる必要があるのでやってもらってもかまわない。ただ、その部分の仕様が変わったりする可能性があるのでオススメはできない。

ちょっと抜けていたり足りなかったりするかもしれませんが、大体このような感じだったと思います。
WebFrameworkのほうはちょっと触ってみたかっただけあって残念。。
Unity for WiiUのほうは、UnityPro相当の機能が無料で全部つかえるっぽいです。

Day2の話を書きたかったという

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

なんだかうまいことまとまらないので出直してきます。

Day1であった任天堂製品(ref. https://gomiba.co.in/blog/?p=37 )についての質問をしてきたので、それについても書きます・・・・
( ˘ω˘ ) スヤァ...

Unite Japan 2013 Day1の

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

と!いうわけで、Unite Japan 2013 Day1へと行って来ました。
だって学生の早割が3kというので、これは行かなきゃと…

(Uniteってなんぞやという方 -> http://japan.unity3d.com/unite/ )

そこで聞いてきた、メモしてきた話を思い出しつつ補完しつつ書きました。
英語での講演もあったので若干解釈がことなる部分があるかもしれませんが、
そこは後日公開される資料であったり、他の方のブログ記事やメディア記事などを参照していただければと思います。

"書いちゃまずい系のもの"はとくに無かったかと思います。
もしあったのであれば申し訳ありません。すぐに消します。

◆ 基調講演
GDCに出てきているゲームの層にインディーズ系が増えてきていること。
5年前は難しかった無名少人数チームで壮大なゲームを作るのが今では可能なこと。
Unityはそれを実現するツールとして優秀なこと。

REPUBLIQUEおもしろそう!楽しみにしています!!

République

 

◆ "Unity for Wii-U"とWii-Uでのゲーム開発

今普及しているUnityとは別物にとして、"Unity for Wii-U"として別途用意されるようです(auのSkypeみたいなアレ)
SDKの都合からか、OSはWindows専用だそうです。
また、リリーススケジュールとしては、通常のUnityと同期して行い、例外的に追加機能が先に入ったり、ということもあるようです。

Wii-U向けのビルドは至って簡単で、ビルドセッティングのウィンドウからWii-Uを選択するだけ。
Windows/iOS/Androidとか書いてあるあの枠にWii-Uの項目が追加されます。

ビルドが完了すると、転送用のバッチファイルとROMデータが生成されるようです。
そのバッチファイルを起動すれば、何かしらの方法で接続している開発用の実機に転送され、実機テストができるとのこと。

Wii-Uといえば、ディスプレイのついたゲームパッドですが、そちらへの対応も簡単にできるようです。
その方法は、カメラを追加して、追加された項目である出力ターゲットをゲームパッドにするだけ。
実際にデモとしてAngryBots(Unityについてくるサンプルプロジェクト)にカメラを1つ追加して、ゲームパッドに3人称視点を出す、ということをやっていました。

Wii-Uの機能として用意されている、フレンド/アカウント/ストアなどへのアクセスは、C/C++のネイティブプラグインを導入することにより可能になるとのこと。

そして、開発者登録をすればUnityのProライセンスが無くとも、無償で全ての機能が利用できるということでした。

ただし!
残念なことに、日本からは個人での開発者登録はできないとのこと。。

 

◆ Nintendo Web Framework のご紹介

Webkitベースに作られた、Wii-U向けアプリケーションを最近流行りのHTML5で作れるフレームワークだそうです。
イメージ的には、PhoneGapとかTitaniumとか、それのWii-U版といったところでしょうか。

フレームワークの方でJavaScriptが拡張されており、Wii-U向けの各種命令郡が使用できるようです。
例えば、ゲームパッドとTVと違う画面を出力したり、ゲームパッドの傾きや振動を取得したり、フレンドやアカウント機能を使用したり....

デモでは、既存のWebページ(動画リストがあって、選択すると再生する)をWii-U向けにビルドしていました。
その時の特徴として、既存コードには一切の手を加えていないというところです。
既存コードにはjQueryやvideoタグなどが含まれていますが、その辺りをうまいことやってくれるようです。
(裏はWebkitが動いているようなので当たり前っちゃあ当たり前っぽい気も)

もう一つのデモとして、同じようにWebページとして作られたゲームがありました。
こちらは、Wii-Uでできることの総集編のようになっており、前述の拡張されたJavaScriptがフルに活かされているようです。
またこのデモはフレームワーク付属のサンプルのようになっており、ソースコードの至るところにコメントがしっかりと付いているとのことです。

最後のデモにベンチマークが出てましたが、これはどうにも比較対象がないのでなんとも。
700くらいのスプライトがでてるけど60fps維持できてますねー、というものでした。

そしてこれまた残念なことに、日本からは個人での開発者登録はできないとのこと。

 

◆ シリアライズ徹底解説

まずなぜシリアライズを行うか。
これはプレイデータの保存やエディタの状態を保存するために行う必要があります。
ここでは、エディタ内に絞った形で講演していました。

・プロジェクトの読み込み
・スクリプトのコンパイル
・ゲームのスタート、ストップ
といったタイミングでシリアライズが行われます。

適当なエディタウィンドウを作って適当にいじって、ゲームのスタート・ストップと行うと、
そのウィンドウ内のデータがシリアライズされてないと吹っ飛びます。

 

intとかfloatとかビルトインの場合は、publicにしたり、privateでもSerializeFieldアトリビュートをつけることで解決します。
自作クラスの場合は、クラス自体にSerializableアトリビュートを付ける必要があります。
この2点を守ればデータのシリアライズが行われます。

また、structsはシリアライズがされないので、シリアライズしたい構造体があるのであれば、クラス化しましょう。

 

ここでシリアライズの問題点として、クラスを参照する場合がでてきます。
同じインスタンスを参照する変数を2つ用意してシリアライズしようとすると、片方しか反映されないとのことです。
なぜならば、それらは別にシリアライズされてしまうからです。

この問題の解決には、ScriptbleObjectを継承したクラスにする必要があります。
その際に、nullチェックやhideFragを使うことで~~

Listなどのリストの場合、簡単なクラス(親クラス型のリストに子クラスのインスタンスを入れるとか"しない")の場合はうまくいきます。

逆に、それらが含まれる場合、そのままでは上手く出来ないので、ファイルを分けて~・・・・

 

シリアライズしたデータ(ScriptableObject?)から、アセットファイルの生成も可能になります。
AssetDatabase.CreateAssetを叩くといいようです。

-----
という具合で、正直よくわからんかったので勉強してきます。。
(英語だったのでよくわからんという点を差し引いても分らなかったとこがありました...)

 

◆ Editorスクリプティング入門

なぜUnityのエディタを拡張するか?という点について、
・他人が触るときに触ってほしくない箇所を隠す
・制約がめんどうなとき("ここはこう設定!"などと定められているなど)
・見やすくする
・編集しやすく、使いやすくする
といった点があり、ここは変えたほうがイイネ、という部分はいじっていきましょう。

では、エディタを拡張が具体的に何ができるか。

 

1つに表示項目の改善があります。
これは例えば2Dゲーム開発でのTransformのZ軸を隠したり、テクスチャの設定欄に小さい窓をつけたり。
メニュー項目を追加したり、シーンビューに追加のハンドルを表示したり、などなど可能性は色々あると思います。
現に、アセットストアに出てる凄い系のものに付属しているエディタちっくなものは、そういった拡張がアツいと思います。

 

もう1つはビルド前後に処理ができるようになります。
具体例こそ示されていませんでしたが、現場の方々であれば色々と必要そうなアレコレをできるのではないかと思います。
最後に、アセット管理における移動や削除の制御ができます。
これらのファイルはこのフォルダ!など、パスに対してマッチングさせて制御するコードを書いていきます。

今回の講演では、主に1つ目。表示項目の改善などについてでした。

(なんだかメモ書きがすごい適当でまったくわからない現象が...)
まとめると、Editorクラスをちゃんと理解しましょう。理解していじらないと最悪Unity毎オチます。
理解した後に、EditorWindowだとか、CustomEditorだとか、シーン/ゲーム/プロジェクト/ヒエラルキーなどへと広げていくといいようです。

余談ですが以前、タワーディフェンス的なサムシングをやろうかと、UnitySteerを使いパス...というか座標を辿るものを使いました。
その時、座標のリストを作るときに、シーンビュー上に"座標の箇所にハンドルを設置してマウスで操作できるように"したらめっちゃ楽でした。

 

◆ Androidでコンテンツを守る方法 -Unity,Androidでのプログラムとデータの暗号化、およびハッキング対策-

セキュリティを最近勉強しはじめている私にとっては今日一番わくわくしていたものです。

まず、Unity on Androidは
Linux | Android | Unity | Mono | Script
という形で、Unityを堺にJavaVMとMonoVMが動いているような。
Unityが何をしているかというと、C#で書かれたスクリプトをJavaへとマッピングを行なっています。

 

よくある?ハックとして課金コンテンツがあります。
これは、AndroidであればGooglePlayLicenseを経由して行われます。

その仕組みは
App -> {random number} -> Google
App <- {message, signature} <- Google
という流れで行われます。
オンライン環境であれば、定期的に確認すればいいのですが、オフライン時にはユーザのデータを信用するしかありません。

また、そのメッセージ・シグネチャを保持するために、アプリのバックエンドにサーバを用意して、
同じような形式でやりとりするのが好ましいようです。

Unity上でこれを実現するには、"GooglePlayLicenseVerification"というライブラリがGithubで公開されているので、
それを使いましょう、とのことです。

 

次にアプリケーションの改竄を検出する方法です。
これは、ゲームコードの変更やチートなどの不正行為を防止するために必要です。

チェックする項目は
・アプリがデベロッパーのプライベートキーで署名がされているか
・Javaコードが正しいか(class.dex)
・Unity/Monoが正しいか(Unityランタイム郡)
・C#コードが正しいか
というものがあります。

詳しくはわからないのですが、こういったことはAndroid開発者の方々には当たり前なのでしょうか。
C#などUnity側からでもJavaのコードを実行できるのでそれで確認しましょう、という具合でした。
(AndroidJavaObjectというクラスが用意されており、それで実行できます)

 

次は暗号化です。

・ゲーム進捗
Unityでは簡単にゲーム進捗を記録できるPlayerPrefsというクラスが用意されています。
そのままではやはり簡単に編集され、メダルXXXXX枚などとされてしまう可能性があります。

これは、key/valueのペアとして記録することに加えて一工夫することで改善できます。
例えばkeyは本来のkeyのハッシュ値、valueには保存するべき値に対してTripleDESなどを掛けるなどを施します。

・スクリプト
スクリプトは暗号化、よりも難読化がメインになります。
ただし、Unityで書けるプログラムは何の変哲も無い普通のC#なので逆コンパイルなどが容易であり、難読化されていても解読は可能です。
Unityのビルドではここに対してなんの暗号化/難読化も掛けられません。
ゲームの根本に関わるような大切なソースコードであれば、自分で暗号化/難読化が必要です。

1つの案としてOpenSSLを使うものがあります。
~.dllとして外部でコンパイルし、それを暗号化して~.binに。これをアセットまたはwebに配置からの通信などを行い、ゲーム内で復号化して実行する。
読み込み部分はAssembry.Loadとリフレクションを使うことで可能になります。

やっぱりこちらもシグネチャの確認は定期的に行ったほうがよいようです。

・アセット
テクスチャやポリゴン、音声やBGMといったメディアだけでなく、上記のような暗号化されたスクリプトやデータベース、プラグインなど、すべてがアセットになります。
これはスクリプトと同様に、~.unity3dを暗号化するのが1つの方法としてあります。
具体的な読み込み方法に関しては特に触れてなかったかと思います。

 

まとめとして、
・APK自体のチェックを怠らない
・重要なコードは自分で保護する(暗号化/難読化)
・様々なアプローチを試行する
・ただしアプリケーションの保護に時間をかけ過ぎない。

この最後の点に関しては、そもそもGooglePlayにアップデートを定期的に早めにリリースするのが良いとされているようなので、
時間をしっかりかけて守るよりも、ぼちぼちな感じでアップデートの方に力をいれたほうがいいよねーみたいな具合でした。

 

◆ モバイル向けShuriken活用法

(これまたメモが凄いメモの役割を果たしていなかったのでさっくりと....)

1.本当にパーティクルが必要か
それはアニメーションテクスチャで出来ないのか。
もっとよい表現方法はないか。

2.そのパーティクルはどう構成されているか
例えば爆発なら火と煙と破片と根本と、4つ?いやいや2つでいけるのでは?
1つのパーティクルに内包されるパーティクルはすべて同じ力を加えなくてはいけない。=> コピペで色やテクスチャのみを変える

3.どのようにパーティクルは流れていくのか
EmitSharpは使わない!Speedも使わない!
-> 表現力が乏しい

ForceとVelocityのカーブを調整して表現する。
このとき、キーフレを追加して、曲線を自由自在に操ることができる。
基本的にはVelocityを使い、力が必要な場合(ex.爆発)でForceを使う

4.パーティクルと一緒にマテリアルを作る
炎のパーティクルを作るなら、火・煙のマテリアルを作りながら、適用しながら。

// 残りはパーティクル作成デモのような形でちょいちょい部分部分の説明があったかと思います。

 


長くなってしまいましたが、Unite Japan 2013 Day1で参加した講演はこのような具合でした。

Wii-UのAngryBotsが企業ブースに置いてありましたが、
まったく触れてなかったので、Day2で触ってみたいと思います。