LS/FC/フレンドは別にネームプレートの色を設定できるようにして欲しい

[lucia]

LSメンバーは128名、FCメンバーにいたっては最大512名です。
ネーププレートへの着色ということになれば、全PCがこれらの情報にアクセスすることになるわけですから、
どう軽減処理を実装しようと、通信負荷についてはそれなりに増えると判断せざるをえないでしょう。
簡単に実装するには通信量が多すぎるし、
通信を軽減しようとすればかなり難しいサーバクライアント処理の実装が必要に思えます。

後は、それだけの開発負荷・通信負荷に見合うゲーム性向上の価値があるかどうかですが‥‥。
正直この要望に関しては「ちょっと便利」を超えるものとは思えません。
すぐに実現に取り掛かってもらえるような話ではないように見えます。

[maytora]

（ポスト内容前略）
確認したわけではありませんが、FCタグだけなら被り名称もおそらく可能？
であれば、FCタグ=文字列だけでの判定は不可能ですね。

FCタグの重複はこちらで確認済みなので、可能みたいです。
具体例を載せたいところなのですが、特定FCの名前を２つも出すのは流石にマズいと思うので、
例を申し上げますと、２つの単語をつなげた名前を、イニシャルにしたものをタグにするケース……
例えば、いま考えた架空のFC名で
Absolute kneesocks　と、　Anpanch Kick　で　<<A.K>>　という風に、被りやすいみたいです。

このようなイニシャル系のFCタグを見かけましたら、
複数のキャラでカンパニープロフィールを覗いてみると、たまに違うFC名が出てくると思うので、
ぜひ試してみてください

[SaariaWynes]

単に見分ける為だけなら根性版の様にネームの前にエンブレムを付けるとかでもいいような気がしますが。
あと、込み合っている場所では11の様に表示する対象ごとに優先順位を設定できるようにすれば特に何も追加しなくていいのでは？

[Nonohana]

ここまでは正しいと思いますが、
ここは誤りだと思います。

今現在ローカルに無い情報→取得しなければならない→通信量の増大→トラフィックの再計画が最大の問題なのであって今あるAPIが流用できるかどうかとかはどうでもいい話です。
アプローチ方法すら限定する部類ではありません、皆川さんのおっしゃってるのは一つのアプローチ方法ですし、貴方が提案している方法と比べてもメリットデメリットがきちんとあります。
私の小さな脳みそだとちょっと皆川さん案は皆川さん案で実装可能なのか疑問ですけど、実現できるならきわめてクライアント側の処理がシンプルになります。それは大きなメリットです。

通常のアプリケーションみたいにリッチにオブジェクト同士が互いの状態を通知しあい、必要な範囲で再描画等を行う単純なアプリケーションなら貴方のおっしゃる方法でも不可能は全然無いでしょう。
しかし、FF14はゲームです。

「～だけでできるはずです。」と断言していますが、何が貴方に、私たちにわかるのでしょう。
私には「FC/LS更新通知がロスト」する可能性だけでまずその断言は覆るように見えます。
ずっとプレイヤーがログインしていられる、ということは100%通知をロストしないようにするか、もしくはリフレッシュを計画しなければなりません。リフレッシュを設ける場合には、同接数ｘリフレッシュ頻度ｘ通信量ぐらいはトラフィック量を上乗せしなければなりません。これが安易な考えでないといえますか？

それに十分複雑な変更をただ名前の色を変更するというだけのことに要求しているように思います。
適当に否定するのはやめていただきたいです、あまり見ていて気持ちよくありません。

[Heme]

各キャラクターのサーバからの通信情報の中に、
「同じFCやLSメンバーと判断するための情報」が含まれていないため、
現時点では色を変えるべきキャラクターをクライアント側だけの情報で特定できていません。

以下略

ジェネラルディスカッションで【キャラクター名の表示設定について】のスレッドを立てた者ですが、無理って事ですよね？残念orz


私個人としては、LS・FC・フレ・PTメンバー以外のプレイヤー名は見えなくて良いのです、何故なら通りすがりの他人の名前なんて興味も無いですし画面がぐちゃぐちゃに成るだけです。
本来ならリアルと同じで相手の容姿（個性の出せる装備でも可能）や声などで判別できればベストなのですが、ゲームでそれを期待するのはもっと無理だと思うので、何とかうまい具合に低負荷処理で出来るようになる事を切に願います。

[naruse]

今現在ローカルに無い情報→取得しなければならない→通信量の増大→トラフィックの再計画が最大の問題なのであって今あるAPIが流用できるかどうかとかはどうでもいい話です。

それは「マップ上のキャラクターの通信情報」に限った話ですよね。

アプローチ方法すら限定する部類ではありません、皆川さんのおっしゃってるのは一つのアプローチ方法ですし、貴方が提案している方法と比べてもメリットデメリットがきちんとあります。

皆川さん案の方がクライアントの処理は楽でしょうね。
サーバー側はマップ上の人数の二乗のサイズのテーブルを常時持っておかないといけない気はしますが。

「～だけでできるはずです。」と断言していますが、何が貴方に、私たちにわかるのでしょう。
私には「FC/LS更新通知がロスト」する可能性だけでまずその断言は覆るように見えます。

必要なものが揃っていて、それで何をすればいいのかわかれば、十分わかるでしょう。
ハッシュテーブルの操作はCPUやメモリが常識的な環境ならばその速度は予想可能で、
メモリサイズが常識的でないPS3での懸念は既に述べたとおりです。
また、FC/LS更新通知が届かない主なケースはエリアチェンジ時(?)、ログイン直後、IDからの復帰時です。
平常時のロストは通常通信にTCPを用いていると思われるFF14では自動的に再送されるはずなので、考えなくてもよいでしょう。

それに十分複雑な変更をただ名前の色を変更するというだけのことに要求しているように思います。
適当に否定するのはやめていただきたいです、あまり見ていて気持ちよくありません。

サーバー側の変更＋マップ上の各キャラクター情報へのデータ追加という極めて高いハードルから、
クライアント側への変更という相対的にかなり低いハードルに落としていますし、
適当と言われるのは心外で、外からの観察と基本的な知識から推測可能なことを述べているつもりです。

まぁ、確かにマップ上の「各キャラクターの通信情報の中」の方にはFC/LS情報が入っていないのはその通りだろうので、
そこをもって誤りだと言ったわたしの発言が微妙なのは仰る通りかも。

[Heme]

私はプログラムに関してはズブの素人なので解らないのですが、単純にログインした時にFC・LS・Friend・BLをローカルに情報を保存して、そのリストから名前を照合って形にした場合（同一サーバー内では名前の重複は無いのですよね？）クライアントがそんなに重くなってしまうのですかね？

やっぱり重くなっちゃうのかな？？私はそんなに登録してないけど、FCによってはカナリの量の人がいるでしょうしね＾＾；

[RocketMonster]

LSメンバーは128名、FCメンバーにいたっては最大512名です。
ネーププレートへの着色ということになれば、全PCがこれらの情報にアクセスすることになるわけですから、
どう軽減処理を実装しようと、通信負荷についてはそれなりに増えると判断せざるをえないでしょう。

リアルタイムにやろうとすればそうでしょうが、
LS/FCメンバーリスト自体はログイン時に一回、または現状のように任意のタイミングで取得した情報をローカルに
保存しておいて、その情報にもとづいた色変えすれば、実用上何の問題もないと思います。

LSやFCメンバー名をローカルで保存しては流出した時に危険という話もあるようですが、ロードストーンで
一般に公開されている情報ですので特にどうという事はないかと。

[Hiroshi_Minagawa]

クライアントがそんなに重くなってしまうのですかね？

FCが512人、LinkShellが８つで各128人の1024人、合計1536名のメンバーリストと、
現在表示している画面上(PS3は30体)のキャラクターの比較処理を行うことになりますから、
UIの他の処理と比較すると、決して軽くはない処理です。

※画面上30PCの場合で、46080回の比較処理です。
　XIVはMMOなので、毎画面描画ごとに比較対象が変わる「可能性」があるため
　比較処理の頻度を落として負荷軽減するといった事はできません。
　処理回数に関しては、FCメンバーだけ、FCとカレントLSメンバーだけ、といったように、
　ある程度対象を絞り込んで減らせます。

この機能の実装が原因で「目に見えてゲームが遅くなる」事は無いでしょう。

ですが、UI系の機能は「塵も積もれば山となる」の塊で、
この先に必要になる追加機能のためのマージンを残しておかないと、
先々のコンテンツ追加時に全く余力が残っていない、となる危険性があります。

表示対応は技術的には不可能ではありませんが、
他の作業に先立って今すぐやるべき優先度では無い、と判断しています。

[naruse]

FCが512人、LinkShellが８つで各128人の1024人、合計1536名のメンバーリストと、
現在表示している画面上(PS3は30体)のキャラクターの比較処理を行うことになりますから、
UIの他の処理と比較すると、決して軽くはない処理です。

単純比較を46080回だと0.05ミリ秒から0.1ミリ秒くらいだと思うのですが、
ハッシュテーブルからの取り出しにすれば演算回数は30回ですむので、一桁くらい早くなりそうな気がします。
「他の作業に先立って今すぐやるべき優先度では無い」は仰るとおりですので、追加ディスクのさらに先でいいと思いますが。