構造設計

ゲーム プログラミング

自分が今やってるプログラムの設計の覚書。


以前作ったサンプルはクラス設計以前に構造化も何もなかった。
C言語プログラムのサンプルだったから当然なんだけど、
とにかくこいつに付け足しでコーディングするのは骨が折れる。


だから色々考えた挙句次のような感じになった。
(今後変更する可能性があるし、そもそもこれが正しいわけでもない)

ソースファイル

まずはソースファイルの分け方。

メインとなる処理

os.* Windows固有のコード。目標はこいつ以外windows.hをインクルードしないこと。
graphic.* DirectX関連のコード。(実はコイツもwindows.hがいる。)
game.* 有体に言えばGameManager
main.*　 gamemain関数がおいてある。Windowsより一つ上のレベルでのスタート地点。

サブっぽい処理

common.* 全体に共通のconstanceやらなんやらを置く。uintとかも定義してある。
option.* コマンドラインオプションを解釈・フラグ化するクラス。
util.* 雑多な処理をおく

こんな感じで分かれている。

構造

クラスの構造は今のところメイン処理のソースファイルと対応してる。

os.cpp

まずos.cppがエントリポイントとなって、ウィンドウの作成・コマンドラインの処理を行う。
os.cppによって公開されるデータは

  • HWND型のウィンドウハンドル(directXに必要)
  • bool型のアプリケーション終了情報(メインのゲームループの終了に必要)
  • bool型のウィンドウメッセージの受信情報(メインのゲームループの処理に必要)

それ以外は隠匿される。


ウィンドウメッセージも全てここで処理してしまう。ゲームにおいて、ウィンドウズGUIのメニューバーを利用しなければならないとかでなければ、ウィンドウメッセージの処理はdestroy(破壊)だけだと思うから。この目論見が外れると痛いかも('д`)


最後に、os.cpp内のWinMainから、main.coo内のgamemainが呼び出される。

main.cpp

os.cppから受け取る情報は現在のところ一つ。Args型。
これは、実際にはstd::vector型である。
(これを生成してるのはos.cpp内の関数。大した手間ではない。)

option.cpp

そして上のArgs型の値をさらに解釈するクラスがOptionクラス。
実行時パラメータは全てこいつに問い合わせる予定。

game.cpp

ゲームの１フレーム当たりの処理の統括。
たぶんシーンコントローラを駆動するだけ、な気がする。
中間管理職。

graphic.cpp

Direct3Dをつかさどるクラス。
とはいえ、恐らく他にも細々としたクラスを作ることになる。
次に作る予定はSprite。2Dのグラフィックスには絶対必要だからなー。

('ω`)

今のところこんな感じ。
hmx,ドーナツ、ひろ氏、id:peregrinationの参考になればいいね。