ゲームサーバー用のErlangの可能性について考えているところです。(ああ、私はErlangの専門家ではありません。ステージを考えているだけです) これは、ゲームシミュレーションにアクターモデルを使用することを意味します。もちろん、最大の魅力は、複数のノードに分散された同時実行性です。
私の現在の大きな疑問は、衝突検出のようなマルチアクターの相互作用をどのように行うべきかということです。（これはほんの一例です）
どのゲームでも衝突検出は本質的に必要ですが、アクター モデルの性質上、グローバルに同期された状態クエリとすべてのターゲティング アクターの更新が必要なため、効率的ではなく、意味がありません。また、同期を使用すると、Erlang のアクター モデルのすべての利点が無効になります。
もちろん、スペース パーティショニングを正しく使用すれば、一度に対象とするアクターを小さくすることができますが、これは単なる最適化であり、主要な答えではありません。それとも、これはこの質問に対する正しい答えですか? 相互作用するアクターの数を減らすことで同期の範囲を狭めますか?
マップを小さな部分に分割し、各部分を独自のプロセスにします (各タイルが独自のプロセスになるように分割することもできます)。プレイヤーが移動しようとすると、タイル/サブマップにメッセージが送信され、そこに移動するというメッセージが表示され、タイルは問題がないかどうかを応答します。一度に 1 つのメッセージのみがタイル/サブマップによって処理されるため、これにより衝突が回避されます。複数のサブマップ/タイルがメッセージを同時に処理する場合があるため、これは依然として並行プログラムです。
Erlang でサーバーを実行する宇宙ベースのゲームがあります。秘訣は、各ロケーション/ノード/etc もアクターであるということです。物理演算を継続的に実行し、定期的に各ゲーム エンティティ アクターに情報を送信します。
アクター/エンティティとは何かについてより抽象的に考え始めると、全体がより明確になります。たとえば、衝突は本格的なアクターになる可能性があります。これにより、クライアント側がはるかに簡単になります。グラフィックとサウンドの効果を衝突に結び付けることができます。サーバー側でも、2 つのエンティティ間の複数の衝突効果を一定時間内に 2 回以上防止します。