TCPとUDP どっちがいいのでしょ？

[ぬこ]

こんばんは～。
ネットワーク対戦できるゲームが作ってみたいなぁっと思いwinsockを勉強中な日々をすごしてる者なのですが、
ちょっとした疑問がでてきたので聞いてください。

TCPとUDPについては勉強したのですが、格闘ゲームの場合ネットワーク対戦機能を追加するならばどっちのほうがいいでしょうか？
ほぼリアルタイムに動かしたいのでUDPをつかったほうがいいと思うのですが、パケットがロストすることがあるってのがひっかかります。
結構シビアなコマンド入力が求められる格闘ゲームの場合は、致命的な気がするのですが・・・、
回線状況にもよると思いますがどの程度ロストって起こるものなのでしょう？
わかるかたは参考までにおしえてくださるとうれしいです。
いっそTCPでいいかなっとも思うのですが、できれば複数人接続できるようにしたいなぁっと思ってます。
複数人と接続する場合は同時に送信できないTCPだとラグがすごそうな気がします。
どっちが向いてるか参考までに意見をお聞かせください。

～蛇足～
今は「WinSock2.0プログラミング」って書籍を参考にしているのですが、他にオススメの参考書とかありましたら紹介していただけるとうれしいです。これいい本なのですが借り物なので返さないといけないんですよねぇorz
とりよせようにも古い本らしく近場では在庫なくて取り寄せられないんです＞＜

[Justy]

　そんなに詳しいわけではないですが。


＞どっちのほうがいいでしょうか？

　どっちかと言われれば UDPじゃないでしょうか。

　TCPは相手に届いたかどうかを確認したり、届かなければ再送処理を行ったりと
処理負荷が高くレイテンシーも上がる傾向があります。

　リアルタイム性が重視される格闘ゲームなら、そういう状況になるよりかは、
余計なことはしない UDPの方が向いていると思います。



＞結構シビアなコマンド入力が求められる格闘ゲームの場合は、致命的な気がするのですが・

　元々リアルタイム性と正確な描画の両方を高い精度で要求する格闘ゲームは
あまりネットワークゲームには向かないと思うのですが、ある程度ロストしても
相手の動きを予測して描画して後でつじつまを合わせたり、
うまくゲームの仕様的に視覚でタイミングをとらなくてもいいようなゲームにするなどで
ある程度回避できるのではないでしょうか。



＞程度ロストって起こるものなのでしょう？

　まさに回線と状況次第としか言いようがないのですが、
ごく普通の家庭内にある有線による同一 LAN内で、ごく普通の使い方しかしていない
機器が数台程度しか繋がっていないのであれば、適度にパケットを送りつける分には
まぁほとんど発生しないと思っていいと思いますよ。

　とはいえ、そういう環境で動かしたゲームが短時間のうちに大量のパケットを
送りつけてた結果、ポロポロとロストすることはありえますが……。

[ベリ工]

＃回答ではないです。私の経験論を・・・

昔、私もソケットを用いてネットワークプログラミングを行った事があります。
ＵＤＰは確かにパケットがロストする可能性がある為、パケット投げっぱなしが基本
なので、良くストリーミング動画再生などに使われたりしますよね。
一方ＴＣＰは相手先に確実にパケットが送信される事が保証されているので
パケットロスは基本的に無いと思ってもらって差し支えないでしょう。

＞格闘ゲームの場合ネットワーク対戦機能を追加するならばどっちのほうがいいでしょうか？
格闘ゲームですか・・・どっちが良いかを判断するのは難しいですね。私は昔、
ぷよぷよみたいな落ちゲーをネットワークゲームにした事あります。
その時はＴＣＰで作成しました。また、ＷＥＢカメラの映像をネットワークで
別端末に表示するネットワークプログラムも作成しましたが、その際もＴＣＰでしたね。
理由は両者共にパケットロスが許されない仕様でしたから・・・。

さて、その実行速度は両者共にほぼリアルタイムに実行できました。
ゲームはまさにリアルタイムネットワーク対戦でき、ＷＥＢカメラ映像は
別端末からリアルタイムに映像が送信されているとは思えないくらい
表示されました。但し、インターネット経由ではなく、ローカルＬＡＮ環境
でしたのでインターネット経由だとほぼ間違いなく遅くなる可能性は大ですが。

リアルタイム性を追求する為、アプリケーション側でもそれなりの高速化を
ゲームでもＷＥＢカメラの場合でも実装しました。

ゲームの場合では
画像、音声データは送信しない。ゲームの今現在の状況データ（自分仕様のテキストデータ）のみ
送信する。画像、音声データはサイズが大きい為、これをそのまま送信するとリアルタイム性が
極端に落ち、ネットワークに負荷を掛けるだけです。画像、音声データは相手先の端末にも
同じゲームがインストールされているはずなので既に相手先に存在しているからです。

ＷＥＢカメラの場合は画像、場合によっては音声データそのもを送信せざるを得ません。
ではどうするかと言うと当然圧縮送信させます。圧縮解凍のプログラミングは
ネット上で探せばそれなりに見つかりますが、大抵はファイルＩＯを伴います。
ファイルＩＯで行うと処理が重くなるのでリアルタイム性が下がります。
なので圧縮解凍アルゴリズムはzipやlzh等の有名アルゴリズムをそのまま利用し、
ファイルＩＯが伴わない（メモリ上で圧縮解凍する）様に自分でそれを改造しましたね。

後は共通的な処理として別途サーバを儲け、受信プログラムをサーバプログラムにして各端末に
ブロードキャスト配信しました。複数端末から一斉に送信されると受信側はどの端末の何番目の
パケットか常に判断をしないといけません（ＴＣＰは送信順も保証されていた気がしますが、念の為に
判断してました）。これをクライアント端末に行わせるのは現実的でありません。なので、
パケットの仕様としてパケット内にヘッダ部とデータ部を設けて、受信時にヘッダ部を見てどの端末の
何番目か判断し、そしてそれをどんどん繋げて最終的に一つのバイナリデータが完成したら
各クライアントに送信する様にしていました。
それを受信したクライアント端末はメモリ上で解凍し、ゲームであればバックサーフェース（裏画面）に
描画し、ＷＥＢカメラであればビットマップハンドルを生成して画面に表示していましたね。

結論から言うと、ネットワークプログラミングは非常に大変です。いろいろな事を考えないといけませんから。
ゲームであればDirectX9(8だったかも)にDirectPlayというAPIが用意されていますので
それを使うのも手かもしれません。

長々と語ってしまいましたが、単なる私の経験論なので別にそうする必要は無いですよ。

[ぬこ]

Justyさん、ベリ工さんご回答ありがとうございました。

やはりどちらかというとUDPなんですね。
ロストすると聞いて不安になっていたのですがUDPでやってみよーと思います。
ロストしても 相手の動きを予測して後でつじつまを合わせたりなど、といった方法は思いつきもしなかったです。
目から鱗という感じで勉強になりました。色々方法はあるんですねぇ。


経験論、非常ためになりました。
私はまだネットワークプログラミングはカンタンなものしか行ったことがないので、
参考になります。ネットワークプログラミングはやっぱり大変そうですね・・・
試行錯誤された方の意見は説得力が違うなぁと感じました。
DirectPlayってのも調べてきました。ロビーのシステムなどこれはなかなか便利そうですね。
こっちにも興味がわいてきました。

少しでもわからないことやこのままでいいのか不安になると作業が滞ってしまう悪い癖があるのですが、
案ずるよりうむが安しってことでとりあえずプログラム組んでみて失敗してきます～。
そのほうが時間はかかってもより詳しく理解できそうだし、なんだかやる気でてきたのでがんばってきます。
お二方ともありがとうございました～。