つづカットのスタック動作に伴う環境の復帰処理はシステムの範疇となり、記述量の減少+より部分修正に強いスクリプト環境を提供可能になるわけです。原則論として、1カット中では初期設定した舞台+時間は変更しないというのが正義でしょう。このための初期設定は、スクリプト的に行なうのではなく、カット情報の保持するパラメータにします。カット切り替えのトランジションも、同様にカット情報のパラメータ扱いにします。することで、カット単位のスクリプトの内容とは全く無関係に、カット切り替わり時のトランジションの統括ができるようになります。全体のトランジションの使い方の傾向を調べて調整したりするときにとても便利、なはず。暫定で「カット」って用語つかったけど、どうですかね。続きそうそう、今回の反省の主眼は「ケアレスミスを防止できなかった」「チェック作業で手間どった」です。演出的な課題は旧版で達成、作業軽減の課題はとりあえずこの版である程度達成。作業ミスのリカバリ、という面では、かなりいまいちだったのでした。今まではあんまり顕在化してなかったんだよなぁ。システムの欠陥から来るバグは、悪いのは俺、ってことで、情けなくはなりますが、悲しくはなりません。直しがいもあるってものです(ぇー。それに対して、作業者のミステイクや素材の問題に由来するバグ、パッケージ作業者的には、単調な修正作業(原因は見た瞬間にわかる)の手間が増えるだけなので、かなり悲しいのです。多くは実際にプレイして確認するしかなく、テスターからあがってくるバグリストを見る→再現性を確認→修正→バグリスト更新→次のターンでテスターに再チェックしてもらう、という手順をふんで処理されます。見た瞬間に原因も対策もわかるケアレスミスなので直すのは一瞬なのですが、リストの更新とか、通知とか、つみかさなると、どんどん時間くわれて、究極的には俺の睡眠時間を削る要因になるのですよ。怠惰を美徳とする者のはしくれとしては、これは許されざる事態なのです!!ミステイクの発生を0にすることは無理ですが、システム的に減らす&リカバリを容易にする&スクリプタに確認しやすくすることで、組み込み屋を仕事から解放するのは可能ってことで。具体的には吉里吉里ベースへの以降。DB処理とか)はプラグインかいちゃえばいいし、安定した言語系+レイヤ合成系+サウンド系を自分の腕とミスを心配せずに使えるのは幸せだよね。-コマンドのデータ構造の問題-現行版のシステムでは、シナリオ格納部をDB化しました、が、演出制御を行なうコマンドの部分は、従来版のシステムを引き継いで、単純なバイトコードに置換して保持するようにしていました。これは特に必要があったからではなく、単に今までのコードそのままですぐうごいていいよね、というそれだけのことだったのですが、ああ、この仕様にした過去の俺がうらめしい......。なんで全部構造を設計しなおして、コマンド系も全部DB化しなかったんだか。チェック作業の基本は「プレイする」なことにかわりはありませんが、「チェック処理を行なうプログラム」を併用すると、その効率が段違いになります。単純で強力なのが「全文検索」。コマンド部はバイトコード化しているため、単純に検索することができません。コマンドを一度逆変換して、元のテキストに戻す処理が必要です。これをはさむと処理が遅くて遅くて......。テキストのみの検索だと十数秒でおわるのが、コマンドふくめて検索すると数分単位で時間が......。コマンド構造がきちんとなってれば、「特定のキャラクタのこのコマンドの部分を検索して置換する」とかそんなことも超簡単にできたはずなのに!ちなみに、ボイスデータとかの設定の部分はDB化の対象なので、ボイスのはめミス部分の特定、とかにかなり役にたちました。\ってことで、次の世代ではもう全面的にDB化確定です。DB化そのものにも問題があります。DBファイルがでかいの1つなので「更新」のための処理がかなりいまいちなことに......。更新しないだろってことでこうしんたですが、甘すぎた......。開発作業中の、「汎用DB」の圧倒的優位性は揺らぐことはないので、「作業時」と「リリース時」で扱いを変えるとかそういった方向でなんとかできないか検討中です。-コマンド入力パネル化の功罪-夏音ではこんなかんじのコンパネからコマンドを決定して入力させてます。コマンドパネルキャラクタコマンド環境コマンドたいした機能ではなくて、よーするにスクリプタのかわりにコマンドとパラメータの体系をおぼえておいてくれるだけのものです。これを操作すると、画面に状態が反映されて「入力」でそれを実現するコマンド文字列が生成されてシーン制御用のパネルに入力され、そこでコマンドを登録することができます。これ自体はスクリプタには好評なのでした。コマンドおぼえなくていいの重要。これだけを使うかぎり、特にミスはおこらないはず、なのですが、往々にしてパターン的なものはこぴぺか直接入力で作業したりするので、そこでミスがおこります(汗)あと、コマンド登録時に、特に直前の状態との比較を行なったりはしていないので「多重な指定」がいともあっさりできてしまうという問題があるのでした。このあたりは、今回の作業では「スクリプタの記憶と注意にたよる」以上のことはしていませんでした。スクリプタさんも人間、これにはおのずと限界があります。いうわけで、次の世代では......行単位編集モードはこぴぺをはさむようなインターフェースは無し。すべて専用の入力で処理。コマンド登録時には自動での差分検出処理を行なう後者のほうは、途中での導入もちょっと考えたんですが、コマンド部がバイトコードになってる関係他もろもろからややこしすぎて断念したのでした。すると不便になる点もあります。-今後準備するべきUIなど-マクロ/置換まずはこれですね。スクリプタから要望があったんだけど答えきれなかったのでした>「マクロ機能」。単純なこぴぺ的なマクロならわりと単純にできたんですが、それだと適当にテキストエディタとかからはりつけるのとあんまかわらないので、結局保留にしたままそのままだったという......ごめん(汗)。コマンド系もDBにそって構造化しますから、それにあわせたマクロ、たとえば、ターゲットになるキャラクタだけ変えて展開、とかできるんじゃないかなってことでいろいろと思案中。置換は、特定の条件をもつ部分を、指定した範囲で一括で処理、とかそういったものですね。これもどんな置換パターンをどんんなインターフェースでつくればいいのか思案中。テキストベース作業さて、こぴぺ禁止、は作業ミスを考えると当然なのですが、実は、似たような作業を大規模展開しようとすると、こぴぺ的作業できたほうがうれしかったりする罠。追加:あと一覧性が悪いからなんとかならんかと文句が(汗)>今の入力用システム結局、インターフェースのレベルがかみあってないのが問題なのです。上でテキスト変更などの作業を(複数行にわたって)行なう。カラム構造はこわさないように注意。側で「作業終了」すると元シーンに一括で書き戻しされる。エラーになる部分は赤くなるのでやりなおし。エラーが残る形では作業結果は反映不可能なので、結果的にエラーフリープレーンテキストよりは構造度高くてうれしいよねってことで淡い期待を>えくせるたん同期制御用インターフェースボイスと演出との同期の機能があるわけですが、今、これのパラメータ設定、ボタン連打でタイマ計測、という、超原始的な手法をとってます。これでも、タイマ数値が自動的にはまるようになった分、以前の、「スペースおすと適当にタイマ値がコンソール表示されるのでそれをこぴぺ」よりは進化したんだよ!!......ごめんん。これはやっぱGUI化せんとダメだとおもいまつ......。レイヤの配置制御インターフェース画面にだした効果レイヤやキャラクタの配置と拡大縮小、このあたりは、全部マウスのドラッグ操作でできてしかるべきだと思います。おしながらだと、現在の奥行きのままで上下左右自動移動をポイント記録+適当に補完、とか、いろいろできるはずです。移動用の曲線とかエディットするモードあるとたのしいかも。用はたせるんですが、視覚的にでるとわかりやすいよねってことで。現行システムだと、縦振動とか横振動とかいろいろありますが、あれの具体的な移動って直感ではやっぱなかなか大変でしょうから。-構成管理上の問題点のまとめ-う、ここの部分、書こうとおもってそのまま書かなかったのだ。わたしたちの田村君」二巻を電車でにやけながら読む今日このごろ、いかがおすごしでしょうか。あとベルガラス3巻は明日読もう。台風一過で暑いの勘弁。さわってみたいなー、評価版ないかなー。10ユーザからに......。勝負する気まんまんだねー。個別の機能的にはすごいところがあっても、値段が高い上に(CALもいるし......)、つくられてる部署と世代が違うからか操作感とかがけっこうばらばらだし、けっこういい勝負できちゃうんじゃないかなぁ。クライアントにできる強みがあるか。10ユーザまでだと超安い罠。そか、一応この製品ラインナップは考えた上でこうなってるんだ......。ダウンロードあるっぽ。これどういう位置づけなんだっけな^^;まあ、日本のほうにも近いうちに来るだろうからそれまっとこう。