通信対戦ゲームでの通信遅延について

質問

例えば60FPSで動作する格闘ゲームでは、1/60秒に一度キー入力を受け付けて
画面を更新しますよね？

これが通信対戦となると、1/60秒に一度自分のキー入力を相手に送信して
相手のキー入力を受信して画面更新しないと、正しく動かないと思うのです。

しかし、実際には1/60秒以内に相手からパケットをもらえる環境など
想定してたらまともに動かないとも思います。

何かごまかし方があるんじゃないかと思うんですが、そういったアルゴリズムについて
キーワードでもいいので何か教えて頂けないでしょうか。

回答No.2

jyufi_february · ベストアンサー

CEDEC2010で、セガの人がまさにその質問のパターンの通信対戦型格闘ゲームについて講演をしていました。
ここで解説されているのは、最初から、プレイヤーの入力が画面に反映されるまで（ネットワーク遅延分だけ）わざと遅延させる手法です。ごまかしというよりも、遅延の影響を最小限に抑えつつ公平なゲーム内容にするには、こういう形にならざるを得ないということでしょう。
2～3フレームというと 30～50msecですが、日本国内の状態の良い回線同士ならば、なんとかこの範囲に収まるのではないかと思います。海外だときついでしょう。

参考URL：

http://www.4gamer.net/games/105/G010549/20100905002/

お礼

参考URLが本当に参考になりました！
UDPで送りつつ、パケットロス対策で過去のフレーム分も載せちゃうなんて
考えてもみませんでした。

基本的にはキー入力をストリーミング情報として扱う感じで、
でも音声ストリーミングのように大容量のバッファリングをさせず
数フレーム分のバッファリングで捌いてくのですね。

自分なりに理解できたと思います。
ありがとうございます。

回答No.3

monova

私の知識内で簡単に回答します。

>例えば60FPSで動作する格闘ゲームでは、1/60秒に一度キー入力を受け付けて
>画面を更新しますよね？
キー入力と言っても、1/60秒間だけキーを押している訳ではないですよね。
一般的には0.1秒感覚でON/OFF出来れば速いほうだと思います。
そもそも、1/60秒だとチャタリングと区別がつかない場合もあります。
したがって、「 キーのON/OFFは最低でも0.1秒間キーをONにしておかなければ有効としない 」
と、すれば良いのではないでしょうか？

また、1/60秒毎にコマンド入力判定を行っているとは限りません。
60FPSというのは、描画速度での話です。

> しかし、実際には1/60秒以内に相手からパケットをもらえる環境など
1/60秒単位でのやり取りはそれ程厳しい環境ではないですよ。
P2Pなら尚更です。
とはいえ、常にベストな状態が維持できるとは限らないので現状では100ms
ぐらいを想定して設計される事が多いのではないでしょうか？

>もちろん入力がないフレームは送受信要らないと思いますが、例えば
普通は、入力がなくても「入力が無い」というデータを送受信をしています。
でないと、同期が取れなくなります。

>xフレーム目にユーザ１がガードを行い、x+1フレーム目にユーザ２がパンチを入力した際、
>xフレーム目のガード入力がx+1フレーム目の処理までにユーザ２に到達する必要がありますよね？
この理屈だと、1/60秒でパンチがヒットする事になりませんか？
通常、コマンド入力からヒットまで速くて0.2～0.5秒ぐらいではないでしょうか？
それで無ければ、モーションを見てガードやカウンターが不可能ですよね。

例えば、

人間の反応速度を考えると、コマンド入力完了から0.1秒後に技が発動しても
遅れているとは感じにくい（個人差はあるにしろ）
人間のキー入力時間は速くても0.1秒
ヒットの判定までに、最速でも0.2秒
コマンド入力は2フレーム毎に見る。

と、した条件を盛り込むとします。
それならば、100ms単位で同期をとって処理を行えば、それ程問題なくゲームが進行していきます。
（フレーム単位での同期が行いたいなら6フレーム程度での同期を行う）
これでも、タイミングにより若干の問題が(ガードが間に合うはずなのにヒットした等）
発生するのですが、0.1sec単位では人間に知覚されづらいので余り問題にならないのです。

と、ここまで書いている間に、No.2さんが リンク付きで回答がありましたね。
このリンク先の説明で概ね解決するのでは無いかと思います。

お礼

回答ありがとうございます。

> この理屈だと、1/60秒でパンチがヒットする事になりませんか？

スーファミのストIIとかだと、弱パンチの繰り出しモーションとかなくて
いきなりあたり判定だったような記憶があったので。
そのようなケースを想定したのですが、記憶違いかもしれませんね。

6フレーム(=100msec)程度であれば問題にならないということですね。
たしかに100msec程度の遅延は僕には気付けない世界だと思います。
一つ疑問が解決しました。
ありがとうございます。

回答No.1

nak777r

>これが通信対戦となると、1/60秒に一度自分のキー入力を相手に送信して
相手のキー入力を受信して画面更新しないと、正しく動かないと思うのです。

そうでしょうか？
どういう動きを開始したか（技の開始、歩き始めた、ガード始めた等）
ガードした
食らった
後は、定期的に、自分の座標と自分の体力ゲージの値を送り
相手の座標と相手の体力ゲージの値をもらう
両方の座標がわかっていれば空振りなのもわかるし

1/60秒毎に送信するタイミングはあるでしょうが
基本動作の開始時さえ分かればよいので、
1/60秒毎常にデータを送っている訳では無いと思いますよ

お礼

No2さんの参考URLを見て、やっとnak777r様の言っていることが
やっと理解できました。
理解力が足りなくって申し訳ないです。

> 1/60秒毎常にデータを送っている訳では無いと思いますよ

これについては回答者様によって意見が異なるようですが、おそらく
どちらでも実装可能そうですね。
信頼性を取るか、パフォーマンスを取るかみたいな話になるのかな、と
思います。

色々勉強になりました。
ありがとうございます。

補足

回答ありがとうございます。
もちろん入力がないフレームは送受信要らないと思いますが、例えば
xフレーム目にユーザ１がガードを行い、x+1フレーム目にユーザ２がパンチを入力した際、
xフレーム目のガード入力がx+1フレーム目の処理までにユーザ２に到達する必要がありますよね？
そうでないとユーザ２側の画面ではパンチがヒットしてしまう。
ということは、ユーザ２側ではｘフレーム目でのガードの有無を受信しないと
ｘ＋１フレーム目の描画ができません。

そこで画面が止まってしまうのはマズイと思うのですが…
（上記はユーザ１とユーザ２のキャラクタが密着しているものとします）

根本的に考え方が間違ってるはずなんですが、正解がなんなのかわからないのです。