堕天使の煉獄

もう今年も終わりが見えてきたなと。

時期的にそろそろ某氏んとこの同人小説のイラスト依頼来てもおかしくない頃なのだけども、なんの音沙汰もないので、今年は無いのかな？
まあ依頼あってのものなので、向こうの都合しだいだしな。


とりあえず年内という括りで、短期的な予定みたいなのを立ててみることに。


3DダンジョンRPGとりあえずシステム周り動くところまで作る。

マップエディタとかのツール類……一言で言えば3DダンジョンRPGツクール的なやつを作る。
シナリオとか素材画像なんかまでは多分時間的に年内では無理だとおもふ。
規模にもよるんだろうけど。
小規模なサンプルゲームぐらいは作れてるとベターな感じで。
まあ作るっていっても、以前作ったやつを作り直す感じなんですけどね。


んで、日々ゴロゴロしてる時とかにもいろいろと脳内で、アレをこーしてああ組もうとか脳内で設計をスクラップ＆ビルド続けてたりはするのですが。

一番大事なのは実際に作り出すモチベーションだったりするわけで。

年内とか明確な区切りで、明確な締め切りってのもモチベーションを絞り出すのに有効な手だったりする感じぽ。


なにげに最近界隈どんな感じ？　とぐぐってみたら

ウィザードリィ（クラシック）の気になるところ
ttps://kumashige.hatenadiary.org/entry/20220103/1641146366
ウィザードリィ（クラシック）の気になるところ２
ttps://kumashige.hatenadiary.org/entry/20220116/1642298033

やっぱ3DダンジョンRPGといえば、私もwiz世代なので（直撃ではないけど。初wizはfc版wiz3だし）

システムとか考える上で、基盤になるのはやっぱwizだったりする。

んでも、ここの記事と同じようなことはその後のゲームの進化を見てきた上で出てくるわけで。
んまあ、ディードリットが作れないとかは知らんわそんなんｗ
てのもあったりするけど、キャラメイクのステータスボーナスで、60前後でるまで繰り返すのとか、たしかに不毛な時間だよなぁと。

わりとwizライク謳うフリゲなんかで、この初期ボーナス割り振るタイプのやつって、大きな値出る設定になってるのかどうか不明なやつ困るんだよな。

人それぞれ多様なwiz観てのがあって、wizのお約束の一つとして大量ボーナスは普通入れるだろ？　なんて人もいれば、大量の初期ボーナスなんて許せない！　システムとして要らない！　なんて考える人もいるわけですよ。

このゲーム開発者はどっちの主義の人？
てな感じでりどみとかに書いといてくれんかなぁとか思ったりする。

ともかく、歴史も古く、もはや古典でもあるので、各人に様々なこだわりや解釈があるので、その是非については問うのは不毛だったりする。

確かに死に呪文多いし、宿屋で馬小屋以外使うメリット殆どないし。
無駄な部分も多い。

あえてwizライクなクローンゲームを作るときに、この作者分かってるなとニヤリとさせる目的以外ではとくに盛り込む理由は無い感じだったりする。


あとこれまた別サイトで紹介されてたのだけど、wizの初期ボーナスの値の決定法ての。
D20(20面ダイス)で四回判定あって、基準値は4スタート。
20が出たら基本値に+10。
20以外が出たら基本値+1d5して終わり。

1回目で20以外なら1d5+4 = 5〜9
2回目で20以外なら1d5+4+10 = 14〜19
3回目で20以外なら1d5+4+20 = 24〜29
4回目で20以外なら1d5+4+30 = 34〜39
5回目で20以外なら1d5+4+40 = 44〜49
6回目で20以外なら1d5+4+50 = 54〜59
7回目は特殊で59+1d3

シリーズとかプラットフォームよって60上限だったり、種族の基本値+10が上限だったり、種族関係なく18ALLが上限だったりするのでいろいろと違うぶぶんもあるんだろうけど。

こうしてみると、たしかに見たことある数字の分布だわと。
んでも、21とか見たことあるようなきがするんだけど、この例だと21は出ないね。
シリーズによる差異かな。
あと30台てあんま見たこと無い気がする。
認知バイアスかかってるのかな。
14～29ぐらいだと、まあ面倒だしこのへんでいいか……ってなるけど、34～あたりだと、忍者にもなれないし上級職作るにしても中途半端感あるんだよなーって感じで却下しちゃうからｗ

んでも確率的に最高値の59+1d3は1/64000000 だってｗ
普通に3キャラぐらいは始めるたびに時間かけて毎回作ってたんだけど、やっぱほかにも何らかの調整もしくは乱数の偏りとかあるのかなぁｗ
確率だけ見ればとても現実的に出てきそうもない確率なんですけどｗｗ


んで、妙にこのブログ、ダンジョンPRG関係の記事多いな。
ググったのはダンジョン部分のデータ構造、他の人はどんな感じにしてるんだろ？　とググった結果で出てきたのだけども……？
したらここの人だったのか。

Desigeon
3DダンジョンRPG制作ツール
ttp://desigeon.net/

かなり昔に見たことあるツールぽ。
ブログの記事みるに2007年～ぐらいから今も開発継続中なのね。

他の記事もみるに、やっぱネックは多様なユーザー（このツールを使ってゲームを作る人）の要望に応えるためには、柔軟なイベントやユーザースクリプトが不可欠になってくる感じだなぁと。

自分のようにコードから自前で書いてる場合なら、戦闘シーンなんかはコードでゴリゴリ書いてもいいわけで。
あえて全部の行動をゲームイベントとしてスクリプトなどで定義できる形なんかにしなくてもいいわけですよ。（まあ内部的には結局イベントドリブンな形にはするんだろうけど）

作るゲーム毎に戦闘部分だけコードを専用で書くってのも出来るわけですし。
その辺、ツクールのような形で色んな人の要望に応えられるようにしようと思うとユーザースクリプト部分に比重が重くなる。
というか完全に駆動部分はスクリプトで全部制御する形にせざるをえない感じで。
その辺はRPGツクールとかウディタとか触ったことある人なら、ああいう感じになるよねっていう。

まあ実際にそんなん作るとなったらえらく大変なわけで。
メンテもプロジェクトの管理も大変ぽ。

なので自分的には多様性は抑えめで共用部分（マップエディタとかそのへん）以外はかっちり仕様きめてハードコーディングな感じで作る感じのほうがやっぱいいよなーと。

どんなゲーム形態でもつくれるユーザースクリプト駆動て汎用性は高いけど、人に作ってもらう場合、まずユーザースクリプトの仕様を覚えて貰う必要あるし、会社レベルで完全に分業化してるならともかく個人で作るレベルならそのゲーム専用のコード書いたほうが速いし面倒もすくないんだよなぁ。なんでも思いついたこと何でもすぐに組み込めるし。


なんてことをいろいろと苦心されてる様をみて思ったり（ぉ


んで当初の目的の、他の人はダンジョン部分のデータどういうふうにもってるのかなーってのは、ここの人の場合は1ブロック単位に床の数だけデータもってて（20*20ますなら400）1ブロック毎に壁は北と西の壁の情報だけ持つ。
という形にしてるみたいね。
壁データに両面分のデータ持ってる感じで一方通行とか扉とか表現する感じ。

まあこのへんは絶対的な正解なんてものもないのでアレですけど。
なんとなく他の人はどうやってるのかなーて気になる部分だったりするんですよね。

自分の場合は1ブロック単位に床の数だけデータもってて、ブロック毎に東西南北の壁のデータを持ってる感じ。
んで、自分ところは壁なしで、隣のブロックのほうでは壁ってなってると一方通行になる。
みたいな感じで以前は作ってたり。

でもそれで作ってみたところ、ミニマップで一方通行だよと知らせるようなマーカー設置するときにちょっと面倒だなーとか思ったりしたりして。

そうなると、床データと壁データは分離したほうがいいのかなぁとか。
水平方向と垂直方向の壁データを個別にリストで持つ感じで。
壁は表と裏の二枚分（一方通行など設定用）で。

この辺はマップの描画方式にも関係していて、このブログの人のところは基本、昔の古いwizのワイヤフレーム形式にこだわっていて、線を描画メソッドで引いて壁とか描いてる感じで。
自分のは1ブロックに1ブロックサイズの3ｄオブジェクト配置して、3Dオブジェクトの四方の壁を表示フラグにあわせて表示非表示切り替える感じでそれを

　　□
　□□□
□□■□□

たしかこんな感じで■がプレイヤーの位置上方向を向いてる図。
（なんか崩れちゃうな。凸型になってると思いねぇ……）
向いてる方向に対して□部分の壁データにあわせて3ｄオブジェクトの壁部分の表示フラグ切り替えてる感じ。
たった9個の四角い箱のモデルを並べて表示してるだけなので軽いｗ

昔作ったやつの実行画面


こんな描画方法なので、床一つに四方の壁のデータを持ってる形に自然に落ち着いたかんじぽ。



あとこのブロクから参考ではられてたwizの解析サイトに、玄室は部屋単位で設定されてるってのを知ったり。
FC版の解析結果とのことなので、本家では違う可能性もあるけど。
なんとなく扉もしくは扉の両側の床1ブロックに玄室の設定フラグがある感じだとおもってたなぁ。

しかしなるほど、レベルデザイン的にはそのほうが進行上、玄室の出現頻度とかをコントロールし易い（デザインしやすい）と思えてきてなるほどなぁとか思ったり。


そんな感じでいま頭の中にある設計では、マップディタ上では床（ブロック）と壁のデータは分離させて行く方向にしてみようかなーと思ってたりする。
そんで、玄室は……レベルデザインの観点からは部屋単位で玄室設定てのはたしかになーと思ったけど、逆に言えばそれ以外の利点は特にないかなと。

床にイベント埋め込むみたく、壁にもイベントを埋め込む方が色々と応用きくかなーと。
鍵だとかイベントアイテムだとかで開く、通行可能イベントとか壁イベントとして設定するほうが便利そうぽ。

この辺、FCとかpc88とか時代に考えられた古いデータ構造だということも考えなきゃいけないわけで。
要は使えるメモリが少なすぎて、壁があるかどうかをビットフラグでもつことで容量を抑えてたりする時代の様式だということ。

今なら壁一つに数バイトのサイズの壁オブジェクト持っていろんな属性やら持ち合わせてるような設計でも問題ないわけで。
まあディスクアクセスで手間取るサイズでもなければ全然問題ないんですよね。

どうもｃ++なんて言語を長くやってると、少しでもデータ容量切り詰めて、少しでも速く動くものを作りたがる癖が身についてしまうのだけども。

時代はもはや富豪的プログラミングで、とにかく作りやすい、わかりやすい、メンテしやすいって方向に意識を変えていかないといけないなーとおもうんだけどね。

でもその最たる例でもあるjavascriptとかあのへんの遅い、重い、無駄にメモリ食うあたりはやっぱ生理的に受け付けなかったりするんだよなぁ（ぉ

ｃ++のせいで貧乏性プログラミングが骨の髄まで染み込んでるぅ～


あとは、作るとしたらとくにwizリスペクトな感じにはしないぽ。
懐古に走るなら徹底的にやるべきだけど、中途半端にやるとどうしょうもないものになりそうだしｗ

今考えてるのは、やっぱ自分がハクスラ系好きってのもあるんだけど、繰り返しダンジョンアタックするのをゲームの芯におきたいなってのもあったりする。

そうなると、やっぱ自動生成マップ欲しいなーと。
キーになる階層だけ（例えば5階刻みとか）マップデザインを手動でデザインする感じで、それ以外の階層はランダム生成。
もしくは全部デザインしたダンジョンと自動生成オンリーの別ダンジョンを用意するとか。

自動生成の場合、壁が床1ブロック分のタイプだと穴掘り法とか棒倒しとかのアルゴリズム使えば簡単だけど。

wizタイプの壁がブロックの間ってのだと分割法あたりが適してはいるんだけど。
玄室もほしいんだよね。
分割法で玄室をつくって、間を棒倒しとかで埋めるとか、複合的なアルゴリズム考えないとだめっぽそう。
複数のアルゴリズムつかって、マップ埋めてくとなんとなく方向性が見えて来る。
この生成法だから埋まってないところはこういう感じになってるはずだーみたいなのが想像できるようなのだと面白そうかなぁ。
自然な感じの通路と玄室のバランスとかは、アルゴリズム結構練らないとうまくいかなそうぽ。

まあ、そこまで行くと3Dダンジョンである必要あるのか？
って話にもなっちゃいそう（ぉ

そういうゲームデザインも考え出すと、全然すすまなく……（ぉ

まあとりあえず、マーク・ザッカーバーグの「完璧を目指すよりまず終わらせろ」の精神で、とにかく作ってみよう。
3DダンジョンでRPG。