物理学とゲームロジックをUIコードから分離する
私は単純なブロックベースのパズルゲームに取り組んでいます。 ゲームプレイは、ゲームエリア内を移動するブロックで構成されているため、簡単な物理シミュレーションです。しかし、私の実装では、理想とはほど遠いものであり、より良い方法についての指針を教えていただけませんか。 多くのパズルゲームで行ったように、ゲームロジックとUIの2つの領域にコードを分割しました。 ゲームロジックは、ゲームの一般的なルール（チェスの正式なルールシステムなど）を担当します。 UIはゲーム領域とピース（チェス盤やピースなど）を表示し、アニメーション（チェスの駒のアニメーションの動きなど）を担当します。 ゲームロジックは、ゲームの状態を論理グリッドとして表します。各ユニットは、グリッド上の1つのセルの幅/高さです。したがって、幅6のグリッドの場合、幅2のブロックを境界と衝突するまで4回移動できます。 UIはこのグリッドを取得し、論理サイズをピクセルサイズに変換して描画します（つまり、定数を乗算します）。ただし、ゲームにはゲームロジックがほとんどないため、ゲームロジックレイヤー[1]は、衝突検出以外にはあまり関係がありません。仕組みは次のとおりです。 プレイヤーがピースをドラッグし始めます UIは、ゲームロジックにそのピースの正当な移動領域を要求し、プレイヤーがその領域内でそれをドラッグできるようにします プレイヤーは駒を手放す UIはピースをグリッドにスナップします（そのため、有効な論理位置に配置されます） UIはゲームロジックに新しい論理的位置を伝えます（ミューテーターメソッドを使用します。 私はそれに満足していません： ゲームロジックレイヤーのユニットテストを作成していますが、UIは作成していません。UIにはトリッキーなコードがすべて含まれていることがわかりました。ピースが他の人や境界と衝突してグリッドにスナップするのを止めます。 UIがゲームロジックに新しい状態を通知するという事実が気に入らないのでmovePieceLeft()、他のゲームのようにメソッドまたはそのようなものを呼び出すようにしたいのですが、そのアプローチにはあまり向いていません。ゲームロジックは、UIで可能なドラッグとスナップについて何も知りません。 最善の方法は、ゲームロジックレイヤーを取り除き、代わりに物理レイヤーを実装することだと思います。それに関していくつか質問があります。 このような物理層は一般的ですか、それともゲームロジック層にこれを行わせるのがより一般的ですか？ グリッドへのスナップおよびピースのドラッグコードは、UIまたは物理レイヤーに属しますか？ そのような物理層は、通常、ピクセルサイズまたはゲームロジック層のような何らかの論理ユニットで動作しますか？ ゲームのコードベースでイベントベースの衝突検出を見たことがあります。つまり、プレーヤーがピースをドラッグするだけで、UIがそれを素直にレンダリングして物理システムに通知し、物理システムがonCollision（）メソッドを呼び出します。衝突が検出されると作品に。もっと一般的なものは何ですか？このアプローチまたは最初に法的運動領域を求めていますか？ [1] レイヤーはおそらく私が言っていることの正しい言葉ではありませんが、サブシステムは誇張されており、各レイヤーは複数のクラスで構成されているため、クラスは誤解しています。