![]() |
モーションデータについて。 動きの一瞬を切り出して絵にしてるアニメパターンとは別に、その絵を一体どれだけの時間表示して、次にどの絵を表示して、というような挙動=モーションのデータを用意するが吉。 例えば、アニメパターン番号、X方向の移動量、Y方向の移動量みたようなデータ構造を定義して、ゲームが1回ループするごと次々とデータを再生していくようなのが簡単ぐり。 まあ実際にはもう少しデータを追加するほうがよくて、例えば ・相手に攻撃が当たったとき別のパターンを再生する ・着地したとき別のパターンを再生する ・相手の攻撃が当たったとき別のパターンを再生する(当身) というような、単純に一つのモーションを再生するのではなく別のモーションにもすぐ移行できるような仕組みを作っておくとよいかもね。 というか通常技キャンセルとか実装しようと思ったらそうなる。 ツクールとか既存のソフトを使っていて容易に構造をいじれないという場合は仕方ないけれど、自作プログラムでデータを動かす人は拡張性もある程度見込んでおくが吉。 ああそうそう、2D格闘ゲームの場合は「飛び道具」というのが普通にあるので、あるモーションから飛び道具を発生する、という仕組みも必要だの。 あとな、これちょっと迷ってる部分なんだが。 |
![]() |
なに? |
![]() |
迷ってるというか、迷ってはいないんだけれど。 モーション・・・例えばジャンプの軌道をデータ化するとき、二つ方法があるとおもうわけだぴょんさ。 ・フレームごとの移動量を全部べたに持ってしまう ・初期値だけ与えて後は計算で移動量を算出する 普通に放物線を描くジャンプは、初期値を与えてそこから重力に応じた値を減らしていくという簡単な計算で表現できるわいね? でも、斜め上にすっとんでいって真下に落ちるとか、少々特殊な軌道を描く必殺技とかだと、単純な計算で表現するのはめんどくさい。 ウサのゲームではどっちも表現できるようになってるのだけれど、前者の移動量のパラメータを全部持ってフレーム毎に加えていく方法のほうが、メリハリというか動きの面白さはあるんじゃないかなあと。 ただ、用意するデータ量は明らかに多くなるので、そこらは作る人の方針次第なのかのう・・・ |