2

私は実際にはJavaのファンではないため、タイルベースの2DゲームをC ++に移行しています（一部の機能は優れていますが、慣れることができません）。TMXタイルマップを使用しています。この質問は、オブジェクト定義を実際のゲームエンティティに変換する方法に関するものです。Javaでは、リフレクションを使用して、指定されたタイプのオブジェクトを割り当てました（基本的なゲームエンティティから派生している場合）。

これは正常に機能しましたが、この機能はC ++では使用できません（理由は理解できますが、文句はありません。リフレクションが乱雑で、Javaで使用するのをためらっていました）。このデータを翻訳するのが最善の方法だと思っていました。私のアイデアは、すべてのエンティティが派生できる基本クラスであり（これはかなり標準的なようです）、ローダーにTMXマップの「type」値に基づいて派生タイプを割り当てさせます。私はこれを行うために2つの方法を考えました。

  1. 巨大なスイッチケースブロック。長くて嫌です。誰かがこれを提案するかどうかは疑わしいです（しかし、それは明らかです）。
  2. std :: mapを使用します。これは、任意の型名を関数にマップして、上記の型名に対応する上記のクラスを割り当てます。
  3. 最後に、1つの基本クラスのエンティティを作成し、さまざまなエンティティタイプにスクリプトを使用することを考えました。スクリプト自体はエンティティタイプをシステムに登録しますが、ゲームはロード時にエンティティタイプスクリプトをロードする必要があります（これは、エンティティごとの編集回数を2に減らす、1つのメインエンティティタイプ宣言スクリプトを介して実行できます）。 ：エンティティの作成、およびエンティティの登録）。

オプション2はかなり良さそうに見えますが、タイプごとに3つのコードを変更する必要はありません（エンティティクラスの定義、allocate関数の定義、およびstd :: mapへの関数の追加）。オプション3は、私の頭の中にある2つのことを除けば、すばらしいと思います。純粋にスクリプト駆動型のエンティティの速度が怖いです。また、私のエンジンにスクリプトを追加すること自体が大きなプロジェクトになることを私は知っています（ライブラリとのインターフェースのためのすべてのヘルパー関数を追加することは興味深いでしょう）。

誰かがより良い解決策を知っていますか？たぶん良くはないが、ただきれいだ。エンティティタイプごとのコード編集が少なくなります。

4

1 に答える 1

2

工場への自己登録を使用すると、ソリューション2でのコード変更の数を減らすことができます。欠点は、エンティティがこのファクトリ（自己登録）を認識しており、このファクトリがグローバル（シングルトンなど）のインスタンスである必要があることです。tisに問題がなければ、このパターンは非常に便利です。新しいタイプごとに、1つの新しいファイルのリンクをコンパイルするだけで済みます。

次のように自己登録を実装できます。

// foo.cpp
namespace 
{ 
  bool dummy = FactoryInstance().Register("FooKey", FooCreator); 
}

抽象ファクトリ、テンプレートスタイル、JimHyslopとHerbSutterによる

于 2012-05-13T05:05:43.727 に答える