ゲームのクラス構成を考えてみる(楽しい寄り道)
(偽NaGu-Ru開発日記)99/12/16,26

今、テスト期間中、というか今日はテスト一日目です。
しかし、どうにも気になって起動しちゃったわけです...。あぁ〜あ。

なんでこんなことを考え始めたかというと、次のような理由からです。

一、ソースが汚くなったので、全書き直しをしましょう。
一、もう一回クラス構成を整理しましょう。
一、バグが多いですよね。

さて、勉強もせず考えてみたんですが、だいたい次のようになりました。

ゲーム管理クラス

ゲームモードクラス
オブジェクト管理クラス
サーフェース管理クラス
サウンド管理クラス
BGM管理クラス

オブジェクトローダー
イベント管理クラス
マップクラス
ステージ管理クラス

現在考えがまとまっているのでこれくらいです。
このうちの半分くらいは今のクラスをちょっと改良すればいいだけです。
今度はもっといい感じにしよう.....。

...ていうかねー、最近思うんだけど、「オブジェクト指向をなぜ使うのか?」っていう問題に大して
「生産性を高める」というのがあった気がするんだけど、これってかなり確固たるクラスじゃないと
駄目だよなー。まぁ、当たり前かもしれないけど(^^;第一、ゲーム作るのに同じソースを使うとは
思わないし(特に違うタイプのゲーム)、つまりソース書き直しが必要なので生産性高くなるのか?
とか思ってしまうんです。でも、その辺はどうにもならないもんなんでしょうねぇ。

だから、「汎用性の高いクラス構成」を作ることが必要になってきます。
つまりしっかりとした「抽象クラス(Cだとスーパークラス?)」を作る、ってことです。
んで、あとは各自で継承して勝手につくっちゃってね、っていう感じにするんです。
もちろん、ある程度の機能を盛り込んだクラスは用意しておきます。物理的な運動をするクラスとか。

というわけで、みんなもがしがし書きなおしていきましょう!!
やっぱり、コードはきれいじゃないと(←おまえがいうな!)ね!!!
やってみると結構なんとかなるものです(マジで)。時間はかかるかもしれないけどね(^^;
そんで、がんがんソースを公開していきましょう。

そういえば、ソース公開されたソースを見ると、僕の経験ではたいてい「わけわかんねぇ!!」ものです(^^;
だって、ゲームのソースってたいてい何千行かのものになるし、しかも公開されているのに限って
ソースが特に長いし、そのコードの中から、自分のほしい部分を抽出できる可能性はまれです。
しかも、かなり時間がかかります。そこで僕が得た結論は「人の見るより自分でやってみれ!!」ってこと。
しかし、これはうそです(^^;)人のソースコードを見て勉強することはとても大事です。
偉人たちのコードは見るべきです。たいてい勉強になりますよ。何万行もあるコードの前に撃沈されるかも
しれませんが、得るものは大きいのです。ちなみに僕はSANDMANさんのコードを見てTList、クラス、可変長個引数、プロパティの
作り方を学びました。あと「High,Low」関数。僕はこれなしではもう生きられません。FDにちゃんと保存して取ってあるし(^^;

話ががんがんずれていきましたので、そろそろ戻しておきます。
ゲームにおけるクラス設計は、最初にちゃんと考えとかないと、僕のように仕様変更ばっかりで
逆に時間がかかったりする可能性もあるわけです。散々文句を言いながらも、実はそれもいいことだとは思うんです。
だって、RPGでいうと経験値が上がってレベルもアップするわけですから。悪いことばかりではないんです。

ゲームプログラマにとって、一版無駄な時間は「ゲームとは関係ない部分に悩む時間」です。
SDKレベルで組んでいくとこれが顕著に表れてきます。DELPHIって結構こういうことをかんがえなくてもいい
開発環境なんでかなり重宝してるんですが、現在のバージョンにはちょっとバグがありすぎてちょっと
いらついています。特に、コードエクスプローラばぐりすぎ。あと、アドレス違反しすぎ。はやくアップデートパッチ
作ってよね。


※テスト期間
ぽくむらは学生であり、当然「テスト」がある。しかも欠点(赤点)が55点以下のため、 勉強をしないわけにもいかない。よって、勉強嫌いのぽくむらには地獄だといううわさだ。 (勉強もろくにせずにこんなことばかりやっているのだが...)

※クラス
知ったかぶったことを書くとえらい人から怒られそうだが、 僕は「構造体に関数がついたもの」と思っている。MFCやVCLなどはこの「クラス」を使って構成されている。

※オブジェクト
ここではゲームで出てくるキャラクタなどをさしている。

※ソース
ここでは、刺身を食べるときなどに間違えてしまうようなものではなく、 「プログラムのコード」のことをさす。ソースコードともいう。

※サーフェース
要するに「絵」。スプライトということもある。

※オブジェクト指向
よくわからん。僕は「クラスをうまいこと使っていい感じにまとめること」という抽象的な捕らえ方をしている。 本がいっぱい出てるので詳しくはそれを参照のこと。

※SANDMAN
多くのDELPHI & DirectXプログラマを支えるお方。 DirectXコンポーネント「QuadrupleD」はあまりにも有名である。 3D、JAVAなど分野も幅広いが、特に画像処理に重点をおいているように見える。 また、メールで「オブジェクト指向」についていろいろ教えてくださった。 http://www.din.or.jp/~hayase/

※TList
VCLの中で僕がもっともよく使うもの。 便利な割にはあまり解説ページがなかったりする。

※FD
フロッピーディスク。今では生産量などもCD-Rに負けているとのうわさも。

※SDK
SoftwareDevelopmentKit(だったかな?)の略称。 プログラムのライブラリみたいなものです(例:DirectXSDKなど)。

※コードエクスプローラ
ソースファイルにある関数やクラス、グローバル変数などをツリー表示してくれる便利な機能。 しかし、DELPHIのはしょっちゅうバグるので、うんざりしている。VCのは速くて安定感がる。

※アップデートパッチ
一度出荷された製品に対してバグが発見されると、 企業が「やっべーよ、おい」てな感じで配布するバグをなくすためのもの。 DELPHI 3のとき使ってみたが、ユーザー名がなくなってしまった。

※アドレス違反
最も見つけにくいバグのひとつ。 DELPHI5自身がこれを起こすこともあり、「堪忍してくれよ」ということになる。

さて、いろいろ考えてみたら、というか開発中に問題が発生しました。 何かというと、ゲームモード(シーン)切り替え時のデータのやり取りができなーーーい!! ということです(グローバル変数を作っちまえばそれで終わるんですが、それじゃなんかあまりにも手抜きでしょ?)。 ちゅうわけで、この問題をうまく解決できるようにせねばなるまい。

まず、思いつくのが、データのポインタをゲーム管理クラスに渡すってことですかね。 んで、次のシーンに移るときにそのデータを新しいシーンに渡す...と。 当たり前ですが、どんな型のデータでも渡せるようにしなければならないので、 ポインタとそのサイズも指定しておいたほうがいいですね。

っておい、それじゃだめだよ、やっぱ駄目ダメ。 第一、どこにデータをおいておくの?どうやって次のシーンに渡すのよ!? ということで、他の手を考えねばなりませんね。

次に考えたのが「シーンを切り替えるな!!」って方法。 例えば、そーねぇ。キャラセレクトのシーンから、戦闘シーンへ移るときを考えてみますか。 ここで問題になるのは、選んだキャラクタのデータをどうやって戦闘シーンに渡すか、ってことですよね。 だって、選んだキャラクタがわからなきゃどれを戦闘シーンに出せばいいわかからないもんね。 だから、シーン切り替えでデータやり取りができないんなら、シーンを切り替えなければいいわけですよ。 具体的には「キャラセレクトオブジェクト」みたいなのを作っておいて、そいつが一番前に でしゃばり出てくるようにしておきます。それで、そのオブジェクトは自分のやりたいことをやって やったあとにはデータを渡すオブジェクトを探してデータを渡して、戦闘開始、みたいな。

説明がよくわからん上に、あんまりいい方法じゃないですな。 なんかいい方法があると思うんだけど、なかなか思いつかないなあ。

※グローバル変数
どのコードからも参照できる変数。 変数名が重なったりすることがよくあるので、 一般にあまり使うべきではないといわれている。 優れたプログラマほどこれを嫌う傾向がある。 結局は時と状況による。

※ポインタ
書き出すと本になってしまうほど奥が深いもの。 初心者プログラマの敵。僕もはじめは「何に使うの?」と思った。 機械語レベルで組むと、これを知らないと話にならないことが多い(マジです)。






もどる