要約
- データ管理の大部分がクライアント側。これによって、通信状況が悪くても待たされることが少ない。
- クライアント内部にDB (LevelDB) がある
- シーン遷移時に内部DBの差分を request queue にためていく
- 基本バックグラウンドで非同期通信
- ガチャや報酬受取などは同期通信（ブロッキング通信）
- ブロッキング通信するときは、事前にすべてのたまった非同期通信を処理し終えてから、始める
- サーバー側のDBはDynamoDB スケールしやすいから
- binary serializer は FlatBuffers
- FlatBuffers に独自実装をまぜてる（暗号化、msgpack/jsonへの変換）
- 「なにも考えずにすべての通信をブロッキング通信にしていませんか？」
- 今回のオートセーブ機構は Google Firebase Realtime Database の独自実装ともいえる
- 独自部分は「FlatBuffersによるスキーマ定義」「ゲーム固有のチート対策」
感想：非同期通信について
なにも考えずにすべての通信をブロッキング通信にしていませんか？
この言葉はグサッときた。 だいたいボタンを押したとき、ローディング画面などでまとめて通信を行うのがよくあるゲーム。
すると、待ち時間が発生して、イライラする・・。 操作中に裏で通信してると確かにストレスが減る。
余談：並列通信
裏で通信とはちょっと異なる話だけど、並列に通信するというのも大事。
たとえば、A -> B -> C と順番に通信すると、非常に待ち時間が長く、AとBは関係ない処理の場合 {A, B} -> C という並列通信にまとめられるはず・・。
でも通信を並列化しようとすると、開発の初期段階で通信周りの処理をしっかり設計しないと、むずかしい・・。
リリースしてからそこを変えるのは・・。。
感想：クライアント側DBについて
チート対策が非常に大変なので、クライアント側に多くデータをもたせることはやめよう、と思っていたので まさかクライアント側にこんなに大きくデータを持つネットゲームが現れるのは意外だった。
たしかに、ちゃんと対策できていればユーザー体験的には待ち時間が少なくてすばらしいのだけれど、 結局技術力がすごいないとチートまみれになってしまう・・。ってことかな。
具体的にどのような部分が狙われやすくて、どうやって対策したかのまとめがあれば、真似するだけでクライアント側にデータを持つ堅いゲームの参考になるかもしれない。
