'99冬：玉鬘・プロローグ篇
'00秋：さよなら、ジュピター〜Vanising Points〜
この二作には、実は決定的な差がある。実は99冬の時点では、変数・if機構が作られていなかった‥‥‥ひでぇ話だ。
何でそんなことになったかって？理由は簡単(かどうかは保証しない)。このシステムでは、文字列を表示するのに、ものすごく長い処理を行うから。
え？全然わからない？
よし、字数稼ぎもあるし、ここは詳しく説明しよう。
まず、変数と条件分岐がワンセットなのは判るよね。例えば、感情値が上がったり下がったりしても、「上がったから、こうする」「下がってたから、どうする」みたいな処理がなかったら、何のために感情値が動いたんだか、わかりゃしない。もちろん、シューティングゲームのスコアみたいな、「値は動くけど、こっち(システム)としては知らない」みたいな事は可能よ。でも、そう言うのって殆どない。
条件分岐って、こういうゲームでは「感情値とかの相手・自分ステータスに応じて、相手の行動・話の展開が変化する」って事にだいたい決まっているんだよね。典型的にはif文。ここまでは、いいよね？
第01回目で話したテキスト表示アプリprtestは、大体こんな流れで表示していた。
ファイル->変換(内部文字形式へ)->論理行分割->物理行分割->表示
それに＠スクリプトをくっつけて、ノベル仕様にしたあとの流れがこう。
ファイル->前処理->@命令分離・分析(表示文字列決定)->変換(内部文字形式へ)->論理行分割->物理行分割->表示->画面に転送・@命令実行
この流れのどこに、「変数処理＝値を動かす」と、「条件分岐」を組み込むか、ってのが問題だった。
見れば判るとおり、「どういう文章を表示させるのか」っていうのは早期に決まっちゃう。だから、変数処理と条件分岐を＠命令実行の所に持ってきても、文章は変更できない。
条件分岐ってやつは、第三段階の分離・分析のところに放り込まないと、文章を変更できないわけ。当然、変数処理もそこに持って来ないと、えらい悪辣なバグの元になる。
後知恵ではとっても簡単なんだけど、セーブ・ロードを放り込んだり、選択肢を選べるようにしたり、ＣＤ再生がおかしかったり、シナリオ実行部の山のようなバグに青くなっていた99年の11月12月には、そこまでアタマが回らなかったんだね。
ところで、変数と条件分岐が無いのに、プロローグ篇では一応マルチエンディングを実現している。じゃあ、どうやったわけ？
答えは簡単なんだ。変数とかができる前に作った「選択肢」は、当然変数をアテにするわけにはいかなかった。だから、「選ばれたら、他のファイルを実行する」という方式をとっていたんだ。
勘のいい人なら、もう判るよね。殆どの選択肢はダミーで、大局に影響を与えないんだ。重要な分岐のあとは、同じ様な展開でもファイルを分けて、分岐したあとのファイル実行の流れが重ならないようにしたんだ。
うげー。それって結局、問題の丸投げじゃないかって？そのとおりなんだな。実際、このせいでシナリオ制作の方で、バグとかもでたんだ。そのうえ、変数とかがちゃんと使えるようになった後も、「変数管理の未熟さ」つまり経験不足ってことでいろいろ響いてくるんだけど、それはまた別の話。
良い子は真似しちゃだめだね(人ごとかよ‥‥)。
変数を使えるようにするに当たって、面倒くさいのが嫌いな僕は考えた。「変数を使うのが感情値系統なら、処理は足す・引く・代入の三種類だけで充分で、しかも実数とか、式の評価とかをはしょれる」
どういうことかというと、要するに、
dlen=sqrt( ( 520/(ftc*1.24) )^2-33^2 )
みたいなのは要らない、ってこと。あとは、「変数処理はスクリプトに埋め込むから、そうと判るような印を先頭に持ってくればいい」ってことで、＄記号を変数の頭に付けるようにした。結果、
$haduki + 1
みたいな構文ができた。無論、表向きは「スクリプターなみなさまの、効率的なスクリプト作成のために」ってことになっているけど、ま、ものは言いよう、ってことで。
今週もこのくらい。
アディオス！
|
≪ Prev |
Next ≫ |