【島国大和】ツールで楽になったところと，ならないところ。ゲームを作る最後の10％

島国大和 / 不景気の波にもがく，正体はそっとしておいて欲しいゲーム開発者

島国大和のド畜生 出張所 ブログ：http://dochikushow.blog3.fc2.com/

　どうもお久しぶりの島国大和です。皆さんデスマーチしてますか？（挨拶）

　最近はゲームを作る環境が整備されてきました。
　Unityだ，Unreal Engineだ，Cocos2dだと，便利な開発環境があって，3Dツールや2Dペイントツールでデータこさえてゲームエンジンに持ってけば，とりあえず絵が画面に出て動くまでは超早いです。すばらしい。

　ちなみに昔，20年ぐらい前は，ゲームを作ろうとしたら，まず“ゲーム用のツールを作るところ”からのスタートでした。
　だってツールが無かったですからね。

　キャラクターツール，マップエディタ，スクリプトエンジン。そして，ツールができたらもうゲームは半分完成したようなものでした。荒削りなゲームが魅力的だった時代です（ゲーム自体が珍しかったから，ガマンできた）。

　そして今，ツールのあり方は随分変わりました。ゲームジャンルによっては，既存のツールだけでタイトルを開発することも珍しくありません。
　結果としてゲームの作り方も変わりましたが，一方で全然変わらず，大変なところもあります。
　今回はその辺の話を書いてみようと思います。

ゲーム開発今昔。黎明期から最近まで

　大雑把に，駆け足でいきますよー。ビデオゲームを作る工程の話です。

「Pong」

　ビデオゲームの歴史を紐解くと，「Pong」（1972年）と「Breakout」（1976年。日本で言うブロックくずし），「スペースインベーダー」（1978年）は避けては通れませんが，この頃のゲームはソフトウェアだけでなく，ハードウェアで動かす部分も多くありました。スペースインベーダーの独特なサウンドエフェクトは，回路の抵抗を変えて出していたそうです。

　ちなみにスペースインベーダーで，インベーダーの数が少なくなるにつれて移動スピードが上がるのは，最近のゲームのようなwait処理がなく，描画量が減った分だけ速度が上がる仕組みだったからだそうです（本当かしらん）。

　あの頃はゲーム開発といえば回路の設計だったのでしょう（自分はその頃遊ぶ側だったので，開発に関わったことはありません）。

　そして次に，ほとんどソフトウェアでゲームを作る時代が来ます。
　「ギャラクシアン」（1979年）は，初めてスプライト機能を使ったゲームだといわれています，背景上でドット絵のキャラクターが動いている，ファミコンやスーパーファミコンなどのゲームを思い出してください。ああいうのを動かすのがスプライト機能です。

　プログラマブルキャラクタジェネレータ（プログラムでドット絵を動かす仕組み）とか，プログラマブルサウンドジェネレータ（プログラムで音を鳴らす仕組み）とか，ソフトウェアでいろいろと簡単にできるようになって，電子工作しなくても，直接VRAMなどをいじらなくても，ゲームを作れるようになったわけですね。
　そうなると，もちろんツールも作れるわけです。

“全部ソフトウェアで動いているから，ツールも作れる”となったこのあたり（1970年代後半から1980年代前半）は，ゲームの発展におけるひとつのキーポイントだと思います。

　ファミコンやスーパーファミコンの頃は，ゲームを作ろうとすると，まずドット絵を描くツールから作るという感じでした。
　自分もこの時期（まだ素人でしたが），スプライトエディタをいくつか作ったことがあります。
　パタパタアニメ機能とか，当たり判定データをぶら下げるとか，そういうことを全部プログラムにベタ書きするのは非効率ですから，とりあえずツールを作ってしまうわけです。

　このあと，ゲームの潮流は，ポリゴンを使った3Dグラフィックスのゲームに向かっていきますが，ポリゴンデータを扱う3Dツールを自作するのはあまりに大変で，ゲーム開発全体でみると，割に合わなくなってきます。その結果，市販されているツールを使うというケースが増えて，今ではもう滅多に見られません。
　ただ，できあがったポリゴンデータに音や当たり判定，モーションの遷移ルールなど，タイトル独自のデータを付加するといったツールは，やはり開発チームの自作でした。

　そして，そうやってツールで作ったデータがゲーム内で動くのを確認できるまで，それなりの手間と時間がかかりました。自社開発じゃないツールで作ったデータに，自社のデータぶら下げて，それを再生するプログラムを自社で組んで，実際ちゃんと思ったとおり動くかな？　ありゃだめだ……みたいなところで時間を取られまくりました。
　あの当時はターゲットハードの描画にあわせたデータじゃなかったですしね。最近の統合環境とは比べられません。

　そういえば，初代PlayStationの開発機には，スプライトエディタと，マテリアルエディタ（ポリゴンにテクスチャをぺたぺた貼るツール）が付いてきたんですが，これは当時としては驚きの大サービスでしたね。
　もちろんそのツールだけでゲームが作れるわけではありませんが，開発期間の短縮にはなったと思います。

　この頃は，便利なツールで作業が楽になった一方で，ほかの人，ほかの会社も楽になっているので，結局，求められるクオリティが跳ね上がっていく，そういう時代でした。

　そして最近は冒頭で触れたように，統合開発環境であるゲームエンジンの最盛期です。3Dツールや2Dペイントツール，音楽ツールなどで作ったデータを持ってきて，ゲームエンジン上で組み立てる。プログラマもデザイナーもプランナーも，ゲームエンジン上で仕事，といった作り方ですね。
　自作ツール，自社ツールも，ゲームエンジン上で作ったりします。

　極論すれば，ビデオゲームとは，ユーザーの操作に従いデータを再生するプログラムです。右に歩けば右のマップが表示され，パンチボタンを押せばパンチの絵が表示される。プレイヤーの操作や条件に応じて，データを再生する，そういうものです。
　そして，そういった部品のようなデータは，ツールを用いて作る場合がほとんどです。プログラムで直書きしていた時代もありますが，それは8bit機全盛期ごろまでじゃないですかね。
　なので，ツールの設計はゲームの設計でもあります。

いいゲームを作るには，まずいいツールから

　で，ツールのお話です。
　たとえば，2DのシューティングゲームやRPGを作る場合，スプライトエディタがすでにあるなら，次は背景のチップセットを並べるツールを作ります。マップエディタですね。マップの絵を並べて，ここに敵を出す，ここはダメージ床，みたいな設定データを編集するツールです。
　2D格闘ゲームなどでは，キャラクターの絵をパラパラ再生しつつ，ボタンへの反応の設定や当たり判定をつけるツールを作ります。3D格闘ゲームなら，モーションに音や当たり判定，操作に対する遷移のデータをぶら下げるツールです。

　そうやってツールで作ったデータを再生するのが，実際のゲームプログラムの役割です。
　RPGツクールとかシューティングゲームツクールといったものがありますよね。プロの現場では，さすがにもうちょっと作るゲームに特化したツールを作りますし，そのデータを再生するゲームプログラムも専用にいろいろ書きますが，基本の流れは同じです。

　いいゲームを作るには，まずいいツールから。
　最近のCGのクオリティは，グラフィックスツールや3Dツールの飛躍的な高性能化にともなって，半端なく上がっていますが，ゲームもいいツールがあればいいものを作りやすくなります。

　大手のゲーム会社のゲームの出来がいい傾向にあるのは，資産として，そういったツールやライブラリ（同じような動作をするプログラムの塊），それを使うノウハウがあるからです。ゼロから開発の新参会社では，まぁ太刀打ちできません

　また，大手であれば，“ツールを複数のゲームに使う前提”で作ればコストを下げられます。
　「MOBIUS FINAL FANTASY」（iOS / Android）は，Unityで開発されているそうですが，そのうえで，ターゲットハードウェア別（スマートフォンの各機種別）に，表示パラメータやデータを細かく調整しているそうです。

　これ，普通の規模のゲーム開発ではできません。最適化をするだけでも大変ですし，よしんば最適化したとしても，アップデートごとに各機種別のデータとパラメータを用意するのは時間的に無理です。

　……が，そこは天下のスクウェア・エニックス，どうせ利益はでるし，培ったノウハウをほかのゲームにも生かせるし（機種別のセッティングなどは特にそうです），ということでこれに挑戦しました。アップデートごとの機種別データ作成に時間がかかるなら，それを自動的に作るサーバーをたくさん用意すればいいじゃない（そういうものです。お金で時間を買えます）という戦い方で切り抜けたそうです（以上，半分は開発者会議Uniteの講演で実際に聞きました。半分はゲスな想像です）。

　ツールは一度作ってしまえば，以後とても便利に使えますし，バージョンアップを繰り返してさらに便利になっていきます。
　まぁ保守が面倒くさくて腐っちゃったり，開発していた担当者が辞めてブラックボックス化しちゃったりって場合もありますけど。

　で，さきほど自社製の3Dツールというものはほとんどないという話をしましたが，ゲームエンジンでも自社製は減っています。
　そう。これも，求められるゲームの完成度に対してなかなか採算が取れないから。もちろん，気合の入ったゲームでゼロからゲームエンジン開発ということはあります。ブラウザゲーム開発のように，わざわざ他社から買うのもナニだなって場合もあります。

　そういえば「スクールガールストライカーズ」（iOS / Android）は自社エンジンを用いて描画の軽量化に特化し，ほかとの差別化も図っていてすごいですね。あんなカッコイイ真似はなかなかできません。ゲームはいつものアレですけど。

ゲームエンジンのおかげでエライ時代に

　ところで，ゲームを作るときに一番面倒くさいのは，「表示とインタフェースと当たり判定」です。異論はあるでしょうけど，自分はこれが一番面倒だと思っています。
　そりゃ，途中までしかできてないゲームを見て，ああしろこうしろ言う人のほうが面倒くさいですが，それはまた別の話。
　ゼロから作る場合「表示とインタフェースと当たり判定」には開発期間の多くを消費します。

　表示周りはハードウェアにべったりの部分なので，書くのが大変です。ここがうまいかどうかで，見た目も速度も全く違ってきます。
　インタフェースはウィンドウだのボタンだの，データの保存だの，ゲームの遷移だの，地味なのに超時間を取られます。手触りって10回言ってみろー！
　当たり判定は数学の塊なので，これまた数学的に大変です。超面倒くさい。

　いわゆるゲームエンジンは，このあたりをまとめて提供してくれます。面倒なところは最初から作ってあって，その環境の上でゲームを作ればいいわけです。
　ポリゴンモデルをドラッグ＆ドロップで突っ込めば表示されますし，ライトを指定すれば影が落ちます。カメラを指定すればちゃんと撮影されます。そのモデルにぶら下げてプログラムを書けば動きます。すげぇ！

　自分は趣味や仕事でUnityを使うことがありますが，とりあえず画面にモデルを出して当たり判定付きで動かすまでなら1日でできます。おおブラボー！　かつてはどれぐらいかかったか分からない仕事ですよ。開発の50％はこういうことをやっていたと言ってもいい。

　これはもうエライ時代が来ました。

　「ツールさえ作ればゲームは半分できたみたいなもの」から，「ツールはもうできてます」って時代になりました。
　えらいこちゃです。

　「TERRA BATTLE」（iOS / Android）が，“Unity使って少人数短期間開発！”ですよ。
　そりゃ偉い人も勘違いしますって。勘弁してください。
　実際はツールやゲームエンジン導入したからといって，そう簡単にはいかないという話をしましょう。

Unity 5

もっとも大事な最後の10％

　というわけで，ゲームエンジンを使えば，ゲームっぽいもの，ゲームの体裁を整えたものは結構簡単に作れる時代になりました。ちょっとしたブロック崩しやシューティングなら，1週間もあれば形になるでしょう。

　でも，それだけでは商品としての価値はでないわけですよ。ゲーム黎明期はそういう荒削りのゲームばっかりでしたけれど。
　各社が開発力を上げると，必要とされるクオリティも同じように上がって，商売のハードルも高くなります。エンジン使ってちょいちょい，では商売にならないんですね。

　一体どうやって商品価値があるゲームを作るか。これはゲーム関係者にとって重要なお題です。

　昔は「ゲームエンジンなんか使ったらほかと差別化できない」という考え方もありました。マシンスペックが低いと，エンジンの設計時点で着地点がある程度決まっちゃうので，事実，差別化ができなかった時期もありました。
　今だって，予算と開発力があるならフルスクラッチもまだ視野にあります。

　そういう事例も含めても，個人的な感想を言えば。
　今も昔も，ゲームの完成度を決めるのは最後の10％じゃないかなと思っています。
　回路から作ろうが，ゼロからアセンブラで書こうが，ゲームエンジンを使おうが，この最後の10％がゲームの良し悪しを決めるんじゃないかなと思います（回路から作ったこと無いんですが）。

　その10％で差別化するしかないんですよ。面白いゲームは，発想と設計と，それを実現する技術と，最後の調整で生まれます。

　素晴らしいアイデアのゲームも，人気タイトルをコピーしたようなゲームも，絵だけに予算のかかったようなゲームも，最後の10％に気合が入っていれば結構遊べるし，ここで手を抜くとアイデア倒れで終わります。

　ちょっと前だと「グランブルーファンタジー」は配信開始当時，バグだらけで重くて，サーバ障害も多くて，最後の10％を作りきれてない感じがしました。
　普通だと損切りしたくなるような出だしだったと思いますが，絵のクオリティは間違いなく最高峰だったので，芽があると判断されたんでしょうね。その後ずっとアップデート続けて，宣伝を続けて，気がついたらストアの売り上げランカーなワケですよ。最後の10％の大事さを，1タイトルで比較できる貴重な事案だと思います。

　というか，あの状況でもずっとTVCMを続けたってのが，すげぇと思います。今大成功してるからこそこうやってネタにできるわけで，最後のツメが悪くて，結局人知れず消えたゲームとかは，心苦しくてネタにできません。

　そんなわけでゲームエンジンは0から50％ぐらいまでの時間を飛躍的に短縮してくれますし，ブラウザゲームのようにフォーマットの固まったゲームも，初期開発はザックリ短縮できます。が，最後の10％は今も昔も変わらないんです。そこはもう個人のスキルと手数に頼りきりです。

　ユーザーテストを延々繰り返すってのもいいですね。あれはやり方次第ですが，上手にやればゲームのどこにコストをかければ多くの人に受け入れられるかを抽出しやすいですし，エライ人を説得できる材料が手に入ります。開発期間は延びますが。

　んで，最後の調整に失敗したら，ほかの部分がどんなに良くてもゴミになりがちです。最初の50％ぐらいが昔に比べて随分楽になりましたから，むしろこの最後のツメの重要性は増すばかりです。
　自分なんかは，最初の10％のアイデア一発で勝負したい派ですけど，もう荒削りなゲームが好意的に受け入れられる時代ではなくなっています。

　結局，ゲームを作るのに手は抜けないなぁ，ツールが便利になっても最後の最後は人間だなぁというのが，偽らざる感想です。結局楽にならないなぁ，という。
　ツールのおかげで最初の50％がラクになるってだけで値千金ではありますが。

　そんなわけで，日夜，あちこちの開発現場で，最後の10％の地獄を戦う人たちがいるわけです。ここで頑張れば，頑張っただけチガウので，そりゃデスマーチは減らないわ。
　なんか，バランスのいいゲーム，手触りのいいゲーム，丁寧な作りだなーというゲームに出会ったら，頑張った人たちがいるんだろうな，と思うと多少はホンワカするかもしれません。

　あと，クソゲーには広い心を持ちましょう（何故？）。

　それでは，今回はこんな感じでー。
　またいつか，忘れ去れる前にお会いしましょう！

■■島国大和■■ 有名ゲーム系Blog「島国大和のド畜生」の管理人で，不景気の波にもがく，正体はそっとしておいてほしいゲーム開発者。「METAL GEAR SOLID V: THE PHANTOM PAIN」をプレイしながら，いくらかかるなー，何人かかるなー，などと思っているという島国氏。冒頭だけで相当な額のお金がかけられていることが想像できて，へんな笑いが漏れてしまうそうです。そういう楽しみ方（？）もあるんですね……。