■

やっぱり鬼門はアニメーション系列か・・・・。いや、数値系列も結構大変だがアニメーション(というか描写)系列は比じゃない。
まず大変なのがアニメーションを数値系列と同期をとること。例えば敵の前後設定。前か後ろというのはダメージ計算やターゲット指定可能性等、数値系列に直結しているが同時に描写系にも直結している。前の敵の方が後ろの敵より前に描写されてなきゃおかしいでしょ？空中の敵が地上の敵より下に描写されてたらおかしいでしょ？だから数値的な値から描写位置を補正する必要がある。が、それはプログラマ的発想であって、実際にゲームを制作する側からみたらむしろ反対なのだ。製作者側からしてみれば、まず描写位置を決めて、それに応じて数値が変化してほしいのだ。つまり数値系列側がアニメーション系列に同期を取りに行く。しかしこれがまた大変。
なぜかって、描写位置から前後や空中を判断するのが数値的に非常に厳しいのだ。「前に描写される(優先度が大)のが前になって、上のほう(ｙ座標が小)のが空中じゃないの？」と思うかもしれない。残念でした。それはフロントビューでの話し。サイドビューの場合は右が前で空中に至っては判別不能です。たとえフロントビューでもいろいろ問題があって、敵が大量に重なっていればどこからが前列でどこからが後列かがわからない。というわけで結構やっかいなのですよこれだけでも。
次に大変なのが、実際の技を出した場合のアニメーション。何でも出来るようにしようと考えた場合、だいたい３段構えくらいになりそうである。ちなみにツクール2000は1段構え(技１つにつきアニメーションが１つ)ツクールXPは2段構え(技一つにつき、発動側とターゲット側で２つ)である。で、SRSはというと、まず、被害者側の派手なアニメーションは元の汎用アニメーションの組み合わせを作り、それを１つと発動側で汎用アニメーションを一つという形をとろうと思っている。これで殆どのことが可能である。さらに連続攻撃系の場合は攻撃１回に対して組み合わせアニメーションを一つずつ割り当てる予定である。「これの何が一体問題なのか？」まずはファイル管理。汎用アニメーションは実際の具体的DATAが詰まっているので非常に大きい。のでファイル一つ一つを個別管理になる。がその上の組み合わせアニメーションは、多分そんなに大きくはならない。なので一つにまとめたほうが良いのでは？となるかもしれないが、そうすると使いもしないアニメーションファイルが常駐することになりメモリの無駄遣いである。さらにその上の技ファイルや連続攻撃系等いろいろと組み合わせるタイプになってくるといろいろとファイル管理(およびメモリ管理)が結構大変になってくる。まあ、全部常駐させるか全ファイルを個別にするのが一番楽なんだがそういうわけにもいかないだろう。で、もう一つの問題(というかこちらが本題かも)は製作者が激烈に大変だということ。３段構えで何でも出来るといっても、３段構えでないと再現出来ないアニメーションなんてボスの決め技や味方のスペシャル技等、殆ど限られている。殆どの技はツクール2000のように汎用アニメーションを一つ割り当てるだけで十分である。それなのにわざわざ大量の設定を施すのは製作者にとって面倒なことこの上ない。
ということでまだまだ抱えている問題の多いアニメーション系列でした。