design-patterns - ゲームとレンダリング ロジックの分離

Question

実際のゲーム エンジン/ロジック コードからレンダリング コードを分離する最善の方法は何ですか? そして、それらを分離することは良い考えですか？

Knightというゲームオブジェクトがあるとしましょう。騎士は、ユーザーが見るために画面にレンダリングする必要があります。現在、2 つの選択肢が残されています。呼び出し可能なメソッドを Knight に与えるか、Render/Drawすべての Knight のレンダリングを処理するレンダラー クラスを作成します。

2 つが分離されているシナリオでは、騎士は彼をレンダリングするために必要なすべての情報を保持する必要がありますか、それとも分離する必要がありますか?

最後に作成したプロジェクトでは、オブジェクトをレンダリングするために必要なすべての情報をオブジェクト自体の内部に格納することにしましたが、実際にその情報を読み取ってオブジェクトをレンダリングする別のコンポーネントがありました。オブジェクトには、サイズ、回転、スケール、現在再生中のアニメーションなどの情報が含まれ、これに基づいてレンダラー オブジェクトが画面を構成します。

XNA などのフレームワークは、オブジェクトとレンダリングを結合することは良い考えだと考えているようですが、特定のレンダリング フレームワークに縛られることを恐れていますが、個別のレンダリング コンポーネントを構築すると、いつでもフレームワークを変更する自由度が高くなります。

Answer 1

KnightRenderer別のクラスを作成します。利点:

• ゲーム ロジックとレンダリングを明確に分離します。彼自身は、ゲーム サーバー上で実行することさえあり、Knightレンダリングについてはまったく知りません。
• 1 つだけの機能に関係する、より小さく単純なクラス。

KnightRenderer(役職、ステータス)について知る必要があるすべての情報はKnight、.NET で公開されている必要がありKnightます。

レンダリングに固有のプロパティはKnightRendererクラスに入ります。たとえば、騎士が攻撃を受けたときに点滅させたい場合は、カウンターまたは時間の値を保存する必要があります。

Answer 2

私は遅れていることを知っていますが、将来の読者のために、私が書いたチュートリアルに興味があるかもしれません。

私は本当の専門家ではありませんが、これが私が関心の分離を適切に見ている方法です：http:
//aurelienribon.wordpress.com/2011/04/26/logic-vs-render-separation-of-concerns/

Answer 3

オブジェクトを可能な限り汎用化し、ゲームプレイの事実をコードにできるだけエンコードしないように努めます。

たとえば、Entity、Object、または Actor クラスがあり、そのクラスには意思決定 (AI) へのポインターとグラフィック表現へのポインターがあります。

その意思決定は、必然的にゲームプレイの事実と結びついています。実際、それはゲームプレイの事実の一部です。したがって、これは意思決定者に「KnightAi」などの名前を付ける場所です。

一方、グラフィック表現はほんの少しのグラフィックです。他のすべてのエンティティと同じように描画されます。モデルまたはいくつかのビットマップといくつかのアニメーションがあるかどうか...これは単に「モデル」のようなものと呼ばれ、エンティティがプレーヤーにどのように見えるかを定義するように指示された情報をロードします。騎士と馬と城をレンダリングする場合、データが異なるだけですべて同じことを行うことがわかります。持っているデータの種類も同じで、中身が違うだけです。

エンティティがすべて円で表されているとします。描画する必要があるサイズの CircleRenderer を指すようにするだけです。必要な円のサイズ (または色など) ごとに異なるレンダラー クラスを作成することはありません。