モバイルゲームのサーバー上のユーザーデータ周りについて
前置き
最近ではゲーム開発においてネットワークの要素は欠かせない要素になってきています。
一言にネットワークの要素といっても様々な要素があります。
・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サーバーで処理をして書き換えるという構造になっています。
この記事が気に入ったらサポートをしてみませんか?