『モンスト』の高難易度コンテンツ、その開発も高難度？あらゆる“メソッド”が学べるセミナー「THE METHOD ＃12」

司会はモンスト事業本部・事業支援室の三瓶が担当しました。

アプリコードからインフラまで！裏側全体を担当
━━上平さんの業務範囲は、どのようなものなのでしょうか？
上平：私の場合、アプリコードからインフラまで裏側全体を担当しています。もう少し具体的なイメージを持ってもらえるよう、案件ベースでお話していきます。

【1】新機能開発の案件
新しいコンテンツが入る際に必要となるサーバー側の実装です。特定のクエストをクリアすると条件に応じてアイテムがもらえる「トレジャー9」やIPに応じたコラボイベントなどがそれに当たります。

【2】既存のコンテンツの改良
既存のコンテンツをさらに改良していく際に必要となるサーバー側の実装です。たとえば、ストック機能の拡張。特定の時間だけ遊べるクエストをストックして好きなときに遊べる機能があるのですが、この機能変更を担当しました。

【3】その他
開発作業で使うツールの改修、インフラ周り、DBやインスタンスなどクラウド周りの対応も、サーバーグループの仕事になります。

「未開の大地」における階層の拡張、問題点はサーバー側にあった
━━具体的な案件では、どのような動き方をしているのか教えてください。
上平　今回は、過去に手がけた案件から「未開の大地の拡張」について詳しく話をしていきたいと思います。
前提の話になるのですが「未開の大地」とは、『モンスト』において毎月定期的に開催されるイベント。挑戦できる階層がどんどん上がっていく点が大きな特徴です。最初は1階から10階まで遊ぶことが可能で、それらを全てクリアすると、次の月に開催されるイベントでは1階層上の2階から11階で遊べるようになります。さらに、これも全てクリアすると、次の月は3階から12階で…と挑戦できる階層があがっていきます。
もともとこの企画は30階で終了する予定だったのですが、ユーザーから好評だったことから階数があがり、現在は34階まで。ここからはその階層の拡張について詳しくお話していきたいと思います。

上平　「階層を拡張していこう」となったとき、問題になったのはサーバーのDBです。クリアデータの管理方法が理由で、32階までしか保存ができない状況にあったんですね。
そもそもの話になりますが、『モンスト』ではクリア情報をステージのグループ単位で管理をしています。一つの敵に対して複数の難易度を用意していて、そのステージを集めたものがステージグループという考え方です。以下の図を見ていただくと分かりやすいと思います。

上平　この例では、敵であるプリンセス・ノッコに対して、それぞれ「極」と「究極」のステージがあり、それらを合わせたものが「ステージグループ」になります。そしてクリア情報管理テーブルでは、completeカラムが実際にクリアしているかの情報を、ステージ毎にbitで保存しています。ステージ1つ毎にcompleteのbitが対応していて、この例では1bit目が「極」に、2bit目が「究極」に対応しているという見方です。「未開の大地」も同様の方法でクリア情報を管理しているんですね。

上平　そして、このbit管理している「completeカラム」は32bitの型。つまり、33個以上の情報を保存することができない。結果、32階までしか設定ができずにいたのです。今回の開発案件「未開の大地」の拡張には、この問題を解決する必要がありました。

解決方法は、複数のレコードを使って「未開の大地」の情報を管理
━━どのような解決方法が検討されたんでしょうか？
上平：あらゆる検討を進めていく中で、2つの解決方法が見えてきました。一つは「クリア情報テーブルのカラムを拡張し、32より多くのステージ情報を持つ方法」。もう一つは「複数のレコードを使って未開の大地の情報を管理する方法」です。

上平　単純な解決案としては、前者の「クリア情報テーブルのカラムを拡張し、32より多くのステージ情報を持つ方法」。これができればカラム拡張以外は特に対応は必要ありませんので、非常にシンプル。しかし、この方法は実際は使うことができなかったんですね。
理由は、このテーブルには「未開の大地」以外に、全てのステージのクリア情報を持っているため、1ユーザーに紐づくレコード数が非常に多い…。当然ながら、レコード数の多いテーブルの構成を変えようとすると時間を要して実現がむずかしかったというわけです。

最終的には、二つ目の「複数のレコードを使って、未開の大地の情報を管理する方法」となりました。以下の図のようなイメージで、「未開の大地」だけ複数のレコードを使ってクリア情報を管理していきます。

影響範囲を確認しながら、一つひとつ問題に対応
━━「複数のレコードを使って、未開の大地の情報を管理する方法」はスムーズに進んだのしょうか？
上平　いいえ…。クリア情報が複数のレコードをまたぐことでの問題点がありました。
「未開の大地」の制覇、つまりその月に全ての階層をクリアしているかは、複数のレコードを跨いで確認する必要があったんです。たとえば、30階から39階まで挑戦可能な場合、前のレコードを3bit、後ろのレコードを7bit確認するといった感じです。しかし、クリア情報のリセット処理は各レコード単体で発生するので、実際には制覇しているのに制覇していないような扱いになってしまうケースが起きていたんです。この問題をなんとか解決する必要がありました。

上平　そこで行ったのが「クリア状況を管理するテーブルとは別で、制覇を示すカラムの追加」です。たとえば1階から10階まで挑戦できるユーザーにおいては、10階をクリアしたタイミングで、そのカラムに「制覇」の情報を保存していきます。これによって、制覇しているかを逐一チェックする必要がなくなると考えました。

━━なるほど…。イベントのように、開発も高難易度ですね。
上平　まだまだ問題点がありまして。
この「completeカラム」の追加もちょっと複雑でした。カラムを追加したタイミングでは全てデフォルト値ではいっていて「制覇していない」ことになっているのですが、本番環境ではすでに制覇済みのユーザーも沢山いるはず。つまり、不整合が発生してしまっていたんですね。解決策として、本番環境にスクリプトを適用してクリア情報管理テーブルの値を見て、制覇済みである場合は「新しく追加したカラムの値を更新する処理」を適用していきました。

上平　他にも、全クリア報酬の処理、全ての難易度をクリアするとオーブがもらえる処理など、既存機能に影響がないかを確認。それから、クリア情報を見るミッションが適切に動作するかも調査していきました。影響範囲を一つひとつ確認しながら、問題がありそうであれば修正していった流れです。

企画変更は、よくある話。柔軟に対応していく

━━最終的にはどのような流れで拡張処理が行われたのでしょうか？

上平　「未開の大地」の拡張処理の流れは以下のようになりました。

【1】メンテナンス中にカラム追加作業。制覇済みカラムを用意。
【2】「未開の大地」イベントが開催されていないタイミングで、スクリプトを適用。制覇済みかの情報を【1】で用意したカラムに移動。
【3】次のメンテナンスで、複数のレコードで「未開の大地」のクリア情報を管理する方式を適用

この工程を経て、「未開の大地」の拡張が完了しました。今回のように、ゲーム運営をしていく中で企画内容が変更されるケースはよくある話だと思います。ここで大事にしたいのは、ユーザーに喜んでもらえるゲームを開発することです。ユーザーの反応を見ながら、“もっと続けていこう”と、チームが一丸となって開発に取り組んでいけるのは、ある意味、エンジニアとして幸せな環境じゃないかと思っています。

質疑応答
最後は、質疑応答です。視聴者のみなさんから寄せられた質問にもリアルタイムで回答しました。

Q：『モンスト』は長く運用しているゲームだと思うのですが、ユーザーの反響によって、最初の実装から変わった例はありますか？
上平　以前「コラボ企画で、経験値をたくさんもらえる案件」がありました。こちらは、もともとコラボだけで終わらせる予定だったのですが、ユーザーから人気だったこともあり、継続が決定。『モンスト』の機能に追加していくことになりましたね。ユーザーの反応を見ながら、新しい企画が動き出すケースは多くあります。

Q：サービス全体に関わる部分（ユーザーのアクセス増加によるハードなどの負荷処理）の業務あたりも担当されているのでしょうか。
上平　私はソフトウェア領域になるのでハードについては担当していないですが、グループ内の別のエンジニアが担当していますね。
王：最近手がけたところでいうと、新しい機能が追加されて負荷が集中した場合、バックエンドのデータを分散する必要があるのですが、そこもサーバーグループの担当。一台のものを複数台に分散する対応を、物理的・ロジック的なところから携わりました。

Q：ゲーム開発でRubyはあまり聞かないですが、選んだ理由はありますか？
王　ここに関しては、歴史的経緯も大きく関係していますね…笑。でも、一ついえるのは、ゲームの特徴にあった開発環境を選択していることです。
上平　「ゲーム開発でRubyはあまり聞かない」との話をいただきましたが、以前勤めていたソーシャルゲーム開発の会社でもRubyでした。確かに多くはないけれど、少なくもない。そんな印象を個人的には持っています。

Q：コラボなどで新しいシステムを構築する場合は、どのくらいの期間をかけて制作するのでしょうか？また企画段階から開発の方も入っていますか？
王　案件の規模によって、期間は変わってきますね。大規模なコラボだと開発期間だけで2ヵ月ほど要します。平均でいうと1ヶ月くらいの案件が多いと思います。
あとは、大きな案件になると開発より前に「相談」されるケースがあります。企画の方から「こういう感じにしたいんだけど、作れます？」と話が合って、それに対して「作れるけど、負荷的な問題がある」「ここを回避すれば、やれそう」と議論していきます。なので、「企画段階から開発の方も入っていますか？」という質問に対しては、Yesと言えると思います。

Q：『モンスト』のサーバーはどのような構成ですか？
王　「マルチクラウド＋データセンター」のハイブリット型です。主流のクラウドは一通り使っていて、そこに自社のデータセンターを構えている体制です。クラウドには緊急性が高かったり、自由に設計する場合に利用していて、自社のデータセンターには重要なデータを置いています。自社自慢のようになりますが、ミクシィのサーバーは性能が高いです(笑)。

最後に
今回登壇していたグループマネージャーの王とエンジニアの上平のやり取りを聞きながら、サーバーグループの“和気あいあい”とした雰囲気が感じられたように思いました。全社的にもフルリモートの働き方となり、リアルで顔を合わせる機会は減ったとのこと。上平に関しては住まいは奈良で、滅多に出社はしないそうです。しかし、物理的な距離に関係なく、日々のコミュニケーションが積み重ねられていることが、しっかり伝わる時間だったのではないでしょうか。

※イベントページはコチラ

今後も様々な“メソッド”に焦点を当てながら、開発・制作ノウハウなどをお届けしていきます。次回もお楽しみに！