[過去ﾛｸﾞ] ゲーム作りませんか？ (822ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
634(2): 名前は開発中のものです。 [sage] 2012/07/26(木) 07:55:28.39 ID:dLnBOUQF(1/2) AAS
Tさんが考えられている部分は詳細部分の設計ですね
あくまで一例として聞き流してもらえればいいんですけど、
最初に考えるべきは具体的な動作ではなくて、共通部品の洗い出しと定義です。
一人で作るにしても、多人数で作るにしても処理が重なる部分はなるべく同じ部品を使わなければなりません
同じ内容なのに毎度作ったり、各々が勝手に作ったりなどで複数存在すると、プレイ上は同じ処理なのに同じ結果が得られない。
バグが発生してしまうなどの問題が発生します。
たとえばアイテムにしてもモンスターにしてもどんなパラメータが存在するのか、という基本的な定義が必要です。
このアイテムは装備なのか、回復アイテムなのかを識別するパラメータであったり
装備で装備のパラメータには何が必要か、他の分類のアイテムのパラメータが設定されていた場合どうするか。
こういった基本部分の枠組みをあらかじめ定義すれば、このパラメータを考えれば新しいアイテムが追加できるということが
他の方にもわかりますから、プログラムがわからなくても考えられるようになります。逆に基本の枠組みがないと
人によってバラバラになってしまうのでエラーの原因となってしまいます。
637: 名前は開発中のものです。 [sage] 2012/07/26(木) 22:18:16.85 ID:dLnBOUQF(2/2) AAS
>>636
その通りです。たとえば歩く、という動作ひとつとってもそんな処理は一度実装すればダンジョンごとに実装する必要なんてありません。
むしろ、個別に作ることによって、あるマップだけ壁をすり抜けて歩いてしまう、なんてバグも簡単に起こってしまいます。
そしてそうなった時、歩く動作が悪いのか、マップが悪いのか、あなた方は悩まなければなりません。
一方でこういった設計の部分は本当に人それぞれです。癖もあれば良し悪しもあります。
たとえばTさんが挙られた「使用可能なのはフィールドでのみか、戦闘中のみか」というパラメータひとつとっても
アイテムにパラメータとして持たせる人もいれば
シーン管理（今戦闘中か、町の中か、フィールドかといったゲーム状態）システムを作り、そこにシーンに合わせてアイテム等の許可不許可を管理する、
マップ情報を管理するシステムに持たせる人もいます。
アイテム以外にパラメータとして持たせる利点を挙げるとすれば、「回復魔法不可、アイテム使用不可」といった特殊なダンジョンやフィールドを制御しやすくなる点などがあげられます
このように、一見アイテムで持つべきに見えるパラメータ、にみえても実際は他で管理するほうが便利な場合が多々あります。
こういった必要なパラメータやシステムの洗い出し、切り分けを行うには全員が何を作るか、何をしたいかをはっきりさせると楽になります。
ですから、魔法やアイテムの細かいデータは後で考えても大丈夫ですがまずアイテムって何をするものか、アイテムをつかって何がしたい
どんなイベントを起こしたいといった表現したいことをゲーム全体でまとめるといいかもしれません。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.040s