先月の事ですが、スペインのノワール映画「マジカル・ガール」見てきました。
変わった映画が好きな方にはお奨めです。
独特の間もさることながら、シニカルなタイトルの意味に感心した。

最近では、漫画「僕だけがいない街」がそうでしたが、
漠然とした、或いは初めはよく分からないタイトルの意味が、
話が進むにつれ明確になっていく過程で得られるカタルシスは、非常に強烈です。

---

承前、ウディタ道のお話。
さて、ステータスをシンプルにするため、リファクタリングをしてみました。

まず、複数のデータベースにパラメータ（攻撃力等）がコピーされて混乱しやすいので、整理してみました。
ステータスを保持するDBは、基本的に５面あります。下表のような感じです。

#	DB項目名	DB種別・No	いつ 使う？	説明
1	主人公ステータス	可変0	移動中	装備や状態異常が加味されない、基本的状態。 レベルアップによる変動は加味される。
2	主人公一時DB	可変17	移動中	#1に装備や状態異常が加味されたもの。 ステータス表示画面に見えるのはこの項目。
3	戦闘一時ステータス[基] (基本攻撃力など)	可変10	戦闘中	戦闘時の基本的な状態。 戦闘開始時に、#1からコピーされる。 戦闘終了時に、（必要に応じ）#1に書き戻される。
4	戦闘一時ステータス[基] ([一時]計算済み攻撃力など)	可変10	戦闘中	#3に装備や状態異常が加味されたもの。 戦闘処理では、基本的にこれが使用される。
5	敵キャラ個体データ	ユーザ9	戦闘中	戦闘開始時に、#3の敵用の領域にコピーされる。 敵キャラなので不変。

---

図示すると、こんな感じです（クリックで拡大）。
青の矢印が、攻撃力等のパラメータのコピーを表します。

※これに加え、武器や防具によるパラメータの増分を保持する領域や、
　細かい所では、レベルアップ時のステータスアップ表示用の一時領域が有ります。

---

さて、ここまで分かったので、DBの構成を変えてみました。
各種DBで重複したパラメータを、外出しにしました。
具体的には、こんな感じ（下図・クリックで拡大）。

例）
可変DBに新しいDBタイプ（ここでは「1:┣ [能力]基本値」）を追加して、
「0:主人公ステータス」の攻撃力などを、新しいDBタイプに移動します（下図）。

　【注意】今回は説明のために、新しいタイプを1番目に「挿入」しましたが、
　　　DBの構成を変えると、基本システム内の至る所に影響が有ります。
　　　心配なら末尾に追加した方が良いでしょう。慎重に。
↓
…と、こういった作業を、全てのDBに対して行います。移動元のDBからは、当然ながら削除します。
　パラメータの順番・数はぴったりと一致させる事。
　　※ウディタで言う所のデータベースは、型のみを定義する概念はないため、
　　　各々のDBで実体の定義が必要になります。

で、ちょっと見通しが良くなっただけで、何が嬉しいの？と思われるかもしれませんが、
これにより、下のようなコードが可能になります。

---

【例】
　コモン122:X[移]一時ｽﾃ計算<初期化>(前の図の、#1→#2へのコピーに相当)
　を、ループで書き直してみた

　※ループ終了条件の通常変数 “STATUS_PARAM_NUM_MAX”は、
　システムの開始時に、

　　　■DB読込(可変)： V4[STATUS_PARAM_NUM_MAX] = 可変DB[ﾀｲﾌﾟ┣[能力]基本値の内容数]

　と初期化してあります。

---

ここで重要なのは、右側はコードが短くなっている事ではなく、
個々のパラメータ（攻撃力など）に依存しない処理になっている事です。
つまり、メンテナンス・フリーということになります。
（仮に「運の良さ」など、パラメータが幾つ追加になっても、このコピー処理には手を加えなくて良い。
　もちろん、DB側のメンテは必要）

…と、これは一例で、こういった作業の繰り返しで、改造をしやすくしていきます。
闇雲に改造するより、最終品質が良くなると判断した次第です。
一般のソフトでも、データ構造次第で、驚くほど処理がシンプルになる事は珍しくないです。

ま、一番のメリットは、こういった調査の中で、頭の中が整理されていくという事なのかもしれません。
ではまた。続きます。道は長いです。