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

1. このスライドはCEDEC2015で発表した「PlaygroundとLuaによ
る大規模モバイルオンラインゲーム開発のレベルアップ」の
「Part III 通信周りのレベルアップ」の部分です。
スライド全体は
https://cedil.cesa.or.jp/cedil_sessions/view/1345
をご覧ください。
発表原稿 :
https://gist.github.com/hasipon/155f3bb80f3a314ee96f
はじめに

2. Playgroundでゲーム作るよ

3. 背景
HTTPサーバ
クライアント
(ブラウザ)
HTML
ガラケー向け
ゲーム

4. 背景
スマホ向け
ゲーム
HTTPサーバ
クライアント
(Playground)
JSON
踏襲
⇒
HTTPサーバ
クライアント
(ブラウザ)
HTML
ガラケー向け
ゲーム

5. 背景
スマホ向け
ゲーム
HTTPサーバ
クライアント
(Playground)
JSON
踏襲
⇒
HTTPサーバ
クライアント
(ブラウザ)
HTML
ガラケー向け
ゲーム
サーバ
開発
サーバ
開発
クライアント
開発

6. 通信API
サーバ開発
クライアント開発
通信API設計
わかりやすい役割分担
わかりやすいスケジュール

7. 通信API
通信API設計とは？
→こんな感じのもの
リクエスト先
main.php/my/changeName/
リクエスト内容
{
"name":"新しい名前"
}
レスポンスデータサンプル
{
"before_name":"以前の名前",
"after_name":"新しい名前"
}

8. 設計の踏襲
ガラケー向け
ゲーム
HTML生成はサーバ側
↓
基本的に操作するたびに
通信
スマホ向け
ゲーム

9. 設計の踏襲
ガラケー向け
ゲーム
HTML生成はサーバ側
↓
基本的に操作するたびに
通信
スマホ向け
ゲーム
基本的に操作するたびに
通信
踏襲

10. 発生した問題
ガラケー向け
ゲーム
HTML生成はサーバ側
↓
基本的に操作するたびに
通信
スマホ向け
ゲーム
基本的に操作するたびに
通信
踏襲
海外向けゲームだったので
サーバを米国に

11. 発生した問題
ガラケー向け
ゲーム
HTML生成はサーバ側
↓
基本的に操作するたびに
通信
スマホ向け
ゲーム
基本的に操作するたびに
通信
踏襲
日本から遊ぶと
通信待ちがひどい
海外向けゲームだったので
サーバを米国に

12. なぜ通信待ちがひどいのか
● 操作するたびに通信しているから
通信頻度が多すぎる
● RTT が 180ms 程度あった
● 物理的に限界がある

13. どうやって通信待ちをごまかすか
サーバ開発
クライアント開発
通信API設計

14. どうやって通信待ちをごまかすか
ここから
見なおさなくては…
サーバ開発
クライアント開発
通信API設計

15. どうやって通信待ちをごまかすか
ここから
見なおさなくては…
サーバ開発
クライアント開発
通信API設計
大規模な改修

16. どうやって通信待ちをごまかすか
「スケジュール上
開発終盤なので急ぎで」
ここから
見なおさなくては…
サーバ開発
クライアント開発
通信API設計
大規模な改修
今ここ

17. どうやって通信待ちをごまかすか
「スケジュール上
開発終盤なので急ぎで」
ここから
見なおさなくては…
サーバ開発
クライアント開発
通信API設計
大規模な改修
今ここ

18. 「スケジュール上
開発終盤なので急ぎで」
ここから
見なおさなくては…
サーバ開発
クライアント開発
通信API設計
大規模な改修
短期的成果
を得るために
場当たり的
対応
今ここ
どうやって通信待ちをごまかすか

19. 「スケジュール上
開発終盤なので急ぎで」
は…
サーバ開発
クライアント開発
修
短期的成果
を得るために
場当たり的
対応
今ここ
場当たり的
対応
場当たり的
対応
積み重なる
場当たり的対応
信待ちをごまかすか

20. 小規模な修正すら
困難になっていく…
場当たり的
対応
場当たり的
対応

21. ガラケー向け
ゲーム
HTML生成はサーバ側
↓
基本的に操作するたびに
通信
スマホ向け
ゲーム
基本的に操作するたびに
通信
踏襲これが良くなかった →
反省点

22. 最初から、操作するたびに
通信しないように設計したい

23. 対策
操作するたびに通信しないようにするには？

24. 対策
操作するたびに通信しないようにするには？
→ 通信結果をキャッシュしよう

25. 対策
通信APIの種類ごとにキャッシュしてみる
API 1 API 2 API 3
キャッシュ キャッシュ

26. 発生した問題
他のAPIのレスポンスに影響を与えるときなどに
キャッシュ間の不整合が発生する
API 1 API 2 API 3
キャッシュ キャッシュ
影響不整合

27. 発生した問題
他のAPIのレスポンスに影響を与えるときなどに
キャッシュ間の不整合が発生する
API 1 API 2 API 3
キャッシュ キャッシュ
影響不整合
クライアントの複雑化に伴って
修正コストが増大していく…

28. 反省点
通信APIの種類ごとにキャッシュしてみる
API 1 API 2 API 3
キャッシュ キャッシュ
↑ これが良くなかった
なぜ通信APIの種類ごとなのか？

29. 反省点
キャッシュ実装はクライアント開発の領域
→サーバ開発から切り離してしまった
API 1 API 2 API 3
キャッシュ キャッシュ
サーバ
開発
クライアント
開発

30. キャッシュ実装と
サーバ開発を統合できないか？

31. MVVMとサーバ
View
View
Model
Model
クライアント

32. MVVMとサーバ
View
View
Model
Model
クライアント
サーバ
サーバとの通信はModelの役割

33. MVVMとサーバ
View
View
Model
Model
クライアント
サーバ
クライアント開発 サーバ開発

34. MVVMとサーバ
View
View
Model
Model
クライアント
サーバ
こうあるべきではないか？

35. 開発体制の変更
サーバ
開発
クライアント
開発
サーバ
キャッシュ
サーバ
Model
従来の開発体制 現在の開発体制
ViewModel

36. 開発体制の変更
サーバ
開発
クライアント
開発
サーバ
キャッシュ
サーバ
Model
従来の開発体制 現在の開発体制
ViewModel
クライアント開発が
通信つなぎこみ

37. 開発体制の変更
サーバ
開発
クライアント
開発
サーバ
キャッシュ
サーバ
Model
従来の開発体制 現在の開発体制
ViewModel
クライアント開発が
通信つなぎこみ
サーバ開発が
通信つなぎこみ

38. 開発体制の変更
サーバ
開発
クライアント
開発
サーバ
キャッシュ
サーバ
Model
従来の開発体制 現在の開発体制
ViewModel
クライアント開発に
通信APIを提供

39. 開発体制の変更
サーバ
開発
クライアント
開発
サーバ
キャッシュ
サーバ
Model
従来の開発体制 現在の開発体制
ViewModel
クライアント開発に
通信APIを提供
クライアント開発に
Modelの関数を提供

40. 開発体制の変更
サーバ
開発
クライアント
開発
サーバ
キャッシュ
サーバ
Model
従来の開発体制 現在の開発体制
ViewModel
ViewModelに影響しない
通信APIの変更が
サーバ開発に閉じる

41. 開発体制の変更
サーバ
開発
クライアント
開発
サーバ
キャッシュ
サーバ
Model
従来の開発体制 現在の開発体制
ViewModel
ViewModelに影響しない
通信APIの変更が
サーバ開発に閉じる
通信頻度削減のための
修正がしやすくなる

42. Modelの構成
API 1 API 2 API 3
キャッシュ キャッシュ
従来の方法 サーバ

43. Modelの構成
API 1 API 2 API 3
現在の方法
Model
サーバ

44. Modelの構成
API 1 API 2 API 3
現在の方法
Model
関数1 関数2
状態1 状態2
サーバ
Modelは状態と関数から構成される

45. Modelの構成
API 1 API 2 API 3
現在の方法
Model
関数1 関数2
状態1 状態2
サーバ
Modelの関数は
ViewModelに
データを加工して渡す

46. Modelの構成
API 1 API 2 API 3
現在の方法
Model
関数1 関数2
状態1 状態2
サーバ
Modelの関数は
サーバと通信する

47. Modelの構成
API 1 API 2 API 3
現在の方法
Model
関数1 関数2
状態1 状態2
サーバ
Modelの関数は
状態を変更する

48. 比較
API
キャッシュ
従来の方法
API
状態
現在の方法
Model
あまり変わってない…？

49. 比較
API
キャッシュ
従来の方法
API
状態
現在の方法
Model
設計順序が変わっている
先
後
後
先

50. 比較
API
キャッシュ
従来の方法
API
状態
現在の方法
Model
先
後
後
先
Modelの状態の設計に
合わせてサーバを設計できる
通信内容やサーバの処理を
効率化しやすい

51. Modelの実装と
サーバ開発を統合できた！

52. 難しい点 (1)
サーバ開発者もクライアントで動作するコードを
書く必要がある

53. 難しい点 (1)
サーバ開発者もクライアントで動作するコードを
書く必要がある
→ サーバ開発者もLuaを書く

54. 難しい点 (1)
サーバ開発者もクライアントで動作するコードを
書く必要がある
→ サーバ開発者もLuaを書く
→ がんばる

55. 難しい点 (1)
サーバ開発者もクライアントで動作するコードを
書く必要がある
→ サーバ開発者もLuaを書く
→ がんばる
→ 純粋なLuaに閉じるようにする

56. 難しい点 (2)
サーバ開発者とクライアント開発者の両方が
クライアントで動作するコードを書く

57. 難しい点 (2)
サーバ開発者とクライアント開発者の両方が
クライアントで動作するコードを書く
→ ひとつの機能に同時に両者が関わる

58. 難しい点 (2)
サーバ開発者とクライアント開発者の両方が
クライアントで動作するコードを書く
→ ひとつの機能に同時に両者が関わる
→ UIとロジックの分離がより厳密に要求される

59. 難しい点 (2)
サーバ開発者とクライアント開発者の両方が
クライアントで動作するコードを書く
→ ひとつの機能に同時に両者が関わる
→ UIとロジックの分離がより厳密に要求される
→ そもそも分離していないのは、
smart UI アンチパターン

60. 難しい点 (3)
通信API設計の変更頻度が上がる

61. 難しい点 (3)
通信API設計の変更頻度が上がる
→クライアントとサーバの対応関係が複雑になる

62. 難しい点 (3)
通信API設計の変更頻度が上がる
→クライアントとサーバの対応関係が複雑になる
→ソースコードリポジトリ統合

63. ソースコードリポジトリ統合
従来 クライアントリポジトリの
アセットによる肥大化
クライアントとサーバの
対応関係は人間が判断
アセット
クライアント
サーバ

64. ソースコードリポジトリ統合
現在 アセットリポジトリ独立で
クライアントのブランチ
切り替えも高速に
同じブランチなら
対応関係があると
考えて良い
アセット
クライアント
サーバ

65. 良かった点(1)
当初の目的通り、通信頻度削減に成功
→ クライアント側でのデータ保持を前提に
サーバ・通信APIを設計してあるので、
クライアントで保持したデータを
積極的に利用でき、通信頻度が下がる

66. 良かった点(2)
クライアント・サーバにまたがる修正が簡単に
→クライアントへの影響を気にして
修正を躊躇するケースが減った

67. 良かった点(3)
クライアント・サーバ統合テストの導入・自動化
→サーバだけのテストでは
クライアント側のデータ保持がカバーされない
→テスト自動化の観点からも
ソースコードリポジトリ統合は良かった

68. レベルアップまとめ
● レベル１
○ 操作するたびに通信しないようにするには、
最初からちゃんと設計しないと難しいことがわかった
● レベル２
○ キャッシュの実装は複雑化すると難しいことがわかった
● レベル３
○ Model開発とサーバ開発を統合できた