エンティティシステムのアニメーション状態の抽象化


8

私は最近、エンティティシステムパラダイムを使用してゲームエンジンの設計を開始しました。つまり、コンポーネントの集約としてエンティティを持ち、実際のゲームを実装するシステムがあります。私はさまざまな面で困難を経験してきましたが、最も気になるのは、さまざまなコンポーネント/システムの抽象化/モジュール性です。具体的には、Playerいくつかのアニメーション状態があるとしましょう。WalkingSleepingJumping、のいずれかのタイプとOpponent、エンティティは、例えば、同様にいくつか(必ずしも同じ)状態を有します。WalkingHidingなど

各エンティティタイプのさまざまな(アニメーション)状態を処理するようにエンジンを設計するにはどうすればよいですか?エンティティタイプごとに異なるアニメーションシステムが必要ですか?正しいエンティティをレンダリングするためにアニメーションシステムに信号を送るフラグを使用する必要がありますか?また、さまざまなポーズに「ハードコードされた」列挙型の使用を回避できますか?スクリプトシステムがおそらく役立つことがわかりますが、もっと簡単な解決策があるとほぼ確信しています。

回答:


4

タイプごとに異なるシステムを使用することはできません。責任の分割が細かくなりすぎています。

これが私の現在の個人プロジェクトで行っていることです。

状態を処理するには多くの方法がありますが、おそらく人間にとって意味のある方法、または少なくとも人間とコードの間の橋渡しが必要です。アニメーションシステムを、離散状態の1つではなく大きなブレンダーと考える必要があります。たとえば、システムに50%の歩行を追加してゆっくりと歩行に移行し、その後100%の走行を追加します。

アニメーションシステムの外部では、文字列を使用して、システムでの作業を快適にし、スクリプトやコードを簡単に作成できます。システムの内部で、その文字列とアニメーションデータ間マッピングを作成します。これは、ハッシュマップのようなキーと値のストア(アニメーションデータをストアにすることで列挙型を完全に回避するため)または文字列から列挙型で実行できます。その方法で作業したい場合は、ルックアップ。その時点では、それはすべて好みの問題です。それは完全にXMLまたはINIファイルから駆動されるデータであり得るので、私はKey-Valueを好みます。

さまざまなタイプを処理するには、システムレイヤーでアニメーションのマッピングのセット作成して、「ミニオン」の「ミニオン」と「実行」のセットが「実行」と「女性プレーヤー」のセットと異なるようにします。タイプ。

要約すると、アニメーションシステムは一般的であり、システムは1つだけです。外の世界にはフレンドリーなインターフェースが必要です。内部世界は、一般的な状態をエンティティタイプにマップする必要があります。

そして、私がやりたいことのリストですが、まだデザインに収まりません。

TODO:移動速度をアニメーションタイプに自動的にマッピングするので、メインプログラムに「歩く」と「実行」を認識させる代わりに、アニメーションシステムは「x速度で移動」を適切なアニメーションに変換できます。

TODO:頭や胴の追跡などのアニメーションを透過的な方法で分割します。

TODO:メインプログラムではなく、システムによって処理される反応アニメーション(顔がパンチされるなど)。


したがって、ifアニメーションシステム内でいくつかのを使用することをお勧めします。以前は(C ++で)文字列の辞書をメモリに関して使用することについて懐疑的でした。ハッシュテーブルについて今日読んだので、私はあなたの答えは非常に簡単だと思います。「ブレンダー」の部分について:「50%の歩行を追加する」とは、一部のフレームを50%の時間で「歩行」のフレームに置き換えることを意味しますか?
petermer 2012年

ブレンディングはアニメーションではかなり一般的な用語です。つまり、2つ(またはそれ以上)のベースアニメーションをブレンドして最終的な出力を得るということです。50%の例では、50%の "アイドル"と50%の "ウォーク"のブレンドを想定しています。これにより、半速の散歩ができます。このようにして、「アイドル」から「ウォーク」、そして「実行」へと連続的に動きを変えることができます。ブレンドすると、上半身が銃を撃っているときに下半身を動かしたり、誰かに手を振ったりすることができます。アニメーションエンジンがブレンディングをサポートしていない場合は、これを検討する方法として使用してください。ルールではありません。
Patrick Hughes

1
参考までに、この段階でプログラム内の文字列のメモリについて心配することは時間の無駄であり、これは「時期尚早の最適化」と呼ばれ、一般に悪い考えです。後で、文字列が本当に大きな負荷を引き起こしている場合、それらは短いCRC番号に変換され、大幅に縮小されますが、デバッグの容易さとビルドプロセスへの追加のステップが犠牲になります。
Patrick Hughes
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.