と回答がありましたので、別スレッドを立ててみました。
詳しいことは分かりませんけど、サーバーにあわせるように見せると、かえって遅く感じるということですよね?
現状サーバーが遅いのはどうしようもない状態でメドも新生まで立たないようなら、今のままで我慢するしかないんでしょうか。
Printable View
触ってみないと分からないかな?と思ったのだけど
これを見る限り「相当酷い」のは分かりますねw (よしPも実際少し触った上での判断かもだし)Quote:
QAチームから「回復がし難くなった」「ストレスに感じる」という声が非常に多く
現状は確かに残念な演出ですが
ストレスが多大にかかりそうなのであれば実装していただかなくて構いません。
というわけで「新生待ち」に1票です。
サーバーが遅いと言う訳ではなく、例えばシュトルムヴィントのようにぐるぐる回して最後にどかーんと行くようなスキルの場合HPが減るのがどかーんと行ったタイミングに合わせると言う事だと思います。
これにより例えば敵が死んだのに未だに桜花を撃っている、もしくは敵が派手派手な攻撃をしてきて自分が死んだのにエフェクトだけ続いているといった事が無くなり、桜花のような多段攻撃は一発エフェクトで当たる度にダメージポップアップして気持ちいいといったようなメリットがあると思います。
代わりにWSを撃ってから敵のHPが減るまでにタイムラグが発生するとか、敵のエフェクト付き攻撃の後のエフェクト無し攻撃が間髪入れずに入って一気に減ってしまうといった問題が発生するかと。
また、止めの一撃を放ってゲージが減るまでの間、無駄に攻撃できてしまう等も起こると思います。
違ったらすいません…。
>「回復がし難くなった」「ストレスに感じる」
>敵のエフェクト付き攻撃の後のエフェクト無し攻撃が間髪入れずに入って一気に減ってしまうといった問題が発生する
描写の違和感がなくなる代わりに操作にストレス伴うなら、新生してから直してもらった方がよさそうです。
大体あってるね。
オンゲの設計における最大の課題の一つは「ネットワークのラグを如何にうまくごまかせる」と言えるだと思います。
例えばひとつのWSが:
1. ユーザーがボタンを押す (場合によってクライアントより攻撃判定及びダメージ算出するかも)
2. その信号がサーバーに伝わる (ネット具合によって20ms~300msの時間がかかります)
3. サーバーの演算 (ダメージ計算がクライアントでやればここで承認する、そうじゃない場合ここでダメージを算出する)
4. 演算結果がクライアントに伝わる (また20~300msの時間がかかる)
5. クライアントで演出する。
6. もしかしすると演出完了もサーバーに知らせる必要がある。(同期のため)
以上は大体の原則です、必ずしもFF14の実際状況と一致することはない。
問題の件は多分、1の時点既に攻撃判定及びダメージが算出して、HPゲージなどUIに反応したのに、演出は5の時点で行われるため、数十~数百ミリセカンドのズレが生じているではないかと思います。
敢えて同期しようとしてると、UI反応の時期がステップ5に移り、ユーザーはボタン押してから結果を見るまで最悪の場合数百msに待たされることになる。
仮にイフBCでこういう状態で操作させると、アビ、魔法、WSのレスポンスが悪くなって、「ボタンを連打したくなる」のは普通の反応だよね。
でも後衛にとって「魔法のボタンを2度押すとキャンセルになる」から、この場合ケアル3一発も打てない間に盾さん殺される可能性が非常に高い。
だからこの状態を解消するため「移動による詠唱中断」に変えたいというなら理解できます。
逆です、逆。
サーバーの応答は現在でも早い。
(HPが減るなどのデータ的処理が先行することがその証明)
それに対して、クライアントプログラムが遅いため、
「HPが減ってから、攻撃を食らってダウンする演出が画面に出る」
ということが起こっています。
早い方にあわせることは難しいため、(遅い方を早くするのは、
「それが簡単に出来れば苦労しないよ」レベルの労力がかかります)
「クライアント側の演出」にあわせて、「サーバー側の応答=結果を
クライアントに反映するタイミングを遅らせる」形で、演出と結果を
同期させる、というのが、マスクされている仕様の正体です。
さて、その上で私個人の見解を述べますと――
今のままでいいですよw
マスクしたままなのは大正解だわw
「新生」では、期待してます。