C#

　文字列を取るコンストラクタを持ったクラスがある。文字列が三文字以内でない場合、エラーになるとする。

　このコンストラクタに文字列定数を入れる場合、エラーであることは実行前にわかる。この場合のエラーを実行前に全部発見することは出来るだろうか。

　ILを見るのはどうだろう。コンパイラやCLRの仕様変更で使えなくなりかねない。多分大丈夫ではあるけど、もっといい方法もあるだろう。

void Hoge()
{
  Str str = new Str("四文字以上はアウトです");
}

　こんな風に使うわけだが、.NET FrameworkのAPIだけではこれは捕まえられないようだ。ILのバイト列は取れるから、自分でがんばって解釈してコンストラクタ呼び出しの前のldstrを捕まえればいいのだろうけど、.NET FrameworkのSide by Side実行というのもAPIがちゃんとしてないのも、それが仕様変更で正しくなくなる可能性を考えているからだろう。

　俺が考え付く限りでは、ソースコードを読んで、new Str("hogehoge")を探して、hogehogeが三文字以内であるかをチェックするアプリを、ビルド成功後に走らせるという形になる。しかしこれでは国際化やなんやらかんやらで文字列を直接埋め込めない場合に困ったことになったりならなかったり。同じ定文字列を使う場合にローカル変数に入れて…とかの場合困ったことになったり。

　ゲットスクリプトdllというのを作って、そのdllの中にStrクラスを作り、コンストラクタをinternalにして直接コンストラクタを呼び出せないようにする。そして、

void Hoge()
{
  Str str = GetScript("Str:三文字以内だよ");
}

　GetScriptの中は文字列定数じゃないとエラー（になるアプリを走らせる）。ソースコードを読んで、GetScriptの中身を解釈し、三文字以内かどうかを調べる。その解釈のためにはGetScriptを実際に走らせて例外が飛ぶかどうか調べればいい。使いまわしなり国際化なりにはGetScriptの中身で対応する。

　そうまでする意味があるのか、というのもまた問題だ。実行時のエラーでよければこんなことする必要はない。

　ノベルゲームだと実行が止まる一番大きな原因は画像ファイル名の指定ミスで、そんなのは実行前に間違いであることが分かる。しかしファイル名のミスをコンパイラが捕捉する機能はない。ファイルの数がそんなに多くなく、たくさん使いまわされるなら、

public const string FileName = "FileName.jpg";

　こんな感じでコンパイラの静的世界に落とし込めば、代入する文字列を間違えない限りうまく動くことが保障されるが、ものすごい数になるのでいちいち作っていられない。ファイル名に当たるものを読んでファイルが実際に存在することを確認した方が楽だ。それを実行前に調べるにはチェックルーチンを自作するほかない。

　もっと問題になるのは、単純な選択肢方式のノベルゲーは実行パスによって動作が変わるということだ。実行パスは指数関数的に増えていき、全てを実際に動作させてチェックすることが不可能になる。「選択肢によって実行パスが変わり、実行パスによって動作が変わるのを実際に実行してみて確認する」という方式ではある複雑さを超えると破綻する。

　なのでどうするのかというのが一番大きな問題だ。全ての実行パスを探索し、条件を満たすかどうかを調べるなんていう機能はコンパイラにはないので、自作せざるを得ない。実行パスが指数関数的に増えるといっても、人間が物語として作れる量なんてたかがしれてるのでコンピュータにやらせれば確認は可能だ。しかし自作できたところで、条件を間違えて記述している可能性は否定できない。それを実行して確認するようになったら元の木阿弥だ。

　おそらく、実行パスによって変化するというモデルの物語は、システムとして先はない。自作したチェック機構で実行前にチェックが可能なモデルの物語でなければならない。実行してのチェックは、誤字脱字などのパスによらないミスだけのチェックでなければならない。

　つまり、パスによって変化せず、チェック可能なある規則によってしか変化しないものの組み合わせだけでどうすれば物語が作れるかという問題になる。選択によって並行世界にどんどん移行していくようなモデルは捨てなければならない。選択肢の意味論が平行世界への移行だと何でもありになってしまう。そうしたらチェックは出来ない。

　選択肢は規則の中である意味を持つものでづけられなければならない。それを選択しても、その規則の中のある状態に移行するだけだ。

　物語のモデルである以上、規則内のある状態はあるテキストと対応する(別にテキストじゃなくても動画でも何でもいいが)。状態:テキストはN:1だ。別に1:1でもかまわないが。テキストは人間の中である意味を持ち、状態はその意味と対応するものでなければ読者にとって状態の以降が意味不明のものになる。状態は物語世界の意味と対応するものでなければならない。つまり規則は物語世界の規則から逆算されるか、規則に従って物語を書く形になる。物語世界の規則から逆算する形ではその規則が静的チェック可能なものにはならない公算が高いので、規則を先に作る形になる。

　テキストの意味をコンピュータにきちんと把握させるなんてことは不可能なので、状態の移行がテキストの意味を完全には反映してくれないことについては、テキストに泣いてもらわなければならない。つまりテキストもまた規則の中で意味を持つことだけしか語れない。規則の中のテキストは、どうしても自由に書いたテキストよりも作れる意味が限られる。規則の中でテキストにどれだけ自由を与えられるか、特に、物語的感興を起こさせるテキストを書く自由を与えられるかが規則にとって最も重要なことになる。

　つまり規則は物語的感興を起こさせられる規則、つまり一般に物語の規則とされているものに近いものでなければならない。物語の規則なんていう形がありそうで全然ない物をプログラムに落とし込むのは非常に難しい。どのような単純化を加えて実装可能なものにするかが問題になる。必要なのは、規則が物語的感興を起こさせるものであることと、規則の中の各状態がテキストの意味と対応すること。