基本は完成したのですが・・・

[dic]

前回に公開したものを改良し
シューティングの基本設計図はできたのですが、色々考えるところもあり、
また公開してみます
なんというか、設計に答えがないもので、これでいくと決めかねているところであり
ここはこうした方がいいとか、これはやめた方がいいとか意見を聞いてみたいです

これをもとに作っていきますが、変更などあるかもしれないし
優柔不断なもので、いまいち決め手が欠けてるところです

[ねこ]

基本的なシューティングの設計としては申し分無いと思いますよ。
今後ゲーム自体のオリジナリティによって色々派生していくと思います。

個人的にですが、CBulletのMove()にくっつく形としてMoveクラス系を加えると変則的な動作は書きやすいと思いますよ。
僕の場合「MoveUtil」という基底クラスを「MoveStraight」「MoveCurve」等で継承して
ShotクラスにMoveUtil* m_pArrMove[10]という配列に保持しています。
イメージとしてはこれらの移動クラスに現在の座標をポインタで渡すと１フレームの移動分値を加算する関数を用意する感じですね。
150フレームはMoveStraight,150以降はMoveCurveというように使い分けると逐一そういう動作をするショットクラスを作らなくても打つ側の組み込みで完結する事が出来ます。
シューティングゲームは弾幕にそれなりの労力がかかるため、ショット周りの手間は可能な限り簡略する事が効率向上になります。

後はサウンド、特にSE関連でしょうか。
読み込んだサウンドハンドルを保持して、どこからでも呼べるクラス関数を用意して
1フレームに何度も呼ばれた時の挙動やボリューム等管理するクラスが１個あると重複して大音量になったり
重なると変に聞こえる音をクラス側で対処出来たりある程度便利です。

１作目には必要ないと思いますが、Enemy系にはEnemyBase⇒Enemy⇒Enemy1というような継承をしておくと次の時便利かもしれません。
というのも例えば体力や自機への参照等、シューティングを作る上では絶対必要だろうって要素はいくつかあると思います。
設計によって異なるのでどれとは言えないのですが、EnemyBaseで基本的なパラメータとSetter/Getter作っておくだけでもEnemyでの記述も少なくなり、見やすくなると思いますよ。

[DVDM]

>>dicさん
良く解らない時は、今の案で一端作ってみては如何でしょう。
そのクラスを使っていくとどこかしらで使いにくくなってくるかもしれません。
その時、より良い設計にするにはどうすればよいか・・・を考えていけばいいと思います。
(私はそういうスタイルでクラスを作成しています)

CStageクラスの中に draw, move 等ありますが、画面遷移のみを担当するようにしてみてはどうでしょう。
描画は別のクラスにお任せすると良さそうな気がします。

インプット関連もクラス化してしまうと次に使う時に非常に便利かなぁ～と思います。

[dic]

>ねこさん　DVDMさん
なるほど、一回作って見た方がいいのでしょうか
アドバイスありがとうございます