RPGツクール素材メモ とかティラノスクリプトの話とか

同人RPGの制作で役立ちそうなスクリプト・プラグイン素材を書き留めておく

コミックマーケット(C97)4日目で買った同人誌、感想vo3

往年のゲームブック火吹山の魔法使いをステートマシン図で表記する本

booth.pm

ステートマシンというのは、UML(この単語でぐぐれば出てくる)の一種とも言われ、
身近な例で言うと、BSさんとかがツィッターで、
Unityのアニメーション制御で状態(ステート)を点で繋いだり して、
遷移を表したりしてるでしょう。
多分、あれ。

私と、このUMLの初遭遇はドリームスタジオ(2000年、ドリームキャスト)
だったのだが、これはデフォで用意された3Dモデルをいかに動かすかという課題に、
状態の□があり、その入口と出口に最大で4つの線を繋げられる、という風に応えていた。
(□の頭と尻に4つの穴が開いてるという分かり易さだった)
状態から状態に繋げられるのは4本の線までであり、
確かその線を繋げる穴ごとに条件を設けては、連結していったのだ
(ちょっと基盤回路にも近い発想だったのか?)

ところで私は自身の[エロトラップダンジョンクリエイター]で、
階層のジャンプを設け、そして各階では予め設定されたトラップが抽選される……という実装をして、
このトラップが実行される条件は、
左項 中項 右項
という形式に決めた。
そして左項は必ず変数であり、中項は演算子である(+や−)、など……。

言わばこういった規約が、実装する側の難度であったり、
あるいはユーザー視点での作りやすさなどを分けるのだが、うーん……
既に勘の良い人には分かったろうか、UML図が
「遷移する条件を決める」のに対し、
エロトラップダンジョンクリエイターでは、まず各階への遷移ありき、
その上で、条件に合わせた罠を実行する……となっている。
では、どの条件にも当て嵌まっていなかったら?
実行される罠は無く、エラーである……
これは実際的にやってしまいがちで、しかもエラーの原因を割と把握し辛いんじゃないだろうか…?

人は新しい物を作ろうとする時にも、無意識に自分の経験から類似したものを頭に描くのだろうか、
この条件式は自分も長く触ってきた、
RPGツクールがやはり念頭にあったのだと思う、
ツクールのページ実行条件とかなり似ているから。
(そしてその割に、ヘンにUMLぽい遷移の悪い所も抱えてしまっている、のではないかと…)

しかし省みるに、ツクールのイベント実行条件というのも……、あれ、いつからや?
自分が知る限りでもツク2000、いや俺は知らぬが、
Dante98シリーズというのがその前にあったそうだから、
それが同じ機構ならば、もう今年で25年モノという具合になるな。

設計というのはなかなか古くなりにくいとは言え、
ドッグイヤー(犬の耳……、嘘、犬年)とも言われるこのソフトウェア業界で、
25年前の設計がそのまま最新のツクMVでも現役って、何か、スゴイね。
正直引くわ。
いい加減古いのでは、RubyになったりJavaScriptになったり手を変え品を変えしてるけど、
基本構造は変わらないままどんだけ稼ぐねんというのは、
一歩ツクールの外から出ると、割と気付いちゃう所ではあって
(例えばアニメエディタ……、
幾らなんでも今ではもっと作りやすいアニメエディタがあったりして、
JavaScriptでその書式を解釈して実行する事だって出来るのに、
標準付属のアニメエディタは、2020年になってもずっとあの作り辛いままなのだ……)

そろそろクドクドと長くなって来たね、
要はツクールの構造もさすがにもう古い、じゃあ何が新しいんだ? という時に、
いま申しましたように、UMLってのがUnityでは採用されてるようだね、という背景がありまして、
(言うて、UMLの歴史ももうかなり長いが…)
コミケで当該のような本を見掛けたら手に取りますよね、という事で。

あともう一点これには経緯もありまして、
例えば先週もちょっと触れた[https://www.dlsite.com/maniax/work/=/product_id/RJ272052.html:title=[アドゥスタ海の孤島]]
とかもそうなんですが、最近、これはというようなゲーム作家さんがアナログゲーに回帰してたり、
あるいはゲームブックなんて線を抑えているようだと。
そしてそんな彼らは、不思議と”外さない”のだ。
素養があって、ちゃんと毎回面白いゲームを仕上げてくる。

一体そこに何が隠されているのだ?
しかしTRPGとかも気になるけど、言うても所詮あれはコミュ力高めの遊びやからな……
と諦めてた所で、しかし「火吹き山の魔法使い」とは俺も聞いた事があるくらいの
ゲームブックの名著よ、これは気にならないのが嘘でしょう……。


本の内容としては、ゲームブック、皆も子供の頃はにゃんたんの大冒険とかやったよね、
その初めから最後までの展開を(途中、やや端折りつつ)
UML、ステートマシン図で書き起こすという本。
(この工程を”モデリングする”と呼んでいる。
ゲームで起こり得る状況をUMLモデリングする……、これも何か設計が現れてる言葉だ)
それによって、ステートマシンを学ぶずら、という運びとなっている。

先般の事情の通り、これが自分にはとてもグッドフィールで、
ソフトウェアの設計としても、ゲームの設計としても、感じ入る所がありました。
(興味無い人には「何か味気ない、工業的な図解と解説文がずーっと載っている」なのかも知れないが……)

例えば現在のJRPGだと、戦闘からの「逃亡」の扱いは確率、
最近のエロゲだと逃亡率100%とか謳っているのもあり、
この時点で別の意味へスライドしているのだが、
ゲームブックの代表作と言われる「火吹き山の魔法使い」はどうしているか。
なんと「逃亡は100%成功する、ただしHPが-2必ず引かれる」と。
そしてこの逃亡するかの判断も上手くて、
まず敵と一合、攻撃の判定があった後に判断するらしいのだ。

攻撃の判定は、
自分の技術点や敵のそれと、ダイスの結果を合わせた結果で判定する。
これは例えば
敵 10
自分 11
だったら、自分の勝ちな訳だが、しかし重要なのは
(……具体的な段取りは本書には書かれておらず、推測になるけども。
考えてみると、ゲームブックでやるのは厳しそうなので、自分が良いように捉えてるだけかも?)
自分の技術点も分かるし、ダイスの目も分かる、
だが敵はトータルの数値は分かるけど、
敵の基本能力やダイスの目は分からない、って事なのだ。
つまり敵の技術点が実は1で、ダイスの目が2つ合わせて9だったのかも知れない。
これはどんどん強気に行くべきだろう。
でも敵の技術点が本当は8で、ダイスが2だったとしたら?
これは続けるには分が悪い勝負で、HP-2を払っても逃げた方が、賢い選択と言えるだろう……

ちなみに攻撃判定の後のダメージも、
「純粋に数字が上な方が、その場で指定された分を相手のHPから引ける」
らしいのだ。
これはもうデジタルなRPGに慣れた身には割と衝撃で、
例えば「上回ってる値の分だけ、相手のHPを削れる」
とか、自分のパラメーターを派手に反映させたくなる所ではないだろうか?
でもその場で指定された、定数なんだなぁ……と感心。

これはソフトウェアの設計的にも面白く、
例えばRPGツクールで、
「ここで敵のHPから1引く処理をして」と言われたら、まぁ
敵HP - 1
とか何とか式を書くかも知れない、
でも他の場面では「2を引く」「3を引く」
とかもある訳で、まぁこうなったら、うぜぇな、
ダメージ値 = 2
とか変数に代入するから、
敵HP - ダメージ値
とでもやっとけよ、となるだろう。

しかしゲームブックはそういう処理はしない、
机上で遊んだりするものだから、複雑な計算するには面倒いんですよというのもあるだろうが、
これはもし自分がプログラムで実装するなら、
ただ1とか2とか定数を返すだけの関数を、それぞれの分だけ作る
としたら割と面白いかな、と感じた。
こうなると何が嬉しいか、
結果は定数であっても過程では関数なのだから、
関数合成的な考え方も出来るという事であって……、
1という定数に2という定数を足した結果を求めるのと、
1をただ返す関数の次に、2をただ返す関数を続けて実行するのだ(繋げるのだ)
というのは、結構出来る事が違う……。
言わば、この関数の連なり自体がUMLやんけ! と、何か興奮していたのだ
(書き起こしたら微妙な感じになってしまったが、
まぁこちらが入れ込むのも自由なのだ……。まして薄い本、そういう楽しみがあっても良かろう)

そしてうろ覚えなのだが、確か「火吹き山の魔法使い」は、
テーブルトークの方にも逆輸入されたんだっけ?
(……ぐぐってみたが、switch版のゲームしか検索上位に来やがらねえ……くそう、Googleめ……)
本書ではUMLの流れを踏まえつつつも、
例えば「レバーを引いたらそれは罠だった! ただし幸運点チェックを行えば、技術点の下降を低く抑えられるかも」
と触れてるのだけど、これをただ事務的に済まさず、
「幸運点チェックの結果、凶なら利き腕、吉なら利き腕でない方に怪我を負った」
と説明してくれたりするのだ。

これなんか、テーブルトークをする時に、凄く納得が行く説明で……、
この辺りの『語り』が上手い人なら、途端に風情が出て楽しい物になるだろうな、と何か、ありありと想像できた。
(他にも「このエリアでは○○というのがコンセプトで」と各ダンジョンごとに書いていたりもして、
逆に読み取れば、
「なるほど、ゲームマスターはそこを強調する『語り』で、そちらに自然と誘導すれば楽しい感じになる訳か」
なんて予想できたり。
まぁこれも、そもそも自分の勝手な妄想かも知れんが……)

そして「火吹き山の魔法使い」のゲームデザインで特徴的だと感じたのは、
「成功・失敗のメリハリが凄い」という事で、
例えば終盤に差し掛かった所で対峙するかも知れない強敵、
吸血鬼には
「道具を使う」>「(それに先んじて、敵の攻撃の)吸血鬼の視線」>失敗判定なら、そのままゲムオバもあるルートに
成功判定>「(もし持ってたら)木の杭で、即勝利確定!」
という極端さなのだ。
ゲムオバか、ボス相手に即勝利かって。

ただ同時に上手いのが、「その極端な中にも、(納得できる)グラデーションを設けてる」という事。
吸血鬼の例で言えば、道具を使おうとして失敗判定が出たとしても、
もし木の杭を持っていれば、そこでゲムオバになったりはしない。
敵の視線に掛かり金縛り状態になってしまったが、
その場から木の杭を投げた、一発逆転!
ここでもう一度判定があり、これが成功すれば再び勝利ルートに合流……ともう一段設けているのだ。
(失敗すれば、今度こそ本当にゲムオバだが……)
全体的に選択の結果、失敗する事も多いけども、このグラーデションは貫かれている気がした。
(戦闘における逃亡の
「ダメージを必ず受けるが、とりあえず予想の範疇に収められる事は出来る(もし戦い続けたら、最悪の結果があるかも?)」
も、考えればそうか)

ちなみに呆気に取られたのが、これ程の危機の末に倒す吸血鬼、
その結果手に入る金貨や意味ありげな本などは当然重要アイテムだろう……と思いきや、
『これらはクリアに一切関係ないアイテム』
だという。

おいおいおい……、やりますねえ!
でも何だろう、思い出してみれば
デジタルゲームでも、SFCの頃とかにはまだそういう理不尽の香りが残ってた気もする……かな。
(終盤になるとやたらとゲムオバルートが多いのは、
昔のファミコンのアクションゲーが理不尽に難しかったのと同じく、
少ないボリュームで長く遊んでもらおうって配慮から生じたのかな? とも思ったり。
逆に今のJRPGはボリュームは充分にあるので、リスクはぎりぎりまで排除して、
RPGとは言っても完全に別物になっているか……
まぁこれは演出を楽しめという事で、
そのまま究めたら、なるほど、ソシャゲに行き着くのも分かると言うか……)

そしてゲームブックを支える基本的な設計としてはもう一つ、
「先が見えない楽しさ」という事もあって、
上記の戦闘も恐らくそう、
敵のトータルの値は見えるけど、敵の基本値なんかは分からないから、どれがベストな選択かを迷う。
吸血鬼の意味無しアイテムもそう、それが意味無しとはプレイヤーが分からないから、
必死に意味を考える。
色々なルートがあって、正解の道を選べばほぼ戦闘も無く先に進めるのに、
悪いルートなら本当にダメージを負いまくったり、
最後の最後でそもそもとっくに詰んでいたなんてのが発覚するなんて事も有り得る。
(酷い。でもこれも先述の、結果の極端さか……)

それら全てをなんだろうなんだろうと楽しめるのは、
やはり「先が見えない」「無駄骨を折っている事が分からない」からなのだ。
まさにそうして探索という雰囲気を出したのだなぁ……(ゲームブックという事で、ただでさえ文章でそれを後押し出来る訳だし)
と、この「火吹山の魔法使い」は80年くらいに発表されたらしいのですが、
何か遠い米国の、引き篭もりがちで空想ばかりしている
小太りの髭もじゃ白人さんと、気持ちが通じ合った気がしたのです。
(……いや調べたら、「火吹山の魔法使い」は英国発だし、
作者さんの写真もすらっとしてる感じだったんだけどね……)

先が見えないから楽しめるなんてゲームじゃ当たり前やんと思うでしょうか、
でも今の日本のRPGを見ると、
見下ろし視点と、背景+立ち絵で移動先選択というの、
どちらが好まれますかね?
前者ではないかと思う、そして前者は「先がある程度見える」のだ。
だからもし洞窟でぐるぐる迂回させられる道があると、無駄を感じて死にたくなる。
戦闘から逃亡するにしても結果が見えているのだ、
仮に確率で失敗してダメージを負ったとしても、
まぁ豊富にあるMPで回復魔法とか、安価なポーションで回復すればいいだけの話だし。
(「火吹山の魔法使い」ではHP回復はボスに勝利した後とか、ごく僅かな機会しか無いようだった。
それももちろん定数、全快とかはしない)


あぁ”この感じ”かと……。
どうもアナログゲー出身者とか、あの辺りが抑えてた素養とは、とね。
俺もまたツールを作ったり、設計したくなったなあ。