FIX したはずのアレに、なんか直前でぽこぽこポカミスをみつけてしまう罠……。呪いか？そのせいで db4 とかなってますが気にしないで下さい。コンテンツ配信のためにつくられたシステムがこのように「も」←一応 使われるのは、予想されたこととはいえかなりトホホなものが……。でも黙々と作業。 \
……あらゆる点で問題ありまくりのプロジェクトだったけど、それは私の管轄外ということもあり、ここではそのあたりは見なかったことにしてシステム設計的上の問題点と課題を中心に。
ちなみに、作品の内容は、私もまだ断片的にしかみてない（もっぱらFIX作業でしかみてない……）のですが、まず会話はかなりおもしろいとおもうのですよ。というか、詩子たんはオカシすぎると思います。あんまりだー、にも勝るとも劣らない名ゼリフはたくさん聞けます。あと、鈴菜はわりと歴史に残るキャラだと思う。
……まあ、変な人物だらけで構成されたお話なので、好みがかなり激しくわかれるとは思うのですが^^; ストーリーについては、青春だねってことで、いちせさんの感想とかは聞いてみたい気がします。
あとは、曲の発注や使い方のセンスとか、ああ、沢村さんだなぁ、ってかんじ。フラワーズをプレイした人ならかなりわかってくれるはずだ。Beautiful Days とかありえなさすぎるから! \
って、話を戻して。
今回使われたシステムの大きな開発コンセプトとして「スクリプタが演出作業を楽に行なうことができる」というのがありました。概要とか。なお、一連の流れは スクリプトのありかたを考えるにまとまってます m(_ _)m
この目標はある程度成功を修め、前作に比べて短期間で高密度な作業を行なうことができたと考えています。もっとも、使いやすくなった分、演出に凝りすぎて、それによる遅延が発生し、全体の演出バランス密度に差が生じてしまっているという側面もあるのですが、それはどちらかというと、政治層で別途解決するべきお話（クオリティコントロールですね）なのと、他の問題による全体の遅延に比べると影響は小さいので（しわ寄せくるのはスクリプト作業以降なんだけどね）、とりあえずここでは無視しておきます。
このシステムには「環境」というオブジェクト概念があり、これのもつ「舞台」と「時間」の２パラメータで背景画像が決定されるロジックを持っています。で、これで十分だと思ってました。……「夜_照明あり」とか「昼_玄関開く」とか謎の時間指定がいつのまにかＤＢに生えてるのに気づくまでは!!
前者の場合は、ほとんどの場所に照明ありなしが存在していたので「夜」「深夜」と分類しておくのが今考えると妥当でした。気づいたときはスクリプトがくまれまくってて補正は無理でしたが。あと、家の1Fと2Fで照明がついてたりついてなかったのバリエーションがまざっていろいろと大変なことに。
後者は使われてる場所が限定的だったので「響の家玄関」と「響の家玄関ドア開け」とか舞台指定のほうに組み替えて処理しました。こうすると場所的には同じなんだけど、内部的には別のものができてしまってよろしくないというのもあるんですが、変な時間指定が増えるよりましです。一応、入力パネルでの配置的用に「グループ」というパラメータをもたせることで、入力上の混乱を軽減さえるような努力はしてました。でも使い分けミスやっぱあった（涙）
もう一つの問題。時間バリエーションの画像が存在せずロードできない場合は、０番に登録されているものにフォールバックするようにしてあったのですが、そうすると、例えば「夜_照明」な時間指定があるタイミングで、「夜」しか画像が無い舞台に切り替えると、フォールバックして「昼」になってしまうんですね。実作業では「夜」と指定しなおすことでのりきってもらったわけですが、そうすると、時間指定の連続性がずたずたになり、指定を最低限にする意味が無くなってしまうのでした……
結論は「舞台」は「環境」の１パラメータとして扱うのは適当ではない、ということになります。「舞台」を「キャラクタ」と同様の１つのオブジェクトとし、個別に状態管理すれば、「戸があいている/あいてない」「１階だけあかりがついている」「靴がある/ない」といった「舞台固有の『状況』」を汎用かつシンプルに管理できます。あ、あと、こうすると「レイヤ」を「舞台」にバインドとかも容易にできるのか。
今回のシステムで「環境レイヤ」については、環境配下のオブジェクトとして分離したので、キャラクタと同様に、[オブジェクト名 メソッド] の記述ができるようになっていたわけですが、音楽はあくまで「環境」の一部なため、[環境 再生 BGM001] といったスタイルでの制御になっていました。
これ自体に特にこれといった混乱は生じなかったのですが、そもそも現時点でも、内部的には複数のサウンドトラックを「環境」が個別管理してるわけで、それなら独立したオブジェクトにしてしまって、配下オブジェクト管理の枠内で一括処理したほうが、全体ロジックもすっきりします。同様に、「気象」「スクリプト」などの環境機能も同様に独立化の方向です。
これに伴い「環境」が持っていた「イベント絵表示」の機能は舞台消去/単独表示のグループをつくることで対応可能なため「環境レイヤ」に吸収されて消えました。
アイデアは、音楽データの「モード」とよんでいた概念からきてます。 BGM とか SE とか、モード別に暗黙の動作、複数再生可能、とか、スキップされても音が消えない、とか指定できるようになってました。概念的に同じなので用語は統一しておかないとだめかな。
このシステムには「シーン」と「行」という概念があり、また、環境系のオブジェクトを「更新」しない限り画面に内部状態を反映しない、というルールで運用することで、任意の「シーン」の任意の「行」をいつでも再現できるようになっています
「シーン」を操作する「シーンプレイヤ」は、操作対象になる「環境」をもっており、「シーン」を再生するときには必ずその「環境」をリセットしてから処理を開始します。画面更新無しで瞬間再生することで目的行へのジャンプを実現するのですが、このリセットを担保に状態再現までにかかる時間があまり長くならないことが保証しているわけです。
なお、分岐制御はシーン単位で行なっており、未読管理は「あるシーンを何行目までよんでいるか」で行われています。ちなみに、選択肢分岐などのちょっとした分岐のためには「前のシーンから画面を再構築する」機能で対応してます。
この仕組み自体には特には問題はないのですが、「シーン」と「環境」の関係が、逆のほうが実はスクリプト的には良いのではないか、ということに最近気づきました。
いわゆる「回想」の動作を考えてみます。現行システムでは、シーン内部の記述は次のようになります。
ここで、この舞台を実現している「環境」について考えます。現行システムでは「環境」はシングルトン的に使っているわけですが、システム的には別にいくらでも存在できるものです。これを活用して「カット」の概念を導入します。
ここまでかけばおわかりでしょう。先ほどの回想シーンの場合は、「本体」とそれから呼び出される「回想シーン」の２つの「カット」を準備すれば良いわけです。
カットのスタック動作に伴う環境の復帰処理はシステムの範疇となり、記述量の減少＋より部分修正に強いスクリプト環境を提供可能になるわけです。
原則論として、１カット中では初期設定した舞台＋時間は変更しないというのが正義でしょう。このための初期設定は、スクリプト的に行なうのではなく、カット情報の保持するパラメータにします。また、カット切り替えのトランジションも、同様にカット情報のパラメータ扱いにします。そうすることで、カット単位のスクリプトの内容とは全く無関係に、カット切り替わり時のトランジションの統括ができるようになります。全体のトランジションの使い方の傾向を調べて調整したりするときにとても便利、なはず。
暫定で「カット」って用語つかったけど、どうですかね。映画とかの演出の本買ってきて類似用語さがしたほうがいいかしら……
そうそう、今回の反省の主眼は「ケアレスミスを防止できなかった」「チェック作業で手間どった」です。演出的な課題は旧版で達成、作業軽減の課題はとりあえずこの版である程度達成。しかしながら、作業ミスのリカバリ、という面では、かなりいまいちだったのでした。今まではあんまり顕在化してなかったんだよなぁ。
システムの欠陥から来るバグは、悪いのは俺、ってことで、情けなくはなりますが、悲しくはなりません。まあ、直しがいもあるってものです（ぇー。それに対して、作業者のミステイクや素材の問題に由来するバグ、パッケージ作業者的には、単調な修正作業（原因は見た瞬間にわかる）の手間が増えるだけなので、かなり悲しいのです。
多くは実際にプレイして確認するしかなく、テスターからあがってくるバグリストを見る→再現性を確認→修正→バグリスト更新→次のターンでテスターに再チェックしてもらう、という手順をふんで処理されます。たいていは見た瞬間に原因も対策もわかるケアレスミスなので直すのは一瞬なのですが、リストの更新とか、通知とか、つみかさなると、どんどん時間くわれて、究極的には俺の睡眠時間を削る要因になるのですよ。むきー。
怠惰を美徳とする者のはしくれとしては、これは許されざる事態なのです!!
ミステイクの発生を０にすることは無理ですが、システム的に減らす＆リカバリを容易にする＆スクリプタに確認しやすくすることで、組み込み屋を仕事から解放するのは可能ってことで。
あ、システムのパフォーマンス的な問題など、基本技術関係は、既に私の能力限界を越えてしまっているので、さっくり別体系に乗り換え予定だったりします^^; 具体的には吉里吉里ベースへの以降。けんじょさんにフォトショップ互換合成を書いてもらって寄贈したので、現在の版（ベータのほう）に既にはいってるし、現システムに無い部分（ブラウザ回りとか DB処理とか）はプラグインかいちゃえばいいし、安定した言語系＋レイヤ合成系＋サウンド系を自分の腕とミスを心配せずに使えるのは幸せだよね。
現行版のシステムでは、シナリオ格納部をDB化しました、が、演出制御を行なうコマンドの部分は、従来版のシステムを引き継いで、単純なバイトコードに置換して保持するようにしていました。これは特に必要があったからではなく、単に今までのコードそのままですぐうごいていいよね、というそれだけのことだったのですが、ああ、この仕様にした過去の俺がうらめしい……。なんで全部構造を設計しなおして、コマンド系も全部DB化しなかったんだか。
チェック作業の基本は「プレイする」なことにかわりはありませんが、「チェック処理を行なうプログラム」を併用すると、その効率が段違いになります。単純で強力なのが「全文検索」。しかし、コマンド部はバイトコード化しているため、単純に検索することができません。コマンドを一度逆変換して、元のテキストに戻す処理が必要です。これをはさむと処理が遅くて遅くて……。テキストのみの検索だと十数秒でおわるのが、コマンドふくめて検索すると数分単位で時間が……。むきー。コマンド構造がきちんとなってれば、「特定のキャラクタのこのコマンドの部分を検索して置換する」とかそんなことも超簡単にできたはずなのに！
ちなみに、ボイスデータとかの設定の部分はDB化の対象なので、ボイスのはめミス部分の特定、とかにかなり役にたちました。 \
ってことで、次の世代ではもう全面的にDB化確定です。
ただ、DB化そのものにも問題があります。DBファイルがでかいの１つなので「更新」のための処理がかなりいまいちなことに……。まあ、あんま更新しないだろってことでこうしんたですが、甘すぎた……。ただ、開発作業中の、「汎用DB」の圧倒的優位性は揺らぐことはないので、「作業時」と「リリース時」で扱いを変えるとかそういった方向でなんとかできないか検討中です。いいアイデア募集中。
夏音ではこんなかんじのコンパネからコマンドを決定して入力させてます。
たいした機能ではなくて、よーするにスクリプタのかわりにコマンドとパラメータの体系をおぼえておいてくれるだけのものです。これを操作すると、画面に状態が反映されて「入力」でそれを実現するコマンド文字列が生成されてシーン制御用のパネルに入力され、そこでコマンドを登録することができます。
これ自体はスクリプタには好評なのでした。コマンドおぼえなくていいの重要。
で、これだけを使うかぎり、特にミスはおこらないはず、なのですが、往々にしてパターン的なものはこぴぺか直接入力で作業したりするので、そこでミスがおこります（汗）
あと、コマンド登録時に、特に直前の状態との比較を行なったりはしていないので「多重な指定」がいともあっさりできてしまうという問題があるのでした。同じ指定が２度少しはなれてある場合、指定ミスなどに気づいて前者を直しても、後者のほうを直し忘れて結局ミスがのこるという事態が発生するわけです orz このあたりは、今回の作業では「スクリプタの記憶と注意にたよる」以上のことはしていませんでした。
スクリプタさんも人間、これにはおのずと限界があります。そういうわけで、次の世代では……
ただこうすると不便になる点もあります。その点の対策については次の項目
まずはこれですね。スクリプタから要望があったんだけど答えきれなかったのでした＞「マクロ機能」。単純なこぴぺ的なマクロならわりと単純にできたんですが、それだと適当にテキストエディタとかからはりつけるのとあんまかわらないので、結局保留にしたままそのままだったという……ごめん（汗）。
コマンド系もDBにそって構造化しますから、それにあわせたマクロ、たとえば、ターゲットになるキャラクタだけ変えて展開、とかできるんじゃないかなってことでいろいろと思案中。
置換は、特定の条件をもつ部分を、指定した範囲で一括で処理、とかそういったものですね。これもどんな置換パターンをどんんなインターフェースでつくればいいのか思案中。
追加:あと一覧性が悪いからなんとかならんかと文句が（汗）＞今の入力用システム
結局、インターフェースのレベルがかみあってないのが問題なのです。
最強のこぴぺ環境とは、それは、テキストエディタ！ということで、テキスト形式への export / import は、現行版よりもすこし高度な形で完備する予定ではあるのですが（現行版は一部情報がおちちゃうので初期時しかつかえない）、加えてこんなのできると楽しいかなぁと（妄想レベル）
プレーンテキストよりは構造度高くてうれしいよねってことで淡い期待を＞えくせるたん
移動用の曲線とかエディットするモードあるとたのしいかも。関数による動作でパラメータの try & error で用はたせるんですが、視覚的にでるとわかりやすいよねってことで。現行システムだと、縦振動とか横振動とかいろいろありますが、あれの具体的な移動って直感ではやっぱなかなか大変でしょうから。
Oracle の Oracle Collaboration Suite がすごく面白そうだ。さわってみたいなー、評価版ないかなー。でも仮に評価しても 100 ユーザからだと買えないねー^^; せめて 10ユーザからに……。
MS 位置づけ的には、 Win Server + SQL Server + Exchange Server + Project Server + SharePoint Portal Server + Live Communication Server ってのを狙ったものですな。勝負する気まんまんだねー。
MS のは個別の機能的にはすごいところがあっても、値段が高い上に（CALもいるし……）、つくられてる部署と世代が違うからか操作感とかがけっこうばらばらだし、けっこういい勝負できちゃうんじゃないかなぁ。あ、MS には Office をクライアントにできる強みがあるか。
ちなみに MS で普通にこの構成すると死ぬほど金かかりますが、 １０ユーザまでだと超安い罠。そか、一応この製品ラインナップは考えた上でこうなってるんだ……。Oracle さん! 中小狙うにはやっぱ 10人限定5万円からですよ! （ぉ
技術的には SMB まわりと WebDAV まわりがどう実装されてるのかが気になります＞Oracle CS
あ、oracle.com の OTN にダウンロードあるっぽ。これどういう位置づけなんだっけな＾＾；まあ、日本のほうにも近いうちに来るだろうからそれまっとこう。
