FPSを作ってみる@wiki
05)
最終更新：
slice
-
view
(2010/05/30)
同期できない．というか進まな過ぎる．
オブジェクトの内部変数が相手側と食い違ったら，一定規則に従ってどちらの結果を優先するか決めて
片方に合わせる．
この時爆発などのエフェクトを伴っていたら当然そのエフェクトはなかったことにしたい（即削除）し，
別のオブジェクトの変数を参照していたり変数を書き換えた場合に接合性が崩れるので
つじつま合わせの小細工を色々とする．
これまでのアクションを巻き戻したら今度は相手から送られた情報に従って再度アクションを実行しなおす・・
...と，そんな感じの処理をやろうとして詰まっている．
依存関係を考え始めたら思考が収束しない．
例えば循環参照していたら？
アクションの履歴が古すぎて既に削除されていたら？等
オブジェクトの内部変数が相手側と食い違ったら，一定規則に従ってどちらの結果を優先するか決めて
片方に合わせる．
この時爆発などのエフェクトを伴っていたら当然そのエフェクトはなかったことにしたい（即削除）し，
別のオブジェクトの変数を参照していたり変数を書き換えた場合に接合性が崩れるので
つじつま合わせの小細工を色々とする．
これまでのアクションを巻き戻したら今度は相手から送られた情報に従って再度アクションを実行しなおす・・
...と，そんな感じの処理をやろうとして詰まっている．
依存関係を考え始めたら思考が収束しない．
例えば循環参照していたら？
アクションの履歴が古すぎて既に削除されていたら？等
(2010/05/22)
どうにも気合が入らないのでweb拍手のメッセージ読み返したりして無理にでもやる気を起こす．
通信プログラムのバグは再現性が不確実というか
一方にブレークポイントかませても，当然もう一方が動いたままなんで
ここで変数の確認をしてから次へ進むという事ができない（できるの？）
マルチスレッドだとデバッガが全てのスレッドを止めてくれるのだが・・
通信プログラムのバグは再現性が不確実というか
一方にブレークポイントかませても，当然もう一方が動いたままなんで
ここで変数の確認をしてから次へ進むという事ができない（できるの？）
マルチスレッドだとデバッガが全てのスレッドを止めてくれるのだが・・
リアルタイムなゲームで片方が動いたままだと一回ブレークした時点で
足並みが崩れるわけでその都度最初から走らせるという事態に．
これではデバッグ効率が悪すぎる．何か良い手法はないものか．
足並みが崩れるわけでその都度最初から走らせるという事態に．
これではデバッグ効率が悪すぎる．何か良い手法はないものか．
(2010/05/20)
見ての通り，最近は勇んで配信開始はするけどすぐ力尽きるパターンが多い．
進む時は進むのだが集中できない時は全くダメ．
そんなのを繰り返してるうちにもう20日だろ～
中々厳しいな・・
進む時は進むのだが集中できない時は全くダメ．
そんなのを繰り返してるうちにもう20日だろ～
中々厳しいな・・
今はまってるのは複数オブジェクトのタイミング合わせ．
pongもどきの例で言うと点数が入ったらパドルとボールを初期位置に戻してサーブから始めるところの細かい処理．
いや，乱暴に言えばどっちのPCの結果を優先するか決めてそっちでバッと上書きすれば終わりなんだけど．
ところがどっこい，こちとら各オブジェクトを個別にパケットやり取りさせてるもんで
彼らを互いの行動経過を混同する事無くタイミング合わせるなんぞ
シングルスレッドとマルチスレッドの関係みたく面倒くさい．
pongもどきの例で言うと点数が入ったらパドルとボールを初期位置に戻してサーブから始めるところの細かい処理．
いや，乱暴に言えばどっちのPCの結果を優先するか決めてそっちでバッと上書きすれば終わりなんだけど．
ところがどっこい，こちとら各オブジェクトを個別にパケットやり取りさせてるもんで
彼らを互いの行動経過を混同する事無くタイミング合わせるなんぞ
シングルスレッドとマルチスレッドの関係みたく面倒くさい．
何で一回で全部送信しないのか．それは同期するオブジェクト数が30や50と増えていった時に
いちいち全部の変数情報を受け渡ししていたらパケットサイズが膨らみすぎると思ったから．
アクションがあったオブジェクトの変数だけをやり取りするのが自然だろうと．
更に言えばFPSでサーバがクライアントに場面情報を送る際に
本来そのプレイヤに見えない変数を含めて全部送るわけにもいかんだろうと踏んでだ．
いちいち全部の変数情報を受け渡ししていたらパケットサイズが膨らみすぎると思ったから．
アクションがあったオブジェクトの変数だけをやり取りするのが自然だろうと．
更に言えばFPSでサーバがクライアントに場面情報を送る際に
本来そのプレイヤに見えない変数を含めて全部送るわけにもいかんだろうと踏んでだ．
パケットサイズに関してもしいっぺんに送信して重けりゃ数フレームおきとか，
数フレームに渡ってちょっとずつという手もあるにはあったが
そうすると通信回線以外の余計なラグが生じる．
60fpsのゲームで1フレーム毎に送受信すれば，相手に情報が届くまでの遅延は(0～16ms)*2 + pingだが
もし5フレームおきに送受信すれば(0ms～80ms)*2 + ping分の遅延が起こり得る
（もちろん16msは正確には16.66666・・msだけど細かい突っ込みはナシで）
数フレームに渡ってちょっとずつという手もあるにはあったが
そうすると通信回線以外の余計なラグが生じる．
60fpsのゲームで1フレーム毎に送受信すれば，相手に情報が届くまでの遅延は(0～16ms)*2 + pingだが
もし5フレームおきに送受信すれば(0ms～80ms)*2 + ping分の遅延が起こり得る
（もちろん16msは正確には16.66666・・msだけど細かい突っ込みはナシで）
実際にはwinsockを別スレッドで動作させており受信は1フレームごとにまとめて受け取るし
送信は割り込み処理を使ってNICの準備が出来次第即送信されるように作ったからもう少し速いかと．
要は自分の納得いく通信プレイがしたい．お粗末様でした．
送信は割り込み処理を使ってNICの準備が出来次第即送信されるように作ったからもう少し速いかと．
要は自分の納得いく通信プレイがしたい．お粗末様でした．
(2010/05/07)
なんだろう，一体バラして組みなおそうと思ったらどう組んでいいのかわかんなくなったような状況．
進捗ないけど現状報告ということで．
図に描いてみたりメモ帳でひたすら思案してみたりと頑張ってはいるハズなんだが．
メモは増える一方ソースコードは触りもしない日が続いている．
にしても正直こんなにも作業が進まないと嫌になってくるな．のれんに腕押しとは正にこの事か．
進捗ないけど現状報告ということで．
図に描いてみたりメモ帳でひたすら思案してみたりと頑張ってはいるハズなんだが．
メモは増える一方ソースコードは触りもしない日が続いている．
にしても正直こんなにも作業が進まないと嫌になってくるな．のれんに腕押しとは正にこの事か．
でも這ってでも先に進まないとゲームが完成しない・・
きっとみんなの拍手が足りないんじゃないか！（戦隊物のステージ風
そうだ，(前日の拍手の数 x 10)分間はどんなグダグダになっても作業画面を配信しようか．
なんて思ったりする．とりあえず今週Onlyで．
きっとみんなの拍手が足りないんじゃないか！（戦隊物のステージ風
そうだ，(前日の拍手の数 x 10)分間はどんなグダグダになっても作業画面を配信しようか．
なんて思ったりする．とりあえず今週Onlyで．
(2010/05/04)
再び組みなおしの悪寒．
ちゃんと仕様決めてから組み始めた方が圧倒的に速いということは身に染みてわかった．
しかし途中で「ああ，これじゃやっぱ駄目だ」と気づく場合もあるしなあ．どうすれば．
じっくり練って試行回数をなるべく少なくするか，どうせ作り直すんだと踏んでその分ちゃっちゃと潔く古いのを捨てるか，どっちが（略
そんな事を想いつつ寝る．眠いから今日は仕様だけメモ帳に書いて実装はまた明日だ．
ちゃんと仕様決めてから組み始めた方が圧倒的に速いということは身に染みてわかった．
しかし途中で「ああ，これじゃやっぱ駄目だ」と気づく場合もあるしなあ．どうすれば．
じっくり練って試行回数をなるべく少なくするか，どうせ作り直すんだと踏んでその分ちゃっちゃと潔く古いのを捨てるか，どっちが（略
そんな事を想いつつ寝る．眠いから今日は仕様だけメモ帳に書いて実装はまた明日だ．
(2010/05/03)
pongのクローンゲーはもうちょっとかな．
1人用のゲーム作って後から拡張した方が速いのか，最初から通信前提で組んだ方がいいのか，どっちがいいんだ？
そんな事を思いつつ作業．
ひとまずはパケット通信量を考えず定期的に内部変数を全て送受信する方向で作ってみている．
折角だし完成したら簡単なルールを追加してみようかね
1人用のゲーム作って後から拡張した方が速いのか，最初から通信前提で組んだ方がいいのか，どっちがいいんだ？
そんな事を思いつつ作業．
ひとまずはパケット通信量を考えず定期的に内部変数を全て送受信する方向で作ってみている．
折角だし完成したら簡単なルールを追加してみようかね
