■サーバーの負荷問題の解決の見通しはついているのですか？

[vbsnbk]

私もそんな前提です。
ただ過去に「データ量減らせばいいんじゃない？」的なコメントをしたら全否定されました。
実際はどうなんでしょうね。
まあ、様々な要因があるからこそ、簡単には解決できないんでしょうが。

全否定と取られてしまったのでしたらごめんなさい。
データ量を上手く減らせばその分処理しなければいけないサーバ負荷も減りますので、無関係である
とまでは言えないのですが、現在の通信量（Windows上で実際に測定出来るフリーのツールがありますので
興味があれば探してみると良いと思います）を測定した限りでは、ラグい時もそうではない時も、通信量そのものは
そう大きく変動がなかったりします。ウルダハやBWといった比較的PC/NPCが多いエリアでも余り人の居ない
エリアでもそうなので、通信に掛かる時間的コストは恐らくラグの根本的な原因ではないかな、と判断されるわけですね。
もし通信コストが原因の場合ですが、
１：一人ひとりのユーザの回線をFF14の通信が圧迫する場合
　観察される通信量はラグが酷くなるに従って急増するかと思われます。
２：接続するユーザが増えてサーバ回線の帯域を使い尽くす場合
　限られた帯域を多人数のユーザーで分け合うので、一人あたりの通信量は少なくなります。これが酷くなると
通信途絶、回線落ちになりますが、クライアント側の負荷でも落ちることはあるでしょうから、回線落ちイコール
サーバー帯域の問題と判断するのは早計かと思われます。

このいずれの事象も起きていないようなので、今のところは通信量が大きな原因だとは考えにくいかと
思われます。もっともこの通信量の測定をしたのは4月の中頃なので、今測定したら違う傾向なのかもしれませんが。

この辺きちんと開発サイドで解説するか、雑誌やゲームポータル系のサイトのインタビューで扱ってくれたりすると
嬉しいんですけどね。まだ「どう対処すれば劇的に改善されるか」までは突き止められてないから、公にアナウンス
する段階ではないんでしょうね。

[ponkotu]

良きプログラマは良き数学者になれと言われるほど、計算式をシンプルに、かつ構造的に優れたものにしなければ軽くはなりません。
つまり、回りくどい計算をして処理をかける事をいかに減らすかと言うことが重要なのです。

なので今回の問題は、単純労働のように時間と予算を入れ込めば何とかなるものではなく、アイデアと頭脳の勝負なのです。
皆さんイライラしてると思いますが、事はそう簡単にはいかない問題で劇的に改善するのはありえないと思っていてください。
出来るのならとっくの昔にやっています。

[puripuri]

そこ直すのなら本来はソフト回収して鯖停止なんですけどね(´・ω・｀)
ユーザーがイライラしているのは早さではなく、何故「やるべきことをやらないのか」という
必要な手を打たないことへの憤懣だと思います。

私はそこ直すならとっとと小売りからソフト回収してサービス停止、しかる後にプログラム全面改修して
この煩わしい問題を完全に治してから１年先でも２年先でも面白くなったFF14やりたいです(´・ω・｀)

これは開発にいう事ではなく、その上……というか一番上の人に何度も何度も執拗に叩きつけたい憤懣ですけどね。
あー名前だしたいｗｗｗｗｗ

[Gingerbread]

妄想の域ですがPC版を先に出したものの、将来的に発売予定であるPS3版の制限(GPUやメインメモリ容量等)が足かせになっているかもしれませんね。
UIの設計(次のページなど)は随所にそれを意識させる箇所が見受けられます。要はPS3版では一度に通信できるデータ量が限られるため変なUIになってしまっている＋通信回数が多くなるので負荷が高いのではと。
設計段階での問題なのでこれを修正するのは根本的なところに手を入れる必要があるが、現状でサービスが動いてしまっているため大々的には変更不可と言ったところでしょうか。

[puripuri]

PS3ちゃんもネットワークマシンとしてはメインメモリ少ない子ではあると思いますが、
問題はこのゲームPS3のサービス前提だったくせになんでサービス前に許容メモリ量使い切るような設計にしてんだよ
この考えなし開発が馬鹿たれ！ってことですよね(´・ω・｀)

[Zhar]

そこ直すのなら本来はソフト回収して鯖停止なんですけどね(´・ω・｀)

勘違いしておられますが、ソフト回収も鯖停止も必要ありませんよ。というかする意味が無い。
クライアント側はアップデートで更新できますし、サーバ側はメンテ期間中のみ止めれば良いのでね。

ユーザーがイライラしているのは早さではなく、何故「やるべきことをやらないのか」という
必要な手を打たないことへの憤懣だと思います。

手は打ってますって。吉田体制になる以前から、通信関連については細かく改修されてます。
店売りの速度がマシになったりしたでしょ？（まだ遅いですが）アレとかその最たる例
FOXさんも書いてるじゃないですか。長期的なスパンになると。
私もそう思いますし、むしろ焦って変なものを作りこんでほしくないな。

もっとぶっちゃけて言うと、無能な人間に担当させないでほしい。

これは開発にいう事ではなく、その上……というか一番上の人に何度も何度も執拗に叩きつけたい憤懣ですけどね。
あー名前だしたいｗｗｗｗｗ

みんな知ってるから大丈夫ｗｗｗ
そーゆー根幹部分まで外注に「回さざるを得なかった」（これは田中Dの海外インタビュー回答から容易に想像がつく）
点からして、開発じゃなくてマネジメントの失敗。マネジメントといえば最高責任者は・・・？ですねｗ

[SAMITO]

以前のインタビューを見るとPS3版は専用テクスチャを使うようです

サーバー負荷問題の目処が立たない今、ユーザーPC環境に限って言えばCPUの要求スペックが低い
必要動作環境のCPU基準Intel® Core™2 Duo（2.0GHz）のリアルタイム使用量を計測すると処理が追いついていません
推奨動作環境のCPU基準Intel® Core™ i7 2.66GHz以上だと処理に余裕があります
GPUは、画質調整で負荷処理を補えますが、CPUは調整できません。このことから、CPU必要動作環境の低基準が足かせになっているかもしれません。

[Thend]

ＰＳ２のゲームで「デッドオアアライブ２」って格闘ゲームがありました。

発売前に「発売日までに間に合うのか？」と噂されましたが、ちゃんと発売されました。
ＰＣで容量を確認すると５ＧＢ以上あり「こんなに容量が凄いのか」と驚いたものです。

暫くして「デッドオアアライブ２ ハードコア」と言う使用キャラやコスチュームが増えて発売されました。
ＰＣで容量を確認すると２ＧＢちょっとしかない。ゲーム要素は増えているのにデータ量は減っている。

どれだけ無駄なものをスマートに削れるかはスクエニの技量次第。

FF14をやっているとFF11の時よりサーバーへの同期が多く、同期の返答も遅い気がします。
その上、チートを懸念しているのかクライアント処理が少ない気がします。もう少し、切り分けをすれば軽くなるんじゃないかなあ。


もっとも「ＦＦ１４ラグってるぞっ！」と文句を言いながら、ベンチマークで４５００以下の人やＡＤＳＬの人ももいるでしょうけど。他のゲームなら文句言う前に自分のＰＣスペックをコピペしろって言われるだよね。

[feifong]

データ量を上手く減らせばその分処理しなければいけないサーバ負荷も減りますので、無関係である
とまでは言えないのですが、現在の通信量（Windows上で実際に測定出来るフリーのツールがありますので
興味があれば探してみると良いと思います）を測定した限りでは、ラグい時もそうではない時も、通信量そのものは
そう大きく変動がなかったりします。ウルダハやBWといった比較的PC/NPCが多いエリアでも余り人の居ない
エリアでもそうなので、通信に掛かる時間的コストは恐らくラグの根本的な原因ではないかな、と判断されるわけですね。
もし通信コストが原因の場合ですが、
１：一人ひとりのユーザの回線をFF14の通信が圧迫する場合
　観察される通信量はラグが酷くなるに従って急増するかと思われます。
２：接続するユーザが増えてサーバ回線の帯域を使い尽くす場合
　限られた帯域を多人数のユーザーで分け合うので、一人あたりの通信量は少なくなります。これが酷くなると
通信途絶、回線落ちになりますが、クライアント側の負荷でも落ちることはあるでしょうから、回線落ちイコール
サーバー帯域の問題と判断するのは早計かと思われます。

興味を惹いたので、レスが滞って久しいスレッドに投稿させて頂きます。

回線に流れるデータ量を測定していません。　ラグは、端末に届く通信データ量じゃなくレスポンス速度ですよ。
単に端末で観測できるデータ量が少ないからサーバ関係ないってのは間違い。
あるアクションに対して、レスポンスがどの程度の時間で戻ってくるかです。
サーバがヒートアップしてくると、逆に端末に届くデータ量は、単位時間に対して減る傾向がでます。

あるピッチャーが１人います。　その人はボールを４０００個持っています。　そしてキャッチャーは４０００人いました。
ピッチャーが１秒間に１００回ボールを投げれた場合、順繰りにキャッチャーへボールを投げたら１０秒間に１個づつ投げられますよね。
ピッチャーは０秒でキャッチャーからの返球を受け取れたとしましょう。　この場合は、レスポンスタイム（ラグ）が１０秒以上という事になります。

さて、じゃあピッチャーは何で１００個しかボールを投げられないのか？
原因は色々と考えられると思います。
0. システム性能がソフトウェアが要求する性能を満たしていない（スラッシングやオーバヘッド：流石になさそう）
1. サーバのハードウェアスペックとソフトウェア効率（計算と変数へのコミットが追いついていない）
2. 通信データ量が肥大して、サーバからの送信が追いつかない（計算は完了しているけれど、レスポンスが返せない）
3. 故意に送信を規制している（何らかの輻輳予防が働いている）
4. 泣きそうな見落としがある（ゲームサーバ以外がゲームサーバを邪魔している。ルーティング輻輳、中途半端なハードウェア故障）

ゲームをプレイした感触でいえば、元々通信データのペイロードを潤沢に大きく設計し過ぎている感触を持ちました。
加えて、送信データの取捨選択がなされていない。　視界範囲やミニマップに見える範囲の動的データを無条件で垂れ流している気がします。
過去に当たったパッチに「ミニマップ上の光点が異常な動きをする」不具合があったと記憶しています。
これって取捨選択を入れたらクライアントが思わぬ動きをしたのかと推測しました。
11だと遠くのPC/NPCはレーダーに映りません。　遠隔サーチでも座標とID(=NPC名)位です。

14だと1キャラクタを表現する為に必要な情報が増えてます。　装備部位、LSチャンネル、キャラクタの造形パタン、HP/MPパラメータなど多彩です。　他にも殆ど変化しないデータ（店の商品リスト、リーヴ種類）も通信データに乗せている様子があります。
ログイン直後のラグが酷い点を観ると、描画データのロードにも時間が掛かっている様子があります。　ここはエリアをシームレスにした副作用かもしれません。（ラグの割にグラフィックボードのファンの回転数が上がらない）
あと周りに人が多い、天候が悪化するとファンの回転数が上昇する。（ファンの人数が増えるとグラフィックボードのファンも嬉しくて高回転する？）
クライアントのスペックが足りていないのが悪いという問題じゃないですがね。　描画の精細さを荒い設定にしても、やっぱり重いですから。　５年後の性能向上を基本値に定めるのは方針かもしれませんが、性能不足な現状でも満足に動かせる設定を用意していない点は設計が甘い。

フレッツNext回線を基本とし、グラフィック性能は1000京ポリゴン/msecと定めて設計して、ついてこれないのはユーザが悪い、性能要求を満たすハードウェアがない世界が悪いので切り捨てます。　妥協案はありません。

これは仕様不良ではないと言い張れても、設計不良とは言えないかと。

じゃあ、どうすれば良いのか？　そんなの知らん。。。

何か、仕様書からテスト仕様書、テスト項目まで一切なく、テスト証跡だけを見せられて、一切説明しないSE/PGにレビューしている気分になってきた…

追記
パッと思いついたのが、何かの理由で実質上の意味なくサーバとクライアントの同期を取っていて、それがラグに見えてしまっているだけかも？

[vbsnbk]

長文に対する長文のレスなのでお互いに意味を掴み切れていない部分が有ったらごめんなさい。

回線に流れるデータ量を測定していません。　ラグは、端末に届く通信データ量じゃなくレスポンス速度ですよ。
単に端末で観測できるデータ量が少ないからサーバ関係ないってのは間違い。
あるアクションに対して、レスポンスがどの程度の時間で戻ってくるかです。
サーバがヒートアップしてくると、逆に端末に届くデータ量は、単位時間に対して減る傾向がでます。

そうですね。
キャラ固有のデータは恐らくそのキャラクターが最初に画面に出たときのみサーバから読み込まれますので、
画面内のキャラ（もしかしたら同じエリアサーバ内に存在するキャラ全てかも）が常に激しく出入りしているような
状況でも無い限り、通信帯域を圧迫するほどのデータのやりとりにはならないと思われます。
#というか、私のコメントはキャラの固有装備のデータの細かさがラグの原因では…というコメントに対するレスですね。キャラ装備データなんかはどんな複雑なアイテムでも通信に乗っかるのはそれぞれの内部ID程度ですので、
一人のキャラの表示情報の通信に占めるコストなんてのは知れたものかと。
　勿論サーバ側のデータベースからユーザデータを読み込む訳なのでコストが掛からないとは言えないですが、リアルタイムのバトルデータを計算してそれぞれに反映させるというエリアサーバの処理に比べれば大きな問題では無いかと思われます。

ゲームをプレイした感触でいえば、元々通信データのペイロードを潤沢に大きく設計し過ぎている感触を持ちました。
加えて、送信データの取捨選択がなされていない。　視界範囲やミニマップに見える範囲の動的データを無条件で垂れ流している
気がします。

これもそうなんでしょうね。ただ一定のデータを常に流して（サーバ上のデータを先読みして）いるので、画面内に表現されている情報量の
割りには通信量の変動が激しく無いとも言えるから、メリットもありデメリットも有りという所でしょうか。

追記
パッと思いついたのが、何かの理由で実質上の意味なくサーバとクライアントの同期を取っていて、それがラグに見えてしまっているだけかも？

例えば攻撃モーションとHPの増減の間のずれ、と見えるのがこれなんじゃないかと思いますね。
攻撃結果の数値がサーバからクライアントに渡される時点では当然サーバ上でHPの増減は計算反映済みな訳なので、
HPのパラメータが正しく同期されているからこそ攻撃モーションの前にHPが減っているように見えるという……(苦笑)。