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

(2009/01/02)

さて、新年です。
FPSと関係ないけどSTGの動画作りました。
あと動画リストをFPS関連とその他にページを分けました。混ぜるな危険。
今回初めて前々から挑戦して見たいと思っていたNiVEを使ってみました。
これから色々機能を覚えていければいいな。
時々不正な処理で落ちるけどムービーメーカーがそれ以上に落ちるので気になりません。
今回の場合で言うとNiVEは3回だけどムービーメーカーは20回くらい落ちたと思います。
で、NiVEは何処で使ったかっていうと序盤のフィルムの穴が上から下に流れてる箇所ですね。
音楽とタイミング合わせるのが面倒だった・・・

今後FPSかSTGかどうしようか悩み中

(2009/01/06)

まだFPSかSTG一本にするとは決めてないけど・・・・同時進行するかもしれない。
どっちか片方だけだと片方煮詰まったときに何も作業が進まなくなってしまう
それ以前に自分が飽きるっていうのもあるし。

何はともあれFPSの現状確認していた。
しばらく触ってなかったから微妙に他人のソースコード化している様子。
敵が適当に撃って来て追って来るまではできてる。
着弾音と足音が表面の材質によって変わるのも実装済み。
射撃の的が出てきて移動するイベント処理も一応動く。って事は後は

• 半分までしか描いてない的グラフィックを完成

あと

• 敵の生成ルーチンを整理して「この敵をこの場所に生成して」って指示したらポンッってその敵が現れる処理
• 敵を撃ったら（現時点では）単純なHP管理して0になったら倒れるモーション再生

以上を実装すれば一区切りっぽい。

それはそれとして
問題点は前から気になってたけどあれだ、
ランダムマップ前提だからアプリケーション起動時にライトマップとBSPを計算する仕様なのだが
ちょっと複雑なマップで繰り返しテストプレイしようとすると毎度待たされて泣ける。
恐らくリリース時には必要ないが事前に計算したライトマップを読み込む機能をつけねばなるまい。

(2009/01/08)

最近は作業用BGMや
ちょっとあのゲーム気になってるんだけど実際どうなの？体験版やるのメンドイし
って感じでゲーム動画をチラ見したり・・くらいしか利用してないニコニコ動画ですが

たま～に「描いてみた」系の動画を見てみたり。（具体的にどれかはなんとなく伏せておく）
だんだん絵が出来がってくのがテレビなんかでよくある、植物の成長を高速で見てるようで面白いな
絵がうまい人とか見てると皆さん製作時間が概して短い

ふと、本物のプロの条件って専門の技術があるのは当然として
素早く作品を仕上げられるとこだよなあと。
普通の人から見て大変そうな事をサラッとやってのけてしまうような。
そんなことを思ってました。

(2009/01/09)

銃の構え方とか立ち回り(?)にセガール映画が
参考になるとかなんとかってのを風のうわさで聞いたので
昨日やってたDAKKAN(奪還)をHDDレコーダに録画予約しておいた。
なんか日本語変だな、まだ見てないけど録画しておいたでいいのか。
せっかくゲーム作るのに中途半端だとなんかヤダし・・・

(2009/01/12)

スクリプトの構文解析部分をバグ取り&機能拡張
今までスクリプトっていっても単に構文解析して数値計算とかデバッグメッセージ表示できるだけの
「実装してみた」だけの機能しかなかったが今回文字列ベースのメッセージを
オブジェクト間で送受信する関数を追加したので少しはマシに・・・なればいいなあ！

あとはデモシーンというか主人公視点から変更する
たとえば監視カメラの視点に切り替えるような仕組みを作ってます(進行形)
そうすると多分主人公のモデルと主人公視点の接合性が問題になってくるかな～と。
かの有名なN64のゴールデンアイの対戦では普通に
自分視点の銃の方向と他人から見た銃の方向がズレてましたけど・・
いやあれは画面分割で相手の画面が見えるからはっきりズレがわかるだけで
今作ってるのだと仮に対戦できるとしても別々のディスプレイだから問題ないか

まだ設定考えてないけど主人公がPDAみたいの持ってて
監視カメラとか砲台を乗っ取ったりできるとかするとズレが気になるかもしれない

(2009/01/13)

敵のアルゴリズムってスクリプトで制御した方が
自由度があってよさそうだな～なんかそれっぽい(?)し
とか考えたので仕様を考えてみたり。
関数一つで敵(主人公)から見えるか判定とか
撃ったり指定座標まで壁を迂回して移動したり出来れば
敵を作成するのがきっと楽になるハズ

(2009/01/16)

STGの話。自分用のメモなので所々意味不です。

弾丸の挙動制御に前々から気になっていたのもあってBulletML使ってみようかと調べていたけど
しばらくした後、アレはどう見ても弾幕STGじゃない事に気づいた。
突進してきたりミサイルとか追尾レーザーとか撃って来ないとなあ
やっぱ自前データ構造でやるか・・・
ボスと中ボスクラスの敵は画面上に多くても3体までしか出ないだろうという前提で
スクリプト制御で動作させる。
ボスが使うレーザー＆ミサイル攻撃の射撃ルーチンも同じく。
一度に数でないなら多少動作が遅かろうが関係ないだろうし。

次。雑魚敵並びに細々したいわゆる通常弾はあらかじめC++側で制御クラスを作っておいて
スクリプト側でゲームエンジンに「この弾丸をこの場所からあの方向へ発射」するとメッセージを送れば
後は勝手に処理してくれるように作る。
弾を撃つ時というのは長くても数フレームなのでこれもスクリプトで撃たせてもいいだろうと。
弾丸の動作だけは画面内に大量に存在する時の事も考えてC++で記述、描画もまとめて一回でやると。
ちなみに描画に関しては自機が撃つハンターも同じような実装になってる。

こんな感じか。

(2009/01/22)

マイクロスレッド周りのバグ取り。
マイクロスレッドとは要するにノンプリエンプティブなスレッドもどきである。
プリエンプティブはOSが勝手にCPU時間をスレッドに割り振るが、
ノンプリエンプティブはスレッドが自発的にCPU時間を他のスレッドに引き渡す。
プリエンプティブだと何時切り替わるかわからんので面倒臭い。（ってか面倒くさい所じゃないらしい）
何でこんなの実装するかっていうとゲームでノンプリエンプティブなスレッドを使いたいからである。
その辺の細かい話は別にいいか。

自分が実装しているマイクロスレッドは自分が欲しいと思う機能を追加する過程で
内部で「ちょこざいな」事をしているので、よくVisual C++ 2005のデバッグ支援機能の
スタックチェックとかバッファオーバーランチェックに無実の罪で引っかかってしまうのである。
手っ取り早いのはこれらの機能をOFFにしてしまう事だが、それだと他の所もOFFになってしまって
非常によろしくない。
(幾つかは特定の場所だけOFFにできるが)

で、今日はそんな
バッファオーバーランのチェックルーチンの目をなんとかごまかそうとアセンブラとにらめっこ。
スタックポインタをいじくってみたりチェックに使ってる変数をどっかにコピーしといて
自分の処理が終わったら何事も無かったかのように元に戻しておくとか色々。
ちょっと「自分は一体何をしているんだ・・」感がしながらも、
とりあえず処置OKかなといったところ。

(2009/01/24)

(C/C++)言語で関数の名前を指定すると関数ポインタが取得できるはずなのに
デバッガで見れるアドレスと実際にポインタ変数に渡されてるアドレスが違う・・・
なんでやねんなんでかなって見てたらVisualC++のdebugビルドでは一旦別のアドレスにジャンプしてから
改めてジャンプし直すコードになってるのが判明（っていうか自分が知らなかっただけ）
よくわからんけどデバッガで追跡しやすくするため？

(2009/01/25)

先日マイクロスレッドのバグを取ったとかなんとか書きました。
でも、ぶっちゃけあれ半分ウソです。
あの記事書いた後に色々テストしてたら幾つかの問題が噴出したので。
さらにぶっちゃけますと、こんな苦労して実装してもあんまり使われない機能な気がします。
もっと動作を制限して単純に実装するのがプロだと思います。
わかってて何でやるの？って声が聞こえますが。

自分で言うのも変ですけど、諦めが悪いんですよ(ただし諦めないと決めた物限定)
例えくそげーでもやると決めたらとことんやります
一人ゲームセンターCXみたいになると言えばわかりやすいでしょうかね

(2009/01/27)

もうかれこれ5日間自作スレッドがどうのこうのやってますが、ようやく目処がつきそうです。
今日中に、多分。
終わったら何しようか。そういえば次にする事を考えてないなあ。

追記：
スレッドのバグ取れたと思う
結論から言って単純ミスでした。
苦戦したバグほど実はパラメタの設定ミスってるか
保存しとなきゃいけない変数の退避忘れてるとか、そんなパターンが多いな・・
今回は後者でした。
初めてのメモリのダンプまでして調べたのに、書き加えたのは3行っていう。

(2009/01/28)

リソース管理クラスのバグフィックスとモデリングを少々。
ゲーム作っていくうちに徐々に扱うファイルが増えていく過程で見つかったバグ。
ってか今の所ファイルは使うときにその場で読み込んでるから大きいファイルを開くときに一瞬止まってしまうダメダメ仕様だ。
音楽のストリーミング再生もできてない状態。
普通はゲーム開始時にまとめて読んで、必要とされるメモリも事前に確保しておいて
ゲーム中は一切ファイル読み込んだりメモリの確保しないですよね。

近いうちに
まとめてファイル読むようなリソース管理の仕様を考えるのと
メモリに読み込んで置けない大きいファイルの非同期ロードの仕組みを考えなければならんか。

(2009/01/30)

スクリプトのメモリ管理をチョンボしてたのでメモリの確保/開放ルーチンを少し手直し
そしたら微妙に速くなった。デバッグビルドで速くなったってあんまりうれしくないが。
同じくスクリプトのグローバル変数があるケースで共有されてしまうバグ発覚。
これも修正。
その後はモデリングのリハビリ。
Jerichoをどんな手順でモデリングしたか忘れたので（っていうか最初スプライン曲線で作って後でローポリ自動最適化みたいの掛けて、最後に手直しという非効率的な作り方だったような？）
最初から六角大王とかみたいにローポリっぽく作っている。
メタセコは昔使ったことあるけど記憶の彼方。
なれないせいかちょっとカクカクが目立つが後々直すとして。
前よりは短い時間でモデルが出来ている様だ。
小道具ぐらいはサクサク作れるようになりたいものである。

(2009/01/31)

一月ももう終わりですね。
テクスチャやサウンドファイルをゲーム開始時に一気に読み込む仕組みを考えておりました。
リソースをテキスト形式で[1行につき1ファイル名]という記述をしたファイル、
リソースブロック（命名：自分）を読み込むとファイル内でリストされているファイルを
順次読み込んでくれる様なクラスを作ろうと思ってます。
リソースブロックは他のリソースブロックを外部参照できるようにして
共有できる物は共有して無駄なファイル読み込みを防ぐ感じで。
FPSだったらステージ毎にブロックを分けて
そのステージでしか使わないファイルをまとめておくとかですね。

でも今自分が作ってるのはステージの概念が無いので
エリア移動のタイミングで読み込みが入る形になるかな。
ハーフライフですね。
もっと色々なFPSを知ってると良いんですけど、FPSボキャブラリが無くて・・

まだ考えが完全にはまとまってないけど。
先ほど詰まらない会議と同じぐらい凄い眠気を催して2時間も寝てしまったのでその分って感じでこれからボチボチ実装してこうかと。