モバイルでゲームは少人数開発へ回帰するのか。「TERRA BATTLE」開発座談会レポート。え，プログラマも各デザイナーも1人ずつ？　

　2014年10月9日にリリースされ，1か月経たずに100万ダウンロードを達成したミストウォーカーの新作RPG「TERRA BATTLE」（iPhone / Android）。同タイトルは，坂口博信氏や植松伸夫氏といった，日本のゲーム業界におけるビッグネームが関わっていることで注目を集め，またゲーム自体も挟み将棋をベースにしたシンプルなルールである半面，属性の相性や連鎖をきちんと考慮しないとクリアできない奥深さで高い評価を得ている。

　そんな「TERRA BATTLE」が，Unityを使って開発されたことは，これまであまり報じられていない。おそらく本稿を目にして初めて知ったという人も多いのではないだろうか。
　4Gamerでは，「TERRA BATTLE」のプログラマであるミストウォーカーの大野浩司氏と，ユニティ・テクノロジーズ・ジャパンの伊藤 周氏および高橋啓治郞氏の3名による，Unityを使った同タイトルの開発に関する対談を取材する機会を得たので，その模様を以下にお伝えしよう。

左からミストウォーカー大野浩司氏，ユニティ・テクノロジーズ・ジャパン 伊藤 周氏，高橋啓治郞氏

少人数開発のメリットは，なんといっても意志決定の速さ

伊藤 周氏（以下，伊藤氏）：
　実を言うと，Unityを使って「TERRA BATTLE」を開発していただいていることは，あとから知ったのですが，あまりそのことを前面に打ち出されてはいませんでしたよね。僕らも，「これはUnityかな？　それにしては動作が速いな」と思っていたくらいでして（笑）。

大野浩司氏（以下，大野氏）：
　Unityを使用しています。とくに難しいことはしていないんですけれど（笑）。

伊藤氏：
　それは素晴らしい。今回はそういったことも含めて，Unityを使った開発について，大野さんが感じたよかった点と悪かった点について率直にお話しいただければと思います。
　事前に伺ったお話では，まず「少人数での開発なので，意志決定が速いこと」をよかった点に挙げられていましたが。

大野氏：
　はい。最初にリリースしたバージョンは，プログラマが1人という体制で開発を進めました。最近，ようやくプログラマが増えて，今は2人体制になりました。

伊藤氏：
　すると，ほぼ大野さんお1人で作っていたわけですね。全体のチーム構成は，どうなっているのでしょう。

大野氏：
　各パートとも，社内ではほぼ1人ずつで，プログラマ，企画/ゲームデザイナー，キャラクターデザイナー，その他グラフィックス全般（エフェクト/UIなど）のデザイナーといった感じです。

高橋啓治郞氏（以下，高橋氏）：
　サーバー側のプログラムも，大野さんがお1人で組まれたんですか。

大野氏：
　そうです。最初はそんなつもりはなかったんですけれど。

伊藤氏：
　個人制作ならともかく，そこまでプログラマ1人でやるという話は，いまだかつて聞いたことがないです。

大野氏：
　そもそも，最初はオフライン専用として作っていたんです。それから何となく「今どきの感じにしないと」という雰囲気になり，サーバーを使った運営タイプのゲームになったんです。そこで新たに人材を導入すべきかどうか考えたのですが，さまざまな事情で1人でやることになりました。

伊藤氏：
　大野さんは，「TERRA BATTLE」で初めてサーバーのプログラムに関わったわけですよね。前職では「ファイナルファンタジー」（FF）シリーズに携わっていたとか。

大野氏：
　そうです。前の職場（スクウェア・エニックス）では，主に3Dエンジンの開発に携わっていました。

伊藤氏：
　つまりデータベース（以下，DB）やプロトコル通信などを扱うのは，まったく初めてだったと。

大野氏：
　社内用のツールでは触ったこともありましたが，製品としてに出すものでは初めてです。

高橋氏：
　やっぱりすごい話ですね。
　それでは「TERRA BATTLE」の開発を始めたのは，いつ頃だったんでしょう。

大野氏：
　2013年の6月です。

高橋氏：
　そうなると，実質の開発期間は1年と少しですよね。しかもサーバー側の開発も含めてですから，同じプログラマからすると「本当に？」という気持ちです。

大野氏：
　まあ，いろいろ問題もありましたので。

伊藤氏：
　開発はリリース日を定めて進めたんでしょうか。それとも出来上がってから出すつもりだったんですか。

大野氏：
　当初は，2014年春のリリースを目標としていました。そもそも最初は，もっと軽いアプリを想定していましたから。ただ，途中でどんどん欲が出てきて，いろいろ追加していくうちに2014年の秋（※2014年10月9日に配信開始）になってしまったわけです。

伊藤氏：
　確かにリリース後の大きな不具合もありませんし，開発を急いだ印象はないですね。

大野氏：
　デバッグはきちんとやりましたから。

高橋氏：
　そうした中で，少人数開発だと意志決定が速いと感じたのは，やはりFFシリーズなどの大規模開発と比較してということでしょうか。

大野氏：
　そうです。大きなプロジェクトだと，何か大きな決定をするときは朝からミーティングが開かれ，やっと終わったと思ったら夜になっていた，なんてこともあったんです。
　「TERRA BATTLE」では，隣にいるスタッフと「じゃあ，こうしよう」と決めて，その場で作るみたいな感じでした。

伊藤氏：
　最初はトライアンドエラーが多かったと聞いているのですが。

大野氏：
　むしろ最後までトライアンドエラーばかりですよ（笑）。今回は，きちんと仕様を決めずになんとなく作っていましたから。

伊藤氏：
　大野さんはディレクターも兼任されているんですよね。そうなると，自分で仕様を決めて，自分で実装するというスタイルなんでしょうか。

大野氏：
　流れとしては，まず坂口（坂口博信氏）が，ああしたい，こうしたいというリクエストをメールで送ってきます。それを読んで「じゃあ，どうしようか」と考えて作り，坂口に見せるという感じです。

伊藤氏：
　坂口さん自身もUnity上でテストプレイされるんですか。

大野氏：
　いえ，僕のほうで毎日iOS用のビルドを作って坂口に送っていました。

伊藤氏：
　まさにラピッドプロトタイピングの理想型ですね。
　これは昔ながらのゲーム開発手法なのかとも思うのですが。

大野氏：
　確かに，僕がスクウェアに入社する前のファミコン/スーパーファミコン時代はそうだったみたいです。

高橋氏：
　おそらく坂口さんくらいのキャリアがあると，原点回帰という感じなんでしょうね。僕らの世代だと，「どうやら以前はそうだったらしい」みたいな伝説の話になってしまいます。

大野氏：
　スマートフォンのゲームが台頭してきたから，小規模開発に回帰してきたんでしょうね。個人的にはプログラマ1人というのは，今回が初めての経験だったので不安もあったんです。今は，何とかなってよかったと思っています。

伊藤氏：
　実は，「TERRA BATTLE」の話を聞いたときは，大規模開発じゃないかと思っていたんですよ。

大野氏：
　いやもう，まったくの小規模で開発しました。

プランナーやデザイナーが直接Unityを使ってデータ管理

伊藤氏：
　二つめのよかった点として，「企画担当者やデザイナーがUnityを直接操作して，実行環境でデータ管理を行えたこと」を挙げられていますけれども。

大野氏：
　はい，各自が実際にUnityを使ってエフェクトなどを作っていました。

伊藤氏：
　というと，Unityのパーティクルシステム 「Shuriken」を使ってですか。

大野氏：
　ええ，ほとんどそれしか使っていません。パーティクルを時系列で組み合わせて，再生しているだけなんです。

伊藤氏：
　コンシューマゲームの開発では，自分でツールを作ったりもしますが，そんなことはしなかったと。

大野氏：
　余力がなかったというのが正直なところかもしれません（笑）。なので，できる範囲でやったわけです。

伊藤氏：
　企画の方も，Unityは初めてだったんでしょうか。

大野氏：
　そうです。

高橋氏：
　キャラクターのパラメータ調整などはどうでしょう。大型RPGではExcelなどの外部ツールで管理しているケースが多いですけど。

大野氏：
　それはさすがにExcelを使いました。

伊藤氏：
　Excelのデータを，Unityで読み込むわけですよね。最後まで，その手法を取ったのですか？

大野氏：
　最終的にExcelのデータがかなり巨大になってしまい，処理が重くなっているので，今は何とかしなければと考えているところです。

伊藤氏：
　DBといちいち直接やり取りするとなると，レスポンスが悪くなってしまうんですよね。

大野氏：
　なので，今は大元のデータをExcelで管理し，調整するときはエディタ上でリアルタイムにパラメータを書き換えて動作を確認するという事をやっています。

伊藤氏：
　運営でDBを使っているのは，どの部分でしょう。ユーザー管理あたりですか。

大野氏：
　ユーザーの管理とイベントの管理です。あとは画像周りもそうですね。

伊藤氏：
　そうなると，随時読み込みが発生するわけですよね。

大野氏：
　はい。必要に応じてダウンロードする形式です。

伊藤氏：
　それはたぶんアセットバンドルを使っていますよね。これも今回初めての経験だと思うのですが，ずいぶんうまく使っていらっしゃると感心しました。

大野氏：
　かなり苦労しましたけれども（笑）。途中，Unityのバージョンが3から4になったとき，フォーマットが変わりましたよね。そこで読めなくなっちゃいまして。

伊藤氏：
　そうでしたね……すみません。

大野氏：
　今後もそういうことがあるのかなと，ちょっと不安になります。
　あと，バージョンアップなしで，どこまで行けるのかも気になるところですね。

Unityのプラグインを活用して工数を削減

伊藤氏：
　3つめのよかった点として「NGUIやアプリ内課金プラグインなど，実績のあるプラグインを採用して工数を削減できたこと」を挙げられています。NGUIはUIツールですけれど，積極的に使っていたと。

大野氏：
　そのとおりです。

高橋氏：
　ほかに使ったプラグインはありますか。

大野氏：
　その二つだけですね。

伊藤氏：
　NGUIはご自身もしくはUIデザイナーが使われたのでしょうか。

大野氏：
　僕自身が使っていました。

伊藤氏：
　UIのデータをもらって，大野さん自身が実装するという感じですか。

大野氏：
　いえ，Photoshop上でこんな感じというイメージだけもらって，僕がチクチクUIを作っていました。

伊藤氏：
　なるほど。たとえば，UIのデータそのものをデザイナーに作ってもらうことはできそうでしたか。

大野氏：
　それは無理だったと思います。そこまで簡単ではないですから。
　……個人的には，バージョン4で入るといわれていた新しいUIツールを楽しみにしていたんですけれど，結局来ないまま「TERRA BATTLE」がリリースになってしまって。

伊藤氏：
　そうですね。もう1年経ってしまいました……すみません。

高橋氏：
　敵が消えるときのエフェクトなどに，凝ったシェーダを使っている印象がありますけれども。

大野氏：
　そこはPixelシェーダで散らしています。

高橋氏：
　そうした見た目の部分に関しては，アセットを使うよりも，ご自身で作ることが多いのでしょうか。

大野氏：
　そうですね。たいしたことをやっているわけではないですから，できる範囲でという感じですけれど。

高橋氏：
　モバイルゲームだと，あのレベルのシェーダであっても，自分では作らないことが多いですよ。

大野氏：
　逆に言うと，そこくらいしかできなかったんです（笑）。

伊藤氏：
　エフェクト以外のシェーダで，何か作ったものはありますか。

大野氏：
　味方のユニットを画像2枚で描いているんですけれど，それを合成するシェーダなどを地味に使っています。

高橋氏：
　やっぱり，そういった工夫をされているんですね。実は「TERRA BATTLE」は，ロードが速いわりに画質が綺麗だと感じていたんです。と言うのも，ロードが速いタイトルの場合，無理な圧縮形式を採用して輪郭線がガビガビになってしまうケースが少なくないですから。

大野氏：
　とくに工夫というほどのことはしていないんですけどね……。もちろん，根本的なリソースの量をなるべく減らすということは考えていますが。

伊藤氏：
　それでは，メモリが圧迫されて困ったというような経験はありませんでしたか。カードゲームなど画面に多くのユニットを表示するタイプだと，往々にしてメモリを食ってしまいがちですが。

大野氏：
　最初はどうやってメモリを解放するのか分からなかったんですよ。でも普通にマニュアルどおりやっているだけで大丈夫でしたね。……まあ，参照が残ってしまって消えないということはありましたけれども。

伊藤氏：
　描画系でDrawCall数を気にされたことも，あまりなかったのでしょうか（※描画処理の実行回数が増えると性能が低下する）。

大野氏：
　そこはもちろん，Atlas（※複数のテクスチャを1枚にまとめたもの）を作って……ということをやっていました。とくにUI周りですね。あとは途中から実装されたスプライトも使っています。

伊藤氏：
　そうなんですか。スプライトはどこに使っているのでしょう。

大野氏：
　UIの一部です。バトル中の文字などはスプライトでやっています。武器のアイコンもそうですね。

バックエンドサーバーにGoogle App Engineを採用するメリット

伊藤氏：
　4つめのよかった点として，「バックエンドサーバーにGoogle App Engineを採用したことで，少人数での開発運用ができたこと」を挙げていますが，このエンジンも今回初めて触ったわけですよね。

大野氏：
　実は「TERRA BATTLE」の前に1本リリースしていないタイトルがありまして，そこで触っています。

高橋氏：
　個人的にGoogle App Engineは好きなんですけれど，ゲームのバックエンドサーバーとして使われているケースはあまり聞きません。

大野氏：
　おそらく，ほかの皆さんは，これから新たに使い方を覚えなければならないということで躊躇なさっているんじゃないでしょうか。
　ぼくはもともとDBに関しては素人ですから，これから覚えるのであれば何でもいいということで選んだんです。最初からやるなら，こっちのほうがいいだろうと。

伊藤氏：
　確かに（Google App Engineは）インテリジェンスですよね。

高橋氏：
　運用は問題なくスケールできていますか。

大野氏：
　何も問題ないです。

高橋氏：
　理屈のうえでは確かにそうですが……。今回サーバーサイドも初めてですよね。

伊藤氏：
　本当に実現できるとは思いませんでした。

大野氏：
　ただ，トランザクションの処理で，たとえばグローバルなカウンタ（どこの処理からでもアクセスできるカウンタ用変数）をインクリメントするようなときは少し気をつける必要があります。「TERRA BATTLE」の配信初日は，皆さんがリセマラ（リセットマラソン）しまくっていたので，大量にリクエストが来た結果，グローバルカウンタが競合してエラーが起きたりもしていました。もっとも，現状使っているのはそこくらいですが。

伊藤氏：
　そう言えば，今後，フレンド機能は実装されますか。

大野氏：
　協力プレイの開発を進めていますので，同時に作っています。

伊藤氏：
　そうなると，トランザクションが発生する部分も増えますよね。

大野氏：
　そうですね。フレンド機能と協力プレイに関しては，別のサーバーを使おうと考えています。

伊藤氏：
　まとめると，初めてだからGoogle App Engineを使ってみたら，かなりうまくいったということですか。

大野氏：
　そうですね。そもそも今回は，少人数での開発が大前提にありました。そこで調べまして，少数とはいえ，Google App Engineを使った小規模開発のケースも見かけたので，選んだというのが実情です。

プログラマ1人の体制では二度とゲーム開発をしたくない

伊藤氏：
　それでは，Unityを使ってうまくいかなかった点についても教えてください。まず「人員が少なすぎたこと」を挙げていますが，確かにプログラマ1人でというのは無謀な挑戦という感を受けます。

大野氏：
　プログラマだけでなく，ゲームのパラメータを作っているのも1人ですし，全体に人員不足でしたね。

伊藤氏：
　バランス調整はどうしていたのでしょう。

大野氏：
　デバッグの際に感想をもらって調整したりもしましたが，基本的には自分達で遊んでみてバランスを取っています。

高橋氏：
　次の機会には，もっと人員を増やした体制をお考えですか。

大野氏：
　ええ，あの体制では二度とやりたくないです（笑）。

伊藤氏：
　とは言っても，プログラマが1人でやるメリットもあったと思うんですよ。それを活かしたまま人員を増やすには，どういう体制が望ましいでしょう。

大野氏：
　少人数がいいと言っても，プログラマが1人である必要はありません。逆に多すぎるとミーティングばかりになりますから，2〜3人がちょうどいいんじゃないかと思いますね。

伊藤氏：
　たとえばUnityだと，複数のプログラマで作業を振り分けるには，どうするのがいいとお考えですか。

大野氏：
　プログラマに関しては，全員が同じプロジェクトファイルをいじっても大丈夫だと思います。ただデザイナーが同じファイルをいじるとなると，たまに書き換えてしまったりもするので，ファイルごとにいじれるかどうかの権限を設定できるといいのですが。実際，　「TERRA BATTLE」程度の規模でもそういったことが起きてしまうんですよ。

伊藤氏：
　そこはバージョン5以降で，いろいろ変更が入りますので期待してください。

大野氏：
　最初は「TERRA BATTLE」もアセットサーバーでバージョン管理をしていたんですが，権限設定ができないので，途中からSVN（Subversion：バージョン管理ツール）に変えたという経緯もあるんです。

伊藤氏：
　というと，今はキャッシュサーバーも使っていないのでしょうか。

大野氏：
　そちらは使ってます。

伊藤氏：
　そうなると，iOS版もAndroid版も同時開発ということですよね。

大野氏：
　そうです。両方ビルドしますので，キャッシュサーバーがないとすごく時間が掛かってしまいますから。

伊藤氏：
　話を戻すと，プログラマが複数になったら，それはそれで問題が生じると。

大野氏：
　それでもチーム全体が10人程度ならなんとかなりますが，それ以上は厳しいでしょうね。

伊藤氏：
　「TERRA BATTLE」はプログラマが1人であることのメリットを享受できたと。

大野氏：
　そうですね。

伊藤氏：
　逆に，もう1人プログラマがいたらよかったと思ったところはどこでしたか。

大野氏：
　先ほど少し触れましたが，本格的にサーバーを導入しようとなったときです。やっぱり，きちんと経験のある人に任せたほうがいいだろうと。

初めての運営型ゲーム開発を乗り越えられた要因とは

伊藤氏：
　次にうまくいかなかった点として，「1人でプログラムを書いていたので，コメントやリファクタリング（※動作を変えずに処理を綺麗にすること）などの整理を怠ってしまったこと」とありますが。

大野氏：
　自分では分かっていることですから，ついつい放置気味になってしまいました。あとは物量が多かったので，あまり手直ししている暇がなかったことも理由です。
　そんな状態で新しいプログラマを迎えてしまったので，今まさに大変な状況になっています。

伊藤氏：
　ソースコードを見ながら，一つ一つ確認している感じでしょうか。

大野氏：
　まあ，今回入ったプログラマは非常に優秀なので，今のところ問題は起きていないのですが。

伊藤氏：
　実装中にはリファクタリングのことはなかなか考えませんから……。

大野氏：
　前職ではチームが大きかったので，割ときちんとやっていたんですけどね。1人になると，もっと優先してやらなければならないことがあって，なかなか（笑）。

伊藤氏：
　コメントも日本語で付けようとすると，今のUnityでは面倒ですよね。

大野氏：
　ええ。ですから基本的には，それっぽい英語でコメントを付けています。複雑なものだけ別のエディタを使って日本語で書いて，コピペしています。

伊藤氏：
　そこは随時，改修していきます。

大野氏：
　ほかのエディタを起動するのも面倒なので，ぜひお願いします。

伊藤氏：
　それではうまくいかなかった点の3つめについて，話を進めましょう。「運営型のゲーム開発が乏しく，試行錯誤を繰り返す必要があった」とありますが。

高橋氏：
　完成した「TERRA BATTLE」を見ると，とてもそうは思えないですけれど。

大野氏：
　いろいろアドバイスをいただきながら開発を進めたので，なんとかできたという感じなんです。

伊藤氏：
　チーム内に運営型ゲームの開発経験がある人はいるのでしょうか。

大野氏：
　1人もいません。

伊藤氏：
　よく，経験なしで運営型ゲームを作って失敗するというケースがありますが。

大野氏：
　実際，開発中には，そんなことまで考えなければならないのかと思うことがたくさんありました。たとえば課金周りですね。いちいちサーバー側に問い合わせなければいけないのかと。最初はクライアント側でやっちゃえばいいんじゃないか，くらいに考えていたんですけれど（笑）。

伊藤氏：
　それはマズいですよ（笑）。

大野氏：
　開発を始めた当初は，そんなレベルだったんですよ。

伊藤氏：
　今，そうした問題はありますか。

大野氏：
　おそらく多くの同業者さんが抱えている問題ではないかと思うのですが，チート行為ですね。　たとえば課金の際にサーバー側に偽のレシートが送られてきたりします。

伊藤氏：
　「TERRA BATTLE」では，どこで起きていますか。日本だけでしょうか。

大野氏：
　世界各国で起きています。

伊藤氏：
　なるほど，世界にはいろんな輩がいますからね……。
　しかし，それを踏まえても「TERRA BATTLE」は，初めてのチャレンジとは思えないほど全般にうまくいっているタイトルです。それはアドバイスがよかったからというだけではないとも思うのですが。

大野氏：
　自分自身が不安だったので，個人的に経験者からいろいろ聞いていたのが功を奏したのかもしれません。

伊藤氏：
　書籍とかではなく，直接聞いて回ったわけですか。

大野氏：
　そうです。今は，ゲーム開発者というと，多くの皆さんが一度はスマートフォン向けの開発を経験していますから。レシート（※決済完了時にやり取りされるデータ）についても「本物と同じ形式で送られてくるから，きちんとチェックしておいたほうがいい」と聞いていたので，大きなトラブルになる前に対策ができました。

伊藤氏：
　今はプレイヤー同士が競う何かがゲーム内にないということも，トラブルが少ない理由かもしれませんね。

大野氏：
　ええ，サーバーがシンプルですから，問題が少ないのだろうと捉えています。

特徴的なボスの行動パターンはプランナーが一つ一つ作っている

伊藤氏：
　それではいくつかお話を聞かせてください。ちょっと話が戻りますが，企画の方はExcelだけを使っていたのでしょうか。

大野氏：
　JavaScriptで，敵を動かすAIのスクリプトを書いていました。C#ではちょっと難しい処理でしたので。

伊藤氏：
　JavaScriptは，UnityのUnityScriptですか。

大野氏：
　はい，UnityScriptです。

伊藤氏：
　つまり，AIの仕組みを UnityScriptで書いて，ソースコードとして使うわけですよね。
　たとえばAIをクライアントでなく，サーバーに置くという選択肢もあったと思うのですが。

大野氏：
　そうしたほうがいいのかなとも思うのですが，セキュリティ面で引っかかるところがあったんです。あと面倒でしたので（笑）。
　ただ，Unityは，JavaScriptが増えると，コンパイルが重たくなりますよね。

高橋氏：
　大量のJavaScriptを突っ込んだプロジェクトを見たことがないのでなんとも……。

伊藤氏：
　もしかしたらJavaScriptに限らず，static変数などでテーブルが大量にあると重くなるのかもしれません。

大野氏：
　互いに参照していない独立したスクリプトなので，それはないと思うのですが……。

伊藤氏：
　JavaScriptに限らず，ソースコードが多いと確かに重くなりがちではあります。C#なら速いのですが。

高橋氏：
　そこはちょっとチェックしてみましょう。
　ちなみに，C#だと難しいのでJavaScriptで……というのは，ありそうで実際には聞かないケースだと思うのですが，どうでしょう。

大野氏：
　そうですね。実質はテンプレ化したコードを作って，それを少しいじるといった程度でした。コルーチン（co-routine）を書くときに，C#だと「StartCoroutine」と書かなければなりませんが， JavaScriptなら必要ないといった程度の理由ですから。

伊藤氏：
　なるほど。AIのルーチンをスクリプトで書くとなると，本当にプログラム的なif文のようなものも出てくるかと思うのですが。

大野氏：
　そういう部分もありますが，基本的にはあれやってこれやってというシーケンスの羅列です。たまに条件を見て行動を変えるという感じです。

伊藤氏：
　たとえば3割の確率で特殊な行動を取るというような作りではなく，もっとロジカルに考えるAIなんですね。

大野氏：
　ボスはもっとややこしいことをやっていますけれどね。

伊藤氏：
　ボスはチャプターごとに登場しますけれども，AIはそれぞれ専用に作っているのでしょうか。

大野氏：
　はい。チャプターごとに作っています。

伊藤氏：
　それぞれ特徴がありますよね。たとえば縦に攻撃するときには縦に移動，横に攻撃するときは横に移動するボスだと，きちんとロジカルにAIを作らないといけませんよね。

大野氏：
　それを網羅しようとすると，データが大変なことになってしまいますから。

伊藤氏：
　ポテンシャルマップではなく，こうなったらこう動くということを一つ一つ書いていると。そうなると職人芸というか，属人的な感じになりますね。

理路整然とした開発ではなく，収拾のつかないような作り方をあえて目指した

伊藤氏：
　お話を伺っていると，そもそも「TERRA BATTLE」自体がかなり属人的な作りという印象を受けます。

大野氏：
　気合いで作りましたから（笑）。

高橋氏：
　スタッフの誰かに事故などがあったら，開発がストップしてしまうパターンですね（笑）。

伊藤氏：
　スタープレイヤーと言いますか，スキルのある方がチームにそろっていたという。

大野氏：
　古くさいスタイルだとは思いますけどね……。

伊藤氏：
　今までの大規模なゲームの作り方とは違ったところに，何か軋轢はなかったのでしょうか。たとえばイテレーション（※小刻みに開発する際の周期）が早くなることが嫌だったとか，

大野氏：
　そんなことはなかったです。

伊藤氏：
　じゃあ，こういったスタイルを皆さんが気に入った感じでしょうか。

大野氏：
　そうだと思います。仕様がころころ変わっていく部分とか。

伊藤氏：
　そもそもの仕様はどんな感じだったんでしょう。

大野氏：
　基本的なゲームのルールは変わっていません。ゲームのネタ──それこそボス戦とか，バランスの調整に時間を掛けました。味方にこういうキャラがいないと苦戦するといったような感じで。

伊藤氏：
　お話だと，プログラムを作り，実装し，坂口さんの意見を踏まえて直すという流れがありますよね。毎日，その流れを繰り返していたんでしょうか。

大野氏：
　そうです。ほぼ毎日。

伊藤氏：
　毎日，坂口さんから文面で仕様が送られてくるわけですか。

大野氏：
　「こんな感じがいいな」みたいなメールが来るので，それを次の日までに形にするということを繰り返していましたね。

伊藤氏：
　なるほど……。坂口さんは，ほかのインタビューで大野さんを優秀だと褒めていましたけれども，逆に「Unityならプログラマ1人だけで何でもできるんだ」と誤解されると怖いですね。

大野氏：
　僕自身は楽しいんですけどね。……キツくもありますけれど。
　最初はもっとシンプルにデータを増やしてゲームを拡張していくことを考えていたのですが，とくに坂口は「もっとぐちゃぐちゃにしないとダメだ」と言っていましたね。

伊藤氏：
　ぐちゃぐちゃですか……。

大野氏：
　「自分達でも収拾が付けられないような作り方をしたら，結果として面白いものができる」「理路整然とデータ化してしまうと，それ以上のものにはならない」と，ずっと言っていましたよ。

伊藤氏：
　調整はするけれど，それでも収拾がつかないものがいいと。

大野氏：
　僕は，こんな作り方で完成するのかと思っていました。もっとも，今後追加していくデータも同じように作っていくわけですけれども。

伊藤氏：
　運営型のゲームですからね。よくコンシューマゲーム開発をしていた方だと，「運営型には終わりがない」と感じるケースが多いんです。今，大野さんもそのギャップを感じているのではないでしょうか。

大野氏：
　感じますね，「いつ休めるの」って（笑）。なので，もっと人員を増やして，交替で休めるような体制を構築したいです。

開発中のエディタ画面

手触りのよさや処理落ちしないことを優先した仕様に

高橋氏：
　基本的な話になってしまいますが，「TERRA BATTLE」の最低動作スペックは，何を基準にしているのでしょう。結構，グラフィックスは重いですよね。

大野氏：
　iPhone 4Sで，Androidも同程度のものを想定しています。いちおうiPhone 4相当の端末でも動作しますが，若干もたつきますね。

伊藤氏：
　手触りのよさについては，目指したところだったのでしょうか。

大野氏：
　そうですね。指の動きについてこれるよう，毎秒60フレーム表示は必須だと考えています。
　まあ，操作に関しては，ユニットを速く動かそうとすると，敵に引っかかるのが嫌だとか，あまり評価がよくないんですけれども。これは実装よりも，仕様の問題ですね。

伊藤氏：
　Unityだと，そういったスムーズな動きの実現が難しいということをよく聞きますけれども。

大野氏：
　可能なら，入力だけは表示と別スレッドでできるといいですね。そうすればまめに表示を更新しなくてもいいのかなと。機種によっては，エフェクトや敵がたくさん画面に表示されているとフレームレートが落ちてしまうので，指について来なくなりますからね。

伊藤氏：
　それでも十分綺麗な表示を実現できていると感じますよ。
　そのほか，苦労した点はありますか。

大野氏：
　とくに苦労したのは，インスタンシエイト（※Unityのオブジェクト構造であるプレファブからオブジェクトを生成すること）が遅いことですね。そこで「TERRA BATTLE」では，基本的にすべて一つのシーンで処理しています。

伊藤氏：
　まったくシーン遷移をしないんですね。

高橋氏：
　実はバージョン4.5でその辺りが速くなっているんですが……。

大野氏：
　本当ですか。すでにシーン遷移をしない作りにしてしまったので，気づかなかったのかもしれません。

伊藤氏：
　今の作りだと，きちんとリソース管理をしないといけなくなりますが，大丈夫でしたか。

大野氏：
　そこは大丈夫です。ただ，「せっかくいい仕組みがあるのに」と不毛な感じを受けました。

伊藤氏：
　1シーンですべてまかなうということについて，何か参考にされたんでしょうか。

大野氏：
　Unityの事例をいろいろ確認している中で，インスタンシエイトが遅いことを理解しました。あとは，非同期ではできないことを確認したりとか。リソースは非同期でも読めるんですけど，そこからインスタンシエイトをするとガクッと遅くなるのが嫌だなと。

伊藤氏：
　何かが発生したときに遅くなると，操作がしにくいだけのものになってしまいますからね。

大野氏：
　ローディングのマークがカクつくのも嫌なんですよ。結局，全部プールして1シーンに収めるという今の形に落ち着きました。

伊藤氏：
　もし機会があれば，インスタンシエイトが速くなったことを実感していただけると幸いです。

大野氏：
　分かりました。

高橋氏：
　もう一つ，「TERRA BATTLE」には動画共有機能がありますけれども，実際の使用率などはいかがでしょう。

大野氏：
　そんなにすごく使われているわけではありませんが，そこそこ動画をシェアしていただいています。

伊藤氏：
　あれを実装しようというのも，坂口さんのアイデアですか。

大野氏：
　むしろプロモーションの一環です。ゲームを広めるには，ああいう機能があったほうがいいだろうと，最後に組み込みました。

伊藤氏：
　組み込みにはどのくらいの時間が掛かりましたか。

大野氏：
　1週間くらいだったと思います。比較的簡単にできました。

伊藤氏：
　ちなみにUnityにも，「Everyplay」という動画共有サービスがあるのですが……。

大野氏：
　すみません，開発が忙しくて知りませんでした。

伊藤氏：
　ひょっとすると，こちらを使ったほうが簡単だったかもしれませんね。次の機会にはぜひご検討ください。

今後の展開は，メディアに掲載された坂口博信氏の発言を読んで初めて知る

高橋氏：
　「TERRA BATTLE」には，今後の伸びしろが大きいですよね。たとえば協力プレイや対戦プレイ，それに伴うフレンド機能といった感じで。
　「ダウンロードスターター」（※アプリのダウンロード数に応じて，アーティストの参戦，ゲームの新モード追加，コンサート開催，本・フィギュアの制作が開始されるというプロジェクト）の達成度によって，今後そういった要素を続々と実装していくわけですけれども。

大野氏：
　頑張ります，としか今は言えません（笑）。

伊藤氏：
　ダウンロードスターターの追加要素は，大野さんも承知のうえで発表されたのでしょうか。

大野氏：
　いえ，発表された内容を見て，「そうなんだ」と思う項目が多いです。坂口がいきなり言い出すことも多くて。「決まったから，あとよろしく」みたいな感じです。

高橋氏：
　その先の読めなさは，プレイヤーからするとワクワク感につながりますけれども，作っている側からすると大変ですよね。

大野氏：
　ローンチ前はまだよかったんですけれども，これからはもうちょっとよく考えてくださいと坂口に言っています（笑）。

伊藤氏：
　「200万ダウンロードでコンシューマ版開発開始」とも言っていますけれど，すぐに達成しそうですよ。

大野氏：
　どうしましょうねえ……。

伊藤氏：
　そうなると，さすがにUnityでどうこうではなくなってしまいますよね。

大野氏：
　ええ，たぶんUnityではないでしょう。

伊藤氏：
　操作もタッチではなくなりますから，作り直すことになりますよね。これまた大きなチャレンジになりそうです。

高橋氏：
　坂口さんはコンシューマ版をMMOにしたいとおっしゃっていますが。

大野氏：
　そうみたいですね。僕も坂口のインタビューを読んで，「そうなのか」と思いました。繰り返しですが，今は頑張ります，としか言えません……。

伊藤氏：
　分かりました。今後もぜひUnityをよろしくお願いします。本日はありがとうございました。

「TERRA BATTLE」公式サイト

「Unity」公式サイト