3DダンジョンRPGエディタを作るスレ (587ﾚｽ)
上下前次1-新
502: 2011/05/29(日)16:27 ID:1TXd3jxq(1) AAS
外部ﾘﾝｸ[zip]:www1.axfc.net
パスdungeon
エディタでマップのエンカウント率を追加
ゲーム側はエンカウント時に画面が光るだけ
起動テスト追加
>>501
今できることは起動しない対策 > 機能追加 > 致命的なバグ修正
という感じなので使い勝手とかは後回しになる。スマン！
503: 2011/06/22(水)16:02 ID:4bs0hzuK(1) AAS
商用利用にはおｋなのかしら
504(1): 2011/06/29(水)23:03 ID:NvqZlOfF(1) AAS
協力したいけど自分の5年前のパソコンでは動かなかったよ
期待してるので頑張ってくれー
505: 2011/06/29(水)23:12 ID:qGpPtV8x(1) AAS
>>504
貴殿のパソコンのスペックを 詳細に記述せよ。
506: 2011/06/30(木)13:09 ID:UVxYsoY6(1) AAS
自分もエディタ制作中
画像ﾘﾝｸ
wxWidgetsとOpenGLで作ってマルチプラットフォームという野望なのだが
飽きてきたからやめるかも
507: 2011/06/30(木)19:30 ID:lQ5gPVWB(1) AAS
画像が内臓
508: 2011/08/31(水)13:44 ID:7+4nZq7i(1) AAS
がんばってほしい
509: 2011/12/06(火)13:06 ID:oDkZLgbY(1) AAS
あげ
510: 2012/02/12(日)14:04 ID:RqRicYC4(1) AAS
ほしゅ
511: 2012/06/10(日)00:25 ID:FQvO3Ugf(1) AAS
とりあえずWolfRPGエディタで作り始めた
思った以上に作りやすかったので
そのうち晒す予定
よろ
512(3): 2012/06/17(日)18:52 ID:j3pvc46H(1) AAS
移動画面がある程度できたので、うｐ
まだちょこちょこ不具合が残ってるので、それ解消できたら今度動くものを上げる
画像ﾘﾝｸ
513: 2012/06/17(日)19:48 ID:UmwMC15z(1) AAS
ほほうメガテン風ですか
514: 512 2012/06/24(日)07:36 ID:W+QaEoro(1) AAS
外部ﾘﾝｸ[zip]:gmdev.xrea.jp
とりあえず、動くはずの現物をうｐした
移動、オートマップのみ
移動はまだアニメしない
そのうちやる
515: 512 2012/07/08(日)21:26 ID:07j0qygt(1) AAS
外部ﾘﾝｸ[zip]:gmdev.xrea.jp
途中経過
516: 512 2012/07/15(日)17:47 ID:6hwYku9y(1) AAS
外部ﾘﾝｸ[zip]:gmdev.xrea.jp
店、装備、ステータス表示実装。
517: 【22.5m】 電脳プリオン 2014/07/19(土)23:16 ID:u5G307Tj(1) AAS
作れた？
518: 2015/05/18(月)18:41 ID:dck9pVIE(1) AAS
もうそろそろ完成したかな？
519: 2015/06/05(金)01:32 ID:RxuzpeQF(1) AAS
それはどうかな？
520(39): 2015/12/17(木)21:52 ID:G0Ny1aox(1) AAS
このスレは要するに女神転生のゲームシステムに、自作のデータを載せたゲームを制作する、というのが目標になるのかな？
521(1): 520 2015/12/19(土)20:41 ID:u/NtzQZv(1) AAS
仮にそうだとして、環境が整えば、そういうゲームを作りたいと言う人は、今でも残っているのかな？
522: 520 2015/12/25(金)22:32 ID:RLVlGygE(1/2) AAS
反応がない。やはり誰も見ていない廃墟スレのようだ。
ならば気兼ねなく、女神転生'風'の３DダンジョンRPG製作技術について語るスレとして、
ここを再利用させてもらうことにしようと思う。
523: 520 2015/12/25(金)22:57 ID:RLVlGygE(2/2) AAS
最初に、女神転生’風’をもう少し具体的にする必要がありそうだ。
ファミコンの頃から続くシリーズのゲームなので、簡単には言い表せないかもしれないが、
・疑似３D表現された迷宮内を探索する
・悪魔（敵）とは戦うだけでなく、交渉次第で仲魔にできる
・仲魔複数体を合体させて、強い仲魔を作ることができる
という要素が特徴的である、と記憶している。
プレイヤーキャラをレベルアップし、資金をためて武装強化するとともに、
仲魔の協力を得ながら迷宮内のイベントを片付けつつ進み、
最後のボスを倒す、というのはRPGの定番とも言える流れであろう。
524: 520 2015/12/26(土)12:11 ID:V44X/Fk5(1/3) AAS
次に、ゲーム性の観点から整理すると、
(1)３D表現された迷路の中を探索し、所定のフラグを立てるゲーム
(2)戦闘等で得た資金・資源をもとにパーティの戦力（持久力）を強化しながら、
その維持に要するコストを賄う経営的ゲーム
が融合したゲームであると言える。
(1)には、ストーリー的設定や、謎解き要素を絡めて飽きさせないことが求められる。
プログラミング的には、古典的でオーソドックスな方法で実装できそうである。
ただし、昔と違って、方眼紙に地道にマッピングしながらプレイする時代ではないようなので、
快適に探索できるようなサポート要素が必要かもしれない。
(2)は、戦闘で経験値を集めてレベルアップ、資金を貯めて武装強化など、
RPGでよく見かけるハック＆スラッシュ要素と並行して、このシリーズの特徴である
『戦闘によって捕獲した仲魔を複数掛け合わして未知の仲魔を作り出す要素』
によって、より深淵部を安全に探索する戦力が得られたという達成感をもたらす。
プレイヤーを飽きさせないためには、十分な種類の装備品、仲魔を用意する一方で、
適切なタイミングで強化させ、その効果を実感できる体験を用意する必要があろうかと思う。
なお、強力な仲魔を連れ歩くには相応のコスト（生体マグネタイト）が発生するルールに則り、
コストパフォーマンスを気にしながら遠征しなければならないジレンマに陥らせることが、
ゲームバランスを調整する際のポイントかもしれない。
525(1): 520 2015/12/26(土)22:58 ID:V44X/Fk5(2/3) AAS
このようなゲームを制作するにあたり、上の(1)と(2)を分離して検討することにする。
まず、(1)迷路探索＆フラグ立てゲームのパートについては、
最初にそのゲームのストーリーや世界観を設定し、可能であれば
攻略の流れがわかるプロットを準備するべきである。
それにより、必要なマップの規模や複雑さなどの要件が決まり、
探索可能な迷路の作成、編集作業が始められる。
同時に素材（テクスチャマッピング用や、イベント用の挿絵、BGM等）の
必要数が見積もられ、ゲームの雰囲気に合うものを集めるか、
依頼することもできるようになる。
このパートでの成果の目標は、３Dダンジョンを歩き回り、
各所でイベント的なものを見たり、固定敵と戦って勝った想定のフラグを立てるなどして
ゴールまで歩くことができるプログラムを完成させることである。
そのようなプログラムを開発するにあたっては、プログラマは、
迷路の形を表すマップデータの仕様を独自に設計し、
それに対応したエディタプログラムと、
実際に３D迷路を表示して歩行できるプログラムを作るのが当面の作業目標になる。
イベントやフラグの扱いについては、マップデータ中に埋め込むか、
それらの発生タイミングや挙動を示したスクリプト（テキストファイル）を
解析して処理する仕組みを取り入れると汎用性が高まると思われる。
526(1): 520 2015/12/26(土)23:23 ID:V44X/Fk5(3/3) AAS
疑似３D表示ダンジョンのマップエディタの開発の難易度については、
マップデータの形式が自分で決められる程度のプログラミング能力があれば、
それほど難しいものではない。
実際、このスレッドでも過去にマップエディタを発表された方が複数いたようである。
注意する点としては、マップデザイナーが、イベントやフラグの扱いをカスタマイズ
できる仕組みをどのように実装するかという問題と、階層やエリアをまたぐ移動を
どのような方法でマップデータに含めるかという問題かもしれない。
これらについては、エディタ上ではとりあえず、そうした問題が発生する地点をマークし、
そこに立ち入った際、どのようにしてほしいか記述できる仕様になっていれば、
探索プログラムを組む際に改めてコーディングしてもよい。
もちろん、プログラミング言語的なスクリプトを書かせて解析しながら実行する方法でもよい。
しかしながら、最大の問題としては、例えそのようなエディタが公開されたとしても、
迷路を作図するという作業は実は非常に地味で単調で、一作品として完成された
大規模なマップデータを作るモチベーションが続かないことではないかと想像している。
527: 520 2015/12/30(水)04:31 ID:QkM8ubds(1/2) AAS
引き続き、(2)の戦闘パートについて検討する。
戦闘には、ランダムエンカウントのザコ戦と、ストーリー（プロット）上の特定場面（地点）
で発生するボス戦とあるが、まずはザコ戦について述べる。
この部分の存在意義は、
a) プレイヤーパーティの戦力(持久力)を試し、その時点での探索限界を設定する障壁
b) プレイヤーパーティの戦力増強の資する資金、経験値、アイテム等の収入源
c) ボス戦に向けた、魔法や特殊攻撃などのチュートリアル
等である。
a) は、消耗による焦燥感や恐怖を煽る要素である。
これがなければ迷路探索は単なるフラグ探しとなってつまらないものになるため、
適度な感覚で発生することが重要である。
また、パーティの戦力アップを経験的に体感する上でも、同一条件の敵と、
ある程度の回数、遭遇できる機会を設けなければならない。
b) については、度が過ぎると「経験値稼ぎが辛い」という印象を与えかねないが、
前述のa)の達成感とのバランスが肝心である。
また、女神転生風ゲームにおいては、パーティ増強または合成素材としての仲魔の捕獲も
この範疇に含める。
c) は、このゲームの戦闘システムのルールをプレイヤーに段階的に理解させるための
機能として、ゲームの進行とともに、徐々に複雑化する要素に慣れさせるためのものである。
例えば中ボス戦で、対策手段がわからない即死攻撃を初体験するようなことがあっては
理不尽ではないだろうか。
528: 520 2015/12/30(水)04:50 ID:QkM8ubds(2/2) AAS
戦闘システムの実装については、そのルール設定に依存するが、
オーソドックスなパーティ型ターン制バトルの場合、
(0) 戦闘に参加するメンバー（プレイヤー側、敵側）の初期状態を定義する
また、その状況をプレイヤーに開示する。
(1) プレイヤーパーティとしての行動を決める。すなわち、
戦うか、逃げるか、あるいは敵と交渉するかの選択である。
(2) 行動可能なメンバーについて、行動予定内容を設定する。
プレイヤー側については、コマンド入力インタフェースなどを用意する。
敵側については、選択可能な行動の中からランダムに選ぶか、
人工知能的なものを準備する。
なお、行動予定内容とは、「どの動作」を「誰に対し」行うかとして記述する。
(3) 戦闘開始時点で、敵、味方すべてのメンバーで行動順序を決める。
一般的には「素早さ」のような能力が反映されるが、
敵パーティが単一種の場合、行動が集中するとバランスが悪いため、
ある程度広い乱数分布で順序評価したほうが良い。
(4) 順番が回ってきた時点で、予定の行動が可能で（生存かつ行動不能な状態異常がない）
であれば、その作戦行動を実行する。
(5) 一方が全滅したら、戦闘を終了する。
プレイヤー側が勝利した場合、HPやMP、状態異常などを探索系サブシステムに
リストアする。
というような組み方が考えられる。
529: 520 2016/01/03(日)13:21 ID:Ljo7IXRL(1/3) AAS
プレイヤー側の戦闘時初期状態の決定には、
キャラクターメイキングシステムとの連携が不可欠である。
ゲームの構成にも依るが、開始時のパラメータ振り分けおよび
レベルアップによる半固定パラメータの保持、更新を行うサブシステムと、
HPや状態異常などの動的ステータスの保持および更新システムが管理する
数値を、戦闘開始時に参照し、戦闘終了時に復元する形で連携させる方法がある。
この実装のポイントは、基本的なことではあるが、
プレイヤーキャラクタのパラメータおよびステータス.にかかわる多項目の数値情報を
適切な方法でプレイヤーに提示するステータス画面の作り方にあると思われる。
膨大かつ複雑な依存関係があるパラメータを単純に羅列するだけでは、
プレイヤーが理解できないし、戦略や見通しを立てる楽しみが損なわれる恐れがある。
また、ステータスの回復、修復に関して、マップ上の特殊な施設の利用や、
魔法、アイテムの使用を手段とする場合、それぞれに対話式ユーザインタフェースの
実装が必要であるとともに、各ステータス異常と回復手段の対応について、
プレイヤーに学習させる時期や方法についても配慮すべきである。
530(1): 520 2016/01/03(日)13:42 ID:Ljo7IXRL(2/3) AAS
店での買い物および.武装についても、キャラクターメイキングの範疇で検討する。
まずは、パラメータ変動効果にバリエーションのある武器、防具、アイテム等のデータベースを
整備しつつ、ストーリー上のどこでどのような武器、防具を入手できるようにするかを
バランス調整の際に検討する。
ゲーム内での実装は、対話型コマンド入力システムが基本となる。
加えて女神転生風ゲームを考えた場合、
戦闘で捕獲した悪魔を仲魔としてパーティに加える戦法や、
仲魔を合体させることで変化させるサブシステムが必要である。
なお、合体に関しては、とりあえず総当たりの表に書き表せられていれば、実装しやすい。
ここに、乱数やステータス値等の影響を絡めたシステムを入れるとすれば、
その仕組みをプレイヤーが容易に理解できるようにサポートシステムが必要である。
悪魔の合体は女神転生風ゲームの醍醐味であるため、
凝った仕掛けを考えたくなる誘惑はあるが、プレイヤーの目線で考えると
手間のかかる行為であるため、常に予定通りの結果が得られるような
公正で明朗なシステムであれば十分面白いのではないかと考えている。
531: 520 2016/01/03(日)14:04 ID:Ljo7IXRL(3/3) AAS
一方で、敵チームの戦闘時初期状態の決定は、マップのエリアコードと
連携したデータベースの参照で行うのが単純である。
敵データベースには、戦闘システムの開始と処理に必要なパラメータと、
その敵の出現エリアを設定しておく。
このデータベースは、登場する悪魔の数だけ全て設定する必要があり、
名前や数値情報以外に、プレイヤーの識別を補助するための画像、
アニメーションを用意することも考えると、その作成にかかわる作業量は
膨大になる。
実際に何種類の悪魔を用意する必要があるかというと、
多ければ多いほうが良いという考え方もあるが、
例えば、プロットをもとにマップエリアを分割し、
各エリアごとに３〜４種類の悪魔を目標にするという方法を提案する。
なお、その３〜４種類のうちの一つは、プレイヤーパーティのベンチマーク用に、
物理攻撃しか行わない咬ませ犬的な敵とするとよい。
上下前次1-新書関写板覧索設栞歴
あと 56 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.010s