投稿記事

ニル 2021/05/06 10:48

『名もない正義の物語』 クリアしました!

名もない正義の物語

ダウンロードページ
https://www.freem.ne.jp/win/game/23378

作者様 Twitter
https://twitter.com/tsukayama2020

SFC時代の古き良き名作を彷彿とさせるRPG(完結済)

とある姉妹が魔法学校に入学し、
そこへ転校生がやってくるところから始まる物語。

なんやかんやあって世界を旅することになっていきます。

学院生や街の人や会話が作り込まれている他、
本棚・タンスに始まり、花、木、樽等、至る所が調べられます。

多すぎて妥協することになりそうですが(自分は妥協しました)
妥協しても詰んだりすることはなさそうです。


にしても、キャラクターの立ち絵がオリジナルで可愛いのはとても魅力的ですね。
改めて強く感じました。

戦闘アニメの豊富さ

戦闘のアニメーションは武器を持った状態でアニメーションが描かれています。

それがそれぞれの技の見た目の良さやオリジナリティを強く引き出しているなぁと。
作るのは大変だったに違いないと思いますが、
クオリティが高く、かっこいい技が多いです。

上位互換・下位互換の存在しにくい装備システム

もちろん、一部には上位互換・下位互換が存在するものの、
基本的に装備品はベースの能力に大きく手を加えるものではなく、
能力補正は他のゲームでいう装飾品に近いです。

ショップを覗いてお金足りないなー。
とは感じていていましたが、すぐにお役御免とはなりません。
場合によっては最終装備に成り得るモノもあります。

超強いモノを拾った! とはなりませんが、
作成者側としてみれば、戦闘の難易度を本来の能力を基準に考えられる為、
調整しやすい事や、プレイヤーからしても、
二度と使わない装備がアイテム欄に増えていくのではなく、
使える装備の選択肢そのものが増えていくというのは、
割と面白い試みかもしれません。

おぉ。と思った点といえば、魔導師装備のローブを
『もちろん魔術師でなくても着用可です』としていること。
……確かににそうだよなぁ。と。

ちゃんと話を聞かないと迷うかも……?

最終的なバランス調整は製作者さんのさじ加減であるので、
苦言ではなく、そういう感じ。と伝えておきます。

一応話を聞いていても南東だっけ、南西だっけ?
みたいになったり。

個人的には次の目的地が明確になってるほうが嬉しいですが、
古き良きRPGでも、その辺りが投げっぱなしの場合もありますしね。

ゲーム内で何度か同じ場所を通る事も多いですが、
プレイヤー自身がある程度、地理(フィールドマップ)を把握する必要もあるのかも。

ルーラ・リレミトは無し

フィールドはひたすら徒歩。ダンジョンに潜れば、往路復路で歩くことになります。
普通に考えれば至極当然。故にここは製作者さんのポリシーだと思われます。

ただまぁ、ちょっと楽したいなーと思ったこともまた事実ではあります。

ただ、何度も通ったからダンジョンの形を覚えてる。というのは、
ゲームのキャラクター達とリンクしているとも言えますね。
いっそ、『ここを通るのもn回目ですねー』……みたいな会話があればよかったのかも?

総合的に大変作り込まれた、とても良い作品

であると思います。
自分も製作者として学べる点が数多くあり、とても面白い作品でした。
特にストーリーが好きでした。
もっとキャラ間の絡みが見たいなーと感じるのは、
キャラクターにも愛着が湧いた事の証明でもあるでしょう。

最終メンバーは初期の4人。
セティリナは一瞬格闘家のお姉さんとポジション争いをしたものの存続。
理由はかわいいから。とてもかわいい。

次作があるならプレイしたいと思いましたし、
これ以前の過去作が4つ?あるようなので、
それをプレイさせてもらうのも良いかも。と思っています。

ニル 2021/05/02 22:32

作成したプラグイン一覧

利用規約というかお願いというか

クレジット不要の代わりにノークレームだと思ってください。

私自身の創作を優先する為、基本的にサポートする気が無いという事に理解がある事。
そもそも、技術的に競合解消等は難しいため、競合した場合は切り捨てるか、
自力で競合解消するかのどちらかでお願いいたします。

自分のコードが綺麗であるとも思っていないので、
競合相手に競合解消の依頼をされるのは、私としては望ましい事ではありません。

ある程度、交流のある方からの依頼であれば、
簡単に出来そうな機能追加くらいは考えるかもしれませんが、
競合解消については多分無理ですし、正直やる気もありません。
打診するだけなら、まぁタダですが、期待はしないでくださいね。


尚、プラグイン単体でのバグであれば対応します。
その際には、単体のバグであることをよく確認の後、報告をお願いします。


スキル後にTPBゲージが溜まっているスキル作成

トリアコンタン様のPluginCommonBaseが前提プラグインとして必要

単純に行動後に再行動可能時間までが早いスキルだけでなく、
スキル使用前にはキャストタイムがあり、
スキル使用後は即時行動等のスキル等も作成可能。
その他、特徴を有するデータベースのメモ欄にスキルIDかスキルタイプを指定して、
魔法使用後のTPBを一律25%上昇する装備なども作成可能。

https://drive.google.com/file/d/1BOsEBFdsESVJSZzfIkEH3EKfhLvQb5DZ/view?usp=sharing


TPBキャストタイムの軽減装備等

トリアコンタン様のPluginCommonBaseが前提プラグインとして必要

特徴を有するデータベースのメモ欄にスキルIDかスキルタイプを指定して、
魔法のリキャストを一律25%軽減する装備などを作成可能。

https://drive.google.com/file/d/18nIe1hp1vEi0dwexfFu_S0Ag52EFIdcL/view?usp=sharing


敵味方のバフを参照し、スイッチを切り替える

敵陣営中で最高のデバフランクと味方陣営中で最高のバフランクを計測し、
ターンごとに指定したスイッチを切り替えるプラグイン。

黒い霧や凍てつく波動を前提に作ったので、
『誰が』や、『何のバフか』までは判定していない。

わかるのは誰かが、バフ(デバフ)に掛かっている。まで。

上記の様に凍てつく波動や黒い霧を撃ってくる敵を簡単に作れる。
味方のバフランクを自動計測し、1以上でスイッチON。
そうでなければOFFと自動で行う為、敵の行動パターンに
スイッチに反応した凍てつく波動を入れておけば、
敵がバフに反応して打ち消しに来るようになる。

あくまでバフ。ステートには未対応。

他のプラグインをお借りしてバフ効果を0%にし、参照アイコンを空白にした上で、
良ステートをかける魔法等で、同時にバフをかけておく事で、
疑似的なステート反応も作れる……かもしれない。

基本的にエネミーの行動管理用のプラグインではあるものの、
他プラグイン作者様のスキルの使用制限を追加するような
プラグインと併用する事で、相手が強いデバフに掛かっていたら使える技とか、
逆に味方が強いバフに掛かって居たら使える技とかにも一応使えそう。


https://drive.google.com/file/d/1_9-OBi0EuyKDcusyX0VOvcdP70py8qbk/view?usp=sharing

クリティカルの威力倍率を変更するプラグイン

デフォルトの威力は3倍だが、それを変更可能。
スキル欄に記述を行う事で、クリティカル威力が例外的に高いスキル等を作成可能。

https://drive.google.com/file/d/1Y2mWjAz-cp3MgMfxSv1bp6_ACXiufL2D/view?usp=sharing


職業・または二つ名に指定した装備タイプの武具名を表示

装備を入れ替える度に二つ名や職業名が変わる様に出来る。
デフォルトだと装備タイプ1を指定したりすると、職業 ロングソード みたいになる。

ステータス欄等での表示を変更するだけであり、
職業や二つ名自体を変更しているわけではなく、装備を外せば本来の名前が表示される。
装備可能な称号を作ったりする事を前提にしたプラグイン。

https://drive.google.com/file/d/1Y2mWjAz-cp3MgMfxSv1bp6_ACXiufL2D/view?usp=sharing


アクターコマンドに逃げるを表示

逃走可能な場合にアクターコマンドに逃げるを表示する。
パーティコマンドから逃げるを消したりすることはしていない為、
他作成者様のプラグインとの連携等が前提。

https://drive.google.com/file/d/1PB1Zg6iQZXfO3ZtwlaZPcwXS4DtgjEK1/view?usp=sharing

選択したスキルから別のスキルに分岐する

連撃のようなスキルではなく、何が出るかわからない技。という感じになります。
ポケモンで言えば ゆびをふる のようなスキルが作成可能です。
(分岐先を一つ一つ書き込む必要があるので多くても10個位の分岐が現実的)

90%は普通の技で10%の確率で特殊技に分岐する。みたいな事も可能。

https://drive.google.com/file/d/1wzT9cmcfJdrODfas8b_usU2McFQG9hnd/view?usp=sharing

MV製プラグイン(MZ移植)

以下のプラグインは、他プラグイン作成者様の移植となります。
私(アーヴェル)のクレジットは別に必要ないですが、
利用規約等は移植元のプラグイン作成者様に従ってください。

移植 / TMStatusMenuEx (ステータス表示拡張)

tomoaky様のステータス表示の拡張を行うプラグインを移植したもの。

https://drive.google.com/file/d/1ewFHqBHTOnfbgjKOQa399GQZ-fF1xqy9/view?usp=sharing

移植 / BB_CustomSaveWindow (セーブウインドウ改造)

ビービー様のセーブウインドウ改造プラグインを移植したもの。

https://drive.google.com/file/d/148heVkYedeJIJ69_2AMRXwrXKtLiDH_z/view?usp=sharing

ニル 2020/12/18 05:26

プレツクデー(202012)

プレミアムツクールデー

今までこれにかこつけて何かをしてきたわけではなかったのですが、
なんとなく今日は記事を書いてみることにします。

結局投稿は間に合わなかったですが。

MZに入って

製作に忙しくて書く暇がなかった……という訳でもないのですが。
購入後しばらくは没頭していたので、書く習慣が抜け落ちてそのままでした。

MVで制作中だった あの水平線のむこうには をMZに移行しようとは思ったモノの、
相当数のプラグインを使用していた為、プラグインの移行を待ちながら、
3~4か月で短編を作ろうと思っていたんですね。

目標としては

何度も繰り返し遊べるRPG

で、街とか実際作ってはいたわけですが、
結局、いまいちストーリーが思いつかず、制作スピードもどんどん落ちていきました。

で、プラグインの移植もかなりされてきていたこともあり、
10月頃にこれ間違いなく短編終わらねえな? と見切りをつけて、移植を開始しました。

で、二カ月かけてどれくらい移植出来たかっていうと、うーん……。
なんともまぁ、遅々としていますね。


ただ、移行にあたって、システムだけでなくストーリーにも手を入れているので、
仕方ないかなぁみたいな。

まあ、制作が遅かろうが早かろうが誰に影響するわけでもなく、
焦燥感があったりするわけでもないので、別に良いのですけど。

公開について考えています

11月くらいからゲームの公開について考える事が増えました。
元々は完成してから公開すればいいんじゃね?

という考えだったのですが、周りにいる作成者さんで、
作成中のゲームを公開している方もいらっしゃって、
そのゲームを楽しみにしている自分が居るんですよね。

自分のゲームを楽しみにしてくれるかはわかりませんが、
もしそういう人が居たら嬉しいよなぁと。

ただまぁ、システムに手を入れた関係で作成しなければならない
スキルの数が膨大になってしまい、やっと40%が終わった程度になっています。


どれくらい変わったかというと、MVでのシステムは、
メインクラスはキャラクター固定でサブクラスが選択制。
1職スキル30個。7職で210個だったのですが、

MZでは
下級クラスの最大レベルが 10
応用クラスの最大レベルが 15

レベルアップに連動してクラスレベルが上昇し、
上昇したクラスに依存してステータス上昇。
最大8クラス選択可能というシステムに変更しました。

こんな感じです。


それに伴いクラスの数を7→60に増加。

基礎クラス1つに対して応用クラスを14種。
基礎クラス 4 応用クラス 56という結構豪華な感じに。

下級クラスのスキルは 9個
応用クラスのスキルは 13個

ということで、

4×9+56×13=764

764個のスキルを作成しなくてはならなくなってしまいました。
現在、応用26クラスと下級2クラス分が概ね終わり、
スキル数で言えば300個くらいですかね。
といっても、モーションやアニメーションは後回しにしているものもあるので、
実際はの完成度もうちょっと低そうですが。

ひとまず付与ステートや威力など、使用出来る状態にしている。という感じです。
そもそもスキルをちゃんと決めていかないと、
ステートがどれくらい枠を食うかもわからないんで、
色々とデータベース作業に影響が出ちゃうんですよね。

とはいえ、データベースの作業は飽きてくるので中々辛いものがあります。

ともあれ、これだけのスキルがあれば、進行中に選んだクラスや、
それで覚えたスキル。そして能力値もがらりと変わるので、
何度も遊べるゲームに出来るのではないか……と考えています。

一部ですがこんな感じ。
アイコンも自作しているお陰で、中々いい感じではないでしょうか。

ニル 2020/12/10 00:00

スクリプトの知識がなくても、自分と一緒に簡単なプラグインを作ってみましょう!

ツクールフォーラムアドベントカレンダー Advent Calendar 2020

https://adventar.org/calendars/5074

https://forum.tkool.jp/index.php?threads/【募集中】アドベントカレンダー2020.4530/#post-26453

まえがきの後は、特定スロットの武具の名前を、職業欄に表示するスクリプトを作成していきます。


まえがき(読み飛ばして頂いて構いません)

さて、今年は書く方が不足しているということで、久々にci-enで筆を取ってみたわけであります。

自分は、RPGツクールMV Trinityのps4版を発売直後に定価で購入したのが、初のツクールであり、
紆余曲折あり2019年の春前にMVへと移行してきました。

その時に感動したのが、プラグインという素晴らしいモノがあること。
そして、プラグインを利用するにも、スクリプトへの理解という壁が、何処までもついてまわるという事を実感しました。

競合の問題。欲しいゲーム内情報の取得法。何度も掲示板やSNSで諸先輩方に助けてもらって今があります。

そんな自分の現在はというと、バリバリスクリプトを書けるようになった!
なんてことはなく、初心者の粋を出て初級者にはなっている……と信じたい。
といった程度です。

自分で必要な分のゲーム内の情報を取得したり、
自分用のプラグインを(複雑なものではないです)書いたり、
他の方のプラグインを自分のゲーム用に多少調整出来る程度は、
なんとか出来るようになりました。

画面は現在作っているゲームのステータス画面です。
一応完全自作。頑張って作りました。


教える立場にいるのかといえば、
そんなレベルには達していないと自覚しておりますが、
右も左も分からなかった頃が直近であるからこそ、
特に何が分からなかったかをまだ覚えております。

もしここで自分がおかしな事を書けばきっと諸先輩方が指摘をしてくれるでしょうし、
もうそうなった場合は自分も一緒に学ばせてもらおう。
そして、お世話になった界隈に少しでも還元をと思い、書いていきます。

ぶっちゃけ記事の中で多くの部分に多分とついてしまう程度なのですが、かといって文章中に(多分)(多分)と
書きまくるのはあまりにウザいので割愛しますが、
実際問題、その程度の知識量であるということをご了承くださいませ。

スクリプトに関して、まず何に躓いたのか。

自分が当時、最も始めに疑問に思い、理解に時間がかかった事を書いていきます。

プラグインとはどうやって、いつロードされているのか。

プラグインっていつどうやってロードされてるんだ?
コモンイベントみたいに、呼ぶための命令をすれば良いのか?
もしそうなら、その命令とは?

プラグインコマンドで呼ぶものやメモ欄に記述するもの。
呼ばなくても動くもの。それらが混在することで、
特に、呼ばずに動くものは何故動くのかが当初理解できませんでした。

プラグインへの認識が、お借りして入れると(何故か)動く。
そういう風に作ったのであろうという事は理解出来ても、
それがどういう風に作ったらそうなるのかわからない。という感じでした。


これに関しては、

ゲーム中は常にスクリプトは常に絶え間なく呼び出されているものであり、
何かしら起動しているからです。

イメージ的にはイベントコマンドの並列処理がずーっと走っている感じでしょうか。


そして、プラグインとはコアスクリプトを上書き・或いは拡張するものであり、
コアスクリプトの処理に追加したり、
本来の処理と別のルートを辿らせる事で、
コアスクリプトが起動していく一連の動作の中で、呼び出されていきます。


つまり、然るべき場所(処理の近しい場所)にやりたい処理を追加する事が出来れば、
それだけで簡単なプラグインであれば書くことが出来ます。

例えばクリティカル威力を変更したり、アイテムの取得時にはそのIDをゲーム内変数に代入したり、TP再生を固定値ではなく割合にしたり。リザルト画面を消したり。
などなど。

その為にはまず、然るべき場所とはコアスクリプトの何処であるのかを見つける方法を身に着けなくてはいけません。


今回は例として、ステータス画面に表示されている職業名の場所に、
装備中の防具の名を参照するようにする。……ということをしてみます。

例えばその防具を称号として扱えば、付けている称号がステータス画面に表示される。
ということになりますよね? そんな感じです。

何処を修正したいのか探そう。

コアスクリプトは

rmmz_core
rmmz_managers
rmmz_objects
rmmz_scenes
rmmz_sprites
rmmz_windows

から構成されています。詳しい説明はもう他の方でしてる方も多いですし、
絶対そっち見たほうが良いので割愛します。

何処に入ってるかわからない?
そんなもん何となく分かるようになってくるまで、
全部開いてCTRL+Fで検索掛ければ良いんです。

料理だってそうでしょう?
レシピ見なくても作れたり味見しなくてもマトモな味が作れるようになるには、
それ相応に料理に触れていかねばならないし、
触れてるうちになんとなく分かってくるんです。
右も左もわからないうちは手間がかかる。それはしょうがない事なんですよ。


因みに自分はプラグイン触るときは未だに全部コアスクリプト開きっぱなしです。



今回はステータス画面で、職業の表示です。

まず、statusでコアスクリプト内を検索してみます。487件ヒットしました。
これじゃダメですね。一個一個見ていっても良いですが……。

では、次にclassで検索します。これは176件ヒットしました。だいぶマシですね。
慣れてくればステータス画面の表示だから、
このコアスクリプトの中かな……と絞ることが出来て、
この状態でも簡単に然るべき場所にたどり着けるのですが、
当時は自分もそれが出来なかったので、考え方を変えてみます。

ステータス画面。表記は他にもあります。
最終的に変えたいのは職業の表記ですが、近くには二つ名などもありますね。
処理が近しいものは、大体同じコアスクリプトの中にありますので、
次は二つ名で探してみましょう。

でも職業はクラス。ステータスはステータスでわかりましたが、二つ名とはどう探せばいいのか?

ここでは2つの方法を提示します。

一つ、トリアコンタンさんのMZの非公式スクリプトリファレンスをお借りします。
二つ名と検索することで、

$dataActors[id].nickname

と記述してあります。
二つ名に関するデータがnicknameであると気づければok。


もう一つは、テストプレイ中のコンソールログを使います。
コンソールログは、エラーが出てくる画面。

……だけではなく、下の入力欄に適正な記述を行うと、
ゲーム内のデータを見ることが出来ます。

コンソールログの使い方

テストプレイ中にF12を押すと出てきます。

こんなのですね。


とりあえずこれを開いて。

$gameActors.actor(アクターID).setNickname("変更する二つ名")

次に、こういう記述がどういう意味なのか紐解いておきましょう。
これも正直、自分は理解までに時間をかけました。

. ←は、そのデータ群の中の……或は命令という感じです。
何が情報群で何が命令なのか、分かってくるまで非常にわかりにくいです。
例えばですけど

$gameActors.actor(アクターID).setNickname("変更する二つ名")
↑これはこんなイメージ
植物.野菜(大根).品種名を変えなさい(”おろし”)

一行の中に、何処のデータで何をしろ。
というのが収まっているので理解がしにくかったんですよね。
ここから命令部分を切り落としてしまえば、そのデータを参照出来るものもあります。

カッコの中の数字は何番のIDの情報を見るか。という指定なので、

$gameActors.actor(1)

この記述で見てみましょう。
▶を押してみるとずらーっとデータの羅列が出てきます。

見ていくと、見覚えのある名前が出てくると思います。
自分の場合だと、アクターの名前である ブレン や、二つ名のEクラス冒険者ですね。

このデータを見れることはとても重要で、
ゲーム内情報を得るだけでなく、変更する際にも大きな足掛かりになります。

今回であればアクターの情報はもう見えています。
そして、中の値を書き換えてしまえば、それを変更出来るんですから。

例えばこのコンソールログに

$gameActors.actor(1)._paramPlus[3] =999
と打ち込めば、アクター1番の防御力に999に入れなさい。となります。


HPにも10万入れていたので、職業由来の値と合わせて
HP:10450
防御:1015
のチート使ったみたいなアルドくんが数十秒で完成です。
中の値を見れるということは、簡単に書き換えられるということ。
よって、中の値を発見する事こそ、大事であることをよく覚えておいてください。

ともあれ、$gameActors.actor()の中身を覗いてみたことで、
二つ名は _nickname に入っていることがわかりました。
とりあえず_は抜いて、nicknameでコアスクリプト内を検索をしてみましょう。

そうすると、14件しかヒットしません!
これなら絞り込めそうですね。

色々見ていくと、いかにも怪しげな

という記述が見つかります。名前、クラス、ニックネーム。
それと、window_Statusという名前。

そうです、ここはもう然るべき場所の一歩手前です。

this.はとても難しいのですが、
今回の場合は、現在の参照値と同じ名を持つフロアの。というような感じ。

ここで、本来変更したいのはクラスであることを考え、
drawActorClassでもう一度検索します。
すると、3件だけヒットしました。

Window_StatusBase.prototype.drawActorClass = function(actor, x, y, width) {

width = width || 168;
this.resetTextColor();
this.drawText(actor.currentClass().name, x, y, width);

};

そのうちの1件がこれ。
drawTextというのは、非常によく出てきます。
文章を表示している命令です。
これは、actor.currentClass().nameをx座標はxにy座標はyに幅widthで記述せよ。と言った感じ。


ここが目的地です。お疲れさまでした!
俺ももうかれこれ、3時間くらい記事書いてます。疲れてきました。

これをプラグインにする。以下をコピーして貼り付け

/*============================================================================
syokugyouhyouziwohenkousuru.js
---------------------------------------------------------------------------
(C)2020 あなた
This software is released under the MIT License.
http://opensource.org/licenses/mit-license.php
---------------------------------------------------------------------------
Version
1.0.0 2020/12/09 初版


[Blog] :
[Twitter]:
============================================================================/
/
:
@target MZ
@plugindesc 職業表示を変更する
@author あなた

*/

(() => {
//ここから必要な記述を行う
Window_StatusBase.prototype.drawActorClass = function(actor, x, y, width) {

width = width || 168;
this.resetTextColor();
this.drawText(actor.currentClass().name, x, y, width);

};
//ここまで必要な記述を行う
})();

↑ここまで

これに、適当な名前をつけて拡張子を.jsで保存します。
メモ帳の場合はUTF-8じゃないとダメだったかと思います。

自分も暫くメモ帳をつかっていましたが、エディタをオススメされまして。
実際、色分けされているとコードの意味がわかりやすいので、
そういった機能があるやつを使うほうが良いかと思います。

因みに自分はatomですが、他人にコードを見せる(相談する)
場合に自動整形するなりして、せめて見やすくするのは最低限度のマナーである。
……みたいな事を目にして、なるほどじゃあ自動整形機能があるのにしようと、
最初に目についたのがこれであったというだけで、その他に特に理由はありません。

諸先輩方がきっとおすすめを教えてくれることでしょう。



で、これを普段使っているプラグインと同様の場所に入れて、ゲーム内からいつもどおりに入れれば、あなたのプラグインが完成しました!

とはいえ、このプラグインは、
コアスクリプトを全く同じ記述でを上書きするだけのものです。
現実的には、競合を引き起こす可能性があるだけのプラグインということになります。


ここで競合についても少しお話します。
今回、プラグイン化にあたって、これ↓の中身を改変します。

Window_StatusBase.prototype.drawActorClass

プラグインはコアスクリプトに対して、上に置いてあるものから上書き保存をして、最終的に出来上がったものを、あなたのゲームで起動します(多分)

プラグインの競合というのは、この過程で、
同じものを複数の場所で上書きした時には必ず起こります。

クリティカル威力は本来の威力の100倍にせよ。

と、コアスクリプトに上書きをした後に、

クリティカル威力は本来の威力の1000倍にせよ。

という上書きをすれば、片方は機能しなくなりますよね。そういうことです。
これが、クリティカル計算の値を100倍する挙動を、本来の挙動にプラスせよ。
みたいな書き方になると、挙動の追加が積み重なり100000倍になったりしますがー。


とりあえず概要の話なのでここでは置いておきます。


さて、次にプラグイン化した方の記述を変えていきます。
これが職業を記述している項目です。

this.drawText(actor.currentClass().name, x, y, width);

では、これをどうしたいのかを考えます。

称号の装備がない時は、職業本来の名前を表示し、
称号があるときはそれを優先表示することにしました。

はい、どーん。 ……流石に疲れてきたので。

改変後

Window_StatusBase.prototype.drawActorClass = function(actor, x, y, width) {

width = width || 168;
this.resetTextColor();
if ($dataArmors[actor._equips[4]._itemId] == null) {
  this.drawText(actor.currentClass().name, x, y, width);
  return;
}
if (actor._equips[4]._itemId == 0) {
  this.drawText(actor.currentClass().name, x, y, width);
}else{
  this.drawText($dataArmors[actor._equips[4]._itemId].name, x, y, width);
}

};

ここまで

actor._equips[4] というのは、アクターの装備で5箇所目を意味します。
プラグインとかで変化していなければ、装備画面で上から5番目の位置です。

そこを参照します。
actor._equips[4].itemId
となると、装備画面で上から5箇所目の装備エリアのアイテムのIDとなります。
今回は5箇所目に防具を装備しているので、防具のIDを参照します。
プラグインで弄らない限りは0番が武器でそれ以外は防具ですが。

$dataArmors[].name

というのは、防具データ[]番の名前を参照する。ということです。
つまり、この2つを合わせて

$dataArmors[actor._equips[4]._itemId].name

こうなると、五箇所目に装備中の”何か”のIDと同じIDを持つ防具の名前を参照せよ。です。

this.drawText(,x,y,width)は少し難しいのですが、

そもそも、大本のこれ↓が呼び出された際、
Window_StatusBase.prototype.drawActorClass

actorとxとyとwidthの数値を受け取ってきています。


Window_Status.prototype.drawBlock1 = function() {

const y = this.block1Y();
this.drawActorName(this._actor, 6, y, 168);
this.drawActorClass(this._actor, 192, y, 168);
this.drawActorNickname(this._actor, 432, y, 270);

};

この中にある、

this.drawActorClass(this._actor, 192, y, 168);

呼び出し元のこの記述ですね。
this._actorはこの場面では、ステータス画面で選択中のアクターを指します。
xは192と指定され、yはblock1Yというところから取ってきたモノを、更に渡しています。

因みにblock1Yを追いかけると、

Window_Status.prototype.block1Y = function() {

return 0;

};
となっています。returnというのは、これが呼び出された時には右の値を返せと言うことなので、0を返します。

つまり、block1Yは0です。block1YをYという名前に変えて、
値はそのままに現在プラグインで作成中の、
Window_StatusBase.prototype.drawActorClass に持ってきたということですね。


Window_StatusBase.prototype.drawActorClassの中で
先程説明した actor._equips[4] ですが、アクターの番号の指定がないのにも関わらず、それがID何番のアクターであるかの情報を持っていたのは、直前に受け渡されている

this.actor が何番のアクターであるかの情報をもっていて、それをactorという名前で受け取ってきているからですね。


……俺のこんな説明でわかるでしょうか?
同じ actor に見えるのにある場所ではカッコが付いて番号指定があったり、
ある場所では直接参照しているように見えたり、理解がし辛いと思いますが、

その文字列に拘って見るのではなく、それに入っている情報が
何処からきた情報であるかを追っていかないとダメ。ということですね。

ここでお役立ち情報。

これなんの情報持ってんだよって思ったときには

console.log();

をスクリプトの間に記述してみましょう。


Window_StatusBase.prototype.drawActorClass = function(actor, x, y, width) {

width = width || 168;
this.resetTextColor();
this.drawText(actor.currentClass().name, x, y, width);

};


例えば今回の大本。改変前のこれで言えば、actorとかthisなんかはわかりにくいですよね。こんなときは


Window_StatusBase.prototype.drawActorClass = function(actor, x, y, width) {

width = width || 168;
console.log(this);
console.log(actor);
this.resetTextColor();
this.drawText(actor.currentClass().name, x, y, width);

};

のように、記述することで、thisとactorが持っている情報をコンソールログに出力せよ。という命令になります。この状態でテストプレイを開始し、F12でコンソールログを開けば、該当した場所が呼び出された時に、このスクリプト内の何行目の出力結果がこれ!

今回であればステータス画面を開いたりすると、コンソールログが出力されると思います。このように console.log(); は値の特定に極めて役立ちます。

困ったら console.log(); です。
勿論、カッコ内に何を出力させるかの指定を忘れずに。


こんなものでしょうか。
……プラグインを書いたりしていたら7時間もかかってしまいました。

今回書いたのはステータス画面用に。ではあるのですが、

Window_StatusBase.prototype.drawActorClass

は機能が最小限で、とても汎用的なモノなので、
ステータス表示の一環として、スキル欄での職業表示でも呼び出されているようです。
なので、特に何もせずともステータス画面と同様に防具名になったりします。

その他のプラグイン独自のシーンに呼び出されているケースもありますし、
その場合でも、

Window_StatusBase.prototype.drawActorClass
を呼び出しているのなら同様に特に何もせずとも変更されます。


さ、これで自分の記事も終了です。


誰かのお役に立てば幸いです。
そして、間違いの多い記事だったら大変申し訳ありません。


最後に、完成後にもう少し使いやすくした状態のプラグインです。
職業名か二つ名の表示欄に武具の名前を表示させるプラグインは
スクリプト内に注釈を書きまくりました。何かの役に立てば幸いです。


そして、以前Twitterでひっそり公開したプラグインの再掲示もしておきます。

職業名か二つ名の表示欄に武具の名前を表示させるプラグイン

https://drive.google.com/file/d/11fgMnFm9sEArMJyab8Q8A9gz_0QPHbJ7/view?usp=sharing

TPBにおいてスキル後にゲージが溜まっているスキルや装備がつくれるプラグイン

https://drive.google.com/file/d/1BOsEBFdsESVJSZzfIkEH3EKfhLvQb5DZ/view?usp=sharing

TPBにおいて、キャストタイムを軽減するスキルや装備が作れるプラグイン

https://drive.google.com/file/d/18nIe1hp1vEi0dwexfFu_S0Ag52EFIdcL/view?usp=sharing

ニル 2020/08/16 20:47

RPGの雑魚戦について考える

制作者としてはRPGの雑魚戦ってすごく難しいと思っていて、
そもそも本来は面白くないモノだと思うんですよ。

逆に、行動1つ1つにメンバーの生死が掛かっているような、
手に汗握るようなボス戦は、RPGの華であるとも思っています。

ただ体力が高いだけじゃない。理不尽に攻撃の威力が高いだけじゃない。
相手の行動パターン次第、つまり運だけで全滅が決まるかもしれない戦闘じゃない。

それでいて、プレイヤーに常に最善手を要求してくるボス戦というのは、本当に面白い。
思考をフル回転させているのにギリギリの戦いになる……が、ギリギリでプレイヤーが勝てるようにする。


これは制作者とプレイヤーの知恵比べとも言えると思います。
そうして出来た傑作のボスというのは、
報酬なんて無くてももう一度戦いたくなりますよね。


ただ、雑魚戦闘はそうじゃないんですよね。
そんな一々雑魚に5分~30分取られるような戦闘は流石にテンポ的にも論外ですし、
プレイヤーだって疲れます。

そうなると、つまり敵を弱くしなければいけない。
弱いという事は、最善手でなくとも倒せるという事。
次に何をすれば勝てるのか、戦闘開始時に既に理解している。
それは思考の余地が無い事を意味します。

それって、つまりつまらないんですよ。
例えば親戚の5歳の子供なんかと腕相撲をして勝つのは楽しいでしょうか?

最初から勝つことが分かっているゲームそのものは基本的にはつまらないんですよ。

そうなると、プレイヤーは”支払う時間”と”報酬”と釣り合いが取れるかを考え始めます。
それは経験値だったりドロップアイテムだったり。

経験値0でドロップも無いが、攻撃は低く、HPだけ高いような敵が居たとしたらどうしますかね。その情報を知ってたら当然逃げますよね。
もし知らなかったら、こんなにめんどくさい相手なのだから報酬は素晴らしいに違いないと思いながら倒すと思います。図鑑見たら唖然とすると思いますけど。


つまり、雑魚戦において正攻法で楽しさが見いだせない場合、
最も大事であるのは報酬なわけです。ここを正攻法でクリアする。

雑魚戦が楽しすぎて報酬が無くても戦いたいRPGがあれば、
本当に革命的システムだと思います。


例えば、エンカウントして3秒で敵全体を瞬殺出来るのは面白いかもしれません。
それは報酬があるからこそ、得るものがあるからこそ、成長があるからこそ、
”報酬”に楽しみを感じているだけで、雑魚戦闘そのものの楽しさではありません。

ただ、戦闘と報酬が直結している以上、
戦闘のつまらなさを誤魔化すかなり有効な手ではあるとも思います。


そもそもプレイヤーは邪魔はされたくないんですよね。例えば謎解きやマップ検索を。
或いはイベントシーンを見たいわけです。

だから邪魔しない程度にしなきゃいけない。

雑魚は雑魚らしく退場し、一番やりたいことを中断させて、
プレイヤーが消費した時間に見合う報酬を与えてあげなくてはいけない。

成長が楽しいゲームは、雑魚との戦闘自体をプレイヤーに強く働きかけるので、
根本の改善ではないですが、雑魚戦がつまらないという課題を
報酬の美味しさによりクリアしていると言えます。

ポケモンなんかはわかりやすいでしょうか。
戦えて捕まえれば仲間になってくれるなんていうのは、報酬として素晴らしいです。

それで、そもそも街道は整理されており、
自ら草むらに入らないとエンカウント無視できる個所も多く、
虫よけスプレーに代表されるスプレーでエンカウントを無くす事も出来る。

障害であるトレーナー戦も、ある程度は無視が可能です。
ただ、トレーナーはそもそも連続戦闘が可能な為にレベリング効率が良く、
(同レベル同一ポケモンの野良よりちょっと経験高いような気もする……?)

野良ポケモンと異なり賞金という報酬もあるので、
足止めされても実は美味しいという側面があります。

ドラクエで普段逃げていても、はぐれメタルをみたら目の色変えて殴りますよね。
比較対象と比べてレベリング効率が極めて良いからです。


……その辺りを考えると、ボーナスモンスターの存在も結構大事なのかもしれませんね。


レビューで戦闘の高速化が望まれているフリーゲームとかもありますが、
それってつまり望まれてる時点で、
その人にとってはそのゲーム雑魚戦はつまらないと感じられちゃってるんですよね。

制作者としては他人事じゃないですね。怖い。


思考の余地が無いからつまらない。報酬が欲しいから戦う。
思考の余地が無いが、戦闘の必要性があるという雑魚相手に、
プレイヤーが帰結するのは、如何に瞬殺出来るか。になってくると思います。

自分もかなりそういうタイプの人間で、色々なゲームで雑魚は開幕瞬殺狙いです。
或いは、報酬が美味しくないと判断したゲームでは、
ボスに勝てなくなるまでエンカウントを回避します。



さて、ここに対する回答の一つ。
根本の改善でもある”雑魚戦闘を面白くする”という事を可能にした稀有な例が、
ガンビットというシステムだと思うんですよ。

ガンビットというのはFF12の戦闘システムの一環で、
自分で事前にAIに命令を組み込んでおき、戦闘時に実行してくれるものです。

こういう系統のシステムは、そもそも好みが分かれることは理解しているのですが、
自動で自分の思った通りに動く。というのはそれだけで面白さがあるんですよね。

装備やスキルツリーで最適解を考えていくのと同様に、
行動に対して最適解を与えてあげる。これは非常に面白い事です。

アツマールにて、そういうゲームがあるので紹介しておきます。

かってにバトル勇者

https://www.freem.ne.jp/win/game/18641
https://game.nicovideo.jp/atsumaru/games/gm8523?link_in=search-word

kikigero さん 作

雑魚戦闘の問題点は勝つことが分かっていて何をしなきゃいけないかも明確であるのに、
一々コマンドを要求され、時間を取られることが一つの大きな問題です。
これ自体はオート戦闘でも解決できる事ですが、そこに面白さはありません。

この差こそが、自分でAIを組む事と、オートバトルオンリーの差なんですよね。

自分の意思をAIに反映させる。コマンド入力の時間が減り、
見ているだけで敵をガンガン倒してくれる。これってかなり楽しい事なんですよ。

手動でも出来るゲームであれば、全自動プレイなんていう遊び方も生まれます。


自分はこのシステムに心酔しているので、何が何でも実装したい機能の一つとなります。
正直全てのRPGに標準搭載されてたら嬉しいレベルなんですけどね。

いやまぁ、先も言ったように好みが大きく分かれているのも理解してはいますが。
敷居がそもそも高いようなんですよね。


……とまぁ、これが雑魚戦における一つの回答だと思っていて、
自分のゲームでは雑魚戦を任意で自作AIに戦ってもらうという事で、
雑魚戦の煩わしさを解消したいと考えていたりします。



誰かガンビットプラグイン作らないかなーというのは、
まごうことなき本心なのですが、それだけをアテにしてもしょうがないので、
一応、自分でも考えてはいます。
絶対的に知識が足りないので現時点では作れないのですが。

ガンビットシステムを作るには

現時点で今後なんとか作成出来る可能性がありそう(現時点では無理)なのは、
Scene Equip (装備シーン)を元にして、
防具の2~7番くらいまでを通常の装備シーンで。

同様に防具8番~32番までしか表示しない装備シーンとかを作成して、
オート戦闘時に、通常の処理ではなく、
参照しているスロットIDに装備しているアイテムのIDから、
行動を割り出して入れ込むというものです。

やなさん のスキルCP制プラグイン等を見ていると、装備ではなくても、
装備に近いシステムを設定できるのは分かるのですが、これは自分には無理そうなので。


その為に必要なのは装備に近いシーンの作成なのですが、
そもそもこれが出来てない。

まぁ、見た目を無視すれば、装備シーンで33個の装備が出来るようにしてしまえば解決するので、最悪その状態でMVプラグインの移植を待ちながら、
短編のゲームを作ってみようかとかも思っています。



次に、オート戦闘のフラグが経っている時にそれを参照するように、
オート回りのスクリプトを書き換えなくてはいけません。
最悪これは、行動予定のスキルIDさえ最後に与えてやれば良いので、
コモンイベントを使いまくって処理する事で何とかなる……かもしれません。

行動予定スキルを割り込ませる事自体は、
割り込み位置を割り出したので一応出来ているので……。



単純に戦闘行動の強○で動かそうとした場合、行動順の問題が重くのしかかるんですよね。敏捷性だったり、スキルの速度補正だったり。

だから自動戦闘で”行動予定のスキル”に割り込ませたい。


いや、ほんとスクリプトって難しい。

6 7 8 9 10 11 12

記事のタグから探す

月別アーカイブ

限定特典から探す

記事を検索