第３回 渋谷Unity技術勉強会-Unity×Html/Unity 2D-(http://atnd.org/events/24710)での発表内容をUP用に編集したものです。 UnityとHTMLのハイブリッドアプリを開発した時のTipsとリリースまでのプロセスの話です。

1. Unity×HTMLで作る
iPhoneオンラインゲーム
開発事例
株式会社 Aiming
リードソフトウェアエンジニア
細田幸治
2012/03/29 @http://atnd.org/events/24710

2. こんばんは

3. 細田幸治といいます。
http://www.facebook.com/kouji.hosoda
MMORPGのサーバーを書いたり、
通信ライブラリを書いたり、
ブラウザゲームを作ったり、
スマホのオンラインゲームを作ったりしています。

4. この発表のターゲット
● ある程度Unity触ってる人
● オンラインゲームの作り方に興味ある人
● iPhoneアプリを出そうとしてる人
● 開発の開始からリリースまでのプロセスに興味
がある人
時間がないので
細かい実装の話は次の機会に

5. 話すこと
● 作ったゲームについて
● HTML連携とかの技術的な話
● 開発中の問題と改善
● 社内テストとブラッシュアップ
● AppleStoreリリースあれこれ

6. 作ったゲームについて
http://lordofknights.jp/

9. どんなゲーム？
カードを強化して戦うストラテジーRPG
あれ、似たようなゲームみたことある！
→ブラウザ三国志、戦国IXA、etc.
実は
プロダクトオーナーはブラ三を作ったメンバー
→先行タイトルを研究し、
ライトなターゲットに向けて仕様を作成

10. 規模感
● クライアント開発3-8人
● サーバー開発約5人
● 企画3人
● デザイン3人
の約20人で
リリースまで8ヶ月半
現在はリリースされたので
運営とマーケティングも加わりもっと増えてる

11. 何でUnity選んだの？
● iPhoneとAndroidの両方でリリースしたいから
● 当時マーケットが大きかったiPhone版から開発
● 現在Android版も開発中

12. Unity×HTMLな理由
画面数が多く、Unityだけだと工数きつい
● 内政、マップ、レポート、メール、ショップ、合成、
カード・・・・・・など４０画面以上！
● UnityでUI作るの大変！

13. HTMLを使うメリット
要件ごとに得意なほうで分担できる
● Unity: 動きが多い＆レスポンス早くしたい画面
● HTML: リスト系など静的な画面
HTML製

14. HTMLを使うメリットその2
リリース後のアップデートがしやすい
● 審査なしでアップデート可能
○ キャンペーンページなどの自由が利きやすい
○ 仕様変更が多い画面はまずはHTMLで
■ 仕様が固まったらUnity化

15. HTMLを使うメリットその3
自由文字入力ができる
● iPhone上でフォントに使えるテクスチャサイズに
制限がある
○ 1つのフォントごとに2048*2048ピクセルのテクスチャに
収める必要がある
● HTMLだと上記のような制限がない
○ チャットなど自由入力出来る画面はHTMLで作成

16. HTMLを使うデメリット
● ローディングが長い
● 反応が遅い
○ どうしてもユーザー体験が落ちる
● メモリーを喰う
○ ゲーム内メールなどのリストを追加読み込みし続けると
突然落ちたりする
● エディターで確認できないところがある
○ 後で説明するUnityとHTMLとの連携部分

17. どんな作りになっているかというと

18. 技術的な話
● 基本設計
● HTML連携
● サーバーとの通信

19. 基本設計
● MVCっぽく依存を分離
○ Model,View,Controllerにクラスを分けて役割を明確化
■ ロジックはModelで管理。Unityに依存しないように
■ Modelの変更はイベントでViewに通知、反映
■ Viewにロジックが必要な場合はViewModelをつくる
■ 複数のView間でデータを取り回す場合もViewModel
■ ControllerはViewの出し入れModelの呼び出しなど
● ソートや検索などのデータ処理はLINQを活用
○ クライアントで処理するのでサーバーの負担が減る

20. HTML連携
● Native Pluginでインゲームブラウザを実装
● Unity、HTML間で情報を相互に通信
○ shouldStartLoadWithRequestを使ってパース
■ クエリストリング(?aho=hoge&foo=barの部分)をクリッ
クや画面ロードのタイミングでパース
○ UnitySendMessageでパースしたデータを送信
● ブラウザが操作不能になる問題が出た
○ Unity側が自動生成するAppCotroller.mmの描画フラグ
を変更(@Unity3.4)
■ #define USE_DISPLAY_LINK_IF_AVAILABLE 0

21. サーバーとの通信
● JSON-RPC形式
● 通信実装コードの自動生成
○ ppcuni/rpcoderを使った
■ githubに上がってる自社制ライブラリ
■ https://github.com/ppcuni/rpcoder
■ アプリケーション層で通信実装を気にする必要はな
いようになってる
● Mockを使ったスタンドアローン開発
○ サーバーの実装スケジュールとの依存が少ない
○ 異常系の確認も手軽にできる

22. 実際の開発で起きた問題と改善ついて

23. 開発初期の問題と改善
最初の1ヶ月ほとんど進捗なし
● 頻繁な衝突、参照外れ
● EzGUIがEasyじゃない
● C#なれてない
● 仕様が最初にそろってない
→見積もりぜんぜんあわない

24. どうやって改善？
● 頻繁な衝突、参照外れ
↓
● ワークフローを工夫して衝突回避
● コードレビュー＆CIで早期発見

25. どうやって改善？
● EzGUIがEasyじゃない
↓
● EzGUIなれてきた
● UIデザインできる人に入ってもらった

26. どうやって改善？
● C#なれてない
↓
● C#達人にプロジェクトに入ってもらった
○ (++C++;// 未確認飛行 Cの中の人)

27. どうやって改善？
● 仕様が最初にそろってない
↓
● アジャイル開発プロセスを導入
○ バーンダウンチャート
○ スプリントでの振り返り
→リスク早期発見

28. 改善の結果
→見積もりあってきた

29. そうやって改善しながら

30. 開発を続け

31. 社内テストとブラッシュアップ
開発を開始して4ヶ月（中間地点）で各パートの実
装がそろい一通り遊べるように。
↓
社員全員を対象にした社内テストを開始

32. 社内テストとブラッシュアップ
● 数十人規模で同時にプレイ
○ 倍速モードでテスト時間短縮
● テストプレイヤーには別プロジェクトやバックオ
フィスの人もいた
○ ガチプレイしてもらえた
● バグと要望の収集にはSkypeとグーグルスプ
レッドシートを使用
○ 報告を集めやすかった
↓
優先度をつけて以降のマイルストーンに反映

33. そしてリリースへ

34. AppleStoreへのリリースあれこれ
初めての iPhone アプリリリースだった
ノウハウがなかったので試行錯誤

35. 審査について
リリースまでにリジェクト3回されました
● リジェクト理由
a. キャッシュファイルの保存場所が悪くてアウト！
■ 永続化用と一時用があるので気をつける
b. 審査専用アカウントを使ってくれなくて審査用サーバー
にログインできなくてアウト！
■ アカウントで審査版かどうかを判断しないように
c. 審査中にメンテしたら問題おきてログインできなくなった
■ In Reviewになったら予定しているメンテがあってもリ
スケする

36. 審査についてその２
どのくらいで通るの？
● だいたい審査出してから約5営業日で審査開始
(In Review)、だいたいその数時間後に結果出る
● 場合によってはIn Reviewのまま1日過ぎることも
あるので油断しない
どういう判断基準？
● 審査のたびに判断基準がまちまち
● 深く見られる時もあれば一瞬でOKでる時も

37. まとめると

38. まとめ
● HTMLのハイブリッドいいよ
● C#便利に使おう
● 通信部分は自動生成とMockで快適開発
● 設計はしっかり、メンテナンスコストを下げよう
● アジャイルいいね

39. まとめ
● Unityの癖を知り乗りこなそう
○ Unity助け合い所助かってます
● なるべく早くテストプレイできるようにしよう
○ ブラッシュアップのサイクルは多いほどいい
● Appleでのリリースは地雷が多いので早く踏む
○ オンラインゲームのリリースはいろいろ大変

40. そして
とにかく楽しむ
どんなトラブルも懸念事項も
前向きに取り組めば楽しいクエストになります

41. おわり