ゲーム "消滅都市" 運用における理想と現実

2015/12/24

渡部晋司

みなさんこんにちは。GREE Advent Calendar 2015、24日目は消滅都市というスマートフォン向けゲームのメインプログラマを担当しております、渡部晋司がお送りいたします。クリスマスイヴではありますが、私は(すでに既婚者なので)恋愛云々のドキドキ感もなければ夫婦間でプレゼント交換もすることもなく、目下楽しみと言えば大きなチキンを食べることぐらい。食欲って怖いですね。

さてさて、今年もあと少しで終わってしまいます。お読みになっている皆様は、今年一年どんな一年だったでしょうか？私の方は消滅都市の運用を年初から年末までやっておりまして、それ以外のことは何もやってないといった感じでした。

本エントリはAdvent Calendarとしての記事ですから、本当は技術的な話とか How To 的なお話ができればよかったのですが、実は今年はCocos2d-x talks #2、CEDEC 2015、KYUSHU CEDEC 2015にて全力投球で登壇させていただきまして、正直言いまして少々ネタ切れ感があります…。と、いうことで！本日は「ゲーム "消滅都市" 運用における理想と現実」と題して消滅都市が今年直面した問題のうち、まだ外に出してない内容2つに焦点を絞ってお伝えしていきます。

※ 過去の講演内容についてご興味のあるかたはこちらをご覧ください。

Cocos2d-x talks #2 にて、Cocos2d-x 3.0を使ったゲーム “消滅都市” の開発事例
CEDEC 2015およびKYUSHU CEDEC 2015 にて、"消滅都市" 運用の一年

消滅都市ってどんなゲーム？

消滅都市は「ドラマ×アクション×RPG」をテーマにしたスマートフォン (iOS / Android / Amazon) 向けのゲームで、2014年5月末にリリースされました。

タップやスワイプの操作によってスクーターを操り進んでいく、いわゆる「ラン系」に分類されるアクションゲームのパートと、後ろで「タマシイ」と呼ばれるユニットが戦い合うRPGの部分を併せ持った感じの作りになっております。おかげさまで運用開始から1年半ほど経過いたしまして、累計で555万ダウンロードを突破することができました(記事執筆時現在)。

技術的な要素で言うと、クライアント側は C++ 11、Cocos2d-x、そのほか各種内製のシステムで構成されており、サーバ側がphp、silex、MagicSpice、cascade、MySQLによって構成されています。

理想と現実

ありがたいことに一定のお客様から評価されましてここまで続けて来ることができた消滅都市ではありますが、順風満帆だったかというと全然そんなことはなくて、運用手法にしてもサービスの質としても理想と現実の間で結構苦しんでいたりします。なるべく現在の状況を理想的な状態へと押し上げていけないかと日々苦心しているわけではありますが、なかなか変更することができない部分もあったりするのが正直なところです。

しかし、全てが理想的に回ってる開発チームなんて存在しないはずですし、「目指すべき理想的な状態」というのもチームの目標やメンバー構成、ゲームを取り巻く周囲(マーケティング的な部分など)によって日々変化する部分もあるかと思います。そういった理想的な状況に、現実を近づけていくことをやり続けていかねばなりません。

データデプロイの話

データデプロイとは

多くのスマートフォン向けゲームが採用している仕組みとして、「アプリのバージョンアップを行わなくても、サーバのデータを更新することでキャラクター等のパラメータを更新することができる」というものがあります。このような仕組みを採用している理由は、スマートフォン向けのアプリケーションをリリースする場合にはそのプラットフォーム運営者に審査を行ってもらう期間を待つ必要があり、その期間無しでゲームを更新できるようにするためです。消滅都市でも同様の仕組みを持っていて、ゲームサーバ上にデータをデプロイすることで全てのゲームクライアントに対してデータの追加や変更を提供することができるようになっています。消滅都市では(特殊なことはやっていないのですが) 以下の手順によってサーバ上のデータを更新しています。

デプロイ作業の理想と現実

データデプロイ自体の仕組みは今までの運用で何度も行われてきており、毎回さほど事故もなく終わるのですが、消滅都市におけるデータのデプロイ作業は大きな問題として長い時間がかかるというものがあります。データをサーバにデプロイするにあたってかかっている処理時間が長いというわけではなく、単純にデータの制作やステージング確認作業といった部分に多くの時間がかかっており、定時内に作業が終わることは稀、下手をすると日付が変わるということもありました。さすがにこの状況が続いてしまうと体力的に疲弊してしまっていくので、なんとかしてデータデプロイの時間を短縮して進めることが求められました。

お知らせ自動生成

消滅都市では「お知らせ」を表示するためにWebブラウザのコンポーネントを使用しており、画面上に比較的自由度高く様々な情報を表示できるようにしています。しかし、サービスインしてからしばらくの間は、このお知らせの内容はゲームで利用しているデータと完全に独立したものになっており、手動で html を入力してあげる必要がありました。もしもこの部分が間違っていた場合には(特にガチャの内容等に誤りがあった場合)、返金対応等が発生してしまうため特に注意して作業する必要がある部分です。そのため、最終的なリリースチェックでも常に注意深く何度も確認する必要がありました。

この部分でかかっていた時間を短縮するため、「お知らせ」画面でよく使うパターンの記述方法についてはテンプレート化し、実際にゲームで使用されているデータを元にして「お知らせ」ビューが生成されるようにすることで入力作業と確認作業の省力化をはかりました。

消滅都市 ITサポートデスク

デプロイにかかる時間を短縮するという目的で新しく作られたものに「消滅都市 ITサポートデスク」というものがあります。これは、データ制作を行うスタッフ(企画、アーティスト等)が様々なことで困ったときに、その分野に詳しい人がヘルプするという仕組みです。実はデータ制作をしている最中、ちょっとした問題で躓いてしまいデータ制作に遅れが出ててしまっている(結果的にデプロイの時間も遅くなりがち)、という声を元にして用意されました。たとえば、

バージョン管理システムで競合が発生してしまったけどどうやって解決すればよいのか分からない
何もエラーを出さずにゲームがクラッシュしてしまう、多分データが悪いのだと思うけどどこが悪いのか分からない
データを作ってみたけど、変換ツールによってエラーが検知されてしまい、その意味がよく分からない
(ゲーム内のお知らせ画面で使用する) スタイルシートを変更してみようと思うけどどうやればいいのかよく分からない
デバッグメニューで出来ないことがあり、改良して欲しい

などといった事柄です。これらの問題を気軽に聞ける場所、ということで社内チャット上に用意して運用を始めました。ゲーム自体の問題からパソコンの操作方法などなど悩む前に気軽に聞けるという空気感が好評で、毎日いろんな質問と答えが流れています。

プログラマも常にあれこれ仕事してるかと言うとそんなこともなく、コンパイルしてる間とか若干ヒマだったりするのでその合間に軽くチャットを覗いて質問に答えているので誰かしらがいてくれる感じになっています。特に担当や当番を決めて運用するようなことはしていませんが問題は起こっていません。

※いや、「若干ヒマ」とか書きましたが真面目に働いてますのでご安心ください >> 上長各位

単体テストの話

単体テストとは

プログラムの品質を担保しつつ変更をやりやすい状態を保つのに最も効果的な手法の１つが単体テスト(ユニットテスト)を用意することかなと思います。単体テストというのはプログラムを構成する各モジュールが入力に対して正しい振る舞いをするかどうかを調べる手法です。特にテストケースを記述して各モジュールが正しく動作するのかどうかを自動的にテストできるようにしておけば、何度でも繰り返し確認ができるため、最終的にシステムの変更に強いプログラムが出来上がります。

消滅都市の開発チームも、開発開始当初はいわゆる意識高い系であったため、クライアント側もサーバ側も単体テストを用意しながら開発を進めていくというわりと理想的な状態でスタートしました。しかしながら、結局のところゲームの仕様というのは一発で決まるようなモノではなく、右往左往蛇行運転しながら最終目的地に向かっていくわけで、その途中でクライアント側の単体テストは無残にもメンテナンスされなくなってしまいました。これらのコードはただのゴミとしてリポジトリの中に残り続けることになり、ファイル全体を #if 〜 #endif で囲むなんとも残念な状態が2年近くも続きました(このあたりで、読者の方から「あるある〜〜ｗｗ」とか言っていただけるとすごく気がラクなのでありますが)。もちろんこれは当初設定されたサービスインまでの開発期間を考えれば妥当な判断ではあったのかなと思っています。サーバの方だけは単体テストが維持され続けたのでその点はよかったかなと思います。

単体テストの理想と現実

実際に消滅都市の運用が開始されると、新しい企画がどんどん持ち上がってはものすごい勢いで実装されていき、システムがどんどんと複雑化していきました。もちろんプレイヤーの皆さんに楽しんで頂けるようにと思ってやっていることなので企画が持ち上がること自体は悪いことではないのですが、技術的な受け入れ体制があまりうまくいっていないまま追加していったところもあり、結果的にデバッグの期間にそれらのしわ寄せが来るみたいなことになってしまっていました。

買いきりパッケージ型のゲームの場合は、プログラムとデータがほぼほぼ揃い、追加されるものが最小な状態になってからデバッグ作業に入るので、そこの時点でしっかり全てをチェックすればあとは出荷しても問題ないということになります。しかし、サーバ側のデータデプロイやクライアントアプリのバージョンアップによって日々更新され続けていくゲームではこの手法は合いません。というのも、プログラム側のバージョンアップのたびに全てのデータが正しく動作するかどうかを確認していては新しいイベントの更新タイミングに間に合わなくなってしまうからです。例えば、イベントの都合上アプリのバージョンアップのタイミングが一ヶ月に一度程度は必要であり、かつ全てのデータの確認が一ヶ月程度かかるとなると、開発作業として取れる時間がほぼ0となってしまいます。必然的に買いきりパッケージ型でないゲームは毎回行われるデバッグの期間は短く短く効率的にというのが求められてきます。

理想に近づけていく

運用開始から一年半、開発開始から数えると二年を超えたこのタイミングで今更ではありますが、もう一度クライアント側にも単体テストを入れてデバッグ作業の省力化に取り組んでいます。消滅都市ではメインで使用しているIDEがXcodeであるということもあり、単体テストのフレームワークは XCTest を使用しています。IDEに統合されていてテストの開始がすぐ出来るのがよいですね。

もちろん、今まで単体テストの存在すら意識せずに書いてきたコードがいきなり単体テスト可能であるはずもなく、まずはテスト可能な状態にするまでに結構な時間を要しました。おそらく、このあたり早く取り組めば早く取り組むだけコスト安くできるかと思いますので、思い立ったが吉日、いろいろとツラくなる前に環境を整備していくのがいいかなと思います。

反省

消滅都市チームの開発期間やら開発リソースを考えると、

サービスインまでのところで、クライアント側の単体テストが作れないのはまぁしょうがないかなと思われるのでリリース前に行うテストで全体をデバッグすることで問題を洗い出して修正する
ある程度ゲームを運用してみて、ゲームが長く続きそうな手応えが感じられたところで、すでに固まりきった仕様に対してクライアント側についても単体テストを入れていく

という形でゲーム開発のスケジュールを引くのがよかったのかなぁと今にして思っております。とは言え後悔先に立たずと言いますか…　このあたり難しいなと実感しました。

終わりに

いかがでしたでしょうか？お読みになられてる方に対して少しでもお役に立てれば幸いでございます。特に、チャット経由でチームメンバーがいろんな質問に答えてくれる「ITサポートデスク」は導入コストが非常に安いわりにいい感じで運用ができていますので、スマートフォンゲーム開発に限らずいろんな分野の方にオススメかなと思います。興味を持たれた方はぜひ一度やってみてください。

さてさて、一ヶ月近くに渡ってお送りしてきました GREE Advent Calendar 2015もいよいよ明日が最終日。25日目は堀口真司さんです！