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

(2010/12/31)

自分で言うのもアレだがwikiのタイトルからしてゲームを作ってみてるのか怪しいものだ．
だって最後に動画出したの2年近く前だろ・・・
過去の発言を見返すと何か宣言しても守れてなさ加減が半端ないので
もう「○○します！」とかは辞めた．

来年の目標は自分の中では設定するけどここへは書かない．
代わりにそう気づいてもらえるように行動で示したいと思っている．

皆様，良いお年を

(2010/12/30)

頑張って作ったコードだけど後で良いアルゴリズム思いついてイラネってなるケースが時としてある．今がまさにそうで．
タイルを並べて背景を作る部分にメモリの無駄が多すぎる事が判明．
細かく書いても仕方ないので掻い摘むと現在の実装では毎回タイル毎に頂点を設定して1マスずつ描画すると重いから
最初に一旦全部テクスチャに出力しておいてそれを一枚ポリゴンに貼り付けて表示という手段をとっている．

しかしこの方式は描画速度は恐らく最速であるものの，メモリに背景画像を全部持つ為にマップが広いと問題になる．
RGBそれぞれ8bitそれにαを8bitの場合，256x256サイズでも256KByte要る．
512x512なら1MByteだし1024x1024ともなると一枚で4MByteも食ってしまう．
今のPCならロースペックでもVRAM128MByteとか当たり前だから全く心配要らないものの
幾らなんでも背景だけで使いすぎだろと．背景の重ね合わせ等しようものなら倍，更に倍へと増えていくし．
まあ年内はこれで出す予定だけど（棒人間が動くだけなので期待しないで欲しい）

で，改善策．
ちょっと良く出来たフリーソフトや製品等はこっちの方法で描画してると思う．
表示画面より少し大きいサイズのテクスチャを一枚だけ確保して画面がスクロールする度に
必要な部分だけマス目毎に上書き描画するという物で
早い話がファミコン，スーファミ世代のコンシューマーでやってる方法．
表示部分がテクスチャ端に近づいたらループさせて表示する．
ただこれだとマスの大きさが2のべき乗でないと都合が悪いが <= 全く問題ないな！

自分は変に自由度持たせようとするから結局効率悪くなっちゃうんだよなあ・・・

(2010/12/21)

ひたすらバグ取り．主にLuaの仕様でつまづく．
メタテーブルの__gcはユーザーデータだけ有効かよ，ユーザーデータのメタテーブルはLuaから変更できないのかよ等．
ていうかメタテーブルは面白い機構であると同時にCのオーバーロード以上にバグの温床になる．
特にメタテーブルの主要なメソッド，__indexを指定した後は変数の参照や書き換え時に常にメタテーブルを意識する必要がある．
（でないとあらぬ変数を書き換えたりエラー吐いたり）
やればやるほど無理やりオブジェクト指向してる感がひしひしと．
本来Luaはそんな複雑な用途に使うもんじゃねえよという声が聞こえてきそうだし
こりゃSquirrelに浮気するのも無理ないな・・・あっちはクラスをサポートしているし整数も使えるなあ．

関係ないけど配列の添え字が1からっていうのはすぐ慣れた．これに関しては特に文句なし．

と，なんということだ！こんな調子じゃ何も出せぬまま今年が終わるではないか．
「残り10日」

(2010/12/16)#2

うむ．大体組み換え終わり．
ついでにインラインアセンブラでこちょこちょやってた部分も一掃され前よりは保守性の高いコードに．
まだ動かない部分があるがこれはまた明日直すとしようか．

(2010/12/16)

前々から気になってたシリーズ．LuaとC++の互換関数の動作が遅い．
どんくらいかっていうと2Dの画像をカーソルキー上下左右で移動＆描画させるだけのプログラムに
CPU時間の15%も食っているレベル．デバッグビルドとはいえこれは流石に不味い．
（ちなみにLuaからC++の関数を呼ばずに黒画面の描画だけだと2%）
原因は呼び出しの度に引数の数分メモリをnewしてるから．
事前に引数の数や形式を専用関数を呼ぶことでリストアップしておいて毎回それを参照しながらどんな変換処理かますかを振り分けているのである．
関数の引数や型なんてものはコンパイルした時点で決まっているのに
何故回りくどくて無駄な事をしているかといえば当時は手探り状態だったからとしか．

C++のテンプレート構文を駆使すればコンパイル段階で固定のメモリと変換処理をかませそうなので，今そうしている．
戻り値がvoid型の場合の例外処理とかで小細工が入る入る．冗長なプログラムコードがくわわる　くわわる．
しかし全ては速度の為・・・っ

(2010/12/14)

全面的にスクリプトを取り入れたことでゲームロジックを簡単に変更できてコンパイルの手間いらずだ．
しかし気が付いたらスクリプトでスクリプトを作っているような状況に悩んでいる．
原因は「他の人にも理解しやすく記述も簡単」など欲張りすぎで
「自分用ゲームエンジン」で踏みとどまるべきなのだろう．
どこまでをC++で実装してどこからをスクリプトにするかの境界も曖昧だ．
（今のCPUならAPIを呼び出す部分以外は全部スクリプトで書いても動くとは思うが）

まあそれはそれとして・・
いくら自分用とはいえ描画や衝突判定の手数とか決まり事が多いなーというのが正直な感想．（だから悩んでいるとも言う）
帯に短し襷に長しとは正にこのことよのう．

という中途半端なエントリでした．

(2010/12/10)

5年前の自分に言いたい事．
「まず2Dでゲームを1本完成させろ」
恥ずかしながら今まで本格的にゲームを完結させた経験がなく
マップやキャラクターをどのように管理するかというのを殆ど考えてなかったのでここで詰まっている．
動画やサンプルみたいな，とりあえず動けばいい用途だとひたすらif文で処理を並べて
データなんかは面倒だから固定長配列で，定数もプログラムに埋め込んじゃえ
でわりかしサクッと作れるが所詮はその場限りなのである．

2Dといえどもゲームとしてやることは同じで，それが画像がモデルになり当たり判定が立体的になるだけだ．
いきなり3Dで作ろうとするとまず表示するだけで一苦労，表示した所でもう完成した気分になってしまい
さてじゃあゲームをと思っても組み方でつまづく．
「なんでもいいから1本完成させる」というのは簡単なようで非常に重要だ．

で，今やってるのは横スクロールの2Dアクションゲームを想定して前回のテクスチャアニメーションに続き
タイルベースの背景表示とイベント配置，それと場面進行管理．
表示云々はいいとしてゲームのコアとなるイベント配置と場面進行ですな．
FPSのマップエディタなんかで”エンティティ”(以下Entity)と呼ばれるオブジェクトを扱った経験がある人も居るかと思うが
基本的にはあれを真似てマップに予めプログラム側で定義した”敵を置くEntity”や”スイッチEntity”を
”置く敵の種類”，”スイッチが起動する対象Entity”等のパラメタを付加して配置．
マップ切り替えや会話イベントもそれ用のEntityを起動して行う寸法だ．
今組んでる仕様で上手く動くかどうかは分からないが，ともかくやってみる所存．

(2010/12/05)

2Dベースのゲームを動かすために色々．
といっても3Dでも使える要素は入ってるから「ま　た　道　草　か」のような突っ込みは勘弁願いたい．
例えば2Dアニメーション．要は板ポリゴンのテクスチャを切り替えて表示するだけなのだが中々奥が深いのだ．
アニメーションを単純に実装するとコマ毎に画像ファイルを用意して次々に切り替える，
又は全てのコマをまとめたファイルを1つだけ用意しテクスチャ座標を操作するという
2方式が考えられるが

• アニメーションのループ
• コマがテクスチャサイズに満たない場合の対処(D3Dでは2の累乗サイズのテクスチャしか使えない）
• ホットスポット（コマの中心点）

等々を考え出すと止まらない．

もちろん今作るゲームに特化させて「敵のパラメタはこのファイルにすべて集約，項目も全部決めておく」などとする事も可能だが
自分は現状を見ればわかるとおり2Dスタイルのゲームが作りたくなる時もあればFPSや古典的なシューティング
を作りたくなるそして投げ出す時もあるから
ある程度汎用性をもたせたいわけである．

テクスチャに関して言えばコマの分割やホットスポットなんてのは画像だけでほぼ決まる物なので
だったらと自動的にテクスチャと一緒に関連情報を読み込むようにしてみた．
（テクスチャと拡張子違いの同名ファイル．JSON形式）

これはFPSだとHUDのアニメーションやビルボードによる爆発，煙エフェクトに使えるかと思っている．