• その1.今はどんなもんだ？
  まずは、今を知ることからはじめましょうか。 今の状況をちゃんと知ることによって、後々気をつけることができそう、ってのが理由。 まずはおおまかに書き出してみましょう。
  • 全ての元となるオブジェクト「TMover」
    思えば、こいつが太りすぎた気がするなぁ。 稚拙な構造のせいで、こいつを太らせることになったんだから。 しぼれるだけしぼっとかないと、メモリの無駄→生成に時間がかかる→パフォーマンス低下につながるからね。
  • オブジェクトたちを管理するやつ「TMoverList」
    こいつかぁ。最初のうちはこれで用が足りたんだよな。でも、もう駄目だね。君、解雇。 もっと、こう、さぁ。他のクラスとの連携うまくしないとさぁ、辛いんじゃない？
  • ゲームのシーンを構築するオブジェクト「TGameModeClass」
    あんたは結構よかったんだよ、うん。でもさぁ、何でTMoverList型のオブジェクトを持ってないわけ？ 継承していちいち追加するのって、面倒じゃん！！頼むよ！！
  • ゲームに使うBMP,WAVファイルの読みこみ、管理を行う「TSurfaceList」「TSoundList」
    あんたたちもよかったよ、うん。その調子、その調子(^^)でもね、QDAファイルの読み込みとか、例外処理がしっかりしてないと、 上は狙えないよ(何のこっちゃ)。
  • コマンド判定などの処理、キー処理全般をまかなうオブジェクト「TKeyManager」
    はじめはよかったんだよな、確かに。最初は俺も満足してたよ、「波動拳コマンドが判定できたー」って(^^;) でもさ、ため技系に未対応だったり、フラグ機能がないのは、やっぱり辛いと思わない？
  • マップ描画、読みこみを賄うオブジェクト「TMap」
    初期に作られたクラスだけあって、駄目駄目ですよ、君。よくそれでNaGu-Ruを支えてこれたもんだね！！ 君は、もう使われない予定だよ、残念だったね。次からはマップという概念がなくなる予定なのさ。 これからは「テクスチャ」の時代だ！！(詳しくは今後扱うと思う)
  • 物理的運動などが可能なオブジェクト「TMoverEX」
    ジャンプ部分のバグについては、ほとんどが君の責任です。
  • NaGu-Ruのメインオブジェクト「TChara」
    君は、なんつーかその、バグありすぎ。ていうか、なにその汚いコード。読めないよ？
  • 面白さを決定付けるオブジェクト「TEnemy」
    「プレーヤーおっかけルーチン」はまさにぎりぎりだったね。再帰法使えよな、基本らしいぜ。 「攻撃、防御ルーチン」もかなりやばいし。今度からはもっと考えましょう。
  • プレーヤーオブジェクト「TPlayer」
    君ねぇ。複数のキャラクタ選択できるのに、なんでそれぞれのクラス作らないわけ？ 頭悪いんじゃない？そんなんだから、コードが絡むんだよ！！

  とりあえずこんなもんですね、主なクラス(オブジェクト)は。NaGu-Ruの不安定さが伺える、 稚拙なクラス群です。よくこれで動いてたな...までは思いませんが。ここで一気に書きまくろうと思っていたんですが、 ファイルがでかくなりそうだったんで、細かく分割することにします。きっとこの考え方はプログラミングでも 大切です。
  次は、「できなかったこと」を見ていくことにしましょうか。

  次へ進む

※「設計してる暇がありゃプログラム組め」
多分、頭のいい人がいったんだと思う。だってさー、あんたらの頭がPen�Vだとしたら、 俺の頭は486だよ！？だから、「設計」という名のテーブル処理しないと話になんないの！！まったくもう！

※三度失敗
えぇ、ほんとですよ。コード書きなおしはこれでもう四回目だっちゅーの！！ 古くて生産性の悪いコードにすがって生きるより、新しいこと、やったことがないことに挑戦して成長しなきゃ、 終わってるでしょ？

※太りすぎ
無駄な機能という名の脂肪が多すぎってことです。この文章の中で重要な比喩表現なので、確実に 抑えておきましょう。

※分割
プログラムの入門書なんかによく書かれていそうなこと。 機能はひとつに集中させずに、細かく分割したほうがいいよ、っていうことです(まんまやん)。