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

(2009/12/31)

うむ。全然実装できてない。やってみたら駄目じゃん状態。
今年は最後の最後までこんな調子だったなあ。
先日の状態変化の例で言えば実はあれはヨーグルトじゃなくて
牛乳にレモン汁たらしたらヨーグルトみたいになったみたいな感じか。どうでもいい。
まあ頑張るさ。

(2009/12/29)

作業再開。物質の状態変化で言うなら液状だった設計構想が
ようやくヨーグルトくらいには固まったので現在、試行錯誤しながらプログラムに手を加えている。
この調子で年越しまで作業してひと段落させたい。是非させたい。

重ねて申し上げますがメモリ管理がテキトーな関係でテストプログラムは無理っす。
メモリリークは朝飯前だし単独でメモリを600MB食ったりしてるレベル。
いくら自己責任でとはいってもプログラムの造りが明らかにマズいですから
そんなのを公開なんて考えられんのです。

(2009/12/26)

プログラム的な進展なっすぃんぐ。
ああでもない、こうでもないとテキストファイルに駄文が溜まっていく・・
今年中に実装に取りかかれる目処さえ立ってないという。
別に年が変わろうが関係ないといえばないが
年末の大掃除の如くキリがいい所まで進めて新年を迎えたい気はする。

(2009/12/23)

マズルフラッシュの点光源は諸処のトラブルがあったが解決した。
頂点単位の色計算なんてレトロだなー何年前だろうと思いつつ。10年前くらい？まあいいか。軽いのが一番だ。
今はまだ試してないけどテクスチャベースの光源も関数呼べば出来ると思う。
次は敵が銃を撃ったときの反動をやろうとしたら全然進まない。
それもそのはずで敵の設計が適当なのだ。
どうやら放置してきた敵キャラクターの動作問題をきちんと対処しなければこれ以上先へ進めないようだ。
思案中なのでまた時間かかるかも・・・

(2009/12/21)

敵キャラに銃を撃たせたいが、やるべき事が沢山ある。

• 上半身だけ向きを変える
• 銃を目標へ向ける
• 下半身と上半身の向きに制限をつける
• 点光源でマズルフラッシュの表現
• 射撃の反動を表現

上から2つは終わった作業、下の2つはまだの作業。真ん中のは途中の作業だ。
これを敵との対戦形式にしたいとなるとやる事が増える。

• プレイヤ側と敵側それぞれ所持アイテムの管理(弾薬や武器など)
• 敵のリロードの動作
• 敵の行動選択(AIみたいなの)
• プレイヤ&敵キャラ本体の当たり判定と体力管理とやられモーション
• ゲームの開始、終了処理
• アイテムを散らして配置する処理
• 簡単なランダムマップアルゴリズムの考案

更にこのプログラムを公開するには

• ちゃんとメモリを開放する
• 手抜きの固定長配列をやめる
• 描画パスをきちんと管理する

という作業が必要だ。
さて軽く眩暈がしたところで、すぐ出来そうな作業から1つ1つ潰していこうか。
まずマズルフラッシュの点光源なんかはすぐ出来るだろうな。
次は銃の反動。座標を振動させるだけの予定（あくまでも予定。つ～ことは途中でトラブって時間がかかるという）
一先ずそれが完了したら次の記事を書いてまた優先順位を考える。

#追記

先読み方向指定は曲がり角に壁がある場合と無い場合（崖の上とか）で
動作変えるべきかとは思ったけど、今は無視。理由はめんどいから。

(2009/12/20)

先日実装した先読み方向指定はうまく動いている。
いや・・よくよく見ていると方向転換が早すぎるか。
実際のマップでテストすると当然ながらセグメントの長さはまちまちで、
それを考慮せず割合だけで方向を決定すると先読み角度のバラつきが出てくる。
セグメントの長さと曲がる角度を考慮せねばなぁ。計算式をあれこれ弄ってそれっぽくなる関数(?)を探す。

#追記

2次のBスプライン曲線を利用することでそれっぽい挙動を得られた。
と、こう書くと難しいことをしてそうにみえるがググって式を引っ張ってきて組み込んだだけ。
(式の理解は今は重要じゃないので)

これから細かいバグつぶしやるかな～

(2009/12/18)

要は壁の淵を撫でるように視点を操作するだけの話なのだが。
FPSじゃなくても普段の生活で通路を曲がる場合、頭の向きは図のようにわずかに先を向いていると思う。
これは向こうから歩いてくる人や障害物を少しでも早く察知するために自然な事である。
逆に常に進行方向へ頭が向いていると、廊下を90度直角に曲がる几帳面な人(?)のようになり不自然だ。
FPSだと角の近くを避けて少し大回り気味に移動するが、一先ずは簡単の為に最短パスを通る条件で考える。
サイドステップ気味になるのもナシで。あと昔のゲームだと常に主人公の方へ向けているのもあった気がするがここでは真面目にやる。

こんな感じか。
さて、ゲームなのでどうやったらいいか理論とかは無視して考える。
まず思いつくのは2つ先のWPの方向けておけば良いんじゃないか？ということ。
しかし曲がり角が鋭角だと右の図のように壁を凝視するマヌケな結果になる。

ならば0と1が駄目ならその中間って事で
現在歩いているWP間の経路1区画分（セグメントとする）の
現在地の進行具合を0から1として、1つ先のセグメントで同じ割合の位置を計算し
そこを見つめるというのはどうだろう。

これだと先ほどの鋭角な曲がり角でも上手く動いてくれそうな気がする。
そんな訳で実装してみよう。

(2009/12/17)

移動パスの最適化については終了。
先日書いたような手順でうまく動いている。今のところは。
アレ以外にもスマートなアルゴリズムはもう一つ考え付いたが今のソースに付け加えるのは困難と判断し
ソース中にコメントでメモだけ残して見送り。
今は上半身の方向を操作してカッティングパイしたいなあと画策している段階である。
明日あたりまた図を使って茶を濁すか。

(2009/12/15)

敵の移動パスについてまだぐだぐだと。このページ初の画像使用。

こんなマップがあったとして、黄緑のひし形がウェイポイント(以下WP)だとする:左図
これらのWPを経由すれば直線でマップのどこでも歩いていける。
右図のようにマップ上の任意の座標、この例では緑の点から黄色の点に移動する際にはまず最寄のWPを探す。
するとそれぞれの色枠で囲んだWPが該当し、WP間の経路探索に入る。
一見して緑の最寄WPが目的地と反対側にあるので後戻りしそうだが、
そこは「最初の座標から2番目のWPが直線移動可能な場合、1番目は省略する」という処理を施しているので問題ない。
（終点に関しても同様の処理を行っている）
最終的に白の点線のような経路パスを得る。ここまでは問題ない。しかしこの場合はどうか？

結果のパスが回り道をしている。本当は右図のようになって欲しいのだ。
見ての通り「最初の座標から2番目の～」が適用できない。
経路探索結果に入っていない他のWPを、
何らかの方法でより最適なWPが無いか調べる必要があるのは明白である。

まず考えたのは始点（終点）から直線移動できるWPで、2番目のWPに近い物を選ぶ方法。

でもよくよく考えてみたら最悪の場合、このようになってもらっても困る。(左図)
じゃあと　始点 => (中間WP) => 2番目のWP　までの距離の総和が一番小さいWPだと行けるかもしれない(右図)
これで実装してみようかと思うが、スパゲティコードなので苦戦しそうだ。

(2009/12/14)

そういえばライトが破壊された場合は周囲も暗くしたいよね、
太陽なんかの平行光源も欲しいねという欲求を押えつつ
敵の動きをスムーズにする作業に入る。
現状だと敵の移動パスが回り道ぽくてスマートとは言いがたいからだ。
あと曲がり角を曲がる時は、上半身はある程度曲がった先を向いているべきだよねとか。
カッティングパイていうんだろうか？
あ、でも部屋に入る前に部屋の外から見える範囲を最大限確認する作業はまだいいや。面倒そうだし。

(2009/12/13)

一応透過はできてる。けど半透明の窓が重なった場合と
透過光が別の不透明ポリゴンによって隠された際の影の処理が不完全である。
画像だとわからんけど影になってはいるが色は付いているという状況。
前者は改善すると重くなりそうなので「窓は何枚も重ねるな」という仕様として無視してもいいが
後者はイカンな。直さねば。

#追記

相変わらず何枚も重ねるとおかしくなるけど先ほどの問題は解消。
あと半透明のポリゴンの背後に壁が全く無いと影になってしまうアフォなバグも直した。

(2009/12/12)

α抜きは出来たので次のステップへ進む。
半透明の窓の透過光を再現したい。ステンドグラスがあったら絵を壁や床に映り込ませたいのである。
またひと悶着ありそうだが早速取り掛かる。

(2009/12/10)

今更ながらシャドウマップをα抜き対応にしようと思った。
対応してないと金網のテクスチャ使っても影が出ないので微妙すぎる。
まあ単にαテスト入れりゃいいんだろと高をくくっていたらところがどっこい
深度マップ描画の高速化の為に頂点情報は位置だけ（テクスチャ座標無し）として
全てのマップポリゴンを前処理で1つのバッファに全部纏めてたりする。
コレは困った。

マップを構成するポリゴンの中で圧倒的に多いのが不透明ポリゴンなので
それを1つのバッファに纏めて描画するのは自然だ。テクスチャも要らないな。
とするとα抜き有りのポリゴンだけ後で別途描画すればいいのか。
考えていると欲が出るもので半透明の窓も入れたくなる。（例えば青いガラスだったら光に色を付けたい）
しかし深度マップのフォーマットにはG16R16を採用しているし、今回変更する範囲以上にそれように作りこんでる部分があるので
透過色を入れる為だけにわざわざフォーマットまで変えたくない。

深度は深度でα抜き処理だけ適用、GPUで光が遮られるかどうか(と影の濃さ)だけチェック、
その後CPU側で1枚ずつ半透明ポリゴンと衝突判定を行って透過光の明るさと積算すれば
実現できるかなあ？

(2009/12/09)

飛び降りポイント設置の不具合が発覚してからはや3日。
ある機能を実装しようとしたら他の部分に不具合が見つかって進まないのはよくある事だ。
アルゴリズムを最初から考え直しもうちょっとで直る予定。
現状同じ場所を何故か2回走査して全く同じ位置にダブってウェイポイントを設置してしまうけど、
どっかで単純ミスしてるっぽい。