2つの別個のグラフィックライブラリで同じゲームロジック

ゲームのロジックを再コード化する必要なしに、ゲームを2Dと3Dの両方のグラフィックスで（別々に）使用できるようにする抽象化/プログラム設計のコード哲学/構造は何ですか？

同じコードを取り、最小限の変更（たとえば、2Dアセットのファイル名を3Dアセットのファイル名に交換するなど）を行い、ジェネリック/テンプレートごとに基本クラスのいくつかの特殊化をプラグインしている可能性があります。

意味のある現実的な状況に置くために、いくつかの非常に優れたゲーマーリグを備えたプレーヤー用の1つの一流の、パフォーマンスを要求する3Dクライアントと、古いもののためのより控えめな2DクライアントがあるLANマルチプレーヤーゲームを想像してください。誰かが屋根裏で見つけたほこりっぽい箱。しかし、それでも同じゲームです。同じイベントが登録され（誰かがコインを拾った）、同じネットワークプロトコルが使用され、世界は比例します。

MVCコンテキストに配置するには：コントローラーはまったく同じ（「上」キーを押すとプレーヤーの加速が3.5単位/秒に設定されます）、ビューはまったく異なり（2Dと3D）、モデルは同じですグラフィックに直接関連するものを除いて（環境の衝突チェックは5秒ごとに実行され、同じアルゴリズムを使用します。これは、2DバージョンのすべてのゲームオブジェクトにZ座標があることを意味しますが、無視するか、別の方法でユーザーに表示します（たとえば、プレイヤーが空中にいるときにさらに左に表示される影によって）。

これをこのような魅力的なトピックにしているのは、開発者が自分のデータがどのように構造化され、制御がどのように流れるかについて非常に明確な考えを持つことを強制することです。これは、SDL、D3DX、OpenGLなどのグラフィックライブラリ以外の使用を意味するものではないことに注意してください。ゲームエンジンはありません。

これはほとんど理論的な問題なので、プログラミング言語は省略しますが、例を挙げたい場合は、好きな言語を使用できます。C++を使いたいなら、Brainfuckでもいいと思います。課題まで（具体的な回答はもちろん、抽象的な回答も歓迎します！）

私が必要とするすべて（？）は、グラフィックスライブラリをラップする抽象化のレイヤーになると思います。使用するライブラリごとに新しいものが必要であり、それぞれがまったく同じ外部APIを持つ必要があります。

文字列のローカライズについて考えてみましょう。「Inventory」という文字列をゲームにハードコーディングする代わりに、（おそらくカスタムビルドされた）ローカライズライブラリを呼び出します。ゲーム。

同様に、グラフィックエンジンへのすべての呼び出しは、ラッパーを介して行われます。

これを行う際に、グラフィックスエンジンに与えることができるコマンドを制限/制限し​​ます。ここにいくつかの重要なものがあります：

1. （場所）に（グラフィックオブジェクト）を描画します
2. （グラフィックオブジェクト）の（アルファ、回転など）プロパティを変更する
3. （グラフィックオブジェクト）を（場所）に移動
4. （レベル名/データ構造）の構築マップ

そして、あなたがあなたのプロジェクトに取り組むときにあなたが見つけるであろう他のいくつか。

Strict-Typed Object-Oriented Languageを使用している場合は、上記のコマンドを、ラッパーがすべて実装するインターフェースに呼び出します。好ましくは、これらは保護されていない/公開されている唯一の方法です。

次に、グラフィックライブラリごとに新しいラッパーを作成し、APIを実装します。__で__を描画するコマンドが与えられたら、コードを使用してスプライトまたはモデルを作成し、それを環境に描画する必要があります。これには、特定のシンボルによって別の時間に再アクセスできるように各スプライトをハッシュに格納するなど、いくつかのトリックが必要になる場合があります。

マップの作成に関しては、最も効率的な方法は、各グラフィックエンジンの各マップを事前に事前に作成し、ルックアップを行うことです。または、マップを独自のカスタムデータ構造に格納し、ラッパーを使用してそのデータ構造からマップを構築することもできます。

これがあなたを始めるのに役立つことを願っています=]

MVCに十分近いパラダイムでゲームのアーキテクチャを構築して、表示コードの完全な抽象化を可能にすることは、大規模なプロジェクトではおそらく非常に困難です。ただし、2Dと3Dの両方のクライアントをサポートするゲームを作成する際の最大の障害は、両方のクライアントが同等に機能するゲームを設計することです。

2つのクライアントを作成してサポートするという完全な意図でゲームの設計を開始する必要があります。おそらく、すべてのゲーム機能を2Dクライアントにとって意味のあるものに制限するのが最も安全でしょう。

落とし穴の例として、制限された機能セットに合わせて設計していない場合、重要な情報またはオブジェクトが特定の角度からしか見えないレベルを作成することがあります。2Dクライアントがこれらの重要なオブジェクトのそれぞれに可視性を持つ視野角を明示的にサポートしていない限り、360度の表示自由度を持つ3Dクライアントには問題ありませんが、クライアントのユーザーに障害が発生します。

2Dクライアントに特定の数の視野角（8または16など）を設定し、これらの制約に適合するようにすべてのコンテンツを開発するのが最善です。残念ながら、特定の角度のセットからのみ表示できるように設計されたレベルとオブジェクトがある場合、3Dクライアント内からはかなり奇妙に見えることがあります。

私の意見では、同等の機能を持つことを目的とした2Dクライアントと3Dクライアントを可能にするゲームデザインを試みるのは適切ではありません。非対称のゲームプレイオプションを設計し、各クライアントがその強みを発揮できるようにするためには、リソースのより良い使用法だと思います。たとえば、2Dクライアントが主にゲームの世界における戦略レベルの視点に焦点を当てていて、3Dクライアントが戦術レベルのゲームプレイに使用されている場合です。

私はあなたがあなた自身の質問にかなり答えたと思います：

MVCコンテキストに配置するには：コントローラーはまったく同じ（「上」キーを押すとプレーヤーの加速が3.5ユニット/秒に設定されます）、ビューはまったく異なり（2Dと3D）、モデルは同じですグラフィックに直接関連するものを除いて。

したがって、入力、ゲームロジックなどとグラフィックの間の適切な抽象化を提供することで、問題を解決します。

これは基本的にMVCモデルのポイントであり、特にデスクトップアプリケーションとWebアプリケーションに関係します。同じデータにアクセスして操作する複数のクライアントが存在する可能性があります（たとえば、Webインターフェイス、モバイルクライアント、および電子メール用のデスクトップクライアント）。

シンプルにしたい場合はシンプルにしてください：-オブジェクトを移動するゲームロジックを記述します。レンダリングに関連するデータを保存しないでください。-ゲームデータの状態を確認して描画する機会が与えられるレンダラーを記述します。

これには多少複雑なプログラミング手法を使用できます。必要なのは、ゲームオブジェクトごとにレンダリングする必要がある「追加の」データを取得する方法だけです。最も簡単な方法は、必要な追加データをゼロにすることです！ゲームオブジェクトが「ウィザード」の場合、ウィザードを描画します。

より複雑なメソッドが必要な場合は、ポリモーフィズム、メモリメントパターン、ハッシュテーブル、void *ポインタなどを検討してください。過度に設計しないでください（これらのメソッドのほとんどは過度に設計されています）。