第7回 ドキュメントと人間の思考
人間の思考というのは、とてもあやふやなものです。
だからいろいろな情報を処理できるけれど、
しっかりとした土台をどこかにつくらないと、
ぐにゃぐにゃとして企画として先にすすまない。
だから人間は台本とか、スケッチとか、
図面とか、コンテとか、譜面とか、
アイデアを記述する術を開発してきました。
これらは作者の考えを他人に伝えるためものですが、
それと同時に、作者自身が自分の考えと
対話しまとめてゆく土台です。
これらをまとめてドキュメントと呼ぶならば、
作者の発想はこのドキュメントの形式によって
変わってくることになります。
五線符であれば音符、台本であれば文字のセリフ、を
作者は見て考えるように。
ですが、ことゲームは構造がとても複雑です。
人によって操作が異なる(=インタラクション)ので、
時間とか情報量とかが固定できない。
いろいろなゲームがあるので
ドキュメントの形式もとくに決まっていない。
開発メンバーはそのアイデアを
いちばん手ごろにある方法で補おうとします。
チームで仕事を進めるときにいちばん厄介なのは、
この「いちばん手ごろにある方法」の個人差です。
僕たちは、いつもこの「ドキュメント」で苦労します。
|
どう書くかでずいぶん変わる |
ちょうど、ロボットを設計していることを
イメージしてください。
どういうものに出くわしたら、こういう反応をしろ、
という反応を決めて、
それらを10人編成のプログラマーに
手分けさせて作業したと。
それらを再度集めて、
ロボットの思考とするプロジェクトです。
仕様はたとえば、
「野原で犬に出会ったら、
あわてたジェスチャーを繰り返しながらに
とにかく一番近い木の影に隠れなさい」というもの。
イラスト/さえんままこと
条件文というものに慣れている
年長プログラマーはこう解釈しました。
「犬に出会ったら、その場所から瞬時に木を探し、
その距離がいちばん近い木をターゲットとして
方向と移動距離を算定して行動開始せよ。
開始時にはあわてるジェスチャーを再生せよ」と。
ところがいつもロールプレイングゲームばかり
好んできてた若いスタッフは、
これを「物語的」に捉えプログラムしました。
「犬に出会う場所がAだったら200m西に移動する。
B地点だったら100m北に移動する。
C地点だったら50m東北へ移動しろ」と。
|
「解釈」という魔物 |
この二者の違いはなにかというと、
出来上がりを条件として理解したか、
物語として理解したか、の違いです。
もうすこしわかりやすくいうならば、
ロボット的(=可変)か、映画的(=固定)か、です。
さてここで犬と出会う場所の組み合わせが
ほかにもあることが判明したとしましょう。
そのときこの二者が書いたプログラムには
どういう違いがでてくるでしょうか?
後者のプログラマーが書いたプログラムは、
シナリオとしてその分の追加をする必要があります。
それに対し前者はその必要がない。
条件に応じて臨機応変に対応するからです。
つまりこの二者の違いは
さまざまな組み合わせの可能性を持つプログラムにおいて
その納期に大きな影響をもたらします。
そしてその違いはすべてプログラマーの
「解釈」の個人差によるものですが‥‥。
|
おなじ結果を出すふたつの書き方 |
おなじ入力から同じ出力結果が出る。
この再現には二種類の方法があります。
おなじ計算を毎回づつ繰り返すこと、
もうひとつは、最初から対応する回答を記録しておくこと。
前者を計算プログラム、
後者をデータテーブルの参照といいます。
前者は臨機応変であること、後者は高速であること、
がメリットです。
すべてがおなじ条件であるうちは、
どちらの方法にも見た目の違いは出ません。
しかし、すこしでも条件が異なると
あからさまに違いがでてきます。
後者は「対応不能」となる。
「生きている」感じを出すのであれば、
前者である必要があります。
|
脳が“かわらなくなる”瞬間 |
さて、こういった複雑な処理が
膨大にからまってくる複合体がゲームソフトです。
ことシミュレーションは、それが顕著です。
ところが企画段階ではいろいろな要素が重なってくる。
そうすると人間の脳はだんだんと
「わからなく」なってきます。
やがてものごとをできるだけシンプルに
仕事を整理したいと思うようになります。
その時に人間は、整理する方法を物語のように
イメージしやすいものに置き換えたいと
思う癖が出てきます。
その方が紙との相性がいいからです。
|
紙の限界、言葉の限界 |
ドキュメントがどう書かれていても、
文字や言葉で書かれている以上、限界がある。
したがってそれはすべての組み合わせを表現でき得ない。
プログラマーは「かいてあるとおり」だけでは足りない。
そこから条件構造を抽出して
「それ以外の組み合わせに対応可能な形」に
プログラムしなければならない。
これが企画をプログラムとして組み上げてゆく
チームプレイでの要注意部分です。
|
紙でコンピュータープログラムを
シミュレートするための‥‥ |
話がすこしややこしくなりました。
ゲームの台本は、工夫しないと誤解される要因となる、
という話です。
プログラムは複雑な処理を引き受けてくれますが、
ゲームソフトがちゃんとプログラムされて
動き出すまでの間、
制作者は、自分の脳と紙で結果を予測しなければならない。
第三者だけでなく企画者自身も
思考を推し進める上で不都合が発生します。
ですから、企画者はその「五線譜にあたるもの」を
デザインすることから始める必要がある。
これこそが、「ゲームの企画が難しい」となる
決定的な要因だと思います。
それがうまくいかないと、
人は既存のものに引き寄せられてしまう‥‥
|
たとえばこんな紙をつくってみる |
若手スタッフが、
舞台となるこの島内で発生するイベントを、
固定されたイベントのように見える予定表で
配布していたのをみて、止めたことがあります。
たくさんの人間が関わっている本プロジェクトでは、
情報のバトンタッチの途中途中で、
シミュレーション上のイベントが
いつしか物語へ置き換えられるミスに
かなり悩まされました。
「イベントは可動式にしてくれ」
そういって作らせたのが写真のような
短冊のドキュメントです。
これはひとつの例ですけれど
移動するドキュメントを見ることで
スタッフの捉えかたも変化してくるんです。
それくらいゲームっていうのは、
関係者がおなじ出来上がりをイメージするのが
大変なものだと思います。
(つづく) |