3DダンジョンRPGエディタを作るスレ (579ﾚｽ)
3DダンジョンRPGエディタを作るスレ http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
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
555: 520 [sage] 2016/03/05(土) 08:32:14.84 ID:/l9sJN3a ２０ｘ２０というと、Wizardryのマッピングを思い出す。 なお、ＦＣ版の女神転生は、基本８ｘ８部屋で１フロア（またはフロア中のエリア） を構成する仕様になっている。 技術的な理由が何かあったのかどうかわからないが、 説明書にも８×８を単位にマッピングしながらプレイすることが推奨されている。 無論、今どきの制作、実行環境でそのようなサイズ制限は考えなくてもよいが、 序盤から暗記できないほど巨大なマップを歩かせるよりも、 (1)まずは３Ｄ迷路を歩くこと、 (2)繰り返し歩くことでマップを覚えること、 (3)覚えきれなってきたらマッピングをすること、 という難易度の段階的設計は、考慮してもいいと思う。 その延長に、マッピング作業を困難にするトラップや、 ８×８という固定観念を破るようなマップを登場させると有効な気がする。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/555
556: 520 [sage] 2016/03/10(木) 04:16:15.09 ID:zG9zBMGi 話を仲魔登録クラスに戻して続けようと思う。 仲魔を最もアクティブに使うのは、合体操作を行う「邪教の館」で、 "合体"という操作についての仕様を検討する。 とりあえず、ＦＣ版の２体合体を考える。 ＵＩを使って合体させる２体を選んだあと、何になるかについては、 >>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 クタム http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/556
557: 520 [sage] 2016/03/10(木) 04:37:27.29 ID:zG9zBMGi 合体ルールを自作する場合に配慮すべき点としては、 ＦＣ版においては、原則として一旦仲魔にした悪魔の登録は、 むやみに解除できないということと、登録数には上限があること、 そして、登録数の空きを確保するには合体させる必要があることである。 ただし、以下の場合には合体ができない。 (1) 合体後の悪魔と同種のものが既に登録されている場合 (2) 合体後の悪魔が現在のパーティレベルに比べて高すぎる場合 そのため、仮に合体素材よりも強い悪魔しか生成されないルールになっていると、 現在の探索範囲に対しコストパフォーマンスが悪い悪魔だらけになって、 呼び出し魔っ貨やマグネタイトが不足するようになったとしても、 合成も新規加入もできずに手詰まりを起こす可能性が考えられる。 なので、ある程度の割合で弱体化する組み合わせも必要ではないかと 考えられる。 ちなみにＦＣ版の場合、仲魔をDEAD状態にしてからパスワードをとると その悪魔は記録されないという裏技のような救済策があるようだが、 飼えなくなったペットを捨てるような罪悪感があって、実行したことがない。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/557
558: 520 [sage] 2016/03/10(木) 05:05:33.34 ID:zG9zBMGi 合体に関する実装に関しての話題を２つほど。 合体元を指定したとき、合体後の悪魔のステータスをプレビューできるが、 そのときには、悪魔の画像はグレイスケールで表示したい。 ttp://amadela.web.fc2.com/megaten/image/gattaipreview.png ファミコンの場合、おそらくパレット変換で処理しているとみられるが、 拙作のプログラムでは自前でRGB→Y変換して表示した。 画像ファイルの扱いをライブラリに丸投げしている場合には、 このような処理ができるのか確認しておいたほうが良い。 合体を実施することにした場合、２つの悪魔が合体する様子を イメージしたデモンストレーションを挿む。 ＦＣ版では左右から中央に向かって２体が交互に点滅しながら寄っていき、 最後に「もやもやど〜ん」で合体後の悪魔が現れる。 そして、「今後とも よろしく。」の決め台詞を忘れてはいけない。 ttp://amadela.web.fc2.com/megaten/image/gattairesult.png http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/558
559: 520 [sage] 2016/03/16(水) 22:45:44.31 ID:kzVfeYKW キャラクターの武装および装備品の売買システムを作るにあたっては、 いくつか検討すべきことがある。 (1)ゲームを通して登場するすべての装備品（武器、鎧、楯、兜）について、 名前、標準価格(非売品も含む)、性能値、その他特性データ を羅列したリストを準備する。 (2)各装備品について、ナカジマまたはユミコが装備できるものだけを 集めた集合を準備する。 この２つは、ゲーム全体で１つ定義すればよい。 (3)売買を行う「辺境の店」があるマップデータ内の地点設定項目に、 その店での取り扱い品目を設定する。 当然深淵に行くほど強い武器を販売するように配置する。 (4)「ナカジマ武器」「ナカジマ鎧」等のように、装備品の種別および 使用者ごとに、現在何を装備しているかを記録する変数を作る。 ＦＣ版の場合、ユミコは楯を装備しないので、２人で７項目である。 これらの変数は、必ずしも個人データに含める必要はないと思う。 http://mevius.5ch.net/test/read.cgi/gamedev/1233369246/559
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 20 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.013s