unity×htmlで作るiphone オンラインゲーム開発事例
DESCRIPTION
第３回 渋谷Unity技術勉強会-Unity×Html/Unity 2D-(http://atnd.org/events/24710)での発表内容をUP用に編集したものです。UnityとHTMLのハイブリッドアプリを開発した時のTipsとリリースまでのプロセスの話です。TRANSCRIPT
Unity×HTMLで作る
iPhoneオンラインゲーム
開発事例
株式会社 Aimingリードソフトウェアエンジニア
細田幸治2012/03/29 @http://atnd.org/events/24710
こんばんは
細田幸治といいます。
http://www.facebook.com/kouji.hosoda MMORPGのサーバーを書いたり、
通信ライブラリを書いたり、ブラウザゲームを作ったり、スマホのオンラインゲームを作ったりしています。
この発表のターゲット
● ある程度Unity触ってる人● オンラインゲームの作り方に興味ある人● iPhoneアプリを出そうとしてる人● 開発の開始からリリースまでのプロセスに興味
がある人 時間がないので細かい実装の話は次の機会に
話すこと
● 作ったゲームについて
● HTML連携とかの技術的な話
● 開発中の問題と改善
● 社内テストとブラッシュアップ
● AppleStoreリリースあれこれ
どんなゲーム？
カードを強化して戦うストラテジーRPG あれ、似たようなゲームみたことある！→ブラウザ三国志、戦国IXA、etc.
実はプロダクトオーナーはブラ三を作ったメンバー→先行タイトルを研究し、
ライトなターゲットに向けて仕様を作成
規模感
● クライアント開発3-8人
● サーバー開発約5人
● 企画3人
● デザイン3人
の約20人でリリースまで8ヶ月半 現在はリリースされたので運営とマーケティングも加わりもっと増えてる
何でUnity選んだの？
● iPhoneとAndroidの両方でリリースしたいから
● 当時マーケットが大きかったiPhone版から開発
● 現在Android版も開発中
Unity×HTMLな理由
画面数が多く、Unityだけだと工数きつい ● 内政、マップ、レポート、メール、ショップ、合成、
カード・・・・・・など４０画面以上！ ● UnityでUI作るの大変！
HTMLを使うメリット
要件ごとに得意なほうで分担できる● Unity: 動きが多い＆レスポンス早くしたい画面
● HTML: リスト系など静的な画面
HTML製
HTMLを使うメリットその2
リリース後のアップデートがしやすい● 審査なしでアップデート可能
○ キャンペーンページなどの自由が利きやすい
○ 仕様変更が多い画面はまずはHTMLで
■ 仕様が固まったらUnity化
HTMLを使うメリットその3
自由文字入力ができる● iPhone上でフォントに使えるテクスチャサイズに
制限がある○ 1つのフォントごとに2048*2048ピクセルのテクスチャに
収める必要がある
● HTMLだと上記のような制限がない○ チャットなど自由入力出来る画面はHTMLで作成
HTMLを使うデメリット
● ローディングが長い
● 反応が遅い
○ どうしてもユーザー体験が落ちる
● メモリーを喰う
○ ゲーム内メールなどのリストを追加読み込みし続けると
突然落ちたりする
● エディターで確認できないところがある○ 後で説明するUnityとHTMLとの連携部分
どんな作りになっているかというと
技術的な話
● 基本設計
● HTML連携
● サーバーとの通信
基本設計
● MVCっぽく依存を分離
○ Model,View,Controllerにクラスを分けて役割を明確化
■ ロジックはModelで管理。Unityに依存しないように
■ Modelの変更はイベントでViewに通知、反映
■ Viewにロジックが必要な場合はViewModelをつくる
■ 複数のView間でデータを取り回す場合もViewModel
■ ControllerはViewの出し入れModelの呼び出しなど
● ソートや検索などのデータ処理はLINQを活用
○ クライアントで処理するのでサーバーの負担が減る
HTML連携
● Native Pluginでインゲームブラウザを実装
● Unity、HTML間で情報を相互に通信
○ shouldStartLoadWithRequestを使ってパース
■ クエリストリング(?aho=hoge&foo=barの部分)をクリッ
クや画面ロードのタイミングでパース
○ UnitySendMessageでパースしたデータを送信
● ブラウザが操作不能になる問題が出た
○ Unity側が自動生成するAppCotroller.mmの描画フラグ
を変更(@Unity3.4)
■ #define USE_DISPLAY_LINK_IF_AVAILABLE 0
サーバーとの通信
● JSON-RPC形式
● 通信実装コードの自動生成
○ ppcuni/rpcoderを使った
■ githubに上がってる自社制ライブラリ
■ https://github.com/ppcuni/rpcoder■ アプリケーション層で通信実装を気にする必要はな
いようになってる
● Mockを使ったスタンドアローン開発
○ サーバーの実装スケジュールとの依存が少ない
○ 異常系の確認も手軽にできる
実際の開発で起きた問題と改善ついて
開発初期の問題と改善
最初の1ヶ月ほとんど進捗なし● 頻繁な衝突、参照外れ
● EzGUIがEasyじゃない
● C#なれてない
● 仕様が最初にそろってない
→見積もりぜんぜんあわない
どうやって改善？
● 頻繁な衝突、参照外れ
↓ ● ワークフローを工夫して衝突回避● コードレビュー＆CIで早期発見
どうやって改善？
● EzGUIがEasyじゃない
↓ ● EzGUIなれてきた
● UIデザインできる人に入ってもらった
どうやって改善？
● C#なれてない
↓ ● C#達人にプロジェクトに入ってもらった
○ (++C++;// 未確認飛行 Cの中の人)
どうやって改善？
● 仕様が最初にそろってない
↓ ● アジャイル開発プロセスを導入
○ バーンダウンチャート
○ スプリントでの振り返り
→リスク早期発見
改善の結果
→見積もりあってきた
そうやって改善しながら
開発を続け
社内テストとブラッシュアップ
開発を開始して4ヶ月（中間地点）で各パートの実装がそろい一通り遊べるように。 ↓ 社員全員を対象にした社内テストを開始
社内テストとブラッシュアップ
● 数十人規模で同時にプレイ
○ 倍速モードでテスト時間短縮
● テストプレイヤーには別プロジェクトやバックオ
フィスの人もいた○ ガチプレイしてもらえた
● バグと要望の収集にはSkypeとグーグルスプ
レッドシートを使用○ 報告を集めやすかった
↓優先度をつけて以降のマイルストーンに反映
そしてリリースへ
AppleStoreへのリリースあれこれ
初めての iPhone アプリリリースだった ノウハウがなかったので試行錯誤
審査について
リリースまでにリジェクト3回されました● リジェクト理由
a. キャッシュファイルの保存場所が悪くてアウト！
■ 永続化用と一時用があるので気をつける
b. 審査専用アカウントを使ってくれなくて審査用サーバー
にログインできなくてアウト！
■ アカウントで審査版かどうかを判断しないように
c. 審査中にメンテしたら問題おきてログインできなくなった
■ In Reviewになったら予定しているメンテがあってもリ
スケする
審査についてその２
どのくらいで通るの？● だいたい審査出してから約5営業日で審査開始
(In Review)、だいたいその数時間後に結果出る● 場合によってはIn Reviewのまま1日過ぎることも
あるので油断しない どういう判断基準？● 審査のたびに判断基準がまちまち
● 深く見られる時もあれば一瞬でOKでる時も
まとめると
まとめ
● HTMLのハイブリッドいいよ
● C#便利に使おう
● 通信部分は自動生成とMockで快適開発
● 設計はしっかり、メンテナンスコストを下げよう
● アジャイルいいね
まとめ
● Unityの癖を知り乗りこなそう
○ Unity助け合い所助かってます
● なるべく早くテストプレイできるようにしよう
○ ブラッシュアップのサイクルは多いほどいい
● Appleでのリリースは地雷が多いので早く踏む
○ オンラインゲームのリリースはいろいろ大変
そして
とにかく楽しむ どんなトラブルも懸念事項も前向きに取り組めば楽しいクエストになります
おわり