第７回　ドキュメントと人間の思考


人間の思考というのは、とてもあやふやなものです。
だからいろいろな情報を処理できるけれど、
しっかりとした土台をどこかにつくらないと、
ぐにゃぐにゃとして企画として先にすすまない。
だから人間は台本とか、スケッチとか、
図面とか、コンテとか、譜面とか、
アイデアを記述する術を開発してきました。
これらは作者の考えを他人に伝えるためものですが、
それと同時に、作者自身が自分の考えと
対話しまとめてゆく土台です。
これらをまとめてドキュメントと呼ぶならば、
作者の発想はこのドキュメントの形式によって
変わってくることになります。
五線符であれば音符、台本であれば文字のセリフ、を
作者は見て考えるように。
ですが、ことゲームは構造がとても複雑です。
人によって操作が異なる（＝インタラクション）ので、
時間とか情報量とかが固定できない。
いろいろなゲームがあるので
ドキュメントの形式もとくに決まっていない。
開発メンバーはそのアイデアを
いちばん手ごろにある方法で補おうとします。
チームで仕事を進めるときにいちばん厄介なのは、
この「いちばん手ごろにある方法」の個人差です。
僕たちは、いつもこの「ドキュメント」で苦労します。

どう書くかでずいぶん変わる

ちょうど、ロボットを設計していることを
イメージしてください。
どういうものに出くわしたら、こういう反応をしろ、
という反応を決めて、
それらを10人編成のプログラマーに
手分けさせて作業したと。
それらを再度集めて、
ロボットの思考とするプロジェクトです。
仕様はたとえば、
「野原で犬に出会ったら、
　あわてたジェスチャーを繰り返しながらに
　とにかく一番近い木の影に隠れなさい」というもの。

イラスト/さえんままこと

条件文というものに慣れている
年長プログラマーはこう解釈しました。
「犬に出会ったら、その場所から瞬時に木を探し、
　その距離がいちばん近い木をターゲットとして
　方向と移動距離を算定して行動開始せよ。
　開始時にはあわてるジェスチャーを再生せよ」と。

ところがいつもロールプレイングゲームばかり
好んできてた若いスタッフは、
これを「物語的」に捉えプログラムしました。
「犬に出会う場所がAだったら200m西に移動する。
　B地点だったら100m北に移動する。
　C地点だったら50m東北へ移動しろ」と。

「解釈」という魔物

この二者の違いはなにかというと、
出来上がりを条件として理解したか、
物語として理解したか、の違いです。
もうすこしわかりやすくいうならば、
ロボット的（＝可変）か、映画的（＝固定）か、です。
さてここで犬と出会う場所の組み合わせが
ほかにもあることが判明したとしましょう。
そのときこの二者が書いたプログラムには
どういう違いがでてくるでしょうか？
後者のプログラマーが書いたプログラムは、
シナリオとしてその分の追加をする必要があります。
それに対し前者はその必要がない。
条件に応じて臨機応変に対応するからです。
つまりこの二者の違いは
さまざまな組み合わせの可能性を持つプログラムにおいて
その納期に大きな影響をもたらします。
そしてその違いはすべてプログラマーの
「解釈」の個人差によるものですが‥‥。

おなじ結果を出すふたつの書き方

おなじ入力から同じ出力結果が出る。
この再現には二種類の方法があります。
おなじ計算を毎回づつ繰り返すこと、
もうひとつは、最初から対応する回答を記録しておくこと。
前者を計算プログラム、
後者をデータテーブルの参照といいます。
前者は臨機応変であること、後者は高速であること、
がメリットです。
すべてがおなじ条件であるうちは、
どちらの方法にも見た目の違いは出ません。
しかし、すこしでも条件が異なると
あからさまに違いがでてきます。
後者は「対応不能」となる。
「生きている」感じを出すのであれば、
前者である必要があります。

脳が“かわらなくなる”瞬間

さて、こういった複雑な処理が
膨大にからまってくる複合体がゲームソフトです。
ことシミュレーションは、それが顕著です。
ところが企画段階ではいろいろな要素が重なってくる。
そうすると人間の脳はだんだんと
「わからなく」なってきます。
やがてものごとをできるだけシンプルに
仕事を整理したいと思うようになります。
その時に人間は、整理する方法を物語のように
イメージしやすいものに置き換えたいと
思う癖が出てきます。
その方が紙との相性がいいからです。

紙の限界、言葉の限界

ドキュメントがどう書かれていても、
文字や言葉で書かれている以上、限界がある。
したがってそれはすべての組み合わせを表現でき得ない。
プログラマーは「かいてあるとおり」だけでは足りない。
そこから条件構造を抽出して
「それ以外の組み合わせに対応可能な形」に
プログラムしなければならない。
これが企画をプログラムとして組み上げてゆく
チームプレイでの要注意部分です。

紙でコンピュータープログラムを シミュレートするための‥‥

話がすこしややこしくなりました。
ゲームの台本は、工夫しないと誤解される要因となる、
という話です。
プログラムは複雑な処理を引き受けてくれますが、
ゲームソフトがちゃんとプログラムされて
動き出すまでの間、
制作者は、自分の脳と紙で結果を予測しなければならない。
第三者だけでなく企画者自身も
思考を推し進める上で不都合が発生します。
ですから、企画者はその「五線譜にあたるもの」を
デザインすることから始める必要がある。
これこそが、「ゲームの企画が難しい」となる
決定的な要因だと思います。
それがうまくいかないと、
人は既存のものに引き寄せられてしまう‥‥

たとえばこんな紙をつくってみる

若手スタッフが、
舞台となるこの島内で発生するイベントを、
固定されたイベントのように見える予定表で
配布していたのをみて、止めたことがあります。
たくさんの人間が関わっている本プロジェクトでは、
情報のバトンタッチの途中途中で、
シミュレーション上のイベントが
いつしか物語へ置き換えられるミスに
かなり悩まされました。
「イベントは可動式にしてくれ」
そういって作らせたのが写真のような
短冊のドキュメントです。
これはひとつの例ですけれど
移動するドキュメントを見ることで
スタッフの捉えかたも変化してくるんです。
それくらいゲームっていうのは、
関係者がおなじ出来上がりをイメージするのが
大変なものだと思います。