« データ作成のためのツール | メイン | セッションの共有 »
2007年09月16日
アニメーションライブラリ:: 演出とかを組む話
Tweet @jin1016をフォローなんか演出に関する話題が周りであったようなので、その辺りの話について。
まずは昔話から。
最初に働き始めた職場では、はじめからアニメはツールで作って、プログラマは呼ぶだけという形になっていました。
なので、私は特にその形について違和感はなく、そういうものと認識していました。
しばらくして私にアニメーション周りをデザインする機会が与えられ、その時にもアニメはデザイナーが作って、プログラマは呼ぶだけと言う形が好ましいと言われました。
そして、そのような作りにしました。
プログラマが演出に立ち入る必要性がある時は、以下のようなケースがあると思います。
・ツールで作ったら莫大なパターンが必要な時
・ツールで実現できない演出を組む時
・インタラクティブ性を必要とする時
莫大なパターンと言っても、パターンと言う言葉が指すようにそこには規則性があります。
最初はこのパターンについては特に考えていませんでしたが、次第にこの問題を解決できればさらに効率化できるのではないかと思うようになりました。
このようなアニメーションで、気付いているパターンは2つ。
実体の差し替えとオフセットです。
実体の差し替えは、単に絵が違うだけのようなものを指しています。
オフセットは、アニメーションの開始位置が違ったり、拡大率が違ったり、反転していたりと言うようなものです。
最初はこれをまずツールで汎用スプライトを作れるようにして、プログラム側からその汎用スプライトの中身を指定してやることで実現しようとしていました。
オフセットは、入れ子もしくは親子関係が出来れば、この汎用スプライトにアニメを入れることで実現できます。
そして、その時は汎用のツールでアニメーションを作っていました。
なのでプラグインを作ってから実機で再生できるように持って行こうとしていたのですが…… 開発期間の問題で実現しませんでした。
改めて考えればこれはもっと簡単な方法で実現できることがわかりました。
単にスプライトに識別のための情報を付与してやれば良いのです。
識別のための情報があれば、アニメーションを再生するプログラム側で一工夫してやるだけでこの問題は解決できます ( 識別のための情報は、以下タグと呼ぶことにします ) 。
アニメーションを描画する時、いわゆる Draw( frame ) と言うようなメソッドを実装してやればよいのでしょうか？
私ははじめそのように考え、その通りに実装していました。
ですが、今はそのようには実装していません。
代わりに traverse と言うメソッドを実装しています。
traverse メソッドにはフレームと関数オブジェクトを指定してやり、そのフレームにインスタンスのあるスプライトすべてを順に、渡された関数オブジェクトにスプライトの情報を渡して呼び出します。
もし差し替えたいスプライトがあるのなら、そのスプライトにタグを設定し、この関数オブジェクト内でそのタグに出会った時に別のスプライトを描画してやれば済みます。
特に何もする必要がない時は、単に描画するだけの関数オブジェクトを渡します。
関数オブジェクトでは、再帰的に traverse をコールすることも可能なので、入れ子になったアニメーションも実現できます。
また、アニメーションのデータは描画すること以外にも使えます。
代表的な例は当たり判定です。
関数オブジェクトを判定用のものにすれば、容易に実現できます。
この場合、タグの値はマスクを意識して設定しておきます。
当り判定は、すべてのスプライトを対象として欲しい状況よりも、特定のスプライトのみを対象としたい場合が多いです。
この場合、当たり判定用の関数オブジェクトがマスク値を保持できるようにしておき、それによってマスクすることで対象を見分けることが可能です ( 例えば、マスク値が 0x0F なら 1～15までのタグ値を持つものにのみヒットする ) 。
アクションやシューティングじゃないので当たり判定なんて使わないかと言うと、マウスでのクリックやタッチスクリーンで触れられた時などに、どのスプライトがクリックされた ( 触られた ) かを見分けたい場面などでも使えます。
そうすれば、メニューなどはある程度アニメーションで組めます。
で、残りの2つ。
・ツールで実現できない演出を組む時
・インタラクティブ性を必要とする時
ですが、これまではこのことについて特に何とかしようと考えたことはありませんでした。
そもそも、インタラクティブ性はそのためにプログラムがあると思えますので。
ただ、ある程度のパターン化は可能だと思います。
パターン化が可能であれば、それらをあらかじめ作っておくことでツールへその指定を持っていくことが可能です。
でも、今回もこのことについては積極的に取り組もうとは今のところ考えていません。
そして最後。
ツールで実現できない演出については、独自ツールで解決していく方向を目指しています。
つまり、最初はプログラムで組まれたものであっても、次回もしくはそれ以降はツールで対応しパラメータを設定してやることで、アニメ呼び出しで一発にするということです。
こういうことは汎用のツールでは難しいです。
アニメをツールで作ってプログラムもしくはスクリプトでアニメ呼ぶだけと言うのはかなり楽です。
ツールで見ながら調整し、出来たものを呼べばいいだけなので、プログラムで微調整しながら何度も何度も確認、調整して行くよりも遥かに楽です。
使えばわかりますが、プログラムで何とかしようと言う気がかなり失せます。
ですが、このような環境がないところが多いのも事実のようです。
実際に Excel や Word で指示された位置へプログラムで表示するように組んでいたこともあります。かなりやってられない気分でしたが、このような環境を構築する工数がなく、とにかく日々忙しさに忙殺されていました。
また、聞いた話ですが座標などのデータを紙で手渡されて、それを組み込んでいくところもあるようです。
そして、もうひとつの問題がツールのコストです。
Director、Flash、After Effects はかなり高いです。
デザイナーさんが使うのなら問題ないと思いますが、プログラマにまで行き渡るようにするとそれなりにコストがかかります。
このような状況を打破する方法はひとつ。
自分で両方作ってしまえっ！です。
ツールと再生ライブラリがあればやってられない状況は回避できます。
汎用的に作っていれば、ポーティングもしやすいはずです。
で、実際にどのくらいかかるの？って話ですが、独自ツールを作り出すと底なし沼にはまっていきます。
それなりに使えるレベルにするのには1ヶ月ぐらいは見ておいたほうが良いと思います。
再生ライブラリは、すぐに出来ます。
アニメファイルが再生しやすいように設計されたバイナリフォーマットであれば、2日もあれば再生できるようになります。
汎用ツールはその調査にかなりの時間をとられます。
一度作ったことがあればまだしも、初めてとなると大変です。
この調査の時間はどれぐらいかかるとは言いづらいですね。
まあ、はじめは多難な道であることは間違いないです。
と言うようなことが、このアニメーションライブラリを作り始めて、作っている時 ( 今 ) の話ですね。
で、その後の話。
完成したらどうしようと思っているかです。
再生ライブラリやファイルフォーマット、コンバーターなどはBSDライセンスで配布します。
ツールについてはフリー版とシェアウェア版を作ろうと考えています。
とは言っても、フリー版は今開発で使っているものよりも高機能なものを目指しています。
つまり、フリー版で何も問題なく作れるようなものです。
で、シェアウェア版は趣味の領域です。
少しは差別化しようとは思っていますが、シェアウェア版買ってくれないところで作業することも考え、フリー版でも普通に作れるようにしようと思っています。
じゃあ、何のためのシェアウェア版かと言うと、みんな買ってくれて他の仕事減らせてツールの充実に時間を使えたらいいなぁと言う無謀な期待を抱いているせいです。
みんな使うんだから少しずつお金出して誰かに任せられないかと言う道の模索でもあります。
投稿者 Takenori : 2007年09月16日 22:34
comments powered by Disqus