玉鬘計画は98年に始まったと見るのが妥当である。しかし、本格的に始動したのは、99年初夏であると言えよう。
玉鬘計画、その神代の時代。そもそもビジュアルノベルというシステムで行こう、と決まった頃。僕はシステムについて考えねばならない立場にあった(無論、今もだが)。
その中でも問題となったのは、スクリプト仕様だった。若干変遷を追う。
つまり要するにアレだ。演出、文字出力なんかをサポートするようなライブラリを僕が書いておく。スクリプターは「Ｃ＋＋で」そのライブラリを使用しながら演出していけばいい、という話。文法がC++であるということと、コンパイルが必要であるということが総てをダメにしていたが、今から考えればそれを除けば、そんなに悪くないと思う。除けば殆ど何も残らないという話もあったが。いずれにせよ安直な方式だった。 多分Simple is the bestを誤解していたのだろう。
ライブラリ支援論というスクリプトに対しては何ら支援されない方式は、様々な問題を抱えていることもあり、マトモに実装されないうちに沈んだ。(Cの教育の問題、デバッグの難しさの問題、コンパイラの入手の問題など)
と、言うよりかは、そのような方式が提案されたということ自体、恥じねばならない呆れたシステムであった。
それに対して提案されたのが、中間方式である。
要するに専用エディタを作って、そのエディタの出力を実行ファイルに食わせよう、というものである。利点としては、
1.エディタさえ作ってしまえば、その出力の質は問題にならない。
というものであったが、肝心のエディタが今ひとつのできだった。それに、実際やってみると「特殊な出力」をする事で結局端折れるのは実行ファイルのパーザだけだった。それなら、エディタの機能と実行ファイルの機能と同じ様なものを、平行して二重に管理しなければいけないのは、ちょっと遠慮したかった。
エディタが前提の中間方式が、そのエディタの質で敗れ去った後。「手書きもできる」XMLが浮上してきた。あたかもHTMLの如くシナリオを作成できるはずだった。DNMLのパクリ、XML信者の純化策ともいえよう。「不備のあるエディタ出力を手動で直せるのでは？」という予測を立てていた。しかし、XMLでエディタをつくるのはとてつもなく大変で、まるで(というか殆ど)HTMLエディタを作るのと変わらない、と気づくのに、そう長くはかからなかった。おまけにテスト文書を書いて、XMLを手でどうこうするのは、つくづく面倒くさいと思い知った。
「エディタでも書けるし、その不備は手書くこともできる」という構想は、結局この場合「エディタは使えないし、手書きするには面倒すぎる」というどっちつかずの状態に陥った。
幸いなことではないが、この辺りの時点で、原作部門の遅れもあり、スクリプト仕様は混迷に陥る。
99年6月頃。なにを思ったのかはしらないが、スクリプトのことは棚上げして、テキストを表示させるミニ・アプリケーションの作成に取りかかった。恐らく、別方向から攻めてみよう、などと考えたに違いない。
あるいは、もっと別の、プログラマ魂を慰めてくれるような自慰行為であったという説は否定できない。
禁則処理、日欧スペース、両揃え文などをサポートする文字列表示アプリケーション、prtest。純テキストを綺麗に表示することを目的とした、改行、改頁毎にマウス入力をまつだけの、バグ多きオブジェクト過多な代物であった。なにしろ、改行文字クラスまで存在したのだから。
prtestはあくまでテストアプリなので、これを流用しようとなると、結構なコストがかかることは、今では予想できる。しかし当時は７月の終わり頃に、ようやっとテキスト表示ができたくらいで、この先もそんなに難なくこなせるだろう、と思っていた。
無論、甘かった。つくづく、甘かった。
まず、文字列表示だけではなく、制御命令をどのように出すのか、が問題となった。prtestが可変スペースを採用していること、テストアプリの入力がテキストファイルであった事などから、スクリプトメインで文字出力をprint等を用いるのは具合が悪かった。
結果として、普通のテキストの中に「@wait」等、命令の頭に＠を付ける命令を埋め込むようになった。余談だが、Shift_JISの2byte目が@になる場合もあり、その辺りの処理がいい加減だったルーチンがバグったりして修羅場の際に大きな禍根を残す。
このようにして、現在の「＠命令＄変数テキスト埋め込み方式」の基本が晴れて日の目を見ることとなったのである。(大げさすぎ)
‥‥そういえば、HTML+JavaScriptでIEを使ったノベルという案もあったな。
今週はこのくらい。
|
Next ≫ |