カテゴリー別アーカイブ: 短編RPG制作

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

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

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

短編RPG制作 – その3 システム – ステータスの改造

バットマン vs スーパーマン 公開日に見てきました。
アクション映画は通勤帰りの平日ナイターに限る。疲れて熟睡できます。
ノーランバットマンとはまた違った香りがして楽しめました。


承前

当分の間、本カテゴリ(“短編RPG制作”)の記事は、ゲームシステムなど、中身の話になるので、、
絵的には地味な更新になると思います。

絵や音については、開発後半になると思います。。が、よろしければおつきあいくださいませ。


さて、ウディタの基本的な構造をもっと知っておこうと思います。
今回の作品は単純化を目指しているので、まずは目に付きやすい、
ステータスパラメータの整理から始めました。

基本システムでは、キャラクターのステータスとして
以下の8つのパラメータが有り、バトルでのダメージ値が算出されます。
 (HP/SPといった消耗ステータスは除きます。)

(1) 攻撃力
(2) 防御力
(3) 敏捷性
(4) 精神攻撃
(5) 精神防御
(6) 命中率[%]
(7) 回避率[%]
(8) クリティカル[%]

このうち、(4)~(8)に関しては、
普段RPGをプレイしないようなプレイヤーにとっては、とっつきにくいかも知れません。
精神攻撃と精神防御のトレードオフを楽しむ戦略も有ると思いますが、
今回のゲームでは、もっと違う所に戦略性のフォーカスを当てたいです。

そこで今回は、以下のようなシンプルな構成に再構築したいと思います。

(1) 攻撃力(そのまま)
(2) 防御力(そのまま)
(A) [NEW] すばやさ(≒敏捷性)
(B) [NEW] かしこさ
(C) [NEW] 運の良さ

「(3)~(8)」を、「(A)~(C)」にマッピングするイメージです。

思いつきなので、詳細は、作っているうちに変わるかもしれない。

さて、この「変わるかもしれない」というのが重要かつ厄介で、
将来的には「魅力」などのパラメータも入れたくなるかもしれません。

さらに、この改造はそうそう簡単ではありません。
基本システムのDBで、(1)~(8)の値、または増分をワンセットで格納している個所は、
10か所に有ります(下図)。
それらが必要に応じて同期、ミラーリングされて動作する仕組みになっています。

ステータスを保持しているDB

ステータスを保持しているDB

現状、ステータスの種類が増減するたびに、上記のDBを設定/参照している処理の
全てに手が入る事になります。
今後、ずっとそのメンテナンスを続けるのは骨が折れます。

というわけで、まずは今の仕様を一切変えずに、改造をしやすくする仕組みに作り替えたいと思います。
いわゆる、リファクタリングです。

リファクタリングは、オブジェクト指向を駆使すると非常に強力なのですが、
ウディタは、現段階ではカプセル化を初めとするオブジェクト指向的機能をサポートしていないので、
今の仕組みで、やってみたいと思います。
今のウディタでも、工夫次第で、改造がだいぶ楽になります。

また、広く浅く基本システム全体を触ることになるだろうので、勉強にもなるだろう、という目論見です。

リファクタリングに興味のある方は、
Martin Fowlerの名著「リファクタリング」を一読してみると良いと思います。
※この書籍は、オブジェクト指向設計が前提です。

リファクタリングを使いこなせば、大きなプログラムを闇雲に改造して
破綻するような危険性が減ると思います。

ではまた。続きます。

短編RPG制作 – その2 ゲーム概要

承前
さて、少しずつでも書いていこうと思います。
過去のエター経験から、あまり大風呂敷を広げないという事も重要と学びました。
というわけで、以下を目標とします。

■プレイ時間:

 3~4時間

■パーティ人数:

 1~2人
  プレイ時間から考えると、あまり沢山は管理できないだろうという見積です。
  その分、密度を濃くしていきたい。
  しかし、市販RPGで、2人パーティってあんまりないですね。
  バランス調整が難しいのか、物足りないからか。
  2人でも、たぶん破綻はしないはず(システム次第)と思う。

■マップ数:

 未定ですが、町や村などは沢山置かず、1か所を拠点にするタイプにしたいと思います。
 NPCが沢山いると、フラグなどの管理が大変そうだから。
 ダンジョン数は考え中。

■システム:

 ウディタの更なる深い理解も兼ね、基本システムを改造した、
 ドラクエ式システムにオリジナル要素を加えたものにしたいと思います。
 ノンフィールドRPGやローグライク、アクションRPGにも惹かれるのですが、またいつか。

■その他:

 ストーリーやキャラクター等は、白紙です。
 下地(システム)が出来たら、それにマッチするものを追い追い考えていきたいです。

 お絵描きしたいのは山々ですが、どんなに優れた映像も、ゲームとして退屈だと台無しになるので、
 プレイフィールであったり、インプットに対するアウトプットの面白さを最優先させたいと思います。
 という事で、システムが最優先。


さて、パーティ人数を1~2人に決めただけでも、出来る事は有るものです。
たとえば、メニュー画面。
基本システムでは最大6人パーティが前提のため、
メンバ数が2人の時は、下に大きく隙間が空きます。

基本システムのメニュー

基本システムのメニュー

これに対し、パーティ数が最大1~2人であれば、
1人当たりのステータス表示を大きく出来るので、そのぶん「攻撃力」など情報量も増やせます。

自作メニュー(1人の場合)

自作メニュー(1人の場合)

自作メニュー(2人の場合)

自作メニュー(2人の場合)

これにより、「装備」画面を開く事無く、ステータスを確認出来ます。
たった1手順の節約ですが、こういったUI設計で、
目的の情報に到達するまでの「手順数」は大変重要です。
これについては深~いので、また別途書きたいと思います。

ちなみに、キャラクターは仮置きです。最終的には別物になります。
が、当分の間世話になるでしょうので、期待を込め、仮置きボーイ/仮置きガールの
称号を与えておきます。

ではまた。

短編RPG制作 – その1 はじめに

もう春ですね。
最近、家ではウディタ(Wolf RPG Editor)をいじってました。

160321

これまでRPGツクールのようなツールを触った事が無かったのですが、
フリーゲームで面白いのが沢山あるので、自分もやってみたいと思ったのが始まりです。

他のエンジンでなく、ウディタを選んだのは、無料なのと、
実行ファイル(ゲーム/エディタともに)がコンパクトだからです。
インストール不要で、提供も楽なのは大きいです。

しかし、触っているだけでも楽しいですね。
私にとってはウディタ自体が壮大なRPGです。

正直、扱いはかなり難しいですが、クセみたいなのが分かってくると、どんどん進むようになります。
こんな面白いツールに今まで着目しなかった、自分のアンテナの低さがうらめしいです。

で、成果物は?というと、10分ぐらいの超短編は出来ました。
(…とても公開できる物ではないので一人で楽しんでます)

「基本システム」という、ベーシックなRPGなら比較的簡単に出来るシステムが提供されているので、
こちらのサイトを参考にさせていただき、全体の流れをつかむ事は出来ました。


で、次は3~4時間ぐらいの規模の短編を目指しています。
今回の記事から、開発日誌という事にしたいです。

さらに、ゲームシステムも一歩踏み込んで、オリジナルにしています。

とはいえ、一から作るには、まだノウハウが足りていないため、基本システムを改造したものにします。
制作にあたり、ひとつだけ心に決めているのは、

「単純化する事」

です。

新しいシステムを追加するにしても、複雑化する方向にはしないという事です。
また、使わないものは積極的に削除します。

SFCの頃のRPGのような、単純なインターフェースで
ゲーム部分に集中出来るものを目指したいと思います。

ちなみに、私はゲームプログラミングに関しては素人なのですが、
幸か不幸か、IT業界歴がそれなりに長いです。

職種は、厳密にはプログラマーではないのですが、
「コスト削減」「生産性」「効率化」「品質」等々については、
日々厳しく求められる環境にいます。

その地の利(?)を生かし、ゲームに限らず、ソフトウェア開発の観点から、
ユーザビリティや、開発プロセスの効率化などに着目した記事も書いていきたいと思います。

ではまた。