00:00
こんにちは、シニアソフトウェアエンジニアのリドルです。このポッドキャストは、IT業界のいろんな話やキャリア、自分たちの困りごとについてお話しするポッドキャストです。
今回は、ソーシャルゲームのバックエンド開発についての後編をお届けします。今回はですね、実際にソーシャルゲーム特有の機能みたいなものをどうやって作っているのかとか、どういう種類のものがあるのかについてご紹介します。
もし前編をご覧になってない方は、先にそちらを聞いていただいた方がより楽しめるかなと思いますので、よろしくお願いします。
チート対策の重要性
では行きましょう。まず1個目、これなんといってもね、チート対策ですね。これね、代償様々あるんですけれども、ソーシャルゲームはですね、めちゃくちゃチートされます。
これいうチートっていうのは、ズルのこと全般を言うんですけれども、クライアントに対するゲーム内のデータを書き換えるみたいな話から、時間を操作する。
時間を操作するっていうのは、クライアント側の端末の時間を変更して、ボーナスをもらったりとか、ゲームを早く進めたりとか、そういうこともありますし、
あとはもう物理的にサーバーに対して攻撃を仕掛けてくるとか、もしくはボットを使って大量にユーザーを作成するとか、
もうなんかいろんなね、多種多様なね、ズルをね、やってくるんですよ。 なのでソーシャルゲーム開発におけるチート対策というのはですね、
一大分野になっていて、それ専門の仕事もあったりします。 あとはそれ専門のツールもあったりします。
多くはクライアントに埋め込むタイプのチート対策ツールなんですけれども、その他にもですね、自分たちが困っているシチュエーションにおいて、
役立つ方法とか手法みたいなものも結構あります。 一つ私が覚えているのというと、例えば私がやっていたゲームはアクションゲームで、
マルチプレイでどっかダンジョンを潜って、敵を倒したアイテムをドロップするみたいな感じだったんですけれども、
このドロップアイテムに対してチートができる可能性があるので、あらかじめこうサーバー側で決められたデータに従って、
ドロップを操作することで、最終的にそのドロップがおかしくないかみたいなことを、ダンジョンクリア時に突合してチェックして、
チートされてないねみたいなことをやったりだとか、まあいろいろやりましたね。 なのでこれからソーシャルゲームに関わられる方については、
そういうチート対策っていうのは一定やらないといけないので結構大変だと思います。 これねチート対策ねやればいいんですけど、やったらやっただけ自分たちの開発も大変になるんですよね。
こうなんかね抜け道をこう用意しないとデバッグしづらいんですけど、でも抜け道用意するとチートになるんで、ここねちょっと難しいですバランスが。
ゲームサーバーの構築
続いてマッチングとかマルチのゲームサーバーですね。 これはゲームの種類にもよるんですけれども、最近のゲームは基本的にマルチが多いかなと思うので、
この特殊なゲームサーバーが必要になります。 通常バックエンドサーバーの開発だと、APIサーバーとかグラフQLのサーバーとかGRPCのサーバーを作ることが
メインになるかと思うんですけども、マッチングとかねゲームサーバーってのはね全く違うジャンルなんですよ。
特にゲームサーバーっていうのは複数のユーザーがそのサーバーに接続して、 いわゆるルーターとかリレーサーバーみたいな呼ばれ方をすることもあるんですけども、
そこでパケットを交換してお互いに通信することでゲームを成り立たせるとか そういうことが求められますし、場合によってはゲームのエンジンと呼ばれる
ゲームを再現する、ただしGUIはないみたいな、要するに物理演算とかゲームのロジックを実行するみたいな機能を持ったものを
ゲームルームサーバー内に組み込んで、ユーザーが全員がそこにアクセスすることで同じ世界を共有できる、そういうものですね。
デリケーティブゲームサーバーって呼ばれることが多いかな。 これはこれでめちゃくちゃ大変で、ネットワークの知識も必要だし、ゲームのエンジンの知識も必要だし、
かつ通常のAPIサーバーと違って、CPUとかメモリの使用率とかも結構シビアに見ないといけなかったりとか、 それが結構ユーザーの体系に直影響することも多いので、
言語選定とか、プロトコル選定とかも結構特殊ですね。 特にGKEで動かすようなケースの場合だと、アゴネスっていう専用のミドルウェアがOSSでありまして、
その上で動かすっていうのは結構デファクトになってますね。 というのも、GKEみたいなKubernetesみたいなポットって基本的にはステートレスなものを並べて、
どれかが落ちても代わりに他のものが同じものが動いているので、そっちに飛ばせば問題ないって感じなんですけども、
ゲームの場合って、例えば4人で対戦している場合に、その4人で対戦するポットが落ちてしまうと、 その4人でまた再集合したいじゃないですか。
ただ、そういうものがうまーくやるための仕組みがGKEにはデフォルトでなかったりするので、 ステートフルセットってのもあるんですけど、それもちょっと役割違うんで、
そうするとそういうものをカスタムリソースとして定義できるようなアゴネスを入れてあげて、 アゴネスの上で動かすみたいなものが結構スタンダードになってますし、
また誰と誰をどういうロジックでマッチングさせようかっていうマッチングサーバーは別に必要で、 これもねオープンマッチっていうOSSがあって、それを使っているケースもあるんですけども、
やっぱり各社マッチングに対してはユーザーの満足度に結構直結するところも多いので、 自作で強いことも多いです。
ガチャとメンテナンスの実装
はい続いてガチャですね。ガチャもね捧げ文化ですよね。 しかもねガチャ前編でもお話ししたんですけど、特許があるんですよ。
これはガチャを実装する仕組みだったり、ガチャ自体としてどういうガチャ、 例えばステップアップガチャとかいろいろあるんですけども、
まあそういうものについての特許が問われていることがあります。 でもねプランナーだったり企画の方はどうにかしてお金を稼ぎたいので、
ユーザーの社交支援を煽るいろんなガチャをね考えてくるんですよね。 一方でガチャって正確性がやっぱり担保されてないとまずいというか、
要するに確率表を今は出さないといけないんですよ。 このガチャを引いた時に何パーセントでこのユーザーが引けますとか、
それを表示しないといけないので、そうするとちゃんと複雑なガチャを作ったとしても、 ちゃんとその確率通りにキャラ出るよねっていうチェックをテストではするんですけども、
まあ複雑な仕様になればなるほどね。ガチャめちゃくちゃ大変です。 なので各ゲームにガチャは絶対あると思いますけど、その裏側は結構大変なことになっております。
続いてメンテナンスですね。ソーシャルゲームやったことあればわかると思うんですけど、 ソシャゲって大体メンテナンスに入りますよね。
なんか1ヶ月に1回とか2週間に1回とか、なんなら緊急メンテナンスみたいに急にバーンって入るみたいなケースもあります。
あれ裏で何やってるかというと、単純に新しいサーバーとかクライアントをアップデートして、 データを入れ替えてリリースしてテストみたいなことを裏でやってるんですよ。
通常のウェブサービスとかだったら、ユーザーに何も酷使しないで、去ってサーバー入れ替えてみたいなことをやるのが大半で、
本当にセンシティブで止めないといけないものに関しては、たまに現在サービス撤収ですみたいなことを出すケースもあるんですけど、
ゲームの作業が結構複雑だったりだとか、一斉に皆さんに遊んでいただきたいみたいな思惑もあるので、基本的にはサービスを止めてリリースして、
メンテナンスを解除してというケースが大半です。なので、このメンテナンスに入れる技術とか、メンテナンス自体をできるように実装するっていうのも
ソーシャルゲームのあるあるだと思います。またメンテナンスといっても普通のメンテナンスとか、強制メンテナンスとか、段階が分かれていることが結構多いので、
それぞれに合わせてこういう作りにしようとか、そうなってるのが多いですね。 続いてタイムトラベルですね。
これは呼び方様々だと思うんですけれども、私はタイムトラベルと呼んでいました。 これはですね、デバッグ機能ですね。ことソーシャルゲームに関しては時間とか日付
これが大事になってきていて、何かというとこの時間から始まるダンジョンとかイベント この時から引けるガチャ、もしくはこの時までカウントできるミッションとか
いろいろあるんですよ。時間がめちゃくちゃ大事なんです。基本的にチートをさせないためにクライアント側の時刻は一切信用しなくて、サーバー側にある時刻を使ってみんなで共有して正しい時刻を管理してるんですけれども、そうなるとですね、QAとかデバッグの時って時間を自由に変えたいじゃないですか。
だって変えないとこのミッションやるために深夜2時まで起きないとまずいとかそんなできないので、そうすると時間を自由に移動できる機能、まあ我々はタイムトラベルと呼んでいましたが、そういうものを作る必要があります。
ミッションの複雑さ
なのでサーバー側でそういう実装を用意して、管理ツール側でこの時間にジャンプしたいみたいな設定をすると、手元のクライアントのゲームではそのユーザーだけがこの時間になるとか、そういう機能を用意します。
実装はね意外にそんな大変じゃないんですけども、やっぱりバグの音症になるというか、正規の時間じゃなくて無理やり書き換えてる時間だったりするので、その実装を考慮できていないと、なんかこのミッションは動かないんだけどみたいなことがね結構あります。
続いて今ちょっと名前が出ました。ミッションですね。ミッションはね皆さんどう思ってるかわかんないんですけど、裏側めちゃくちゃ大変なんですよ。
ミッションってユーザーの満足度を上げたりとか、アイテムを配ったりするにめちゃくちゃ便利で、めちゃくちゃ機能が豊富になりがちなんですよ。
例えばデイリーミッション、ウィークリーミッションみたいな、毎日同じやつをやっていくみたいなミッションもあれば、親ミッションがあって、コミッションがある。
でコミッション全部達成すると親ミッションが達成扱いになるとか、ミッションの条件も色々あって、アイテムをゲットすることとか、
フレンドを招待することとか、モンスターを何体倒すこと、特定のモンスターを何分以内に倒すこと、この武器を装備して倒すこととか、条件がめちゃくちゃいっぱいありますよね。
これをねまともに実装するとめちゃくちゃ大変なんですよ。ユーザーのアクションを一つ一つに対して何かフラグを更新して、そのフラグの更新を契機にミッションを更新するのか、
はたまた全部のAPIの裏側でミッションの更新を呼び出すのか、もっと複雑な構成にするならイベント駆動みたいなものにしてイベントに対してミッションを更新している非同期の構成にするのか、
でもその構成にするとユーザーはアクションしたけどミッションが更新されないみたいなケースがあるかもしれないけど大丈夫かとか、
あれはですね、マジでミッションは大変なんです。ちょっと調べてもらえばわかると思いますが、初詐欺ミッションみたいなことで調べるといろんな実装方法が出てきます。
結構バラバラですね。これは仕様によるから作るものは変わるというのもあるんですけれども、結構ミッションはですね、
初詐欺開発の花形と言ってもいいぐらい複雑です。ここをうまく作れるかによってバックエンドエンジニアの力量が問われます。
ログイン処理の重要性
最後です。ログインですね。皆さんログインって聞くと普通常のユーザーとパスワードを入れてのログインだと思いますが、
初詐欺のログインは違います。モンストとかだと朝4時が日にちの切り替わりのタイミングなんですね。
まぁちょっとよくわかんないと思うんですけど、基本なんか0時で切り替わるじゃないですか。そうじゃなくて、ゲームの場合はシステムの負荷が高くない時間みたいなものを狙って、
中途半端な時間にしたりすることがあるんですけど、モンストの場合だと朝4時に次の日に切り替わるって感じなんですね。
次の日に切り替わる時にそのログインというイベントを叩くというかAPIで叩くんですけども、その裏ではめちゃくちゃいろんなことやるんですよ。
例えば新しいマスターデータ。マスターデータっていうのはゲーム内のモンスターとか武器のデータとかステージのデータとかガチャのデータとかを全部持ってるデータがあるんですけども、これをサーバーからダウンロードしてきてクライアントが使うとか、
そのためにクライアントは一度リスタートしますよだったり、ログイン経験で例えばスタミナ回復するとか、特定のイベントの挑戦回数が回復するとか、何かアイテムがもらえるとか、ミッションが進捗するとか、本当にいろんなことが起こるんですよ。
大体のソシャゲの場合って、最初はもうエイヤで作りきっちゃうんで、めちゃくちゃ拡張することをそんなに考えてないんですよ。
これはもうしょうがない。ただソシャゲって当たるとデカいもので、当たるとこのログイン処理めちゃくちゃ重くなるんですよね。
なぜかというと、いろんな機能が増えてきたり、いろんなイベントが増えてくると、結局そのリセットをログインに寄せたりするんですよ。
そうなるとログインがめちゃくちゃ重たくなるんですね。本当だったらログインのタイミングでログインイベントみたいなものを発行してあげて、
そいつをフックする形でイベント駆動でいろんな処理を裏でどうにか処理するみたいなイベント駆動のやり方もあると思うんですけど、
まあ大体のソシャゲはそこまでカバーしきれてないので、愚直にログインAPIの裏側でめちゃくちゃいっぱい書いて、ファットなコントローラーみたいなのができるわけですよ。
ファットなUスケースでもいいんですけど、だからこのログインっていうのは結構ね、魔境になっていると聞くことが多いですね。
まあこの他にもですね、まあいろんなAPIあります。武器をね、同行するとか、モンスターを同行するとか、アイテムをゲストするとか、ギフトを送るとか、フレンドを招待するとか、
フレンドを申請する、フレンドを解除する、ランキングを見る、ランキングに入る。これはまあゲームのね、機能の数だけAPIも大量に存在するんで、本当にね、わけわかんなくなります。
まあそういう感じで、ちょっとソーシャルゲームサーバーのいろんな裏側の特殊な話をさせていただきました。
まあね、バックエンドエンジニアとしては、ソーシャルゲーム開発はめちゃくちゃ力つくと思うんで、そういうのを期待する方は是非参加していただきたいなと思います。
最近だとね、結構ソーシャルゲーム開発やってる会社も減ってきましたし、1回作るにあたって数年かかることがザラになってきてしまったので、
なかなか機会としては多くないかもしれないんですけれども、是非そういう機会があればですね、飛び込んでみてください。
このポートキャストはハッシュタグユーザーITで皆様からの感想やコメント募集しております。
また、チャンネルの概要欄からですね、Googleフォームのリンク経由での投稿も可能ですので、よろしくお願いします。
ありがとうございました。
