Path of Exile 攻略Wiki

"Desync" は非常にホットな話題だ。最良の時にはそれが起こった時は少し苛立つだけだが、最悪の時にはモンスターが周囲にいないと思われる状況でキャラクターが殺されることになる。我々はこの状況を大きく改善する多くの変更を行っているが、興味のある諸君のために、いかに我々の同期システムが機能しているか説明し、またゲーム状態の同期は全てのオンラインゲームが扱う必要のある問題であることを明らかにしたい。

この記事では私は以下の明確な説明を試みる：

• 異なるタイプのオンラインゲームがどうやってレイテンシを制御するのか
• 我々の行動予測がどのように機能しているのか
• なぜ同期問題がこのシステムで発生し、またどのようにそれらは現れるのか
• なぜ desync は存在しなければならず、またなぜ "ゴムバンド"（rubber-banding）が良いのか
• なぜいくつかの他のゲームは同様な問題を抱えていないように見えるのか
• 同期を改善するために我々は何を計画しているのか

どんなゲームも行動の結果を決定するために発生する計算を行っている。RPGでは、それらは戦闘計算（誰がどんなダメージを与えたか）からゲームアイテムを含む経済処理に及ぶ。プレイヤーのチートを防止するため、これらの計算はゲーマーのコンピュータでは行われない。なぜなら彼らはそのような計算の結果を簡単に変更できるからだ。

このため、誰かの進展に影響を与える全ての計算は、我々がコントロールするサーバ上で行われなければならない。これらのサーバは世界中（テキサス、アムステルダム、シンガポール、オーストラリア）に存在するが、光速度とその他の物理的な制限により、それらからデータを瞬時には送受信できない。我々は典型的には我々のプレイヤー達とサーバの間のレスポンス時間は50-250msだと見ている。

全てのオンラインゲームはこの状況にある。サーバは何かが起こったか起こらなかったか規定しなければならないが、データがサーバに届いて戻って来るのに50-250msの遅延がある。ゲームがこれを解決するには三つの方法がある：

• クライアントを信用する。これは人々がチートを使えることを意味するが、この結果は瞬時である。我々はこれは行わない。
• 何か を行う前にデータがサーバから戻って来るまで待つ。これはRTSやMOBAゲームにおける非常に一般的な戦略である。あなたが移動のためにクリックすると、ユニットはサーバがひとたびそのように命じた場合にのみ動きだし、これは0-250ms後である。もしあなたがサーバに近ければ、あなたはすぐにラグに馴れることができ、全てがとても良く感じられる。もしあなたが遠く（例えば、ニュージーランドまで）離れていれば、あなたは酔っぱらっているみたいに感じられる。あなたが命令を出す時はいつでも、1/4秒の間は何も起こらない。これはアクションRPGにとっては良く機能しない - その即時性と戦闘のペースは、即座に実行するために行動の開始を必要とする。
• サーバが即座にイエスと言っているかのように行動結果の予測を開始する。サーバがあなたに結果を持って戻って来た時、それを要素に分解する。これは Path of Exile を含むアクションRPGが行っていることである。これはあなたが移動や攻撃するためにクリックした時、それが即座に起こることを意味しており、素晴らしく感じられる。問題は行動を起こす事が出来なかったとサーバが決定した時に何が起こるか - これがゲームにひどい同期ずれが生じる時である。

アクションRPGで反応が良いと感じるためには３番目のシステム（行動予測）を使わなけらばならない。問題は、あなたが動き出す時、あなたは暗黙の内に定義上は非同期である事である。あなたのクライアントは移動の最初の数フレームを（良好で反応が良く）描画してしまったが、サーバはそのデータが到着するまであなたがボタンをクリックしたことをまだ知らない。行動予測はこのタイプのゲームにおいて必須であるが、ほとんど全ての時においてあなたはわずかに非同期になっているという結果になる。これは一般的には問題は無いが、正しくないデータに基づく予測が非常に多くなると、とても悪いことが起こる。挑戦はこれが起こる前に状況を検出して訂正することである。

あなたが200msの往復レイテンシでプレイしていて、あなたから2秒の移動距離にいるモンスターをクリックする場合を述べよう。あなたの攻撃アニメーションは300ms後に接触地点を持つと仮定する（これはダメージが与えられる地点である）。

0ms：あなたはモンスターをクリックする。あなたのキャラクターはクライアント上でそれに向かって走り出す。
100ms：あなたのクリックがサーバに到着する。そこにいるキャラクターもそのモンスターに向かって走り出す。この段階であなたのローカルのキャラクターは、既に(モンスターへの）道の5%の地点にいる。
2000ms：あなたのキャラクターはクライアント上でモンスターに到着する。サーバ上ではまだそこにいない。あなたはそれがちゃんと到着したかどうかさえ知らない（攻撃スキルによって妨害されたかもしれない）。あなたのクライアントは剣の振りのアニメーションを開始する：
2100ms：あなたのキャラクターはサーバ上でモンスターに到着する。サーバは接触地点に先立って即座に戦闘計算を実行し、クライアントに仮の結果を送信する。
2200ms：あなたはどんなタイプの、またおおよそいくらのダメージを与えるかについてサーバから通知を受信する。ありがたいことにアニメーションの接触地点の前にそれは到着した！　これはいつもこの通りとは限らない。
2300ms：あなたはクライアント上の接触地点にヒットする。あなたは先立ってダメージ情報を入手しているため、あなたは心地よい血しぶき、火のエフェクト、等々を描画できる。このヒットはまだサーバ上では発生していない。
2400ms：あなたはサーバ上で接触地点にヒットする。このダメージは格納されて実際にモンスターに適用される。それは死ぬ。経験値とアイテムが計算されてクライアントに送信される。
2500ms：あなたのクライアントは経験値のアップデートと、何のアイテムが地面に落ちているのが見えるかの情報を受信する。

あなたの情報が100ms遅延しているにもかかわらず、それは接触地点の前に到着し、クライアントが通知されたレイテンシ下でのプレイングの唯一の指示は、アイテムのドロップが到着するために十分の一秒かかるという事実だった。この処理ではプレイヤーにシステムをチートするのを可能にするような方法で妥協されたゲームプレイ計算はない。

上記の例は全てがスムーズに行われたことを仮定している。２秒の往復時間においては両端では完全に違ったものになりうる。またはラグスパイクによってタイミングは完全に同期がずれた状態になりうる。攻撃が開始される前（移動中）にサーバ上でそれが妨害されたがクライアント上ではそうでない場合、キャンセルできない長いアニメーションがプレイされるのをあなたは見ることになる。なぜなら通信時間はアニメーションの相当の長さにあたるである。

異常なラグが発生しなくても、近くのモンスター達はクライアント上であなたがいると考えられる場所への経路を探索している - これはレイテンシのため定義上はサーバ上でのものとは異なる。これらの存在は他のモンスターの周りで動く経路を見つける必要があり、これはもちろんそれぞれの側では微妙に異なった位置にいる。異なる経路はさらにモンスターが間違った場所にいる原因となる。

強調に値するのは、戦闘イベントの99%においては、全ては良好に感じられることである。シミュレーションがデータ通信の速度によって同期ずれはするものの、タイミングは一般的に算出され、異なる経路をたどるモンスター達はおおよそ正しい時間におおよそ正しい場所であなたに到達する。本当には何かが間違っている事を知るのは難しい…それがひどく間違っている場合を除いては。

不幸にも、同期が非常にずれている時、プレイヤー達はとても酷く感じることになる。彼らはどこからともなくダメージを受けたり、クライアント上の正しい場所に現れていないモンスター達の中に実際は捕われているのを見ることになる。我々にはこれらの状況を検出するためのコードがあり、上手く行けば存在するものを素早くその場所に resync（rubber-band、ゴムバンド）して戻すことができるが、しばしばそれは十分ではない。

理解するための鍵は、アクションRPGはこのような行動予測システムを使う必要があるということである。もしサーバから全ての行動の確認を待っていたらコントロールするのは酷く感じられる。

我々の resync（再同期）コードが完璧だったとしても、わずかなタイミングの違いによってゲームが同期ずれする状況は存在しうる。あなたが大きな岩の近くを走っていて、その反対側を任意にクリックした場合を想像して欲しい。クライアントとサーバの両側は岩の周囲の最短経路を見つけようとする。あなたのクライアントは定義上はサーバに先行しているため（反応が良くなるように、移動は近似的に50-250ms早く処理されるため）、クライアントがサーバと異なった岩の周囲の道を進むことを選択する場合が起こりうる。もしあなたが途中でモンスターにヒットされた場合、両者のシミュレーション上で異なる場所であなたの移動が妨害されることになる。あなたは同期ずれ状態になる。賢い resync コードはこれを検出し、岩を越えてあなたの意図される場所へと rubber-band（ゴムバンド）する。

ここでの鍵となる所見は、今の我々のものに比べて、改善された resync コードは更なる rubberbanding を含むということである。我々がそれを適切に行う場合、モンスターとプレイヤーは更に頻繁により良い位置に修正され、何かが不適当になるのを徹底的に防止する。多くのプレイヤー達は rubber-banding それ自体を "desync" と解釈しているが、ここで実際にはそれは問題が検出された際に修正しているのである。rubber-banding の割合の増加は良い事ばかりでないと説明するのは簡単ではないが、理想的な解決策でもある。

"サーバが応答するまで待つ" 方式を使用するゲーム（RTSやMOBAゲーム）はずっと高い入力レイテンシを持つが、我々と同じ同期問題は抱えていない。それらのゲームは我々が幸運にも扱う必要の無い、それら自身の分類のゲーム状態同期の問題を抱えている。

我々のようなクライアントの行動予測を使用するゲームは、シミュレーションの特定の見地においてごまかさない限り、我々と完全に同じ同期問題に陥ることになる。例えば、アクションRPGにとって以下の組み合わせが一般的である：

• 存在する物たちは遠距離から互いにヒットできる
• ヒットする確率が無い - 全てのヒットが確実に起こる
• 変更されたクライアントを使った速度改変やモンスター通り抜けを簡単にさせるような、様々な速度/衝突の譲歩
• 攻撃アニメーションの妨害（つまり我々が「スタン」として扱うもの）がありえない

不幸にも、我々はこれらのことを一つもやりたいと思わない！　それらはそれぞれ個別にハードコア体験を破滅させる：戦闘/移動のチートを許す、メカニズムとして（命中の）正確性が存在することを妨げる、スタンロックを妨害する、人がふさがれるのを妨害する、などなど。

我々はハードコアなゲームのメカニズム（つまり位置の問題やPvPにおいてチートするのが難しいこと）を持ちたいという事実により、我々にとって唯一の選択は我々の戦闘シミュレーションや resync コードを改善するために多くの作業を費やすということだった。

我々が試している、戦闘シミュレーションの同期を個別に改善しうる変更（それらのポテンシャル上の欠陥に沿ったもの）がたくさんある：

• エントロピーを減らすため、クライアント上のモンスターがクライアント上のあなたの位置でなくサーバ上の位置に攻撃する。二つの間の中間地点を攻撃するのはそれらの妥協になるだろう。ここでの欠陥は、それらは空中に（武器を）振っているが、技術的にそれらはより同期しているように見えることを意味していることである。
• 血と属性効果をダメージ確認せずにクライアント上の接触地点に表示する。これはおそらく戦闘がより衝撃的に感じられることを意味するするが、ダメージが実際に与えられたかどうかについてやりとりされる視覚的な情報を我々が失うことになる。spell（魔法）は一般的にヒット/ミスの計算を持たないため、それらからエフェクトを適用するのは容易になるだろう。
• クライアント上であなたの近くに何も無い時にあなたにヒットするのが成功した存在を resync する。これは実際にはあなた自身が間違った場所にいる場合に、その存在をより同期ずれさせる可能性がある。
• desync した存在の周辺のエリアにいる全てのものを resync する。これは全体的なエントロピーを大規模に減少させるが、とても不調和になるだろう。
• クライアントがその経路において先行している場合に行動を遅延させる。これは（もしあなたが同期ずれしていなければ）あなたがモンスターに辿り着く前にそれが死ぬ場合を解決するだろうが、技術的にはそれらの場合においてプレイヤーにとっての戦闘効率を低下させる結果になる。
• あるべき場所から遠く離れている物体に生じる、距離に基づく resync を改善する。現在、これは移動速度を適切に考慮していない。これは Rhoa（モンスター）が突進する時に非常に同期ずれしているように感じる理由である。
• プレイヤーに関する全体的なエントロピーを測定して、あるしきい値を越えた場合に強制的に resync する。問題は resync された情報がクライアントに到着するまで、より多くの行動が発生しうることである。
• クライアント上とサーバ上で異なる行動をさせる特定のスキルに関するバグを修正する（例えば Whirling Blades は時々、終端において距離に基づくトリガーに失敗する）。
• ここで明確に説明するにはあまりに微細な/難解なその他の変更

この段階において、物体があまりに desync している場合に戦闘状況を高速に信頼できる resync を行えるように、 resync コードを改善することによって最大の利益が得られるように見える。これはより多くの（先に説明した）rubber-banding を意味しているが、プレイヤーが存在の本当の位置を見ることができない事から生じる死を大規模に減少させるだろう。

私は上記の変更をそれらの欠陥と共に説明した。なぜなら私はこの問題を解決するのが本質的に困難なことを明快にしたいからである。我々は物理法則（データの伝送速度）とゲームプレイメカニズムを妥協しないという望みの両面に対して格闘している。私は我々がこの状況を大きく改善するますます多くの変更を適用するであろうことを完全に確信している。

新たな開発マニフェストにこの記事を載せるにあたって、私は上記の説明を改善する方法を見つけることができなかった - それは少しの小さな修正を除けば依然として非常に正確であり、私は殆どそのまま残したいと思う。

それが最初に投稿された時から挙がって来た、明らかにしたいいくつかの点がある：

• desync は我々のサーバへの負荷からは影響を受けない（上記の記事で説明されたように）。多くのサーバを購入することは問題を解決しない。我々は現在、十分なサーバを所持している。それらが過負荷になった時、戦闘予測に影響を与えるのではなく、新たなエリアを出現させるのに失敗する。
• プレイヤー達の中には行動の同期に関係していないものを頻繁に "desync" と呼んでいる人もいる。例えば、一般的なインターネット上のラグスパイクがある場合、またはクライアントが急いでアート資産をロードする必要がある場合（これはフレームレートの低下を引き起こす）、これはあるプレイヤーによってはしばしば "desync" と記述される。こうした他の問題は別の解決策を必要とする事柄である。誰かが "今日の自分とサーバの間のISPには酷いラグがある" という意味で、"今日の desync は本当に酷い" と言っているのを見るのは比較的いらいらする。
• 人々がレースにおいて同期がより悪いように感じる理由は、彼らが小さなドアや密集したモンスター達を通してキャラクターを本当に押し出しているからである。レースは同じサーバ上で行われ、リーグの修正が存在しない限り、同じゲームルールのもとでは通常のゲームである。
• 我々がRTS/MOBAゲームのような同期動作モデルに切り替えるという提案は本当に良い解決策ではない。私はRTS/MOBAが desync を持たないのは理解しているが、それらはそれぞれの全てのクリックの後にラグを持っている。あなたがあるユニットに命令しているという意味であるとき、このラグは理解できるが、*あなたが* そのユニットである場合、それは本当に酷く感じられる。今、我々のクライアント予測は、へんぴな国にいるユーザーが200ms以上のレイテンシのもとで Path of Exile をプレイするのを可能にしている。そのような別の動作モデルのもとではこれはずっと悪い体験になりうる。加えて、それはゲームの大部分の書き換えを必要とする。
• 様々なスキル（Whirling Blades、Cyclone、BrutusのHook、などなど）に関係する絶対的な問題があり、これはそれらを他のスキルよりもっと desync しがちにする。これらは積極的に調査されており、我々は間もなく共有できる良い進展を得られるだろう。
• 特定スキルの改善の他に、より賢い resync を生じることによる、これまでの問題への取り組みの試験的な変更。小さく頻繁に resync すること（これはゲームを過敏に感じさせるが同期は保たれる） vs 頻度を落として大きくテレポートさせること。ユーザーは resync を非同期と関連づけてきたため、従ってそれらをより頻繁にアップデートすると同期は良くなるどころか悪くなるように感じさせる。

体をブロックする、スタンやミスをする、一方でプレイヤーが戦闘の結果を操作することを防ぐといったハードコアなゲームメカニズムを維持するために、小さな量の desync は自然に発生する。光の速度があるため、これについての解決法は無い。Grinding Gear Games からの理想的な解決策は非常に高速にこれらの同期問題を検出して訂正し、物体をそれらがあるべき所に戻すことである。我々はまだこの解決策を我々の満足する所まで実行していない。しかしながら実行すれば、あなたは定期的な resync に気付くかもしれない、これは最初はあなたが常に同期ずれしているように感じただろう。これはシステムが完全に良好な状態を仮定し、あなたが壁に打ち付けられて二つ隣の部屋で進めなくなるよりも、システムがその事を認めて修正しているからである。

私はこの範囲において我々が進展を続けている間はこの記事をアップデートする予定だ。読んでくれてありがとう。あなたはあなたが望んでいたよりもネットワークゲーム状態同期の苦労について知る事ができたよ。