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

(2010/11/28)

前回ドキュメント生成について一通り調べた後に，良い機会だと思って
前々から気になっていたバージョン管理システムを導入すべく動いていた．
現状では1人でしか開発してないしファイルを定期的にコピー，バックアップしていれば事足りたので
ファイルを差分で保存したり編集履歴を残さずともなんとかなってはいた．

しかし後のことを考えればwebページにリリースしたバージョンはそれはそれでとっておきたいし
ちょっと新しい機能を実装してもし駄目だったら特定の時点のファイル構成に戻したりできれば
便利だろうという目論見である．

とはいってもどれを使えばいいのかイマイチわからんので
検索したら一番に出てきたSubversion(SVN)を選択．
早速WindowsのSVNクライアントであるTortoiseSVNをインストールし
一通り操作方法やアップデート手順や仕組み等を学んだ後にプロジェクトファイル一式を移行した．
今のところ不具合は発生せず．

(2010/11/24)

プログラムの方は相変わらず進んでない．

通常IDEを使って自分だけで開発する場合はInteliSenseのようなコマンド補完が働くので特にドキュメントは必要ない．
とはいえスクリプトとC++で同じ関数を便宜上別名で登録したりすると
「関数名はなんだったっけ？」「引数の順番は？」等いちいちC++のソースを見るのは効率が悪く
把握のために関数表が欲しくなってくる．

聞くところによるとある一定の規則に従ってコメント記述すれば（DocXMLと言うとか，なんとか・・）
VisualStudioにクラス構造をXML形式で出力する機能が備わってるらしい．

そういえばこんな項目が．
試しにビルドすると左のように記述したコメントが右のように出力された．

なるほど，これをsandcastleというツールで処理すると見た目がMSDNみたくなるわけですな．
sandcastleは本来CUIのツールでコマンドを覚えるのが億劫な私はサッサとフロントエンドを探してくるのだった．

とりあえず有名なsandcastle help file builderを選択．必要な情報を設定後，早速ビルドボタンを押す．
が，APIが1つも検出されませんでした云々というエラーが出る．APIが関係あるのかよ．
つーか使い方を説明してるwebサイトは何でどいつもこいつもコンパイルしたdllを指定してんじゃ．
デバッグシンボルでも解析してんの？と思ったがそうでもないらしい．
色々調べた結果どうやらsandcastleは.NETFrameworkのコードが前提という．要するにネイティブコードとか知ったこっちゃねえと．
正確にはVisualStudioのソリューションファイルを読み込めるみたいだけど
sandcastle最新版ではVisualStudio2010のみのサポートだから2008とか無理と言われてしまった．（マイクロソフトのツールなのね）
でもやはりマネージドコード（.NETを使ったコード？）でないと駄目な雰囲気が・・
そうだよなーMSが非.NETなんて推奨しないよなーとか思いつつ．

一先ず別のツールを試す．
いつかのdoxygenもDocXML形式のコメント記述に対応してるらしいのでそれを．
結果は日本語化け直しに手間取ったが成功．コレで行こうかと思っている．

とここまで書いて「そもそも必要なのはC++とLuaの関数対応表だけ」という重大な問題に気づいた．
DocXMLのタグで補足として記述すればいいのか？
そんなオチですいません．後で役に立つだろうという事でひとつ．

(2010/11/19)

なんか思考がまとまらない．
進捗をと思って一昨日から何回か，
HLSLと頂点形式とかゲームオブジェクトとの関連付けについて記事を書いていた・・が
自分で読んで明らかに文章がおかしい．
書いては捨てて書いては捨てての繰り返しだ．
原因はよくわからないがテンションが物凄い低いし，何もやる気がしない．

そんな調子なのでしばらく更新が滞りそうだという事だけ報告．

(2010/11/12)

表示はできたっちゃあできたんだけど
今更バッファを黒色にクリアしました，2D画像貼っ付けました．
じゃ（スクショ的に）示しがつかんよなぁ
てなわけでゲームオブジェクトやシーンの扱いとかをちょいと作って
ゲームぽく動かそうと思ったが見事に仕様が穴だらけでありました（要するにいつものパターン）
中途半端に古いソースがあるとそれを無理に生かそうと働いて駄目だね～

現在メモ帳とドローソフト使って思案中
形だけでも決まらないと心配で今夜寝られそうにないんだが，果たして・・

(2010/11/10)

当たり判定は一段落したので描画関連に入った．
とりあえずカメラに，描画グループとシェーダークラスの移植をば．
描画機能はどのクラスに持たせるか悩んだが結局エンジン本体クラスにした．
なんかあまりスッキリしない設計だけど・・・こだわりすぎも良くないということで．
HUD用の2D描画クラスを移植すれば一先ず表示が出来る筈．
今日と明日で実装終わればいいがなぁ

今後の予定

• ユーザー定義オブジェクトのメッセージ駆動の動作確認（他のオブジェクトと色々やりとりしたり）
• 当たり判定，キー入力判定，描画，の動作確認的な意味で2Dのサンプルゲーム作成

どんなゲームよ？
そうだなあ・・ブロック崩しとかどうだろうか

(2010/11/07)

細かい仕様が煮詰まってなかったのでメモ帳にすべてのケースを書き出してアルゴリズムの吟味など．

そんな感じ．さっさと実装しなきゃね．

(2010/11/06)

今日も当たり判定の動作確認と少し仕様変更という地味な作業．書くことなし．

ちょっと前から左下のTwitter欄を消してみてたんだけど，このままでいいのだろうか．
辞めたわけではないんだがTwitterが繋がりにくいとこのwiki全体のページ読み込みが遅くなるし
特に見たいって人いなそうだし・・

(2010/11/05)

作業はまだまだ当たり判定の仕様決め＆実装途中
当たり判定の結果をどのように返すか？当ったインタフェースの取得方法
他にメッセージでオブジェクトに通知する機能や
当ったかどうかだけ知りたい場合はもうすこし処理を軽く出来そうだ・・・とかやってたらもうこんな季節．
年明けるまでに何も動いてなかったらいよいよもって駄目かもわからんね．
苦労の甲斐あってもうちょっとで完成しそうだがバグが潜んでる可能性あり．

これが終わったら次は描画の仕様を考えねばならぬ．
描画優先度やZバッファの操作，カリングの方法はどうする～？など．
当たり判定でこんな苦戦してんだからすんなりと行くはずないよな．

その後はちょいちょいと2DのHUD描画クラスを移植して
スクリプトで2Dの絵を動かしてみる予定．で，プログラム公開して
「ちょっとスクリプトいじってみてくれや，不具合あったら報告よろしくー」とか出来るんかなぁ？
サウンド関連はとりあえず無くても良いだろうし．

ところでここにきて懸案事項が．
Luaでゲームの殆どを制御できるように今まで作り直してきたわけだが
デバッグはPrint()系の関数でひたすらログ出力と言う原始的な方法に頼っている．
規模が小さいうちはそれでもやってけるが後々を考えると，何とも．
現在使用中のLuaエディタであるLuaEditはゲームエンジンから呼び出した際の
デバッグは無理だろうしなあ・・（もしかしたらできるの？）
Luaにユーザーが各自でデバッガを作れるらしき支援関数が用意されているのは知っているが
そこまでガッツリ取り組むべきなんだろうか．