FPSを作ってみる@wiki
08)
最終更新：
slice
-
view
(2010/08/21)
元々スクリプトで利用する事を考慮していない描画補助クラス等を，少しの変更で対応できるようにとの願望から
スクリプトで使うクラスとC++で使うクラス構造を一緒にして，
変数リストと関数リストを定数の形で別途用意．
エンジン初期化時にそれを読み込ませてやれば後はスクリプト側でのクラス構築やら変数同期，関数の中継呼び出しを
やってくれる仕様とした．
これでHUDを描画するC++側で定義したHudクラスはスクリプトの中でもHud.create()と記述すれば
エンジン側とスクリプト側でそれぞれメモリ確保し，初期化もしてくれて後始末までバッチリ
（の予定．色んなケースについて検証が必要だ）
スクリプトで使うクラスとC++で使うクラス構造を一緒にして，
変数リストと関数リストを定数の形で別途用意．
エンジン初期化時にそれを読み込ませてやれば後はスクリプト側でのクラス構築やら変数同期，関数の中継呼び出しを
やってくれる仕様とした．
これでHUDを描画するC++側で定義したHudクラスはスクリプトの中でもHud.create()と記述すれば
エンジン側とスクリプト側でそれぞれメモリ確保し，初期化もしてくれて後始末までバッチリ
（の予定．色んなケースについて検証が必要だ）
生ポインタ使ってる関係でクイックセーブ＆ロード機能を追加するときに問題が発生しそうだけど
多分そこまで行き着く前にまた作り直すだろうから放置で行く．
多分そこまで行き着く前にまた作り直すだろうから放置で行く．
他にはスクリプトのテーブルをteble[item]という記述でc++風に参照できるようにしたりとか
Luaスタックを意識せずに済むアダプタ関数の製作．実はまだ両方とも実装途中だけど．
Luaスタックを意識せずに済むアダプタ関数の製作．実はまだ両方とも実装途中だけど．
そんな感じで遅いながらもまあ，進んではいる．
(2010/08/15)
エンジンのリファイン作業は一旦置いてスクリプトの仕様を練っている．
描画のタイミングや各オブジェクトのアップデート処理をスクリプトに移行
エンジン側はどんな関数を用意しておくか・・・等等．
描画のタイミングや各オブジェクトのアップデート処理をスクリプトに移行
エンジン側はどんな関数を用意しておくか・・・等等．
ユーザーが組む時にこんな風かな～と，テンプレートの形で少しずつ手順を定めていく．
現状はこれといって書き記す事がないですね～残念ながら．
現状はこれといって書き記す事がないですね～残念ながら．
(2010/08/12)
作り直しその3「マテリアル・リソース」
名前はご大層だがやってる事はただのINIである．
変数名と変数のペアを羅列した，あのファイル．
変数名と変数のペアを羅列した，あのファイル．
調整が必要なゲーム内パラメタをファイルに分離
変数をゲーム実行中にいじれるようにする．
或いはテクスチャに付随する情報（材質フラグ等）を記述する．
XML形式だったが，複雑な記述は要らないので例の如くJSONに変更．
変数をゲーム実行中にいじれるようにする．
或いはテクスチャに付随する情報（材質フラグ等）を記述する．
XML形式だったが，複雑な記述は要らないので例の如くJSONに変更．
ちなみにマテリアルは他のマテリアルを継承できるようにしている．
要求したエントリが見当たらなかったら継承元のファイルを探すというわけだ．
こうする事で「ここだけ違うけど後は同じ」マテリアルは同じエントリを重複して記述せずに済む．
要求したエントリが見当たらなかったら継承元のファイルを探すというわけだ．
こうする事で「ここだけ違うけど後は同じ」マテリアルは同じエントリを重複して記述せずに済む．
前にこんな感じでウィンドウを出してキー操作でリアルタイムに変更する機構を作ってはみたものの
操作性がイマイチであまり使わなかった・・
操作性がイマイチであまり使わなかった・・
次はサウンドが簡単そうに見えるが
リファクタリングばかりやってるとモチベーションが続かないんで
スクリプトでも組み込んでみるかなー．自分で「おおっ」て思うのが無いと．
スクリプトからリソースを一気に読み込ませたりとかしたい．
リファクタリングばかりやってるとモチベーションが続かないんで
スクリプトでも組み込んでみるかなー．自分で「おおっ」て思うのが無いと．
スクリプトからリソースを一気に読み込ませたりとかしたい．
(2010/08/11)
リソース基本クラス（前回書いたようなもの）の実装完了．一通り動作確認もした．
前まで固定長配列上等，メモリリークなんて知らねー動けば良し的な感じでやってたリソースの管理を
一から見直しソースコードを半分以上書き換えた．
スマートポインタのような仕組みを導入し，誰もそのリソースを所有するクラスが無くなったら解放するようにした．
代わりにリソースの参照が少々面倒臭くなったが・・
前まで固定長配列上等，メモリリークなんて知らねー動けば良し的な感じでやってたリソースの管理を
一から見直しソースコードを半分以上書き換えた．
スマートポインタのような仕組みを導入し，誰もそのリソースを所有するクラスが無くなったら解放するようにした．
代わりにリソースの参照が少々面倒臭くなったが・・
読み取りロックと読み書きロック機構によりマルチスレッド環境等で
裏でファイルを読み込みながらも描画は続けるといった動作が可能に．
（今までは複数のスレッドが同じリソースを同時に参照したらクラッシュしていた）
更にリソースが使用中だったらロックできるまで待ってから制御を返すか
待たずに処理を続行するかを選べるようにもした．
自分で言うのもナンだが力作です．
裏でファイルを読み込みながらも描画は続けるといった動作が可能に．
（今までは複数のスレッドが同じリソースを同時に参照したらクラッシュしていた）
更にリソースが使用中だったらロックできるまで待ってから制御を返すか
待たずに処理を続行するかを選べるようにもした．
自分で言うのもナンだが力作です．
まぁC#やJavaだとガベージコレクタがあって色々と楽な気がしなくもないが！
少々強引にC++で自作する利点を探すとすれば
後幾つリソースを確保したらメモリの再割り当てが起こるかが明確にわかったり
任意のタイミングでメモリコンパクション処理を実行したり出来るとかかね．
少々強引にC++で自作する利点を探すとすれば
後幾つリソースを確保したらメモリの再割り当てが起こるかが明確にわかったり
任意のタイミングでメモリコンパクション処理を実行したり出来るとかかね．
ともあれ，これで以前のような「3回中1回，一般保護エラーで落ちる」「エンジン初期化しただけでメモリ500MByte食う」
事は無くなるはずだ．
事は無くなるはずだ．
ここまできてやっと個別のリソースクラスへ入れるわけだけど
本丸であるゲームのキャラクターを管理するクラスはまた一悶着ありそうなので
まずは移植するだけと思われる簡単なのからこなして行こうと思う．
具体的にはテクスチャ，サウンド，モデル，モーション辺り．
本丸であるゲームのキャラクターを管理するクラスはまた一悶着ありそうなので
まずは移植するだけと思われる簡単なのからこなして行こうと思う．
具体的にはテクスチャ，サウンド，モデル，モーション辺り．
(2010/08/07)
「次に作り直すときはああしよう，こうしよう」と思っていたのが次から次へと出てくる．
今日は例外処理を入れてみたくて，クラスの構造考えてた．
関数読んだ履歴が表示されるといいよねー，
エラーは軽微な物はコンソールにメッセージ出すだけで動いて欲しいな，
メッセージの出力先も標準出力の他にゲーム内ウィンドウへ切り替えしたいよね．等など．
今日は例外処理を入れてみたくて，クラスの構造考えてた．
関数読んだ履歴が表示されるといいよねー，
エラーは軽微な物はコンソールにメッセージ出すだけで動いて欲しいな，
メッセージの出力先も標準出力の他にゲーム内ウィンドウへ切り替えしたいよね．等など．
あとはリソースのマルチスレッドロック機構ですか．書き込みしてる時は1スレッドしかアクセスできないけど
読み込みは複数OKなのとか．
本当はもう個別のリソース管理クラスの再構築に入ってるつもりだったが見積もりが甘すぎた（いっつもそうだ）
読み込みは複数OKなのとか．
本当はもう個別のリソース管理クラスの再構築に入ってるつもりだったが見積もりが甘すぎた（いっつもそうだ）
しょうがないよな，地道に1つずつこなしていくしかない・・
(2010/08/05)
作り直しその2 「モデル・モーション出力形式」
リソースマネージャは各リソースの制御クラスも含めてなので結構範囲広いじゃないか．今気づいた．
とりあえずモデル制御クラスを書く前にモデルとモーション出力形式を改良をば．
早い話が今までXMLだったのを重いしそんな機能要らないから軽いJSONにしようと．
本当は昨日で終わる予定だったのにXMLとJSONをスイッチ一発で切り替えられるようにしたお陰で手間取った．
とりあえずモデル制御クラスを書く前にモデルとモーション出力形式を改良をば．
早い話が今までXMLだったのを重いしそんな機能要らないから軽いJSONにしようと．
本当は昨日で終わる予定だったのにXMLとJSONをスイッチ一発で切り替えられるようにしたお陰で手間取った．
で，今まで左(XML)のような感じでやってたのを右(JSON)のようにした
銃なんかの，薬莢の出るタイミングをモーションのフレーム単位で指定する情報は別ファイルへ移行．
文字数はスペース抜きカウントでXMLが4483文字，JSONが4946文字・・・ておい！増えてるじゃねぇか．
パースは見るからに構造が単純だからJSONが速いんだろうがサイズでかくなってるのは気に食わない．
幸い原因はわかっているので明日にでもちゃっちゃと直して再度比較してみようかと．
文字数はスペース抜きカウントでXMLが4483文字，JSONが4946文字・・・ておい！増えてるじゃねぇか．
パースは見るからに構造が単純だからJSONが速いんだろうがサイズでかくなってるのは気に食わない．
幸い原因はわかっているので明日にでもちゃっちゃと直して再度比較してみようかと．
もちろんファイルはテキスト形式でなくてバイナリ形式が処理速度，サイズ共に有利なのは言うまでもないが
それは可読性（デバッグのし易さ）とトレードオフだし．
リソースマネージャ関連の作業は続く・・
それは可読性（デバッグのし易さ）とトレードオフだし．
リソースマネージャ関連の作業は続く・・
#追記
JSONでの無駄な記述を無くしたら4167文字まで減った．ら，同時にXML形式だと3631文字になった．
まあいいか．きっとファイルサイズも小さいはず！という幻想を抱いていただけだ．
まあいいか．きっとファイルサイズも小さいはず！という幻想を抱いていただけだ．
(2010/08/03)
作り直しその1 「リソースマネージャ」
昨日は自作エンジンのココが使いにくかったからこう改善しようああしようと考えてただけでまだ作業してなかった．
ゲームエンジン基礎の基礎（だと自分は思っている）資源管理から入る．
ゲームエンジン基礎の基礎（だと自分は思っている）資源管理から入る．
といってもやる事自体はそんなに難しくない
テクスチャやサウンド等，それぞれ対応する各マネージャに読みたいファイル名を渡したら
内部でファイルを解析してバッファに蓄え，
アプリケーションは一意のハンドル（ID)を受け取るという一般的なシステムだ．
生ポインタと違ってハンドルで仲介するから間違って資源が開放されていてもわかる，
資源開放のタイミングをマネージャに任せられるなどの利点がある．
メモリ管理の要と言おうか．
テクスチャやサウンド等，それぞれ対応する各マネージャに読みたいファイル名を渡したら
内部でファイルを解析してバッファに蓄え，
アプリケーションは一意のハンドル（ID)を受け取るという一般的なシステムだ．
生ポインタと違ってハンドルで仲介するから間違って資源が開放されていてもわかる，
資源開放のタイミングをマネージャに任せられるなどの利点がある．
メモリ管理の要と言おうか．
今までサンプルプログラム出してと言われその度にメモリリークが～意味分からんエラーが～と言い訳してたのは
主にこいつが原因なのである．
途中からマルチスレッド対応にした関係で色々と無駄があるし．
主にこいつが原因なのである．
途中からマルチスレッド対応にした関係で色々と無駄があるし．
(2010/08/02)
以前twitterでも呟いた事だけれどスクリプトの扱いについて．
ゲームの処理をどの程度スクリプトに依存するのか？これが疑問だったわけだが2chで次のようなレスを見かけた（かなり意訳）
「ゲームプログラムの8割方はスクリプトで記述できる．
残りの2割はDirectX等のAPIを呼ぶ部分や速度が必要な衝突判定等
まずスクリプトで書いて見て遅かったら順次コード化していけばいい」と．
自分はこれで合点がいった．
ゲームの処理をどの程度スクリプトに依存するのか？これが疑問だったわけだが2chで次のようなレスを見かけた（かなり意訳）
「ゲームプログラムの8割方はスクリプトで記述できる．
残りの2割はDirectX等のAPIを呼ぶ部分や速度が必要な衝突判定等
まずスクリプトで書いて見て遅かったら順次コード化していけばいい」と．
自分はこれで合点がいった．
恐らくUnrealやQuakeエンジンも同じ様な感じかな～
そう考えるとFPSのMODでかなりの部分を改変して場合によっては原形もとどめてない形になるのはそういうことかぁ等と思ったりした．
スクリプトで記述して何が良いかと言えば，前回の記事で書いたがエンジンとゲーム固有ロジックの分離である．
ゲームでしか使わない機能をコードでガリガリ書くとエンジン部分をライブラリで纏めてあるとはいえ
書いていくうち何所までがエンジンなのか曖昧になって宜しくない．
それに，テスト実行するのにコンパイルも不要．
そう考えるとFPSのMODでかなりの部分を改変して場合によっては原形もとどめてない形になるのはそういうことかぁ等と思ったりした．
スクリプトで記述して何が良いかと言えば，前回の記事で書いたがエンジンとゲーム固有ロジックの分離である．
ゲームでしか使わない機能をコードでガリガリ書くとエンジン部分をライブラリで纏めてあるとはいえ
書いていくうち何所までがエンジンなのか曖昧になって宜しくない．
それに，テスト実行するのにコンパイルも不要．
現状のエンジンだとコードを1箇所修正してコンパイルするのに12～3秒ほど待たされ，ちょっと待てばすぐとはいえ
しかし結構な時間である．
極端な話，パラメタ値を1変えただけで毎回10秒以上待たされるのはたまったもんじゃない．
しかし結構な時間である．
極端な話，パラメタ値を1変えただけで毎回10秒以上待たされるのはたまったもんじゃない．
過去にこれではイカンと主要なパラメタをXML形式で管理しゲーム実行中にリアルタイム編集，
開始・終了時に自動的に読み書きするような仕組みも作ったが
扱えるのはあくまでも「値」であって「アルゴリズム」は従来どおりコンパイルしなおさなければならなかった．
（まぁそれでも便利は便利）
そういう経緯もあって今回スクリプト言語のLuaを採用した．
開始・終了時に自動的に読み書きするような仕組みも作ったが
扱えるのはあくまでも「値」であって「アルゴリズム」は従来どおりコンパイルしなおさなければならなかった．
（まぁそれでも便利は便利）
そういう経緯もあって今回スクリプト言語のLuaを採用した．
ちなみに知ってる人は知ってるかもしれないが，
前にスクリプト言語を自作してたのはちょっと字句解析を作ってみたかった程度なので不採用．バグも結構あるしね．
雷力の動画で，敵の動作やドアの開閉等のステージ進行は自作スクリプトで動いてるからあれが記念になるか・・
もう使う事は無さそうだしその時のスクリプトコードを晒してみる．
前にスクリプト言語を自作してたのはちょっと字句解析を作ってみたかった程度なので不採用．バグも結構あるしね．
雷力の動画で，敵の動作やドアの開閉等のステージ進行は自作スクリプトで動いてるからあれが記念になるか・・
もう使う事は無さそうだしその時のスクリプトコードを晒してみる．
infrustum()関数でカメラが視界に入ったのを感知，一定間隔で指定回数分攻撃命令を送る
マップに予め設定したカメラ軌道が一定の地点を過ぎるとcustommsg()へメッセージが送られる． それに反応して同じくマップへ設置しておいたオブジェクトへ向かって前進，停止．
マップに予め設定したって何よ？と言いますと(こんな感じ)で置いて，
マップの何時何が起こるという設定はなんとなんと(ベタ書き)である．
なんともお粗末だが当時は「とにかく動けばいい」方針でやってたから仕方ないか・・
マップの何時何が起こるという設定はなんとなんと(ベタ書き)である．
なんともお粗末だが当時は「とにかく動けばいい」方針でやってたから仕方ないか・・
話を戻してスクリプトは見た目殆どC言語．って言ってもswitch文が無かったり，
インクリメントは前置きのみとかの手抜き．型宣言，構造体宣言も無いか．
ただまあ折角作るのだからと文字列は＋で繋けられるしデフォルトでset(集合)型やstring型，vector型を持っていたり（演算もOK）
break文は break 2; のように数字を記述することで2重ループから一発で抜けられるようにしてたりとか自分好みの改変はしている．
後は組み込み関数のinfrustum()でカメラ視界に入っているか判定して～とかまあそんな感じ．
で，何が一番言いたいかというと一度スクリプトを自作したから既存スクリプトの理解の助けになったよってことか．
ありがとう名無しスクリプト，さようなら．
インクリメントは前置きのみとかの手抜き．型宣言，構造体宣言も無いか．
ただまあ折角作るのだからと文字列は＋で繋けられるしデフォルトでset(集合)型やstring型，vector型を持っていたり（演算もOK）
break文は break 2; のように数字を記述することで2重ループから一発で抜けられるようにしてたりとか自分好みの改変はしている．
後は組み込み関数のinfrustum()でカメラ視界に入っているか判定して～とかまあそんな感じ．
で，何が一番言いたいかというと一度スクリプトを自作したから既存スクリプトの理解の助けになったよってことか．
ありがとう名無しスクリプト，さようなら．
(2010/08/01)
さて8月．
通信プログラムはあれから少し進めたものの完成とは言い難い出来に終わった．心残りはある
しかし今月は心機一転，ゲームエンジンの作り直しを始める．というか見直し？
メモリリークや不安定性を改善しサンプルプログラムも配布できるような状態にするのが目標である．
期間はできれば8月上旬，遅くとも中ごろまで．
それとこのページを少なくとも週に1度は更新したい．
ネタが無いのに更新するハメにならないよう頑張るという事で．
通信プログラムはあれから少し進めたものの完成とは言い難い出来に終わった．心残りはある
しかし今月は心機一転，ゲームエンジンの作り直しを始める．というか見直し？
メモリリークや不安定性を改善しサンプルプログラムも配布できるような状態にするのが目標である．
期間はできれば8月上旬，遅くとも中ごろまで．
それとこのページを少なくとも週に1度は更新したい．
ネタが無いのに更新するハメにならないよう頑張るという事で．
エンジンの見直しが終わったらLuaを組み込み，主人公の動きをLuaにて記述出来るかテスト．
エンジン側はモデルやサウンドの管理に専念しゲーム自体の処理はスクリプトに分離する．
これは早くて1週間，長くても・・・いや，そんな掛かるとは思えんな・・ジャスト1週間だな．
エンジン側はモデルやサウンドの管理に専念しゲーム自体の処理はスクリプトに分離する．
これは早くて1週間，長くても・・・いや，そんな掛かるとは思えんな・・ジャスト1週間だな．
その後の予定は追々考える．あまり先の事考えたってその通り進まないし．
