[過去ログ] みんなでRPGゲームつくりませんか? (656レス)
1-
抽出解除 レス栞

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
154
(93): 2006/07/25(火)21:37 ID:52jkANFr(1) AAS
企画ページ拝見しました。

キャラクタの変数に「年齢」「引退時期」とありますが、
主人公の王子が引退時期になったらどうなるんでしょうか?

それから経験値が能力別に設定されていて、やりこみ要素が強そうなゲームに思いましたが、
このルールだと出来るだけ年齢が若い(引退時期まで長い)キャラクタを固定して使い続けるのが得策で、
パーティ編成や登場キャラクタが増える楽しみが少なさそうな気がします。

キャラ絵にも力が入っているみたいなので、
省2
162: 154 2006/07/27(木)21:04 ID:GqLJ9wrn(1) AAS
能力の最大成長を2倍程度に制限するというのは、良いと思います。
パーティ編成時、全体の強さよりも、バランスの重要性が増すのではないでしょうか。
「成長タイプ」は先天的に決めて生涯の成長(退化)曲線もある程度固定してしまい、
戦士向きか魔術師向きかはプレイヤーが判断して、関連スキルを獲得させることによって
個性が出るようなシステムなんてのはどうでしょう。

さて、質問の続きですが、食糧と薬草について整理させてください。企画書によると、
【食糧】
省15
164: 154 2006/07/28(金)06:03 ID:u3eoiK1I(1) AAS
企画ページの中断前画像によると食糧が特別重要なパラメータぽくなっていますが、
実際は一般アイテム扱いで、総重量および数量に制約があるということですね。
こんなまとめ方でどうでしょうか?

【食糧】通常アイテム、出発時に安価に購入可能
・探検時の休息コマンドで使用する(戦闘中は使用できない/魔法薬と差別化)
・HPと調子が若干回復する([料理]スキルでボーナスあり)
・対象は全員?
省14
166: 154 2006/07/29(土)18:10 ID:cSVdykfg(1) AAS
「食糧」というものに種類がなくて、使用場面が「休息」コマンドに限定されているのなら、
お金と同じで財産扱いにしても良いかもしれませんね。

ちょっと気になったのは、「休息」コマンド1回につき、パーティのメンバー数に関係なく
食糧1個消費というのは妙なので、単位は個数ではなくてアナログ的な表現(グラムとか)
を検討してみてはどうでしょうか。
大食いのキャラクタを設定してみたり、探検中、
食糧を通貨の代わりにするような応用もできると思います。
省4
172: 154 2006/07/31(月)21:24 ID:Ij0p3S/2(1) AAS
「レア度」大体理解できましたが、「ボーナス経験値」とか「スコア」とか新しい要素が出てきましたね。
そのあたり、また改めてお尋ねすることにしますが、
距離と能力地(と地形?)に対してランダムでアイテムを入手できる要素というのは、
アイテムに設定するよりは、イベントのパラメータテーブルに書いた方が調整しやすいと思います。

それから、パーティーを常に5人にするというアイデアは、確かに実装は合理的にできますが、
戦闘システムの作り方次第では、プレイ初心者にいきなり5人管理させるのは、
とっつきが悪くならないでしょうか。
省9
174: 154 2006/08/01(火)21:57 ID:1mUF57m1(1) AAS
5人なら進めて4人では厳しいバランスでは、パーティ編成がシビアになりませんか?
遊び人など戦闘向きではないキャラクタを連れて歩く余裕もあったほうが楽しいと思いましたが、
その辺も含めて調整次第でしょうね。

では次に、アイテムの持ち方についてですが、「重量」が設定されているようなので、
おそらくパーティ全体で運搬できる重量に制限(または重量超過でペナルティ)があると思います。
また、アイテムは、武器・盾・鎧・装飾品など装備もできますよね。
本当は、具体的なアイテムの一覧表のようなものがあると、いろいろな状況を想定しやすいんですけれど、
省10
177: 154 2006/08/02(水)21:51 ID:hGe1rI9V(1) AAS
ということは、定義したアイテムごとに「街に保管している数」「携行している数」を配列で記憶することと、
各プレイヤーについては、単純に武器・鎧・盾・装飾品の最大4品をアイテムIDで記憶するような
データ構造が良さそうです。
念のため確認しておきますが、資金は重量に含めませんよね?

では引き続き、探検システムについて、
(1)地形の発生方法について
 (a)毎回全く予想できないように乱数で生成
省10
180: 154 2006/08/05(土)09:59 ID:07Xwd+nG(1/2) AAS
距離の設定については、
「1歩進むと、免除スキルがない場合、HPが1(地形によってはそれ以上)消費される」
という設定があるため、オートマチックで分岐店まで進むというよりも、
1歩ごとに、不測の戦闘に備えて回復しておくか、もう少し我慢するか、というような判断を
プレイヤーに問うような形になると思っていました。

地形は、その判断基準として最も基本的な要素らしいですが、
その切り替え周期があまり長いと辛いかも、と思ったわけです。
省12
182: 154 2006/08/05(土)18:37 ID:07Xwd+nG(2/2) AAS
AA省
184: 154 2006/08/06(日)07:03 ID:JlpW1mIa(1/2) AAS
AA省
186: 154 2006/08/06(日)21:09 ID:JlpW1mIa(2/2) AAS
数百ですか…!
書くのも大変ならテストプレイも大変そうですね。

【発生条件】
【発生時のメッセージ】
【「はい」を選択した場合のメッセージと結果】
【「いいえ」を選択した場合のメッセージと結果】
  (選択肢は一つの例)
省7
188: 154 2006/08/07(月)05:54 ID:ZRwvPZzr(1) AAS
シナリオ補助にしろ、プログラマにしろ、拘束期間が読めない状態で
募集をかけるのは待ったほうが良いと思うのですが。

おそらく必要な作業で思いつくのは、33氏を監督として、
・システムプログラム作成
・ユーザインタフェース用画像【現在275氏が担当】
・イベント用シナリオ(主にメッセージ)作成
・イベント用画像作成
省10
190: 154 2006/08/09(水)05:02 ID:X/ZMJ8Ay(1) AAS
なんか33氏のライフワークになりそうな勢いみたいですが、
完成の見通しが立たない計画では、絵でもシナリオでも気軽に参加ということは
なかなか難しい気がしますね。
プログラマにしても、パラメータ調整してチェックという作業は、
程度によりますが、あまりクリエイティブでないと飽きる心配があります。

現在の企画について完成の妨げになっている要因は、
(1)ゲームの規模が分からない(開発作業量が見積もれない)
省8
193
(1): 154 2006/08/10(木)07:33 ID:TxqlPz+d(1/2) AAS
>>192 については、全くそのとおりなのですが、具体的にどのような方法を取れば
その問題を避けられるかは考えておく必要があります。
ゲーム本体以外に、パラメータ調整専用ツールが必要なら、その仕様も示さなければなりません。

>>190 の終わりに書いた「ゲーム性」というのは、ゲームの目的のことではなく、
例えば、アイテムを発見するのを楽しむゲームであるとすれば、
情報により存在は知っているけれども未入手のアイテムがほしいときに、
どのようなパーティ編成をしてどのようなルート選択や戦闘スタイルにするかなどを
省11
195: 154 2006/08/10(木)22:16 ID:TxqlPz+d(2/2) AAS
つまり、
・AとBが仲良しらしいという表現(会話・ステータス等)=断片的状況
・AとBを連れて行くと何かイベントが起こるかも=プレイヤーの推理
・(その組を連れて行くと戦闘等で不利益が生じるならその補完=戦略)
・予想通りのイベントが起きたor起きなかった=プレイヤーの経験
ということですよね?

ところが最後のイベントが起きる、起きないの部分が乱数に依存していたり、
省8
198: 154 2006/08/16(水)06:07 ID:zYtjGimH(1) AAS
戦闘と成長システムに関しては企画書では不明瞭な点が多すぎるので
現時点で具体的な数値を出されても良く分かりません。

例えば成長タイプ一致時の経験値800という値についても、
成長タイプなしの場合いくつなのか、あるいは、そもそも800という値は
ゲーム中のどのような行為何回程度相当なのか基準が見当たりません。
(スライム800匹だと、うんざりしそうな作業量ですし)

個別のパラメータごとに、どういう条件・タイミングでどの程度変動するか、とか、
省2
200: 154 2006/08/17(木)22:30 ID:qCH4tkcf(1) AAS
各能力値(筋力等6種)の「戦闘以外」の作用は、
基本的にイベントの発生または分岐条件ということになると思いますが、
可能性として、
(a)ave(筋力)=パーティの合計値(平均値)
(b)max(筋力)=パーティ内の最大値:誰か得意な人
(c)min(筋力)=パーティ内の最小値:足を引っ張る人
(d)any(筋力)=パーティ内のランダムな誰か:運のいい人、悪い人でも可
省11
202: 154 2006/08/18(金)22:24 ID:1uROWIqo(1) AAS
なんか、
「冒険者になることを志願したものの『自由に過ごせ』と言われ、
見つけてきたアイテムは主要パーティに召し上げられ、
一度も冒険に連れ出されず歳月を重ねて引退の時を迎える」
うだつの上がらない大学講師のような人生を想像したら悲しくなってきました。

それはそれとして、待機キャラが最大何人ぐらいに増えるかわかりませんので、
それぞれ個別に行動を設定・管理するのは、システム的には可能だと思いますが、
省8
204: 154 2006/08/20(日)08:05 ID:PNdQ4KZt(1/3) AAS
パーティ外人物の行動設定関係は、了解しました
ただ、うっかり放置しておくと数年後あまりに偏った成長をするというのも
ちょっと理不尽な気がしたもので。

そういうお話なら、例えば
・冬季は全員の行動について見直し&清算する季節にする(年単位で行動を指示)
・春・夏・秋はパーティメンバ入れ替えを制限する(5人中1人だけとか禁止とか)
というのはどうでしょうか。
省10
205: 154 2006/08/20(日)08:11 ID:PNdQ4KZt(2/3) AAS
あと、
・口調タイプ条件が設定されていないキャラクタ(無口、阿呆など)の
 台詞が設定されていません
・セイレーンイベントで、神学スキルなし、知力低の場合、
 8に進み、95%の確率で「霧の布」が手に入ります。
 こうなるとちょっと意味不明な展開みたいですが、仕様ですか?
 
208: 154 2006/08/20(日)18:12 ID:PNdQ4KZt(3/3) AAS
バリエーション100種類という目標の内訳について、
アイテム入手系イベントは、アイテムの設定種類数によって、
また被害系イベントは、主な被害はHPが中心で、回避条件の設定の仕方によって
自ずとバリエーションが限られてくるような気がします。

程度の大小もあるでしょうが、「何が起こってどれだけの被害が出たか」を
直感的にプレイヤーに知らせることが重要で、しかも頻繁に発生するのなら、
凝った情景描写を入れても読まれなくなるでしょうから、
省10
210: 154 2006/08/21(月)21:04 ID:z3T5lzNj(1) AAS
企画の内容を逐次更新していくことは、
プロジェクトの目指している方向を示す上でも、アクティビティを示す上でも、
重要だと思いますので、是非進めていただきたいですね。
更新履歴を残しておくのも有効だと思います。

しかしながら、これまでに出てきた内容を反映して詳細な企画を示したところで
新たに募集をかけなおしてみても、
前回の募集時点と比べてぱっと見で劇的な変化に乏しいような気がしますから、
省9
211
(1): 154 2006/08/23(水)05:38 ID:aF4sll0O(1) AAS
企画ページがずいぶんと加筆修正されて分かりやすくなっていますね。

せっかくですので、トップのイメージもそれに合わせてはどうかと思い、
サンプル画像を作ってみました。
画像リンク[jpg]:gamdev.org

背景素材は、>>140に紹介のあるサイト様のものを利用しています。

表示内容の仕様は未定ですが、大体こんなイメージになるのではないかと思っています。
募集も必要でしょうが、それ以前にこのプロジェクトに興味を持っていただける方が
省2
213: 154 2006/08/24(木)04:30 ID:djN6LInm(1/2) AAS
派遣の際は、持っていく荷物の選択と食糧の購入のための選択がありますよね。
そのためにはパーティの編成、つまり人員の選択と装備選択が終わっていないと、
所持可能な重量が計算できません。

ゲームの性質上、パーティ選択は詳細なパラメータをチェックしながら
慎重に人選すべきだと思いましたので、結構時間を掛けると思いますし、
途中、セーブもしたくなるのではないかと思います。
なので、パーティ編成と装備を先に済ませておき、
省9
215: 154 2006/08/24(木)21:45 ID:djN6LInm(2/2) AAS
開始直後のイメージ(主人公は王子・必須キャラということで)
画像リンク[jpg]:gamdev.org

パーティを編成しているイメージ(上の絵だと寂しいので)
画像リンク[jpg]:gamdev.org

ちょっと冒険中のイメージ(テスト画像)
画像リンク[jpg]:gamdev.org

ユーザインタフェースの設計は、凝りだすと時間ばかりかかるので、
省3
217: 154 2006/08/25(金)21:47 ID:JF4u7J5I(1) AAS
更新ご苦労様です。
多くの方に関心を持ってもらえるようになれば良いですね。

ちなみに現在もプログラマ募集中になっていますけれども、
とりあえずパーティ編成から探検・イベント処理までの実装の目途が立ちましたので、
こんな調子でよければ開発を続けますが、いかがでしょうか?

それから、主人公キャラなし、ということについては、
そうなりそうな気がしていましたので了解です。
省4
219: 154 2006/08/26(土)06:37 ID:AS8bySNV(1/3) AAS
企画ページ等に列挙されているデータを元に、
内部記憶とユーザインタフェースを構成したハリボテです。
C++で作成していますが、内部変数を「ルールに従って」操作するメソッド
を実装すれば、おそらくゲームらしくなると思います。

現状は、自前のテキスト処理プログラムで内部変数の初期値を書けることと、
選択やメッセージボックスなどの簡単な入力インタフェースを使って
内部変数の操作(一部)ができ、結果を画面に表示できることまでです。
省6
221: 154 2006/08/26(土)20:59 ID:AS8bySNV(2/3) AAS
実装上の都合で要望に添えない部分が出る可能性はありますが、
その都合でゲームデザインを束縛しては意味がありませんので、
遠慮なく要求仕様を出していただいて構いません。
その仕様に矛盾や問題点があれば、対案もだしながら指摘するようにします。

イベントの結果をゲーム中持続して保持してくことは可能ですが、
いかにしてプレイヤーにそのフラグが立っているかを示すことが問題になります。
よくあるのは、フラグが立っていたら会話が変化するという表現方法ですけれども、
省6
222: 154 2006/08/26(土)21:17 ID:AS8bySNV(3/3) AAS
それからビジュアルエフェクトの関連は専門ではないので、
あまり高度なことに対応できるかどうかわかりません。
現状寂しいスレッドですが、そういう知識のある方がアドバイザとして
付いていただければ、こちらとしては勉強になります。

また多少のことは出来るかもしれませんが、使っている描画エンジンの関係上、
プレイヤーへの要求スペックが過剰に上がってしまうかもしれませんので、
その辺は必要に応じて打ち合わせ、ということでお願いします。
223: 154 2006/08/27(日)12:26 ID:VuVl8f8x(1/2) AAS
なんか、>>220の答えになっていませんので、頭がすっきりしているときに補足しておきます。

イベントの開始・分岐条件にキャラクタの状態を使うことは可能です。状態とは、
・冒険者ストックに登録されているか否か
・パーティ内にいるか否か
・指定のスキルを持っているか否か(装飾品による追加スキルも含む)
・指定の装備品を装備している否か
・パラメータ値が参照値より大きい(小さい、等しい)か
省17
225: 154 2006/08/27(日)20:11 ID:VuVl8f8x(2/2) AAS
プレイ時間も大事ですが、プレイの目的の方が重要かもしれませんよ。
「最長距離を目指す」だけだったら、セーブ&リトライを繰り返し、
不利なイベント、戦闘結果を避けまくるという攻略法をすれば、
1シーズン何時間かけてでもプレイするかもしれません。
逆に、遠征が無理だと判断されたらすぐ帰還するでしょうから、
平均的な探検時間を想定しても、思惑通りにはならない気がします。

遠征することは、イベント発生条件の一つとして考え、
省4
227: 154 2006/08/28(月)22:39 ID:5/jkVsYQ(1) AAS
探検隊を出してレアな材料を持ち帰ってくるか、
奉仕活動に精を出すか、良く考えよう、というところですか。

冒険者ストックが少ない(10人以下)ぐらいなら、
派遣するしないでの差がはっきりすると思いますが、
分母が増えてくると、おそらく毎回派遣するのが得なんじゃないかという気もします。

発展度は面白いと思いますが、ますます経営シミュレーションぽくなっていきますね。

実装上必要なことは、
省8
229
(2): 154 2006/08/30(水)22:10 ID:fHHK+aKc(1) AAS
先日のイメージを作っているデモプログラムの準備が出来たので公開しようと思います。
そこでちょっとご相談なのですが、このプロジェクトをどの程度の人数がチェックしているか興味があるので、
ダウンロード数をチェックできる自サイト(外部リンク:www7a.biglobe.ne.jpに置きたいと思います。

プログラムの実行には、企画ページで公開されている顔グラフィック(chr1.bmp〜chr13.bmp)が
必要なのですが、コピーをアーカイブに含めて、こちらのサイトで公開してもよろしいでしょうか?

さもなくばそれらのファイルを企画ページからダウンロードしてもらうように、ドキュメント中に書いておきますが、
その場合、まとめてダウンロードできるような形にしていただけたらありがたいです。
省1
232: 154 2006/09/01(金)21:25 ID:NOsA4zWA(1) AAS
デモプログラムの公開を開始しました。
>>229 のHPから「ちょっと気になったゲーム」⇒「ミニRPG第一部」です。
まだゲームになっていませんが、とりあえず動くとこんな感じではないか、
というところです。

画像の形式は、WEBブラウザで見える形式なら必要に応じて変換しますので、何でも構いませんが、
縦長の画像なら、高さ128(2のベキ乗)で作ってもらえると効率が良いです。
今のままでも問題ありません。
省2
234: 154 2006/09/02(土)05:55 ID:yioBrm1m(1) AAS
インターフェースのデザインに関しては、仮組みですからどんな風にもできますが、
「中断前」のレイアウトをベースに、デバッグの都合優先になっています。

すぐにでも修正はできますが、ゲームシステムに変更が起きた場合、
また作り直しになる気がしますので、
まずルールが確定し、表示するパラメータの種類、単位、範囲、表現方法と、
操作別のレイアウトがまとまってから変更しようと思っています。

しかし分かっている部分については、
省4
236: 154 2006/09/03(日)20:10 ID:Sqp5XO5v(1/2) AAS
AA省
238: 154 2006/09/03(日)22:34 ID:Sqp5XO5v(2/2) AAS
敵5体が同時に行動ゲージ満タンになって、
敵が5回連続攻撃してくるのはさすがに厳しかろう、と思ったのですが、
良く考えてみたら、戦闘開始時の行動ゲージ初期値を分散させておけば済みますね。
エンカウント条件によって自分または敵の行動ゲージが規定されてましたし。

敵の種類は、地形に合わせて定義し、編成パターンをいろいろ作っておいて、
テストプレイ時に難易度で選別するという方法もあります。

いずれにしても、敵キャラクタの設定や画像のデザインで作業量が増えますね。
省2
242: 154 2006/09/05(火)22:37 ID:PDAF9ajh(1) AAS
とりあえず、魔法の種類と効果、使用可能条件と使用方法についての設定をお願いします。
魔法を使う敵を出すのかどうかによっては、プレイヤー側にも魔法耐性の設定(算定)が
必要になるかと思います。

敵のサイズは特に気にする必要はないと思います。
それよりも、絵描きさんにとって「横向き」って描きやすいんでしょうか?

プレイヤーパーティに合わせて、カード対戦ゲーム風に
抽象化した表現でも良いような気がしましたが、いかがでしょう?
244: 154 2006/09/06(水)22:47 ID:UUiwG0sC(1) AAS
魔法関係の確認事項です。よろしくお願いします。

(1)魔法関係のスキルを持っていなくても、杖さえ装備していれば、
 戦闘時、知力(だけ)をベースに攻撃するようになる?

(2)剣士であろうが、スキル系魔法を使うことが出来る?効果は一律?

(3)スキル系の魔法は戦闘開始時の1回だけ使用可能?
  先制なら確実に使用可能
  通常はランダムで2分の1
省7
250: 154 2006/09/07(木)20:57 ID:7kpEbGg+(1) AAS
丁寧にありがとうございます。では遠慮なく。

(1)■行動のところに「攻撃 対象を選択し攻撃する」にとあるのと、
  2:「敵の場合攻撃可能範囲からランダムで選択」とありますが、
  攻撃対象は指定できるのかできないのかどっち?

(2)(自分の)前衛と後衛が入れ替わった結果、全員後衛状態になるのは良いのか?

(3)近接武器しか持たないキャラが後衛に回されたら何もできない?
  (戦闘中、前衛・後衛の入れ替えを指示することはできるのか?)
省7
255: 154 2006/09/10(日)20:40 ID:1mWddEQI(1) AAS
ダメージ計算式と対象選択方式のテーブルを増やすだけのことなので、
武器による7種以外に、敵専用パターンを設定しても大して手間にならないと思います。

もしくは、攻撃パターンは現状+α程度にしておき、
武器の付帯スキルでバリエーションを増やすことも可能かと思います。
「炎」=杖属性の武器+「火炎攻撃スキル」+攻撃力の値

また、防具の付帯スキルによって、火に強い法衣とかも定義できると思います。
「水の羽衣」=鎧属性+「火炎防御スキル」+防御効果
省6
257: 154 2006/09/12(火)04:02 ID:A2xUyCKt(1) AAS
際限なく攻撃力が上がって、何も考えずに打撃だけで勝ててしまうRPGと違い、
割と狭い範囲で能力値が変動するようになっている本ゲームシステムでこそ、
攻撃・防御に属性が付いていると、戦略性が上がると思いますよ。
そこまで難解なものにしなくても良いかもしれませんが。

サブ武器ですが、
・全キャラデフォルトで護身用に短剣を保持していることにする
もしくは
省4
259: 154 2006/09/13(水)23:20 ID:9y3ntG9d(1) AAS
「敵のステータス」のところの「攻撃」と「T」は、
それぞれ表現方法と、攻撃力計算方法ということでよろしいですね?

ちなみに「巨人」の場合、攻撃力55、筋力54のメイスだから
攻撃力は55+54×2=163で、
しかも受ける人の防御は半分キャンセルされると、無茶苦茶痛そう…

ところで、行動ゲージ蓄積の際、装備品の重量は無視しますか?
261: 154 2006/09/14(木)06:14 ID:XhDdGZh+(1/2) AAS
数値が具体的だったのでこれを基礎資料にキャラクターの
標準的な能力を設定するのかと思いましたが、まだ暫定値、ということですね。

了解です。
とりあえず、戦闘部分についても、動くものを作ってみます。

それからリンクは一応、トップページにお願いします。
262
(1): 154 2006/09/14(木)22:36 ID:XhDdGZh+(2/2) AAS
追加の確認事項です。

武器アイテムのパラメータの項目に、「貫通力」「衝撃力」「必殺力」というのがありましたが、
@現在の戦闘システム案のどの辺に効いてくるのか?
A敵には、これらに相当するパラメータが設定されていないようですが、
 これらの支援があるのはプレイヤーサイドだけで良いのか?

ついでに、
B戦闘時の計算では随所でスキルの支援効果がありますが、敵は一切なしで良いのか?
省13
264: 154 2006/09/15(金)21:30 ID:Ex2Lph9a(1/3) AAS
「敵のステータス」のページで、preタグの中を、
・名前やパラメータ名が書いてある行の頭に半角#を書く
・時々混じっている全角スペースを半角スペースに置き換える
としてもらえると、非常にありがたいです。

耐・無・弱の中にある「魔」は、杖による単体および全体攻撃のことでしょうか?
もしそうなら、「杖全」と書いてもらえるほうが処理しやすいです。
また、「T」のところも、短剣なら「短」、全体なら「全」にしてください。
省8
266: 154 2006/09/15(金)22:40 ID:Ex2Lph9a(2/3) AAS
# はコメント行の判断のためですので、コボルトなど実際に定義している行には付けなくて良いです。

道具や装備品については、もうちょっと検討してみますので、待ってください。

メンバ募集については、良い方針だと思います。
スローペースで申し訳ないですが、今後ともシステム的な部分を頑健にしていけるよう、
お手伝いをさせてください。

そういえば、メンバ募集で思い出したのですが、そろそろ「ミニRPG」とは呼べない規模に
なってきましたから、何かプロジェクト名をつけてはいかがですか?
267: 154 2006/09/15(金)22:57 ID:Ex2Lph9a(3/3) AAS
敵の出現パターンについては、これももう少し検討してから確定したいですが、
今1行に並べたいのであれば、
 ゴブリン F 20; ゴブリン F 25; ゴブリン弓 R 40; ゴブリン弓 R 50; ゴブリン弓 R 50;
のような形式かな、とか考えています。

つまり、
 名前 設定文字 設定文字 … ;
の形式で、名前は敵ステータスの名前に対応し、
省11
271: 154 2006/09/16(土)20:00 ID:90d0VYDV(1/4) AAS
試験的に、攻撃力の計算式を>>262で提案したように
攻撃力= 装備武器の攻撃力 + 筋力×α + 技量×β + 知力×γ
剣(1,1,0)、 斧(0,2,0)、 メイス(2,0,0)
槍(1,1,0)、 短剣(1,1,0)、 弓(0,2,0)
杖(0,0,1) 魔術(0,0,1.5) 魔道(0,0,2)
としてみましたが、ちょっと強すぎるみたいなので、
係数や計算式を変えたほうが良さそうです。
省8
272: 154 2006/09/16(土)20:08 ID:90d0VYDV(2/4) AAS
間違えました。
ルトラ(短) 5+21+30=56
それでも黒ドラゴンより強いです。

攻撃力=武器の攻撃力×技β+筋α
とかで、どうでしょうね?(βは小さめに設定する)
273: 154 2006/09/16(土)21:06 ID:90d0VYDV(3/4) AAS
またしても確認事項です。

敵が戦闘開始時に使う魔法(および弓攻撃)は、
弓なら攻撃タイプを参考にして決められますが、
スキルが設定されていないので魔法の選択ができません。

敵に先制攻撃タイプ(なし・弓・鉄身・火炎・睡眠・死)を設定するか、
スキルを持たせるかしたほうが良いと思います。

それから、全体攻撃しかしない敵というのは、相当嫌ではないかと思いましたので、
省3
277: 154 2006/09/16(土)22:14 ID:90d0VYDV(4/4) AAS
今、コーディングしながら模索している最中なのですが、
・敵にもスキルを任意数設定できる(魔法スキルに限らず、剣聖でも根性でも可)
・敵の攻撃タイプは最大32個まで設定可能
・「剣剣剣剣全」とすると、4分の1の確率で全体攻撃するようにも設定できる
・攻撃の名前は、攻撃タイプに対応づけてコンマ区切りで書く(例えば「牙,牙,牙,牙,ブレス」)
というようなことができます。

ただし、以下のスキルについては、敵の場合は反映されません。
省6
280: 154 2006/09/17(日)07:06 ID:kiu9f7eN(1/3) AAS
名前を増やすぐらいで済めば簡単なのですが、
将来的に「それぞれにエフェクトを」とかなると、大変なことになりますので、
その辺も考慮しておいてください。

33氏のサイトは、これまでどおり、企画の「まとめサイト」として、
ルール設定などを充実することに重点を置くのが良いと思います。

もともとステフスレの発祥企画で、将来的に、メンバ募集のリベンジも視野に入れているなら、
2chを公開打ち合わせの場所として利用しているのが、参加の敷居が低くなると思います。
省7
281: 154 2006/09/17(日)21:23 ID:kiu9f7eN(2/3) AAS
個人データから、戦闘用ユニットデータのパラメータ変換の依存関係を図にしてみました。
画像リンク[png]:www7a.biglobe.ne.jp

一番上のCpersonが、公開中のテストプログラム内で定義している、個人データです。
各種スキルが関与して、戦闘用ユニットデータ(CbattleUnit)になります。

下半分は敵の場合です。
テーブル化された基礎データに、
パーティ編成時に設定できる個体補正パラメータと追加スキルを反映させて、
省6
284: 154 2006/09/17(日)23:19 ID:kiu9f7eN(3/3) AAS
装飾品の効果が、まだ具体的に設定されていなかったような気がしますが、
能力値上昇は6種類個別に±できるようにしておきます。。
(装備できる品であれば、剣でも盾でも、能力値に影響させることもできます)

補正計算は、「基礎能力値+年齢別補正値」を想定していましたが、
一次関数「基礎能力値×a[齢]+b[齢]」にしてもいいですよ(現在だとa=1)。

次は、戦闘開始時の条件を検討しているのですが、
『敵と味方の知力+運+乱数(+「勘」)を比較』とありますが、
省9
287: 154 2006/09/18(月)16:50 ID:mCpRJjY6(1/2) AAS
先制攻撃できるチームが5人の場合、
先制攻撃されるチームの評価値との比により、
 1.1〜1.2 ☆
 1.2〜1.3 ☆☆
 1.3〜1.4 ☆☆☆
 1.4〜1.5 ☆☆☆☆
 1.5〜   ☆☆☆☆☆
省4
289: 154 2006/09/18(月)19:50 ID:mCpRJjY6(2/2) AAS
AA省
291: 154 2006/09/19(火)21:31 ID:kE/U1OP+(1) AAS
多分、こんな感じじゃないかと思いますがいかがでしょうか。
画像リンク[png]:www7a.biglobe.ne.jp
※感知力の筆頭者加重付き平均は、感知力最大の人が2回加味された平均値
 乱数フィルタのパラメータηは、とりあえず 1.5

先制攻撃の順番は、計算で求めた感知力の順にも出来ますが、
指定どおり敏捷性の順位で良いですか?
294: 154 2006/09/21(木)21:54 ID:HRvrb5+S(1) AAS
先制攻撃判定における敵の弓・魔法攻撃の種類は、プレイヤーチームと同様、
保有スキルと攻撃タイプ(弓)から乱数で決定すればよいでしょうか?

敵のスキルは、現在の敵ステータス「T」の項目の後ろにコンマ区切りで
羅列すれば定義できます。

戦闘に関連するスキルは、
@戦闘前(プレイヤーのみ。敵の場合はあらかじめステータスに加味しておく)
 鉄壁、盾装、魔術、魔道、加護
省11
298: 154 2006/09/22(金)22:28 ID:8MmIzEtJ(1/2) AAS
ムードメーカーは、このスキル保有者がパーティに加入したら自動的に底上げするのではなくて、
何かイベントをきっかけに、パーティメンバの調子を改善する、ということですね。

先制攻撃判定に関わる主なパラメータは、大差の閾値に当たるη(=1.5)と、勘スキルによる補正量(=10)と、
敏捷性、運、知力に掛ける係数(1, 1, 0.5)です。
これを変えるとどのようにバランスに影響するかは、まだはっきりとは分かりませんが、
地形によって変更するというのは、良いかもしれません。
一応、地形データ中に変数を定義しておきます。
299: 154 2006/09/22(金)22:37 ID:8MmIzEtJ(2/2) AAS
ところで、道具の定義書式ですけれども、
# 名前 種別(,手) 維持,レア度 重量 性能値 能力補正(6種) 追加スキル 説明
のような順序でお願いします。

・名前 = 道具の表示名

・種別,手={備品,消耗品,剣,斧,メ,槍,短,弓,杖,鎧,盾,装}のいずれか
      武器に限り、{両,片}のいずれかを指定するが、斧槍弓はデフォルトで両手

・維持方式={ 廃棄(季節更新時自動消滅), 通常,  重要(廃棄禁止),  個人(装備解除禁止)  }
省12
301: 154 2006/09/23(土)07:07 ID:t6gufmnw(1/2) AAS
片手の斧は、「斧,片」と表記します。

重量の単位を表示する必要はないと思いますが、
あらゆる装備と道具の重量を合算して筋力と比較することになりますので、
設定する際の目安となる基準があったほうが良いと思います。
一食分の食糧の重量が1に対して、剣が100とか200という重量比では不自然ですし、
パーティ編成の際、バランスが取れません。

ソーティング用のカテゴリ分けが必要であれば、そのための項目を一つ追加しても良いですし、
省2
302: 154 2006/09/23(土)07:10 ID:t6gufmnw(2/2) AAS
維持方式は、「食糧を一般アイテム扱いしてシーズン持ち越し不可」に設定していた名残です。
ほとんどのアイテムは「通常」設定で良いと思いますが、
生もの(イベントで拾った果物とか「氷の剣」みたいなもの)は「廃棄」設定にしておくと、
システム側で自動的に処分します。

「重要」設定アイテムの管理をイベントシステム内部フラグに任せると、
総重量への反映が煩雑になるのでおすすめしません。

「個人」設定は、装備品を人物に固定して使いまわされないようにするための設定です。
省8
306: 154 2006/09/28(木)21:35 ID:Mf8F/2Pu(1) AAS
数字ばかり眺めていたら気持ち悪くなってきましたのでグラフにしてみました。
画像リンク[png]:gamdev.org

ちょこっとテストした印象としては、敵は全般的に敏捷性と運が高めっぽいので、
ほとんどの組み合わせで先制権を持っていかれるような気がしました。

ところで先制チームは、魔法などの攻撃をした上に行動ゲージ満タンで開始できるとなると、
ちょっと一方的な展開になってしまいそうなんですよね。
しかも、先制が取れるチームというのは基本的に敏捷性が高いわけで、
省3
308: 154 2006/09/29(金)21:11 ID:YVXf3doQ(1) AAS
失礼。実は風邪ひいてました。

ゲーム展開における敏捷性の支配割合について話題にしたかったのは、
一番戦況を左右しやすい攻撃順序をシステム的に揺さぶることで、
バランスを拮抗させる調整要素にしてはどうか、という提案です。

操作は単純だけど中身が複雑な戦闘システムにしているので、
単純な力比べや、機動力・体力勝負にならないように工夫して、
できるだけ勝負の行方に、あるいは逃亡する決断も含めて、
省1
310: 154 2006/10/04(水)21:43 ID:S4+yZVYF(1) AAS
進展少ないですけれど、生存報告しておきます

先日から、戦闘システムのチェック用プログラムを作っていて、
内部的なデータ構造はほぼ確定して、従来の(プレイヤー用の)キャラクタ定義から
戦闘用に共通化したユニット定義に変換する部分までのコーディングを終えています。

その際、いくつかパラメータ(変換に関わる係数)があるため、
敵の設定パラメータと合わせて調整するための専用ツール(模擬戦闘システム)
を作りかけています。
省14
312: 154 2006/10/06(金)06:11 ID:1VA4qC/U(1) AAS
戦闘中に使えるアイテムといえば、確定しているのは
・ガラスの剣 一定確率で敵を即死させる
・煙玉     戦闘を強制終了
・魔法薬
でしたよね?

敵はアイテムを使わない仕様だったと思いますので、
プレイヤー側だけアイテム利用を前提にした戦法がとれる
省12
315: 154 2006/10/14(土)21:13 ID:oT5I8qVV(1) AAS
今週滅茶苦茶忙しかったので連絡が途絶えてしまいました。すみません。

中間報告になりますが、現在のテストプログラムの状況です。
外部リンク[lzh]:www7a.biglobe.ne.jp

フロントエンドはしょぼいですが、設定されている計算式での算出結果の比較評価
ぐらいには使えるのではないかと思います。

現在のプレイヤーパーティ側の能力を平均値とするなら、全般的にもう少し敵は弱めで
設定したほうが良いかな、という気がします。
省4
317: 154 2006/10/17(火)21:52 ID:6a+NsWyr(1) AAS
企画ページによると、
・どちらの先制でもない場合(比率が1.0〜1.5のとき)、
 (比率-1)×2×100%の確率でテストして、
 パスした場合、上回る側(だけ)が先制攻撃
でしたけど、双方先制攻撃合戦にもできます。
どちらが良いでしょうね?

再試行のバグ、確認しました。次のリリースまでに直しておきます。
省2
321: 154 2006/11/04(土)21:08 ID:RBv9cuAq(1) AAS
すみません、今月中旬期限の本業が片付くまで手が回りません
システム的にはだいたい理解出来ていると思いますので
まとまった時間が確保できれば今月末ぐらいのタイミングで次のプレビュー版を
公開したいとは思っています

当初にくらべて企画内容は随分クリアになりましたし
まだちょっと大規模すぎる気がしていますが、ある程度作業量が見えてきているようなので
必要なスタッフ募集については、随時、進めていただいて良いと思いますよ
326: 154 2006/11/22(水)21:21 ID:RG10qaot(1) AAS
そろそろ再開しましょうか。

戦闘中のキャラクタの表示方法についての案ですが、
プレイヤー側は、
 画像リンク[JPG]:www7a.biglobe.ne.jp
な感じでどうでしょう?

バーグラフの上側がHPで、
・125までは黒地に赤色
省11
329: 154 2006/11/24(金)21:40 ID:T69TwFy0(1/2) AAS
武器(攻撃タイプ)の区別はエフェクトを変える表現方法が良いと思います。
攻撃元から攻撃対象への方向も、エフェクトで表現するつもりです。

各個体の識別と、前衛、後衛が視覚的に区別できるようにするのであれば、
 画像リンク[png]:www7a.biglobe.ne.jp
のような画面構成にする方法でも、とりあえずなんとかなりそうなので、
データが揃ってくるまではこのスタイルでプロトタイプを作ろうと思います。

>>327 の例にあるように、フィールドの平面的な広がり感を演出しようとすると、
省6
330
(1): 154 2006/11/24(金)22:02 ID:T69TwFy0(2/2) AAS
試しに、募集をかけてみましょうか?

【募集内容】RPG戦闘画面用キャラクタ静止画像
外部リンク[html]:www.eonet.ne.jp で公開されている顔画像を参考に、
全身像(左後方斜め上から見たアングル)を表現したもの
【サンプル】画像リンク[png]:www7a.biglobe.ne.jp
【 色 】RGBA
【抜き色】αチャネルで指定/RGBは(0,0,0)が望ましい
省6
335: 154 2006/11/27(月)21:14 ID:c3ynmT1b(1) AAS
>>332
いい感じですよね。

たぶん攻撃タイプ別性別画像にするよりも、個人別の画像を用意するほうが、
顔グラフィックと対応しやすいと思うので、全員分揃うことを願います。

色指定がないと、残りのキャラクタを設定するのが難しいと思いますが、
そのあたり、どういう段取りにするか考えないといけませんね。

275氏が復帰されると良いのですが、そうでなければ先に全身画像で色を
省7
338: 154 2006/11/30(木)06:29 ID:wTjJ3FTy(1/2) AAS
では、真横、前ナナメの画像も同様に(128x128程度,png)で募集してみましょう。
残りの顔グラフィックについても、色指定があったほうが描き易いでしょうね。

いまのところ全身画像が戦闘時にしか使わない予定で、
単に前衛・後衛の位置関係と個体識別が出来さえすればよいですから、
システム上は十分上等だと思います。

個体の装備品、例えば盾を持っているか否かの違いを
この画像で確認する必要は、システム上ありません。
省4
339: 154 2006/11/30(木)06:37 ID:wTjJ3FTy(2/2) AAS
それからついでに、敵グラフィックスについても同様な方法で募集してみます。

【募集内容】RPG戦闘画面用敵キャラクタ静止画像
外部リンク[html]:www.eonet.ne.jpで公開されている敵の名前を参考に、
全身像(右前方斜め上から見たアングル、または真横)を表現したもの
 ( >>330 で提示したサンプル画像に向かい合うアングルです )
【 色 】RGBA
【抜き色】αチャネルで指定/RGBは(0,0,0)が望ましい
省10
346: 154 2006/12/03(日)21:37 ID:jXI55BCG(3/3) AAS
絵のクオリティについては異存ありません。ぜひ、引き続きお願いしたいです。

ところで真横にすると前衛・後衛の違いを表現するのに水平位置を変えますよね。
それとパーティの構成員数は縦に並べることになります。

大きなキャラクタが居れば、レイアウトの都合上、重ね合わせる必要がありますから、
例えば大きな前衛キャラクタ同士が、縦方向にずれて首が積み重なっているような
絵になってしまうと、ちょっと格好悪いかな、と懸念しています。

それに比べると斜めアングルの方が平面的にレイアウトする余地がある分、
省3
350: 154 2006/12/06(水)21:53 ID:HdA6ql0+(1) AAS
ついでなので、必要なものをいろいろ募集してみます。

(1)プレイヤーキャラクタの横向き画像
 特に、戦闘テストに使っているアストン、ダリア、ルトラ、クレア、ワンジの5名を急募します。
 未着色のダリア、ルトラ、クレアの着色顔画像もあると良いです。

(2)攻撃表現用の補助画像
 剣、斧、メイス、短剣、槍、矢 の画像(右向き、128x64程度、PNG)
 中央水平線に軸が通るようにしてください。
省5
354: 154 2006/12/07(木)21:53 ID:dT0/Dh9U(1) AAS
戦闘画面の構成ですが、一応、パーティの隊列(前後と人数)が一覧できるように、
画像リンク[jpg]:www7a.biglobe.ne.jp
のようなレイアウト案にしてみました。

でもこの画面構成だと、いまいち迫力に欠けるような気がするので、
行動選択時には、カメラを寄せてみたところ、こんな感じになります。
画像リンク[jpg]:www7a.biglobe.ne.jp

で、戦闘時のエフェクトですが、攻撃者がターゲットの前に移動し、
省4
358: 154 2006/12/09(土)08:38 ID:tD/oi58m(1) AAS
画像のサイズは適当で良いですが、
128x128など、2のベキ乗サイズを使うのが、実装上、最も効率的です。

画面上でのサイズやベースラインの高さは、
画像ごとに微調整できますので、作画時に無理にそろえる必要はありません。

ただし、ビルボード処理の都合上、縦軸の中心だけは真ん中に通してください。

また、影は別の方法で処理しますので特に意図しない限り、描かなくて結構です。
362: 154 2006/12/13(水)21:24 ID:Sir3MeFq(1) AAS
開発途中ですが動作テスト用に公開します。
外部リンク[lzh]:www7a.biglobe.ne.jp

最近のPCなら問題ないと思うのですが、
戦闘システムの描画処理が重すぎるようなら、表現方法を再考しますので、
なるべく多くの方からの動作報告をお待ちしています。
1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.046s