とりあえず「ストーリー」というよりも「ゲームの舞台設定」といいましょうか、 そんな感じになりましたが、とりあえず決まりました。この設定でいくとストーリーは なくなりそうですね。というか、テストプレーバージョンまでの「格闘アクション」とは まったく違ったものになりそうです。ホント、ころころ変わるなぁ。

今後の課題として、プログラム的には、多関節物体を表現するのに「座標系を傾けられるように」しなければなりません。 座標系が回転しなければ今のままでもいいんですが、それだけはやっちゃいけねぇ。それやっちゃうと 以前とほとんどかわらねぇ。この道、前進あるのみ！！

今日はキー回りもちょこっと。
キーの状態を格納するバッファは、悩んだすえTListじゃなく普通の配列を使うことにしました。 理由は、TListだと重そうかなーと思ったから。そんだけ。キーデータはひとつ12Byteだけど、それでも ちりも積もれば山となる、を恐れた上での考えです。このへんは最近読んだOh!Xに影響されている せいでもあります。

おっ、そうだ。もうひとつ考えておかなきゃならないのに 「実行時のメモリ確保をなるべく減らす」っていうのが前回からの教訓だった。 殴ったときとかいっぱいエフェクト出ると、とたんに処理おちするんだった。 これは、よく使うであろうクラスはどっかに配列にして先に作っておいて、 使いたいときは配列からひっぱってきて、使い終わったら参照のみを消す、と。 メモリは開放せずに、後から使いまわせるようにとっておくんです。 こうすることで、処理落ちが多少抑えられるはず...。あまり使わないやつを 先に作っておいても駄目だけど、よく使うやつなら結構効果あるはず。

でも問題はどうやってこれを実装するか、だね。 スーパークラスはコンストラクタが呼び出されると、自動でリストに登録してるんだけど、これは ちょっとやめておこう。フラグを追加してそれがTrueなら自動登録、っていうふうにやればいいかな。 生成回りはこれでよし、と。次は開放回り。後から使いまわすんだから開放は厳禁。だから、さっきの フラグがTrueなら、メモリ開放は行わずに、変数の初期化をして、リストから削除する、でいいかな？ やっぱりやってみないとなんとも。

さて、最後は「配列からどうやってもってくるか」です。これが一番やっかいですね。 生成、開放回りは呼び出される側の責任ですが、これは呼び出す側に責任があるから面倒なんですよねぇ。 うーん、このへんを管理するクラスを作っておいたほうがきれいに書けそうだ。 もちろん、配列の上限を超えたら新たにメモリ確保しなきゃ何ないし。しかもこういう設計にすると、 呼び出す側はこのへんを管理するクラスを参照できる必要があります。うーーーーん....。

おっとこれでどうだ！？
まず、リストに「先に作っておいたクラスのリスト」も持たせることにします。 このリストにはもちろんポインタが入っているだけですが。 こうすると、参照側のスーパークラスはリストへのポインタをプロパティとしてもっているので、 問題なくこの「先に作っておいたクラスのリスト」にアクセスできます。 つまり、先に作られた可能性のあるクラスを新たに使おうとするときには、 まず「先に作っておいたクラスのリスト」を調べて、そこにない、又は、全部使用中のときには 新たにメモリ確保してそれを使い、そうでなければ、使用中じゃないのを探して使うって形になります (長いし、わかりにくいな、これ)。とりあえず、これでいけそうな感じだ。うむ、明日やってみよう。 おやすみ〜。