強火で進め

このブログではプログラム関連の記事を中心に書いてます。

「COLOPL UnityNight」に行って来ました(その1)

「Unity - Asia Bootcamp Tour:東京」の2日目の夕方からコロプラさんにて「COLOPL UnityNight」が開催されました。

こちらのイベントはUnityの勉強会は「大人数+初心者向け」のものが多くなっているため、参加可能人数を少なめにして深く勉強し合える場所があると良いなと思い開催されたとの事です。

一歩進んだUnityの使い方 - ガンホー・オンライン・エンターテイメント株式会社 第1企画開発本部 西村 大介さん(@nishimuland)

▼アセット購入のメリット
・1から作るよりも圧倒的に早い
→基本的にUnityのアセットはUnity上で動作するデモプロジェクトと一緒に販売されているので、使えるようになるのも早い

・優秀なアセットが多数ある(しかも安い!)
→EZGUI等はGUIシステムが丸ごと入っているのに数千円で購入できる

だだし、売られている全てのアセットが優秀なわけはない!
同じ機能を持った複数のアセットを購入し、より良いものを選ぶというスタンスが重要!

▼アセット購入のデメリット
・バグを吐いた瞬間、修正に大きな工数がかかる!
→結果的に自分達で作った方が早かった…
 中身がブラックボックスになっていてお手上げな場合も…
(筆者注:ライブラリによってはソースでは無く、DLLファイルにした状態で提供されているものが有る)

スマートフォンのOSアップデートについてこれない!
→今後はAndroid 4.0やiPhone 5の発表に合わせたiOSのアップデートが怖い

アセット自身の出来の良し悪しはもちろん、開発者のサポートがどれだけ厚いのかもアセットを評価する上では重要!

実際に購入/試用したアセット群
【prime[31]】

prime31 - Mobile application and Unity plugin specialists
http://www.prime31.com/

  • StoreKit → iPhoneでの課金システムとUnityの繋ぎ込み
  • Android_StoreKit → 上のAndroid
  • GameCenter Plugin → iPhoneのGameCenter連動版
  • Social Networking Plugin → Facebook連動
  • Social Networking Android Plugin → 上のAndroid

【Above and Beyond Software】

Above and Beyond Software
http://www.anbsoft.com/

  • EzGUI → ケリ姫クエストのGUIは全部これで作成

【Ratrod Studio】

Ratrod Studio - Not your Ordinary Junk!
http://en.ratrodstudio.com/

Ratrod StudioのTwitterライブラリでバグが有ったがソースが提供されていたので修正が可能だった

【GamePrefabs.com】

GamePrefabs - Products
http://gameprefabs.com/

GoogleAnalytics → Googleアナリティクスとの連携

現在のスマフォ向けだとFacebookなどの連動も必須に。その辺りへ別途1人アサインする必要が出る事も。それを解消出来るがAsset Store。

Twitter連動などは沢山リリースされている。

サポートの厚さもアセットを評価する基準。

▼コミュニティの有効活用
・Unityの公式フォーラムには有益な情報が多数ある
→Unity自体の昨日の質疑応答はもちろん、Unityの最新Verやアセットストアの商品に関する評価等、いろいろ転がっている

・英語無理ッスって人に朗報!
Facebookのグループ「Unityユーザー助け合い所」を活用しよう!
→日本人の開発者が集まって主にUnityに関する情報のやり取りをしている。アクティブな方が多く、レスポンスも良い
"本当に助かってます"

ハマるポイントは大抵みんな同じ
先に地雷を踏んでくれた先人の知恵をありがたく頂戴しましょう

Unityを使用しての初めてのコンテンツ制作

  • 世界(3Dマップ)を自動的に生成する
  • ランダムマップ生成
  • 自動生成された世界を旅する
  • 物理エンジンを活用したギミック

テラインの生成処理を(EditorScriptで)自作
ベースとなる地形の起伏の幅や水面の高さを設定出来るように制作
   ↓
実際に生成させてみるとゲーム的に面白い地形はランダム生成では難しいという問題が発生
   ↓
地形スタンプという手動で作成したHightMap(地形の高さ情報を持っているテクスチャ)を作成
   ↓
これにより自然にはまず出来る事のない面白い地形を作成する事に成功

ランダム生成でも十分に遊べるレベルのものが作成可能に

▼テクスチャの設定
生成したテラインは標高/角度に応じてテクスチャ自動的に適したものが貼り付けられるシステム
BaseにSubをノイズとして入れたりして不自然感を抑えた

▼オブジェクトの配置
生成するテラインのサイズの選択(1024x1024,512x512...)

作ったテラインの上に配置するオブジェクトのリスト(家+木のセット、花畑セットなど)

配置するオブジェクトは単体で扱うと見た目が微妙だった
   ↓
ある程度は集合体(群集)で配置されるように設定して解決

しかし、集合体として配置すると生成された地形によっては宙に浮くオブジェクトが出てくる
   ↓
単体に設定した当たり判定により個別に判定。接地していないオブジェクトは排除する

大きなオブジェクトの場合にも地形に対してはみ出して配置されることが有る
   ↓
こちらは単体のオブジェクトであるため排除するわけには行かないのでオブジェクトの当たり判定を利用して、地形側を再設定する事で解決

以上のシステムと全て、UnityのGUIで編集出来るように作成

ゲームの細部の調整をプランナーが行える!

ココがUnityがすごい理由!

【まとめ】
・無い機能は売っているかを確認する
インターフェイスが優秀なもの/サポートが厚いものを選ぶ

・分からなかったらすぐに質問する
→日本語の返答をご所望なら「Unityユーザー助け合い所」へGO

プログラマーに機能を実装してもらう際はUIまでお願いする(Inspectorやメニューから操作ウィンドウを呼び出すなど)
→実装コストが大きくなるが最後には絶対笑ってくれる(はず)

・ディレクター(プランナー?)もUnityを勉強する
→技術者と可能な限り対等に話せないとダメ!

【重要】
ガンホーはいつでも開発者を求めています。
興味がある方は是非ご連絡を!
http://www.gungho.co.jp/recruit/

ゲームの本質を追求し、スマートフォン市場で業界No.1を目指します!

QA

Q:AssetBundleの読み込みの高速化のコツ

  • AssetBundle細かくダウンロードさせる
  • シーンをプレハブ化し、分割
  • シーンは一つで、必要なデータのみプレハブからロード
  • データの読み込みは遅い。Resourceから読んだとしても1M、1秒以上かかる

Q:AssetBundleについての注意点

  • 3.4からキャッシュしてくれるが、関数があまり充実しておらずターゲットを指定して破棄が出来ない(全て削除しか無い)
  • ケリ姫では最大200MBにまでなった
  • iPhoneの20MB制限(筆者注:当時の制限。現在は50MBまで3G回線でOK)のタメにBundleを使った
  • AssetBundleだと非同期で読み込める
  • Resourceだと非同期で読み込めない
参考資料

内部ツールについての話はこちらの記事なんかが参考になります。

4Gamer.net ― 「スマートフォンゲーム開発者向けUnityエンジンセミナー」開催,「ケリ姫クエスト」に見るUnityエンジンの活用事例
http://www.4gamer.net/games/032/G003263/20111121034/

もう一つ講演が有りましたが、ページが長くなったのでエントリーを分けます。

「COLOPL UnityNight」に行って来ました(その2)

Unityとスマートフォンアプリの最適化 - Kuma the bear準備室 栗原 秀行さん

(追記 2012/04/21)
スライドが公開されたので追記。

(追記ここまで)

発表者のご紹介
  • プログラマです
  • Objctive-C と C# は大好き
  • ゲームの移植とあはやってましたが、もともとはNativeアプリケーション屋でした
Kuma the bearとは・・・
  • オフラインで動作するアプリである事

バイスや通信速度に依存しないプラットフォームとして。
できるだけ多くの端末をカバーするため。

  • グローバルである事

App Store / Google Playのプラットフォームで展開する以上、ローカライズも積極的に。

  • ゲームとして面白いものである事

スマートフォンバイスの性能から、携帯の付加機能のゲームでなく、ゲームプラットフォームそのものとして考える。

Kuma the bearタイトルのご紹介

(筆者注:ちなみにこれらは全てUnity製)

Kuma the bear新タイトル「むしアミ!」

コロプラスマートフォン向けゲームアプリ『むしアミ!』を提供開始 〜家を侵略する「むし」を退治しろ!ディフェンス系シューティングゲーム登場! | 最新情報一覧 | 株式会社コロプラ位置ゲーで毎日の移動を楽しく】
http://colopl.co.jp/news/pressrelease/2012040901.php

Kuma the bearタイトルのメンバー
  • 基本はスモールチーム(3-4人)
  • プロジェクト初動は、
    • エンジニアがプロトタイピング
    • ディレクターとデザイナーが企画を固める

意思決定は早く!

  • プロジェクト終盤は皆でゲームバランスの調整
  • みんなUnityを使っている
  • メンバの特性を活かす

メンバの特性

  • iOSネイティブ周りに強いiTunes Connect
  • 3Dに強いコンシューマあがり、GLとか分かってる
  • Androidネイティブ周りに強い
  • Unityそのものに超詳しい、AssetStoreオタク
  • Unity EditorScriptでツール作り
  • チームメンバーのUnityに関するナレッジはフラットに!
ところでプログラマー内では派閥があります。
  • Unityは「早い」派 → 4人
  • Unityは「遅い」派 → 3人
  • EzGUI派 → 5人
  • ex2D派 → 2人
作る上での基本構成

基本は1シーン

  • 直ぐに始められるゲームを目指すために、必ずワンシーンにする
  • シーンロードは避けるように務める
  • そのために Resources.Load/UnloadUseAsset を使ってメモリロードはフレキシブルに

プロジェクト毎にツールを作成

  • プロジェクトに応じたツールは EditorScript・Shell などで作成する
  • ゲームパラメータの調整には必須

EzGUIは使っています

  • 悪名高いライブラリですが、パフォーマンス改善・省サイズには効きます
  • 上手く使えばMVCモデルにできてスッキリ

ひとつのバイナリで多言語に対応

  • EzGUIの機能を使って、ワンバイナリで多言語対応を実装

Nativeのソースは流用しまくる

基本のターゲットプラットフォーム

参考までに、リファレンス機
Android
Galaxy S 2010年10月発売

iPhone
iPhone 3GS 2009年6月

リズムコイン 〜ここでハマった〜

問題 その1.全体的に遅い、もっさりしている
→Profilerで見ると、CPU UsageがほとんどPhysics関係

疑いその1.Mesh Colliderの頂点数が多いんじゃない?

Primitive Collider ではどうしようもできないので、8角形のCollider用のMeshを別途作成
→結果、ほんの少しだけ軽くなったけど、基本は変わらない!

疑いその2.そもそもコインが重くて場に残り過ぎなのが問題では?
→コインの Physics Material の摩擦係数を軽くして、土台から流れやすくする事で、結果的に衝突回数を減らせて、Physicsの抱える問題を解決!
   ↓
これが正解だったけど、ゲームバランスを再調整する必要が発生

パフォーマンス調整でゲームバランスへの影響をする事は多いので段階的にパフォーマンスチェックもすべし!

問題 その2.フィーバーモード突入時に一部Android端末で落ちる
→クマの後ろで出している ReanderTexture が原因じゃないか?

どうやらテクスチャの初期化で落ちるのは GalaxyS で再現性が取れた
→動的にスクリーンのMaterialに SetTexture をしていたのが問題

・初期化のタイミングで RenderTexture を割り当てて、内部的に切り替える様にした

RenderTexture の使用そのものを控えるべきですが、その他 IS03 など一度に複数の RenaderTexture が使えない端末もありました。GPUに依存する所が大きいです。

わっさーゾンビ! 〜ここでハマった〜

問題 その1.ここでも全体的に遅い、もっさりしている
→ Skinned Mesh Renderer を使っているし、 Draw Call 数はゾンビの数だけ発生。あと、やはりPhysicsが重い。

→ボーン入りのキャラクターアニメーションを使っている都合上、 SkinnedMeshRenderer を切ることは不可能
→キャラクターはRigidBody同士の衝突となっているが、既にプリミティブの Collider となっている
→やや乱暴だが、Time設定の FixedDeltaTime を調整する事で物理エンジンの演算回数を減らす事で対応。その他、アプリケーションのフレームレート上限を30に指定。描画コスト減

Unity Script Reference – Time.fixedDeltaTime
http://unity3d.com/support/documentation/ScriptReference/Time-fixedDeltaTime.html

アクション性・物理特性がゲーム性に影響しないタイトルにのみ使用可能

問題 その2.実時間ベースでのゲームバランス調整は正直きつい
→ツールやシミュレーションベースの方法を使ってテスト
→Time.timeScale での設定でx倍速モードでテスト出来るように構成しておく
→シミュレータ上からゲームの進行ログをConsoleだけなく、CSVではける様にしておく。経過時間とイベント発生をグラフ化して、ゲーム内の進行状況に偏りが出ないようにする


問題 その3.iOS上でプチフリが発生(iPad/iPhone 3GS/iPhone 4)
→データ保存のホーリング中に発生

→ゲームの特性上、PlayerPrefsが肥大化、またゲームの特性上、更新頻度が上がってしまった事が原因

→PlayerPrefsの保存は必ず処理が一時停止するため、まずは保存の項目の省サイズ化
PlayerPrefsは非同期で無い事に注意

→ OnApplicationPause と OnApplicationQuit できちんとセーブしてあげれば、問題無し

ポーリングでデータ保存すると、壊す可能性も否定出来ないため要注意!

むしアミ! 〜ここでハマった〜

問題 その1.ここでも全体的に遅い、もっさりしている
→Skinned Mesh Renderer 使っているし DrawCall 数はむしの数だけ発生。あと、やはりPhysicsが重い
→Physicsは衝突はさせていませんが、Triggerには使ったりしています
 →Physicsの計算を端折ったり、FPSを落としたりできない!
→やられポイント取得などのエフェクトの拡大、縮小などをモデルとアニメーションが行われていたため、そこでの DrawCall をバッチングさせるために、テクスチャのOffsetアニメーションなどで実装。演出もEzGUIで実装
 →Draw Callのバッチングが効くケースと効かないケースをしっかりと把握しておく事
→全体的に敵の流れが良くなるように、ゲームのバランスを調整

→結果として真っ向勝負しないようにして、パフォーマンスを改善


問題 その2.全ステージ300ステージ
→Inspector上からの編集は正直難しい。CSVが必要でやる事に決めた
→Inspector上からの調整は誤入力が起きそうで正直怖い
→Export/ImportスクリプトをEditorスクリプトで調整
Excelでグラフ化しながら大雑把に調整
→300ステージでのパラメータ入力にあたり、難易度にゆらぎ・誤入力が出ないように、Editorスクリプト上でバリエーションを実装
バリデーションでエラーが出たらコンソールに出力

Inspectorでの配列操作は50くらいまでが上限かと、、
それ以上のパラメータはCSVとの連携が可視化の意味でオススメ!

EzGUI Localize Tips! その1
  • フォントスプライトシートの出力はMacなら BMGlyph か GlyphDesigner で
  • 両方ともEzGUI用のExport設定有り
  • 文字の装飾はGlyphDesignerが綺麗に出せるので、こちらを推奨します!
EzGUI Localize Tips! その2

GUIのスプライトシートは無圧縮16bit画像つき、メモリの圧迫サイズが大きいのでシステム言語環境に応じて、 Resources.Load でMaterialのMainTextreを変更。全言語で共通のUIはそのまま共有。

【コード例】

		Material LocalizeMaterial;
		if (Application.systemLanguage != SystemLanguage.Japanese) {
			Texture2D t = (Texture2D)Resources.Load("LocalizeResource/GUILocalizedEnMaterial", typeof(Texture2D));
			LocalizeMaterial.mainTexture = t;
		} else {
			Texture2D t = (Texture2D)Resources.Load("LocalizeResource/GUILocalizedJpMaterial", typeof(Texture2D));
			LocalizeMaterial.mainTexture = t;
		}
Android メモリ小技

Androidの実行メモリの使用量につき、OSによりActivityが終了させらる事が有ります。
メモリの使用量は、AdmobなどNativeまわりも考慮してUnity単体で100MB以下におさえる必要が有ります。

端末のタスクマネージャーに表示されている数字については、端末毎に異なった数字が返ってくるので当てになりません(Galaxy S2とか)

以下のコマンドで確認しましょう

adb shell top | grep package name

adbを使えば、正しいメモリ使用量が取得できますので、adbを使って実際のメモリの使用量として参考にして下さい。

プロジェクトの序盤ではUnityから直接APKを作っていて問題ありませんが、後半では、Native側の連携が重要となり、なおかつ実機テストが必要となります。

いちいちEclipseを通してのパッケージングは面倒臭いので、UnityBuild後に、Antでコマンドビルドするようにしました。

UNITY_PROJECT=/Documents/unity/title/
ECLIPSE_PROJECT=/Documents/Eclipse/title/

cp -r $(UNITY_PROJECT)/Temp/StageArea/assets $(ECLIPSE_PROJECT)
ant clean
ant release
date

InAppBillingのテストなど署名付きビルドをする場合には署名のパスフレーズも Build.properties に書いておけば入力しないで済むので超便利!

まとめ

1.パフォーマンスがらみは正面から勝負するよりも分析。またSCMで必ず遡れるゆ鬼して原因の差分を比べる
Profiler/Instruments/OpenGL ES Perfomance Detective/adbを駆使

2.特定の問題の出やすい端末を把握しておく事が必要
IS03/Arrows X/Infobar/Galaxy/iPhone 3GS ... more

3.UnityのEditorScriptはエクスポート・インポートだけでなく、バリデーションにも使える。
Excelとの連携にも便利になるので、プロジェクト毎でも起こす価値がある。
SerializeしてInspectorでの調整はべんりだけど、数の多い配列はCSVも考慮して。

4.ゲームとしての面白みにこだわるための近道は常に確保。AssetStoreは眺めるだけでも楽しいもんです。

5.ツールを作るのはプログラマ的に、超楽しい。

正しいパスワードを入力しているにも関わらずGmailやExchangeで「不正なパスワード」とアラート表示がされる時の対処方法

最近、iPhone 4Sを水没させてしまって、新しいiPhone 4Sに交換して来ました(もちろん、有料。手痛い出費(>_<;) 皆さん、気を付けましょう)。

今回の様に同一機種間での変更だからかなど原因はイマイチ不明ですがiCloudからデータを復元した所、以下の様な症状が発生しました。

  • Exchangeを使ったカレンダーなどの同期を行った時に「不正なパスワード」とアラート表示がされる
  • Gmailのアドレスにメールチェックを行った時に「不正なパスワード」とアラート表示がされる

パスワードの入力をミスしたかな?と思い何度も入力しても改善されません。また、iPhone上のSafariGmailを開いてログインしてみるとそちらは問題なくログイン出来ました。

「うーむ、パスワードは正しいのは確認出来たし原因は何だろう?」と、かなり理由を突き止めるの苦労しましたが最終的にはこちらのサイトに書かれている方法で解決出来ました。

iPhoneのカレンダーとGoogleカレンダーの同期で悩む。 - Awayannのブログ
http://d.hatena.ne.jp/Awayann/20100210/1265771271

具体的には https://www.google.com/accounts/UnlockCaptcha へアクセスし、「次へ」のボタンを押すと改善されました。自分の場合には CAPTCHA (※)は表示されませんでしたが元記事を読むと CAPTCHA を解除と書かれているのでそちらの入力が必要な場合も有るのかも知れません。
CAPTCHA とは、歪んでたり、ゴミのドットが散らされた文字や数字を読み取って入力欄に記述するちゃんと人間の入力で有る事をチェックする為の画像(システム)。