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

■ずばりお伺いしますが、ＦＦ14のシステム的な重さは、
　抜本的なプログラム改修や作り直しをせずに可能なものなのですか？

　通信量の多そうな耐久度システムや修理に関してまるで手をつける姿勢が見えませんが。


■フォーラムが立ち上がって二ヶ月。
　ここは果たして何のために作られた場所ですか？
　開発の言い訳を聞くためにユーザーはここで議論をしているわけではありません。

　フォーラムが立ち上がるよりも以前、ＦＦ14の復活のためには小売からソフトを回収し、
　サービス停止を含め、十分な開発期間を以って
　プログラム自身の抜本的な修正をすべきだと一部のユーザーは提言してきました。
　素人目に見てもあからさまなプログラム的問題が見て取れるほどそれはひどいものでした。

　しかし御社は回収の手を打つこともなく、「できる」と言いながら年始から五ヶ月もの間
　それらのゲームの面白さと直接係わり合いのない部分に対し手を煩わせ、
　ユーザーの声に対し無理、といい続けています。


■もう言い訳は結構です。教えていただきたいです。
　プログラム部分の抜本的改修を行うことなくＦＦ14の負荷問題を解決できるのか否か。

　ＦＦ14を購入し、楽しいＦＦになることを待っている我々は、
　「待つ」ことに対し報われる日が来るのですか？
　私は待てました。御社がきちんと、このゲームを作り直すためにサービスを停止するのならば。
　一年だろうと二年だろうと待てていたでしょう。
　御社の全力を再開の日に味わうために、再び14をインストールし、ログインしたことでしょう。

　誠実に、現実的にお答えいただきたいです。
　目処が立っていないほど絶望的ならばその日まで放置するなり、スレッド削除をよろしくお願いします。

以下妄想ですが

１．1月に全く新しいサーバープログラム、クライアントの作成を開始していてそれが出るまでは小手先のパッチで時間稼ぎしてる。（ポエムが6月だったか7月を表している）

２．オートバトルにすることによって通信量が下がるからラグが少なくなるのを期待してる

３．１１の鯖の統合が先日行われました。１４の過疎鯖合併が先じゃないの？という状況で、合併された鯖はどこも人がいっぱいで阿鼻叫喚らしいです（ジュノ港に７００人以上、同時接続数５０００近くとか・・・）。そうやって１１からむしり取ってきた鯖を１４に持ってきて負荷問題をなんとかしようとしてる

４．いまのサーバーとクライアントをなんとかこねくり回して改善しようとしてる

さてどれでしょう？
１を期待したいんですが・・・

追記、一つ忘れていました
５．もうこれ以上の投資は無駄なので自然消滅を待つだけ・・・

①だったらいいな・・・・

負荷問題に関しては早急に何らかのコメントが欲しいですね。

あっ、コメントと言っても、お決まりの「　検討中です　暫くお待ちください　」とかはいらないです。

改善される時期、負荷軽減のために進めている計画などを教えていただきたいと思います。

FF14は１サーバあたりの収容キャラ数が少なすぎる！　オンラインなのに人がいないって、どういうこと！
ただ歩いているだけなのに、他者からダンスと言われるって、どういうこと！
http://forum.square-enix.com/ffxiv/s...139#post120139

ということで、通信量削減の提案
●キャラクターカスタマイズ（容姿）幅の削減
　髪の色とかメッシュとか瞳の色とか特徴とか特徴とか特徴とか特徴とか【微妙な違いの選択肢が多すぎる】

●シープ、ラム、ロストユー、ロストウェザーとか、そんなの【１種類でいいじゃん】

●NPC、モンスターの名称を【英語表記に統一】

とにかく負荷要因になっている余計なシステムを全部あげて行って、
ゲームの直接的な面白さに直結しないと思われる要素は残らず排除というわけにはいきませんか？

修理などの通信量が多いものは言わずもがな、ほかの方も挙げられている通り
外見的に直接影響の出にくいあるんだかないんだかわからない傷や模様。
また、重さの要因になっているのかはわかりませんがエモートのアクション。
開発の方ならばもっと直接的にそれを理解しておられるでしょう。
まずはゲームのためにそれらすべての要素をカットできませんか？

とにかく今望んでいるのは見える距離にいるキャラクターの全表示を可能にする少ない負荷です。
また、開発の方が仰る「負荷があるので～～が」などと言わせないだけのゲームに必要な負荷的余裕です。
このゲームは何ですか？　着せ替えゲームですか？　違いますよね？
ゲームがやりたいです。ゲームとして必要な部分にリソースを回しているゲームをしたいです。
余裕のない状況であることはユーザーでもわかっています。
贅沢は言いません。よろしくお願いします。

Quote:

---

Originally Posted by RemingtonSteele

FF14は１サーバあたりの収容キャラ数が少なすぎる！　オンラインなのに人がいないって、どういうこと！
ただ歩いているだけなのに、他者からダンスと言われるって、どういうこと！
http://forum.square-enix.com/ffxiv/s...139#post120139

ということで、通信量削減の提案
●キャラクターカスタマイズ（容姿）幅の削減
　髪の色とかメッシュとか瞳の色とか特徴とか特徴とか特徴とか特徴とか【微妙な違いの選択肢が多すぎる】

●シープ、ラム、ロストユー、ロストウェザーとか、そんなの【１種類でいいじゃん】

●NPC、モンスターの名称を【英語表記に統一】

---

その辺のデータを削減したところで、パッチのダウンロード時間の削減やユーザのHDDの容量は
減らせるかもしれないけど、肝心の通信量の削減にはこれっぽっちも役に立ちませんよ。

　一部の分かっていない人が声を大にして変な主張をしているから多くの人が勘違いしてますが、
問題は通信量ではないんです。サーバ側のバトル/移動/エリアサーバ間の処理引き渡しなどのサーバ側
レスポンス処理の問題で、これはパッチ毎に少しずつ改善（それをどう評価するかは各個人の自由ですが）されています。

そういった細かいデータの対処をして向上するのは、HDD上に置いてあるデータを読み込む速度が遅いとか、VGAや
CPUの処理能力が低いロースペックPCでの速度向上が主です。また、この辺はユーザ側の設定変更で
大幅にストレスを軽減させることが可能です。

現プロデューサーは出来ないことは言わないのがポリシーだそうです
ということはサーバー負荷については解決不可能なんでしょう
出来るのならとっくに言ってますよね、FF14にとって一番といっていい問題点なんですから

(´ρ`)へーーーーーーーーー

FF14が"ダメ"な根本的な問題ですね！
私は 一から作り直さないと無理と判断しましたので引退しましたが、
この問題には個人的に凄く興味がありますので 暫く様子見させて頂きます。

スクエニ開発さんに一言ｗ　Crystal Toolsがどのくらい優秀なものか知りませんが
CryEngine3もかなり優秀ですよ！お借りしたらどうですか？

Quote:

---

Originally Posted by Moebius

スクエニ開発さんに一言ｗ　Crystal Toolsがどのくらい優秀なものか知りませんが
CryEngine3もかなり優秀ですよ！お借りしたらどうですか？

---

マジレスすると・・・
ラグの問題はサーバのプログラム及び通信の仕様に依存することが多い。ゲームエンジンを切り替えても改善される可能性が低いでしょう。

Quote:

---

Originally Posted by Kristina_Farron

マジレスすると・・・
ラグの問題はサーバのプログラム及び通信の仕様に依存することが多い。ゲームエンジンを切り替えても改善される可能性が低いでしょう。

---

(´・ω・`) 何か勘違いしていませんか？
マジレスすると・・・ｗ
遅延の事など一言も語っていません。
失敗作をエンジンを変えてまでして作り直してどうするのでしょうか？
現FF14で使い物になるのは キャラデザインと各都市のデザインくらいだと思っています。
このデザインに関しては 流石と言うべきでしょうね。

自分的にはアイテム周りの重さが気になります。
一覧表示やスクロール時のもっさり感、アイテムを売るとき、移動するときのレスポンスの悪さなど。
これが起因して装備マクロも遅くなっているのではないのかな？

以前アイテム周りのレスポンスは問題だと思っている様なコメントがインタビューか何かでありましたが、
これまで何度か改善してきてはいるものの、まだまだかなと思っています。
現時点での方向性など、運営さんのコメントがほしいところです。

Quote:

---

サーバー負荷関連全般
プログラマが根本的なシステムを見なおしていますというのは既報のとおりですが、これは長期的な開発スパンになります。戦闘計算は、無駄なデータ検索や関数呼び出しを減らすことを意識して改修していきます。

---

別のところの回答を見ますと、まだ見通しは立っていないようですね。

(´・ω・｀)
まだ続くのか、負荷を言い訳にした検討しています祭りが……orz

8ヶ月もたっていまだにプログラマーがシステムを見直しているレベルなんです
どう改修するかを決めるだけで5年くらいかかりそうな気がしますね

Quote:

---

Originally Posted by puripuri

(´・ω・｀)
まだ続くのか、負荷を言い訳にした検討しています祭りが……orz

---

言い訳じゃなくて、正直に話してるだけでしょうｗ
サーバー回りの処理は本当にセンシティブなので、それなりにスキルの高い人がやらないといけない
（＝出来る人が限られるので、進行はどうしても遅くなる）ということだと思います。
まあ、最初にそんな大事な部分まで外注に出しちゃった経営判断がイカれてるんですけどｗ

あと、vbsnbkさんも仰ってますが、通信量と通信処理量は違います。
負荷について語るならこの辺は知識として持っておくべきかと。
超ざっくりと言うと、8byteの通信を1回行うより、1byteの通信を8回行う方が、処理としては「重い」ってことですね。

そういえば通信量が増えてラグになるって前提で話してましたが（私だけかもしれませんが）、
サーバーの計算能力（ダメージ計算やらＭｏｂのAIなどで）が足りてませんでした。ってことになったりしませんかね？
その場合はエリアをさらに小さく分割したりするのかしら？（確か三国はそうしましたよね）
それとも一つのエリアを複数の鯖で管理なんてできるんでしょうかね

鯖のプログラムに無駄がありすぎて鯖がいっぱいいっぱいになっているんだとしたら、まさしく根幹から手を付けないといけなくて一朝一夕では解決しそうにない気がします。しかも無駄な計算をしているところを特定し効率上げるのって大変そう・・・地道な努力の積み重ねが必要みたいな

Quote:

---

Originally Posted by Poice

そういえば通信量が増えてラグになるって前提で話してましたが（私だけかもしれませんが）

---

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

Quote:

---

Originally Posted by Moebius

現FF14で使い物になるのは キャラデザインと各都市のデザインくらいだと思っています。
このデザインに関しては 流石と言うべきでしょうね。

---

ウルダハが比較的マシというだけで、リムサやグリダニアのデザインは相当酷いと思いますよ。
パイプ通路でとにかく遠回りさせて時間稼ぎ、
移動の動線がバラバラで使いづらく、たむろしやすい広場もない
通路は細いくせに引っ掛かるオブジェクトは山盛りで、本当に常にイライラさせられます。

ＭＭＯですから、一箇所にプレイヤーが集まるとラグが起こりやすいというのは判りますが、
使い勝手を悪くしてユーザーを分散させよう、という発想が１４失敗の一因だと思っています。

Quote:

---

Originally Posted by Snowman

>>ウルダハが比較的マシというだけで、リムサやグリダニアのデザインは相当酷いと思いますよ。

---

いえ Mapの構造ではなく建物とかのデザインのことですね。
>>各都市のデザイン
誤解を招く表記ですみません。
私個人的にリムサの都市構造はこれまでのMMOにはない独創的な発想で面白いと思っています。
グリダニアは確かに酷いですね。

Quote:

---

Originally Posted by RemingtonSteele

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

---

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

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

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

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

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

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

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

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

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

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

Quote:

---

Originally Posted by puripuri

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

---

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

Quote:

---

Originally Posted by puripuri

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

---

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

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

Quote:

---

Originally Posted by puripuri

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

---

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

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

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

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

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

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

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

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


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

Quote:

---

Originally Posted by vbsnbk

データ量を上手く減らせばその分処理しなければいけないサーバ負荷も減りますので、無関係である
とまでは言えないのですが、現在の通信量（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にレビューしている気分になってきた…

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

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

Quote:

---

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

---

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

Quote:

---

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

---

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

Quote:

---

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

---

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

面白いスレッドですね。

私も少し書いてみようか・・・。

ラグの原因、それはfeifongさんが書かれているとおり、レスポンス速度が一番問題です。
で、このレスポンス速度は小さなプログラムだとあまり気になりませんが、このような大がかりなC/Sシステムであると、サーバー側で十中八九メモリリーク起こしてます。

他のネットゲームでは、それらを凌ぐために週１メンテナンスを実施しています。この週１のメンテナンス中に何をするかというと・・・

Quote:

---

１．サーバープログラムの再起動（メモリリフレッシュ）
２．データベースのRebuild-Index（Index検索を有効活用するため）

---

この辺りが主にやることです。
特に１．は必須、２．は時間がかなりかかるので３ヶ月に１回が目安かと思いますが。
で、今のFF14ですが・・・・週１メンテなど行っていませんよね？なので時間が経つにつれ、サーバー側でメモリリークを起こしてレスポンス低下を招き
ユーザー（クライアント）側にはそれがラグに写るという事に繋がると考えます。

もちろん、それ以前にサーバープログラムの処理実装がお馬鹿な為、レスポンスが悪いというのも考えられますが、こちらはパッチ毎に少しずつ改善していってるようで・・・。
まだまだ足りませんけどね。（元がどれだけ産廃プログラムだったかという事の裏返しでもありますが）


なので、パッチでのレスポンス改善ももちろん行う必要がありますが、週１メンテを実施するというのも一つの手です。ここまでやっていないのも珍しいというかおかしいくらいなので。

実施曜日は、週の頭や週末を避け、水曜くらいが妥当でしょうね。

Quote:

---

週１メンテナンス

---

確かに他のネトゲでは大抵やってますね。大規模なサービスプログラムではメモリリーク含むバグを根絶するのは難しいので、運営の定期メンテでカバーするというのは現実的な解かもしれません。

今はリテイナー街もサーバ再起動時に配置が記憶されますので、定期メンテのユーザにとってのデメリットは「その時間遊べない」位でしょうかね。他のネトゲと違って全世界サービスをうたってる以上、毎回ピークタイムにメンテが掛かるエリアのユーザにとっては迷惑な話かもしれませんが(苦笑)。

お世話になります。

リークはないんじゃないかな。　「要素数」が変動する要素が少ないし。　設計上、上限を作れる（定められる）サーバだしね
だからこそ、ゲームサーバに手を入れることを極端に恐れているし、実際、ゲームデータ部分のみの変更パッチが殆どだし
DBサーバでリークがあるようなら、冗長化して定期的にノードを再起動すれば、ホットリフレッシュもできるでしょう
競売もないし、DBサーバすら使っていないんじゃないかな。　よくてログアウト時にプレイヤ情報をDBにコミットしている位じゃないかな
まことしやかに書いておりますが、全部妄想です。

最初にオートアタックに手を入れたのだから、それはクライアントからの非同期アクション投入が、サーバ負荷の一番の原因だったのかもですね。
次に来るのは、移動速度制限、エリアの疑似分割、戦闘・行動・表情など結果到達範囲の縮小、可視範囲の縮小、天候エフェクトカットスイッチの追加、初期表示用のキャラクタ装備のプリロード（＝装備読込契機の延伸）、表示キャラクタ数の大幅削減、遠方で移動するPC/NPCの座標情報通知間隔の間引き、シームレスの撤廃、LSチャンネルの一本化、mob移動頻度の削減、友好NPCのモーション決定をクライアントで自動決定（これすらゲームサーバで決定しているような予感）などかな？と妄想している次第です。

今日はまだ飲酒していないので、筆が進みませんので、これにて。　暇つぶしの妄想ネタになれば幸いです


（てか、「かな」ばっかりな駄目な文章…）

Quote:

---

Originally Posted by feifong

お世話になります。

リークはないんじゃないかな。　「要素数」が変動する要素が少ないし。　設計上、上限を作れる（定められる）サーバだしね
だからこそ、ゲームサーバに手を入れることを極端に恐れているし、実際、ゲームデータ部分のみの変更パッチが殆どだし
DBサーバでリークがあるようなら、冗長化して定期的にノードを再起動すれば、ホットリフレッシュもできるでしょう
競売もないし、DBサーバすら使っていないんじゃないかな。　よくてログアウト時にプレイヤ情報をDBにコミットしている位じゃないかな
まことしやかに書いておりますが、全部妄想です。

最初にオートアタックに手を入れたのだから、それはクライアントからの非同期アクション投入が、サーバ負荷の一番の原因だったのかもですね。
次に来るのは、移動速度制限、エリアの疑似分割、戦闘・行動・表情など結果到達範囲の縮小、可視範囲の縮小、天候エフェクトカットスイッチの追加、初期表示用のキャラクタ装備のプリロード（＝装備読込契機の延伸）、表示キャラクタ数の大幅削減、遠方で移動するPC/NPCの座標情報通知間隔の間引き、シームレスの撤廃、LSチャンネルの一本化、mob移動頻度の削減、友好NPCのモーション決定をクライアントで自動決定（これすらゲームサーバで決定しているような予感）などかな？と妄想している次第です。

今日はまだ飲酒していないので、筆が進みませんので、これにて。　暇つぶしの妄想ネタになれば幸いです


（てか、「かな」ばっかりな駄目な文章…）

---

今のところ、大がかりなシステムでメモリリークしないプログラムはまず組めないでしょう。凄腕プログラマ（Wizard級）が寄って集ってやるなら話は別ですが。
DBサーバーでリークというのは有り得るでしょうがそれほど酷くはない・・・といったイメージ。逆に起こりまくるのはそれは製品として屑です。誰も買わない。
冗長化するならば、今のところOracle RAC一筋じゃないでしょうかね。それ以外の冗長化はゴミ。使い物にならないです。ま、ライセンス料の高いOracleをFF14に使ってるかどうか定かではありませんが。

DBへのコミットは定期的に行われているようです。行われてないとオンラインゲームは巻き戻りの嵐ですけど。
一部、ウィジットを表示したときにコミットしている箇所もあります。（当たり前か＾＾）
例：クラスランクのコミットはステータス＞習得クラスを開いたときに行われる節がある。
　　ランクが上がって習得クラスを見たとき、その時にランク数が書き変わるのを目視出来ることによるもの。お試しあれ。

どのRDBMSを選んでもそうですが、初期パラメータで使用しているとパフォーマンスは全然出ません。この辺りはDBエンジニアの経験がものを言うところです。
少し弄るだけで、劇的にパフォーマンスは変わります。そりゃもう20秒のクエリが1秒以内とかそんな感じで。
また、テーブル正規化も正しく行われており、クエリも高速化を計るような組み立てをしていればここでもパフォーマンスは変わりますね。
逆に、クエリをO/Rマッパなどに任せて動的に組んだ場合、最悪使い物にならないほど遅い。この辺りをどう組んでいるか見てみたいモノですね。

ゲームサーバーの根幹に手が付けられないのは、以下の理由と睨んでいます。

Quote:

---

１．コードがスパゲティ過ぎる
２．仕様書/APIドキュメントなどが存在しない。あるのはイミフなコメント行のみ
３．コードが冗長している＝うまくオブジェクトに分離できていない
４．オブジェクト指向で組んだは良いが、メモリ使用率の事を考慮に入れていない

---

まだまだあるでしょうが、ざっと出るのは上記４つくらいですね。クライアントにも同様のことが言えますけど。
クライアントは画像を読み込み、オンメモリ処理をかけているようなので、同じ場所に滞在していれば全然重くなりません。
しかし、街やマップを移動していると、新しい画像をメモリ上に展開するので、たちまちに重くなります。
通常、使われなくなったメモリ上のオブジェクトは解放してあげるのが世の常ですが、たぶん、現行FF14クライアントはそんなのしていない。
なので、ウル->BWを行き来するだけで、クライアントは激重になっていく。マップでは嵐や雨といったエフェクトもありますので余計にね。
クライアントが重くなると何が起こるか？それは受け取り側での情報ロストですかね・・・普通に考えるならば。
R0の悪魔はこの辺りから来ていると考えています。



ゲームサーバーのメモリリフレッシュ、DBのIndexデフラグ、クライアントのメモリリフレッシュ・・・これらをうまく行うためにも、定期メンテナンスは実施すべき。今からでも遅くない。

余談ですが、何億とRowがあるテーブルのRebuild-Index（Oracle）は、６時間以上かかりましたね・・・。１ヶ月後同じように行ったら２時間ほどで終わりましたが。
あの時は家に帰れないのではとヒヤヒヤしました・・・(´・ω・`)

Quote:

---

Originally Posted by Minna

DBへのコミットは定期的に行われているようです。行われてないとオンラインゲームは巻き戻りの嵐ですけど。

---

一点だけ。
FF11では、キャラデータの保持にはDBを使ってないそうです。（それでも実績として、鯖運営の安定性は高かった）
ソースは大昔の（今は亡き）DBマガジンです。運用担当者がそう言ってました。
残念ながら何月号かは失念・・・廃刊のちょい前です。
仮に、基幹周りの設計がFF11を踏襲している場合、FF14もそうだということになりますね。
※FF11サービス開始当初、S&Iとかでやたらとプレゼンしてたアレ（Oracle10gを使った大規模クラスター）は
課金系・POLまで含めた構成の話だった模様です。私も、この話読んだ時割とびっくりしましたよ。

# ちなみにOracle一択ってちょっと違和感あるなあ・・・大規模システムだったらDB2とかの方がマトモだと思うんだけど

Quote:

---

Originally Posted by Zhar

一点だけ。
FF11では、キャラデータの保持にはDBを使ってないそうです。（それでも実績として、鯖運営の安定性は高かった）
ソースは大昔の（今は亡き）DBマガジンです。運用担当者がそう言ってました。
残念ながら何月号かは失念・・・廃刊のちょい前です。
仮に、基幹周りの設計がFF11を踏襲している場合、FF14もそうだということになりますね。
※FF11サービス開始当初、S&Iとかでやたらとプレゼンしてたアレ（Oracle10gを使った大規模クラスター）は
課金系・POLまで含めた構成の話だった模様です。私も、この話読んだ時割とびっくりしましたよ。

# ちなみにOracle一択ってちょっと違和感あるなあ・・・大規模システムだったらDB2とかの方がマトモだと思うんだけど

---

調べてきました。2008年3月号のようですね。また古くのWeb記事ではこの件に関してのカンファレンスも開かれていたようで。
キャラデータをファイルとしてですか・・・。コストがバカ高いですねぇ。（ここでいうコストはストレージのRead/Write）
しかしファイル保存という事ならば、ロドストのヒストリ同期が遅いというのも頷けますね。おそらくキャラクターキャッシュの更新を行う処理がスケジューラで
動いていると考えられますから、そのスケジューラが動くまではロドストで最新ヒストリが閲覧できないとなりますので。

そしてファイルということならば、且つFF11の頃よりも高性能ということならば、おそらくはKVS系の何かでしょうね。ちと難しそうだな・・・。
KVSについては私はあまり知識がないので、深くは語れません。概念的なモノは理解してるんですが・・・(´・ω・`)

OracleもDB2も古くからあるRDBMSであり双方がトップシェアを狙っているのは確かですね。
でもまぁ突き詰めて、パフォーマンス・チューニングを適切に施せばどのRDBMSでもモンスターに化けますが。
トランザクションが多いシーンであるとやはりOracleのトランザクション処理が優秀と言えるかと思います。
シーンに応じた、またコスト面も考えてRDBMSを選ぶのが普通ですねぇ。

某重力のMMOでDBがSQL Serverだったのを知ったときは吹き出しそうになりましたが・・・
それでもFF14の当初のようなラグラグ・ゲームじゃなかったのは確かです。

Quote:

---

Originally Posted by Minna

調べてきました。2008年3月号のようですね。また古くのWeb記事ではこの件に関してのカンファレンスも開かれていたようで。

---

おおう、私の適当な書き込みから調べて戴いたんですね。
申し訳ない、古い本はどんどん捨ててるものですから(´Д｀; )ヾ

Quote:

---

Originally Posted by Minna

キャラデータをファイルとしてですか・・・。コストがバカ高いですねぇ。（ここでいうコストはストレージのRead/Write）

---

どうでしょう？一定以上のリクエスト数がある場合、DBを使ってもその辺のコストって下がらないと私は思うんですが。
むしろ、アプリケーション側の実装で細かく制御できる分、DBを使う方が不利じゃないかと感じます
（なので件の記事は驚きはしましたが、結構ストンと胸に落ちました）

Quote:

---

Originally Posted by Minna

OracleもDB2も古くからあるRDBMSであり双方がトップシェアを狙っているのは確かですね。
でもまぁ突き詰めて、パフォーマンス・チューニングを適切に施せばどのRDBMSでもモンスターに化けますが。
トランザクションが多いシーンであるとやはりOracleのトランザクション処理が優秀と言えるかと思います。
シーンに応じた、またコスト面も考えてRDBMSを選ぶのが普通ですねぇ。

---

んですね。ですが私はOracleは嫌いです(´∀｀)
某MMOって多分FFTチックなグラのアレかと思いますが、SQL Serverってだけで吹くのはMSに失礼じゃｗ
97の時は随分アレでしたが、2000あたりからだいぶマトモになってきてますよ。
Oracleみたいに細かいパラメータ制御が出来ないので、そういうのを飯の種にしている人は嫌いますが
阿呆なテーブル設計とか阿呆なSQL食わせなきゃいいだけです。
Oracleってそういう馬鹿を力技で捻じ伏せちゃうところがありますからね・・・っと脱線が過ぎるか。失礼ｗ

Quote:

---

Originally Posted by Zhar

おおう、私の適当な書き込みから調べて戴いたんですね。
申し訳ない、古い本はどんどん捨ててるものですから(´Д｀; )ヾ

---

こういうとき、デジタルデータで保存しておくとかさばらなくて良いですよねぇ・・・。
デジタルだと今ならスマホとかで通勤・通学中に読めたりしますし。
オライリーがんばれ！（謎）

Quote:

---

Originally Posted by Zhar

どうでしょう？一定以上のリクエスト数がある場合、DBを使ってもその辺のコストって下がらないと私は思うんですが。
むしろ、アプリケーション側の実装で細かく制御できる分、DBを使う方が不利じゃないかと感じます
（なので件の記事は驚きはしましたが、結構ストンと胸に落ちました）

---

実装を複雑にするか、それともRDBMSにお任せするか・・・どちらかだと思います。
後々のことも考えると、実装は簡素で良い・・・改良しやすいし(´・ω・`)
もちろん、様々なコストを考えた実装をしていただかないと、どちらでも「おばかさぁ～ん」って田中理恵声で罵ってもらううことになりますが。

Quote:

---

Originally Posted by Zhar

んですね。ですが私はOracleは嫌いです(´∀｀)
某MMOって多分FFTチックなグラのアレかと思いますが、SQL Serverってだけで吹くのはMSに失礼じゃｗ
97の時は随分アレでしたが、2000あたりからだいぶマトモになってきてますよ。
Oracleみたいに細かいパラメータ制御が出来ないので、そういうのを飯の種にしている人は嫌いますが
阿呆なテーブル設計とか阿呆なSQL食わせなきゃいいだけです。
Oracleってそういう馬鹿を力技で捻じ伏せちゃうところがありますからね・・・っと脱線が過ぎるか。失礼ｗ

---

その力技でもねじ伏せられないクエリを近頃見ましたよ。制作者表へ出ろ！と心の中で叫びました。
SQL Serverは土台がWindows・・・という段階でアウトーーーー！セキュリティパッチ毎にダウンタイムとか嫌だよもん・・・
しかもパッチの影響でいろいろ動かなくなることもしばしば・・・もっと嫌だよもん(´・ω・`)


おっと・・・ゲームから大分逸れてしまった・・・。技術系の話は面白いのでついつい・・・。
あまり逸れるとRepさんに私の存在を消されてしまう or リアルで３時間遊んでこい！コースを選ばれてしまうので、自重しておきます。

技術系の話が、エラいＬｖで展開されてるので、私からしてみれば「神々の討論会」にしか見えなかったヨ(；´Д｀)

　サーバーの負荷問題に関してなのですが､コレって実言えば「クローズドβテスト」の段階で解決されるべき問題じゃなかったのかなと、今にして思えば感じており､元βテスターとしては、口惜しい所でもあります。

　なんでこんな事を思ったのかと言うと､今月頭ごろ、このフォーラムでも｢チョッピリ吹き荒れた」”とあるネトゲの「クローズドβテスト」”での出来事がキッカケなのです。

　というのも、その「クローズドβテスト」が開始されたのは午後４時、私が参加したのが､午後８時を過ぎていたのですが、そのときの「とあるネトゲ」の状態と言えば・・・ＦＦ１４を「はるかに上回る」激烈級のラグに襲われていたのです。

（普通に動いても、超スローモーション状態だったのです。周りに人が居なくてＭｏｂばかりになってもね。ＵＩの反応速度も､ＦＦ１４の開始当初”よりも”遅かったです。開始当初のＦＦ１４を普通にプレイできるＰＣを以ってしてもね。）

　で、開始して約１０分後・・・運営側より「只今から緊急メンテナンスに入ります。メンテナンスが明けるのは、午後１０時半を予定しております」という緊急アナウンスが入り､全員が強制ログアウト。

　その後､午後１０時半を回って、再度ログインしてみたら・・・そこは正しく「別世界か！！」と思えるほど、ラグが殆ど無くなった「とあるネトゲ」の姿だったのです。

　そのときのチャットウィンドウは、「よくやった！！！」「おめでとう！！」という歓声で埋め尽くされました｡

　クローズドβテスト後に放送された､公式のＵＳＴ番組内（しかも、日本側の総合Ｐ自ら出てきてます）にて、こんな発言をなさってました。

　「ユーザーに､『サーバーの数が少なかったから、重かったんでしょう？』とブログ等に書かれたりしましたが､あれは当初の予定通りでした｡ところが、予期せぬ別のトラブルが発生してしまい､初日の緊急メンテということになってしまいました。こういうことを発見することも､クローズドβテストの目的なんです」

　正に「目から鱗が落ちた」と同時に､「コレ（ＦＦ１４）のクローズドβの時に、なんで「全体的に付きまとうラグ」を指摘できなかったんだ」と自らの知識力の無さを反省した次第です・・・。

　少々負荷問題とは関係が無い文になっちまったかもしれませんが､元βテスターの「くやしさ」を判ってもらえれば幸いです・・・。

CBの時点いろいろ指摘されても改修する気 (時間?) すらなかったよ。
UIと戦闘まわりのバグつぶしだけ手一杯。
そういえばFF11の時PS2 CBがかなり長期間で進行、一旦安定化した段階になってから発売だったけど、
やっぱり「αより毛は生えた」状態で14の強行発売を決めたトップは一番いけない・・・