【CEDEC2016】「フェーズごとにやることを絞ったのが良かった」　DeNA佐藤氏が明かす『FFRK』におけるマルチプレイ開発

ディー・エヌ・エー（DeNA）<2432>の佐藤拓弥氏は「1000万人が遊ぶFINAL FANTASY Record Keeperにマルチプレイを導入した話」と題するセッションを8月25日の「CEDEC2016」で行ったので、その模様をレポートしておこう。このセッションでは、『FINAL FANTASY Record Keeper（以下、FFRK）』において、マルチプレイを導入したが、その時の開発の流れや開発中にあがってきた課題とその対処法などを紹介するものだった。

『FFRK』は、スクウェア・エニックスとの共同開発タイトルで、DeNAがシステム開発を担当している。リリースからまもなく2年を迎えるが、リリース以来の最大のアップデート項目となるのが7月29日に実装された「マルチプレイ」だった。これはプレイヤー4人が参加し、1人あたり2キャラとアビリティを持ち寄ってバトルで共闘するものとなっている。リアルタイムで同期を取り、FF最大の特徴であるアクティブタイムバトルが楽しめる。


 
まず、マルチプレイの開発に先立ち、動くモックを制作し、少人数で遊んでみるところから始めたという。できるだけ少人数・短期間で行い、ゲームのコアであるバトルの開発を行った。捨てコード上等で開発を行い、利用できるキャラやアビリティは限定した。最初に「何ができればいいか」と定義してそれに向けて開発を行った。動くようになったら、プレイして問題を洗い出し、再び開発に…というPDCAを短期間で回す手法をとったという。
 

チェックしたのは、マルチプレイが面白いかどうか。そして、システム面では、多人数が参加しても耐えられる同期通信サーバにすること、同期通信がネックとなってプレイ感を損ねないかのチェック、サポート可能な低スペック端末の確認を行った。この時点で「問題を洗い出すことができたので、対処法も決められたので後々の開発にはいい影響を与えたのではないか」と振り返った。
 

また、工数の面では、これまでの運営で積み重ねてきた大量のアビリティや必殺技、敵・味方のキャラクターなどのプロダクトが存在しており、これらをどの程度の期間でマルチプレイに対応させられるかも問題となった。試算したところ、200日～300日は必要であるという結果となり、システムなどでまとめて対応する方法がないのか、検討することにしたそうだ。

同期通信サーバは、どのサーバー技術を使うか、モックの時点で検討したそうだ。DeNA内にある技術から選択したが、WEB系ソーシャルゲームで使う「Skanda」、SHOWROOMで使われている「bcsvr」、マルチプレイのゲームで使われる「IRIS」があり、「bcsvr」を選んだという。「IRIS」は一見良さそうだったが、『FFRK』の仕組みの問題で実装難易度が高いと判断したという。「bcsvr」は、ルーム管理や排他制御などの機能はないが、ゲームサーバ経由で行うことにした。
 

システム構成と通信方式は以下のとおり。『FFRK』では、ゲームサーバーと同期サーバがつながっており、ゲームサーバー経由で全クライアントと通信する形式となっている。
 

 
本開発のフェーズでは、ゲームサイクルの開発を行い、マルチプレイを遊ぶ一連の流れを実装していった。ダンジョン選択とパーティ編成、ルームの作成・選択、ルームでのプレイヤー同士のマッチング、そしてバトルという流れとなる。ここでは、バトル突入時のロード時間の長さや、特定の組み合わせで発生する不具合などの問題が出てきたそうだ。
 
実際にマルチプレイ化をする際、マルチプレイには、マルチプレイ用の通信処理を追加するのみで対応できたそうだ。ホスト-ゲスト構成とし、ホスト側はシングルプレイと同じような動作とし、ゲスト側はコメントインプットとアニメーションの再生のみとした。
 

モック段階で判明していた課題としては、800種類を超えるボスごとのAIロジックの処理や、6000種類を超えるアビリティ・必殺技のロジック処理などがあり、200～300人日必要になるという試算だったが、バトルの処理に追加するだけで対応することができたとのこと。ただ、検証を行ったところ、数百件の不具合が発生し、個別に対応していったが、20日程度で対応が完了したという。
 

マルチプレイに関しては、ホスト-ゲスト構成にしているが、端末のスペックや通信環境によって、ホスト-ゲストの同期が十分にできず、ゲストが徐々に遅れていく問題が発生していた。これについては、シンプルにアニメーションの再生速度を早めて処理時間を短縮することで、ゲストがホストに追いつけるようにしたとのこと。
 

また、バトル突入時のロードの重さについては、バトルのときにアビリティのアセットのダウンロードを行っていたのが、低性能端末のダウンロード時間が長く、高性能端末が引っ張られてしまうために生じた問題だった。これについては、ルームでの編成中の時間に着目し、これを有効活用することで対応した。
 

 
マルチプレイは、クローズドβテスト、オープンβテストを経て、正式リリースとなった。クローズドβテストでは、3万5000人を対象に行なったが、当初の想定より発生した不具合が多かったという。本番環境がテスト環境よりもスペックが高かったために発生したバグや、ゲームサーバーの排他処理のバグなどもあったが、心配された同期サーバーは特に問題はなかったという。
 

続くオープンβテストは、正式リリースの1カ月前に実施した。クローズドβテストで発生した不具合の改修を行ったため、大きな問題はなかったという。この時、プレイしていておかしいと感じた点などをお問い合わせとアンケートとして集計した。例えば「メテオ」のアビリティを使うと一定時間固まる問題など「ゲームで遊べないわけではないが、ユーアーから見て違和感のある事象」などがあげられる。集計した結果を開発とQAに送り、QAが違和感のある事象を再現し、開発が改修して本番環境に反映していった。集計、再現、改修を分業したことで、それぞれ仕事により集中することができ、スピード感のある対応につながったという。
 

その後、無事リリースすることができ、ユーザーからも好評とのこと。現在、週に2回のペースでマルチプレイダンジョンをリリースしているという。ただ、端末スペックの際によるUXの悪化や、高負荷によるレスポンスの悪化、アセットの増加といった改善点があるという。
 

最後に、全体を見て、フェーズごとにやることを絞ったことがよかったのではないかと振り返った。モックの作成では最速で動くものを作ってチェックして本開発に移行できた。また、本開発ではモックで生じた課題に対応できていた。そして、リリースでは、ユーザーからのフィードバックで得た意見を汲み上げてゲームのクオリティを高めることができたという。「まだまだ課題がありますが、リリースして好評なので、今後も課題に対応しながらしっかりと運営を続けていきたい」と述べて講演を終えた。