3DダンジョンRPGエディタを作るスレ (579ﾚｽ)
3DダンジョンRPGエディタを作るスレ http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
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
541: 520 [sage] 2016/02/11(木) 06:26:13.14 ID:TKq/gaXF ダイダロス塔クリアまでの迷宮マップとイベントの設置テスト結果について。 このエリアの１階には一部に一方通行の場所とダークゾーンがあるが、 これらを含め、宝箱や壁の落書きなど全てそれっぽく収容することができた。 ttp://amadela.web.fc2.com/megaten/image/minotauros.png セル単位に東西南北の壁または通路を記憶する本方式では、 隣接部屋間のその設定値を敢えて不整合にすることで 一方通行を設定することができる。 定型的なトラップの一種なので、エディタ上で入力サポートするように 機能を追加した。 ダークゾーンについては、階段と同じように、該当セルにフラグを立てて置き、 描画ルーチンの対応で表現する方法で実装する。 原則的には、ダークゾーンは壁または扉で仕切られたエリアを充填するもので、 そのエリア内にいる間はメインウィンドウを霧で目隠しする表現方法をとるのだが、 もし、ダークゾーンが広間の途中に浮いているようなデータであったとしても、 白い柱が立っているような形で見えるように、描画処理を工夫してみた。 ttp://amadela.web.fc2.com/megaten/image/preview20160211.png http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/541
542: 名前は開発中のものです。 [sage] 2016/02/12(金) 16:23:07.19 ID:iP/PhpAe がんばって〜 どこまで作るか知らないけど http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/542
543: 520 [sage] 2016/02/13(土) 04:45:31.70 ID:sZ75RTIP 当面の目標はファミコン版女神転生を収容できるシステム＆エディタを自作することで、 現状、３Ｄ迷路のマップデータとトラップ類の設置については既報のとおり完了した。 幸いにして実機およびＲＯＭカセットを所有しているのと、攻略サイトやプレイ動画等 豊富に情報があるので入力と検証も自力で可能なのがありがたい。 問題があるとすれば今後のモチベーションをどのように保っていくかと思われる。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/543
544: 520 [sage] 2016/02/13(土) 05:36:14.41 ID:sZ75RTIP ここからは開発の焦点を変えて、このゲームのプレイ要素の一つである キャラクターメイキング、パーティ編成のシステムの実装について検討する。 最終的に、戦闘システムの勝敗に関わる要素であるため、バランス調整が 肝になると予測されるが、まずはプレイヤーとのインタフェース部分から考えていく。 本作中には、戦士型のナカジマ、魔法使い型のユミコと、その他仲魔の３タイプの キャラクタが登場し、その設定項目がタイプ別に微妙に異なることと、 それに応じてステータス画面のレイアウトも変える必要がある。 共通する要素としては、 ・名前、種族、レベル ・強さ、知力、攻撃、機敏さ、運もしくは防御 ・ＨＰおよび最大ＨＰ ・ＭＰおよび最大ＭＰ（ただし、ナカジマはともに０） ・状態異常フラグ で、固定（半固定）な値もあれば、ゲームの進行で変動するものも含まれる。 項目さえ決めてしまえば、これらを管理するクラスを作るのは容易であるが、 項目をカスタマイズ可能にしようとすると少し面倒になる。 少しやりかけてみたが、ＵＩ処理の実装など足かせになるばかりなので、 ＦＣ版の仕様に準拠した構成で進めることにしたい。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/544
545: 520 [sage] 2016/02/13(土) 05:50:40.09 ID:sZ75RTIP キャラクターのステータス値の構成が決まったら、 次にできることは以下の通りである。 (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)で作った画面のＵＩ部品を流用できる。 数値を扱うユーザインタフェースを作るのは地味であるが、 ゲームの根幹をなすシステムなので、しっかりと作っておきたい。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/545
546: 520 [sage] 2016/02/16(火) 21:35:12.25 ID:OSyFbIMG キャラクターメイキングの画面を試作した。 ttp://amadela.web.fc2.com/megaten/image/making.png また、同種の方法でプレイヤーのステータス画面および 仲魔のステータス画面も実装してみた。 ttp://amadela.web.fc2.com/megaten/image/status.png ステータス画面に、キャラクタの肖像画が表示されるというのは ＦＣ版で、特に印象的だった記憶がある。 試作プログラムにおいてもその仕様に準拠し、 複数枚の画像を用意すればアニメーションも可能である。 なお、プレイヤーたちの画像および悪魔の画像については、 真面目に描こうという気が全く感じられないと思われるかも 知れないが、当然のことながら、差し替え可能な仕組みに作ってある。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/546
547: 520 [sage] 2016/02/23(火) 04:44:06.01 ID:VJ1v/4yS このゲームでは、パーティに悪魔を加えるためには、 事前に交渉（もしくは合体）の上で「仲魔」として登録が必要とされる。 仲魔はＦＣ版では最大７体まで登録可能である。 この「仲魔登録」クラスの設計については、以下の仕様とする。 (1)初期状態では空っぽとする (2)登録しようとする悪魔が既にエントリされていないかチェックする (3)登録数が上限に達していないかチェックする (4)登録可能な場合、悪魔の種類と現在のHP、MPをセットで配列末尾に登録する (5)登録されている悪魔を抹消し、配列を詰める (6)悪魔データベース記載の最大HP,MPを参照し、回復に必要な金額を算出する とりあえず今思いつくのはこれくらいだが、単純な配列操作で実装できそうだ。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/547
548: 名前は開発中のものです。 [sage] 2016/02/24(水) 21:20:20.48 ID:3aPoux15 なんの言語を使っているのだろう。 配列じゃなくList型とかでもいい気がする？ class Nakama { int hp, mp; } List<Nakama> nakamaList; みたいな。 ちなみに自分は、敵、味方、（未実装だけど味方が召喚したのも） Characterクラスで統一して、 List<Character> characterList; で一括管理ｗ http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/548
549: 520 [sage] 2016/02/25(木) 22:31:03.08 ID:cdKIzSfc システム設計上の話とプログラミングの話を曖昧にして申し訳ない。 ゲームの仕様上は、要素数に上限のある配列構造を準備できればよく、 プログラミング上、必要な操作ができるのであれば、 listでもarrayでも構わない。 ただ、この仕様で敢えてlistを採用するメリットが見いだせない。 と言ってデメリットもないような気もするが、、 高々７個程度の要素数では、効率云々を議論するまでもなく、 結局、どっちでも構わないと思う。 なお、的確な指摘であるだけに、最後の「ｗ」は残念だ。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/549
550: 名前は開発中のものです。 [sage] 2016/02/27(土) 00:05:51.89 ID:xKWjyR2t おおう、申し訳ない。 「ｗ」はクセのようなもので他意はないです。失礼しました。 なるほど、論理設計上、配列的な設計ということですね。 3Dダンジョン繋がりで、いろいろ参考にさせてもらってます。 （「セル」という名前付けは同じなんだなー、とか、 セル同士リンク構造でつなげてるんだなー、とか（うちはX×Yの方形構造）） http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/550
551: 名前は開発中のものです。 [sage] 2016/02/27(土) 18:53:42.63 ID:k3nxuSN5 3Dダンジョン ウィザードリィをベースに作ってる ワイヤーフレームと3D画像と http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/551
552: 520 [sage] 2016/02/28(日) 21:40:29.87 ID:fYTROrM4 引き続き、その「仲魔登録クラス」の利用方法について検討する。 戦闘状態で交渉に成功したときに、登録エントリーの末尾に新規登録するのは 特に問題はないと思われる。 ＣＯＭＰ→よぶコマンドを実行したときには、 「登録している仲魔のうち、まだ召喚していない悪魔」の選択リストを作る操作と、 その選択画面でカーソルを動かしたとき、呼び出しコストの見積もり表示を更新する 処理が必要になる。 この処理の実装に、汎用的なメッセージウィンドウを流用するのが困難であれば、 専用の選択ダイアログを作る価値はあると思う。 ttp://amadela.web.fc2.com/megaten/image/compcall.png ＣＯＭＰ→もどすコマンドを実行したときには、 仲魔登録クラス側のＨＰ，ＭＰを更新し、回復の泉での代金計算に利用する。 最後に重要なのが、邪教の館での合体対象の選択ＵＩで、 これは合体表（実質的にはドリアード確認表）を示して 合体対象の悪魔２体を選択するウィンドウである。 これも、この選択専用に作ったほうが容易である。 ttp://amadela.web.fc2.com/megaten/image/gattai.png 合体を実行したときには、 (1)選択した２体の悪魔が召喚中なら帰還させ、仲間登録エントリから抹消し、 (2)合体結果の悪魔を、エントリの末尾に登録する という操作を行う。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/552
553: 520 [sage] 2016/02/28(日) 21:57:23.90 ID:fYTROrM4 >>550 セル（部屋）をリストで管理する方法については>>533で述べたように、 広さや形、フロア間の相対的な位置関係を気にせずに ストレスなく作成、編集できるようにするための実装であるが、 方形配列に比べてアクセス効率が悪いデメリットがある。 しかし、これも仲間登録クラスの実装の問題と同じで、 今のＰＣなら速度的に大して問題にならないという理由で、 ３Ｄダンジョンに限らず、拙作のドラクエ風ゲームでも採用している。 ただし、マップデータの保持がそうなっているだけで、 マップを表示する処理クラス内では、速度的な効率改善のため、 視野範囲内の壁や仕掛け要素を一旦、方形配列に抽出してから 利用している。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/553
554: 名前は開発中のものです。 [sage] 2016/03/04(金) 19:52:08.14 ID:4OMe0RSY なるほど、セル＝１マスじゃなくてセル＝１部屋だったのか。通りで ＞１フロアあたりせいぜい１００セル程度 １００って少ないと思ってたんだ（２０ｘ２０でも４００マスだし） http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/554
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 25 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.028s