したはずのアレに、なんか直前でぽこぽこポカミスをみつけてしまう罠......。かなってますが気にしないで下さい。使われるのは、予想されたこととはいえかなりトホホなものが......。\......あらゆる点で問題ありまくりのプロジェクトだったけど、それは私の管轄外ということもあり、ここではそのあたりは見なかったことにしてシステム設計的上の問題点と課題を中心に。ちなみに、作品の内容は、私もまだ断片的にしかみてない(もっぱらFIX作業でしかみてない......)のですが、まず会話はかなりおもしろいとおもうのですよ。いうか、詩子たんはオカシすぎると思います。勝るとも劣らない名ゼリフはたくさん聞けます。あと、鈴菜はわりと歴史に残るキャラだと思う。ストーリーについては、青春だねってことで、いちせさんの感想とかは聞いてみたい気がします。あとは、曲の発注や使い方のセンスとか、ああ、沢村さんだなぁ、ってかんじ。フラワーズをプレイした人ならかなりわかってくれるはずだ。\▽システム問題点って、話を戻して。今回使われたシステムの大きな開発コンセプトとして「スクリプタが演出作業を楽に行なうことができる」というのがありました。_)mこの目標はある程度成功を修め、前作に比べて短期間で高密度な作業を行なうことができたと考えています。使いやすくなった分、演出に凝りすぎて、それによる遅延が発生し、全体の演出バランス密度に差が生じてしまっているという側面もあるのですが、それはどちらかというと、政治層で別途解決するべきお話(クオリティコントロールですね)なのと、他の問題による全体の遅延に比べると影響は小さいので(しわ寄せくるのはスクリプト作業以降なんだけどね)、とりあえずここでは無視しておきます。-オブジェクト概念設計の問題点-「舞台」パラメータに関する問題このシステムには「環境」というオブジェクト概念があり、これのもつ「舞台」と「時間」の2パラメータで背景画像が決定されるロジックを持っています。これで十分だと思ってました。......「夜_照明あり」とか「昼_玄関開く」とか謎の時間指定がいつのまにかDBに生えてるのに気づくまでは!!前者の場合は、ほとんどの場所に照明ありなしが存在していたので「夜」「深夜」と分類しておくのが今考えると妥当でした。気づいたときはスクリプトがくまれまくってて補正は無理でしたが。あと、家の1Fと2Fで照明がついてたりついてなかったのバリエーションがまざっていろいろと大変なことに。後者は使われてる場所が限定的だったので「響の家玄関」と「響の家玄関ドア開け」とか舞台指定のほうに組み替えて処理しました。すると場所的には同じなんだけど、内部的には別のものができてしまってよろしくないというのもあるんですが、変な時間指定が増えるよりましです。一応、入力パネルでの配置的用に「グループ」というパラメータをもたせることで、入力上の混乱を軽減さえるような努力はしてました。使い分けミスやっぱあった(涙)もう一つの問題。時間バリエーションの画像が存在せずロードできない場合は、0番に登録されているものにフォールバックするようにしてあったのですが、そうすると、例えば「夜_照明」な時間指定があるタイミングで、「夜」しか画像が無い舞台に切り替えると、フォールバックして「昼」になってしまうんですね。実作業では「夜」と指定しなおすことでのりきってもらったわけですが、そうすると、時間指定の連続性がずたずたになり、指定を最低限にする意味が無くなってしまうのでした......結論は「舞台」は「環境」の1パラメータとして扱うのは適当ではない、ということになります。「舞台」を「キャラクタ」と同様の1つのオブジェクトとし、個別に状態管理すれば、「戸があいている/あいてない」「1階だけあかりがついている」「靴がある/ない」といった「舞台固有の『状況』」を汎用かつシンプルに管理できます。あ、あと、こうすると「レイヤ」を「舞台」にバインドとかも容易にできるのか。「時間」は「環境」配下のパラメータとする「環境」はそれに属する「舞台」オブジェクトを持つことができる。「舞台」オブジェクトは環境中に複数存在できるが、1度に1つだけ表示状態を得ることができる。「環境」に「時間」を指定すると、全ての「舞台」オブジェクトの「状況」はリセットされる。「舞台」は「状況」のありうる組み合わせ×「時間」分の画像による背景を保持する。実際の画像と存在しない場合のフォールバックは個別指定できる。ここまで複雑に規定しなくていいじゃん!という意見もあるかもなのですが、舞台指定ごとに時間指定もさしかえが必要になると、ミスの修正とチェックが、激しくめんどくさくなる、というのが今回えられた経験則です(汗)。そんなことはそもそも起り得ないロジックにするのが正義。スクリプタよりもデバッガさんが泣く目にあうのでした。修正作業的に難しいことはなにもないんだけど、とにかくめんどい。再生機能は「環境」オブジェクトの一機能として実装されていたのですが、これ、よくよく考えると、一貫性がとれてません。いったスタイルでの制御になっていました。これ自体に特にこれといった混乱は生じなかったのですが、そもそも現時点でも、内部的には複数のサウンドトラックを「環境」が個別管理してるわけで、それなら独立したオブジェクトにしてしまって、配下オブジェクト管理の枠内で一括処理したほうが、全体ロジックもすっきりします。同様に、「気象」「スクリプト」などの環境機能も同様に独立化の方向です。オブジェクトのグルーピング処理これは開発中に仕様変更されて実現済みなのですが、当初想定との差ということで記録。制御の記述がわりとめんどくさいということが判明したので、登録する段階でグループ別に暗黙の動作を規定できるようにしました。「舞台」or「時間」が切り替わったときに消える/消えない同じグループのレイヤが同時に多数存在できる/できないこれに伴い「環境」が持っていた「イベント絵表示」の機能は舞台消去/単独表示のグループをつくることで対応可能なため「環境レイヤ」に吸収されて消えました。アイデアは、音楽データの「モード」とよんでいた概念からきてます。スキップされても音が消えない、とか指定できるようになってました。概念的に同じなので用語は統一しておかないとだめかな。-シーン概念の問題点-このシステムには「シーン」と「行」という概念があり、また、環境系のオブジェクトを「更新」しない限り画面に内部状態を反映しない、というルールで運用することで、任意の「シーン」の任意の「行」をいつでも再現できるようになっています「シーン」を操作する「シーンプレイヤ」は、操作対象になる「環境」をもっており、「シーン」を再生するときには必ずその「環境」をリセットしてから処理を開始します。画面更新無しで瞬間再生することで目的行へのジャンプを実現するのですが、このリセットを担保に状態再現までにかかる時間があまり長くならないことが保証しているわけです。分岐制御はシーン単位で行なっており、未読管理は「あるシーンを何行目までよんでいるか」で行われています。ちなみに、選択肢分岐などのちょっとした分岐のためには「前のシーンから画面を再構築する」機能で対応してます。この仕組み自体には特には問題はないのですが、「シーン」と「環境」の関係が、逆のほうが実はスクリプト的には良いのではないか、ということに最近気づきました。いわゆる「回想」の動作を考えてみます。現行システムでは、シーン内部の記述は次のようになります。キャラクタ会話のつづきつまり、「回想の前後」とは、「3つのシーンの切り替え」ということです。前の状態を変更した場合は、かならず後の状態もあわせて変更しないと画面表示に矛盾が生じます。この修正はめんどくさい上に、ミスを招きがちです。ここで、この舞台を実現している「環境」について考えます。現行システムでは「環境」はシングルトン的に使っているわけですが、システム的には別にいくらでも存在できるものです。これを活用して「カット」の概念を導入します。「カット」は固有の「環境」をもつ。「カット」開始時に「環境」を生成し、「カット」終了時に開放する。「シーン」は複数の「カット」を連続実行する。「カット」が切り替わる部分ではトランジェントを指定できる。「カット」の途中で別の「カット」を生成してスタック的に呼び出すことができる。「カット」が切り替わる部分ではトランジェントを指定できる。ここまでかけばおわかりでしょう。先ほどの回想シーンの場合は、「本体」とそれから呼び出される「回想シーン」の2つの「カット」を準備すれば良いわけです。