現在、2Dゲームエンジンの新しい機能を直接エンジンにコーディングして実装し、テストしています。同時に、スクリプト機能を備えたショーケースゲームがあり、エンジン機能を呼び出す必要があります。たとえば、ゲーム専用にスクリプトを作成するのではなく、固定タイルの動きをエンジンのEntityクラスに添付します。これは、複数のゲームに使用される一般的なエンジンのアイデアを間違いなく壊しています。
適切な部分(エンジンとゲーム)の正しい実装に焦点を当て続けるベストプラクティスはありますか?
現在、2Dゲームエンジンの新しい機能を直接エンジンにコーディングして実装し、テストしています。同時に、スクリプト機能を備えたショーケースゲームがあり、エンジン機能を呼び出す必要があります。たとえば、ゲーム専用にスクリプトを作成するのではなく、固定タイルの動きをエンジンのEntityクラスに添付します。これは、複数のゲームに使用される一般的なエンジンのアイデアを間違いなく壊しています。
適切な部分(エンジンとゲーム)の正しい実装に焦点を当て続けるベストプラクティスはありますか?
回答:
これについては、いくつかの考え方があります。1つは、エンジンに必要な特定の機能をリストすることです(ここで尋ねたものです)。しかし、もう1つの方法は、「エンジン」についてあまり気にせずにゲームを作り始めることです。ゲーム(特に、すべてのゲームで使用される機能)を特定のゲームのソースから「エンジン」と呼ばれる共有コードベースに移行する必要があります。
結局のところ、ゲームではなくエンジンで特定の機能が必要な理由は、複数のゲーム間で共有されるからです。通常は、描画コマンド、入力コントローラー、ネットワークコードなどです。2Dゲームエンジンには、画像の読み込み、zオーダーの表示階層、スプライトシートの処理、トゥイーンなど、多くの2Dグラフィック機能があります。多くのゲームには物理シミュレーションが必要ですが、多くのゲームには必要ありません。一方、ほぼすべてのゲームで使用される「ボンネットの下」のものには、タイマー、イベントメッセージング、さらにはゲーム開発に固有の数学関数(たとえばdistanceToTarget()
長い話:
A)エンジンには、ほとんどのゲームで共有される機能が必要です。
B)ゲームの束を作成することにより、どの機能が共有されるかを学びます。
just start making games without worrying too much about the "engine"
、間違いなく素晴らしい提案です。
just start making games without worrying too much about the "engine"