選択肢ウィンドウの表示速度を変えて欲しい

[coca]

選択肢ウィンドウ(箱や？？？を調べた時にでる選択肢ウィンドウ)の表示速度が遅いので、速度が変えれるのであれば早くして欲しいです。

調べてから表示されるまでの間、開く時のアニメーションがどうにも遅くて急いでいる時はイライラします。
表示される時の間はラグの問題もあると思います。もしも、意図的に時間を設けている場合は無くてもよいのではないかと思います。

コレに加えて、カーソルの初期位置がキャンセルの選択肢であることが多いので、ウィンドウが遅いタイミングで開く→キャンセルを押す→消える→調べるの繰り返しでストレスです。
カーソルの初期位置がキャンセルの選択肢なのは間違いが無い様にするにはいいことなのですが・・・。

特に、ゲームが重いときにボタン連打してたら上記の繰り返しに陥ってしまうことが多いです。重いと動作が遅くなるのは分かるんですが、サクサクと動いてくないものでしょうか・・・。

ボタン連打するのが悪い、言われればそうなんですが、そうさせているＵＩの速度の方も改善できるのであれば検討して欲しいです。

素人目では、調べた時の間の短縮、ウィンドウが開く時のアニメーションの時間の短縮あるいは削除ができたらもう少し早くなるのかなーと思っていたり。

別件で蛇足にもならないけれど、エリアチェンジした直後に鞄を見ると何も表示されない時間もストレスです。仕組みは違うと思うので要望に入れませんが以前に比べて表示されるまでの時間が長くなっているように感じます。またＬＳリストもそうです。
もう一つこれは話題が変わってしまうのですが、強化魔法を受けているときの硬直時間は無くてもいいのではないでしょうか・・・。例を挙げるとヘイストなのですが、これは意図的に硬直時間を設けていたとどこかで聞いた気もするのですが、理由までは覚えていません。タイミングによっては迷惑な時もありせっかくの支援なのにもったいないなと思います。(殴りかかろうとした瞬間にヘイストがきて硬直するなど)
といった感じで、「間」や「意図的な硬直」、「ラグ」もよりスムーズになるような調整も出来るのであればやって欲しいなあと思います。
有効な支援が掛かっている時ほど時間を無駄にしたくないのでこういったところの時間の浪費も少なくして欲しいなと思いました。

追記：自分はＰＣでプレイしています。ＰＳ２に関しては分かりません。

[Vorpal_Bunny]

ウィンドウが出るときの「内側から外側に開く」エフェクトをカットしてスパッとウィンドウが出るようにして欲しいですねー。

無くすと通信ラグでウィンドウが開いて一瞬間を置いてからからテキストが表示されるようになったりするのかな～。

[coca]

そうですそうです、内側から外側へと大きくなるエフェクト、動きが遅いと暫く反応がなくて、あれ？押したかな？まだったかな？と思って連打してしまうこともあります。
スパッとすぐに調べたと分かるようになって欲しいといいますか、とりあえず、「調べたよ」って情報が受理されているか否かもすぐ分かるといいですね。

人の多いところだと、調べても調べたことになってなくて2度目を調べたりってのもしょっちゅうです。
例でいうと、混雑している真界だと、ＢＣに入るためのクリスタルも、結構それが発生します。
すぐ入れるようにクリスタルをタゲっているのに無効になったり。あわててもう一度調べＢＣに入ります。たまに入ったつもりになって入ってないときもあります。画面切り替わらないなーと思って無効になってることに気づいてあわててもう一度調べたり。
報酬のGlimmering Troveを調べた時も同様です。

こういったこともボタン連打する原因かな、とふと思いました。

[Neumesser]

確かに、以前に比べると操作が呑まれることが随分増えましたよね
パッチで「機器の入れ替え」ってのがある度にレスポンスが下がってきたように感じます
今って結構ギリギリになってるんじゃないでしょうか、何とか頑張ってほしい部分なんですが

[Mocchi]

こんにちは。

ご意見ありがとうございます。
開発環境上で、メニューの開閉アニメーションを無くすテストを始めてみました。

QA検証が進み、進捗を報告できる段階になりましたらまたお知らせします。

[Dacco]

これは期待！（*＾＾*）

ま、万一オフにしたら却って操作しにくくなったら戻すだけだから。

[coca]

わあ、ありがたし！ありがたし！

どんな具合になるのか、よくなるといいなあ。

[Rito]

私も同様のことで非常に悩んでました
これが改善されると結構ストレスなくなりそうですね
スレ主はいいとこに目がつきますねぇ

[eland]

マクロパレット表示ウェイト修正のときのような想定外の不具合がでませんように　（－人－）

[kakiagesoba]

調べてから表示されるまでの間、開く時のアニメーションがどうにも遅くて

個人的な見解を横から・・・。
アニメーションはそのものは十分に速いと思います確かにもうちょっと速くてもいいかも。

開発環境上で、メニューの開閉アニメーションを無くすテストを始めてみました。

アニメーションを無くしてみたところで効果は微小で
本質的な解決にならないと推測します。（細かいことは折り畳み。）

「とりあえず手っ取り早くできそうなとこに手を入れました！」
とゆーポーズ的・場当たり的な対応になることを危惧します。

■ cocaさんの入力の連打キャンセルが発生するまでのシーケンス（妄想）

「★」マークが付いているところがユーザから見て待ちが発生している部分。

----------------
CL　　宝箱や各種ターゲット(???)等を選択
CL　◇キー/ボタン入力制限開始
CL　　サーバ側に選択情報を送信
　↓
　↓
　↓
★　SV　　クライアント側から届いたデータを処理
★　SV　　　　+-- インスタンス用サーバに問い合わせ
★　SV　　　　+-- 関連ＤＢサーバに問い合わせ
★　SV　　同期とかの排他とかの整合性処理
★　SV　　　　+-- PTメンバー全員にステータス確認
　↓
CL　★サーバ側からの応答を受信
CL　★サーバ側にステータスを送信
　↓
★　SV　　サーバ側のステータスを更新・クライアント側に応答を返せる状態になる
★　SV　　クライアント側に応答（正常レスポンス開始）を返す
★　SV　　クライアント側に応答（中身～Endまで）を返す
　↓
　↓
　↓
CL　◎ユーザはイライラしながらボタン連打中
CL　★サーバ側からの応答を受信

CL　　ダイアログの最終サイズを確定・アニメーション位置を計算
CL　　▽ ダイアログが開くアニメーション開始～
CL　★表示する内容の構築開始（HDDからデータのロードを開始）
CL　　　 ダイアログが開くアニメーション～途中まで～（数フレーム）
CL　★表示する内容の構築を内部的に完了（デフォルト位置はキャンセル）
CL　　△ ダイアログが開くアニメーション～完了（数フレーム）

CL　◇キー/ボタン入力制限解除
CL　◎ユーザがボタン連打していた入力が反映される
CL　　（本来なら：展開したダイアログ上に表示内容を配置開始）
CL　　（本来なら：ダイアログにサーバ側からの応答 - テキスト - を表示完了）
CL　　（本来なら：ダイアログにサーバ側からの応答 - 画像 - を表示完了）
CL　◎操作はキャンセルされました^^
----------------


実際の処理はまた違うとは思いますがが大筋はこんなもんかなと思います。
この流れの中で、ダイアログの表示アニメーションに費やしている時間は
ほんの僅かなものです。

アニメーションそのものの時間の短さは処理負荷の軽い場所で
メインメニューの表示とかを試してみればすぐにわかる事。
# ボワンとした感じのアニメーションなのでせっかちな人には
# 「膨らみすぎなとことかもっと削れるだろ！」とゆー印象を与えるかな・・・。

でも実際これを削ってみたところで数フレーム分の削減にしかなりません。
（仮に10フレーム削るとすると166ミリ秒程度の削減。）

調べてから表示されるまでの間

この問題で対処すべき箇所はたぶんここ↑。
表面的な問題点はサーバ側からの応答の遅さにあって、それに対して開発側ですべきことは次の２点です。

　　・応答までのボトルネックとなっている箇所の検出
　　・上記原因への対処。

　※補足
　　開発側ではこんなこと言うまでも無く理解している事と思われます。


でも本当はそうじゃないと思う。

「調べたよ」って情報が受理されているか否かもすぐ分かるといいですね。

これ↑がこのスレッドの問題の本質（その１）なんじゃないのかなと。
スレッドのタイトルはウィンドウの表示に言及してますがそうじゃなくて。
（ついでにこのコメントからは解決方法への糸口も見えてきます。）

本当の問題点は、

　　・ユーザはサーバ側からの応答をただひたすら待つしかない。

という状況/仕組み。
改善策として、例えば

　　・ＢＣとかに入るために問い合わせをした際に下記の統計情報が
　　　一次情報としてすぐに返却される。
　　　　　　- 現在のインスタンスの使用状況　　15/15 (Full)
　　　　　　- インスタンス内の戦闘の平均所要時間　　26分
　　　　　　- 直近10分間の入室数の実績　　2PT/10分
　　　　　　- 直近10分間の入室リクエストの受付数　　1206回/10分
　　　　　　- このフィールドにいる（＝入室待ちと思われる）パーティー数　　24PT

としたらユーザ側はその場で続けて待つことにするか
それとも他のコンテンツに移動して
時間を有効に使うかどうかの判断ができます。
（これを境にユーザの待ちの責任の所在がシステム側からユーザ側に移ります。）

同時にこれは「調べたらちゃんと応答したよ」という
フィードバックにもなります。

この一次情報の提供の後で「入室しますか？」とゆー選択ダイアログが
表示される流れにすれば「それでも入室する」ユーザは
待ち時間がかかる事も承知の上で臨む格好になり、
いきなり一方的に待たされる状況からは解放されます。

　＊　＊　＊

このフォーラムでのやり取りにも散見されることですが、
ユーザは結果も大事ですが（結果が得られないのなら）進捗を知りたいと
思うものです。

結果が出るまで応答しないのではなく定期的に何らかの応答を
返すことでユーザには処理が継続されているという安心感を
与えることができます。

また上記の例のような一次情報を提供することができれば
ユーザ側の意思でその次の行動を決めることができるので
現状よくある

　「ただ一方的に理不尽に待たされ、著しく不満が募る」
　（※一般社会では仕事を切られる直接的な原因になり得る事です。）

という状況が相当に軽減されることが期待できます。

　＊　＊　＊

ウィンドウが遅いタイミングで開く→キャンセルを押す→消える

ここ↑も問題の本質（その２）。
ユーザがイライラしてボタン連打をしてしまうのは止めようがない事なので
システム側でできる事は次の１点しかないと思います。

　　・「これからダイアログが開きますよ」ということを事前に通知する。

ユーザにそろそろ通信が完了してダイアログが開きそうな事に気付いてもらう。
それをもって、ユーザに自発的にボタン連打を止めてもらうことを期待する。

　　具体的に言うとダイアログを開く前に「(正弦波)ピピッ！」みたいな
　　小さな画面演出を入れて、一瞬の間を置いてダイアログを開く。
　　但しこれは必ず出すんじゃなくてサーバ側への送信完了から
　　3秒以上経過していた場合に限定、といった対応を入れる。


　　# クライアント側での入力制限状態（キー/ボタン入力情報の破棄と受付）の
　　# 管理方法で何とかしようとすると多分新たな問題を発生させることに
　　# なるような気がします・・・。






※以下は蛇足

（誰も気にしていないと思いますが）FF11の各種ウィンドウ類の
表示・非表示アニメーションは相当練りこまれていると思います。
何も考えない人が設計すると単純にフェードイン・フェードアウトに
してしまいかねないところをわざわざ手の込んだ折り畳み方式にして
プログラム的にも作りこんだ上で組み込んでいます。

フェードイン・フェードアウト方式との比較：

　　フェードイン・フェードアウト方式：
　　　・アニメーションはもっさり感をもたらす
　　　・表示時、ウィンドウの背面は全体的に認識できなくなる
　　　・非表示時、背面の認識ができるまでにやや時間がかかる

　　折り畳み方式：
　　　・アニメーションにスピード感・躍動感がある
　　　・展開時、背景の鮮明な画像がギリギリまで見えている
　　　・収縮時、背景の鮮明な画像をイチ早く見れる

旧TV画面（4：3比）でウィンドウ類がプレイ画面を埋め尽くしてしまう状況での弊害を極力軽減しようとか、
通信時の遅延を演出面でできるだけ違和感無く吸収しようとか、
プレイ時に軽快な感じとか躍動感とかをもたらそうといった意図を感じます。

（誉めすぎ？）