はじめに
今回はこちらを見ていきます
7. キャラクター
Intro and Philosophy
- 20年近くもの間テストし柔軟でしっかりしたフレームワーク
- キャラクター中心のゲーム制作に利用されてきたがキャラクターなしやアプリケーションですら対応可能
- プレイヤーからAIコントロールへのシームレスな遷移
- 復元力のある正確な動きの実装
- どのような種類のアプローチでも対応できるようにカメラは設計
- AIシステムがビルドインされている
UE1 to UE3
- UE1ではPawnがすでに導入されていた
- プレイヤーコントロールはまだなし
- UE2でコントローラークラスを追加
- UE2ではアニメーションは頂点アニメーションだった
- Pawnの入力/レプリケーションはUE1から標準だった
全体図 概要
- コントローラーとポーンの関係が重要
- コントローラーはAI駆動でもプレイヤー駆動でもどちらでも可能
- AIコントローラーはポーンやキャラクターの振る舞いや移動先をナビゲーションメッシュに基づいて決定
- ポーン(Pawn)はキャラクターに関連していて、キャラクターは特殊なポーンの一種
- 移動コンポーネントとアニメーションが基本機能として組み込まれている
- カメラシステムがあり一般的なゲームプレイフレームワークもある。どちらもポーンに紐付いている
スキマティック
Controler / Pawn / Character
- キャラクターコントロールの基本フレームワーク
- ボディーとブレインの設定
- コントローラーがこのシステムの頭脳
- ポーンがボディ
- 上記2点が最も肝心な部分
- コントローラーが決定し、ポーンはその決定を実行する
- AIシステムを通じて決定を行うことも可能
- アイテムごとのアイテムのデモンストレーション
例えばサードパーソンキャラクターがいて、プレイヤーはスティックを動かしたりボタンを押したりする。ボタンやスティックの動きは決定に変換され、それをコントローラーは関数に変換したりしてポーンの移動やアクションのための指示に変換する。指示を受けたポーンはそれに従い行動する。
- ポーンは物理表現でありアクションを実行する
- キャラクターは実際はポーンのサブクラスでありポーンにいくつかの機能が追加されている
- キャラクターはポーンの強化版で、移動とスケルタルメッシュが実装済みのためアニメーションを再生する事ができる
Character
- ポーンの脳としてコントローラーは存在する
- 脳はプレイヤーコントローラー(Player Controler)またはAI(AI Controler)になりえる
- ポーンはライフタイム中に異なった脳に所有され得る
- 適切に設定すれば複数キャラクターを存在させる事が出来て、自分がどのキャラクターを所有するか決定する事もできる。
- サッカーゲームみたいなものですかね。
- プレイヤーコントローラーの所有を解除してAIコントローラーに所有を託すことも可能
Input
- 全体図から確認するとPlayer Controler にのみ伸びており
- Player Controler は入力を受け取っているだけなのが確認できる
- Defaultinput.ini はプロジェクト設定→inputから確認可能
- Action(ボタン)とAxis(スティック)は入力コンポーネントに進む
- Input Component には入力の優先順位を取得しているかどうか、どのBPが入力を受け取れるかなどが順に結び付けられている
- Player Controllerは入力を受け取りポーンに対する命令に変換する
Camera
- カメラの可能性
- 非常に柔軟なシステム
- キャラクター作成時にはそのキャラクターにアタッチするのは非常に簡単
- SpringArm コンポーネント
- SpringArmによってキャラクターに追随するようにカメラは動く
- カメラマネージャ
- 例えばシネマティックカメラに移行したい場合など、それを行うのがカメラマネージャ
- ワールド内のすべてのカメラを管理している
- カメラは Controller と Pawn どちらにも関連している
- SpringArmコンポーネントを使用していない場合にカメラを制御する方法は2つある
- 1つは CalcCamera
- もう一つは ViewTarget
- カメラの正面に有るアクタがそのカメラの振る舞いを決定できる
- カメラがカメラの振る舞いを決定する事もできる模様。イメージできない
Behavior Tree
- Behavior Treeは意思決定システム
- バイナリ方式
- 単純なBehavior Tree
- 黒板(Blackboards)
- Behavior Treeが決定を行うためにアクセスできる変数
- 何をするかを知るためにBehavior Treeがアクセスする多数の変数がある
- 知覚システム(Perception System)
- Behavior Treeから読み取ることのできるコンポーネント
- 敵などがプレイヤーを探す場合に使用したりしている
- 環境クエリシステム(Environment Query System) 実験的機能
- 環境についてのデータを収集するサブシステム
- 環境に対しクエリや質問を行うことができる
- 青い球はプレイヤーから見えていると環境が教えているところ
- 奥に緑の球がありそこはプレイヤーが見えていないところ
- この情報を使いNPCをプレイヤーの死角に移動するように指示できる
NavMesh Navigation Mesh
- すべてがナビゲーションメッシュに結び付けられている
- ビルドパーツ内でナビメッシュをビルドする必要がある
- ナビメッシュボリューム内で生成される
- そのためのボリュームを配置しなければならない
- NavAgents
- ナビメッシュをどこに生成するかはエージェントにより決定する
- 急な斜面やもっと緩やかな斜面にする必要がある場合エージェントをそのように設定する
- 事前計算しておくこともリアルタイムで計算することもできる
NavLink Proxies
- 接続されていない2つの異なったNavMeshを接続する
NavAreas
- ナビゲーションメッシュの重みやコストを変更する
NavFilters
- NavAreas によって定義されたコストを上書きする。
- パスはデフォルトではなくフィルターによって定義されたほうで計算される
NavModifiers
- NavAreaで定義された重みの内の指定した部分の重みを変更する
Replication
- ネットワークソリューションの基本をネイティブに実装
- オーナーシップに基づくレプリケーション
- 例えばクライアントがプレイヤーコントローラーを所有している場合、それはそのアクタをレプリケートする事を任されている。
- ワールド内のすべてのアクタはレプリケートする事ができる
- すべてのメッセージは信頼性に基づいていて、必ず伝達するように設定もできる
- しばらく経ってもメッセージが届いたというレスポンスがなければ再送したりする
- アクタとそのアクタの内部にあってレプリケーション用にマークされているすべてのプロパティは
- アクタが変化した時やスポーンまたは破棄される時
- レプリケートされる
- プロパティが変化した時
- 各クライアントとサーバーに伝達される
- アクタが変化した時やスポーンまたは破棄される時
RepNotify
- プロパティの変更があったことをフックさせる事ができる
- それに対して音や効果を出すなどに利用できる
Gameplay Framework
- より広域のゲームプレイフレームワークに接続する
- プレイヤー状態
- 通常ポーンのコントローラーはゲームモードに認識される
- ゲームモードはゲームの状態の変化を任されている
Movement Component
- ナビゲーションメッシュを横断する為のもの
- ポーンに対し柔軟で高度に設定可能。NavMeshのTraverseに使える
Crowd Manager 群衆マネージャ
- 多数のポーンの移動に適用でき、それらの移動をプランニングし衝突を軽減する。
Character Movement Component
- Movement Component の拡張
- 歩く、走る、ジャンプ、飛行、しゃがむ、泳ぐ、カスタムな運動をサポートする
- 詳細には多数の変数がある
- これを見て何ができるのかを確認しておく事を強くおすすめします。とのこと
アドバイス
Controllers and Pawns
- 格闘しようとせず理解する事に努めてください
- 本当の潜在能力が理解できるようになります
- どのような課題にもソリューションがあります
- 異なったコントローラーを持てたり、コントローラの制御をスワップする仕組みがあります
- それらを自動テストに使えます
Character vs Pawn
– 図はイメージです
Movement Component
- 多くの機能
- 深く設定可能
- 意思決定から切り離されている
- カスタムな動きをするモードを生成する事が可能
Projectile Movement Component
- 発射物の動きのためのコンポーネント
Input
ここではアクションに関連するボタンについて考えてみる。例えばゲームパッドコントローラを使用しあるステートでアクションを行い、別のステートで別のアクションを行う。ボタンがある場合。
1つにまとめてグループ化しないで下さい。つまりそれらのアクションを同じボタンにグループ化せずにアクションだけをグループ化して下さい。
例えば、あるボタンはジャンプ用。攻撃時などの別のステートではジャンプを作成するだけ、攻撃を作成するだけといった再利用可能キーに分ける。そうすれば将来デザイナーが動きを変えようと考えた時にやりやすく成る。
といっていたが、よくわからない。そのまま記載しておく。
- BPを使う発想は避けて下さい。どこで起こっているか見つけるのにひどく苦労する結果と成る為。との事
- すべてのことをコントローラまたはUIで行うように心がけて下さい
Behavior Trees
- Behavior Treesは1キャラクターに対し1以上使用することができる
- 例えば回避してから交戦する場合など、異なるステートがある場合に2つ使用して切り替える
- あるいはサブツリーを使って大きなBehavior Treesの中にまとめる
- 例えば回避してから交戦する場合など、異なるステートがある場合に2つ使用して切り替える
- ランタイムに変更可能
- 速い
- 数が多くてもうまく機能する
- ブラックボードを供給するBPで行う必要のあるデータ処理は必ず意思決定から切り離して下さい
- そうすることで純粋なBehavior Treesとなる
Workflow with animation
- キャラクターにアニメーションをリンクできるものはリアクトアニメーションとなる
- AnimNotifiesから情報を取得できます
- イベントに合わせて音を再生したりパーティクルを再生したり出来ます
- 具体的には足音などにも使用されているみたい。
What capsules can be used for カプセルは何に使われるか
- キャラクターには物理アセットと呼ばれるアセットがアニメーションクラスにある
- それは物理アニメーション用だけではなく、それらのカプセルのインタラクションやオーバーラップも確認できる
- それらのカプセルでブロックできる
- それは物理アニメーション用だけではなく、それらのカプセルのインタラクションやオーバーラップも確認できる
- グラッグすると動くもののような物理プロファイルを使用して物理的な振る舞いを追加できる
- シャドウウィング用のレンダリングクラスで見たようなカプセルを使用する事も可能
最後に
色々わからないとこはあれど頭の中で落とし所を持つようにしている。情報量が多くてちゃんと理解できているか不安になるけど最後に行う小テストで100点取れると概要くらいはつかめてる事がわかって嬉しくなりますね。
そして次がいよいよ最後。頭より手を動かしたいので苦痛だったけど、これから行うすべての事についてある程度自分がいまいる場所もつかめるようになっていると思うと有用だったように思いますね。
まぁ結果はまだわかりませんが。
自分用メモ
Pawn <|-- Character Pawn : Behavior() Character : SkeltalMesh Character : Collision()
メモ
- Traverseは横断するとか越えるなどという意味っぽい