前回、構造化プログラミングという話が出てきたので、プログラミングとの比較でゲームブックの記法を際立たせてゆくこともできると思いました。
さて、ある時期、BASIC言語のプログラムとゲームブックのパラグラフ文に類似性を見ることはできたのですが、その後、プログラミングの世界では条件分岐の結果として「番号」の割り当てられた任意の項目へジャンプする方式は廃れています。このことは、ゲームブックがいまも同方式を積極的に採用しているわけを照らし出してくれます。
プログラムというものは一般に、どこで何が起こって今どういうデータが保持されているのかという状態の変化を、人間が追いかけやすいつくりになっていることが良いとされています。これは、正確に動作するプログラムを作ることが重要視されているためですね。そうすると、プログラム中のどの「番号」にでもジャンプできてしまう作りかたは不都合なものでした。何度も遠い番号へジャンプしてしまうようだと追いかけるのは手間になります。
構造化プログラミングという考え方が浸透するにつれて、このジャンプは廃れてゆきました。構造化プログラミングでは、たとえジャンプがあるにせよ、それを人間がぱっと見渡せる程度の小さい範囲に収めます。ジャンプ先がすぐ近くであれば、追いかけるのにそう苦労はありませんよね。大きなアプリケーションを小さなモジュールに分けて、参照関係を局所化してゆく。これは論理的なアウトラインを持つ文章の書き方にも通じるところがあると思います。
正確な動作を目的とするプログラミングの世界では、構造化プログラミングが提案され、ジャンプの局所化が行われました。では、ゲームブックではなぜ同じことが行われてないのでしょう。え？当たり前？そんなことないですよ。ゲームブックを自分で作ってみるとすぐに判るのは、3番から121番へ、75番から13番へジャンプするような細切れのパラグラフを正確に動作するように組み上げるのはとても難しいということです（じっさいバグのあるゲームブックも存在します）。ですので、より正確な動作を実現したいなら、3番からジャンプする先は4番や5番に、75番からジャンプする先は74番や76番にしておいたほうが、より間違いなく作りやすいはずですね。
ゲームブックは正確に作られているに越したことはないと思います。そのうえで、あらためてゲームブックの主な目的のことを考えたとき、それはプログラミングと同じではないのだよ、と導きたい。ゲームブックにおいて近い番号へのジャンプが避けられる傾向にあるのは、近くに置いた場合、ジャンプ先の展開が予めプレイヤーの目に入ってしまうことがあるためです。そのことがゲームブックの体験にどう影響するのか、制作者が制御できないという点ではどちらかというと悪いほうへ働きそうですが、独特の味わいをもたらしている部分でもあります。こうした動作のしくみがすべて見えていることは紙のゲームブックの特性で、良くも悪くも制作者を悩ませてきたところだと思います。
プログラムとパラグラフ文に類似性を見るならば、その後の構造化プログラミングによってゲームブックのパラグラフ構成が照射されます。ゲームブックではジャンプ先は局所化されず、むしろやや追いかけにくい位置におかれます。それと同時に、物語上あとから登場するパラグラフはなるべく後ろに置くといった塩梅も見られるように思います。こうしたことはプログラミングの世界では普通は見られない姿といえます。
