「いけにえと雪のセツナ」遊んでみました。
「刹那」「久遠」といったキーワードから、私の好きな仏教的時間観、無常感が味わえるかも？
と、少し期待していたのですが、そういう話ではありませんでした。
が、普通のRPGとしては楽しめました。同じチームの作品が出たら、次も買いたいです。

ただ、ずっと雪景色が続くのですが、ストーリーやシステムに、もっと雪国である必然性が有れば、
「どこまで行っても変わり映えしない」という印象が拭え、説得力を増したように思います。

---

ところで、セツナを遊んでいて気付いたのですが、
ウディタの基本システムに、数値入力ボックスが備わっていないので、自作してみました。
よくあるこんな感じの、数値を増減するUI部品です。

車輪の再発明になってるかも知れませんが、勉強も兼ねてるので、良しとします。

この数値ボックス、RPGではお馴染みですが、
手元にあるセツナと、真女神転生4Fとでは、仕様が違ってて面白いと思いました。
（上限値をオーバーしようとすると、前者は上限で止まりました。後者はループするようになってました。）

---

承前。
さて、だいたい準備が終わり、自作システム作りに行きたいですが、
その前に、今回なぜ「単純化」にこだわっているのか？を
もう少し掘り下げてみたいと思います。

■理由１：ユーザーが考える事が少なくて済み、分かり易いから。

もちろん、これが一番の理由ですが、他にも理由が有ります。

■理由２：現実世界との親和性を高めるため。

ソフトウェアにおいてユーザーに「何を見せるか」というのは極めて重要ですが、
言い換えると「何を隠すか」も重要という事になります。

テレビのリモコンに電圧調整が付いていても困ってしまうのと同じで、
ユーザーにとって難度が高すぎる、もしくは滅多に触らない機能が、
いつも見えるところに有ると、一気に敷居が上がってしまいます。

とはいえ、この抽象と具象のバランスというのは大変難しく、
ユーザーによって優しい仕様と、実装者にとって優しい仕様が、
トレードオフになる事がよく有るんですね。

「仕様の単純化＝作り易い」という事ではなく、むしろ難しい場合の方が多いと思っております。

私もいつも悩んでいます。で、今回は、私自身の訓練も兼ね、
徹底的にユーザー（ゲームならプレイヤー）に優しい仕様を考えたいと思っております。
今回の短編RPGでは、

「映画や小説に置き換えても、違和感のない言葉を使う」

というのを心掛けています。
例えば、ある映画で、怪物と対峙して

「こいつは防御力が高すぎる、ここは一旦引くべきだ」

という台詞が有ったとします。
これを

「こいつは精神防御力が高すぎる、物理で攻撃すべきだ」

…のように、いかにも特定層向けの言葉が出てきたら、
一気に敷居が上がってしまうでしょう。
こういった傾向をなるべく抑えていきたいという事です。

■理由３：システムとストーリーの親和性を高めるため。

直感的である事には、単に分かり易いという以外にも、
メリットが有ります。

例えば、「精神が強くないと突破できないイベント」等、
戦闘以外の、ドラマ部分にも応用が利きやすくなるはずです。

もし、「精神」が「精神防御力」に置き換わったとしたら、
ドラマとしてはピンときませんよね。

個人的に、古くはFF7のマテリア、サガフロ2のアニマのような、
システムとストーリーが融和したゲームが好きです。

今回は、こういった直感性を目指している次第です。
あくまで「今回は」なので、次回が有れば、
もっとヘビーユーザー向けのものも考えるかもしれません。

ではまた。
次から、いよいよ独自システムに入っていきたいと思います。

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

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

---

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

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

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

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

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

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

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

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

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

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

＜今回の短編RPG用の新パラメータ＞

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

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

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

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

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

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

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

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

---

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

まず、複数のデータベースにパラメータ（攻撃力等）がコピーされて混乱しやすいので、整理してみました。
ステータスを保持する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側のメンテは必要）

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

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

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

---

承前。

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

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

---

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

基本システムでは、キャラクターのステータスとして
以下の８つのパラメータが有り、バトルでのダメージ値が算出されます。
　（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)の値、または増分をワンセットで格納している個所は、
１０か所に有ります（下図）。
それらが必要に応じて同期、ミラーリングされて動作する仕組みになっています。

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

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

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

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

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

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

ではまた。続きます。

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

■プレイ時間：

　３～４時間

■パーティ人数：

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

■マップ数：

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

■システム：

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

■その他：

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

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

---

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

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

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

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

ではまた。