モバイルゲームのサーバー上のユーザーデータ周りについて

前置き

最近ではゲーム開発においてネットワークの要素は欠かせない要素になってきています。

一言にネットワークの要素といっても様々な要素があります。
・DLCや配信による追加コンテンツ対応
・ユーザーのセーブデータ管理
・ガチャやログインボーナス等の処理
・プラットフォームサービスやSNS等外部サービスとの連携
・サービス運営でお客様サポート等を行うために必要な諸々の話
・ネットワークを通じたマルチプレイ
等々…

今回はユーザーのセーブデータ管理や、ガチャやログインボーナスを行っているサーバー周りについて書き起こしたいと思います。

※ここでは、ガチャ等でマネタイズしているスマートフォン向けの基本無料ゲーム（いわゆるソシャゲ）を前提にして話を進めていきたいと思います。

ユーザーのセーブデータについて

モバイルゲームにおいては、ユーザーのセーブデータは端末側に保存せず、サーバーのデータベース上に保存される事が殆どです。
またクライアント側から直接データを書き換えを行うわけではありません。
APIサーバーと呼ばれるサーバープログラムがクライアントのリクエストを受け取り、APIサーバー内で処理を行った後にDBサーバー(データベースサーバー)のデータを書き換えを行うという形になっています。

分かりやすい例ではガチャです。
1.クライアント側から「このガチャを引きます」とサーバーに対して通信します(引きますとサーバーに伝えるだけで特に何も処理しません)。
2.受け取ったサーバー側は、受け取ったガチャの抽選情報を見てサーバー側で抽選処理を行います。その結果をDBサーバーに対して書き込みして、クライアントに結果を返します
3.サーバーから受け取った抽選結果を元にガチャのリザルト表示を行います。

APIサーバー・DBサーバー？

サーバーサイドでは複数のマシンが役割分担して動作しています。
ユーザーのデータやマスターデータを管理するDBサーバー、クライアントから受け取って処理の入り口になるAPIサーバー等々複数のマシンが動いています。

APIサーバーでは、PHPやJavaと言った言語で書かれたプログラムが動作していて、クライアントから受け取ったデータを処理します。
DBサーバーではMySQLやMariaDBなどと言ったSQLベースのデータベースで動作している事が多くあります。
ちなみに、私はPHPで作っていたAPIサーバーをJavaに乗り換えたという事がありました。

データベース上のユーザーデータについて

データベース上にユーザーのセーブデータが置かれるという話をしましたが、スタンドアローンのゲームのセーブデータと大分持ち方が異なります。

スタンドアローンでは1つのファイルに、進行の状況などをファイルに保存することでセーブデータを保持していると思います。
しかし、サーバー側にある場合はSQLのデータベース上に保存しています。
例えばですが、ユーザーの所持しているカード状況はDBのテーブル「user_card_inventry」に下記のような形で保存されています。

他にも、ユーザーの所持している強化アイテム情報ならば、このような感じです。

DBサーバー上のデータはすべてのユーザーが混在した形で入っています。

通常はリクエストがあった特定ユーザーのデータだけを扱う事が殆どです。そのため、リクエストされたユーザーのデータだけを扱うためにSQL分で条件を指定して、特定のユーザーのデータを取得したりします。
例えば、「SELECT * from user_card_inventry where user_id=1」のような形でデータベースにクエリを発行すると、user_idが1になっている user_card_inventryの情報が返ってくるといった形です。
（※ユーザーのデータが増えても検索のOrderがNにならないために user_idでIndexを貼るといった工夫なんかもしたりします)

セーブデータ管理について

このような形で、DBサーバー上にユーザーのデータを保存し管理する形になっています。
DBサーバー上にはカテゴリ別でデータがあり、全ユーザーのデータが混ざっています。そして、SQLで条件を指定してリクエストのあったユーザーのデータだけを扱うといった形になっております。
また、クライアントアプリから直接書き換えるのではなく、APIサーバーで処理をして書き換えるという構造になっています。