2011-12-17 11 views
2

私はゲームサーバーとクライアントを作成しています。サーバーは世界を生成し、さまざまなプレーヤーのクライアントまで提供します。大規模なマルチプレイヤーではありません。専用サーバー対クライアント/サーバーの複合?

クライアントは(少なくとも今のところ)かなり要求の厳しいソフトウェアレンダラーを実行するだけでなく、標準のクライアント側のシミュレーションを実行します(これは権限のあるサーバーの承認を必要とします)。良い。

サーバはまた、プロセッサを集中すること、およびプロジェクトの性質を与えられますが、プロジェクトが進むにつれてより多くのようになるだけに可能性があります。世界は手続き的であり、そのうちのいくつかはの間に行われます。の再生中です。世界のオプションは、ゲームが開始される前に、その時のシステム能力に基づいて設定されます(理想的には、最小限の外部プロセスが実行されていることが理想的です)。したがって、ハードウェアスレッド数のスケーラビリティは、サーバにとって絶対必要です。

また、MMOではなく、であるため、プレイヤーはすべてクライアントとサーバーの両方にアクセスできるため、独自のサーバーをセットアップできます。多くのプレイヤーは、友人と遊ぶことができるように、サーバーをホストしてクライアントを実行するマシンを1台しか持たないでしょう。この事実に基づいて、私はより良いサービスを提供するでしょうか?

  • 組み合わせ、クライアントとサーバプロセス
  • 別々のクライアントとサーバが

を処理...なぜ?

PS。上記の複雑さのうちのいくつかが後で過ぎ去ったとしても、私はできるだけ早くアーキテクチャを(この点で)適切にする必要があります。

答えて

1

私は意思決定のお手伝いをするための最も重要な側面があると言うだろう - クライアントとサーバーの両方のために共有されているすべての計算集約的なタスクがありますか?クライアントとサーバーの両方に対して計算を2回ではなく1回行うことができれば、1つのプロセスを持つことが理にかなっています(ただし、これは実装が難しいかもしれません)。そうでなければ私はそれを別に言う。

は、私は、分離プロセスといくつかの利点を参照してください。

  • は、クライアントがクラッシュすると、サーバーが誤って
  • を起動したまま(および/または怒り(私は複雑レンダラーおよび/またはバギーグラフィックドライバでより多くの可能性と言うだろう)ときQQ)出て行くゲームは が
  • (必要な場合)、それは他の人にいくつかのコアにサーバとクライアントをバインドする方が簡単です
  • あなたはおそらくとにかく専用サーバーを記述する必要が
  • (それが上でホストすることができ
  • 、他のプレーヤーのためのゲームを殺すことはありませんリモートサーバー、おそらくグラフィックスなし)それを他のOSに移植する方が簡単かもしれません...

クライアントコードは全体的にあまり複雑に(私はそれを思い付く場合、私は、後でリストに何かを追加することも)

+0

私はあなたのポイント1〜3を特に洞察力があると感じる、これらのためにあなたに感謝します。 4については、厳密にはそうではありません。クライアントを組み込んだサーバーを作成し、単にクライアントのアスペクトをオフにすることができます。 5つは潜在的ですが、もちろんあなたのポストの始めに示唆するように、クライアントとサーバーの間にロジックが重複しています。ただし、同じボックスで両方を実行している場合は、クライアント対サーバーの調整は扱いません。私が純粋なクライアント/サーバーにならないようにする唯一のことは、この懸念です。 –

+0

私が最初に示そうとしていたことは、単にコードの重複を排除するのではなく、実際の実行の冗長性を取り除くことでした。クライアントとサーバーの両方が何かをしなければならないという意味、つまり。いくつかの物理計算 - とクライアントとサーバーの間で結果を共有することができます、それは1つのプロセスでそれらを持って、結果を共有する意味があります。しかし、これの効率は、主にどのくらいの作業を共有できるか、そして共有を実現するのがどれほど難しいかによって決まります。 – Fox

+0

この問題は、サーバーが権威を持っていることに気付きました。サーバーのセキュリティをある程度の危険にさらすことなく、そのロジックを組み合わせることはできません。純粋なクライアントサーバーへのさらに別のポインタ。 –

1

懸念の分離は常に重要な要素ですので、別々のプロセスとして保つ方が良いでしょう。パフォーマンスにとっても優れています。クライアント機能のみを使用したい場合は、サーバー関連のコードを同じアプリケーションに保存する必要はありません。私はそれが必要な場合にのみ私はそれを起動します。

+0

あなたは高い需要で実行しているサーバーのシミュレーションを管理することを提案しているだろうか、しばらく同時に同じボックスでクライアントを実行していますか?サーバーの設定はゲームのロビーに設定されており、実行時には変更できないことに注意してください。スレッドの競合を最小限に抑え、クライアント上でサーバーの優先順位を決めることができるので、クライアント/サーバーの統合されたアプリケーションでは全体的なコントロールが優れていると思います。 –

+0

それはこの需要がどれほど高いかによって異なります。標準的なデスクトップPCには、クライアントに十分な機能がありません。同じマシン上で実行されているクライアントに加えて、3つ以上のクライアントを接続することは期待しないでください。シンプルなPCには、これに必要なリソースがありません。 – Tudor

+0

Hmm。私はそれが非常に主観的であると感じます。スケーラビリティに関するディスカッションの全体的なポイントは...設計時には、実際にユーザーが持つことが分からないことです。 Total Annihilationは、デザイナーが現実的に予見していたものを何年も超えて使用されていたスケーラブルなサーバーの非常に良い例でした。そのスケーラビリティは、10年以上にわたって非常によく機能していました。 –

関連する問題