PhotonServer:サーバ用のプログラムの販売。Windowsサーバが必要。サーバ側のプログラムをちょっといじりたい、という場合にはPhotonServerでないと出来ないとのこと。Windowsサーバが必要ということに加え、情報がそんなに多くなく英語ばかりということなので、構築は"イバラの道"Photonクライアントを利用して同期を取るには、"StateSync"と"RPC"の2つが用意されています。"StateSync"はそのとおり同期してくれ、"RPC"はメソッド呼び出しの同期が取れます。true;とすることで、オフライン状態への以降も特に障害なく行なってくれるようです。手間を考えると常に複数端末でオンラインでテストをするわけにもいかないので、Unityエディタの拡張を上手く使って、オフラインからテストできる仕組みを用意するとよさそうです。Macがメインの会社なのでMac版Unityならでは?の複数起動の裏ワザも使っていたとのこと。Hacksそういう使い方があったか!とか、データの使い回しやあまり知られてなさそうな事など、生産性を挙げるアイデアの生まれる種になれば。いうような趣旨の講演でした。・AnimationCurve入力の向きに応じた速度変化やカメラの移動量など、"2D的に変化のあるデータ"を表現するのに使えます。アニメーション用途以外にも活用できるので、いまの開発現場に活かせる箇所があるかもしれません。ビジュアル的に見えるので、キーフレームを打ちつつデータを取る、といったデバッグ用途でも使えます。・データの使い回し例えばステルスゲーム、ライトの当たらない暗闇に入るとキャラが影にかかって薄くなる、みたいなものですね。LightmapSettings.lightProbes.GetInterpolatedLightProbe(とrender.transform.positionなど)を使うとライティング情報が取得できるようです。ライトが気に食わなかったら移動してベイクして、それだけでスクリプトの編集は不要になります。・ReflectedStateenumとAction、Dictionaryを使ってステートマシンを作る、というテクニックです。frameworkにあるメソッド参照、デリゲートです。Dictionaryはkey-valueペアが作れるリストです。enumで定義して、StartメソッドでDictionaryに放り込む。呼び出したいところでUtillity.Get~~~(メモ書きがここで途切れている)でこうなんかうまいことつくるとちょっと便利になる、ということだそうです。スライドの37-45あたり。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がある。これらを利用して、みなさんのゲーム開発現場に置いてなにか改善できるひらめきが生まれるといいでしょう。今年は昨年の講演に比べて、より実践的なことを話しました。Makerステート制御により、スクリプト不要でゲームが作れる。状態遷移やパラメータ変更などができる。Splineスプライン曲線が書けるやつ。横スクロール型2Dゲームでの曲線なマップを視覚的につくることができる。Moves2Dスプライトのボーンアニメーションを簡単にできるやつ。1枚の画像から切り出したり、タイムラインがあったり高機能。Manager4プレファブの事前生成やプリロードの仕組みを提供する。「メモリープロファイリング」の時に聞いた話を簡単に実装できる。・FxMakerエフェクトツール。ゲームビューでコントロールできるという(いい意味で)わけの分からないプラグインエフェクトを作ったりプリセットを利用したり、コピペできたりなんかもうすごい。・結論エディタ拡張すごい。ここまで出来るのか、というのを教えてくれる。有料アセットに手を出しづらい(がっつりゲーム開発してるわけでもない)ので、実際に動かして紹介してくれるというのはありがたい。Unity~>コンシューマ変更が度々起こると、コストがすごいので仕様・仕組みをがっちり固める。ゴールに対して直線的に、最短距離で進んでいくので早い気がする>Unity変更・調整を少人数・低労力で行うことができるので、低コストで繰り返せる。最初はぶれぶれかもしれないが、完成に近づくにつれでどんどん固まっていく。納得が行くまで試行、イメージの統一。これがUnityではできる。CEDEC2011で、自動車と飛行機の違いという講演があり、まさしくここで感じたことと同じだった。Unityは、そのシステムがイテレーションを意識しているので、開発手順だったりアプリだったりも合わせないといけない。>パラメータをエディタから読み込む>Unityで編集できないのでUnity外で管理はしない>オブジェクト間の依存性を減らす>コンポーネントベースなのでスクリプトを細分化するなどなど、Unityを邪魔しない設計が重要。このようにUnityはラピッドプロトタイピングに力強さがある。それだけ、という理由でUnityを使うのであれば、元々の自社エンジンだったり、他のツールでもいいのでは。Unityを選ぶなら他の強みを活かす。WiiUとNintendoWebFrameworkについてあと、Day1に聞きそびれた任天堂のやつ関連で質問してきました。法人向けしかないようで、個人で使えないのはなぜか。任天堂は今までのノウハウを生かして、ビジネスとしてこういったツールを出している。個人相手ではどのようにビジネスを展開するか、ということがまだ考えられていないため、個人向けにはまだ出せない。他にも、任天堂としてはWiiUでアプリ・ゲームを出して欲しい。なると必然的に販売ルートを確保できるような相手じゃないと難しい。GooglePlayのようなアプリを配布するプラットフォームの準備が出来れば個人開発者の可能性も大きく高まる。任天堂としてWiiUでアプリ・ゲームを出して欲しいので、法人向けと書いてあるがその法人の規模は特に問わない。してもツールを触ってみたい、WiiUでゲームを出したい、というのであれば起業するのも1つの手。非公開のAPIを叩いたりアヤシイ事をするのは、そもそも開発者登録を済ませる必要があるのでやってもらってもかまわない。その部分の仕様が変わったりする可能性があるのでオススメはできない。抜けていたり足りなかったりするかもしれませんが、大体このような感じだったと思います。WebFrameworkのほうはちょっと触ってみたかっただけあって残念。WiiUのほうは、UnityPro相当の機能が無料で全部つかえるっぽいです。data-src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>。