と！いうわけで、Unite Japan 2013 Day1へと行って来ました。 だって学生の早割が3kというので、これは行かなきゃと…
（Uniteってなんぞやという方 -> http://japan.unity3d.com/unite/ ）
そこで聞いてきた、メモしてきた話を思い出しつつ補完しつつ書きました。 英語での講演もあったので若干解釈がことなる部分があるかもしれませんが、 そこは後日公開される資料であったり、他の方のブログ記事やメディア記事などを参照していただければと思います。
“書いちゃまずい系のもの"はとくに無かったかと思います。 もしあったのであれば申し訳ありません。すぐに消します。
◆ 基調講演 GDCに出てきているゲームの層にインディーズ系が増えてきていること。 5年前は難しかった無名少人数チームで壮大なゲームを作るのが今では可能なこと。 Unityはそれを実現するツールとして優秀なこと。
REPUBLIQUEおもしろそう！楽しみにしています！！ http://www.camouflaj.com/
◆ “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活用法
（これまたメモが凄いメモの役割を果たしていなかったのでさっくりと….）
１．本当にパーティクルが必要か それはアニメーションテクスチャで出来ないのか。 もっとよい表現方法はないか。
２．そのパーティクルはどう構成されているか 例えば爆発なら火と煙と破片と根本と、４つ？いやいや２つでいけるのでは？ １つのパーティクルに内包されるパーティクルはすべて同じ力を加えなくてはいけない。=> コピペで色やテクスチャのみを変える
３．どのようにパーティクルは流れていくのか EmitSharpは使わない！Speedも使わない！ -> 表現力が乏しい
ForceとVelocityのカーブを調整して表現する。 このとき、キーフレを追加して、曲線を自由自在に操ることができる。 基本的にはVelocityを使い、力が必要な場合（ex.爆発）でForceを使う
４．パーティクルと一緒にマテリアルを作る 炎のパーティクルを作るなら、火・煙のマテリアルを作りながら、適用しながら。
// 残りはパーティクル作成デモのような形でちょいちょい部分部分の説明があったかと思います。
長くなってしまいましたが、Unite Japan 2013 Day1で参加した講演はこのような具合でした。
Wii-UのAngryBotsが企業ブースに置いてありましたが、 まったく触れてなかったので、Day2で触ってみたいと思います。