月別アーカイブ: 2016年4月

短編RPG制作 – その7 システム – 成長について

体感型中年育成ゲーム(※1)のリザルト(※2)が帰ってきました。
綿密なパラメータ調整(※3)が功を奏したのか、なかなかハイスコアでした。
が、背が縮んでました。胃検査は、今までバリウムでしたが、次回から胃カメラにしよう。

※1 人間ドックの事。
※2 結果の事。
※3 糖質制限の事。


続きです。
過去にも書きましたが、グラフィック等は後になりますので、
当分、本カテゴリー「短編RPG制作」は地味~な更新が続きます。
最初のうちからグラフィックを作りこむと、手戻りになる可能性が高いためです。
よろしければお付き合い下さい。

さて、独自システムの作成に入っていきたいと思います。
今回は2つ、中心となるシステムを考えたのですが、1つは成長システムです。

RPGの醍醐味の一つに、キャラクターのレベル上げが有りますが、
「成長した」と感じる為には、数値の多寡、つまり「レベル数の絶対値」が、
かなり重要に思います。

もちろん、レベルの扱いはゲームによって異なるのですが、
プレイヤーは、1レベル上がるとどの位強くなるか、
おおよその尺度を持っていると思います。

つまり、ゲームに関係なく、単に「レベル10」と言った時に、
何となく、「どの程度の強さか」が想像できてしまうという事です。

標準的な商用RPGのクリアレベルは50~70ぐらいでしょうか。
プレイ時間は20~30時間として、平均して1時間に2~3レベルぐらい。

一方、今回作ろうとしてるのは、3~4時間程度です。
1時間に2~3レベルだとすると、クリア時はレベル10前後です。
「達成した」と感じるには、10は厳しい数字に思えます。

逆にクリア時にレベル50とすると、1時間に10レベル以上も上がる計算になり、
今度はインフレ感が出てしまう。なかなか難しい問題です。

—–
そこで、今回は、「主人公のレベル上げ」とは違う方法で、
達成感を味わってもらおう、と考えました。

まず、主人公から「レベル」を削除しました。
つまり、キャラクターは成長しません。

そして、なんと「武器」や「防具」も、(装備品としては)削除してます。
これは2つ目の自作システムの時に解説します。

おいおい何やってんだよ!と言われそうです。はい、かなり不安です(:
どうやって成長するの?というと、装備品(アクセサリ(仮))を成長させます。
つまり、「レベル」はアクセサリに持って行っています。

twitterでも2ヶ月ぐらい前に試作品を貼り付けましたが、
以下がアクセサリ(仮)の装着画面です。

アクセサリ装着画面

アクセサリ装着画面

アクセサリごとにレベルや特性が有り、習得できるスキルや属性が異なります。
(説明のため、「指輪(リング)」という事にしてます)
幾つかのスロットにアクセサリをセットする方式で、
他人が育てたアクセサリを装備する事も可能です。

最大レベルは各々8ぐらいですが、「アクセサリの数」によって、
達成感を補うのも、狙いの一つです。

長くなるので続きます。
良いGWをお迎えください。

短編RPG制作 – その5 システム – パラメータをシンプルにした

年度の境目の慌ただしさも少々落ち着いてきました。

MODOも10の大台ですか。
今のところ、特に必要な機能は無さそうですが、
私の場合は完全に趣味なので、楽しそうだという理由だけで買ってしまいそうです。
ドラクエ新作発表とあまり変わらん感覚です。いや、年一回だからKOFか。


承前。短編RPG制作の話。
さて、改造しやすくしたところで、いよいよ本番です。
まず、基本システムで、各ステータスがどのような意味を持つのか?を整理してみました。

コモン208:【基本システムVer2.10説明書】にも説明が書いてありますので、
具体的な計算式は省きます。どこで処理しているかだけ記載します。

<基本システム(v2.10)のパラメータ>

#パラメータ何に作用する?どこで処理してる?
1攻撃力ダメージ値コモン165:「X[戦]┗単体処理」の290行目
「技能を使用した場合の処理」
で処理。
2防御力ダメージ値同上。
3精神攻ダメージ値同上。
4精神防御ダメージ値同上。
5敏捷性戦闘時の行動順・コモン157:「X[戦]コマンド登録」で、
 発動者・対象コマンド・敏捷性を紐づけ。
・コモン194:「X┣◆行動順の計算」で、
 上記の「敏捷性」を元に、行動順を決定。
6命中率攻撃の成功率#1と同じ。具体的には
310行目の「【2.1】 成功率が技能依存か武器依存時かで分岐」
という個所。
成功率が0%以下ならミス。
7回避率攻撃の成功率同上。
8クリティカルクリティカルヒット率
(最終的にはダメージ値)
#1と同じ。具体的には、
「【2.5】 クリティカル判定」
という個所。

見て分かる通り、「敏捷性」を除いては

コモン165:「X[戦]┗単体処理」

で処理しています。
当然ながら、このコモンはかなり大きいので、
大改造する場合は、分割してからの方が良いかも知れません(私は分割しました)。

前回までで調べたように、値の受け渡しは至る所で行われて、
なおかつ色々な補正が掛かりますが、大筋は結構シンプルなのが分かりました。

役割がスッパリ分かれてます(※)ので、置き換えもあまり難しくないです。
(※例えば、敏捷性がダメージに影響することはない、という事)

で、いったん、こんな感じにしてみました。

<今回の短編RPG用の新パラメータ>

#パラメータ何に作用する?備考
1攻撃力ダメージ値変更なし。
2防御力ダメージ値変更なし。
3[NEW!] 精神力ダメージ値「精神攻撃」と「精神防御」を統合。
攻撃と防御の割合はT.B.D.
4[NEW!] 素早さ行動順、命中率、回避率、
クリティカル率
「敏捷性」を拡張。
5[NEW!] 運命中率、回避率、クリティカル率、
アイテムドロップ率
新規。
6命中率(隠し)攻撃の成功率変更なし。
ただし、プレイヤーには見せない。
7回避率(隠し)攻撃の成功率同上。

「命中率」と「回避率」については、さすがに独立して残さざるを得ないようです。
鳥系モンスターのように、極端に攻撃の当たりにくい敵など、
対象者ごとに固有値として持つ必要が有るため。
ただし、プレイヤーには見せず、「運」と「素早さ」によって決まる値とします。
おお…何だか、運がめちゃ重要だ(笑)

ちなみに個人的にRPGでは、「運」というパラメータが結構好きです。
ゲームによって効果が大きく違いますが、何となく有利になりそうな曖昧さが好きです。
女神転生でも運をよく上げてました。

という事で、具体的な計算式は未定ですが、「運」と「素早さ」を入力とし、
「命中率の増分」「回避率の増分」「クリティカル」を出力とするコモンを
ブラックボックスとして作っておきます。
追い追いチューニングします。

ここまで出来たので、記念写真をパシャリ。ぐっとシンプルになった感じ。

新パラメータ記念写真

新パラメータ記念写真

ためしに戦闘してみたら、意外と戦えました(笑)。
ではまた。続きます。

短編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側のメンテは必要)

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

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