演出遅延の問題について

[Anemone-aura]

ちょっと横道に逸れるのですが、この件、いつかはお話ししようと思っていました。
この処理はサーバLagが原因ではなく、ご指摘の通りクライアントプログラムの「仕様」です。
「サーバからの応答を演出遅延させることなく、即時UIに反映していること」によるものです。

吉田も就任後に演出同期に変えるよう指示を出し、既に修正はパッチ1.17で行ってあります。
が、QAチームから「回復がし難くなった」「ストレスに感じる」という声が非常に多く、
かなり迷ったのですが、パッチには実装せず、現在も処理をマスクしてあります。

新生では新規演出と込みで、吉田の意図通りに実装しますが、
現行でも、なるべく早いタイミングで、実装した方が良いでしょうか？

この実装を行うことで「今のダイレクトな実装に比べ、むしろ遅延しているように感じる」ことになります。
なぜなら演出同期とは、サーバからの結果と演出を同期させるために、
UIなどの結果に対して、ウェイトを入れることに他ならないからです。
最初から同期されていれば問題なかったのですが、そうではなかったため、
パッチ1.17当時は、ストレスが増すことを考え、実装を見送り、依然マスクされています。

こちらもご意見ありましたら、お聞かせ頂けると嬉しく思います。
（必要なら別スレッドを立てた方が良いかもしれません）

と回答がありましたので、別スレッドを立ててみました。

詳しいことは分かりませんけど、サーバーにあわせるように見せると、かえって遅く感じるということですよね？

現状サーバーが遅いのはどうしようもない状態でメドも新生まで立たないようなら、今のままで我慢するしかないんでしょうか。

[NorL]

触ってみないと分からないかな？と思ったのだけど

QAチームから「回復がし難くなった」「ストレスに感じる」という声が非常に多く

これを見る限り「相当酷い」のは分かりますねｗ　（よしＰも実際少し触った上での判断かもだし）

現状は確かに残念な演出ですが
ストレスが多大にかかりそうなのであれば実装していただかなくて構いません。

というわけで「新生待ち」に１票です。

[Thiro]

ちょっと横道に逸れるのですが、この件、いつかはお話ししようと思っていました。
この処理はサーバLagが原因ではなく、ご指摘の通りクライアントプログラムの「仕様」です。
「サーバからの応答を演出遅延させることなく、即時UIに反映していること」によるものです。

吉田も就任後に演出同期に変えるよう指示を出し、既に修正はパッチ1.17で行ってあります。
が、QAチームから「回復がし難くなった」「ストレスに感じる」という声が非常に多く、
かなり迷ったのですが、パッチには実装せず、現在も処理をマスクしてあります。

新生では新規演出と込みで、吉田の意図通りに実装しますが、
現行でも、なるべく早いタイミングで、実装した方が良いでしょうか？

この実装を行うことで「今のダイレクトな実装に比べ、むしろ遅延しているように感じる」ことになります。
なぜなら演出同期とは、サーバからの結果と演出を同期させるために、
UIなどの結果に対して、ウェイトを入れることに他ならないからです。
最初から同期されていれば問題なかったのですが、そうではなかったため、
パッチ1.17当時は、ストレスが増すことを考え、実装を見送り、依然マスクされています。

こちらもご意見ありましたら、お聞かせ頂けると嬉しく思います。
（必要なら別スレッドを立てた方が良いかもしれません）

私としては、「むしろやるなら今のうちですよ」という意見ですね。
可能であれば事前に比較動画を出していただけるとさらに判断がしやすいかと思います。

[sakyu]

サーバーが遅いと言う訳ではなく、例えばシュトルムヴィントのようにぐるぐる回して最後にどかーんと行くようなスキルの場合HPが減るのがどかーんと行ったタイミングに合わせると言う事だと思います。
これにより例えば敵が死んだのに未だに桜花を撃っている、もしくは敵が派手派手な攻撃をしてきて自分が死んだのにエフェクトだけ続いているといった事が無くなり、桜花のような多段攻撃は一発エフェクトで当たる度にダメージポップアップして気持ちいいといったようなメリットがあると思います。
代わりにWSを撃ってから敵のHPが減るまでにタイムラグが発生するとか、敵のエフェクト付き攻撃の後のエフェクト無し攻撃が間髪入れずに入って一気に減ってしまうといった問題が発生するかと。
また、止めの一撃を放ってゲージが減るまでの間、無駄に攻撃できてしまう等も起こると思います。

違ったらすいません…。

[Dlacroix]

現状⇒サーバーから来る情報を順次表示しているので、その順番どおりに画面で表示(WS実行後、敵のHPが減ってからモーションが表示されてログが出る等)
演出同期を行う⇒サーバーからきた情報を一度クライアントで止めて、全部揃ったら同時に表示する
という事でしょうか？
自分も技術的な事は分かりませんが、今の重いクライアントでそういう芸当をするのはよろしくないのではないかと思います。

QAチームから「回復がし難くなった」「ストレスに感じる」という声が非常に多く

との事ですし、無理に実装する必要はないかなと･･･

[shimon]

＞「回復がし難くなった」「ストレスに感じる」
＞敵のエフェクト付き攻撃の後のエフェクト無し攻撃が間髪入れずに入って一気に減ってしまうといった問題が発生する

描写の違和感がなくなる代わりに操作にストレス伴うなら、新生してから直してもらった方がよさそうです。

[Kristina_Farron]

と回答がありましたので、別スレッドを立ててみました。
詳しいことは分かりませんけど、サーバーにあわせるように見せると、かえって遅く感じるということですよね？
現状サーバーが遅いのはどうしようもない状態でメドも新生まで立たないようなら、今のままで我慢するしかないんでしょうか。

大体あってるね。
オンゲの設計における最大の課題の一つは「ネットワークのラグを如何にうまくごまかせる」と言えるだと思います。

例えばひとつのWSが：
1. ユーザーがボタンを押す (場合によってクライアントより攻撃判定及びダメージ算出するかも)
2. その信号がサーバーに伝わる (ネット具合によって20ms~300msの時間がかかります)
3. サーバーの演算 (ダメージ計算がクライアントでやればここで承認する、そうじゃない場合ここでダメージを算出する)
4. 演算結果がクライアントに伝わる (また20~300msの時間がかかる)
5. クライアントで演出する。
6. もしかしすると演出完了もサーバーに知らせる必要がある。(同期のため)

以上は大体の原則です、必ずしもFF14の実際状況と一致することはない。
問題の件は多分、1の時点既に攻撃判定及びダメージが算出して、HPゲージなどUIに反応したのに、演出は5の時点で行われるため、数十~数百ミリセカンドのズレが生じているではないかと思います。

敢えて同期しようとしてると、UI反応の時期がステップ5に移り、ユーザーはボタン押してから結果を見るまで最悪の場合数百msに待たされることになる。

仮にイフBCでこういう状態で操作させると、アビ、魔法、WSのレスポンスが悪くなって、「ボタンを連打したくなる」のは普通の反応だよね。
でも後衛にとって「魔法のボタンを2度押すとキャンセルになる」から、この場合ケアル3一発も打てない間に盾さん殺される可能性が非常に高い。

だからこの状態を解消するため「移動による詠唱中断」に変えたいというなら理解できます。

[Kristina_Farron]

私としては、「むしろやるなら今のうちですよ」という意見ですね。
可能であれば事前に比較動画を出していただけるとさらに判断がしやすいかと思います。

いやいやいや、普通は現行サーバーと別にテストサーバーを立ち上がってテストするだろう。

[Hieroglyph]

詳しいことは分かりませんけど、サーバーにあわせるように見せると、かえって遅く感じるということですよね？

逆です、逆。

サーバーの応答は現在でも早い。
（HPが減るなどのデータ的処理が先行することがその証明）

それに対して、クライアントプログラムが遅いため、
「HPが減ってから、攻撃を食らってダウンする演出が画面に出る」
ということが起こっています。

早い方にあわせることは難しいため、（遅い方を早くするのは、
「それが簡単に出来れば苦労しないよ」レベルの労力がかかります）
「クライアント側の演出」にあわせて、「サーバー側の応答＝結果を
クライアントに反映するタイミングを遅らせる」形で、演出と結果を
同期させる、というのが、マスクされている仕様の正体です。

さて、その上で私個人の見解を述べますと――

今のままでいいですよｗ
マスクしたままなのは大正解だわｗ

「新生」では、期待してます。

[Thiro]

いやいやいや、普通は現行サーバーと別にテストサーバーを立ち上がってテストするだろう。

仰るとおりだと思います。

ですが、現状テストサーバがない状態ですから、課金が開始される前に実装してみるのもひとつの手かなと思ってます。それが不安であれば、先にも書きましたが比較動画をだしていただいて、それを判断材料にして是非を決めれば安心かな？といったところでしょうか。