スマホアプリの中ってどうなってるの?

世に流通しているゲームは沢山ありますが、作り方について大きく分けると2種類あります。

1つは、スタンドアローン型と呼ばれ、プログラムとハード(以降クライアントと呼びます)のみで構成されます。

インベーダーゲーム、ファミコンのゲームなど古くのゲームはこの型で、一度発売したらバージョンアップができないと言うのが大きな特徴です。

バージョンアップができないと言う事は不具合も修正できないと言う事ですが、昔は不具合を裏技と称しポジティブに扱っていました(笑)

不具合と言ってしまうと最悪の場合は交換になりかねませんから。

そしてもう1つは、オンライン型と呼ばれ、プログラムとクライアントの他、インターネット環境とサーバーで構成されます。

現在スマホアプリとしてリリースされているのは殆どがオンライン型です。

オンライン型の最大の特徴は、バージョンアップや不具合修正ができる事。

「無料」で始められて、どんどん追加される強キャラを「ガチャでゲットする」ビジネスモデルは今のところ鉄板で、しばらくは続くと思います。

で、オンライン型ですが、ゲームデータやセーブデータをサーバーとクライアントでやりとりしてるだけ、と思っている人も多いのではないでしょうか?

スマホアプリの仕事をする前は自分も、サーバーってユーザー共有のメモリーカードなのかな、と思っていました。

この考えは概ね間違っていないのですが、クライアントのデータは書き換える事ができるのを前提としなければなりません。

世の中には色んなツールがあるので、スマホの中のプログラムを書き換えるのは簡単です。

(ガラケーのソシャゲの時は、アドレスを暗号化していないと入手アイテムの個数を書き換える事もできていたようですが。)

例えば、あるステージでレアアイテムをドロップしたようにデータを書き換えたとします。

スタンドアローン型だったら、このまま進行できてしまいますが、オンライン型の場合は、チェックを行い、不正と判断したらエラーメッセージを表示してタイトルに飛ばしてしまいます。

多くのゲームは、データを戻す、そのステージを遊ばなかった事になるのではないでしょうか。

どのようにチェックしているかと言うと、まずステージ開始時にドロップするかしないかを決めてしまいます

そしてステージリザルトで嘘データをサーバーに送った場合、サーバー側の整合性チェックで、もともとドロップされていないと決定されていたのに違うデータが来たと判断されたらエラーメッセージを表示してタイトルに飛ばします。

文だと分かりにくいので、流れを箇条書きにするとこんな感じです。

ユーザー:「イベントステージを遊ぶぜ!」

クライアント:「イベントステージ遊ぶからデータとドロップ結果の計算をサーバー君よろしく!」

サーバー:「イベントステージのデータとドロップ結果を決めたからクライアント君に送るね!」

クライアント:「サーバー君からデータが来たからイベントステージ始めるね!」

ユーザー:「レアアイテムが出た事にしてデータ書き換えたろ!」

クライアント:「ステージをクリアしたからドロップ結果をサーバー君に送るね!」

サーバー:「あれ、このレアアイテムはドロップしないハズだったのに何かデータ壊れたかな、安全のためデータをステージ遊ぶ前にデータを戻すね!」

まだ、分かりにくいかなー。もっと分かりやすい表現を考えたら修正するかもです。

この「あらかじめデータを決めておく」手法は賢いなーと思います。某コンシューマの対戦ゲームでも採用していました。

ネット対戦で負けそうになると切断しちゃうユーザーがいますすが、通信切断による終了は敗北にならないゲームもあるんですよね。

負けたくないのでケーブルを抜く人がいると思いますが、それを防ぐため、対戦開始時に、まず両方共に負けた情報を保存します。そうすると通信切断で終了しても情報は残っているので、負けた事になります。

正常に対戦が終わった時は、勝者のみデータを書き換えて終了です。

ついでに言うと、対戦ゲームの中には切断率を保持しているものもあります。対戦開始時に「切断した」情報をこっそり保存しておき、正常終了した場合は消すんです。

そして、マッチング条件の中に切断率が近いユーザーという条件を入れれば、切断率が低いユーザー同士が対戦ができる仕組みです。

確か携帯機版のゼルダがこれを採用していたと記憶しています。

話を戻しますが、ステージを始める・終わる時、ゲームによってロード時間に差があります。

これは、端末の性能やゲーム処理の重さと言うよりは、如何にして最小限のデータのやりとりで済ますか、をこだわっている重要な点で、セールスランキングの上位にいるアプリはだいたいサクサク進みます。

たまーにありますけどね。新しめの会社で初のスマホアプリだと頻繁にロードが入るものとか。そこはサーバーとクライアントのプログラム設計の経験が物を言うので、なかなか真似できるものではないです。




シェアする

  • このエントリーをはてなブックマークに追加

フォローする