【CEDEC2014】大ヒット中のスマホ向けMMORPG『剣と魔法のログレス いにしえの女神』を支える技術とは。開発社Aimingが明かす舞台裏

2014年9月2日～4日に、パシフィコ横浜（神奈川県）で国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2014」（以下、CEDEC 2014）が開催。

初日（9月2日）では、スマートフォン向けMMORPG『剣と魔法のログレス いにしえの女神』における技術背景の講演が実施された。スマホアプリでありながら、MMORPGという巨大なコンテンツを、いかにしてアプリ内に詰め込んだのか。クライアント/サーバの両サイドに関する技術面の内容を取材。

 

■スマホの本格MMORPGアプリを支える技術

 
そもそも『剣と魔法のログレス いにしえの女神』は、元となるPCブラウザ版をスマートフォン端末へ最適化したネイティブアプリで、数分から遊べる手軽さを実現したMMORPGである。配信はマーベラス<7844>、開発はAimingが担当で2013年12月にリリース。

ジョブシステムや多彩な装備、スキルを駆使したコマンドバトルなど王道のRPGでありながら、部屋の中ではもちろん、外出先や移動中に片手で友だちと一緒に冒険やバトルが楽しめることが人気に火がつき、現在300万ダウンロードを達成、さらにApp Store売上ランキングでは最高4位を記録（関連記事）するなど、スマホ向けMMORPGで大成している数少なく作品である。

さて、今回登壇したのは、Aimingの開発グループ・ソフトウェアエンジニアである神部公輔氏、山藤智之氏、西村哲弥氏の3名。それぞれクライアントとサーバ側の観点から同作の成り立ちについて解説してくれた。
 

はじめに『剣と魔法のログレス いにしえの女神』における開発環境を紹介。同作は、Aiming社内において「PCブラウザ版をスマートフォンに移植するだけなので、なるべく早めのリリースを目標」とし、開発ツール「Cocos2d-x」を用いて2012年冬に制作がスタートした。ゲームクライアントはWindowsでVisual Studioを利用して開発し、サーバはVMwareなど仮想マシンで開発。WebサーバにはPythonを利用、開発のフローはJenkinsなどを利用している。
 

本作は、PCブラウザ版が先行して動いているため、サーバを使いまわすことが可能とのことだが、スマートフォンアプリのクライアントは別途の新規開発になってしまうようだ。なお、MMORPGのクライアントに求められる要件として、「TCP通信が可能」「iOS/Androidをターゲットしたクロスプラットフォーム開発が容易」であることが開発現場では挙げられた。

さらにPCブラウザ版用に作成された豊富なFlashアニメーションデータを再利用するため、大量の2Dオブジェクトが表示可能であり、かつそのうえで快適なプレイが保証される必要もあったとのことだ。これらの要件を満たすために考えた末、ゲームエンジンは「Cocos2d-x」が最も相性がいいのではないか、と今回の採用にいたったという。

ここで「Cocos2d-x」のメリットについて解説してくれた。メリットには、大きく「クロスプラットフォーム開発のサポート」「2Dゲームフレームワーク」「ソースが公開されている」という技術的な解決ができないという状況を回避してくれる3つの要素を挙げた。対して、「Objective-CベースでC++に移植されているため、C++の文化と違う部分でコーディングが面倒」「UIのサポートが弱い」などのデメリットも存在。なかでもUIに関しては、コンテンツが多く複雑なUIを必要とするMMORPG作品のため、様々な面で事足りないことに直面したようだ。

そして実際に「Cocos2d-x」を使用したことにより、MMORPGクライアントにゲームのデータをダウンロードするパッチシステムをはじめ、UIコンポーネントの追加、Flashアニメーションプレーヤの作成、内製のネットワークライブラリの組み込みなど、多様な追加システムが実装できたという。
 
ここからは、MMORPGに必要不可欠なリアルタイム通信の要素について。おもな要素としては、「TCP通信」「RPC（remote procedure call）」のふたつが存在。TCP通信は、データを確実に転送させるための通信規格の役割で、大きなデータを確実に届けることが可能。また、ゲームに参加しているホスト同士が、継続的に通信し続けるために利用される。RPCは、クライアントの要求に対して、サーバが結果を返すときなどに用いられる。内製ネットワークライブは、これらふたつの通信サポートが適応されていて、PCブラウザ版でも同様のものが利用されている。

続いてゲームアセットとゲームデータとの違いを解説してくれた。ゲームアセットはクライアントが読み込む用のデータ、音楽や画像、アニメーションなど、基本的にサーバが知り得なくていい情報が該当する。逆にゲームデータは、スクリプターやレベルデザイナーが作成したデータをサーバが読み込む役割を担っている。なお、ゲーム進行の情報やシステムを駆動するアルゴリズム（ゲームロジック）は、おもにサーバ側に実装されており、クライアントにはほぼゲームロジックは実装されていないという。処理するものといえば、クライアントで完結するものか、クライアントで分散処理可能なものくらいとのことだ。

例として、本作ではタップした場所に経路探索を施して移動するようにアルゴリズムが設定されているのだが、この経路探索はクライアントで行っているという。まずクライアントで全ての経路を計算して、サーバに送るのは直線で移動できる区間、そして常に経路を移動する間に送り続けて、その直線を単純にサーバが嘘の移動経路を言っていないかをチェックしている。クライアントで分散処理して、サーバに負荷を与えない形でゲームロジックを持つこともあるとのこと。

 

■サーバの概念図とMMORPGの肝となるチャットシステム

ここからはサーバ構成について解説された。下部は1ワールド分のサーバ構成の概念図となる。Accountはユーザーアカウントの管理、Databaseはゲームデータの保存、back-endはフロントエンド間のデータ同期、Zoneはゲームサーバ間のデータ転送、Gameはゲームサーバ、Clientはゲームクライアントとなる。特徴的なのは、WebAPIである。ゲームサーバに関しては、比較的容量の小さいデータを断続的に飛ばすための経路だというふうに扱っており、大きなデータをクラアインからとる場合にWebAPIサーバが用いられるようだ。概念図を見て分かるように、データは循環するような動きになっている。
 

物理的なサーバ構成の図としては、下部のような形で落とされていくようだ。赤く囲まれている部分は、負荷が集中してもハードウェアを足すことにより、スケールアウトができるようにしている箇所。これらの場所に関しては、ユーザーが増えて負荷が上がっていくと、負荷分散することができるような作りになっている。「冗長化は可能な限り行っている。やらない（やれない）ところは諦めている」と山藤氏。また、データベースは垂直分割（機能毎に分離）して、水平分割（ユーザー単位分割）は行っていないとのこと。
 

次にMMORPGの肝となるチャットシステムについて。チャットシステムに対して定義された開発現場の要件は、「可能な限り過去までさかのぼってログを見れる」「自分がオフライン中の間に他プレイヤーが発言したメッセージもログで見れる」「グループチャットができる」の3点だ。「可能な限り過去までさかのぼってログを見れる」は、データベースに一ヶ月分程度のログを保持することで対応。「自分がオフライン中の間に他プレイヤーが発言したメッセージもログで見れる」では、データベースに保存されているため、クライアントからWebAPI経由で取得する方法を採用。
 

なお、「グループチャット」を実現するためには、発言した瞬間に内容がバックエンドに飛ぶような仕様になっている。これは同じグループに所属しているプレイヤー全員が、受け取った一台のサーバに接続しているとは限らないため、一度発言の内容はバックエンドに向かって飛ばしているという。
   

■リリースまでに起きた問題と残された課題

最後に開発中で直面した問題と、その解決について紹介してくれた。問題のひとつとしては、やはり「3G回線でのゲームプレイが可能か」である。常時接続型のMMORPGのため、弱い接続の回線でプレイしているユーザーも当然存在するが、果たしてどのように解決したのか。しかし、これが意外にも具体的な対策はなく、「テストプレイの段階でチューニングを重ねた結果、特に大きな問題なく動いた」と神部氏がコメント。ただ、回線切断は避けられないため、これについてはPCブラウザ版のページリロード対策のノウハウがほぼそのまま使われたという。

そして、今後の課題として、期間を短くして突貫で開発した部分もあるためか、クライアントのパフォーマンス・チューニングに対応していくことを挙げた。なかでもMacの描画がフィールド画面では、3割から5割の負荷を占めており、ここの部分を多角形のポリンゴ化を施して、無駄な部分を描画しないでピクセルなどで対応中という。また、アバター描画の最適化にも余念がない。イベント中には、ゲーム画面に数100人が表示されてしまうため、アバターだけで処理を食ってしまうことになる。これに関しては、かなりチューニングの余地が残されていることで対応中のようだ。

これらの問題点をチューニングすることで、電池消費量の改善となり、ひいてはユーザーの快適なプレイ環境にも繋がる。次いでクライアントの安定化に対応することで強制終了の改善と通信料の削減を目指すようだ。「開発チームの目標としては、強制終了を無くして、キャリアの通信制限にかかっても遊べることを目指したい」と神部氏がコメント。これらを実現するために、サーバ１ワールド毎の同時接続数の許容量を増やす（約1.5倍）ことも視野している。

神部氏は、講演の最後に「サービス開始して1年も経ってないタイトルだが、今後も技術的な挑戦とノウハウを溜めていきます。また、今回のような講演ができる場があれば、もっと深く面白い話ができると思います」という言葉で講演を締めくくった。