3

私は、Urban Deadが使用するものと同様の 3 x 3 ビューポートを持つ JavaScript Web ゲームを作成しています。「世界地図」は 100 x 100 の 2D 配列サーバー側 (nodejs) として格納され、座標の各ペアが「部屋」を定義します。したがって、3 x 3 ビューポートには 9 つの部屋の名前と内容が表示されます。

ユーザーの位置は座標としてサーバー側に保存されます。例Bob = { x : 2, y : 3 }。したがって、ボブの x 座標はBob.xです。クライアント (ブラウザ) はこれを取得して、他の 8 つの部屋の座標を計算し、それらの部屋の内容をサーバーに問い合わせます。これらはビューポートに表示されます。これは、 Urban Dead (左上隅)のビューポートのように見えると思われます。

質問

ビューポートを「リフレッシュ」または更新するにはどうすればよいですか? この方法でやろうと思って...

1)プレイヤーが座標 (2,3) から (1,3) に移動したとき。クライアントはサーバーに 9 つの部屋の内容を再度問い合わせ、すべてを再描画/表示します。

2)ルームの 1 つのコンテンツが変更されると、サーバー (nodejs) は、9 つ​​のルームのコンテンツをサーバーに要求し、すべてを再描画/表示するように指示するクライアント側関数を実行します。

プログラミングに慣れていないので、この実装は単純すぎるか、非効率的ではないでしょうか?

4

3 に答える 3

1

The question is do you care of AFK being notified, and how important is information about next room.

If you think a strategy can change if a room is updated ? In this case update every time a update is done.

If a player don't care then change are done when pass to next room.

A middle way solution is to ask a "delta" update ( just element who have been modified ) every 10s or 30s depending of the game. In this case us a central clock can be funny ( multiple player will update a same time ), and this create a turn-style gameplay.

As a RPG player ( paper RPG ) I will think the third is a good way. You can even mix solution : short time update for current room, and perception based time ( a bling and deaf will update exterior room only at major event ).

于 2012-12-07T14:44:18.183 に答える
1

前者のオプションが最適です。純粋に、マップが拡大するにつれて、クライアントにマップの特定の領域をロードさせるトリガー領域を設定しやすくなるという理由からです。表示またはアクセスできる部屋のみを読み込むこともできます。

これは、たとえば、複数のキャラクターがいる場合にも役立ちます。ある場所にメイン キャラクターがいて、別の場所にサブ キャラクターがいるとします。クライアントが自分がどこにいるかを知り、各キャラクターが何を見ることができるかを理解し、サーバーからこの情報のみを要求する方がはるかに良いでしょう. これは、サーバーがすべてのルーム情報を聞いている人に常にブロードキャストするよりも、はるかに拡張可能なソリューションです。

部屋のコンテンツの変更に関しては、これはサーバーからすべてのクライアントへのイベントとしてフラグを立てることができますが、純粋に部屋の座標と最小限のデータに基づいています。このイベントが、クライアントが現在表示できるルームの 1 つをカバーしている場合、そのクライアントによるルーム情報の要求が発生する可能性があります。したがって、これにはオプション 2 の一部が含まれますが、あまりブロードキャストしないでください。

類推として、これは、クライアント/ユーザーが必要なときに Web サイトから必要なリソースのみを要求し、興味のあるコンテンツに関するアラートをメールで送信するようにサインアップすることに似ています。ユーザーが RSS フィードにサインアップして、サイトで何かが変更されたときに通知を受けるのではなく。前者はより最適で、特定の方法で制御できます。ユーザーがサイトのコンテンツ全体を概観することに関心がある場合は、後者が適しています(通常、ゲームではそうではありません。カンニング）。

全体として、両方のアプローチの一部を実装して話し合った後、役立つでしょう。しかし、それが選択である場合、最初の選択により、より多くの制御が可能になります。

于 2012-12-07T14:44:48.583 に答える
1

単純すぎる、または非効率的なソリューションについては心配しません。難しいのは、ゲームをプレイ可能で楽しいものにすることです。最適化は後で行います。

例を見ると、転送するデータの量はそれほど大きくないように見えます。更新用に 9 つの部屋セットをすべて取得できるはずです。

間隔を空けてサーバーからデータをプルしていますか (ポーリング)、またはサーバーからクライアントに何らかの変更をプッシュしていますか?

于 2012-12-07T14:34:34.667 に答える