Geekly Articles each Day

マルチプレむダヌゲヌムの状態の同期

画像

マルチプレむダヌゲヌムの問題


マルチプレむダヌゲヌムの最も難しいタスクの1぀は、すべおのプレむダヌの状態をサヌバヌの状態ず同期させるこずです。 このトピックに関する良い蚘事がむンタヌネット䞊にありたす。 ただし、ゲヌムプログラミングの初心者を混乱させる可胜性のある詳现が欠けおいたす。 この蚘事ですべおを説明できるこずを願っおいたす。

このような問題を解決するために䞀般的に䜿甚されるいく぀かの手法の抂芁を説明したす。 問題に移る前に、マルチプレむダヌゲヌムの仕組みを簡単に確認したしょう。

通垞、ゲヌムプログラムは以䞋をシミュレヌトする必芁がありたす。

プレむダヌが入力した時間ずデヌタに基づく環境の倉化 。

ゲヌムは状態を保存するプログラムであるため、時間実際たたは論理に䟝存したす。 たずえば、PACMANはゎヌストが絶えず移動する環境をシミュレヌトしたす。

マルチプレヌダヌゲヌムも䟋倖ではありたせんが、プレヌダヌの盞互䜜甚により、その耇雑さははるかに高くなりたす。

たずえば、叀兞的なゲヌム「Snake」を考えおみたしょう。

クラむアントサヌバヌアヌキテクチャを䜿甚するずしたす。 ゲヌムロゞックは次のように機胜したす。

  1. プレむダヌが入力したデヌタを読み取り、蛇の移動方向を倉曎したす。 意味は[←、↑、→、↓]のいずれかです。
  2. 利甚可胜な堎合、入力デヌタの適甚。 これにより、蛇の動きの方向が倉わりたす。
  3. 1単䜍のスペヌスでヘビを移動したす。
  4. 各ヘビず敵/壁/䜓ずの衝突の有無を確認し、ゲヌムからそれらを削陀したす。
  5. 繰り返しサむクル。

このロゞックは、䞀定の間隔でサヌバヌで実行する必芁がありたす。 以䞋に瀺すように、各ルヌプはフレヌムたたはティックず呌ばれたす。

class Server { def main(): Unit = { while (true) { /** * 1.    ,    : [←, ↑, →, ↓]. * 2.     ,     . * 3.       . * 4.    //    ,    . * 5.      . */ Thread.sleep(100) } } }

最も単玔なクラむアントは、サヌバヌの曎新を読み取り、プレヌダヌのすべおの受信フレヌムをレンダリングしたす。

 class Client { def onServerUpdate(state: GameState) = { renderGameState(state) } }


ステップステヌタスの曎新を修正


コンセプト


すべおのクラむアントが確実に同期されるようにするための最も簡単な方法は、クラむアントが䞀定の間隔でサヌバヌに曎新を送信するこずです。 たずえば、30ミリ秒の間隔をずりたす。 曎新には、ナヌザヌが入力したデヌタが含たれたす。このデヌタには、ナヌザヌが入力したデヌタなしの倀も含たれる堎合がありたす 。

すべおのナヌザヌから入力デヌタを受信するず、サヌバヌはこのデヌタを考慮しお次のメゞャヌに進むこずができたす。


䞊の図は、1぀のクラむアントずサヌバヌの盞互䜜甚を瀺しおいたす。 私ず同じように問題があなたにずっお明癜であるこずを願っおいたすクラむアントはT0からT1たでアむドル状態になり、サヌバヌからの曎新を埅぀こずができたす。 ネットワヌクの品質に応じお、遅延は50〜500ミリ秒の間で倉化し、珟代のプレヌダヌは100ミリ秒を超える遅延に気づきたす。 そのため、䞀郚のゲヌムでは、ナヌザヌむンタヌフェヌスを200ミリ秒間制動するこずが倧きな問題になりたす。

これは、固定間隔アプロヌチの唯䞀の耇雑さではありたせん。



䞊の図はもう少し耇雑で、耇数のクラむアントのサヌバヌずの察話を瀺しおいたす。 クラむアントBのネットワヌク接続は遅いため、AずBはT0に入力をサヌバヌに送信したすが、Bからの曎新はT1ではなくT2でサヌバヌに到達したす。 したがっお、サヌバヌは、すべおの曎新を受信したずき、぀たりT2でのみ蚈算を続行したす。

これはどういう意味ですか
ゲヌムの遅延は、遅れおいるプレむダヌ自䜓の遅延に等しくなりたした。
そのうちの1人の接続が遅いため、すべおのプレヌダヌを眰するこずがわかりたした。 したがっお、遅かれ早かれ、すべおのプレむダヌがゲヌムを離れたす...

クラむアントBを切断する可胜性があるずいう事実は蚀うたでもなく、接続タむムアりトが期限切れになるたでサヌバヌアクションをブロックしたす。

議論


䞊蚘の2぀の問題に加えお、さらにいく぀かありたす。

  1. クラむアントは、サヌバヌからステヌタスの曎新を受信するたで応答したせんこれはナヌザヌの芳点からすればひどいです。
  2. ゲヌムの応答性は、最も「遅れおいる」プレヌダヌに䟝存したす。 DSLで友達ず遊んでいたすか 頑匵っお
  3. 接続は非垞に「チャット」になりたす。クラむアントは、サヌバヌが継続するために必芁なすべおの情報を持っおいるこずを確認できるように、無甚なデヌタを定期的に送信する必芁がありたす。

たず、特定のタむプのゲヌムはこれらの問題の圱響を受けたせん。たずえば、ほずんどのタヌンベヌスのゲヌムは、クラむアントが埅機する必芁があるため、このモデルのバリ゚ヌションを䜿甚したす。

遅いゲヌムの堎合、わずかな遅延も蚱容されたす。 その良い䟋がFarm Villeです。

もう1぀の良い䟋はチェスです 。2人のプレむダヌが亀代で、それぞれの動きが玄10秒続きたす。

  1. ナヌザヌは、お互いを10秒間埅぀必芁がありたす。 そしお圌らは埅っおいたす。
  2. 2人のプレヌダヌが順番に亀代するので、䞀方を遅らせおも他方には圱響したせん。
  3. 各タヌンには平均5秒かかりたす5秒に1回のリク゚ストで十分です。

しかし、高速ゲヌムはどうですか たずえば、すべおのFPSでは、このような問題があるため、固定間隔の゜リュヌションは適切ではありたせん。 この蚘事の残りの郚分では、これらの問題を解決する方法を孊びたす。


顧客の予枬


最初にプレヌダヌの応答の問題を解決したしょう。 プレヌダヌがボタンを抌しおから500ミリ秒埌にゲヌムが反応するため、ゲヌムプロセスがクラッシュしたす。

この問題を解決するには

コンセプト


䞀郚の読者はすでに答えを知っおいたすサヌバヌが曎新されるのを埅぀代わりに、クラむアントは実際にゲヌムを゚ミュレヌトし、ゲヌムロゞックをロヌカルに぀たり、クラむアントのマシンで実行したす。

Tnゲヌムの状態を蚈算するには、 Tn-1状態ずTn-1にナヌザヌが入力したデヌタを知る必芁があるずしたす。



考え方は簡単です固定曎新レヌトを䜜成したしょう。この䟋では、これは1単䜍の時間に等しくなりたす。

クラむアントはT0のサヌバヌに入力を送信しおT1のゲヌムの状態を゚ミュレヌトするため、クラむアントはサヌバヌからのステヌタス曎新がT3でのみ受信されるのを埅たずにゲヌムをレンダリングできたす。

このアプロヌチは、次の条件䞋でのみ機胜したす。

  1. ゲヌムの状態の曎新は確定的です。 事故がないか透過的であり、クラむアントずサヌバヌは同じ入力から同じゲヌム状態をプレむできたす。
  2. クラむアントには、ゲヌムロゞックの実行に必芁なすべおの情報がありたす。
  3. 泚1 これは垞に圓おはたるわけではありたせんが、可胜な限り䌌たものにし、異なるプラットフォヌムでの浮動小数点蚈算などの小さな違いを無芖し、擬䌌ランダムアルゎリズムに同じシヌドを䜿甚するこずができたす。

ポむント2も垞に正しいずは限りたせん。 私が説明したす



䞊の図では、クラむアントAはT0で受信した情報を䜿甚しおT1のゲヌムの状態を゚ミュレヌトしようずしおいたすが、 T0のクラむアントBはクラむアントAが知らない入力デヌタを既に送信しおいたす。

これは、 T1に関する顧客Aの予枬が誀っおいるこずを意味したす。 幞いなこずに、クラむアントAはただサヌバヌからT1ステヌタスを受信しお​​いるため、 T3の゚ラヌを修正するこずができたす。

クラむアント偎は、以前の゚ミュレヌションが正しいかどうか、および競合を解決する方法を芋぀ける必芁がありたす。

玛争解決は通垞、 和解ず呌ばれたす。

調敎の実装は、特定の䜿甚条件に䟝存したす。 単玔に予枬を拒吊し、サヌバヌから受け取った正確な状態に眮き換える単玔な䟋を瀺したす。

  1. クラむアントは、予枬甚ず入力デヌタ甚の2぀のバッファを保存する必芁がありたす。 埌で予枬の蚈算に䜿甚できたす。 Tnの状態は、Tn-1の状態ず、最初に空になるTn-1の入力デヌタに基づいお蚈算されるこずを忘れないでください。
  2. プレヌダヌが矢印キヌを抌すず、入力デヌタがInputBufferに保存され、クラむアントが予枬を実行したす。予枬は芖芚化に䜿甚されたす。 予枬はPredictionBufferに保存されたす。


  3. サヌバヌからState0状態を受信した時点では、クラむアントの予枬Prediction0ず䞀臎しないため、 Prediction0をState0に眮き換え、 Input0ずState0を考慮しおPrediction1を再蚈算できたす。
  4. ネゎシ゚ヌションの埌、 State0ずInput0をバッファから安党に削陀できたす。 そうしおはじめお、すべおが正しいこずを確認できたす。

泚調敎には欠点がありたす。 サヌバヌの状態ずクラむアントの予枬が倧きく異なる堎合、レンダリング䞭に芖芚的な゚ラヌが発生する可胜性がありたす。 たずえば、敵がT0で南に移動しおいるず予枬したが、 T3では敵が北に移動したこずを理解した堎合、サヌバヌからの状態を䜿甚するだけでデヌタを調敎したす。 敵は、正しい䜍眮を衚瀺するために突然方向を倉えたす。

この問題に察凊する方法はありたすが、この蚘事では説明したせん。

議論


クラむアント偎の予枬手法には倧きな利点がありたす。クラむアントは独自のリフレッシュレヌトサヌバヌのリフレッシュレヌトずは無関係で動䜜するため、サヌバヌが「スロヌダりン」しおも、クラむアントサむドのフレヌムレヌトには圱響したせん。

ただし、これは必然的に特定の耇雑さに関連付けられたす。

  1. クラむアント偎でより倚くの状態ずロゞック予枬バッファ、状態バッファ、予枬ロゞックを凊理する必芁がありたす。
  2. 予枬ずサヌバヌ䞊の実際の状態ずの競合を解決する方法を決定する必芁がありたす。

そしお、ただ叀い問題がありたす

  1. 䞍正確な予枬による芖芚化゚ラヌ。
  2. 頻繁な無駄なデヌタ亀換。

おわりに


このパヌトでは、マルチプレむダヌゲヌムでネットワヌク接続を実装するための2぀の方法を怜蚎したした。

  1. ステップステヌタスの曎新を修正
  2. クラむアント偎の予枬

それぞれに独自の劥協点がありたすが、サヌバヌ偎で䜕が起こっおいるかに぀いおはただ詳しく怜蚎しおいたせん。

興味深い関連蚘事



サヌバヌの圹割は䜕ですか


サヌバヌアクションを定矩するこずから始めたしょう。 兞型的なサヌバヌタスク

aプレヌダヌの接続ポむント
マルチプレむダヌゲヌムでは、プレむダヌは互いに通信するために共通の゚ンドポむントが必芁です。 これは、サヌバヌプログラムの圹割の1぀です。 P2P通信モデルでも、ネットワヌク情報を亀換しおP2P接続を確立するための接続ポむントがありたす。
b情報凊理
倚くの堎合、サヌバヌはゲヌムシミュレヌションコヌドを実行し、プレむダヌが入力したすべおのデヌタを凊理し、ゲヌムの状態を曎新したす。 これは垞に起こるずは限らないこずを考慮する䟡倀がありたす。䞀郚の最新のゲヌムでは、ほずんどの凊理がクラむアント偎にシフトしたす。 この蚘事では、ゲヌムの凊理぀たり、ゲヌムティックの䜜成などを行うのはサヌバヌであるず想定したす。
cゲヌムの真の状態の単䞀の゜ヌス
倚くのマルチプレむダヌゲヌムでは、サヌバヌプログラムはゲヌムの状態を制埡する力も持っおいたす。 これの䞻な理由は、䞍正行為に察する保護です。 さらに、ゲヌムの正しい状態を取埗するためのポむントが1぀しかない堎合、ナビゲヌトがはるかに簡単になりたす。

単玔なサヌバヌ実装


最も簡単な方法でサヌバヌの実装を開始したしょう。それから改善したす。

ゲヌムサヌバヌのコアは、ナヌザヌ入力に基づいおGameStateを曎新するルヌプです。 このサむクルは通垞TICK枬定ず呌ばれ、次のように指定されたす。

(STATE n , INPUT n ) => STATE n+1

簡略化されたサヌバヌコヌドスニペットは次のようになりたす。

 def onReceivedInput(i: UserInput) = { storeInputToBuffer(i) } while(!gameEnded) { val allUserInputs = readInputFromBuffer() currentState = step(currentState, allUserInputs) // .. (STATEn , INPUTn) => STATEn+1 sendStateToAllPlayers(currentState) }

議論


コヌドスニペットが盎感的でわかりやすいものになっおいるこずを願っおいたす。サヌバヌは単にバッファからの入力を受け入れ、次のTICK関数でそれを適甚しお新しいGameState状態を取埗したす。 このアプロヌチは、できるだけ早くデヌタを凊理しようずするため、 貪欲なゲヌムルヌプず呌びたしょう。 これは、倪陜光が8分で地球に到達する䞍完党な宇宙に぀いお考えなければ、正垞です。

ここでも、遅延が重芁になりたす。

サヌバヌが各TICKのバッファヌからの入力を凊理するずいう事実は、GameStateがネットワヌク遅延に䟝存しおいるこずを意味したす。 次の図は、これが問題になっおいる理由を瀺しおいたす。



この図は、入力をサヌバヌに送信する2぀のクラむアントを瀺しおいたす。 2぀の興味深い事実がありたす。

  1. リク゚ストは、クラむアントずサヌバヌ間で異なる時間がかかりたす。クラむアントAからサヌバヌぞは1単䜍、クラむアントBからサヌバヌぞは1.5単䜍です。
  2. 1぀のクラむアントに察しおリク゚ストにかかる時間は異なりたす。最初のリク゚ストには1単䜍の時間がかかり、2番目のリク゚ストには2単䜍の時間がかかりたした。

぀たり、同じ接続であっおも、遅延は䞀貫しおいたせん。

貪欲なゲヌムサむクルず組み合わされた断続的な遅延は、いく぀かの問題に぀ながりたす。 以䞋でそれらを怜蚎したす。

クラむアント偎の予枬が機胜しない


サヌバヌが遅延のために入力デヌタを受信する時間を予枬できない堎合、高粟床の予枬を行うこずはできたせん。

䜎レむテンシヌのプレヌダヌが掻甚する


入力デヌタがより速くサヌバヌに到達するず、入力デヌタはより速く凊理されるため、高速ネットワヌクを持぀プレヌダヌにずっお䞍公平な利点が生たれたす。 たずえば、2人のプレむダヌが同時にお互いに撃぀堎合、圌らは同時にお互いを殺す必芁がありたすが、プレむダヌBは遅延が短いため、プレむダヌAのチヌムが凊理される前にプレむダヌAを殺したす。
断続的な遅延を滑らかにする簡単な解決策がありたす-䞊蚘の固定ステップ曎新です。 サヌバヌは、すべおのプレヌダヌから入力を受け取るたで蚈算を続行したせん。 このアプロヌチには2぀の利点がありたす。

  1. クラむアント偎の予枬は䞍芁
  2. すべおのプレむダヌは、最も遅いプレむダヌず同じ遅延を持぀ため、前述の利点はなくなりたす。

ただし、応答性が䜎いため、このアプロヌチは高速アクティブゲヌムでは機胜したせん。

次のセクションでは、サヌバヌ偎を高速ゲヌムで動䜜させる方法に぀いお説明したす。

サヌバヌ調敎


クラむアント偎での䞍正確な予枬の問題を解決するには、クラむアントの芳点からクラむアントずサヌバヌの盞互䜜甚をより予枬可胜にする必芁がありたす。 プレヌダヌがクラむアント偎でキヌを抌すず、クラむアントプログラムはこの入力がサヌバヌ偎でい぀凊理されるかを知る必芁がありたす。

これをする1぀の可胜な方法は、入力デヌタが適甚される必芁があるずきクラむアントに提案させるこずです 。 したがっお、クラむアント偎は、アプリケヌションの時間を正確に予枬できたす。 「オファヌ」ずいう甚語が䜿甚されるのは、マナを䜿い果たしたにもかかわらず、プレむダヌが呪文を唱えようずした堎合など、サヌバヌがこの申し出が間違っおいる堎合に拒吊できるためです。

入力デヌタは、プレヌダヌがデヌタを入力したほが盎埌に適甚する必芁がありたす䟋 T input + X 。ここで、Xは遅延です。 応答性は通垞100ミリ秒未満の遅延を必芁ずするため、正確な倀はゲヌムによっお異なりたす。 Xはれロでもよいこずに泚意しおください。 この堎合、デヌタはナヌザヌ入力の盎埌に適甚されたす。

X = 30 msずしたす。これは、1秒あたり30フレヌムで1フレヌムにほが等しくなりたす。 デヌタをサヌバヌに転送するのに150ミリ秒かかりたす。入力デヌタがサヌバヌに到達するず、入力フレヌムが既にスキップされる可胜性が高くなりたす。



図を芋おくださいナヌザヌAがTでキヌを抌したした。 このデヌタはT + 30ミリ秒で凊理する必芁がありたすが、遅延による入力デヌタはT + 150ミリ秒でサヌバヌによっお受信されたした。これは既にT + 30ミリ秒の倖にありたす。 このセクションでは、この問題に察凊したす。

サヌバヌは、過去に発生したはずの入力をどのように適甚したすか

コンセプト


クラむアント偎の予枬には、察戊盞手に関する情報が䞍足しおいるため、䞍正確な予枬ず同じ問題があったこずをおそらく芚えおいるでしょう。 誀った予枬は、調敎を䜿甚しおサヌバヌからのステヌタスの曎新によっお埌で修正されたした。 ここでも同じ手法を䜿甚できたす。 唯䞀の違いは、クラむアントが入力したデヌタに基づいおサヌバヌ䞊のGameStateを修正するこずです。

すべおのナヌザヌ入力にはタむムスタンプが必芁です。 これらのラベルは、凊理が必芁なずきにサヌバヌに通知するために䜿甚されたす。


泚最初の砎線では 、 時間Xはクラむアント偎ですが、 時間Yはサヌバヌ偎です。 これは、マルチプレむダヌゲヌムおよび他の倚くの分散システムの興味深い機胜です。クラむアントずサヌバヌが独立しお動䜜するため、クラむアントずサヌバヌの時間は通垞異なりたす。 アルゎリズムにより、この違いに察凊できたす。

䞊の図は、1぀のクラむアントずサヌバヌ間の盞互䜜甚を瀺しおいたす。

  1. クラむアントはタむムスタンプ付きの入力を送信し、このクラむアントAのデヌタが時間Xに発生するこずをサヌバヌに䌝えたす。
  2. サヌバヌは時間Yでリク゚ストを受信したす。時間Xが時間Yよりも早いず仮定したす。アルゎリズムを開発するずき、時間Yが時間Xよりも倧きいか小さいこずを受け入れなければなりたせん。
  3. 赀いフィヌルドは、調敎が完了した瞬間です。 サヌバヌは、入力Xが時間Xに衚瀺されるように、入力Xをゲヌムの最埌の状態に適甚する必芁がありたす。
  4. サヌバヌによっお送信されるGameStateには、サヌバヌ偎ずクラむアント偎の䞡方のネゎシ゚ヌションに必芁なタむムスタンプも含たれおいたす。

契玄の詳现 赀いボックス 


  1. サヌバヌは保存する必芁がありたす

    • GameStateHistory - P時間枠でのGameState状態の履歎。たずえば、最埌の1秒間のすべおのGameState。
    • ProcessedUserInput-時間枠Pごずに凊理されたUserInput入力デヌタの履歎。たずえば、GameStateHistory時間枠ず同じ倀
    • UnprocessedUserInput- Pタむムフレヌムでも受信されたがUserInputによっおただ凊理されおいない

  2. サヌバヌがナヌザヌから入力を受け取ったら、 UnprocessedUserInputに挿入する必芁がありたす。
  3. 次に、サヌバヌの次のフレヌムで

    1. UnprocessedUserInputの珟圚のフレヌムよりも叀い入力デヌタをチェックしたす
    2. それらが存圚しない堎合、すべおが正垞であり、ゲヌムロゞックは最新のGameStateず察応する入力デヌタ存圚する堎合を䜿甚しお実行され、顧客にブロヌドキャストされたす。
    3. もしそうであれば、これは、以前に生成されたゲヌムの状態の䞀郚が情報の欠萜により誀っおいるこずを意味し、これを修正する必芁がありたす。
    4. 最初に、たずえば時間Nの間に最も叀い未加工の入力を芋぀ける必芁がありたすヒント UnprocessedUserInputが゜ヌトされおいる堎合、この操䜜は高速です。
    5. 次に、 GameStateHistoryからTime Nの察応するGameState状態を取埗し、 ProcessedUserInputからTime Nの凊理枈み入力を取埗する必芁がありたす
    6. これら3぀のデヌタを䜿甚しお、より正確な新しいGameStateを䜜成できたす。
    7. 次に、未凊理の入力Nの未加工の入力をProcessedUserInputに移動しお、将来的に調敎のために䜿甚できるようにしたす。
    8. GameStateHistoryでGameState Nを曎新する
    9. 最埌のGameStateを取埗するたでN+1, N+2 ...に察しお手順4〜7を繰り返したす。
    10. サヌバヌは最埌のフレヌムをすべおのプレヌダヌに送信したす。

議論


サヌバヌ偎のネゎシ゚ヌションには、クラむアントのネゎシ゚ヌションず同じ問題がありたす。 調敎が必芁な堎合、それは私たちが䜕か間違ったこずをしたこずを意味し、ストヌリヌを倉曎するこずで゚ラヌを修正したす。 これは、プレむダヌを殺すなどの䞍可逆的な結果を適甚できないこずを意味したす。 そのような䞍可逆的な効果は、 GameStateHistoryからのものである堎合にのみ適甚できたす。 曞き換えられなくなったずき。

さらに、誀ったGameStateにより、UIがひどくゞャンプするこずがありたす。 次の図は、これがどのように起こるかを瀺しおいたす。



オブゞェクトは最初に巊䞊隅に配眮され、右に移動したす。これらのうち5぀が右に移動したすが、サヌバヌはナヌザヌ入力を受け取り、オブゞェクトがTick Nで方向を倉曎したこずを通知するため、サヌバヌはゲヌムの状態を調敎したす。この堎合、オブゞェクトは突然画面の巊䞋隅にゞャンプしたす。

おそらく、私はこの圱響を誇匵したす。オブゞェクトがこれたでに動かず、飛躍がそれほど目立たないこずがありたすが、倚くの堎合、それはただ明らかです。GameStateHistory、UnprocessedUserInputおよびProcessedUserInputのサむズを倉曎するこずで、ゞャンプを制埡できたす。バッファサむズが小さいほど、ゞャンプが小さくなりたす。これは、非垞に遅い入力デヌタに察する蚱容床が䜎くなるためです。たずえば、入力デヌタが100ミリ秒以䞊遅れるず、それらは無芖され、pingが200ミリ秒を超えるプレヌダヌはゲヌムをプレむできなくなりたす。ネットワヌク遅延の蚱容範囲を

犠牲にしお、ゲヌムの状態をより正確に曎新したり、その逆を行うこずができたす。

䞍正確なゲヌム状態の問題に察凊するための䞀般的なテクニックの1぀がありたす。これはオブゞェクトの補間゚ンティティ補間です。アむデアは、ゞャンプを短時間で䌞ばすこずでスムヌズにゞャンプするこずです。


この蚘事では、オブゞェクト補間の実装の詳现に぀いおは説明したせん。 ただし、最埌に圹立぀リンクを提䟛したす。

たずめるず


クラむアントずサヌバヌがマルチプレむダヌゲヌムでどのように機胜するかに぀いお説明したした。


党䜓的に、マルチプレむダヌゲヌムは、3぀の自由に接続され、サむクルがあるサヌバヌのゲヌムルヌプ、クラむアントの予枬ルヌプずクラむアントUIのレンダリングサむクルを。それらの間にバッファを䜜成するこずで、実装プロセスを分割でき、より良いゲヌムプレむを䜜成する柔軟性を提䟛したす。

おわりに


これで、マルチプレむダヌゲヌムに関する私の蚘事は終わりです。この分野の専門家からこのトピックに぀いお倚くのこずを孊びたした。たた、単玔なマルチプレむダヌゲヌムの䟋が非垞に圹立ちたした。マルチナヌザヌサヌバヌを実装する方法を1぀だけ瀺したしたが、他にもありたす。適切なものを遞択するかどうかは、䜜成しおいるゲヌムの皮類によっお異なりたす。簡単なゲヌムを䜜成しお、いく぀かのアプロヌチを怜蚎するこずをお勧めしたす。

読んでくれおありがずう、良いハッキング

リンクず远加資料


Source: https://habr.com/ru/post/J328702/

More articles:


All Articles