1）プレーヤー：ステートマシン+コンポーネントベースのアーキテクチャ。
Playerの通常のコンポーネント：HealthSystem、MovementSystem、InventorySystem、ActionSystem。これらはすべてのようなクラスですclass HealthSystem。
使用することはお勧めしません（通常の場合、フレームごとに何らかのアクションが必要な場合を除き、ヘルスシステムを更新することは意味Update()がありません。これらはめったに起こりません。時々健康を失うために-コルーチンを使用することをお勧めします別の人は常に健康またはランニングパワーを再生します、あなたはちょうど現在の健康またはパワーを取り、時が来たらそのレベルまで満たすためにコルーチンを呼び出すだけです。彼は破損していたか、再び走り始めました。
状態：LootState、RunState、WalkState、AttackState、IDLEState。
すべての状態はから継承しinterface IStateます。IStateこの例では、例として4つのメソッドがあります。Loot() Run() Walk() Attack()
また、class InputControllerユーザーのすべての入力を確認する場所があります。
さて実際の例に移りましょう：InputControllerプレイヤーがのいずれかを押したかどうかを確認しWASD or arrows、次にを押したかどうかを確認しShiftます。彼が押された場合にのみWASD、我々は呼んで_currentPlayerState.Walk();、このhappendsと我々が持っているときcurrentPlayerStateに等しくなるようにWalkStateして、その後WalkState.Walk() 、この場合には-私たちはこのような状態のために必要なすべてのコンポーネントを持ってMovementSystem、我々はプレーヤーの動きをするので、public void Walk() { _playerMovementSystem.Walk(); }あなたは私たちがここに持っているものを参照してください- ？動作の2番目の層があり、コードの維持とデバッグに非常に適しています。
次に2番目のケース：WASD+をShift押したらどうなりますか？しかし、以前の状態はでしたWalkState。この場合、Run()が呼び出されますInputController（これを混同しないでください。これは、のためではなく+ チェックインRun()があるために呼び出されます）。我々は呼び出すときに-私たちは切り替える必要があることを知っているにして私たちがそうするのと、私たちはこのフレームを失うアクションにしたくないので、別の状態で今、このメソッドの内部で再びそれを呼び出すけど。そして今、もちろん私たちは呼び出します。WASDShiftInputControllerWalkState_currentPlayerState.Run();WalkState_currentPlayerStateRunStateRun()WalkState_playerMovementSystem.Run();
しかしLootState、プレーヤーがボタンを放すまで歩くことも走ることもできない場合はどうでしょうか？さて、この場合、略奪を始めたとき、たとえばボタンEが押されたとき、私たち_currentPlayerState.Loot();はスイッチにLootState電話し、そこから呼び出されます。そこで、たとえば、範囲内に略奪するものがあるかどうかを取得するためにcollsionメソッドを呼び出します。そして、アニメーションがある場所または開始する場所でコルーチンを呼び出します。また、コルーチンブレークでない場合はプレーヤーがボタンを保持していることを確認します。しかし、プレーヤーが押すとWASDどうなりますか？- _currentPlayerState.Walk();が呼び出されますが、ここではステートマシンについてのかわいいものがありますLootState.Walk()何もしない、または機能として実行する空のメソッドがあります。プレイヤーは、「おい、まだこれを略奪していない、待てますか？」と言います。彼が略奪を終了すると、に変わりIDLEStateます。
また、class BaseState : IStateこれらのデフォルトメソッドのすべての動作を実装した、呼び出される別のスクリプトをvirtual実行できoverrideますがclass LootState : BaseState、クラスのタイプで使用できるようにそれらを実行します。
コンポーネントベースのシステムは素晴らしいです、それについて私を悩ます唯一のものはインスタンスです、それらの多く。また、ガベージコレクターのためにより多くのメモリと作業が必要です。たとえば、敵のインスタンスが1000個ある場合。それらはすべて4つのコンポーネントを持っています。1000個ではなく4000個のオブジェクト。Mbは、単一のゲームオブジェクトが持つすべてのコンポーネントを考慮すれば、それほど大したことではありません（パフォーマンステストは実行していません）。
2）継承ベースのアーキテクチャ。コンポーネントを完全に取り除くことはできないことに気づくでしょうが、きれいで機能するコードを作成したい場合は実際には不可能です。また、適切な場合に使用することを強くお勧めするデザインパターンを使用する場合（それらを使いすぎないでください、それは過剰生成と呼ばれます）。
ゲームで終了するために必要なすべてのプロパティを持つPlayerクラスがあるとします。ヘルス、マナ、エネルギーを持ち、移動、実行、能力を使用でき、インベントリを持ち、アイテムを作成し、アイテムを略奪することができ、バリケードやタレットを構築することもできます。
まず、インベントリ、クラフティング、ムーブメント、ビルディングは、次のようなメソッドを持つことはプレイヤーの責任ではないため、コンポーネントベースにする必要がありますAddItemToInventoryArray()-プレイヤーは、PutItemToInventory()前述のメソッド（2レイヤー-異なるレイヤーに応じていくつかの条件を追加します）。
建物の別の例。プレイヤーはのようなものを呼び出すことができますOpenBuildingWindow()がBuilding、残りのすべてを処理し、ユーザーが特定の建物を構築することを決定すると、必要なすべての情報をプレイヤーに渡しBuild(BuildingInfo someBuildingInfo)、プレイヤーは必要なすべてのアニメーションで構築を開始します。
ソリッド-OOP原則。S-単一の責任：前の例で見たこと。ええ、でも継承はどこにありますか？
ここで：プレイヤーの健康と他の特性は別のエンティティによって処理されるべきですか？私はそうは思いません。体力のないプレイヤーはいません。もしあれば、私たちは継承しません。例えば、我々が持っていますIDamagable、LivingEntity、IGameActor、GameActor。IDamagableもちろんありTakeDamage()ます。
class LivinEntity : IDamagable {
private float _health; // For fields that are the same between Instances I would use Flyweight Pattern.
public void TakeDamage() {
....
}
}
class GameActor : LivingEntity, IGameActor {
// Here goes state machine and other attached components needed.
}
class Player : GameActor {
// Inventory, Building, Crafting.... components.
}
したがって、ここでは実際にコンポーネントを継承から分割することはできませんでしたが、ご覧のようにそれらを混在させることができます。たとえば、システムの種類が異なり、必要以上のコードを記述したくない場合は、システムの構築用の基本クラスを作成することもできます。実際、さまざまな種類の建物を持つこともできますが、実際にはコンポーネントベースでそれを行う良い方法はありません！
OrganicBuilding : Building、TechBuilding : Building。2つのコンポーネントを作成して、建物の一般的な操作やプロパティのためにコードを2回記述する必要はありません。そして、それらを異なる方法で追加し、継承の力を使用し、後でポリモーフィズムとカプセル化を使用できます。
間に何かを使用することをお勧めします。コンポーネントを使いすぎないようにします。
ゲームプログラミングパターンに関するこの本を読むことを強くお勧めします。これはWEBで無料です。