進捗状況(2010/03) - FPSを作ってみる@wiki

(2010/03/30)

まあそんな感じか．あとは置ける場所が無いときにパスボタンを表示すれば終わりな雰囲気．

(2010/03/28)

接続認証処理から通信開始までの間にこける現象がたまに発生する問題を今まで放置してきたが多分解決．
WSAWait系関数で複数のイベントを待ち受けたらシグナルが来た時に
戻り値のインデックス1つしかチェックしてなかったが
コケる時っていうのは恐らく同時にシグナルが来てるんだろうな．
ということで単純にループ回して全部のイベントをチェックするようにした．

(2010/03/25)#2

近況．テキストで思案ばかり．

今書いてるプログラムが一区切りついてから～なんて長い事放置していたvisual studio 2008を2005と入れ替えインストール．
そんな事言ってたら何時まで経ってもできないわけで．
環境が変わった時の手直しについては気合で頑張るしかない（といっても何も無さそうだけど）
常時接続だしオンラインのだけで十分と思っていたMSDNもインストールしておこうかと．
たまに回線が重くてもたつく時があった．
でも一番の理由はブラウザを開くことによってふと目に入った気になるリンクをクリック，あらぬページへジャンプして本来の目的を見失うのを防止する為だったりする．
他にはソースコードエディタの描画が何故か2005は2003と比べて遅いのが気になったのもある．
2008はどうかな？更に重くなければいいが．

(2010/03/25)

リアルタイムゲームの同期はまだ考え中．机上の空論レベルで仕様がまとまって来たかといった所．
結果だけ見るとA4ノート半ページに収まっちゃう勢いで「数日間考えて，これだけ？」と言われそうだが・・
実装しようとするとボロボロと穴が見つかるんだろうな～

やる事を整理しよう．
まずターン性ゲームの方をちゃっちゃと形にして区切りをつける．（ネタバレするとリバーシを作ろうと思ってる）
次に簡単なリアルタイムゲームを作ってみる．
これも腹の内を明かすと第一段階としてPONGのクローン，そこから発展させて上から視点のシューティングゲームをやろうかと．
シューティングといっても戦闘機のではなく人を上から見た絵が自機でマウスカーソルの方に銃口が向く
最近の例だとshadow groundsみたいなタイプだ．
P2P形式で通信プレイやるのはそこまで．というのも3人以上だとまた制御を考えねばならん気配なので．

更にその後はPONGか上から視点シューティングを本命のサーバー&クライアント形式に改造する．
最初からそれで作れという話だけどP2P形式でラグが平等な対戦ゲームも一度やってみたかっただけです．

(2010/03/23)

先日ひょんなことからそれなりなビデオカード買ってしまって
早速積んであったヒットマンやってたりするんで作業が滞りがちに．
で，アンケートにラジオチャットとありますが．
おそらくショートカットから出せる定型文チャットの事ですよね．
（ボイスチャットは別途skypeでも使ってもらうことにして・・）
文字だけなら入れるつもりだったけど・・声なんてある程度ゲームの規模が大きくなってから幾らでもできるだろうし．
L4Dのシステムは中々秀逸だと思うからアレを更に発展されされればと．

作業経過：
○×ゲームの後，急に汎用クラス化したくなりそこまでしてもな～と思いつつもしている．
ターン性の完全情報公開ゲームの主要機能を搭載したベースクラスに，
ルールや描画方法を記述したゲーム盤クラスを渡せばそのゲームが出来るという．
でもいい加減こういう変なこだわり捨てないと．どうせ後々使わないよと．

それと元々リアルタイムゲームの通信プレイをやりたかったのでこちらも同期の方法を検討中．
デバッグ用途に任意の通信遅延を発生させるプログラムを書く必要があるかなあ．
100msとか固定の遅延とある程度遅延の波がある状況を意図的に作り出せないと
実際インターネットを介してプレイした時に安定するのか甚だ疑問である．

(2010/03/18)

思ったんだけどターン性のゲームだったらご大層な通信クラスなんか無くても作れるよね？
チート対策はともかく通信と処理する手順が決まっているのだから例外処理とか要らないよね．
じゃあ何でこんな時間掛けてんだ・・・
リアルタイムゲームへ移行しないとバカやってるみたいだ．はやくなんとかしないと．

(2010/03/17)

例の如く配信の抜粋を追加してみた．
文字が潰れてるし何がなんだかって感じだが雰囲気だけでも．

(2010/03/16)

よく，プログラムがうまく動いた時に快感が得られるから続けられるというが
自分の場合は気持ちいいのは確かなんだけど「やっっっと動いた～疲れたー」という感じで疲労感の方が強い．
まあそれはそれとして．

スクショを見てもらえば分かるように以前から書いていた簡単なゲームというのは○×ゲームの事だったのだ．
言ってしまえばたかが三目並べ，しかもターン性なのでリアルタイムに比べ同期が楽だし
TCPオンリーだからパケットが届かなかった時の処理もしなくていい・・・と
高をくくっていたがそれでもwinsockを使って一から作ると結構な作業量となる．
例えばwinsockのsend()関数で123, 456, 789と3回に分けてデータを送っても受信側も3回分に分かれて受信される保証はなく
ドライバの実装によっては12, 345678, 9みたいに届く可能性もあるのでデータの切り分け作業が必要だ．
もう少しエラー処理を加えてから公開したい所存
その後は練習として別のボードゲームを実装したい．三目の次といったら大体見当がつくかもしれない．
基礎は出来てるからサクッといく予定なんだけど，どうだか．

#ちなみに

以前にTCPを使ってないゲームなど無い等と嘘吐いてしまったがちょっと調べたら
主に大手だとUDPオンリーなゲームもありますな．
とはいっても内部でTCPみたいな再送機構を設けてるだろうし，独自実装はパケット解析されにくいというのもあるだろう．

(2010/03/07)

鬼のように日にちが過ぎる．
肝心のプログラムはというと未だに通信関連を弄っている．
商用ゲームの同期の仕組みってどうやってるんかな？まあそのへんは製品のアドバンテージに成り得るし企業秘密だろうけど．

前回の記事書いた後に実装したのは「オブジェクトの状態のズレ補正」だ．
どういう事かというと例えば各プレイヤがチャット画面からゲーム画面へ移行した後
互いにメッセージ（MSG)をやり取りする処理を書いたとする．
この時一寸の狂いもなく全員同時に画面（ゲーム状態）を切り替えできればいいが
現実的にはどんなに頑張っても1～2ms程度の誤差は出てくる．
するとあるプレイヤはまだチャット画面なのにMSGが届いてしまう．この場合，どう処理していいか困るのだ．

真っ先に思いつく解決策は「ゲーム画面」へ移行した後に数秒待ってからMSGを送る手だが
レスポンスが悪いし，なにより確実性に欠ける．
あるプレイヤはPCの処理が込み入っていて10秒待ってもまだチャット画面かもしれない．
かといってチャット画面の時に受信したMSGを捨ててしまうと
届かなくても影響が少ない物（キャラの挨拶アクションとか？）ならともかく，それはそれで問題だ．

じゃあどうするか．自分が考えた方法は
チャット画面の時にMSGを受け取ったら一旦別のバッファに溜めておいて
アプリケーションに対してはあたかもゲーム画面へ移行した直後にメッセージが届いたように見せかける，というもの．
考え付くまでに結構時間掛かった．
でもまだまだ先は長そうだ．なんせ簡単なゲームさえ出来てないのだから（俺達の通信はこれからだ）