【78】「知識ベースの理解」と「構造ベースの理解」

深澤 正俊

　我々はゲーム制作が「好き」かつ「得意」である。多くの場合、これは自分の長所になる。個々ではそれぞれの長所を最大限に活かして、自分の分野で戦っている。

　ゲーム開発は多くの分野の集合で進められる。だから、各分野間の連携が重要だ。そのためには、個々が自分の分野以外でも長所を活かせるようになれば良い。そうすれば他分野にとっても、自分にとっても、そしてプロジェクト全体にとっても恩恵がある。

　どの分野にも何かしらのシステムがある。その上で様々な要素が動いている。また、何かを表現する手法を持ち、関連する他分野がある。従って、分野の特徴は、それぞれのシステムと要素の組み合わせと、表現手法、他分野との関連性によって生じると私は考える。

　よって、自分の長所を他分野で活かすためには、まず自分の専門分野のシステムや要素を分解整理して理解する必要がある。他分野のシステムや要素についても同様に理解したら、それを表現する方法を模索すれば良いと言える。

　システムや要素を分解整理するためには「知識ベースの理解」「構造ベースの理解」という考え方がキーになる。私の定義付けはこうだ。

　例を挙げて説明する。落語の一席に「天狗裁き」という噺がある。筋はこうだ。

　ある日の夕暮れ時。昼寝していた夫を妻が起こす。気持良さそうに寝ていた夫に妻は夢の内容を尋ねる。夫は夢の内容を覚えていない。妻は夫が何か隠し立てしているのではないかと疑い夫婦喧嘩となる。そこに隣人が仲裁に入る。仲裁後、隣人も夢の内容が気になり旦那に夢の内容を尋ねる。同様に喧嘩となる。以下同様に仲裁者が大家、奉行、天狗とエスカレートしていく。そして、最後には…。

　この落語を演じる上で、いかにしてこの噺を覚えるかという点について、2 つの方針がある。

　それぞれに長所短所がある。「知識ベースの理解」であれば確実に一席を勤めあげる事はできるが、客の反応に随時応じる事はできない。「構造ベースの理解」であれば客の反応に応じ喋る内容を随時決められるが、一方で飛んでしまう（舞台が壊れてしまう）リスクを負う。

　もう少し一般的に言うと、「知識ベースの理解」は単一の問題しか取り扱えないが、理解はしやすいという利点がある。「構造ベースの理解」は様々な問題を同一のフレームで理解する事ができるが、そのままでは理解しづらい。という表裏一体の関係があるわけだ。

　「天狗裁き」の場合「旦那と喧嘩対象とのやりとりの一つ一つは同じシステムで内容がエスカレーションしていく」という構造がある。噺そのものはゲームにできないかも知れないが、この構造はゲームの「レベルの難易度が先に進む毎に上がり、盛り上りを演出する」という形で表現する事ができる。同じ構造があると思ったら、多少強引であろうが結びつけてしまって良い。結びつける事により期待した以上の効果が出る（例えば面白い事になる）場合があるからだ。

　異なるものを、何かのゲームシステムにそのまま当てはめて考えるのは良いアイディアだ。我々はゲーム制作が「好き」かつ「得意」なのだから、むしろそうすべき。ここで冒頭の話に戻ることとなる。

　好きな事やストロングポイントを、他の分野に活かせるのは実に気持が良い事だ。これならできる。皆さんも試してみませんか？

　（謝辞：文章に的確なアドバイスを下さいました同僚に感謝を捧げます）