先月の事ですが、スペインのノワール映画「マジカル・ガール」見てきました。
変わった映画が好きな方にはお奨めです。
独特の間もさることながら、シニカルなタイトルの意味に感心した。
最近では、漫画「僕だけがいない街」がそうでしたが、
漠然とした、或いは初めはよく分からないタイトルの意味が、
話が進むにつれ明確になっていく過程で得られるカタルシスは、非常に強烈です。
承前、ウディタ道のお話。
さて、ステータスをシンプルにするため、リファクタリングをしてみました。
まず、複数のデータベースにパラメータ(攻撃力等)がコピーされて混乱しやすいので、整理してみました。
ステータスを保持するDBは、基本的に5面あります。下表のような感じです。
# | 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側のメンテは必要)
…と、これは一例で、こういった作業の繰り返しで、改造をしやすくしていきます。
闇雲に改造するより、最終品質が良くなると判断した次第です。
一般のソフトでも、データ構造次第で、驚くほど処理がシンプルになる事は珍しくないです。
ま、一番のメリットは、こういった調査の中で、頭の中が整理されていくという事なのかもしれません。
ではまた。続きます。道は長いです。