Unityのオンラインゲームをhtmlに移植してわかったこと
- 1. Unity のオンラインゲームを HTML に移植して わかったこと 株式会社 Aiming リードソフトウェアエンジニア 細田幸治 2012/11/06
- 2. こんばんは！
- 4. 話の前提として
- 6. ロードオブナイツとは ● 多人数ストラテジー ○ マップ：ブラウザ三国志 ○ 内政：Kingdoms of Camelot ＋ ● カードバトル ○ ターン制オートバトル ■ ドラクエモンスターズ風
- 10. 私は
- 12. 目次 ● Unity 版の開発と移植の経緯 ○ Unity 版の開発経緯 ○ HTML 版の移植経緯 ● 移植のポリシーと実際 ○ 移植チーム体制 ○ 移植ポリシー ○ 移植の実際 ■ 再利用性 ■ 良かった点・ネックになった点 ● 開発のこれから（おまけ）
- 16. Unity 版の開発経緯 Unity 版の開発経緯 ● 2011 年夏 ○ スマホでリッチなゲームが少なかった ○ そもそもゲーム少なかった ゲームでアプリ内課金で売り上げランキング上位 だったのは Kingdom Conquest ぐらい
- 17. Unity 版の開発経緯 Unity 版の開発経緯 ● 2011 年夏 ○ スマホでリッチなゲームが少なかった ○ そもそもゲーム少なかった ● iPhone と Android でリッチなゲームをすばやく 出せれば勝てる可能性が高いと判断 ○ 当時使えそうなフレームワークを検討した結果 Unity に
- 18. Unity 版の開発経緯 Unity 版の開発経緯 ● 2011 年夏 ○ スマホでリッチなゲームが少なかった ○ そもそもゲーム少なかった ● iPhone と Android でリッチなゲームをすばやく 出せれば勝てる可能性が高いと判断 ○ 当時使えそうなフレームワークを検討した結果 Unity に ● 工数の都合や当時の Unity での制約上、部分 的に HTML で作成
- 19. Unity 版の開発経緯 Unity 版の開発経緯 ● 2011 年夏 ○ スマホでリッチなゲームが少なかった ○ そもそもゲーム少なかった ● iPhone と Android でリッチなゲームをすばやく 出せれば勝てる可能性が高いと判断 ○ 当時使えそうなフレームワークを検討した結果 Unity に ● 工数の都合や当時の Unity での制約上、部分 的に HTML で作成 ● オンラインゲームなので追加開発は当然 ○ メンテナンス性も重視
- 21. Unity 版の開発経緯 画面の分担 ● 動きのある画面、レスポンスを良くしたい画面 ○ Unity で ● 自由入力、リスト表示系、キャンペーンなど更新 頻度高い画面 ○ HTML で
- 22. Unity 版の開発経緯 画面の分担：メッセージ連携 ● HTML 画面と Unity 画面とのメッセージ連携 ○ 独自形式でメッセージ送受信できるようにしてた ○ Unity のネイティブプラグインを書いて実装
- 23. Unity 版の開発経緯 画面の分担：メッセージ連携 ● HTML 画面と Unity 画面とのメッセージ連携 ○ 独自形式でメッセージ送受信できるようにしてた ○ Unity のネイティブプラグインを書いて実装 例：HTML のリンクを押したら 任意の Unity 画面に遷移 遷移
- 24. Unity 版の開発経緯 画面の分担：メッセージ連携 ● HTML 画面と Unity 画面とのメッセージ連携 ○ 独自形式でメッセージ送受信できるようにしてた ○ Unity のネイティブプラグインを書いて実装 例：HTML のリンクを押したら 任意の Unity 画面に遷移 遷移
- 25. Unity 版の開発経緯 画面の分担：メッセージ連携 割とトリッキーな実装 後で後悔する
- 26. Unity 版の開発経緯 通信 ● Unity と PHP の通信は HTTP で JSON-RPC 形式 ● 最初から通信コードの自動生成導入 詳しくは Lord of Knightsの開発裏側みせます のスライド参照
- 27. Unity 版の開発経緯 通信 デバッグしやすい 修正コスト低い これはよかった
- 28. Unity 版の開発経緯 設計とレビュー ● 仕様レビュー ○ 企画の意図を理解し、Unity で作るか HTML で作るかを 判断 ○ 実装コストが高いものについては仕様調整できないかも 随時相談 ● コードレビュー(gerrit) ○ 全コミットがレビュー対象 ○ 通信設計、クラス設計などは必ずレビューする ○ ブラックボックス作らない
- 29. Unity 版の開発経緯 設計とレビュー ● コードレビュー(gerrit) Web 上でインライン でコメントできる
- 30. Unity 版の開発経緯 設計とレビュー メンテナンス性に貢献 これはよかった
- 32. Unity 版の開発経緯 作業分担 これまでの開発経験を元に以下の分担にした ● クライアント Unity: ○ Aiming（弊社） ● クライアント HTML: ○ infinite loop(パートナー会社)
- 33. Unity 版の開発経緯 作業分担 これまでの開発経験を元に以下の分担にした ● クライアント Unity: ○ Aiming（弊社: 東京） ● クライアント HTML: ○ infinite loop(パートナー会社: 札幌) ● サーバー & API: ○ infinite loop ● 通信設計: ○ Aiming が設計 ○ infinite loop がレビュー ■ 誰が読んでも機能を連想できる名前付けを心がけた
- 34. Unity 版の開発経緯 コミュニケーション ● やり取りは Skype チャットがメイン ● 仕様は Redmine の wiki やエクセルで ● タスクの優先度付けは Google spreadsheet ● メールはほぼ使いません
- 35. Unity 版の開発経緯 コミュニケーション ● チャットのレスは 1 日あたり数百件ぐらい ● お互い遠慮しないで発言してる ○ 信頼関係が築けているのでリモートだけどそんなに問題 ない
- 36. Unity 版の開発経緯 Unity 版の 開発ボリューム
- 37. Unity 版の開発経緯 開発ボリューム ● 開発期間 ○ 約 8 ヶ月 + 運用 4 ヶ月 ● API数 ○ 75 個 ● 画面数 ○ 100 画面以上 ● コード行数 ○ クライアント ■ C# 82022 行 ○ サーバー ■ PHP 133659 行
- 38. Unity 版の開発経緯 コード 20 万行以上！ けっこう ボリュームあります
- 39. どのような経緯で HTML 版 が作られたのか
- 40. HTML 版の移植経緯
- 41. HTML 版の移植経緯 Unity 版 軌道に乗ってきた！
- 43. HTML 版の移植経緯 そこで
- 44. HTML 版の移植経緯
- 45. HTML 版の移植経緯 移植の要件 ● mobage のスマホ、PC の両プラットフォーム同 時リリースしたい！
- 46. HTML 版の移植経緯 移植の要件 ● mobage のスマホ、PC の両プラットフォーム同 時リリースしたい！ ● アプリ版よりブラウザ版の方が間口広いのでブ ラウザで！
- 47. HTML 版の移植経緯 移植の要件 ● mobage のスマホ、PC の両プラットフォーム同 時リリースしたい！ ● アプリ版よりブラウザ版の方が間口広いのでブ ラウザで！ ● UIデザイン作り直し！ ○ スマホブラウザは縦持ちじゃないとプレイしにくい ○ PC版は画面サイズが結構違う
- 48. HTML 版の移植経緯 移植の要件 ● mobage のスマホ、PC の両プラットフォーム同 時リリースしたい！ ● アプリ版よりブラウザ版の方が間口広いのでブ ラウザで！ ● UIデザイン作り直し！ ○ スマホブラウザは縦持ちじゃないとプレイしにくい ○ PC版は画面サイズが結構違う ● 工期3ヶ月で！
- 49. HTML 版の移植経緯 移植の要件 ● mobage のスマホ、PC の両プラットフォーム同 時リリースしたい！ ● アプリ版よりブラウザ版の方が間口広いのでブ ラウザで！ ● UIデザイン作り直し！ ○ スマホブラウザは縦持ちじゃないとプレイしにくい ○ PC版は画面サイズが結構違う ● 工期3ヶ月で！ ● ゲームの仕様は変わらないよ！
- 50. HTML 版の移植経緯 つまり
- 51. HTML 版の移植経緯 強くてニューゲーム Easy Hard Very Hard
- 52. HTML 版の移植経緯 強くてニューゲーム Easy Hard Very Hard
- 53. HTML 版の移植経緯 強くてニューゲーム Easy Hard Very Hard
- 54. HTML 版の移植経緯 強くてニューゲーム Easy Hard Very Hard
- 56. 移植のポリシーと 実際
- 57. 移植チーム体制 移植チーム体制
- 58. 移植チーム体制 チーム体制 サーバー側 ● 移植チームと Unity 版チームが同じメンバー ○ メンバーの増員はやった ● Unity 版と HTML 版でワンソースで管理 ○ マルチプラットフォームごとの対応でブランチたくさん管理 するのは大変だったという経験から。
- 59. 移植チーム体制 チーム体制 クライアント側 ● 移植チームは Unity 版チームと別メンバー ○ 開発初期は Unity 版も忙しく、移植チームは別動隊 ○ 社内＋業務委託で １２ 人ぐらい ■ ロードオブナイツ経験者ほぼいない ● Unity 版と HTML 版で別ソース ○ Unity 版は C# ⇔ HTML 版は CoffeeScript ○ CoffeeScript をはじめて触る人がほとんど
- 61. 移植ポリシー 移植ポリシー
- 62. 移植ポリシー 移植ポリシー ● 使えるものは使いまわす♪ ● 優先度低い仕様は削る♪ ● 省略できる実装はやらない♪
- 63. 移植ポリシー 移植ポリシー ● Unity 版と作業分担はそのままにする ● サーバー側の追加実装は基本しない ○ クライアントは全部ブラウザ上の JavaScript で処理 ○ サーバー側とドメインも分離してデプロイフローも独立
- 64. 移植ポリシー 移植ポリシー ● Unity 版と作業分担はそのままにする ● サーバー側の追加実装は基本しない ○ クライアントは全部ブラウザ上の JavaScript で処理 ○ サーバー側とドメインも分離してデプロイフローも独立 Unity 版と HTML 版で共通の デプロイフローを使えるように
- 65. 移植の実際 移植の実際
- 67. 移植の実際 結果 ● 工期 ○ １ ヵ月近くオーバーした ○ リミットラインの 8 月中にはなんとかリリースできた ● コード量 ○ クライアントは CoffeeScript 20290 行 ○ コード量 4 分の 1 になった！ ● API ○ ４つ追加 ○ ログイン、クライアントの設定保存用API ● 画面数 ○ 微増 ○ 友達招待系の画面追加
- 68. 移植の実際 Before/After Unity 版 HTML 版 開発期間 8 ヶ月 3 ヶ月半 クライアント 8 万行 2 万行 コード量 API数 75 個 79 個 画面数 100 以上 微増
- 69. 移植の実際 Before/After ● 工数は Unity 版の半分ぐらい！ ○ 予定よりかかってる ● コード ○ CoffeeScript 書きやすい ○ 仕様や実装をシェイプアップできた
- 70. 移植の実際 再利用性
- 71. 移植の実際 再利用と作り直し クライアント Unity すべて作り直し クライアント HTML 実装は再利用 テンプレート･CSSは 作り直し サーバー & API ほぼ再利用 認証・課金･友達招待 作り直し & 追加実装 等 Platform 対応
- 74. 移植の実際 振り返り
- 75. 良かった点 ネックになった点
- 76. 良かった点 ネックになった点 設計面 ● 良かった点 ○ API は超再利用性高い ○ 通信設計が仕様書になる ● ネックになった点 ○ Unity 版の HTML 画面がネックに
- 77. 良かった点 ネックになった点 良：API は超再利用性高い ● Unity 版のサーバーがほぼそのまま使えた ● JSON-RPC ○ ブラウザの開発者ツール使えばデバッグしやすい ● 自動生成なので変更コスト低い
- 78. 良かった点 ネックになった点 良：通信設計が仕様書になる ● 可読性が高い通信の定義書 ○ それが実装仕様になる ● Unity 版でレビューしてきた成果がでた
- 79. 良かった点 ネックになった点 ネック：Unity 版の HTML 画面 ● いろいろトリッキーな実装だった ○ Unity とのメッセージ連携 ■ 独自プラグインで実装されていたので HTML 版でどう するか模索 ○ 通信内容が API 化されていない ■ HTML 版でどうワンページアプリとして実現するか模 索 HTML 版で上記が動くようになったのは残り1 ヶ月 ぐらいになってから
- 80. 良かった点 ネックになった点 チーム体制面 ● 良かった点 ○ Unity 版の HTML 画面のおかげで作業分担できた ● ネックになった点 ○ 移植チーム孤立 ○ パートナー会社とのコミュニケーション不足
- 81. 良：Unity 版の HTML 画面の 良かった点 ネックになった点 おかげで作業分担できた ● サーバー側は API が再利用できた分、HTML 画面の実装に回れた ● 並列作業が出来たので工期短縮に貢献 分担できてなかったらスケジュールやばかった
- 82. 良かった点 ネックになった点 ネック：移植チーム孤立 ● 初期は Unity 版が忙しくて移植チームが孤立し てた ● 新規メンバーはロードオブナイツあまり知らな かった ○ スケジュールがタイトで使用理解不足のまま進んだ ○ 異常系などが漏れてバグバグになった ■ 急遽 Unity 版の優先度調整して Unity 版のメンバー が参加 ● Unity 版のメンバー参加後 ○ 裏仕様や実装仕様の把握が進みスピードアップ
- 83. 良かった点 ネック:パートナー会社とのコ ネックになった点 ミュニケーション不足 ● infinite loop さんとのやり取り慣れてなかった ○ プロジェクトの優先度の共有ができてなかった ■ 初動が遅れた ○ プラットフォーム対応の実装優先度付けに失敗してた ■ 何がネックになるか把握できてなかった ■ サーバー側の課金や友達招待などの実装タイミング がぎりぎりになってしまった
- 84. 以上をまとめると
- 85. 移植で注意すべき 3つのこと
- 86. 移植で注意するべき3つのこと 1. API 設計はしっかり ○ レビューを活用して誰が見ても分かる状態をつくろう！
- 87. 移植で注意するべき3つのこと 1. API 設計はしっかり ○ レビューを活用して誰が見ても分かる状態をつくろう！ 2. トリッキーな設計はなるべくしない ○ なるべくフレームワークに乗る範囲でやる！
- 88. 移植で注意するべき3つのこと 1. API 設計はしっかり ○ レビューを活用して誰が見ても分かる状態をつくろう！ 2. トリッキーな設計はなるべくしない ○ なるべくフレームワークに乗る範囲でやる！ 3. コミュニケーションはやっぱり大事 ○ 仕様や実装を把握しているメンバーも一緒にやる！ ○ パートナー会社と優先度をしっかり共有する！
- 89. どれも当たり前のこと ですが、
- 90. 基本が大事。
- 92. 質疑応答 ● ここまででなにかあれば！ ● Unity 版のコードを素直に移植しなかったのは なぜ？とか
- 93. 質疑応答 ● ここまででなにかあれば！ ● Unity 版のコードを素直に移植しなかったのは なぜ？とか ○ 初期に Unity 版メンバーがいなくて Unity 版のコードの伝 達出来てなかった ○ Unity とアーキテクチャが異なるのでそのままは使えない ところも多かった（特に View 周り） ○ Model 層は結構使えたので最初に読んでいたらもっと開 発の効率上がってたと思う ○ でも直移植でないからこそコード量を圧縮できたという面 もある
- 94. 質疑応答 ● 他になにかあれば！
- 95. 質疑応答 ● 他になにかあれば！ ● なぜ UnityWebPlayer を使わなかったのか？
- 96. 質疑応答 ● 他になにかあれば！ ● なぜ UnityWebPlayer を使わなかったのか？ ○ スマホのブラウザで動かない ○ ネイティブプラグインの再実装のコストが結構かかりそう だった ■ クライアント側のストレージ ■ Webとゲーム部分との機能連携
- 97. 開発のこれから （おまけ）
- 98. チームを1つに ● Unity 版、HTML 版の区別をなくしチームを統合 中 ● 朝会、夕会を共有 ● 開発は全員 Unity 版、HTML 版の開発環境を 触れるように 企画・仕様・設計の理解をメンバー全員が出来て るようにするのがねらい
- 101. 質疑応答 ● なにかあれば！
- 102. 今後ともよろしく！