Guinea Pig 2nd

http://d.hatena.ne.jp/murishinai/ の続き。 https://note.com/shikatanai から移動する予定

あるゲーム開発の記録

 開発・運営していたモバイルのゲームが平成の終了と同時に終わった。社内からもすっかりその空気や記憶が消え、ほとぼりが冷めてきたこの時期に、ぼやき的な開発記録を書く。プログラマからの視点であり、全部うろ覚えで適当である。

開発に向けた経緯、あるいは地獄への入り口

 今から何年も前のこと。

 簡単に言うと石を売れるゲームを模索していた。しかしガチャの実装は不可能だった。理由は簡単で、ガチャというのは継続的に圧倒的な物量の供給があってこその販売戦略であって、そしてその膨大なアセットを適切に管理できてこそ可能な商売の手段であり、世の有象無象が過去を懐かしんで怨嗟とともに口汚く罵るよりもはるかに大変な事業なのである。開発規模が小さい自分のチームでその選択肢をとることは出来なかった。

 結局ない知恵を絞っても革新的なことが出来るわけもなく、時間回復のスタミナ的なところへの課金アイテム設定となった。一応なけなしのDLCというか追加要素もあったが、費用対効果として働くことが出来るだけの仕組みが用意できなかった。

 石を売ると言うことは、石をサーバで管理すると言うことである。クライアントの端末を信じるのであれば別にサーバを立てる必要はないのだが、そのような選択肢は最初から当然排除された。しかしこれが最初の壁となる。

 つまりモバイルゲームのためのサーバを運用した経験がないのである。そこで、サーバサイドを外注することになるのだが、このあたりで自分の力不足をかなり露呈させることになった。ある程度カスタマイズ可能な構成を発注したのであるが、最後までまとまりきらないセキュリティ要件や、自社の偉い人側の知識不足、あるいは自分のプレゼン力不足のせいで、良いものを発注できなかった。

上司へ新時代の常識が説明できない

 お金を扱うのであるので、もちろんサーバサイドというかデータベースはトランザクションが保証されなければならない。その一方で、どれだけユーザ数が増えたとしても安定したパフォーマンスで動作させねばならない。しかし、トランザクションを保証した(レガシーな)データベースへのやりとりは、その作りにも寄るが、ユーザ数の増大に伴って徐々に破綻していくものである。と言う、あちらが立てばこちらが立たないという話について、自社の中ではかなり議論が紛糾した。他にはセキュリティ要件についても同様にどこまでもガチガチに漏れない認証が求められたり、サーバの可用性というか、決してエラーを起こさず安定して動き続け、最終的には監視が不要である仕組みが求められた。少なくともオンプレミスではそれは実現できないであろう。

 とにかく、クラックなどの攻撃に無制限に強く、どのような大量アクセスにも挫けることはなく、そして一切のエラーが発生せず、全てのデータ操作は安全であり、そして応答性の早さを無邪気に要求された。これについても、本当に自分の力不足というか、現実的なラインにおける妥協と、緊急時における復旧方法についての理解を深めるべきであった。必要なのは竜を倒す方法ではなく、いかに味方は全滅しないかの説明であった。

 このあたりの頭の悪いやりとりについて、サーバサイドを担当してくれた外注会社はとても素晴らしい提案をしてくれたと今になって思う。

AWSへの入門

 おおむね以下の構成となった。

・EC2(ELB(MultiAZ) + AutoScaling) の多インスタンス構成。 ・web は nginx で受けて処理は RoR(unicorn) ・環境は Packer で構築し Terraform で管理する ・DynamoDB + SQS + SNS ・データのやりとりは、書き込みを SNS から SQS で詰んで、読み込みは直接。 ・SQS からの書き込み処理を常に行う Worker を EC2 に置く。 ・監視に Mackerel で通知先は Slack

 理解に時間をかけたのは DynamoDB で、当時は予約された分しか読み書きが保証されなかったため、大分肝を冷やしながらキャパシティの設定を手動でやっていた。今となっては自動で調整してくれるオプションがついたため、そちらに丸投げしている。

 どれだけユーザ規模が増えても耐えられること、そして極力メンテナンスフリーで、と言う要求に対して、ベストアンサーであったと思う。当時は Lambda がなく、サーバレスで関数単位の処理を任せることが出来なかったので、そこはやむなく EC2 でインスタンスを持つこととなった。

 当時も Aurora はなかったが、それにしても安易に RDS を選択しなかったのは本当に感謝しかない。シンプルな KVS であることと、スキーマレスで動的に内容を定義していけるのは本当に素晴らしい仕組みであった。一方で、自分の理解が追いつかず、パーティションキーとソートキーについて価値のある議論が出来なかったことは今でも悔やまれる。

……のように AWS への入門からやってしまったため、サーバが実際に何をするかについての議論について深く踏み込むことが出来なかった。月が落ちてくるような極端な心配は早く片付けて、何をして欲しいのかという所に尽力すべきであった。

 サーバーサイドではいくつかの定型機能を提案され、そして実装をお願いしたが、そのほとんどが使われることがなかった。必要なのは自由なカスタマイズ性と、いい感じに DynamoDB + SQS を Wrap してくれることであり、どのようなデータレイアウトであるべきか、あるいはテーブルの設計をするべきかを知らない我々は、本当に必要な機能を正しく予測することが出来なかった。

 最後の手段として、自由に記述できる、独自のクラスを動的に読み込んで実行する機能を提供してもらったが、結果としては実質この最後の手段がメインの戦力・サーバの価値となってしまっている。発注仕様はこの部分を掘り下げるべきであった。

いつも通りの開発

 外注へのサーバサイド発注アンド仕様決定と、クライアントアプリの実装は平行で行われた。クライアントアプリは最初、スタンドアロンで開発を行い、サーバの完成に伴って部分的に処理をサーバサイドへ移動させる想定であった。もちろん、モック的な考えも開発経験もあるわけはなく、スタンドアロンで動くアプリとサーバと連携するアプリとではプログラムの書き直しを余儀なくされた。

 クライアント開発は Unity を使って行われた。これ自体は非常に強力で生産性の高いツールであるのだが、データの外部化、つまり Asset Bundle となると話は全く変わる。元々 PC 用の安定した通信環境を前提として設計されているリモートの Asset Bundle 処理は、そのまま提供されている API を使うと、ダウンロードしたデータは最大で(確か) 180 日しか保持されず、そして、保持したファイルの数に比例してそのヘルスチェックを行うため、アプリの起動が遅くなるのである。自分の記憶においては、(他社で言うと)テクテクテクテクがこの罠を踏み、あらかじめデータをダウンロードした方がアプリの起動が遅くなると言う本末転倒な現象が発生していた。

 そのため Asset Bundle を自前で保存する機構から実装を求められた。あの不自由な iOS や、ストレージが内部にあるのか外部にあるのか常に生きているのかオフラインなのか保証されない Android でそれを実装するのである。とにかく Asset Bundle はそれ自身の融通の気かなさと、モバイルにおける様々な環境の信頼性の少なさから、今でもなお Unity では利用したくない技術のひとつになっている。

 アプリの実装もまた、自分の経験不足が最後まで仇となった。まず UI についてであるが、当時の Unity は OnGUI から uGUI への移行期間であったが、勇気を持って uGUI を選択することが出来なかった。Canvas のパフォーマンスが未知数であったことと、デザイナーに対して正しいツールの説明が出来なかったからである。

 ここでもうひとつ、さらに大きな負債として立ちはだかってくるのが、国内で大手のモーション作成ツールである。ここは元々、主にコンシューマゲーム機などへの画像減色ツールなどの提供を行っていたのであるが、それと並行してゲームへのモーションを付けるツールの提供も行っていた。デザイナのスキルがそれでロックインされていたため UI の動きについてもこの大手ツールを使う流れになっていた。これがひとつ、非常に良くないところであった。今であったらどうにかして uGUI と Unity の Animator でお願いしているところである。

 この大手ツールはそもそもパフォーマンスが悪く、さらにそのツールで作られたデータのインポート・エクスポートにも難があった。(Unity)C#で記述しているには(GC的な意味で)無駄の多いランタイムであったり、あらゆる表現を可能にしたいが為に、使わない・使い切れない大量のシェーダ・マテリアル・データを抱え込む仕様であった。そこまでリッチなものを作りたいわけでも(我々の規模としても)作れるわけでもなく、そしてさらに悪いことに UI としてもこのツールの利用を決定してしまったため、開発は大いに難航した。パフォーマンスが出ないであったり、デザイナが作ったデータの受け渡しに非常に手間取ったり、繰り返すが、このときに自分の Unity への熟達が十分であれば、すべて Unity で解決していたであろう。

終わらないパラメータと地獄のようなExcel

 全てに於いて想定の甘さという話に着地するのであるが、ゲームのシステムディレクターは必要なパラメータを洗い出せなかった。実装に従い必要な情報が増え、そして都度Excelはレイアウトが変わる。さらに悪いことに、中途半端に別シート参照果ては別ファイル参照という小賢しいテクニックでもってデータが作られてくるため、そもそもこのデータのやりとりに最後まで苦労をした。特に何も言われずデータのレイアウトは変わり、数値と信じていたものは文字列に変わり、見栄えのために空白のセルや結合されたセルがあちらこちらに舞い、そして xlsx ではなく xls であった。要は新しい(リボン)UIを拒絶した結果がここに来たのである。そういえばその人は Windows もOSや必要ソフトのインストールの次にすることは XP や 7 のスタイルから Windows 95 のスタイルへ直すことであった。使っているエディタも未だにサクラである。

自分に対して唯一の救いとなったC#

 そんな中、開発言語として C# が採用されていたのは自分にとって非常に助かったことであった。とは言え、この場合比較対象として想定に出るのは Java くらいであって、これが C++(C++11以降) であったとしたら、それはそれでそれほど開発の楽さは変わった感はない。つまり、必要なのはさくっとコールバックを書くための楽な文法であり、その場で変数のキャプチャを伴う関数の定義ができれば何でも良かったのである。当時の Java であったら、そのたびに生成される匿名クラスの記述量に憤死していたであろう。そして、当時の MonoDevelop-Unity は(今となっては Rider には及ばないにしても)それでも十分パワフルであった。

無計画であった集金方法

 話をゲームに戻す。ガチャではないスタイルで実装されていたこのゲームの集金モデルは、あまりにも楽観的すぎる予測とともに設計されていた。基本無料でガチャをやらないのであれば、例えば Homescapes のように、あるいは他のゲームのように、支払いへの導線を綿密に作り、あるいは支払いではないにしてもリワード型の広告をふんだんに盛り込むべきであった。今になって思うと、石よりも必要なのはこの部分の実装であった。この部分が最初から厳密に仕上がっていれば、今でも細々とこのゲームは緩慢なアップデートを繰り返し生き続けていられたのかも知れない。

ようやくのサービスインとフェードアウト

 そんなこんなで、ひたすら苦痛の中でどうにか生み出されたこのゲームのサービスが始まった。結果としては先に述べたように、あまりにも集金への導線が薄かったため、開発費に対してこれがペイしないことは直ちに判明した。いくつかの再起を図って、機能改善や石の消費を伴う追加要素、果ては英語版のリリースまで行ったのであるが、その全てが徒労に終わった。元々開発力のないチームであったというのもあり、結局大きな事は何一つ出来なかった。あとにはユーザから中途半端に吸い上げた、浮いた金(石)だけが残った。

サービスのクローズと返金と

 アプリやそのサービスが、元々想定の乏しいプアな作りであったため、返金への対応はかなり後手後手となった。アプリの内側から直接連絡を受けることは出来ず、大分プリミティブな方法での返金対応となった。ただでさえ赤字を出しているプロジェクトが、ここで自分を殺すためにさらに余計な人件費を嵩ませることになった。当たり前の話であるが、サービスを伴うアプリを作るときには、その閉じ方も想定するべきであり、どこまでも行き当たりばったりにサービスを行かしておくのは、結果として最大限の損失に繋がる。

繋がる未来があるとするなら

 これ以上思い出すことはない。ある種の運営型アプリはこの業界にとってレッドオーシャンであることは既知であり、そして一発ホームランを狙うにしては投げる球のコストがアホみたいに高くなりすぎている。

 Unity についての知見は溜まった。また Unity もどんどん機能を増やし改善され、いろんなことが少ないコストで出来るようになった。しかし、それを上回る速度で iOSAndroid は無駄に複雑化していく。ただ単にゲームを作るだけであれば Unity は非常に優秀な環境であるが、モバイルにおけるネイティブの機能と使おうと思った瞬間に修羅の道と化す。Unity は、ちゃんとしたネイティブの知識を持たずには、ほとんどまともにモバイルでゲームを作ることが出来ない。そのゲームが数千円で売り切られるのなら問題はないが、実際には基本無料の上に様々な SDK を乗せてようやく収益が見込まれ、そして人に遊んでもらえる環境となる。そしてその様々な SDK は Unity と仲が悪かったり、他の SDK と仲が悪かったりする。

 あるいはそもそも、ゲーム業界という IT で最も神の加護の下にない世界には、もはや生きるための余地はないのかもしれない。馬鹿のひとつ覚えのようにやれインディーだ個人開発だなんだと吹き上がっているが、どんなに良いものを作っても金を稼ぐ事に繋がらなければただの負債であるし、知名度が足りなければ、あるいは宣伝する手段がなければその価値は目に見える場所にあるゴミにも満たない。無である。

 この業界に、少なくとも自分に、繋がる未来は、おそらくない。ただただ大手が AAA 級と呼ばれるゴージャスなコンテンツを提供するか、ハイクオリティで盛り沢山の絵と声を用意したガチャを作るか、あるいは元から知名度のあるクリエイターが約束された名作を生み出すか。

 ただそれだけである。