ラグをどうにかしないとバトルどうのこうのではないのではないか

[Minna]

マンガや小説の読みすぎｗ　通信仕様に関わるところは、ほぼ触れないと見ていいです。
大体、光より早い通信手段は無いんだから・・・
（どこぞの政党は、光より早い回線が出来たらどうするんですか！って仕分けしようとしてましたがｗｗ）


通信じゃなく、バトル仕様の根本変更で、これをやろうとしてるっぽいですね。
多分、オートアタックにする理由の一つがソレだと思います。お互い、期待して待ちましょうか・・・ｗ
最低限FF11レベルなら文句ないなあ

回線レベルでの"通信"という意味でコメントしたわけではありません。もし回線レベルとして最初のコメントを書かれていたので在れば申し訳ない。

通信遅延のさほど無い場所では気が付きにくいでしょうが、ＢＷなどの重い地域では顕著に現れるのが

　　アクション実行->攻撃判定->ダメージポップアップ->キャラクターモーション->ログ表示（キャラクター視点）
　　攻撃判定->ダメージポップアップ->モンスターモーション->ログ表示（モンスター視点）

の順で通信が行われているであろう事（これは他の方も似たようなことを違うスレッドで書かれていたはずです）。
遅延が大きければ大きいほど、この矢印の間は大きくなり、結果ちぐはぐな戦闘といつの間にか死んでいるという現象が現れる。（大体R300超えたくらいからわかるかな・・・）
実際にパケットを盗聴やプログラム解析した訳じゃありませんので、ゲーム上で見える現象を言葉にするしかないので、上のような表記ですが。
#パケット盗聴やリバースはいろいろやばいですからね

また、これもパケットを見ているわけではないので、一応やってるとは思いますが通信データの圧縮です。
データ量が大きければ大きいほど、サーバーが重いときのクライアントに映る"重さ"即ちラグと感じる度合いは大きくなります。
圧縮するか、データ量を極力小さくすれば、サーバーが重くてもさほどクライアントにはわからなくなります。
#もちろん、クライアントＰＣのスペックがめちゃくちゃ悪かったりするのは別のお話しですけど。

こういう意味から、「プログラマのお仕事、スキルの見せ所」と書いたわけです。
私もプログラマの端くれであり、C/S系も組むことから、そのようなコメントをしたわけで、そんな通信回線レベルで光を超えろとか無理難題は言いません。

まとめますと、回線レベルではなく、あくまでも"クライアント・サーバー間のプログラムによる通信仕様"という意味で書いたこと、ご理解いただければと思います。

[Zhar]

まとめますと、回線レベルではなく、あくまでもクライアント・サーバー間のプログラムによる通信仕様という意味で書いたこと、ご理解いただければと思います。

おや、技術者の方でしたか。じゃあ尚更素人さんに誤解させるような書き方はマズいと思うんですよ
先日も、手段なんてどうでもいいからラグだけ修正しる！みたいな方が沸いて辟易しましたし(´д｀)
まあ、私も解析した訳じゃないので断言は出来ないですが、通信データ「サイズ」と
現状の通信ラグには線形関係は無いと思いますよ。
関係あるのは通信頻度のほうで、多分何でも通信しすぎてDoS状態になってるんじゃないかと・・・
だから根本のゲーム仕様（バトルのポチポチ戦闘とか、リテイナーの通信とか）を変えないと
軽くならんのじゃないかと予想してます。
というわけで、頑張るのはPGレベルの人間じゃなくて松井さんとか皆川さんとかのデザイナー層でしょうね。
なのでまあ、この場で頑張れ！って書くわけですｗ

[Minna]

おや、技術者の方でしたか。じゃあ尚更素人さんに誤解させるような書き方はマズいと思うんですよ
先日も、手段なんてどうでもいいからラグだけ修正しる！みたいな方が沸いて辟易しましたし(´д｀)
まあ、私も解析した訳じゃないので断言は出来ないですが、通信データ「サイズ」と
現状の通信ラグには線形関係は無いと思いますよ。
関係あるのは通信頻度のほうで、多分何でも通信しすぎてDoS状態になってるんじゃないかと・・・
だから根本のゲーム仕様（バトルのポチポチ戦闘とか、リテイナーの通信とか）を変えないと
軽くならんのじゃないかと予想してます。
というわけで、頑張るのはPGレベルの人間じゃなくて松井さんとか皆川さんとかのデザイナー層でしょうね。
なのでまあ、この場で頑張れ！って書くわけですｗ

そうですね。通信データの頻度はさほど昔と変わってないかと思います。
しかし、データ量は確実に減っている気がします。それこそ昔はデータ量多くてHUBが常時点灯してましたし・・・
#HUB/NICが壊れないかひやひやでしたけど！

しかも昔はデータ量が多いものだから、DoS攻撃まがいな状態でサーバーも頻繁に落ちていたのではないかと推測します。

で、ＰＧレベルのお話しですが、いくらデザイナー（この場合SEというべきか）が「こうしたい！」と考えても、ＰＧにそれを具現化（コード化）できる能力（スキル）が
足りてないと、全く無意味なんですよ。
なので敢えてプログラマのお仕事・スキルと書いてたわけです。

[Zhar]

そうですね。通信データの頻度はさほど昔と変わってないかと思います。
しかし、データ量は確実に減っている気がします。それこそ昔はデータ量多くてHUBが常時点灯してましたし・・・
#HUB/NICが壊れないかひやひやでしたけど！

しかも昔はデータ量が多いものだから、DoS攻撃まがいな状態でサーバーも頻繁に落ちていたのではないかと推測します。

で、ＰＧレベルのお話しですが、いくらデザイナー（この場合SEというべきか）が「こうしたい！」と考えても、ＰＧにそれを具現化（コード化）できる能力（スキル）が
足りてないと、全く無意味なんですよ。
なので敢えてプログラマのお仕事・スキルと書いてたわけです。

通信データサイズと、通信頻度をごっちゃにしてません？それとも敢えて意図して「データ量」って表記なのかな？
ちなみに、oβ→製品版では、通信「頻度」は確実に減少してました。ルータのログがそうなってたのでｗ
最近はどうなんでしょうね・・・バージョンアップのたびにその辺まで弄ってるんでしょうか。そうは思えないけど。
ゲーム会社って所謂SEってのはいないって聞いたことがあるんですが、■さんはどうなんでしょうねえ。
でも何にしても、上からトンデモ仕様を投げられて「何でもいいから快適になるように実装してねｗｗｗｗｗｗ」
とか言われても下のPGとかはエラい迷惑じゃｗ　Minnaさんご自身も経験ないです？ｗ
最近ようやく、■の求人も正社員募集に変わったようですし、上も下もみんな頑張ってってことで一つｗ
特に松井さんにはホント超期待してます。オートアタックでかなり変わると思うんだよなあ

[Minna]

通信データサイズと、通信頻度をごっちゃにしてません？それとも敢えて意図して「データ量」って表記なのかな？
ちなみに、oβ→製品版では、通信「頻度」は確実に減少してました。ルータのログがそうなってたのでｗ
最近はどうなんでしょうね・・・バージョンアップのたびにその辺まで弄ってるんでしょうか。そうは思えないけど。
ゲーム会社って所謂SEってのはいないって聞いたことがあるんですが、■さんはどうなんでしょうねえ。
でも何にしても、上からトンデモ仕様を投げられて「何でもいいから快適になるように実装してねｗｗｗｗｗｗ」
とか言われても下のPGとかはエラい迷惑じゃｗ　Minnaさんご自身も経験ないです？ｗ
最近ようやく、■の求人も正社員募集に変わったようですし、上も下もみんな頑張ってってことで一つｗ
特に松井さんにはホント超期待してます。オートアタックでかなり変わると思うんだよなあ

そんなこというSEなら、コード書く前に辞表届けを書きます。
しかし伝わりにくいようなので、出来る限り箇条書きで書いてみますね。

－データ量
　C/Sでのデータ量は極力小さくしなければならない。この際に有効なのがデータ圧縮。データ圧縮に関しては、もうかなりの先人が
　コードを書いているので、ソレを拝借することを考慮に入れつつ、最適な圧縮ルーチンを組み込む。かなりいろいろ圧縮ルーチンあると思うので
　例は割愛。簡単に言えば1MBのBMPの生画像を送るか、ZIPで圧縮した数KBのファイルで送るかといった感じ。

－通信頻度
　アクション毎に送らず、どこかでアクションをパック化し、１通信でのアクション量を増やしておく。パックすることにより、C/S間の通信頻度は下がる。
　例（クライアントから見た場合）：
　　　殴れ（送信１回）　->　ダメージ表示（受信１回）　->　キャラモーション（受信１回）　->　ログ表示しろ（受信１回）
　　　　　送信１受信３
　パックしてみる
　　　殴れ（送信１回）　->　ダメージ表示＋キャラモーション（受信１回）　->　ログ表示しろ（受信１回）
　　　　　送信１受信２
　結果受信回数を1回減らすことが出来る。＝通信頻度は下がる。

で、ユーザー（プレイヤー）が"ラグ"と感じるのは、行動/判定/モーションがちぐはぐになっているというところが大きいので、前の書き込みの
　　

アクション実行->攻撃判定->ダメージポップアップ->キャラクターモーション->ログ表示（キャラクター視点）
攻撃判定->ダメージポップアップ->モンスターモーション->ログ表示（モンスター視点）

を考えてみる。
もちろん、量/頻度以外にも致命的なミスがあるので、それも修正してみる。

　　アクション実行（送信１）　->　[キャラクターモーション＋攻撃判定＋ダメージポップ]（受信１）　->　ログ表示（受信１）

送受信の頻度を下げ、いくつかの行動をパック化した状態がこれで、あとは圧縮しつつ送受信するのみ。
で、見ればわかると思いますが、アクション実行後の順序を若干変えている。これは今のちぐはぐな戦闘を解消する、また突然死や戦闘をより普通にするために変えてある。
#モーション前に判定って、即ち野球でボール投げる前にストライク！って言われているようなものですからね。

やば・・・余計わかりにくくなったかな・・・（涙

[imo]

FF14では、FF11の頃のように通信回線がISDN前提というわけではないので、当初からあまりクライアント＜ー＞サーバ間のパケット量の見積もりを厳密に行なっていない節がベータの頃からありました。

現在大きな見直しをしているのでしょうが、ラグの原因の大半は、当初の設計ミスであると自分は想定しています。
上記の仮説を正とすると、問題の解決が用意ではないことは容易に推測できます。

とはいえ、だから泣き寝入りするのではなく、開発者に対してラグ問題の情報開示と解決策の方針を示してもらうよう
熱く語ることがプレイヤーの出来ることではないかと考えます。

[Zhar]

やば・・・余計わかりにくくなったかな・・・（涙

単純に、データをパック化したら、そこがまたラグの発生要因になりますなｗ
判定順序は、現状がどうなってるか分からないですからね・・・いや、ホントどうなってるんでしょうねえ(´д｀)
兎にも角にも、バトルの仕様変更は最優先ですよねえ。現状のバトルは何がしたいんだレベル。

[imo]

いいかげん、ラグ問題のロードマップを見せてほしい。どうやって解決しようとしているのかくらい公表できないのかな？方針さえも不透明で、不安が募るばかりです。

[darden]

ですねえ、一番重要な問題な気がするんですが、どういう対策をしようとしているのか、それともオートアタックにして何か変わるのか・・具体的なコメントがないですもんねえ。
重要な問題だけにすぐにコメントが欲しいところです。

このスレを見てる人、同じようにこの問題について考えてる人、開発にどれだけの人がこの問題について注目しているかを知ってもらうためにも、短くてもいいのでなにかコメをたくさんもらえると注目されるかも！？

[Kristina_Farron]

あくまで個人の感覚ですが、

某電力会社のような実行不可能のロードマップを提出するより、しっかり検証してから公表するほうが望ましい。

一応プログラマとして、見えない基盤を改修することの大変さがわかります。
これはFF14未来の死活にかかわる最重要問題；二度の失敗が許さない。

我々の金を稼ぎたい会社ならそれをわかってないはずがない。