これは基本的にはプロセスとスレッドの質問です。どちらもそれほど違いはなく、スレッドは軽量プロセスと呼ばれることもあります。最大の違いは、別のプロセスには独自のアドレス空間があることですが、他の違いがあります（1）。
プロセスごと
- アドレス空間
- グローバル変数
- ファイルを開く
- 子プロセス
- 保留中のアラーム、割り込み、シグナルハンドラ
スレッドごと
これらの違いに基づいて、ファイルハンドルとグローバル変数を共有できるように、サーバーとクライアントのスレッドを同じプロセスに置くと便利です。これは、「同じプロセスで」のアプローチに対する議論であり、別の（小さな）議論は、プロセスごとに1つの「Windowsファイアウォール」ポップアップしか表示されないというものです。「異なるプロセス」アプローチの議論は、人が複数のクライアントを実行する必要なしに複数のサーバーを実行できるということでしょう。これは、セットアップのような専用のホストにとって理想的であり、私たちが一人称シューティングでよく目にするアプローチです。
オフラインプレイ（さらにはシングルプレイヤー）でもサーバープロセスまたはスレッドを使用するというアイデアは、実際によく使用されている素晴らしいアイデアです。ロード画面を見ると、多くのゲームがこれを行うことがわかります。「受信」のような小さなヒントは、それを提供します。マルチプレーヤーにする場合、ほとんどのゲームルールはサーバーによって管理されるので、これを行うのは理にかなっています。これにより、記述しなければならないコードが削減され、クライアントと「ゲーム」が明確に分離され、コードの品質が向上します。
では、プロセスとスレッド間の通信についてはどうでしょうか。プロセス間通信は、（名前付き）パイプ、共有メモリ、COMなど、さまざまな方法で実行できます。これは、実際に使用しているテクノロジに依存します。ただし、サーバーを作成している場合は、ソケットやTCPのようなものを使用したネットワーキングバリアントを使用することをお勧めします。これはもちろんLIDGRENが役に立ちます。
これらのテクニックの多くは、スレッド間通信にも有効です。しかし、これはあなたが使用しているテクニックにさらに依存します。再びTCPを使用することもできますが、おそらくこれよりも単純なシステムはイベントとマーシャリングですが、これによりゲームのループが非決定的になる可能性があります（2）。
出典
- オペレーティングシステムの設計と実装（MINIX本）、Andrew S. Tanenbaumによる第3版
- Glenn Fiedlerによるタイムステップの修正：http : //gafferongames.com/game-physics/fix-your-timestep/