ソーシャルゲームの特徴
こんにちは、シニアソフトウェアエンジニアのリドルです。このポッドキャストは、IT業界のいろんな話だったり、自分たちのキャリア、困り事についてお話しするポッドキャストです。
今回は、ソーシャルゲーム開発の、特にバックエンドについてご紹介したいと思います。今回はですね、2部構成になってまして、第1部では、ソーシャルゲームのバックエンド開発ってどんなものなの?
普通の開発と何が違うの?という話。第2部ではですね、具体的に作る機能について大きな違いがあるので、そこをご紹介したいと思います。
はい、皆さんソーシャルゲームって作られたことありますかね?もしくはプレイしたことあるでしょうか?
私はバックエンドキャリアの最初がソーシャルゲーム開発だったので、ちょっといろいろと思い入れがあるのでご紹介できればと思います。
モバイルゲーム、もしくはソーシャルゲーム、通常ソーシャゲーと言いますが、これって普通のコンシューマーゲームとは何が違うんでしょうか?
コンシューマーゲームというのは、いわゆる買い切りの作品のことを指していて、皆さんがもしかしたらプレイしたことがある昔のゲームソフトとかですね。
ポケモンとかストリートファイターとかロックマンとか、そういうのは基本的にはソフトを買ってきて、家で何かのゲームの筐体で遊ぶみたいな感じですよね。
1回5000円とか8000円とか払ってずっと遊べるし、その後のアップデートは基本的にないよというもの。
最近だと後でね、追加のDLCみたいなコンテンツがあったり、バグについてはパッチが提供されることもありますが、基本的には買い切りというものがコンシューマーゲームとなります。
一方でソーシャルゲーム、ソーシャゲーについては、リリースしてから頻繁にアップデートがあります。
2週間に1回とか1ヶ月に1回とか、どんどんバージョンアップしていって、1年後にはね、全然違うサービスになってますよね。
そういう感じで基本的にはコンシューマーゲームっていうのは作りきるまでが勝負なんですけれども、ソーシャルゲームは作りきるまでも勝負だし、運用に乗ってからも勝負っていうね、そういう性質の違いがあります。
ユーザー獲得の重要性
サービスがゲームっていうことなので、通常のサーズとかユーザーに提供するプロダクトとは違いまして、マーケットはですね、別に欲しいものを作るわけじゃないんですよね。
というのも、例えば任天堂スターが持たれているマリオシリーズだったり、ゼルダシリーズみたいなものは一定のファンがもともといて、それに合ったものを作るので、少し例外とはなりますが、
いきなり例えばスプラトゥーンというものを作りますとか、まあわからないけど新しいソーシャルゲームを作りますってなると、ユーザーが別にね、このゲーム遊びたいって言ってるから作ろうってわけじゃないんですよね。
今のところこのゲームないからとか、このジャンルのここのユーザー末層に狙ったゲームはないから作ろうみたいな、調査をベースにやったりとか、
こういう体験新しいからさせてあげたいから作ろうみたいな、そういう駆動になっているので、そのゲームって実際に遊んでもらうまでヒットするかどうかとか、
面白いかどうかって全然わかんないんですよ。なので、いわゆるプロダクト開発におけるマーケットプロダクトフィットを狙ったような最小単位でのリリースみたいなのは難しくて、
特にソシャゲの場合は初動がすべてなんですね。最初にどれだけたくさんのユーザーに認知してもらって遊んでもらえるかっていうのがめちゃくちゃ大事なんで、
ちっちゃく作って徐々に成長していこうっていうやり方が全然通用しないんですよ。なんで最近の開発だと100人単位のメンバーで何億円もかけて数年ででかいものをバーンで作って、
例えば馬娘とか原神とかそういうものを出してそれがめっちゃヒットしたらその後もだんだん伸びていく。逆に一番最初のリリースでこけたらだいたいダメです。
なので負荷的な話、これはサーバーへの負荷の話ですけれども、そこの話をするとサービス即後にいきなりアクセス数がバーンって伸びます。
アップルとかグーグルに出してダウンロードしてもらって、例えば朝9時からゲームスタートってなったら朝9時からもうログインディクエストが大量に飛んでくるんで、
そこのピークタイムをうまく乗り切れるかっていうのがサーバーエンジニアだったりSREの腕のお店ところですね。
ほんとねここの最初の初動で失敗してしまうとユーザーがね、もうこのゲームめんどくせえ飽きたやめよみたいな話になってくるので、ここはね本当に重要です。
プログラミングのアプローチ
続いて設計のアプローチが違うというものですね。これねどういうことかというと、ゲームって皆さんいろんな機能あると思いませんか。
ミッションとかガチャとかモンスターとかモンスターを育成するとか武器を作る育てる、練成する、まあ装備する、ダンジョンに行く、ダンジョンで何かアクション起こすとか
ゲームによって様々あると思いますけれども、いろんな機能が作っては消え作っては消えしていくんですよ。なんなら途中でゲームの根本が揺らぐこともあるんですね。
例えばユーザーにあんまり遊んでもらいたいってなるとテコ入れをすることもあるので、そうするとこうな機能が入れ替わるんですよ。
でこれね問題なのがプログラミングです。我々がめちゃくちゃ丁寧に作った機能であっても使われなかったらすぐ捨てられて別の機能になります。
しかもゲームの機能って実際に作ってディレクターとかプランナーと呼ばれるゲームの企画を考える方が遊んでみて、やっとちゃんとした面白さがわかるんですよ。
なのでスピード感のある言語で結構作られることが多くて、例えばRubyとかPHPとかPHPとかで作られることがまあまああります。
また運用中もですね結構機能を新たにバンバン作りまくったりとか減らしまくったりということもよくあるので結構ね行動がカオスになりがちなんですよね。
Mixyで運用しているモンストとかねもう10年ぐらいは動いてますから相当な行動になってるんじゃないでしょうか。
ちょっと私は見たことないんであれですけど、やってた人の話を聞くと結構大変みたいな話は聞きますね。
はい、そしてユーザーの行動特性みたいなものがあると思います。昔のソシャゲだと例えば朝6時にデータが切り替わるとか朝9時にデータが切り替わる。
グローバルのゲームだと日本時間の0時に切り替わるんじゃなくて9時に切り替わる。まあUTCの0ですね。
でその時に一斉にユーザーのログインが飛んでくるみたいなこともあるんですよ。
まあその時にデータが入れ替わるんでガチ勢の人とかはその瞬間に切り替わって例えば新しいガチャが始まったから
引こうとかログインイベントが多いからもらおうとかそういうことをやるんですね。そうするとまあその朝4時とかね
よくわかんない時間にいきなりリクエストが大量に飛んでくるんでスパイクが発生するんですよ。
まあスパイクっていうのは急にリクエスト数が伸びて跳ねるっていうニュアンスですね。
その他にも最近の差し掛けは例えば運営側が生放送を行って新しいイベント出ますよとか
有名なユーチューバーの方とコラボしてそのユーチューバーの方がダンジョンに挑戦するとかで一気にゲームへのアクセス数が伸びたりとか
そういうこともあるので結構ですね読めない負荷の上がり方をすることが多いです。
またですね例えばランキングとかリーダーボードとか結構集計が必要なものとかも多いのでそういったバッジを定期的に動かすんですけれども
そのバッジをね何時何分までに更新しなければならないとかそういうものも結構頻繁にあります。
はい4つ目です。4つ目インフラの工夫が結構あげられます。インフラの工夫ですけど大きいゲームの場合結構グーグルクラウドを使うことが最近多いかなと思っていて
もうお決まりのパターンがあります。GKEプラスクラウドスパナーですね。GKEはKubernetesをグーグルクラウドが用意してくれてるやつで
バックエンドのスケーラビリティとデバッグ
クラウドスパナーはニューエスキューレと呼ばれる第三のSQLですね。何がいいかというともうGKEもクラウドスパナーも相当スケールするんですよ。
GKEは今はノード数が15,000ぐらいスケールするので1クラスターであってもコンピューティングリソースとしては相当稼げますし
クラウドスパナーに至っては事実上ほぼ無限に近い形でスケールできるデータベースの性能を持っているので
かつスケールインもできるんですね。減らせるんですね。そう考えるとゲームって先ほどスパイクがあるというお話をしましたが
一時的に計算量が必要だっていうシーン結構あるので需要を読んで先にGKEのノードとかボットを増やす
またスパナーのプロセッシングユニットを増やしてリードやライトの性能を上げるといったこともよくやりますね
そういった感じで結構ですね動的にリソースを増減させるケースが多いかなと思いますので
スケーリングに関してはいろいろとテクニックがあるかなと思います。また5つ目としてクライアント側のデバッグがすごい大変というものもあります
想像してほしいんですけれどもゲームっていろんなパラメーターがあるじゃないですか
ユーザー側がいじるのも大変なのにクライアントチームとかそれをチェックするQAチームってもっと大変なんですよね
これがマルチプレイのゲームになるともっと地獄で複数人とかネットワークの状況とかボスの状態とか
敵の状態とかなんかいろんなことを加味した上でいろんなテストをしないといけないのでしかも自動化しづらいんですよね
通常のHTMLの操作みたいなものだったらプレライドとかセレニウムとかそういうもので自動化できたりしますけど
ゲームの場合ってまあゲームの種類にもよりますけどアクションゲームとか私はやっていたのでそれを自動化するっていうのは
結構難しいというか私の時はそういうのは無理だったので人海戦術ですよね
かつクライアント側に結構リッチなデバッグ機能とかを入れて特定の状態に一発でできるデバッグ機能とか
特定のアイテムを99個に増やすとかそういうものを大量に用意して、でただデバッグコマンドを使うと
なんか再現しない本番のバグがあったりとか本当にいろいろな問題があってQAチームはめちゃくちゃ人も多かったりし大変そうでしたね
法的規制とクライアント連携
はい最後です最後はですねバックエンドインジニアの対応する範囲がめちゃくちゃ広いです
これは会社にもよるかもしれないんですけど少なくとも私がやっていた時はバックエンドはもちろんバックエンド側のコードも書きますし
クライアントチームとの挑戦をするしゲームの内容についてもまあいろいろ相談をするし
ソーシャルゲームの場合ってガチャとかオーブとかで稼ぐんですけれどもそうすると景品表示法っていうのがかかってくるんですね
どれくらいのものまでいくらとして売っていいのかとかいくらで売る場合どれくらいの価値マルを出すのかとか
ガチャでこういうガチャは禁止だよとかコンプガチャは禁止だよみたいなのがいろいろあるんですよ
だから法務的な観点でちゃんとコードが守られているかとかまた特許ってものもあるんですね
ゲームにおけるガチャの仕組みには各社が取っている特許があるのでそれを侵害しないようにガチャを組む必要があるとか
その度にこういうロジックで行こうと思うんですけどみたいなことを会社と相談して実装するとかそういうこともありました
またオーブの経費生産処理みたいなところもイファースみたいなものがあるのでどうやって集計してログ取って出せば経理のチームがちゃんと計算できるかとか
そういうことも考える必要がありましたしアップルとかねグーグルのプラットフォームとうまく連携して課金をするみたいなところで
まあいろいろひともんちゃがあったりとか ゲームってユーザーデータをうまく解析して改善に生かしていくっていうのが結構しっかりやらないといけない
ジャンルだったりするのでそれこそこういうアクションを取ったユーザーがこうしましたとか こういうキャラクターを持ってて何レベルのユーザーがこういう失敗を起こしますとか
あとはユーザーがどこをどうタップしたのかとかまあいろんなデータがあるんでそういうデータをうまく集めて データ解析チームの方に渡したりとか
そもそもどういうKPIに対してどういうログを出すべきなのかとかそういうところはね めちゃくちゃやらないといけなかったので各所との連携みたいなところを一点になる
ことも多かったですし またQAチームが使うようなデバッグツールとか管理画面とかそういうものを結構リッチに
作る必要もあったのでもう本当に仕事の量はめちゃくちゃ多かったですね ということで第一部ではソーシャルゲーム開発のバックエンドについて
普段のweb系のバックエンドの開発の違いについてご紹介しました 第2部はですね実際に作る機能について結構違いもあるのでその内容について
ご紹介できればと思いますので次回も楽しみにしていてください このポッドキャストはハッシュタグUITで皆様からの感想やコメント募集しております
またチャンネルの概要欄からGoogleフォームのリンク経由でのコメントも大歓迎ですので どうぞよろしくお願いします
ありがとうございました
