通常のMUDサイクルを取り除く

私はMUDエンジンに取り組んでおり、私がプレイしたすべてのMUDゲームとは少し異なる方法でそれを実行したいと思っています。「サイクル」システムはとても退屈だと思います。私が持っていたアイデアの1つは、すべてのクライアントのソケットを独自のスレッドで動作させることです。何百ものプレーヤーで終わることはないことは承知していますが、単一のプロセスで「大量」のスレッドを作成する際に問題があるかどうかを知りたいです。

または、「リアルタイム」で作成したい場合（戦闘など）に使用できる他の戦略。

皆さんが質問を理解してくれることを願っています。

ありがとうございました。

サーバーが利用可能な時間内にすべてを処理したり、ネットワーク要求を十分に速く処理したりできないため、MUDサイクルは通常ありません。コマンドをできるだけ速くスパミングすることは有効な戦術ではないためです。

単に、各能力に関連付けられたクールダウン/チャージアップタイマーがあります。ソーシャルデザインによっては、「移動」と「話す」が含まれる場合と含まれない場合があります。

一般に、ゲームのネットワーク処理のためにコアごとに複数のスレッドを持つことは無意味です。パケット処理に制限がある場合、コアあたりのスレッドがシステムを使い果たしてしまいます。スレッドが増えると、他のスレッドが必要とするCPU時間を使い果たしてしまいます。パケット処理に縛られていない場合、コアあたりのスレッドは十分に小さいため、あまりにも多くのコンテキストスイッチを介してシステムの他の部分に影響を与えることはありません。

スレッドのネクロマンシーについては申し訳ありませんが、この問題は、同時実行モデルとフレームワークを学習および教えるための私のお気に入りのペットプロジェクトです！

すべてのクライアント/ mobを独自のスレッドで実行すると自然な分割が行われますが、CPUコアよりも多くのスレッドを使用するとスレッドが高価になることがいくつかあります。これがMUDで使用しないやむを得ない理由ではない場合でも、より良い方法を学ぶのに十分な理由です。

アクションがいくつかのループをとる単一の固定時間ゲームループですべてのクライアントを実行することは、グラフィカルゲームの世界ではよく知られた方法です。ループを十分にきめ細かくすることでそれを隠すことができますが、世界のすべてを同じタイムサイクルに結び付けます。私が見るように、この方法の主な欠点は、本質的に並列化できないことです。誰かがスレッドを作成して、I / Oの構築/解析/送受信、AIの実行などを他のスレッドにオフロードできることを指摘しましたが、メインのゲームロジックを並列化するには、根本的な変更とスレッドセーフを維持するための多くの作業が必要です。

そのすべての作業を行った場合、おそらく私の現在のお気に入りであるActorモデル（http://en.wikipedia.org/wiki/Actor_model）に似たものになるでしょう。Actorモデルは時分割戦略であり、クライアントごとに1スレッドのアイデアで提案していたものにかなり近づきます。これを使用して、「アクター」をスタンドアロンスレッドのようにコーディングしますが、いくつかの制限があります。それらはイベント駆動型である必要があり、メッセージを渡すことによってのみシステムの残りの部分と通信できます（これは異なりますが単純です）。イベント駆動型ビットは、アクションが完了したとき、またはクライアント固有の頻度でなど、特定のタイミングでアクター固有のイベントを起動するようにスケジュールすることにより、完全に独立したタイミングの余地を作ります。

内部では、実装は、すべてのアクターによって生成されるメッセージのキュー（1つまたは複数）と、CPUコアの数に一致するスレッドのプールを使用します。スレッドはメッセージをキューから引き出し、受信側のアクターのメッセージ処理メソッドを呼び出して処理し、メッセージが「処理される」までそのアクターのコンテキストで実行されます。あなたの観点から見ると、各アクターは実際に実行されているときはいつでも独自のスレッドを取得しますが、システムの観点からは、それらを実行するCPUと同じ数のスレッドしかありません。

Erlang / OTPやAkkaなど、優れたActorフレームワークがいくつかありますが、基本的な考え方は単純で、フレームワークの追加の手間をかけずに任意の言語で実装できます。

完全を期すために、Actorモデルは実際には、スレッドセーフティのためのメッセージパッシング、同時実行性のためのイベント駆動型プログラミング、およびスレッドディスパッチメカニズムの組み合わせにすぎません。スレッドディスパッチビットを削除すると、「反応性」のシステムが残されます。これは、現在、一般にスケーラビリティに関して非常に流行しているものです（http://www.reactivemanifesto.org/を参照）。次に、実行をクラウド内の複数のマシンなどにマッピングできます...アイデアが出てきます...つまり、MUDプログラミングプロジェクトが市場性のあるプログラミングスキルを教えているということです。やったー！

コマンドが入ってくるときに戦闘コマンドを許可し、コマンドの実行にかかる時間に基づいてコマンドの後に時間遅延を追加できます。

Dragonrealmsはこのメソッドを戦闘やその他の多くのアクションに使用します。そこではラウンドタイムと呼ばれています。重い武器ほど時間がかかりますが、減らすことはできますが、力と敏捷性でそれをなくすことはできません。

とにかく、ネットワーキングは本質的にシリアルです（少なくともマルチTbpsの光ファイバー回線に入るまで）。ネットワークI / Oのためのスレッドを1つ持つことはゲームロジックから分離し、おそらくいくつかの自律エージェントのスレッドは理にかなっています。それ以外はすべてやりすぎです。