Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CEDEC 2015: PlaygroundとLuaによる 大規模モバイルオンラインゲーム開発のレベルアップ Part3

590 views

Published on

CEDEC2015で発表した、PlaygroundとLuaによる大規模モバイルオンラインゲーム開発のレベルアップ
( http://cedec.cesa.or.jp/2015/session/ENG/9928.html )の「Part III 通信周りのレベルアップ」の部分

Published in: Technology
  • Be the first to comment

CEDEC 2015: PlaygroundとLuaによる 大規模モバイルオンラインゲーム開発のレベルアップ Part3

  1. 1. このスライドはCEDEC2015で発表した「PlaygroundとLuaによ る大規模モバイルオンラインゲーム開発のレベルアップ」の 「Part III 通信周りのレベルアップ」の部分です。 スライド全体は https://cedil.cesa.or.jp/cedil_sessions/view/1345 をご覧ください。 発表原稿 : https://gist.github.com/hasipon/155f3bb80f3a314ee96f はじめに
  2. 2. Playgroundでゲーム作るよ
  3. 3. 背景 HTTPサーバ クライアント (ブラウザ) HTML ガラケー向け ゲーム
  4. 4. 背景 スマホ向け ゲーム HTTPサーバ クライアント (Playground) JSON 踏襲 ⇒ HTTPサーバ クライアント (ブラウザ) HTML ガラケー向け ゲーム
  5. 5. 背景 スマホ向け ゲーム HTTPサーバ クライアント (Playground) JSON 踏襲 ⇒ HTTPサーバ クライアント (ブラウザ) HTML ガラケー向け ゲーム サーバ 開発 サーバ 開発 クライアント 開発
  6. 6. 通信API サーバ開発 クライアント開発 通信API設計 わかりやすい役割分担 わかりやすいスケジュール
  7. 7. 通信API 通信API設計とは? →こんな感じのもの リクエスト先 main.php/my/changeName/ リクエスト内容 { "name":"新しい名前" } レスポンスデータサンプル { "before_name":"以前の名前",  "after_name":"新しい名前" }
  8. 8. 設計の踏襲 ガラケー向け ゲーム HTML生成はサーバ側 ↓ 基本的に操作するたびに 通信 スマホ向け ゲーム
  9. 9. 設計の踏襲 ガラケー向け ゲーム HTML生成はサーバ側 ↓ 基本的に操作するたびに 通信 スマホ向け ゲーム 基本的に操作するたびに 通信 踏襲
  10. 10. 発生した問題 ガラケー向け ゲーム HTML生成はサーバ側 ↓ 基本的に操作するたびに 通信 スマホ向け ゲーム 基本的に操作するたびに 通信 踏襲 海外向けゲームだったので サーバを米国に
  11. 11. 発生した問題 ガラケー向け ゲーム HTML生成はサーバ側 ↓ 基本的に操作するたびに 通信 スマホ向け ゲーム 基本的に操作するたびに 通信 踏襲 日本から遊ぶと 通信待ちがひどい 海外向けゲームだったので サーバを米国に
  12. 12. なぜ通信待ちがひどいのか ● 操作するたびに通信しているから 通信頻度が多すぎる ● RTT が 180ms 程度あった ● 物理的に限界がある
  13. 13. どうやって通信待ちをごまかすか サーバ開発 クライアント開発 通信API設計
  14. 14. どうやって通信待ちをごまかすか ここから 見なおさなくては… サーバ開発 クライアント開発 通信API設計
  15. 15. どうやって通信待ちをごまかすか ここから 見なおさなくては… サーバ開発 クライアント開発 通信API設計 大規模な改修
  16. 16. どうやって通信待ちをごまかすか 「スケジュール上 開発終盤なので急ぎで」 ここから 見なおさなくては… サーバ開発 クライアント開発 通信API設計 大規模な改修 今ここ
  17. 17. どうやって通信待ちをごまかすか 「スケジュール上 開発終盤なので急ぎで」 ここから 見なおさなくては… サーバ開発 クライアント開発 通信API設計 大規模な改修 今ここ
  18. 18. 「スケジュール上 開発終盤なので急ぎで」 ここから 見なおさなくては… サーバ開発 クライアント開発 通信API設計 大規模な改修 短期的成果 を得るために 場当たり的 対応 今ここ どうやって通信待ちをごまかすか
  19. 19. 「スケジュール上 開発終盤なので急ぎで」 は… サーバ開発 クライアント開発 修 短期的成果 を得るために 場当たり的 対応 今ここ 場当たり的 対応 場当たり的 対応 積み重なる 場当たり的対応 信待ちをごまかすか
  20. 20. 小規模な修正すら 困難になっていく… 場当たり的 対応 場当たり的 対応
  21. 21. ガラケー向け ゲーム HTML生成はサーバ側 ↓ 基本的に操作するたびに 通信 スマホ向け ゲーム 基本的に操作するたびに 通信 踏襲これが良くなかった → 反省点
  22. 22. 最初から、操作するたびに 通信しないように設計したい
  23. 23. 対策 操作するたびに通信しないようにするには?
  24. 24. 対策 操作するたびに通信しないようにするには? → 通信結果をキャッシュしよう
  25. 25. 対策 通信APIの種類ごとにキャッシュしてみる API 1 API 2 API 3 キャッシュ キャッシュ
  26. 26. 発生した問題 他のAPIのレスポンスに影響を与えるときなどに キャッシュ間の不整合が発生する API 1 API 2 API 3 キャッシュ キャッシュ 影響不整合
  27. 27. 発生した問題 他のAPIのレスポンスに影響を与えるときなどに キャッシュ間の不整合が発生する API 1 API 2 API 3 キャッシュ キャッシュ 影響不整合 クライアントの複雑化に伴って 修正コストが増大していく…
  28. 28. 反省点 通信APIの種類ごとにキャッシュしてみる API 1 API 2 API 3 キャッシュ キャッシュ ↑ これが良くなかった なぜ通信APIの種類ごとなのか?
  29. 29. 反省点 キャッシュ実装はクライアント開発の領域 →サーバ開発から切り離してしまった API 1 API 2 API 3 キャッシュ キャッシュ サーバ 開発 クライアント 開発
  30. 30. キャッシュ実装と サーバ開発を統合できないか?
  31. 31. MVVMとサーバ View View Model Model クライアント
  32. 32. MVVMとサーバ View View Model Model クライアント サーバ サーバとの通信はModelの役割
  33. 33. MVVMとサーバ View View Model Model クライアント サーバ クライアント開発 サーバ開発
  34. 34. MVVMとサーバ View View Model Model クライアント サーバ こうあるべきではないか?
  35. 35. 開発体制の変更 サーバ 開発 クライアント 開発 サーバ キャッシュ サーバ Model 従来の開発体制 現在の開発体制 ViewModel
  36. 36. 開発体制の変更 サーバ 開発 クライアント 開発 サーバ キャッシュ サーバ Model 従来の開発体制 現在の開発体制 ViewModel クライアント開発が 通信つなぎこみ
  37. 37. 開発体制の変更 サーバ 開発 クライアント 開発 サーバ キャッシュ サーバ Model 従来の開発体制 現在の開発体制 ViewModel クライアント開発が 通信つなぎこみ サーバ開発が 通信つなぎこみ
  38. 38. 開発体制の変更 サーバ 開発 クライアント 開発 サーバ キャッシュ サーバ Model 従来の開発体制 現在の開発体制 ViewModel クライアント開発に 通信APIを提供
  39. 39. 開発体制の変更 サーバ 開発 クライアント 開発 サーバ キャッシュ サーバ Model 従来の開発体制 現在の開発体制 ViewModel クライアント開発に 通信APIを提供 クライアント開発に Modelの関数を提供
  40. 40. 開発体制の変更 サーバ 開発 クライアント 開発 サーバ キャッシュ サーバ Model 従来の開発体制 現在の開発体制 ViewModel ViewModelに影響しない 通信APIの変更が サーバ開発に閉じる
  41. 41. 開発体制の変更 サーバ 開発 クライアント 開発 サーバ キャッシュ サーバ Model 従来の開発体制 現在の開発体制 ViewModel ViewModelに影響しない 通信APIの変更が サーバ開発に閉じる 通信頻度削減のための 修正がしやすくなる
  42. 42. Modelの構成 API 1 API 2 API 3 キャッシュ キャッシュ 従来の方法 サーバ
  43. 43. Modelの構成 API 1 API 2 API 3 現在の方法 Model サーバ
  44. 44. Modelの構成 API 1 API 2 API 3 現在の方法 Model 関数1 関数2 状態1 状態2 サーバ Modelは状態と関数から構成される
  45. 45. Modelの構成 API 1 API 2 API 3 現在の方法 Model 関数1 関数2 状態1 状態2 サーバ Modelの関数は ViewModelに データを加工して渡す
  46. 46. Modelの構成 API 1 API 2 API 3 現在の方法 Model 関数1 関数2 状態1 状態2 サーバ Modelの関数は サーバと通信する
  47. 47. Modelの構成 API 1 API 2 API 3 現在の方法 Model 関数1 関数2 状態1 状態2 サーバ Modelの関数は 状態を変更する
  48. 48. 比較 API キャッシュ 従来の方法 API 状態 現在の方法 Model あまり変わってない…?
  49. 49. 比較 API キャッシュ 従来の方法 API 状態 現在の方法 Model 設計順序が変わっている 先 後 後 先
  50. 50. 比較 API キャッシュ 従来の方法 API 状態 現在の方法 Model 先 後 後 先 Modelの状態の設計に 合わせてサーバを設計できる 通信内容やサーバの処理を 効率化しやすい
  51. 51. Modelの実装と サーバ開発を統合できた!
  52. 52. 難しい点 (1) サーバ開発者もクライアントで動作するコードを 書く必要がある
  53. 53. 難しい点 (1) サーバ開発者もクライアントで動作するコードを 書く必要がある → サーバ開発者もLuaを書く
  54. 54. 難しい点 (1) サーバ開発者もクライアントで動作するコードを 書く必要がある → サーバ開発者もLuaを書く → がんばる
  55. 55. 難しい点 (1) サーバ開発者もクライアントで動作するコードを 書く必要がある → サーバ開発者もLuaを書く → がんばる → 純粋なLuaに閉じるようにする
  56. 56. 難しい点 (2) サーバ開発者とクライアント開発者の両方が クライアントで動作するコードを書く
  57. 57. 難しい点 (2) サーバ開発者とクライアント開発者の両方が クライアントで動作するコードを書く → ひとつの機能に同時に両者が関わる
  58. 58. 難しい点 (2) サーバ開発者とクライアント開発者の両方が クライアントで動作するコードを書く → ひとつの機能に同時に両者が関わる → UIとロジックの分離がより厳密に要求される
  59. 59. 難しい点 (2) サーバ開発者とクライアント開発者の両方が クライアントで動作するコードを書く → ひとつの機能に同時に両者が関わる → UIとロジックの分離がより厳密に要求される → そもそも分離していないのは、 smart UI アンチパターン
  60. 60. 難しい点 (3) 通信API設計の変更頻度が上がる
  61. 61. 難しい点 (3) 通信API設計の変更頻度が上がる →クライアントとサーバの対応関係が複雑になる
  62. 62. 難しい点 (3) 通信API設計の変更頻度が上がる →クライアントとサーバの対応関係が複雑になる →ソースコードリポジトリ統合
  63. 63. ソースコードリポジトリ統合 従来 クライアントリポジトリの アセットによる肥大化 クライアントとサーバの 対応関係は人間が判断 アセット クライアント サーバ
  64. 64. ソースコードリポジトリ統合 現在 アセットリポジトリ独立で クライアントのブランチ 切り替えも高速に 同じブランチなら 対応関係があると 考えて良い アセット クライアント サーバ
  65. 65. 良かった点(1) 当初の目的通り、通信頻度削減に成功 → クライアント側でのデータ保持を前提に サーバ・通信APIを設計してあるので、 クライアントで保持したデータを 積極的に利用でき、通信頻度が下がる
  66. 66. 良かった点(2) クライアント・サーバにまたがる修正が簡単に →クライアントへの影響を気にして 修正を躊躇するケースが減った
  67. 67. 良かった点(3) クライアント・サーバ統合テストの導入・自動化 →サーバだけのテストでは クライアント側のデータ保持がカバーされない →テスト自動化の観点からも ソースコードリポジトリ統合は良かった
  68. 68. レベルアップまとめ ● レベル1 ○ 操作するたびに通信しないようにするには、 最初からちゃんと設計しないと難しいことがわかった ● レベル2 ○ キャッシュの実装は複雑化すると難しいことがわかった ● レベル3 ○ Model開発とサーバ開発を統合できた

×