私たちは、いくつかの異なる状態を持つキャラクターをプレイするゲームを作成しています。ほとんどの例では、状態に基づいて制御可能な文字にswitchステートメントが表示されます。これは、ほとんどのゲームで行われる標準的な方法ですか？または、その状態のアニメーションとロジックを処理する一連の状態を作成することをお勧めします。後者は、必要ではないかもしれないが、より柔軟性のある多くのクラスを作成するようです。caseステートメントを使用すると、コードが乱雑になりますが、ファイル全体が少なくなります。AIタイプの関数には、状態モデルを使用する方がよいことを私は知っています。私が得ているのは、「walkleft」、「walkright」などの単純なものの状態オブジェクトを作成する必要があると思いますか？それとも、私が見逃していることを行うためのより良い方法はありますか？
ありがとう、これが十分に明確であることを願っています。
それはすべて、switch ステートメントの大きさによって異なります。個人的には、たくさんの状態オブジェクトを作成することに傾倒します。そのためにたくさんのファイルができてしまったら、それでいいのです。各状態は、他のコードが干渉する可能性が少ないモジュールであるため、おそらくコードが理解しやすくなります。状態の動作について推論しようとすると、気を散らすその他のコードが少なくなります。
設計を小さな断片に分割してコーディングし、可能であればスタンドアロン モジュールとしてテストできるようにすることをお勧めします。これにより、デバッグがはるかに簡単になります。すべてをモジュール化することに夢中になる必要はありませんが、いくつかの巨大でぎこちないクラスよりも、多くの小さなクラスに傾倒します。
必要のないものを作成することに少し警戒するのは正しいことです。柔軟性が高すぎると、維持するのが苦痛になります。現在の問題を処理するのに十分な柔軟性を持たせてください。仮説的な将来のニーズを解決することに力を入れすぎないでください。今必要なものに集中してください。多数のケースを含む大きな switch ステートメントを使用すると、コードが乱雑になることがわかりました。それがあなたの答えをすぐに与えると思います。小さな関数と小さなクラスを含む単純なコードを使用する傾向があります。確かにそれらはたくさんありますが、巨大な関数で無数のステートメントが積み重なってどのように適合するかよりも、いくつの小さな関数が適合するかを把握する方がはるかに簡単です。
単純なケース ステートメントと本格的なステート マシンの間の中間点として、ジャンプ テーブル (別名、ブランチ テーブル、または最近では関数またはメソッド テーブル) を使用することを検討してください。