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