ただ見上げるより この手を伸ばしてみたくなるだけ (ポコアポコ/カヒーナムジカ)
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

 Flashからmidiを鳴らすスクリプトの動作確認にご協力下さった皆様、ありがとうございます。
 「そうか、Operaだとそうなるんだ」とか、いくつか有用な情報を知ることができました。
 まだまだ募集中ですので、よろしくお願いします。

 その一方で、他の箇所のスクリプトも少しずつ書き進めています。
 えらく速度遅いですが(汗)。
 前作「青の彼方」で、思うように作業時間を減らせなかった作業に、入力作業がありまして。
 ダイスアニメとかステータス変化のアニメとか確率図とかは、値を入力すればその値で表示が実施されるのですが…この入力が意外と大変で、随分時間を食いました。
 そこをいかに削減できるのか? が今回のスクリプトのテーマの一つです。
 
 基本方針としては、「推敲したテキストを一括変換などの処理で外部AS化し、そのままパブリッシュすればヴィジュアルリプレイのできあがり!」という、とてもインスタントな方法を目指しています。
 ただ前回までそういう方法を取って来なかったのにはやはりそれなりの理由がありまして。
 例外処理をするものが多い、というのも理由の一つ。
 ですが、最大の理由は、「上手く法則を取り出してスクリプト化できなかった」という事ですね。

 例えばステータス変化のアニメの場合、元の値、変化後の値はもちろんのこと、変化しないパラメーターも全て入力しないといけない仕様になってしまっていました。
 ステータスの値を複数のオブジェクトで引き継ぐスクリプトが書けない。あるいは書く気がない。

 ちょっと込み入ったスクリプトになると面倒がったり、書けなかったり。
 その辺りの事情があるから、前作では「スクリプトに頼るのは最小限にする」という方針が立ってしまった訳です。が、その方針が結局、何百時間とか言うルーチンワークを吐き出してくれます。
 自信がないスクリプトチームが「それが作れるかどうかわからない。作れたとして何日かかるか分からない。コミケに間に合わないかも知れない」と主張してしまえば。何百時間かかろうとも時間が積算できるルーチンワークの方が確実で好ましいとなってしまった訳で。
 じゃあ誰が何百時間の作業をするのさ? という問いかけは愚問で、最初から丹川の他にやる人がいなかったのです(苦笑)。

 確かにスクリプトを使わずに済む部分は使わない方が、誤動作や予期せぬ動作が起こらず楽なのは事実です。
 しかし「同じような動作を何十回と繰り返す」ことは、スクリプト化した方が絶対に楽です。
 それをスクリプトチームが上手く法則として取り出すことができなかったという事実は、プロジェクトリーダーとしては大いに反省すべき点です。
 今回、「スクリプトが出来上がるまで、その他は一切作らない」という方針を掲げているのは、同じ轍を二度と踏まずに済むようにするためです。しかし〆切第一主義の下ではこの方針を通すのが難しいので、新しい枠組みが必要になったという事情もあります(それだけが理由ではないですが)。


 話が逸れました。
 ともかく今は、テキストの中に関数を埋め込み、その指示でアニメーションを実行してくれるようなスクリプトを書いています。
 今回はコンポーネントを原則使わない方針になったので(外部ASで全てを操作するため)、巻き戻しやロード時に問題なく動くスクリプトをどう書くのかも課題です。
 スクリプトの条件や動作内容の整理してみたら、何のアニメを実行するにしろ、共通するパターンで処理できる事が分かりました。ということは、一つの関数でどうにかできるはずなのです。
 ただアニメによって、引数の数と型に違いがあります。ActionScript2.0以降では引数の型を指定しないとならないので、物によって引数の型が変わってしまうのは困ります。
 あと、引数の数を可変にする方法はどうしたら良いのか、とか。
 ですが、調べてみたら何とかする方法はあるようです。
 渡したい引数を全部配列にして、その配列自身を引数として渡すとか。その方法ならば、引数は配列一つで済みます。
 Function.apply( );などでも同じようなことができるみたいですね。
 
 なんとか上手く行くんじゃないかと思います。


追記を閉じる▲
 
 基本方針としては、「推敲したテキストを一括変換などの処理で外部AS化し、そのままパブリッシュすればヴィジュアルリプレイのできあがり!」という、とてもインスタントな方法を目指しています。
 ただ前回までそういう方法を取って来なかったのにはやはりそれなりの理由がありまして。
 例外処理をするものが多い、というのも理由の一つ。
 ですが、最大の理由は、「上手く法則を取り出してスクリプト化できなかった」という事ですね。

 例えばステータス変化のアニメの場合、元の値、変化後の値はもちろんのこと、変化しないパラメーターも全て入力しないといけない仕様になってしまっていました。
 ステータスの値を複数のオブジェクトで引き継ぐスクリプトが書けない。あるいは書く気がない。

 ちょっと込み入ったスクリプトになると面倒がったり、書けなかったり。
 その辺りの事情があるから、前作では「スクリプトに頼るのは最小限にする」という方針が立ってしまった訳です。が、その方針が結局、何百時間とか言うルーチンワークを吐き出してくれます。
 自信がないスクリプトチームが「それが作れるかどうかわからない。作れたとして何日かかるか分からない。コミケに間に合わないかも知れない」と主張してしまえば。何百時間かかろうとも時間が積算できるルーチンワークの方が確実で好ましいとなってしまった訳で。
 じゃあ誰が何百時間の作業をするのさ? という問いかけは愚問で、最初から丹川の他にやる人がいなかったのです(苦笑)。

 確かにスクリプトを使わずに済む部分は使わない方が、誤動作や予期せぬ動作が起こらず楽なのは事実です。
 しかし「同じような動作を何十回と繰り返す」ことは、スクリプト化した方が絶対に楽です。
 それをスクリプトチームが上手く法則として取り出すことができなかったという事実は、プロジェクトリーダーとしては大いに反省すべき点です。
 今回、「スクリプトが出来上がるまで、その他は一切作らない」という方針を掲げているのは、同じ轍を二度と踏まずに済むようにするためです。しかし〆切第一主義の下ではこの方針を通すのが難しいので、新しい枠組みが必要になったという事情もあります(それだけが理由ではないですが)。


 話が逸れました。
 ともかく今は、テキストの中に関数を埋め込み、その指示でアニメーションを実行してくれるようなスクリプトを書いています。
 今回はコンポーネントを原則使わない方針になったので(外部ASで全てを操作するため)、巻き戻しやロード時に問題なく動くスクリプトをどう書くのかも課題です。
 スクリプトの条件や動作内容の整理してみたら、何のアニメを実行するにしろ、共通するパターンで処理できる事が分かりました。ということは、一つの関数でどうにかできるはずなのです。
 ただアニメによって、引数の数と型に違いがあります。ActionScript2.0以降では引数の型を指定しないとならないので、物によって引数の型が変わってしまうのは困ります。
 あと、引数の数を可変にする方法はどうしたら良いのか、とか。
 ですが、調べてみたら何とかする方法はあるようです。
 渡したい引数を全部配列にして、その配列自身を引数として渡すとか。その方法ならば、引数は配列一つで済みます。
 Function.apply( );などでも同じようなことができるみたいですね。
 
 なんとか上手く行くんじゃないかと思います。

【2009/05/15 00:37】 | 天地未だ形れざるとき
トラックバック(0) |
コメント
この記事へのコメント
コメントを投稿
URL:

Pass:
秘密: 管理者にだけ表示を許可
 
トラックバック
この記事のトラックバックURL
この記事へのトラックバック
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。