FPSを作ってみる@wiki
02)
最終更新：
Bot(ページ名リンク)
-
view
(2010/02/27)
あ～一応誰か通信不能になった際のリカバリ処理はOKかな～？といったところ．
winsockの扱いには少し慣れてきた気がする．
p2p形式なんてFPSではまず使わないだろうから今はどうでもいいんだけど
当方，興味があると色々手を出す性格でありましてシミュレーションにも挑戦してみたいという願望があります．
そういう多数のユニットを動かすゲームではサーバに全部処理させてたらあるプレイヤから別のプレイヤへデータを渡すのに
プレイヤ1 -> サーバ -> プレイヤ2
という風に回り道するがp2pでは
プレイヤ1 -> プレイヤ2
のようにダイレクトに渡せるというメリットがある．（サーバに負荷が集中するのも防げる）
デメリットとしては誰か1人でもラグってると全員に影響を及ぼす事．
でもこれって考えようによっては全員同じくらいの操作遅延でプレイできる＝対等な条件での対戦
ということなので一概に悪いとも言えないか．
winsockの扱いには少し慣れてきた気がする．
p2p形式なんてFPSではまず使わないだろうから今はどうでもいいんだけど
当方，興味があると色々手を出す性格でありましてシミュレーションにも挑戦してみたいという願望があります．
そういう多数のユニットを動かすゲームではサーバに全部処理させてたらあるプレイヤから別のプレイヤへデータを渡すのに
プレイヤ1 -> サーバ -> プレイヤ2
という風に回り道するがp2pでは
プレイヤ1 -> プレイヤ2
のようにダイレクトに渡せるというメリットがある．（サーバに負荷が集中するのも防げる）
デメリットとしては誰か1人でもラグってると全員に影響を及ぼす事．
でもこれって考えようによっては全員同じくらいの操作遅延でプレイできる＝対等な条件での対戦
ということなので一概に悪いとも言えないか．
あれ？予定ではもうゲームが出来てるハズじゃなかったっけな．おかしいなあ・・
関係ないけどいつか話に出たシャドウタワーアビスを買ってみたのでそのうちやるつもり．
前作はクリア済み．
前作はクリア済み．
(2010/02/16)
あまりにも作業が進まないので過去の配信動画を2つほど上げておいた．動画リストのページからどうぞ．
なんだかんだコードは書いてるんだけどちょっと作ってはやり直しの繰り返しで全然できてこない．
メインのソケットとは別にサブで大容量データをやり取りする仕組みを作ろうとしたら結局最初から書き直す形となったし．
てかどうすんだコレ？もう2月半分過ぎちゃったぞ．
なんだかんだコードは書いてるんだけどちょっと作ってはやり直しの繰り返しで全然できてこない．
メインのソケットとは別にサブで大容量データをやり取りする仕組みを作ろうとしたら結局最初から書き直す形となったし．
てかどうすんだコレ？もう2月半分過ぎちゃったぞ．
(2010/02/13)
当面はTCPオンリーで作ることに決めた訳ですが．
ユーザーの作成したアバター画像なんかの比較的デカいデータを送受信するには
ソケットを別途確保した方が良いのかな？
その場合はNICの作業自体は変わらないけど併行して処理できる点でCPUで言うスレッドのような感じになるのか～
ユーザーの作成したアバター画像なんかの比較的デカいデータを送受信するには
ソケットを別途確保した方が良いのかな？
その場合はNICの作業自体は変わらないけど併行して処理できる点でCPUで言うスレッドのような感じになるのか～
#追記1
現在，本流とは別に大きいデータをやり取りする為の大改修を施している．
今まで固定長バッファで事足りてた＆簡略化を図っていた場所がいろいろ面倒だ
今まで固定長バッファで事足りてた＆簡略化を図っていた場所がいろいろ面倒だ
(2010/02/12)
知らない人に簡単に説明するとTCPは確実にデータが届いたか確認，必要なら再送するプロトコルで，
UDPはデータ送りっぱなしのプロトコル（その分軽い）です．
で，何故かつい最近まで必死に「UDPは軽いプロトコルだ」「UDPをメインにしないとラグが酷くて使えない」という幻想を持っていた．
実際は全くそんな事は無く，むしろTCPを使わずにゲームなんか作れないだろうと．
MMORPGのログイン画面やゲーム中のフラグ同期がTCP必須の主な例か．
UDPはデータ送りっぱなしのプロトコル（その分軽い）です．
で，何故かつい最近まで必死に「UDPは軽いプロトコルだ」「UDPをメインにしないとラグが酷くて使えない」という幻想を持っていた．
実際は全くそんな事は無く，むしろTCPを使わずにゲームなんか作れないだろうと．
MMORPGのログイン画面やゲーム中のフラグ同期がTCP必須の主な例か．
まあ確かにTCPだとデータが途中でロストしたら再送の間，後続データの流れが滞るわけだけど
ゲームだから1秒間に60回も転送できれば全く問題ないわけで．
これがストリーム動画とかだと千や下手すれば万単位なんじゃなかろうか？
あ，1秒60回は自分の感覚です．
つまり遅延も気にするだけ無駄っぽい．ブロードバンドも普及してるしね．
ぶっちゃけ今の環境でアクションゲームをTCPオンリーで作ってもUDPと変わらんだろうなあ．
ゲームだから1秒間に60回も転送できれば全く問題ないわけで．
これがストリーム動画とかだと千や下手すれば万単位なんじゃなかろうか？
あ，1秒60回は自分の感覚です．
つまり遅延も気にするだけ無駄っぽい．ブロードバンドも普及してるしね．
ぶっちゃけ今の環境でアクションゲームをTCPオンリーで作ってもUDPと変わらんだろうなあ．
UDPが活躍する場面っていうのは主人公の位置や向きデータなんかの
新しいデータが先に届いたら古いデータは意味を成さない（古いのを再送しても無駄な）場合と
マルチキャストが出来るので複数のPCへデータを送る時，
文字通り確認応答が要らない届かなかったら届かなかったで構わないデータとかですな．
MMORPGのような大規模になると1バイトでも節約したいだろうから大活躍なのかも．
新しいデータが先に届いたら古いデータは意味を成さない（古いのを再送しても無駄な）場合と
マルチキャストが出来るので複数のPCへデータを送る時，
文字通り確認応答が要らない届かなかったら届かなかったで構わないデータとかですな．
MMORPGのような大規模になると1バイトでも節約したいだろうから大活躍なのかも．
結論として詳しいところはわからんけど初心者はつべこべ言わずに全部TCPで作っとけ
それで遅延が気になるならUDPを検討しろとなりそうだ．
それで遅延が気になるならUDPを検討しろとなりそうだ．
・・・・という駄文でした．
(2010/02/11)
なんか昨日の記事の日付が間違ってたし意味分からん．
さてヤバイ．もう2月中旬に入る勢いなのにまだネットワークやってる．
だがグチグチ言っても何も生まれないのは明白なので気を取り直して再開する．
現在，ユーザープログラムが何か通信プレイを続ける上で問題が起こったと判断した場合や
又はネットワーク基本クラス（今作ってるとこ）がネット切断等の問題を検知した時に
自動で問題のあるピアを判定して切断，残りのピア同士で通信を再開するというアルゴリズムを書いている．
昨日の一箇所を直したらわりかしスムーズに動いているので今週には決着をつけたい．
だがグチグチ言っても何も生まれないのは明白なので気を取り直して再開する．
現在，ユーザープログラムが何か通信プレイを続ける上で問題が起こったと判断した場合や
又はネットワーク基本クラス（今作ってるとこ）がネット切断等の問題を検知した時に
自動で問題のあるピアを判定して切断，残りのピア同士で通信を再開するというアルゴリズムを書いている．
昨日の一箇所を直したらわりかしスムーズに動いているので今週には決着をつけたい．
(2010/02/10)
ページの左側に叫んだ通り物凄く初歩的なミスでウン時間潰してしまったので呆れているという．
P2P形式での通信確立処理を今やってて，まずはホストにクライアントが繋ぎ
ホストがIPアドレスの伝達役となってクライアント同士で別の接続を開く．
全員が相互接続できたらゲーム開始処理をしてその後はホストクライアントの区別無くP2Pに～という流れ．
の予定だったのだが．
P2P形式での通信確立処理を今やってて，まずはホストにクライアントが繋ぎ
ホストがIPアドレスの伝達役となってクライアント同士で別の接続を開く．
全員が相互接続できたらゲーム開始処理をしてその後はホストクライアントの区別無くP2Pに～という流れ．
の予定だったのだが．
あれ～なんで最初の接続（ホストとクライアント1人目）は大丈夫なのに追加で人が来た時に
2人目以降クライアント同士のコネクションが10秒程してからロストすんだこれ？とソースコードを舐める様に調べていたら
なんとなんと，繋いだはいいがメンバリストに入れてないので結果的に接続要求だしっぱになっていた．ビックリ．
それでも全員ホストとは繋がっていたので個々のパケットは届くし・・・
ネットワーク（というか2つ以上のプログラムとの連携）って難しいなあ
2人目以降クライアント同士のコネクションが10秒程してからロストすんだこれ？とソースコードを舐める様に調べていたら
なんとなんと，繋いだはいいがメンバリストに入れてないので結果的に接続要求だしっぱになっていた．ビックリ．
それでも全員ホストとは繋がっていたので個々のパケットは届くし・・・
ネットワーク（というか2つ以上のプログラムとの連携）って難しいなあ
