クライアントとサーバーの両方を同時に効率的にコーディングするにはどうすればよいですか？

クライアントサーバーモデルを使用してゲームをコーディングしています。シングルプレイヤーでプレイする場合、ゲームはローカルサーバーを起動し、リモートサーバー（マルチプレイヤー）のようにローカルサーバーと対話します。これは、シングルプレイヤーコードとマルチプレイヤーコードを別々にコーディングしないようにするためです。

コーディングを始めたばかりで、大きな問題に遭遇しました。現在、私はすべてのゲームクラスをパッケージに編成して、Eclipseでゲームを開発しています。次に、サーバーコードで、クライアントパッケージのすべてのクラスを使用します。

問題は、これらのクライアントクラスにはレンダリングに固有の変数があり、これは明らかにサーバーでは実行されないことです。

サーバーで使用するクライアントクラスの修正バージョンを作成する必要がありますか？または、クライアント/サーバーがそれを使用しているかどうかを示すために、ブール値でクライアントクラスを変更するだけです。他にオプションはありますか？サーバークラスをコアクラスとして使用し、レンダリングクラスで拡張することについて考えただけです。

レンダリングコードはゲームロジックとは別のものであるため、ゲームロジックとは別にすることをお勧めします。

レンダリングコードをクライアント/サーバーコードから分離すると、いくつかの利点が得られます。

• レンダリングするコードは1か所にあるため、専用サーバーの作成は簡単です。
• updateフェーズをフェーズから分離renderし、異なるタイムステップで実行できます。
• を使用することで、レンダリングコードがゲームの状態を変化させないようにすることができますconst。バグを減らします。

クライアントとサーバーのコードを明確に分離する必要があると思います。サーバーコードとクライアントコードは、インターフェイスで公開されている機能を除いて、相互に認識すべきではありません。サーバーは、レンダリング、クライアントの登録、位置の追跡、時間などについて何も知らないはずです。懸念を明確に分離している場合、ゲームを維持し、さらに開発するのが簡単です。これが少し役立つことを願っています。

懸念事項の分離FTWは、他の人が言ったように、最終目的がクライアントアプリケーションとサーバーアプリケーションを分離することである場合、さらに一歩進める必要があります。クライアント固有のもの、サーバー固有のもの、共有されるものを決定する必要があります。共有されるものすべてについて、排他的に共有されるコードのクラスに分けます。クライアント固有またはサーバー固有のクラスは、必要に応じて共有クラスをサブクラス化または参照できます。共有クラスを別のプロジェクトに移動して「共有ライブラリ」JARを構築し、そのJARをクライアントプロジェクトとサーバープロジェクトの両方に含めます。

これにはいくつかの利点があります：関心の分離を明確にし、すべてを別々のプロジェクトに保持します。クライアントとサーバーが同じ共有コードで開始することを保証します（同じバージョンの共有JARを使用している場合）。また、共有コードを気付かずに「誤って」変更することを不可能にします。共有コードが独自のプロジェクトにある場合、そのプロジェクトで何かを編集しているときに、変更がクライアントとサーバーの両方にどのように影響するかを認識する必要があることがわかります。