Unity×HTMLで作るiPhone オンラインゲーム開発事例
•
99 likes•36,334 views
第３回 渋谷Unity技術勉強会-Unity×Html/Unity 2D-(http://atnd.org/events/24710)での発表内容をUP用に編集したものです。 UnityとHTMLのハイブリッドアプリを開発した時のTipsとリリースまでのプロセスの話です。
Unity×HTMLで作るiPhone オンラインゲーム開発事例
- 1. Unity×HTMLで作る iPhoneオンラインゲーム 開発事例 株式会社 Aiming リードソフトウェアエンジニア 細田幸治 2012/03/29 @http://atnd.org/events/24710
- 2. こんばんは
- 4. この発表のターゲット ● ある程度Unity触ってる人 ● オンラインゲームの作り方に興味ある人 ● iPhoneアプリを出そうとしてる人 ● 開発の開始からリリースまでのプロセスに興味 がある人 時間がないので 細かい実装の話は次の機会に
- 5. 話すこと ● 作ったゲームについて ● HTML連携とかの技術的な話 ● 開発中の問題と改善 ● 社内テストとブラッシュアップ ● AppleStoreリリースあれこれ
- 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を使ったスタンドアローン開発 ○ サーバーの実装スケジュールとの依存が少ない ○ 異常系の確認も手軽にできる
- 23. 開発初期の問題と改善 最初の1ヶ月ほとんど進捗なし ● 頻繁な衝突、参照外れ ● EzGUIがEasyじゃない ● C#なれてない ● 仕様が最初にそろってない →見積もりぜんぜんあわない
- 24. どうやって改善？ ● 頻繁な衝突、参照外れ ↓ ● ワークフローを工夫して衝突回避 ● コードレビュー＆CIで早期発見
- 25. どうやって改善？ ● EzGUIがEasyじゃない ↓ ● EzGUIなれてきた ● UIデザインできる人に入ってもらった
- 26. どうやって改善？ ● C#なれてない ↓ ● C#達人にプロジェクトに入ってもらった ○ (++C++;// 未確認飛行 Cの中の人)
- 27. どうやって改善？ ● 仕様が最初にそろってない ↓ ● アジャイル開発プロセスを導入 ○ バーンダウンチャート ○ スプリントでの振り返り →リスク早期発見
- 28. 改善の結果 →見積もりあってきた
- 29. そうやって改善しながら
- 30. 開発を続け
- 32. 社内テストとブラッシュアップ ● 数十人規模で同時にプレイ ○ 倍速モードでテスト時間短縮 ● テストプレイヤーには別プロジェクトやバックオ フィスの人もいた ○ ガチプレイしてもらえた ● バグと要望の収集にはSkypeとグーグルスプ レッドシートを使用 ○ 報告を集めやすかった ↓ 優先度をつけて以降のマイルストーンに反映
- 33. そしてリリースへ
- 35. 審査について リリースまでにリジェクト3回されました ● リジェクト理由 a. キャッシュファイルの保存場所が悪くてアウト！ ■ 永続化用と一時用があるので気をつける b. 審査専用アカウントを使ってくれなくて審査用サーバー にログインできなくてアウト！ ■ アカウントで審査版かどうかを判断しないように c. 審査中にメンテしたら問題おきてログインできなくなった ■ In Reviewになったら予定しているメンテがあってもリ スケする
- 36. 審査についてその２ どのくらいで通るの？ ● だいたい審査出してから約5営業日で審査開始 (In Review)、だいたいその数時間後に結果出る ● 場合によってはIn Reviewのまま1日過ぎることも あるので油断しない どういう判断基準？ ● 審査のたびに判断基準がまちまち ● 深く見られる時もあれば一瞬でOKでる時も
- 37. まとめると
- 38. まとめ ● HTMLのハイブリッドいいよ ● C#便利に使おう ● 通信部分は自動生成とMockで快適開発 ● 設計はしっかり、メンテナンスコストを下げよう ● アジャイルいいね
- 39. まとめ ● Unityの癖を知り乗りこなそう ○ Unity助け合い所助かってます ● なるべく早くテストプレイできるようにしよう ○ ブラッシュアップのサイクルは多いほどいい ● Appleでのリリースは地雷が多いので早く踏む ○ オンラインゲームのリリースはいろいろ大変
- 41. おわり