私たちはいくつかの異なる状態を持つプレイキャラクターでゲームを作っています。ほとんどの例では、ステートに基づいて制御可能な文字のswitch文が見えます。ほとんどのゲームではこれが標準的な方法ですか？または、その状態のアニメーションとロジックを処理する一連の状態を作成する方がよいでしょう。後者は必要ではないかもしれないが、より柔軟なクラスをたくさん作り出すようだ。 case文を使うと、コードがもっと乱雑になりますが、全体的なファイルが少なくなります。 AI型関数の場合、状態モデルを使うほうが良いでしょう。私は、「walkleft」、「walkright」のような単純なもののための状態オブジェクトを作るべきかと思います。それとも私が行方不明のことをする良い方法がありますか？状態と制御可能なゲームオブジェクト
ありがとうございます、これは十分明確です。
すべてはswitch文の大きさによって異なります。私は、個人的には、国家のオブジェクトの束を作るために傾くだろう。あなたがそのためにたくさんのファイルを持ってしまうと、そうなるでしょう。これはおそらくコードを理解しやすくします。なぜなら、各状態は他のコードが干渉する可能性が低いためです。あなたが状態の振る舞いについて推論しようとすると、あなたの注意をそらすための雑多なコードが少なくなります。
コードを作成し、可能であればスタンドアロンモジュールとしてテストできるように、デザインを細かく分割することをお勧めします。これにより、デバッグがはるかに簡単になります。あなたはすべてをモジュール化して持ち運ぶ必要はありませんが、私はいくつかの大きな厄介なものではなく、多くの小さなクラスに傾いています。
あなたは、必要でないものを作成することに少し注意することは間違いありません。柔軟性があまりにも高いと、維持しなければならない苦痛に終わります。あなたの現在の問題を処理できるだけの柔軟性を持たせてください。将来の仮想的なニーズを解決するのに多大な努力を払わないでください。あなたが今必要なものに集中してください。大量のswitch文を使用すると、コードが乱雑になります。私はそれがあなたの答えをそこに与えると思う。小さな関数と小さなクラスで簡単なコードに向かう。確かにそれらをたくさん持っていますが、膨大な機能の中で互いに積み重ねられたステートメントがどれだけ一緒にフィットするかよりも、いくつの小さな関数が一緒に収まるかを把握する方がはるかに簡単です。
シンプルなケースステートメントと本格的なステートマシンの中間地点として、ジャンプテーブル（別名ブランチテーブル、より一般的にはファンクションまたはメソッドテーブル）を使用することを検討してください。