3DダンジョンRPGエディタを作るスレ

**名前は開発中のものです。** · 2009/01/31(土) 11:34:06

現在は女神転生に括らず、一人称視点（Wizardry・女神転生など）のRPG
を作る事を目指し、そのような３DダンジョンRPGのエディタを作るスレです。
また、３DダンジョンRPGで使える/必要となる素材や
プログラム/ソースコード、ライブラリの製作をするスレッドです。

まとめwiki(メガテン風ゲーム作ろうぜwiki）
ttp://www1.atwiki.jp/megaten_tkool/

**520** · 2015/12/30(水) 04:50:17.43

戦闘システムの実装については、そのルール設定に依存するが、
オーソドックスなパーティ型ターン制バトルの場合、
(0) 戦闘に参加するメンバー（プレイヤー側、敵側）の初期状態を定義する
　　また、その状況をプレイヤーに開示する。
(1) プレイヤーパーティとしての行動を決める。すなわち、
　　戦うか、逃げるか、あるいは敵と交渉するかの選択である。
(2) 行動可能なメンバーについて、行動予定内容を設定する。
　　プレイヤー側については、コマンド入力インタフェースなどを用意する。
　　敵側については、選択可能な行動の中からランダムに選ぶか、
　　人工知能的なものを準備する。
　　なお、行動予定内容とは、「どの動作」を「誰に対し」行うかとして記述する。
(3) 戦闘開始時点で、敵、味方すべてのメンバーで行動順序を決める。
　　一般的には「素早さ」のような能力が反映されるが、
　　敵パーティが単一種の場合、行動が集中するとバランスが悪いため、
　　ある程度広い乱数分布で順序評価したほうが良い。
(4) 順番が回ってきた時点で、予定の行動が可能で（生存かつ行動不能な状態異常がない）
　　であれば、その作戦行動を実行する。
(5) 一方が全滅したら、戦闘を終了する。
　プレイヤー側が勝利した場合、HPやMP、状態異常などを探索系サブシステムに
　　リストアする。
というような組み方が考えられる。

**520** · 2016/01/03(日) 13:21:09.37

プレイヤー側の戦闘時初期状態の決定には、
キャラクターメイキングシステムとの連携が不可欠である。

ゲームの構成にも依るが、開始時のパラメータ振り分けおよび
レベルアップによる半固定パラメータの保持、更新を行うサブシステムと、
HPや状態異常などの動的ステータスの保持および更新システムが管理する
数値を、戦闘開始時に参照し、戦闘終了時に復元する形で連携させる方法がある。

この実装のポイントは、基本的なことではあるが、
プレイヤーキャラクタのパラメータおよびステータス.にかかわる多項目の数値情報を
適切な方法でプレイヤーに提示するステータス画面の作り方にあると思われる。

膨大かつ複雑な依存関係があるパラメータを単純に羅列するだけでは、
プレイヤーが理解できないし、戦略や見通しを立てる楽しみが損なわれる恐れがある。

また、ステータスの回復、修復に関して、マップ上の特殊な施設の利用や、
魔法、アイテムの使用を手段とする場合、それぞれに対話式ユーザインタフェースの
実装が必要であるとともに、各ステータス異常と回復手段の対応について、
プレイヤーに学習させる時期や方法についても配慮すべきである。

**520** · 2016/01/03(日) 13:42:03.19

店での買い物および.武装についても、キャラクターメイキングの範疇で検討する。
まずは、パラメータ変動効果にバリエーションのある武器、防具、アイテム等のデータベースを
整備しつつ、ストーリー上のどこでどのような武器、防具を入手できるようにするかを
バランス調整の際に検討する。
ゲーム内での実装は、対話型コマンド入力システムが基本となる。

加えて女神転生風ゲームを考えた場合、
戦闘で捕獲した悪魔を仲魔としてパーティに加える戦法や、
仲魔を合体させることで変化させるサブシステムが必要である。

なお、合体に関しては、とりあえず総当たりの表に書き表せられていれば、実装しやすい。
ここに、乱数やステータス値等の影響を絡めたシステムを入れるとすれば、
その仕組みをプレイヤーが容易に理解できるようにサポートシステムが必要である。

悪魔の合体は女神転生風ゲームの醍醐味であるため、
凝った仕掛けを考えたくなる誘惑はあるが、プレイヤーの目線で考えると
手間のかかる行為であるため、常に予定通りの結果が得られるような
公正で明朗なシステムであれば十分面白いのではないかと考えている。

**520** · 2016/01/03(日) 14:04:31.02

一方で、敵チームの戦闘時初期状態の決定は、マップのエリアコードと
連携したデータベースの参照で行うのが単純である。
敵データベースには、戦闘システムの開始と処理に必要なパラメータと、
その敵の出現エリアを設定しておく。

このデータベースは、登場する悪魔の数だけ全て設定する必要があり、
名前や数値情報以外に、プレイヤーの識別を補助するための画像、
アニメーションを用意することも考えると、その作成にかかわる作業量は
膨大になる。

実際に何種類の悪魔を用意する必要があるかというと、
多ければ多いほうが良いという考え方もあるが、
例えば、プロットをもとにマップエリアを分割し、
各エリアごとに３～４種類の悪魔を目標にするという方法を提案する。

なお、その３～４種類のうちの一つは、プレイヤーパーティのベンチマーク用に、
物理攻撃しか行わない咬ませ犬的な敵とするとよい。

**520** · 2016/01/16(土) 08:16:51.31

ここまでに考察したところで、女神転生風ゲームのゲームシステム面での
主要な要件は出そろったと思われる。

以後、実際に女神転生風のゲームを試しに作りながら、考察が足りない点は
その都度、検討する方向で進めてみたい。

当面の目標としては、このスレッドのタイトルに倣って、
「３Ｄダンジョン（迷路および謎解き）」を制作、編集、テストができる環境を整えることとする。

参考までに、現時点の画面のイメージはこのような状況である。
ttp://amadela.web.fc2.com/megaten/image/preview20160116.png

**520** · 2016/01/16(土) 10:06:51.12

３Ｄダンジョンに関する要求については、>>525-526で書いているが、
このプログラムを作成するに際して、より詳細な検討を加えている。

まず、迷路を保持するデータ構造について説明するため、
迷路を構成する最小単位を便宜的に「セル」と呼ぶとする。

１つのセルには、必須データとして、
・セルの座標　ｘ、ｙ　（ｘは東西方向、ｙは南北方向）
・セルの東西南北の境界表現（壁の有無、または扉）
を持たせている。

このセルを複数集めて、１つのフロアマップを形成している。
複数のセルの管理にはリンクドリストを使用していて、
任意の形、任意の広さのフロアを表現することが可能である。
と言っても、１フロアあたりせいぜい１００セル程度に留めておきたい。

また、必要がある場合に限り、セルには以下の付帯情報を記憶させることが
できる仕組みになっている。
・天井と床の穴表現有効化フラグ
・ダークゾーンフラグ
・セルの名前
・イベント処理用スクリプト（任意行数のプログラムテキスト）

上述の試作プログラムでは、以上の情報を用いてマップデータの編集および
歩行移動テストが可能になっている。

**520** · 2016/01/16(土) 10:38:57.47

試作プログラムにおけるマップの編集について、少し工夫したことを書いておく。

このプログラムでは、ゲームプレイ時のスタイルでカーソルキーを使い、
３Ｄ迷路を歩き回ることが出来ていて、そのシステムに上乗せする形で、
・スペースキーを押すと、眼前に１つセルを作り、現在地点との間を通路でつなぐ。
・ＤＥＬキーを押すと埋め戻す。
・コマンドまたはショートカットキーで、眼前に壁や扉を設置または撤去する。
・コマンドで階段表示、ダークゾーン設定およびスクリプト編集する。
という仕様になっている。

つまり、３Ｄマップを歩いてみて、この辺に通路を開けたいと思ったら、
スペースキーを押しながら前進すれば、好きなだけ穴を掘っていける
という変則的な方法でマップを編集する方法にしている。

おそらく一般的に、３Ｄダンジョンのマップエディタといえば、
ttp://amadela.web.fc2.com/megaten/image/houganmap.png
のような、迷路を俯瞰した形で編集するのが常識ではないかと思われる。

しかし、このようなエディタは、「あらかじめ方眼紙などにデザインされた
マップを、ゲームプログラムで扱えるデータに打ちなおす」目的であれば
効率的なツールになるかと思うが、そもそも方眼紙を前にして、
マップをデザインするという作業が全然楽しく思えないと、生産性が悪い。

当初は俯瞰型のエディタも作ってはみたが、
何のモチーフもなしに迷路を描くというのは非常に効率が悪いと感じたため、
このように、プレイヤー目線の体験の拡張でマップデータを編集する仕組み
を開発した次第である。

**520** · 2016/01/19(火) 22:57:14.21

迷路の描画については、魔法のマッパーが有効な時の俯瞰表示と、
メインウィンドウとなる疑似３Ｄ迷路の２つがある。

俯瞰表示については、フロアマップのセル群のうち、所定の範囲
（この場合、進行方向前後５マス、左右３マス）にあるものについて、
進行方向が画面上側になるように回転させて描画する。

描画する際はセル単位に相互に重ならないように描くようにすれば、
描画順序（セルの保持順序）を気にしなくてもよい。

それに対して（Ｚバッファを使わない）疑似３Ｄ表示については、
奥から手前に向かい、左右は両端から中央に向かって描画
する必要があるため、現在の地点座標と向いている方角から、
視界内（試作プログラムでは奥に４ブロック、横７ブロック）の
進行方向側の壁（または門）と、左手および右手のそれらを
一旦配列に集計してから、所定の順番に描画する方法としている。

この集計処理は、移動または向きを変えるごとに必要なので、
処理時間が気になるならマップの保持方法を見直すなどの
高速化・最適化が有効であると考えられるが、
１００セル程度のマップであれば、今どきのＰＣなら気にする
ほどの時間はかからない。。

**520** · 2016/01/20(水) 23:38:56.10

マップエディタでは、迷路形状データの編集と合わせて
マップ上に様々な仕掛けを配置することも重要な機能である。

仕掛けとは、ターンテーブルやワープなどの罠だけではなく、
階段によるマップ間移動や、会話イベント、宝物の配置、
店や宿などの施設の設定全般のことである。

これらの仕掛けをマップデータ中に定義する方法としては、
マップ上の該当セルにユニークな名称（ラベル）を設定するとともに、
その名称に対応する仕掛けの内容を説明した任意様式の設定資料を
併用する方法が考えられる。

仕掛けの内容は当然ゲーム内容によって変わるものであるため、
ストーリーの核心に触れるような謎解きイベントなどの実現には、
どこかの段階でプログラミング作業が必要で、マップエディタ上で
テストを完結するのは難しい。

簡単な仕掛け、例えばターンテーブルや、情報が得られるメッセージなどは、
簡単なイベントコードと、メッセージテキストなどのカスタマイズ可能な要素を
マップデータ中に記録できる形式を定義してやれば、テストできないこともない。

しかし、「あるアイテムを持ってその場所に行くと中ボスが表れて、
会話の流れで”いいえ”を選択すると戦闘になって、勝利したら
あるフラグが立ってアイテムを消失する」のような、ストーリー上に
一回でもあるかどうかわからないようなイベントのテンプレートを
エディタ設計時に想定して組み込んでおくという発想には限度がある。

この課題があるために、汎用性のある３Ｄ迷路のデータ構造の定義は困難で、
そのようなエディタを開発しようとした場合に悩むことになる。

**520** · 2016/01/27(水) 23:34:21.05

そこで、マップデータにイベントを埋め込むという発想を拡張し、
イベントやマップ情報をひっくるめて「３ＤダンジョンＲＰＧ」そのものを
コントロールする処理システムというものを考える。

コントロールする対象は、ターンテーブルやマップ間移動のような
迷路のトラップに関するもののほか、情報を表示するためのウィンドウシステム、
プレイヤーの入力ＵＩ、ゲームの進行を管理するフラグ等、
制御内容を容易に"記述可能"なものから順に考えている。

これにより、イベントの設置、つまり制御内容を記述しテストする作業を、
迷路の設計と並行してマップデザイナー（兼シナリオライター）一人で
完結させるのが目的である。

実のところ、この仕組みを発展（制御対象を拡大）していけば、
既存のＲＰＧエディタ、ツクール等や、スクリプト処理言語と同じようなものに
なっていく。結局、イベントを細かくカスタマイズしようと思ったら、
どういう形であれ、プログラミング的な作業は避けられない。

汎用性を高くしすぎて、とっつきにくいエディタになるのは不本意なので、
”女神転生風”ということを再確認して、処理系を構築しようと思っている。

**520** · 2016/01/28(木) 22:08:46.47

参考のために一例を示す。
ttp://amadela.web.fc2.com/megaten/image/preview20160128.png

マップ上を移動し、このセルに踏み込んだら、
このセルのマップ情報に付帯しているスクリプトを
テストプログラムが解釈する仕掛けになっている。

上から順に、画像ファイルを指定して表示、
ウィンドウを開く、テキストを表示する（２行）、
プレイヤーのキー入力待ち、画像消去、ウィンドウ消去
を意図した記述になっている。

画像ファイルとメッセージ文字列以外は一般に定型でよいため、
設置指示時に、エディタがテンプレートを貼るようにしてある。

この例に示す程度の、上から下に進むだけの動作の記述であれば、
プログラミングの知識に関係なく、マップデザイナーの作業範疇で
容易にカスタマイズができるのではないだろうか。

**520** · 2016/01/29(金) 22:08:40.81

もう少し複雑になった例を示す。
ttp://amadela.web.fc2.com/megaten/image/preview20160129.png

宝箱があり、開けるかどうか聞かれ、「はい」と答えると中身を入手する
パターンである。

ウィンドウにテキストが表示されるあたりは前例と同様で、
「はい」「いいえ」の回答によって分岐する部分があることと、
魔ッ貨と宝玉の入手にかかわる内部変数操作、そして、
宝箱開封済みを示すフラグの操作で構成される。

このスクリプトはマップデータ中の該当セルに埋め込んであるが、
魔ッ貨、宝玉および取得済みフラグについては、
別の定義ファイル中で宣言し、ゲーム進行中保持するようになっている。

なお、「マップ中のアイテムを取得する」という行為を表現するには、
この例のように、アイテム取得済みのフラグを立て、次回は、そのフラグが
既に立っているなら処理しない、というロジックを使うのがセオリーである。

プログラミング経験者にとっては当たり前のことだが、マップデータ中から、
アイテムの記述情報を取り除くような真似はしない点、念を押しておく。

**520** · 2016/01/29(金) 22:24:46.29

このほか、階段の昇り降りやエレベータ判定、店などに入った時の切り替えも、
同じようにマップセル中にスクリプトとして記述できる。

店や回復施設など、複雑な選択操作やデータアクセスを伴うものについては、
別途プログラマが実体を開発する必要があるが、マップ上の特定地点に
その施設を置くという指示は、マップデザイナーに委ねることができる。

また、併せてストーリー進行に関しても、フラグを併用して迷宮内の謎を解きながら
探索するというパズル性も、若干プログラミング的な思考を伴うが記述可能で、
エディタ上でテストできる環境が整った。

現在、試しにＦＣ版女神転生のダイダロス塔（静玉をとってエレベータに乗れるまで）を
このシステムで収容できるかどうかテストしているところである。

**520** · 2016/02/11(木) 06:26:13.14

ダイダロス塔クリアまでの迷宮マップとイベントの設置テスト結果について。

このエリアの１階には一部に一方通行の場所とダークゾーンがあるが、
これらを含め、宝箱や壁の落書きなど全てそれっぽく収容することができた。
ttp://amadela.web.fc2.com/megaten/image/minotauros.png

セル単位に東西南北の壁または通路を記憶する本方式では、
隣接部屋間のその設定値を敢えて不整合にすることで
一方通行を設定することができる。

定型的なトラップの一種なので、エディタ上で入力サポートするように
機能を追加した。

ダークゾーンについては、階段と同じように、該当セルにフラグを立てて置き、
描画ルーチンの対応で表現する方法で実装する。

原則的には、ダークゾーンは壁または扉で仕切られたエリアを充填するもので、
そのエリア内にいる間はメインウィンドウを霧で目隠しする表現方法をとるのだが、
もし、ダークゾーンが広間の途中に浮いているようなデータであったとしても、
白い柱が立っているような形で見えるように、描画処理を工夫してみた。
ttp://amadela.web.fc2.com/megaten/image/preview20160211.png

**名前は開発中のものです。** · 2016/02/12(金) 16:23:07.19

がんばって～
どこまで作るか知らないけど

**520** · 2016/02/13(土) 04:45:31.70

当面の目標はファミコン版女神転生を収容できるシステム＆エディタを自作することで、
現状、３Ｄ迷路のマップデータとトラップ類の設置については既報のとおり完了した。

幸いにして実機およびＲＯＭカセットを所有しているのと、攻略サイトやプレイ動画等
豊富に情報があるので入力と検証も自力で可能なのがありがたい。

問題があるとすれば今後のモチベーションをどのように保っていくかと思われる。

**520** · 2016/02/13(土) 05:36:14.41

ここからは開発の焦点を変えて、このゲームのプレイ要素の一つである
キャラクターメイキング、パーティ編成のシステムの実装について検討する。

最終的に、戦闘システムの勝敗に関わる要素であるため、バランス調整が
肝になると予測されるが、まずはプレイヤーとのインタフェース部分から考えていく。

本作中には、戦士型のナカジマ、魔法使い型のユミコと、その他仲魔の３タイプの
キャラクタが登場し、その設定項目がタイプ別に微妙に異なることと、
それに応じてステータス画面のレイアウトも変える必要がある。

共通する要素としては、
・名前、種族、レベル
・強さ、知力、攻撃、機敏さ、運もしくは防御
・ＨＰおよび最大ＨＰ
・ＭＰおよび最大ＭＰ（ただし、ナカジマはともに０）
・状態異常フラグ
で、固定（半固定）な値もあれば、ゲームの進行で変動するものも含まれる。

項目さえ決めてしまえば、これらを管理するクラスを作るのは容易であるが、
項目をカスタマイズ可能にしようとすると少し面倒になる。
少しやりかけてみたが、ＵＩ処理の実装など足かせになるばかりなので、
ＦＣ版の仕様に準拠した構成で進めることにしたい。

**520** · 2016/02/13(土) 05:50:40.09

キャラクターのステータス値の構成が決まったら、
次にできることは以下の通りである。
(1) ナカジマとユミコ用の、初期の１５ポイントを振り分ける画面を作る
(2) ナカジマとユミコ用の、１ポイントレベルアップする画面を作る
(3) 仲魔ステータスのデータベースを作る
(4) ナカジマ専用ステータス画面
(5) ユミコ専用ステータス画面
(6) 仲魔専用ステータス画面

特に、(1),(2)はこのゲームを遊んだときに初めて体験した操作で、
個人的に非常に印象が強い要素である。

(3)については、いささか面倒であるが、攻略サイトの情報をもとに、
例えば以下のような様式のレコードファイルを作る作業を行う。
　　　　　　　nakama　幻魔アルラウネ
　　　　　　　MG=17　　LV=20　　HP=232　　MP=70
　　　　　　　STR=14　　INT=19　　ATK=7　　AGL=12　　DEF=7
　　　　　　　spell　マリンカリン
　　　　　　　spell　メディカ
　　　　　　　spell　クリンク

(4),(5),(6)については、実機の画面レイアウトを参考に数値を並べるだけで、
(1),(2)で作った画面のＵＩ部品を流用できる。

数値を扱うユーザインタフェースを作るのは地味であるが、
ゲームの根幹をなすシステムなので、しっかりと作っておきたい。

**520** · 2016/02/16(火) 21:35:12.25

キャラクターメイキングの画面を試作した。
ttp://amadela.web.fc2.com/megaten/image/making.png

また、同種の方法でプレイヤーのステータス画面および
仲魔のステータス画面も実装してみた。
ttp://amadela.web.fc2.com/megaten/image/status.png

ステータス画面に、キャラクタの肖像画が表示されるというのは
ＦＣ版で、特に印象的だった記憶がある。
試作プログラムにおいてもその仕様に準拠し、
複数枚の画像を用意すればアニメーションも可能である。

なお、プレイヤーたちの画像および悪魔の画像については、
真面目に描こうという気が全く感じられないと思われるかも
知れないが、当然のことながら、差し替え可能な仕組みに作ってある。

**520** · 2016/02/23(火) 04:44:06.01

このゲームでは、パーティに悪魔を加えるためには、
事前に交渉（もしくは合体）の上で「仲魔」として登録が必要とされる。
仲魔はＦＣ版では最大７体まで登録可能である。

この「仲魔登録」クラスの設計については、以下の仕様とする。
(1)初期状態では空っぽとする
(2)登録しようとする悪魔が既にエントリされていないかチェックする
(3)登録数が上限に達していないかチェックする
(4)登録可能な場合、悪魔の種類と現在のHP、MPをセットで配列末尾に登録する
(5)登録されている悪魔を抹消し、配列を詰める
(6)悪魔データベース記載の最大HP,MPを参照し、回復に必要な金額を算出する

とりあえず今思いつくのはこれくらいだが、単純な配列操作で実装できそうだ。

**名前は開発中のものです。** · 2016/02/24(水) 21:20:20.48

なんの言語を使っているのだろう。
配列じゃなくList型とかでもいい気がする？

class Nakama {
int hp, mp;
}
List<Nakama> nakamaList;
みたいな。

ちなみに自分は、敵、味方、（未実装だけど味方が召喚したのも）
Characterクラスで統一して、
List<Character> characterList;
で一括管理ｗ

**520** · 2016/02/25(木) 22:31:03.08

システム設計上の話とプログラミングの話を曖昧にして申し訳ない。

ゲームの仕様上は、要素数に上限のある配列構造を準備できればよく、
プログラミング上、必要な操作ができるのであれば、
listでもarrayでも構わない。

ただ、この仕様で敢えてlistを採用するメリットが見いだせない。
と言ってデメリットもないような気もするが、、
高々７個程度の要素数では、効率云々を議論するまでもなく、
結局、どっちでも構わないと思う。

なお、的確な指摘であるだけに、最後の「ｗ」は残念だ。

**名前は開発中のものです。** · 2016/02/27(土) 00:05:51.89

おおう、申し訳ない。
「ｗ」はクセのようなもので他意はないです。失礼しました。

なるほど、論理設計上、配列的な設計ということですね。

3Dダンジョン繋がりで、いろいろ参考にさせてもらってます。
（「セル」という名前付けは同じなんだなー、とか、
セル同士リンク構造でつなげてるんだなー、とか（うちはX×Yの方形構造））

**名前は開発中のものです。** · 2016/02/27(土) 18:53:42.63

3Dダンジョン　ウィザードリィをベースに作ってる
ワイヤーフレームと3D画像と

**520** · 2016/02/28(日) 21:40:29.87

引き続き、その「仲魔登録クラス」の利用方法について検討する。

戦闘状態で交渉に成功したときに、登録エントリーの末尾に新規登録するのは
特に問題はないと思われる。

ＣＯＭＰ→よぶコマンドを実行したときには、
「登録している仲魔のうち、まだ召喚していない悪魔」の選択リストを作る操作と、
その選択画面でカーソルを動かしたとき、呼び出しコストの見積もり表示を更新する
処理が必要になる。
この処理の実装に、汎用的なメッセージウィンドウを流用するのが困難であれば、
専用の選択ダイアログを作る価値はあると思う。
ttp://amadela.web.fc2.com/megaten/image/compcall.png

ＣＯＭＰ→もどすコマンドを実行したときには、
仲魔登録クラス側のＨＰ，ＭＰを更新し、回復の泉での代金計算に利用する。

最後に重要なのが、邪教の館での合体対象の選択ＵＩで、
これは合体表（実質的にはドリアード確認表）を示して
合体対象の悪魔２体を選択するウィンドウである。
これも、この選択専用に作ったほうが容易である。
ttp://amadela.web.fc2.com/megaten/image/gattai.png

合体を実行したときには、
(1)選択した２体の悪魔が召喚中なら帰還させ、仲間登録エントリから抹消し、
(2)合体結果の悪魔を、エントリの末尾に登録する
という操作を行う。

**520** · 2016/02/28(日) 21:57:23.90

>>550
セル（部屋）をリストで管理する方法については>>533で述べたように、
広さや形、フロア間の相対的な位置関係を気にせずに
ストレスなく作成、編集できるようにするための実装であるが、
方形配列に比べてアクセス効率が悪いデメリットがある。

しかし、これも仲間登録クラスの実装の問題と同じで、
今のＰＣなら速度的に大して問題にならないという理由で、
３Ｄダンジョンに限らず、拙作のドラクエ風ゲームでも採用している。

ただし、マップデータの保持がそうなっているだけで、
マップを表示する処理クラス内では、速度的な効率改善のため、
視野範囲内の壁や仕掛け要素を一旦、方形配列に抽出してから
利用している。

**名前は開発中のものです。** · 2016/03/04(金) 19:52:08.14

なるほど、セル＝１マスじゃなくてセル＝１部屋だったのか。通りで
＞１フロアあたりせいぜい１００セル程度
１００って少ないと思ってたんだ（２０ｘ２０でも４００マスだし）

**520** · 2016/03/05(土) 08:32:14.84

２０ｘ２０というと、Wizardryのマッピングを思い出す。
なお、ＦＣ版の女神転生は、基本８ｘ８部屋で１フロア（またはフロア中のエリア）
を構成する仕様になっている。

技術的な理由が何かあったのかどうかわからないが、
説明書にも８×８を単位にマッピングしながらプレイすることが推奨されている。

無論、今どきの制作、実行環境でそのようなサイズ制限は考えなくてもよいが、
序盤から暗記できないほど巨大なマップを歩かせるよりも、
(1)まずは３Ｄ迷路を歩くこと、
(2)繰り返し歩くことでマップを覚えること、
(3)覚えきれなってきたらマッピングをすること、
という難易度の段階的設計は、考慮してもいいと思う。

その延長に、マッピング作業を困難にするトラップや、
８×８という固定観念を破るようなマップを登場させると有効な気がする。

**520** · 2016/03/10(木) 04:16:15.09

話を仲魔登録クラスに戻して続けようと思う。

仲魔を最もアクティブに使うのは、合体操作を行う「邪教の館」で、
"合体"という操作についての仕様を検討する。
とりあえず、ＦＣ版の２体合体を考える。

ＵＩを使って合体させる２体を選んだあと、何になるかについては、
>>530にも書いたように、対象となる２体の組み合わせごとに、
合体結果を定義した表があれば完璧であるが、
非常に大きな表になるため、実際には次のようにして縮小している。

(1) 合体元の悪魔を、３種類程度ずつグループ化してラベルを付ける
(2) グループラベル同士の組み合わせごとに合体結果の悪魔を定義する
(3) 組み合わせが定義されていないグループ同士はドリアードとする

定義データの一部抜粋は、こんな感じになっている。
mixgrp　S　ファンガス　ヴィー　ヨモツシコメ
mixgrp　T　ノーム
mixgrp　U　ボーグル　プーカ　フォーモリア
mixgrp　V　エルフ　　トロール　ゴブリン
mixgrp　W　ドリアード

mix　S　V　ケルピー
mix　S　W　ソラス
mix　T　U　クタム
mix　T　V　トレント
mix　T　W　ヘケット
mix　U　U　ケルピー
mix　U　V　クタム

**520** · 2016/03/10(木) 04:37:27.29

合体ルールを自作する場合に配慮すべき点としては、
ＦＣ版においては、原則として一旦仲魔にした悪魔の登録は、
むやみに解除できないということと、登録数には上限があること、
そして、登録数の空きを確保するには合体させる必要があることである。

ただし、以下の場合には合体ができない。
(1) 合体後の悪魔と同種のものが既に登録されている場合
(2) 合体後の悪魔が現在のパーティレベルに比べて高すぎる場合

そのため、仮に合体素材よりも強い悪魔しか生成されないルールになっていると、
現在の探索範囲に対しコストパフォーマンスが悪い悪魔だらけになって、
呼び出し魔っ貨やマグネタイトが不足するようになったとしても、
合成も新規加入もできずに手詰まりを起こす可能性が考えられる。

なので、ある程度の割合で弱体化する組み合わせも必要ではないかと
考えられる。

ちなみにＦＣ版の場合、仲魔をDEAD状態にしてからパスワードをとると
その悪魔は記録されないという裏技のような救済策があるようだが、
飼えなくなったペットを捨てるような罪悪感があって、実行したことがない。

**520** · 2016/03/10(木) 05:05:33.34

合体に関する実装に関しての話題を２つほど。

合体元を指定したとき、合体後の悪魔のステータスをプレビューできるが、
そのときには、悪魔の画像はグレイスケールで表示したい。
ttp://amadela.web.fc2.com/megaten/image/gattaipreview.png

ファミコンの場合、おそらくパレット変換で処理しているとみられるが、
拙作のプログラムでは自前でRGB→Y変換して表示した。
画像ファイルの扱いをライブラリに丸投げしている場合には、
このような処理ができるのか確認しておいたほうが良い。

合体を実施することにした場合、２つの悪魔が合体する様子を
イメージしたデモンストレーションを挿む。
ＦＣ版では左右から中央に向かって２体が交互に点滅しながら寄っていき、
最後に「もやもやど～ん」で合体後の悪魔が現れる。

そして、「今後とも　よろしく。」の決め台詞を忘れてはいけない。
ttp://amadela.web.fc2.com/megaten/image/gattairesult.png

**520** · 2016/03/16(水) 22:45:44.31

キャラクターの武装および装備品の売買システムを作るにあたっては、
いくつか検討すべきことがある。

(1)ゲームを通して登場するすべての装備品（武器、鎧、楯、兜）について、
　　　名前、標準価格(非売品も含む)、性能値、その他特性データ
　を羅列したリストを準備する。
(2)各装備品について、ナカジマまたはユミコが装備できるものだけを
　　集めた集合を準備する。
この２つは、ゲーム全体で１つ定義すればよい。

(3)売買を行う「辺境の店」があるマップデータ内の地点設定項目に、
　　その店での取り扱い品目を設定する。
当然深淵に行くほど強い武器を販売するように配置する。

(4)「ナカジマ武器」「ナカジマ鎧」等のように、装備品の種別および
　　使用者ごとに、現在何を装備しているかを記録する変数を作る。
　　ＦＣ版の場合、ユミコは楯を装備しないので、２人で７項目である。
これらの変数は、必ずしも個人データに含める必要はないと思う。

**520** · 2016/03/16(水) 23:03:24.27

辺境の店での会話の進め方については、以下のように作る。

(0) 店の場所のマップデータにある、その店での取り扱い品目（分類と品名）リストを解釈する
(1) 分類を選択させる。
　　　ＦＣ版の場合、武器か防具で、防具には鎧も楯も兜も含まれていた。
　　　選択肢を絞り込むための分類なので、「特価品」「新製品」でも構わない。
(2) 品名を選択させる。
　　　(1)で選んだ分類に含まれる商品名から選択させる。
(3) 選択した商品を、装備品データベースで確認、一時的にマークを付ける。
(4) マークした装備品が今の所持金で購入可能か判定する。
　　　所持金が不足する場合、その旨表示して(1)へもどる。
(5) 誰が装備するかを選択させる。
(6) 選択したキャラクタが、マーク中の装備品を使用可能か判定する。
　　　装備できない場合、その旨を表示して(1)へもどるが、このとき、
　　　武器の場合は「～は扱えない」、鎧楯兜の場合は「～は合わない」とメッセージを切り替える。
(7) マークした品の種別と同じ装備品を既に装備中の場合、下取り金額を計算、提示する。
(8) 「よろしいですか？」と最終確認する。
(9) 所持金からの支払いと、下取り金額の返金を行う。
(10) マークした装備品を、選択したキャラクタの該当変数に記憶する。そして(1)にもどる。

関連するデータベースや変数が分散しているため、アクセスのための仕組みを
整えるのが大変であったが、図のような形で実装を完了した。
ttp://amadela.web.fc2.com/megaten/image/henkyoushop.png

**名前は開発中のものです。** · 2016/06/01(水) 19:34:10.69

上のは頓挫かね

**520** · 2016/06/01(水) 23:30:55.18

>>561
申し訳ない。今ちょっと別のスレにかかりっきりなもんで。
もう少しで片付く予定何だが。

**名前は開発中のものです。** · 2016/06/09(木) 09:29:25.25

3Dダンジョンといい戦略的なゲームといい
ここの現主とは嗜好が似ているので応援してる！
(あっちはああだけど、それなりに応援してる)

…俺も今週中には書き込もう…

**520** · 2016/06/11(土) 08:33:29.81

他のスレを２つほど寄り道してて間があいてしまったのだが、
現況を整理して、そろそろ再開しようと思う。

履歴についてはこのスレに書いてある通りで、以下が開発済み。
(1) 迷路データの入力、移動
(2) 迷路の切り替え（階段、EV、エリア切り替え等)
(3) 月齢変化とマッパー表示
(4) 迷路内のスクリプト埋め込みおよびイベント処理
(5) パーティ編成および仲魔の呼び出し
(6) 「邪教の館」のうち、合体操作
(7) 「辺境の店」による武器・防具の売買
(8) ステータス画面、キャラクタメイキング、レベルアップ

テストデータとしてＦＣ版女神転生のマップを、
(a)ダイダロス塔８Ｆ～１Ｆまでのマップおよびイベント(ミノ～静玉）
(b)ビエン、ヴァルハラ、マズルカまでのマップと接続
を写経のごとく入力したところ。

**520** · 2016/06/11(土) 08:44:38.66

この先、開発が必要なところは、
(9) 敵との遭遇、戦闘
(10) 「回復の泉」によるHP,MP回復動作
(11) 「邪教の館」による死亡および状態異常の回復動作
(12) 「ラグの店」の実装
仕様に忠実に粛々と作るだけなので、調査を進めながらの作業となるが、
特に難しくはないであろうと予想している。

テストデータの方は、現在の作業の延長で、アンフィニ以降のマップを入力しつつ、
実機確認しながら罠等のイベント埋め込み作業ができそうで、
とりあえず戦闘抜きで開始からエンディングまでの探索操作が
できるものの完成を目標にしようと思う。

ただ、これが完成しても、マップデータと敵データベースが
ＦＣ版そのものなので、このままでは公開することができないのが残念だ。

**520** · 2016/06/11(土) 08:54:42.60

そこで、スレの主旨に立ち返ってみると、
> 女神転生に括らず、一人称視点（Wizardry・女神転生など）のRPG
> を作る事を目指し、そのような３DダンジョンRPGのエディタを作るスレです。
とある。

現況において、このような３Ｄダンジョンゲームの探索パート＋α程度の
システムは実現できており、ＦＣ版女神転生風のゲームを作りたい場合、
必要なデータをエディットする環境が提供できる状態にある。

>>521 で問い合わせたのは、こういうものを期待する人が、現在でも
残っているのかどうかというのを確認する意図だったのだが、その時は空振りだった。

当時より多少は開発が進んだ状況で、改めて伺いたいのだが、
前スレ以前の住人らを含め、３ＤダンジョンＲＰＧの制作に興味がある人があれば、
申し出ていただきたい。

**名前は開発中のものです。** · 2016/06/12(日) 21:05:32.13

563です。以前から見てます。

いろんな理由で、
＞環境が整えば、そういうゲームを作りたい
の時はレスしませんでした。
（「作りたい」ではなく「作っている」だし、エディタ不採用のダンジョン動的生成ですしね）

http://www64.atwiki.jp/suxgames/pages/44.html

ちなみに今は寄り道中…
http://echo.2ch.net/test/read.cgi/gamedev/1333204842/

ともかく、「３ＤダンジョンＲＰＧの製作に興味がある」のは間違いないので、
このスレは興味をもって見てますし、現スレ主の開発も応援してます。

**狂気の匿名ウサギ** · 2016/06/13(月) 15:45:30.63

気紛れ3Dダンジョン http://yado.tk/w/
これは何かに流用できないの？

**名前は開発中のものです。** · 2016/06/24(金) 22:53:51.85

システムがFC版のままなら興味がある奴がいたとしても需要はないだろうな

**名前は開発中のものです。** · 2016/06/26(日) 21:37:30.24

逆に、ＦＣ版規模の企画ですら示せないような人は、
どんなエディタを作ってもらっても、一生完成しそうにない

**名前は開発中のものです。** · 2017/12/31(日) 20:31:44.98

簡単にお金が稼げる方法興味ある人だけ見てください。

グーグル検索⇒『来島のモノノリウエ』

9CER89AIE2

**名前は開発中のものです。** · 2018/02/17(土) 08:27:10.80

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**ケモプレ制作委員会** · 2019/04/07(日) 21:38:10.60

ウディタでの疑似3Dゲーム用の合作テンプレート作ってみた。
https://www.freem.ne.jp/win/game/18651

**名前は開発中のものです。** · 2019/12/19(木) 14:12:14.15

**名前は開発中のものです。** · 2020/05/05(火) 00:25:06.96

wizardryの仕様解析サイトはよく見るけど
メガテンのは見ないな

**名前は開発中のものです。** · 2023/07/05(水) 02:41:51.21

まだ需要はありますか？

**名前は開発中のものです。** · 2023/07/08(土) 07:48:37.09

あるよ

**名前は開発中のものです。** · 2023/08/10(木) 14:43:07.70

ｽｩｰｯ(´┏･┓｀)v-~~ﾊｧｰｯ(´┏∀┓｀)v-~~