ガンハウンドには機種に依存した部分が殆ど無く、テクスチャつきの3角形さえ毎フレーム2000個位描画できれば、どんなプラットフォームでも理論上は動く仕組みだった。グラフィックの背景はグーグルの画像検索で得た画像を組み合わせて横に長いBMPを作った。それを16x16のマップチップに分解
するツールを作ってできるだけ小さいテクスチャに区切った。敵キャラは自分で描いたものや検索で拾ってきたものに手足をつけてテクスチャ化しアニメをつけ
て動かした。全てが仮の素材だったが、テクスチャ中のスプライト位置も決定していて、アニメのさせ方もレイヤー構成も決まっていたので、あとはこれを「リ
ファイン」してくれるグラフィッカーを探した。やりたいことは画面で見せられるし、描いてもらいたいものの方向性も決まっている、出現する場所もスクリー
ンショットで構成し、グラフィッカーにその素材の使われ方を意識してもらうことでMOD的な感覚で作業をしてもらえることに期待した。こうすることで敵
キャラの仕組みを考える時間を減らしているのが強みだ。これはVIIを作っていたことで得た知恵で、かつ最も効率の良かったやり方だった。「最初に素材あ
りき」でプログラムに組み込むとなると後から設計をしなくてはならなくなるし、その設計も一貫性に乏しくなる(※)
※ ドラえもんの道具に「続きスプレー」というのがある。それを想像してもらいたい。船の舳先を書いてスプレーすれば続きを描いてくれるスプレーなのだが、最 初に書く船の舳先がヘボければ続きスプレーで出来上がる船全体の絵もしょぼい。しかし最初の舳先を丁寧に設計すれば出来上がりの船は素晴らしいものにな る。なので多少面倒ではあるが、少人数で作る時はプログラム主導で必要な素材を「仮素材」としてできるだけ精度の高いものを用意し、それをCG、サウン ド、スクリプトに至るまで用意してあげることで、意図が伝わりやすく作業者もMOD感覚で作業できる。作業効率が高まれば2ヶ月かかるところが1ヶ月で済 む。120万円かかるところが60万円ですむということになる。
次回はこのアジャイルについて少し話を進めたい。
※ ドラえもんの道具に「続きスプレー」というのがある。それを想像してもらいたい。船の舳先を書いてスプレーすれば続きを描いてくれるスプレーなのだが、最 初に書く船の舳先がヘボければ続きスプレーで出来上がる船全体の絵もしょぼい。しかし最初の舳先を丁寧に設計すれば出来上がりの船は素晴らしいものにな る。なので多少面倒ではあるが、少人数で作る時はプログラム主導で必要な素材を「仮素材」としてできるだけ精度の高いものを用意し、それをCG、サウン ド、スクリプトに至るまで用意してあげることで、意図が伝わりやすく作業者もMOD感覚で作業できる。作業効率が高まれば2ヶ月かかるところが1ヶ月で済 む。120万円かかるところが60万円ですむということになる。
ただし、この方法には落とし穴がある。グラ
フィックに長けた者が考える表現手法と、プログラマが考える表現手法では最終的な出来上がりに大きな差ができるのである。つまり、プログラマが考えるグラ
フィック表現なんていうものは長年の知識を溜め込んできたグラフィッカには最終的にはかなわない。そうなると最も無駄を省くにはグラフィッカが最初から設
計をした方がいいようにも思えるが、グラフィッカはプログラムへの配慮の仕方がわからないので、超巨大なデータを作ってきて最終的にメモリに乗りきらない
リスクもあり得る。そうなるともう取り返しがつかない。
そこでいい方法がある。プログラマが自分で作る仮素材をリファイン
してもらうまでの工程を全工程として捉えずに70%の作業工程として考えることにする。つまり用意した素材をリファインしてもらって出来上がっても70点
なのである。そこから何もしなくても70点の出来であれば出荷可能だ。全部を100点にする必要があるかないかは予算によるが、1箇所でも60点を下回っ
たらそれは落第としよう。そうすれば少なくとも60点以上のものは出来上がる。背景に関しては70%を現実的ラインとして構成し時間が足りるのであれば、
残りの30%をグラフィッカの要望に対応する時間としてギリギリまで品質を上げることに費やすこともできる。そのために基本システムに手を入れることも必
要になるかもしれない。手を入れることで基本システムが破綻してしまうこともあるかもしれない。しかし元々合格点である60点以上のリファインはすでに終
わっているのであるから、仮にシステム改造に失敗したとしてもその品質向上の30%分は捨てることでいつでも出荷できる、当然うまくいけばさらに品質を上
げることができる(※)
※ここで気をつけなくてはいけないのはグラフィッカーのモチベー
ション管理である。最悪捨ててしまってもいいものに一生懸命になることはなかなか難しいし、せっかく作ったものは何としても入れて欲しいのが開発者であ
る。ディレクター判断として「入れ込まない」選択をする必要に迫られた時には、そこはディレクターの采配としてはプロジェクト的に許容できるけれども開発
者としてはやるせない「大変遺憾ながら捨てざるをえない、ごめんね」っていうスタンスは崩してはならない。逆の立場なら一生懸命作ったものほど、きっと悲
しいはずだ。
実はこれはアジャイルという開発手法らしい。アジャイルをできるだけ簡単に説明すると、「小さい完成形を何度も作り上げながら大きな完成に持って行く」と説明できる。
次回はこのアジャイルについて少し話を進めたい。
このブログにコメントするにはログインが必要です。
さんログアウト
この記事には許可ユーザしかコメントができません。