短編RPG制作 – その4 システム – ステータス関連DB

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

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


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

まず、複数のデータベースにパラメータ(攻撃力等)がコピーされて混乱しやすいので、整理してみました。
ステータスを保持する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で重複したパラメータを、外出しにしました。
具体的には、こんな感じ(下図・クリックで拡大)。

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

DB構成変更(例)

DB構成変更(例)

 【注意】今回は説明のために、新しいタイプを1番目に「挿入」しましたが、
   DBの構成を変えると、基本システム内の至る所に影響が有ります。
   心配なら末尾に追加した方が良いでしょう。慎重に。

…と、こういった作業を、全てのDBに対して行います。移動元のDBからは、当然ながら削除します。
 パラメータの順番・数はぴったりと一致させる事。
  ※ウディタで言う所のデータベースは、型のみを定義する概念はないため、
   各々のDBで実体の定義が必要になります。

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


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

コモン122:X[移]一時ステ計算 修正例

コモン122:X[移]一時ステ計算<初期化> 修正例

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

   ■DB読込(可変): V4[STATUS_PARAM_NUM_MAX] = 可変DB[タイプ┣[能力]基本値の内容数]

 と初期化してあります。


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

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

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

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です