そんなん、単純に構造体で管理だろJK
・・・かもしれませんが、この部分のデータ設計を予め如何に適切におこなっておくかで、ゲームの表現の幅が大分変わります。私はそのことを、SHOT01～SHOT03（３作品）の開発での失敗を経て実感しています。
まずは、実際に設計中のデータ（実物）を見た方がイメージが沸き易いかと思います。
なので、現在開発中のSHOT04で作成途中のデータ構造を例示します。
 |
クラス構造としては、敵、オブジェクト、パーツの３種類。
E-Rで表記すると、
- 敵：オブジェクト＝１：ｎ（最大８）
- オブジェクト：パーツ＝１：ｎ（最大８）
という感じ。
つまり、１匹の敵は最大64パーツ（8^2）持てます。
数は今後、コロコロ変わっていくんでしょうけど。
実は、SHOT01の頃は単純な１個の構造体で敵を表現していました。
ただ、それだと当り判定が複数個所に分かれるような場合、処理が面倒になります。
そこで、SHOT02とSHOT03では、１つの敵を複数のオブジェクトで表現する感じにしました。
ただ、それでも処理が厄介な部分があったので、今回は、敵、オブジェクト、パーツの３層構造のスキーマを定義。（予定）
オブジェクトには、有するパーツ数＋パーツ情報を定義します。
例えば、グラディウスの多節足の敵の場合、根っこの部分、胴体の部分（複数）、頭の部分みたいなパーツをグループ化したものが、ひとつのオブジェクトになります。
それなら、オブジェクトとパーツだけ（２層構造）で十分だ・・・と普通は考えます。
（だから、SHOT02とSHOT03はその形態にしました）
ただ、例えば多節足を２本持っていて、足単位でパーツ破壊できるような敵（足×２＋本体）というものを作ろうとするとプログラムが複雑になってしまいます。だから、オブジェクトを更にグループ化した、クラス（Enemy）を追加・・・という訳です。これで、どんなものでも簡単な処理で表現できる筈。まだ、作ってないから確証は持てませんが。
ちなみに、クラスだとかスキーマだとか、オブジェクト指向の用語を使っていますが、プログラム言語はCのみです。私は、C++やJavaが大嫌いなんですが、オブジェクト指向の考え方自体は、重要だと思っています。（ついでに、iPod touch化するときにもに楽になる筈）
