ほとんどのきちんとしたエンジンとフレームワークは、必要な機能を提供し、邪魔をしません。
彼らですか？それはむしろ、グラフィカルに言えば、あなたが何をしているかに正確に依存しています。
多くの種類のゲームには、グラフィカルな質問に対する標準的な回答があります。たとえば、平均的な2Dゲームは、XNA / MonoGameなどの2Dの腕前でうまく処理できます。単なるスプライトであり、テレインのバッチで提供されたり、回転したりすることができます。
しかし、ゲームが以前は平均的な2Dゲームだった場合、高さマップを使用して画面に相対的な奥行きの外観をもつ詐欺師を作成するなど、いくつかのクールなテクニックについて読みます。そして、あなたはそれをしたいのです。
今、あなたは通常のマッピングと、場合によっては視差マッピングを採用しています。すべてが「レンダリングスプライト」の同じコンテキストにありますが、多くの純粋な2Dエンジンが処理できる必要があります。具体的には、マルチテクスチャの「スプライトブリッティング」が必要です。これは、多くの2Dエンジンが実行できるものではありません。
エンジンがあなたに適応できない場合はどうしますか？つまり、複数のパスを実行する必要があります。1つは色用で、もう1つは法線マップを介した照明用です。ただし、カラールックアップに視差マッピングを使用するには法線マップの高さフィールドが必要なので、これは機能しません。んで、どうする？透明度を得るにはアルファが必要なので、アルファを盗むことはできません。また、エンジンはマルチテクスチャをサポートしていません。
したがって、次のいずれかを選択する必要があります。
- アイデアを放棄します。これは、ゲームが機能的にエンジンによって制限されることを意味します。
- エンジンをハックしてマルチテクスチャを作成します。あなたがソースコードにアクセスできると仮定すると、あなたは今それを他人のコードを突くために自分で取っています。これはまた、あなたがそれを維持する必要があることを意味します。
- エンジンの制限内で、できる限りのことをしてください。したがって、法線マップでは視差を取得できますが、色では取得できません。望んでいたものとは異なるかもしれませんが、何もないよりはましです。
例として、Geometry Warsを取り上げます。ほとんどの2Dエンジンは、これらの種類のビジュアルを吸い込みます。それらのほとんどは、線ではなくスプライトの描画に基づいて構築されているためです。それは非常に特殊な種類のレンダラーを必要とするゲームです。
結局のところ、あなたはあなたのゲームのニーズにとって重要なあなたのゲームの要素に責任を持つ必要があります。ゲームの視覚的な外観が、特定の効果ではなく、主に使用する画像とモデルのアートスタイルによって開発されている場合は、事前にパッケージ化されたソリューションを使用するのが適切です。ただし、カスタムレンダリングコードによってゲームの視覚スタイルが大幅に定義されている場合、標準のエンジンがボックスの外側で行うことを決定した場合、標準エンジンが深刻な制限になる可能性が高くなります。
さらに、非常に実用的な問題があります。すべてのゲームエンジンが同じように移植できるわけではありません。
最近のモバイルプラットフォームの台頭により、ゲームの市場は多数のOSやユーザーインターフェイスデバイスに広がっています。すべてのエンジンがすべてのデバイスで動作するわけではありません。また、エンジンがプラットフォーム上で機能しない場合、時間をかけてプラットフォーム上で機能させることはできません。結局のところ、そもそも最初にエンジンを使用したわけですよね？
自分のゲームが特定のプラットフォームで機能することが重要な場合は、再度責任を負う必要があります。そして、これで成功するための「最も簡単な」方法は、自分でやることです。低レベルの詳細を処理する必要がある場合に、おそらくより単純なプラットフォーム固有のフレームワークを使用して、複数のプラットフォームで動作できるエンジンを構築します。そうすれば、それが壊れた場合、それはあなたのコードです。あなたはそれを修正できる最高の人です。