3DダンジョンRPGエディタを作るスレ (579ﾚｽ)
3DダンジョンRPGエディタを作るスレ http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
521: 520 [] 2015/12/19(土) 20:41:24.08 ID:u/NtzQZv 仮にそうだとして、環境が整えば、そういうゲームを作りたいと言う人は、今でも残っているのかな？ http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/521
522: 520 [sage] 2015/12/25(金) 22:32:02.52 ID:RLVlGygE 反応がない。やはり誰も見ていない廃墟スレのようだ。 ならば気兼ねなく、女神転生'風'の３DダンジョンRPG製作技術について語るスレとして、 ここを再利用させてもらうことにしようと思う。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/522
523: 520 [sage] 2015/12/25(金) 22:57:41.24 ID:RLVlGygE 最初に、女神転生’風’をもう少し具体的にする必要がありそうだ。 ファミコンの頃から続くシリーズのゲームなので、簡単には言い表せないかもしれないが、 ・疑似３D表現された迷宮内を探索する ・悪魔（敵）とは戦うだけでなく、交渉次第で仲魔にできる ・仲魔複数体を合体させて、強い仲魔を作ることができる という要素が特徴的である、と記憶している。 プレイヤーキャラをレベルアップし、資金をためて武装強化するとともに、 仲魔の協力を得ながら迷宮内のイベントを片付けつつ進み
、 最後のボスを倒す、というのはRPGの定番とも言える流れであろう。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/523
524: 520 [sage] 2015/12/26(土) 12:11:22.54 ID:V44X/Fk5 次に、ゲーム性の観点から整理すると、 (1)３D表現された迷路の中を探索し、所定のフラグを立てるゲーム (2)戦闘等で得た資金・資源をもとにパーティの戦力（持久力）を強化しながら、 その維持に要するコストを賄う経営的ゲーム が融合したゲームであると言える。 (1)には、ストーリー的設定や、謎解き要素を絡めて飽きさせないことが求められる。 プログラミング的には、古典的でオーソドックスな方法で実装できそうである。 ただし、昔と違って、方眼紙に地道にマッピングしながらプレ
イする時代ではないようなので、 快適に探索できるようなサポート要素が必要かもしれない。 (2)は、戦闘で経験値を集めてレベルアップ、資金を貯めて武装強化など、 RPGでよく見かけるハック＆スラッシュ要素と並行して、このシリーズの特徴である 『戦闘によって捕獲した仲魔を複数掛け合わして未知の仲魔を作り出す要素』 によって、より深淵部を安全に探索する戦力が得られたという達成感をもたらす。 プレイヤーを飽きさせないためには、十分な種類の装備品、仲魔を用意する一方で、 適切なタイミングで強化させ、その効果を実感できる体験を用
意する必要があろうかと思う。 なお、強力な仲魔を連れ歩くには相応のコスト（生体マグネタイト）が発生するルールに則り、 コストパフォーマンスを気にしながら遠征しなければならないジレンマに陥らせることが、 ゲームバランスを調整する際のポイントかもしれない。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/524
525: 520 [sage] 2015/12/26(土) 22:58:44.57 ID:V44X/Fk5 このようなゲームを制作するにあたり、上の(1)と(2)を分離して検討することにする。 まず、(1)迷路探索＆フラグ立てゲームのパートについては、 最初にそのゲームのストーリーや世界観を設定し、可能であれば 攻略の流れがわかるプロットを準備するべきである。 それにより、必要なマップの規模や複雑さなどの要件が決まり、 探索可能な迷路の作成、編集作業が始められる。 同時に素材（テクスチャマッピング用や、イベント用の挿絵、BGM等）の 必要数が見積もられ、ゲームの雰囲気に合う
ものを集めるか、 依頼することもできるようになる。 このパートでの成果の目標は、３Dダンジョンを歩き回り、 各所でイベント的なものを見たり、固定敵と戦って勝った想定のフラグを立てるなどして ゴールまで歩くことができるプログラムを完成させることである。 そのようなプログラムを開発するにあたっては、プログラマは、 迷路の形を表すマップデータの仕様を独自に設計し、 それに対応したエディタプログラムと、 実際に３D迷路を表示して歩行できるプログラムを作るのが当面の作業目標になる。 イベントやフラグの扱いについては、マップデ
ータ中に埋め込むか、 それらの発生タイミングや挙動を示したスクリプト（テキストファイル）を 解析して処理する仕組みを取り入れると汎用性が高まると思われる。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/525
526: 520 [sage] 2015/12/26(土) 23:23:46.65 ID:V44X/Fk5 疑似３D表示ダンジョンのマップエディタの開発の難易度については、 マップデータの形式が自分で決められる程度のプログラミング能力があれば、 それほど難しいものではない。 実際、このスレッドでも過去にマップエディタを発表された方が複数いたようである。 注意する点としては、マップデザイナーが、イベントやフラグの扱いをカスタマイズ できる仕組みをどのように実装するかという問題と、階層やエリアをまたぐ移動を どのような方法でマップデータに含めるかという問題かもしれな
い。 これらについては、エディタ上ではとりあえず、そうした問題が発生する地点をマークし、 そこに立ち入った際、どのようにしてほしいか記述できる仕様になっていれば、 探索プログラムを組む際に改めてコーディングしてもよい。 もちろん、プログラミング言語的なスクリプトを書かせて解析しながら実行する方法でもよい。 しかしながら、最大の問題としては、例えそのようなエディタが公開されたとしても、 迷路を作図するという作業は実は非常に地味で単調で、一作品として完成された 大規模なマップデータを作るモチベーションが続かないこと
ではないかと想像している。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/526
527: 520 [sage] 2015/12/30(水) 04:31:41.60 ID:QkM8ubds 引き続き、(2)の戦闘パートについて検討する。 戦闘には、ランダムエンカウントのザコ戦と、ストーリー（プロット）上の特定場面（地点） で発生するボス戦とあるが、まずはザコ戦について述べる。 この部分の存在意義は、 a) プレイヤーパーティの戦力(持久力)を試し、その時点での探索限界を設定する障壁 b) プレイヤーパーティの戦力増強の資する資金、経験値、アイテム等の収入源 c) ボス戦に向けた、魔法や特殊攻撃などのチュートリアル 等である。 a) は、消耗による焦燥感や恐怖を
煽る要素である。 これがなければ迷路探索は単なるフラグ探しとなってつまらないものになるため、 適度な感覚で発生することが重要である。 また、パーティの戦力アップを経験的に体感する上でも、同一条件の敵と、 ある程度の回数、遭遇できる機会を設けなければならない。 b) については、度が過ぎると「経験値稼ぎが辛い」という印象を与えかねないが、 前述のa)の達成感とのバランスが肝心である。 また、女神転生風ゲームにおいては、パーティ増強または合成素材としての仲魔の捕獲も この範疇に含める。 c) は、このゲームの戦闘システムのル
ールをプレイヤーに段階的に理解させるための 機能として、ゲームの進行とともに、徐々に複雑化する要素に慣れさせるためのものである。 例えば中ボス戦で、対策手段がわからない即死攻撃を初体験するようなことがあっては 理不尽ではないだろうか。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/527
528: 520 [sage] 2015/12/30(水) 04:50:17.43 ID:QkM8ubds 戦闘システムの実装については、そのルール設定に依存するが、 オーソドックスなパーティ型ターン制バトルの場合、 (0) 戦闘に参加するメンバー（プレイヤー側、敵側）の初期状態を定義する また、その状況をプレイヤーに開示する。 (1) プレイヤーパーティとしての行動を決める。すなわち、 戦うか、逃げるか、あるいは敵と交渉するかの選択である。 (2) 行動可能なメンバーについて、行動予定内容を設定する。 プレイヤー側については、コマンド入力インタフェースなどを用意
する。 敵側については、選択可能な行動の中からランダムに選ぶか、 人工知能的なものを準備する。 なお、行動予定内容とは、「どの動作」を「誰に対し」行うかとして記述する。 (3) 戦闘開始時点で、敵、味方すべてのメンバーで行動順序を決める。 一般的には「素早さ」のような能力が反映されるが、 敵パーティが単一種の場合、行動が集中するとバランスが悪いため、 ある程度広い乱数分布で順序評価したほうが良い。 (4) 順番が回ってきた時点で、予定の行動が可能で（生存かつ行動不能な状態異常がない） であれば、
その作戦行動を実行する。 (5) 一方が全滅したら、戦闘を終了する。 プレイヤー側が勝利した場合、HPやMP、状態異常などを探索系サブシステムに リストアする。 というような組み方が考えられる。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/528
529: 520 [sage] 2016/01/03(日) 13:21:09.37 ID:Ljo7IXRL プレイヤー側の戦闘時初期状態の決定には、 キャラクターメイキングシステムとの連携が不可欠である。 ゲームの構成にも依るが、開始時のパラメータ振り分けおよび レベルアップによる半固定パラメータの保持、更新を行うサブシステムと、 HPや状態異常などの動的ステータスの保持および更新システムが管理する 数値を、戦闘開始時に参照し、戦闘終了時に復元する形で連携させる方法がある。 この実装のポイントは、基本的なことではあるが、 プレイヤーキャラクタのパラメータおよびステ
ータス.にかかわる多項目の数値情報を 適切な方法でプレイヤーに提示するステータス画面の作り方にあると思われる。 膨大かつ複雑な依存関係があるパラメータを単純に羅列するだけでは、 プレイヤーが理解できないし、戦略や見通しを立てる楽しみが損なわれる恐れがある。 また、ステータスの回復、修復に関して、マップ上の特殊な施設の利用や、 魔法、アイテムの使用を手段とする場合、それぞれに対話式ユーザインタフェースの 実装が必要であるとともに、各ステータス異常と回復手段の対応について、 プレイヤーに学習させる時期や方法についても
配慮すべきである。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/529
530: 520 [sage] 2016/01/03(日) 13:42:03.19 ID:Ljo7IXRL 店での買い物および.武装についても、キャラクターメイキングの範疇で検討する。 まずは、パラメータ変動効果にバリエーションのある武器、防具、アイテム等のデータベースを 整備しつつ、ストーリー上のどこでどのような武器、防具を入手できるようにするかを バランス調整の際に検討する。 ゲーム内での実装は、対話型コマンド入力システムが基本となる。 加えて女神転生風ゲームを考えた場合、 戦闘で捕獲した悪魔を仲魔としてパーティに加える戦法や、 仲魔を合体させることで変化させ
るサブシステムが必要である。 なお、合体に関しては、とりあえず総当たりの表に書き表せられていれば、実装しやすい。 ここに、乱数やステータス値等の影響を絡めたシステムを入れるとすれば、 その仕組みをプレイヤーが容易に理解できるようにサポートシステムが必要である。 悪魔の合体は女神転生風ゲームの醍醐味であるため、 凝った仕掛けを考えたくなる誘惑はあるが、プレイヤーの目線で考えると 手間のかかる行為であるため、常に予定通りの結果が得られるような 公正で明朗なシステムであれば十分面白いのではないかと考えている。 http://
mevius.5ch.net/test/read.cgi/gamedev/1233369246/530
531: 520 [sage] 2016/01/03(日) 14:04:31.02 ID:Ljo7IXRL 一方で、敵チームの戦闘時初期状態の決定は、マップのエリアコードと 連携したデータベースの参照で行うのが単純である。 敵データベースには、戦闘システムの開始と処理に必要なパラメータと、 その敵の出現エリアを設定しておく。 このデータベースは、登場する悪魔の数だけ全て設定する必要があり、 名前や数値情報以外に、プレイヤーの識別を補助するための画像、 アニメーションを用意することも考えると、その作成にかかわる作業量は 膨大になる。 実際に何種類の悪魔を用意する必要
があるかというと、 多ければ多いほうが良いという考え方もあるが、 例えば、プロットをもとにマップエリアを分割し、 各エリアごとに３〜４種類の悪魔を目標にするという方法を提案する。 なお、その３〜４種類のうちの一つは、プレイヤーパーティのベンチマーク用に、 物理攻撃しか行わない咬ませ犬的な敵とするとよい。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/531
532: 520 [sage] 2016/01/16(土) 08:16:51.31 ID:nb4XakV3 ここまでに考察したところで、女神転生風ゲームのゲームシステム面での 主要な要件は出そろったと思われる。 以後、実際に女神転生風のゲームを試しに作りながら、考察が足りない点は その都度、検討する方向で進めてみたい。 当面の目標としては、このスレッドのタイトルに倣って、 「３Ｄダンジョン（迷路および謎解き）」を制作、編集、テストができる環境を整えることとする。 参考までに、現時点の画面のイメージはこのような状況である。 ttp://amadela.web.fc2.com/megaten/image/
preview20160116.png http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/532
533: 520 [sage] 2016/01/16(土) 10:06:51.12 ID:nb4XakV3 ３Ｄダンジョンに関する要求については、>>525-526で書いているが、 このプログラムを作成するに際して、より詳細な検討を加えている。 まず、迷路を保持するデータ構造について説明するため、 迷路を構成する最小単位を便宜的に「セル」と呼ぶとする。 １つのセルには、必須データとして、 ・セルの座標 ｘ、ｙ （ｘは東西方向、ｙは南北方向） ・セルの東西南北の境界表現（壁の有無、または扉） を持たせている。 このセルを複数集めて、１つのフロアマップを形成している。
複数のセルの管理にはリンクドリストを使用していて、 任意の形、任意の広さのフロアを表現することが可能である。 と言っても、１フロアあたりせいぜい１００セル程度に留めておきたい。 また、必要がある場合に限り、セルには以下の付帯情報を記憶させることが できる仕組みになっている。 ・天井と床の穴表現有効化フラグ ・ダークゾーンフラグ ・セルの名前 ・イベント処理用スクリプト（任意行数のプログラムテキスト） 上述の試作プログラムでは、以上の情報を用いてマップデータの編集および 歩行移動テストが可能になっている。 http://mev
ius.5ch.net/test/read.cgi/gamedev/1233369246/533
534: 520 [sage] 2016/01/16(土) 10:38:57.47 ID:nb4XakV3 試作プログラムにおけるマップの編集について、少し工夫したことを書いておく。 このプログラムでは、ゲームプレイ時のスタイルでカーソルキーを使い、 ３Ｄ迷路を歩き回ることが出来ていて、そのシステムに上乗せする形で、 ・スペースキーを押すと、眼前に１つセルを作り、現在地点との間を通路でつなぐ。 ・ＤＥＬキーを押すと埋め戻す。 ・コマンドまたはショートカットキーで、眼前に壁や扉を設置または撤去する。 ・コマンドで階段表示、ダークゾーン設定およびスクリプト編集する。
という仕様になっている。 つまり、３Ｄマップを歩いてみて、この辺に通路を開けたいと思ったら、 スペースキーを押しながら前進すれば、好きなだけ穴を掘っていける という変則的な方法でマップを編集する方法にしている。 おそらく一般的に、３Ｄダンジョンのマップエディタといえば、 ttp://amadela.web.fc2.com/megaten/image/houganmap.png のような、迷路を俯瞰した形で編集するのが常識ではないかと思われる。 しかし、このようなエディタは、「あらかじめ方眼紙などにデザインされた マップを、ゲームプログラムで扱えるデータに打ちなおす
」目的であれば 効率的なツールになるかと思うが、そもそも方眼紙を前にして、 マップをデザインするという作業が全然楽しく思えないと、生産性が悪い。 当初は俯瞰型のエディタも作ってはみたが、 何のモチーフもなしに迷路を描くというのは非常に効率が悪いと感じたため、 このように、プレイヤー目線の体験の拡張でマップデータを編集する仕組み を開発した次第である。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/534
535: 520 [sage] 2016/01/19(火) 22:57:14.21 ID:u9fe2fGH 迷路の描画については、魔法のマッパーが有効な時の俯瞰表示と、 メインウィンドウとなる疑似３Ｄ迷路の２つがある。 俯瞰表示については、フロアマップのセル群のうち、所定の範囲 （この場合、進行方向前後５マス、左右３マス）にあるものについて、 進行方向が画面上側になるように回転させて描画する。 描画する際はセル単位に相互に重ならないように描くようにすれば、 描画順序（セルの保持順序）を気にしなくてもよい。 それに対して（Ｚバッファを使わない）疑似３Ｄ表示について
は、 奥から手前に向かい、左右は両端から中央に向かって描画 する必要があるため、現在の地点座標と向いている方角から、 視界内（試作プログラムでは奥に４ブロック、横７ブロック）の 進行方向側の壁（または門）と、左手および右手のそれらを 一旦配列に集計してから、所定の順番に描画する方法としている。 この集計処理は、移動または向きを変えるごとに必要なので、 処理時間が気になるならマップの保持方法を見直すなどの 高速化・最適化が有効であると考えられるが、 １００セル程度のマップであれば、今どきのＰＣなら気にする ほどの時間
はかからない。。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/535
536: 520 [sage] 2016/01/20(水) 23:38:56.10 ID:yqZ8gL0+ マップエディタでは、迷路形状データの編集と合わせて マップ上に様々な仕掛けを配置することも重要な機能である。 仕掛けとは、ターンテーブルやワープなどの罠だけではなく、 階段によるマップ間移動や、会話イベント、宝物の配置、 店や宿などの施設の設定全般のことである。 これらの仕掛けをマップデータ中に定義する方法としては、 マップ上の該当セルにユニークな名称（ラベル）を設定するとともに、 その名称に対応する仕掛けの内容を説明した任意様式の設定資料を 併用する方法が
考えられる。 仕掛けの内容は当然ゲーム内容によって変わるものであるため、 ストーリーの核心に触れるような謎解きイベントなどの実現には、 どこかの段階でプログラミング作業が必要で、マップエディタ上で テストを完結するのは難しい。 簡単な仕掛け、例えばターンテーブルや、情報が得られるメッセージなどは、 簡単なイベントコードと、メッセージテキストなどのカスタマイズ可能な要素を マップデータ中に記録できる形式を定義してやれば、テストできないこともない。 しかし、「あるアイテムを持ってその場所に行くと中ボスが表れて、 会話
の流れで”いいえ”を選択すると戦闘になって、勝利したら あるフラグが立ってアイテムを消失する」のような、ストーリー上に 一回でもあるかどうかわからないようなイベントのテンプレートを エディタ設計時に想定して組み込んでおくという発想には限度がある。 この課題があるために、汎用性のある３Ｄ迷路のデータ構造の定義は困難で、 そのようなエディタを開発しようとした場合に悩むことになる。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/536
537: 520 [sage] 2016/01/27(水) 23:34:21.05 ID:VDw6Dqmf そこで、マップデータにイベントを埋め込むという発想を拡張し、 イベントやマップ情報をひっくるめて「３ＤダンジョンＲＰＧ」そのものを コントロールする処理システムというものを考える。 コントロールする対象は、ターンテーブルやマップ間移動のような 迷路のトラップに関するもののほか、情報を表示するためのウィンドウシステム、 プレイヤーの入力ＵＩ、ゲームの進行を管理するフラグ等、 制御内容を容易に"記述可能"なものから順に考えている。 これにより、イベント
の設置、つまり制御内容を記述しテストする作業を、 迷路の設計と並行してマップデザイナー（兼シナリオライター）一人で 完結させるのが目的である。 実のところ、この仕組みを発展（制御対象を拡大）していけば、 既存のＲＰＧエディタ、ツクール等や、スクリプト処理言語と同じようなものに なっていく。結局、イベントを細かくカスタマイズしようと思ったら、 どういう形であれ、プログラミング的な作業は避けられない。 汎用性を高くしすぎて、とっつきにくいエディタになるのは不本意なので、 ”女神転生風”ということを再確認して、処理系を
構築しようと思っている。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/537
538: 520 [sage] 2016/01/28(木) 22:08:46.47 ID:dhlMU4Pp 参考のために一例を示す。 ttp://amadela.web.fc2.com/megaten/image/preview20160128.png マップ上を移動し、このセルに踏み込んだら、 このセルのマップ情報に付帯しているスクリプトを テストプログラムが解釈する仕掛けになっている。 上から順に、画像ファイルを指定して表示、 ウィンドウを開く、テキストを表示する（２行）、 プレイヤーのキー入力待ち、画像消去、ウィンドウ消去 を意図した記述になっている。 画像ファイルとメッセージ文字列以外は一般に定型でよいため、 設置
指示時に、エディタがテンプレートを貼るようにしてある。 この例に示す程度の、上から下に進むだけの動作の記述であれば、 プログラミングの知識に関係なく、マップデザイナーの作業範疇で 容易にカスタマイズができるのではないだろうか。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/538
539: 520 [sage] 2016/01/29(金) 22:08:40.81 ID:iWN0LHQ9 もう少し複雑になった例を示す。 ttp://amadela.web.fc2.com/megaten/image/preview20160129.png 宝箱があり、開けるかどうか聞かれ、「はい」と答えると中身を入手する パターンである。 ウィンドウにテキストが表示されるあたりは前例と同様で、 「はい」「いいえ」の回答によって分岐する部分があることと、 魔ッ貨と宝玉の入手にかかわる内部変数操作、そして、 宝箱開封済みを示すフラグの操作で構成される。 このスクリプトはマップデータ中の該当セルに埋め込んであるが、 魔ッ貨
、宝玉および取得済みフラグについては、 別の定義ファイル中で宣言し、ゲーム進行中保持するようになっている。 なお、「マップ中のアイテムを取得する」という行為を表現するには、 この例のように、アイテム取得済みのフラグを立て、次回は、そのフラグが 既に立っているなら処理しない、というロジックを使うのがセオリーである。 プログラミング経験者にとっては当たり前のことだが、マップデータ中から、 アイテムの記述情報を取り除くような真似はしない点、念を押しておく。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/539
540: 520 [sage] 2016/01/29(金) 22:24:46.29 ID:iWN0LHQ9 このほか、階段の昇り降りやエレベータ判定、店などに入った時の切り替えも、 同じようにマップセル中にスクリプトとして記述できる。 店や回復施設など、複雑な選択操作やデータアクセスを伴うものについては、 別途プログラマが実体を開発する必要があるが、マップ上の特定地点に その施設を置くという指示は、マップデザイナーに委ねることができる。 また、併せてストーリー進行に関しても、フラグを併用して迷宮内の謎を解きながら 探索するというパズル性も、若干プログラミング的な
思考を伴うが記述可能で、 エディタ上でテストできる環境が整った。 現在、試しにＦＣ版女神転生のダイダロス塔（静玉をとってエレベータに乗れるまで）を このシステムで収容できるかどうかテストしているところである。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/540
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 39 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.012s