みんなでＲＰＧゲームつくりませんか？

**琥珀の月** · 04/02/18 21:16

本気でゲーム作ってみたいと思う人集まれ　（・∀・∩）

３３ · 2006/08/01(火) 23:35:56

街にはアイテムを無制限に保管できて問題ないでしょう
携行アイテムはまず各PTメンバーの筋力（＋α）から
それぞれの装備重量を引いて、残りの値を全員分足した
数値まで全体として個数関係なくアイテムを持てる
ということになります

例　
キャラ　　筋力　　装備　　差し引き
　A　　　　　１５　　　　５　　　１０
　Ｂ　　　　　１０　　　　４　　　　６
　Ｃ　　　　　　６　　　　３　　　　３
　Ｄ　　　　　１２　　　　２　　　１０
　Ｅ　　　　　１０　　　　０　　　１０
　　計　　　　　　　　　　　　　　３９

所持可能重量　３９
赤い魔法薬（重量３）×３
ガラスの剣（重量５）×１
魔法の角笛（重量２）×１
食料　２３食分

重量を超えるアイテムは持てないということでいいでしょう
探検中に重量をオーバーするような宝を見つけた場合
何かアイテムか食料を捨てないと入手できないようにして。
消費アイテムはややこしいので一回で消えることで良いでしょう
　

**154** · 2006/08/02(水) 21:51:19

ということは、定義したアイテムごとに「街に保管している数」「携行している数」を配列で記憶することと、
各プレイヤーについては、単純に武器・鎧・盾・装飾品の最大4品をアイテムIDで記憶するような
データ構造が良さそうです。
念のため確認しておきますが、資金は重量に含めませんよね？

では引き続き、探検システムについて、
(1)地形の発生方法について
　(a)毎回全く予想できないように乱数で生成
　(b)毎回一定の一本道だが、コースを選択できる
　(c)最初は（例えば）草原で始まり、既定の距離で分岐を選択できる
　(d)季節によって発生内容をコントロールするか

(2)探検の終了方法について
　(a)いつでも帰還可能 or 洞窟など帰還不可能な場所を設定する
　(b)エンドレス or 一定距離でイベントが発生し打ち切られる

(3)地形の変化タイミングについて
パーティメンバのＨＰとのバランスもありますが、
３０歩同じ地形が続くというのはちょっと長いように思いますが、
何かバリエーションの持たせ方をお考えでしょうか？

３３ · 2006/08/02(水) 23:16:47

地形の順番はランダムで、ただし序盤は草原や森が多く
距離が伸びるにつれて洞窟や砂漠、雪原などの上級地形が
多くなる、といった補正は有

探索の終了は[帰還]コマンドでいつでも帰還できるようにして
稀にイベントで強制的に帰されることも有

同一の地形は３０～１００歩（ランダム）くらいの間続くように
しようと思ったんですが長いですかね？まぁ実際プレイしてみての
感覚が解らないんで後々調整ということになりますが
一定距離進んだ所で選択肢が出てどちらの地形に進むか決められる
選択肢は２個くらいでランダム
後何歩進んだら地形が変わるかはわからない方が面白そうですね

所持金に重量のあるゲームって昔ありましたね
ファンタジーかハイドライドかなんかで・・・
このゲームでは当然無しで

>>175
ツクールは使ったことありませんがなんとなくこのゲームには合わないような・・・
まぁまだシステムも確定してないしシナリオもこれからなんで
のんびり待ちますよ

３３ · 2006/08/05(土) 00:12:42

イベント案などをちょっとずつ作ってます

**154** · 2006/08/05(土) 09:59:04

距離の設定については、
「１歩進むと、免除スキルがない場合、ＨＰが１（地形によってはそれ以上）消費される」
という設定があるため、オートマチックで分岐店まで進むというよりも、
１歩ごとに、不測の戦闘に備えて回復しておくか、もう少し我慢するか、というような判断を
プレイヤーに問うような形になると思っていました。

地形は、その判断基準として最も基本的な要素らしいですが、
その切り替え周期があまり長いと辛いかも、と思ったわけです。
せいぜいサイコロの１～６歩ぐらいごとに分岐点があっても良いかな、
と考えていますが、イメージ間違ってますでしょうか？

ところでプログラマに関しては、とりあえず見栄えを気にせず、ゲームのルールと
バランスをチェックするぐらいのプロトタイプなら私にも作れると思います。
しかしながら、他のプロジェクトなどで頓挫しているものを見ていて思うのは、
企画と実装の間にある「仕様設計」が固まらない段階でプログラムを作り始めても、
仕様を企画かプログラマのどちらが決めるかによって、企画意図と違う仕上がりになるか、
仕様変更が重なって開発が長引き、スタッフが自然に飽きてしまうような傾向が見られます。

このＲＰＧに関して言えば、企画ページにある程度項目は挙がっていますけれども
詳細な仕様設計については現状で３３氏の頭の中にしかありませんから、
もう少し構想をはっきりさせて、プログラマが具体的に工数見積もりできるように
準備しておいたほうが良いのでは、と思いましてしつこく質問している次第です。

**名前は開発中のものです。** · 2006/08/05(土) 17:36:07

そうですね、プログラマさんに完成形が見えてないと
どうしようもないですからね
実際作り始める前に十分に話し合っておくのは必要ですな

距離に関しては１～５行の認識で間違いないです
ただあんまりコロコロ地形が変わるのはどうかと思いますね
イベントの頻度にもよりますが、同一地形がある程度続いた方が
ゲーム性は良くなるんじゃないかな
今どういう地形に居る、この地形が何処まで続くか解らない
と考えながら進んでいくのが面白いと思うし
分岐点に来た時に、楽な森を選ぶか厳しいけれどイベントやアイテム
のために敢えて砂漠を選ぶか、というようなことで悩むのも
面白いと思います
雪原に強いキャラを入れてきて正解だったなー、とか

**154** · 2006/08/05(土) 18:37:09

例えば、「草原」が続く途中に、
小川があったり、木陰があったりなどのイベントを用意して、
それが物によっては数ステップ前から予見できるような仕組みにしておくと、
「とりあえず川を越えておこう」とか、「あの木陰で休もう」など、
ある程度目標を持った行動計画を立てられるようにするシステムはどうでしょうか？、
（勿論、敵襲などで予定が変わることもありで）

これなら、３０～１００ステップぐらいで地形が変化するのでも、
五里霧中の世界をさまよう不安が安らぐと思います。

ちなみに、イベント案を検討中とのことですが、
そちらの仕様も検討しておきたく思っております。
単発の、「食べ物を見つけた、食べる？食べない？」程度なら簡単ですが、長そうなもの
をお考えでしたら、現在考えている内部変数の保持方法、
更新タイミング等と付き合わせしてみたいので、
ぜひとも、まとめサイトなどで公開してほしいです。
（例：あるキャラクタが探検隊に志望した。
　　　その目的は○○を見つけることらしいが、
　　　そのためには△△のスキルを持ったパートナーの協力が必要で、
　　　○○を見つけた後、それを使った真の目的が明らかに…　）

また、折角スレで意見を出しているわけですから、
いろいろな方からのアイデアも検討していきたいと思っています。

３３ · 2006/08/05(土) 21:30:14

一応ＨＰに「イベント」の項をアップしておきましたが
あれだけじゃ解りづらいでしょうなタブン・・

ところで２７５氏は今作業してくれているんでしょうが
長いことレスが無いと生存してるか不安になりますな
作業は急ぐ必要ないけど時々は生存報告くれると
安心します

**154** · 2006/08/06(日) 07:03:59

とりあえず探検イベントですね。
「進む」コマンドを実行したときの処理手順を考えてみました。

(1)発生させるイベントを決める
　　優先順位の高いイベントから順に、条件式を評価
　　　　高：固定イベント
　　　　中：高確率設定の探検イベント
　　　　低：中、低確率設定の探検イベント
　　条件が最初に成立したもの１件について、(2)以下を実行する
　　条件にかなうものがなければ、その回はイベントなし
　　※１歩移動したときのイベントは最大１個と仮定しています
(2)ユーザに対し、イベントが発生したことをテキスト等で通知する
　　必要に応じて選択肢を示し、入力を促す
(3)内部変数および入力結果を含む条件式を評価し、
　　必要に応じて(2)のユーザインタフェース処理または、
　　内部変数に対する演算操作を行う
　　※演算操作＝対象変数と操作方法（加減算、追加、除去、更新）と程度パラメータのセット
　　　　程度パラメータの決定は「影響」で示されたスキル・フラグ類の要素を含む数式を利用
(4)ゲーム全体を通して１回(もしくは限定回数)しか発生しないイベントを実現するため、
　　(1)で評価されるべきフラグを更新しておく

開発手順によりますが、最終的に調整しながら追加するようなことがあるなら、
真っ当なスクリプト処理系か状態遷移図のグラフエディタを用意して、
イベント定義をプログラムの外部に持たなければだめですね。

３３ · 2006/08/06(日) 16:15:25

イベントはこのゲームの肝ですからね
イベントの数が少ないとゲームが単調になってしまうし
単純なものでも良いので数百はほしいところですな
後から随時追加できるようなプログラムが望ましいです
プログラム的にはイベントが一番の難関なのかも

**154** · 2006/08/06(日) 21:09:46

数百ですか…！
書くのも大変ならテストプレイも大変そうですね。

【発生条件】
【発生時のメッセージ】
【「はい」を選択した場合のメッセージと結果】
【「いいえ」を選択した場合のメッセージと結果】
　　（選択肢は一つの例）

というようなテンプレートに押し込められるものなら、
数が増えてもプログラミングの難易度は変わらないと思いますが、
このパターンばかりというわけでは無いでしょうから、
拡張性のある定義方法が必要になってくると思います。

そういう実装は可能だと思いますが、
データを作利続けるモチベーションが保てるかどうかのほうが
問題になりそうな気がします。

３３ · 2006/08/06(日) 22:11:27

俺一人だとかなり時間がかかるでしょうね
ゲームが形になってきたらモチベーションは続きそうですが
ネタが尽きるという心配もありますし・・・
シナリオ補助の募集に誰か来てくれれば自分はメインシナリオとキャラ
関連、ゲームバランス、システムに専念できるんですけどね
プログラマーが確定して動き出したらまた本スレで
募集をかけてみましょうかね

**154** · 2006/08/07(月) 05:54:03

シナリオ補助にしろ、プログラマにしろ、拘束期間が読めない状態で
募集をかけるのは待ったほうが良いと思うのですが。

おそらく必要な作業で思いつくのは、３３氏を監督として、
・システムプログラム作成
・ユーザインタフェース用画像【現在２７５氏が担当】
・イベント用シナリオ（主にメッセージ）作成
・イベント用画像作成
・（完成が見えた段階で、イベント用音楽・効果音・画像エフェクト）
・戦闘用敵キャラクタ設定
・戦闘用敵キャラクタ画像
・（完成が見えた段階で、戦闘用音楽・効果音・画像エフェクト）
のような感じだと思いますが、それぞれサンプル程度のものを数件作成し、
見込んでいる必要数（数百件というのが現実的かということも検討が必要です）
を示し、受け入れ態勢を整えてから募集をかけるのが、無難な気がします。

プログラマ待ちで開発が滞っているとお考えなら、
見栄えを気にせず、とりあえずシステムの雰囲気が分かる程度のものでよければ、
私が作ってみましょうか？

３３ · 2006/08/07(月) 22:10:47

絵と文章に関しては量は多ければ多いほど良いわけで
作業もクリエイティブな仕事だからどれだけやれば
どれだけ出来るって見通しの立つものではないと思います
でもこれは手伝ってもらうにしろ最低私一人居れば
なんとか続けられるものですから気軽に参加してくれれば
いいと思います

でもプログラマーさんだけはきっちり決まらないとどうしようもないですね
まず仕様を把握してもらうのに時間がかかるし、組む間も
話し合いながら進めていかないといけないですからね
途中で離脱されると他の人に後を引き継ぐって訳にもいかないし

理想としては土台のプログラムを集中して仕上げてしまってから
あとはデータをどんどん放り込んで数字を調整していけばいい
という状態まで早めに持っていってから、じっくり肉付けをして
いくっていう形ですね
その後ももちろんプログラマーさんは残ってもらわないと困りますけど
作業は楽になるし大丈夫でしょう

**154** · 2006/08/09(水) 05:02:56

なんか３３氏のライフワークになりそうな勢いみたいですが、
完成の見通しが立たない計画では、絵でもシナリオでも気軽に参加ということは
なかなか難しい気がしますね。
プログラマにしても、パラメータ調整してチェックという作業は、
程度によりますが、あまりクリエイティブでないと飽きる心配があります。

現在の企画について完成の妨げになっている要因は、
(1)ゲームの規模が分からない（開発作業量が見積もれない）
(2)プレイヤーにとってのゲーム性（何を判断材料にして何を目指すか）がはっきりしない
(3)個別の設定要素（ステータスパラメータやスキル定義等）の意味、相互作用が数式化されていない
などではないかと、私は考えています。

現在のプロトタイプがない状況ですべての設定を正確に定義しようとするのは無理ですが、
とりあえず紙と鉛筆とサイコロと電卓を使ってゲーム性を確認する程度の作業はできると思います。
少なくとも1年分（冒険3回訓練１回）の模擬プレイをしてみて、
各項目の意味づけや、必要なイベント数や発生タイミング、パーティ編成と戦闘のゲーム性などに
関わる数値データを割り出してみてはどうでしょうか？

３３ · 2006/08/09(水) 21:47:45

よく解りませんがゲーム性については特に心配してませんよ
ゲーム自体は非常に単純で、大量のイベント、アイテム、人物
等を発見し味わうのが主な楽しみのゲームですからね
難易度とかゲームバランスに関しては単なる数値のやり取りでは
判断できません。それらはプレイヤーがどう感じるかを基準にして
調整しないといけませんからね
絵を見たり文章を読んだりマウスをクリックしたりという中で
どう感じるかということが問題になるわけですから

現在土台のプログラムを作るのに必要なことで残っているのは
年齢とＨＰの関係の数式と戦闘の数式、このへんです
これが決まればプログラム作っちゃって良いと思いますが
シナリオや絵はまだまだ手付かずですからね
それらはプログラム無くても進められる部分なので
今別にプログラマさんが居ないから製作が進まないというような
状況ではないですよ
ただ私一人でやってたら一日に顔１枚とかイベント一個とかしかできなかったり
するし完成は１年後とかになっちゃうでしょうね
まぁ２７５氏もどうやらいなくなっちゃったようだし、また一人でしばらく
進めるのもいいかと思いますけど、募集かけてワイワイやったら
勢いつくだろうしそれもいいかなと思います

３３ · 2006/08/09(水) 21:51:21

あとプログラム作るにしても数値をチョコチョコいじるのに
一々プログラマさんの手を借りないといけないのは非現実的ですよね
数値やテキストは簡単に変えられるようにしてもらわないと
イベントをチェックするのにそこまでゲームを進めないといけないとか
やってられませんからね

**154** · 2006/08/10(木) 07:33:52

>>192 については、全くそのとおりなのですが、具体的にどのような方法を取れば
その問題を避けられるかは考えておく必要があります。
ゲーム本体以外に、パラメータ調整専用ツールが必要なら、その仕様も示さなければなりません。

>>１９０の終わりに書いた「ゲーム性」というのは、ゲームの目的のことではなく、
例えば、アイテムを発見するのを楽しむゲームであるとすれば、
情報により存在は知っているけれども未入手のアイテムがほしいときに、
どのようなパーティ編成をしてどのようなルート選択や戦闘スタイルにするかなどを
プレイヤーが考え、実行する部分のことを言います。

単純に距離を稼ぐだけなら、ある程度の防具を揃え、武器を持たずにその重量分を
食糧と回復アイテムに回し、戦闘は逃げまくる、という戦略も、プレイヤーとしては
一つの選択肢になるでしょう。
その戦略がうまくいく、いかないという味付けがバランス調整の役割になります。

もし「大量のイベント」が単に乱数だけで発生するだけだったらゲームになりませんから、
ちゃんと脈絡のあるストーリー展開、すなわち、イントロダクション～断片的情報提供を経て、
プレイヤーが推理し戦略を立て実行、そして目的達成となるシナリオが必要だと思うのです。

移動や戦闘システムの単純さはセールスポイントにして良いと思いますが、
肝心のイベントやアイテム、人物との出会いまで単純にしてしまったら、
ゲームというより、単なるブラウザじゃないですか？

３３ · 2006/08/10(木) 18:25:37

＞ちゃんと脈絡のあるストーリー展開、すなわち、イントロダクション～断片的情報提供を経て、
＞プレイヤーが推理し戦略を立て実行、そして目的達成となるシナリオ

こういうものはこのゲームにはありませんよ
プレイヤーが推理するとしたらそれは過去の自分のプレイの経験からですね
プレイヤーのために道を作っておくようなゲームではありません
アイテムについて事前に情報とかそんなのも無いです
イベントは条件と乱数ですね
大航海時代とか、太閤立志伝のような感じというか・・
人物も三国志でいう武将のようなもの（それよりはずっとしゃべりますが）です
ＡとＢは仲が良いらしいから（そういう情報は街での会話で）一緒に連れて行ったら
なんかイベントが起こるんじゃないか？というふうに
プレイヤーが試行錯誤するゲームです
９～１２行目は大事なことですね
ゲームが一通り出来上がってからが結構かかりそうな気がします

**154** · 2006/08/10(木) 22:16:44

つまり、
・AとBが仲良しらしいという表現（会話・ステータス等）＝断片的状況
・AとBを連れて行くと何かイベントが起こるかも＝プレイヤーの推理
・（その組を連れて行くと戦闘等で不利益が生じるならその補完＝戦略）
・予想通りのイベントが起きたor起きなかった＝プレイヤーの経験
ということですよね？

ところが最後のイベントが起きる、起きないの部分が乱数に依存していたり、
いろいろな条件が重なりすぎていて、何が原因でイベントが起こったかという
因果関係がプレイヤーに理解できない（つまり脈絡が無い）と、
推理も経験もできないんじゃないかと思います。

探検パートや戦闘部分の戦略性・ゲーム性が豊富で、
イベントはおまけみたいな位置づけならそれぐらいでもちょうど良いかもしれませんが、
このゲームのコンセプトはむしろ逆だと思っていました。
それならそれで、イベントや人物を記号的に扱えるので、
もっとシンプルな実装方法もありそうです。

３３ · 2006/08/10(木) 22:46:20

あー条件が複合だと何が原因でイベントが起きたか
解りにくいというのは考えられますね
イベントのテキストの中にそれとなくヒントを入れておく
のもいいかもしれません

プレイヤーの仕事が複雑になるほどゲーム性が上がる
というものでもないと思うんですよ
単純な中に数値的なシビアさを適度に感じさせる
加えて豊富なイベントやアイテム、人物などのテキストデータ
によって飽きさせない、やり込み心をくすぐる
キャラや世界に魅力があれば尚良し
こういうのが目標ですね

ここのところ高校野球の録画を観るのに時間を使って
あんまり作業が進んでなかったりして・・・
今日はキャラ絵２つほど描きましたが

３３ · 2006/08/12(土) 00:27:53

成長関係の設定を一応アップしてみました
数値は大体なので要調整でしょう

**154** · 2006/08/16(水) 06:07:43

戦闘と成長システムに関しては企画書では不明瞭な点が多すぎるので
現時点で具体的な数値を出されても良く分かりません。

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

個別のパラメータごとに、どういう条件・タイミングでどの程度変動するか、とか、
どういうときに参照され、どういう意味・影響力を持つ値なのかということなど、
後々調整するにしても、もう少し丁寧に書き出してあると良いと思います。

**名前は開発中のものです。** · 2006/08/17(木) 17:50:56

一応説明を入れてみましたがどうですかね

経験値は最初１００で上がるようにしようかと思ったんですが
イベントごとの獲得経験値に少しずつ差をつけるためには
数値を大きくしないと難しいので一桁増やしました

１季の訓練で経験値が２５０上がると一年で能力が１上がります
訓練のメリットは伸ばしたい能力を上げられること
探検では思い通りの能力を上げられなく、各能力の経験値を
少しずつ稼ぐことになるが合計値では訓練よりも多くなる
というバランスにしようと思ってます

**154** · 2006/08/17(木) 22:30:33

各能力値（筋力等６種）の「戦闘以外」の作用は、
基本的にイベントの発生または分岐条件ということになると思いますが、
可能性として、
(a)ave(筋力)=パーティの合計値（平均値）
(b)max(筋力)=パーティ内の最大値：誰か得意な人
(c)min(筋力)=パーティ内の最小値：足を引っ張る人
(d)any(筋力)=パーティ内のランダムな誰か：運のいい人、悪い人でも可
を条件式の評価値にすることが出来そうです。
　　ex. if max(技量)>50 then 宝箱内のアイテムを入手

もちろん他にもイベント発生条件の変数はありますが、それらを組み合わせ、
またそのイベント発生時のテキスト表現や結果について、
完結した典型的な具体例を２，３示していただくと、よりイメージがはっきりしてきます。
きっと、イベントごとに挿絵が一枚くらいずつあると良いんでしょうけれど、
募集するにしても数次第でしょう。

それから勘違いしているといけませんので念のため確認しますが、
「訓練」というのは、
(1)毎年「冬」だけではなかったですか？
(2)パーティ以外の冒険者も訓練するのでしょうか？

３３ · 2006/08/17(木) 22:55:04

訓練は探険に出なかった人が留守の間にします
冬は探検隊を出せないので全員が訓練します
各自に[行動]というデータを用意して
「筋力訓練」「敏捷性訓練」・・・と設定をいつでも
変えられるようにしておきます
「自由行動」も用意して能力が上がらない替わりに
稀に何か特典（アイテムを取ってくるとか、スキルを覚えるとか）
があるというのもいいかもしれません

イベントは挿絵欲しいですね・・・
でも全部に一枚ずつだと大量になりそうなので
重要なイベントや発生回数の多いのを優先になるでしょう

**154** · 2006/08/18(金) 22:24:48

なんか、
「冒険者になることを志願したものの『自由に過ごせ』と言われ、
見つけてきたアイテムは主要パーティに召し上げられ、
一度も冒険に連れ出されず歳月を重ねて引退の時を迎える」
うだつの上がらない大学講師のような人生を想像したら悲しくなってきました。

それはそれとして、待機キャラが最大何人ぐらいに増えるかわかりませんので、
それぞれ個別に行動を設定・管理するのは、システム的には可能だと思いますが、
プレイヤーの負担が大きくなるような気がします。

パーティに入っていないキャラクタの行動まで縛るのは心情的にちょっと抵抗感があって、
それぞれ勝手に訓練するようにするか、あるいは全員に対して一括命令できるけれども、
従うか従わないかはプレイヤーとの友好度に任せるというのはどうでしょう。

それと、通年で訓練できるのであれば、別に冬を休みにしなくても良い気がします。
遠征は難しいけれども冬しか発生しないイベント、冬季限定アイテム、
冬しか参加しない冒険者とかを登場させられるようになると思ったのですが、
それでも冬に探検させない理由があるのでしょうか？

３３ · 2006/08/19(土) 23:34:17

一人一人に行動を設定するのはプレイヤー的には
特に問題ないと思いますよ
他の色々なゲームと比べてみてもそのくらいは考えること
があっていいくらいだと思います
毎季節設定しなおす必要は無いですしね
時々パラメータをチェックして変更するだけでいいですから

訓練をサボるとか勝手に他の行動をするとか
そういう人間臭さはあると面白そうですね

冬は春～秋に比べて表現上大きな落差を考慮しないと
いけませんからね
冬では違和感のあるイベントが多そうだし、それらを起こらなくすると
冬専用のイベントを多数用意しないといけなくなるでしょう
砂漠や雪原はどうなのかって話もあるし
冬にまで探検隊を派遣するのかよってのも・・・
いっそ冬は出せないことにした方がゲーム上メリハリも出るしいいかなと
冬は街でのイベントを多く用意したらいいんじゃないかな

イベント→イベント例で２個ほど具体案を書いてみました
やっぱりシナリオ面でも協力者が欲しいと思いました・・・

**154** · 2006/08/20(日) 08:05:01

パーティ外人物の行動設定関係は、了解しました
ただ、うっかり放置しておくと数年後あまりに偏った成長をするというのも
ちょっと理不尽な気がしたもので。

そういうお話なら、例えば
・冬季は全員の行動について見直し＆清算する季節にする（年単位で行動を指示）
・春・夏・秋はパーティメンバ入れ替えを制限する（5人中1人だけとか禁止とか）
というのはどうでしょうか。

イベント案、拝読しました。非常に分かりやすいです。
しかしセイレーンクラスのイベントを「数百」書くというのは、
単に作業量の問題というだけでなく、要求スキル的に言って、
協力者を募るのは、結構難しいと思いますよ。

名無しさんからネタを出してもらってそれをベースに
スタッフが確定事項（条件評価関数、アイテム、戦闘相手…）の表を
眺めながら実装し、必要な素材を発注する、というような作業スタイルが
そこそこのペースでうまく機能すれば、もしかしたら実現するかも。

まだ時期尚早かもしれませんが、
とりあえず公式にBBSを設置してみてはいかがですか？

**154** · 2006/08/20(日) 08:11:47

あと、
・口調タイプ条件が設定されていないキャラクタ（無口、阿呆など）の
　台詞が設定されていません
・セイレーンイベントで、神学スキルなし、知力低の場合、
　８に進み、９５％の確率で「霧の布」が手に入ります。
　こうなるとちょっと意味不明な展開みたいですが、仕様ですか？
　

３３ · 2006/08/20(日) 17:20:26

全員が魅了された場合の結末を忘れてました・・・

イベントのボリュームについては

「宝箱」「薬草」「鉱石発見」「謎の果実」といったような
アイテム入手系、「罠」「雷雨」「落石」のような被害系
そういった感じのテキストの少ない単純なものを１００種程度
ちょっとした戦闘や捜索のようなものを５０種前後
選択肢や会話など物語性、分岐のあるやつを３０くらい
そして一番手間がかかる＆重要な、キャラクター関連をできるだけ多く
あとメインストーリーにかかわるものを１０～２０、これは自分で
責任を持って創らないといけないでしょう

助っ人に頼むとしたら、アイデアだけでもいいしチャートまで作れたら
創ってもらえると助かります
でも数値の変動やテキストは自分で手直ししないといけないでしょう

口調について、実際書いてみて思ったんですが口調タイプはある程度数を
絞らないといけませんね
５～６種くらいが丁度いいんじゃないでしょうか

３３ · 2006/08/20(日) 17:33:13

口調タイプ案

俺　：「俺～」「～だぜ」「～しろ！」「～か？」
僕　：「僕～」「～だよ」「～だね」「～なの？」
女　：「わたし～」「～ね」「～よ」「～かしら？」
チンピラ：「チッ～～やがる」「～～じゃねぇよ」「てめぇ～～」　[俺]で代用の場合あり
娘：「あたし～」「～よ！」　[僕]で代用の場合あり
紳士：「私～」「～です」「～ます」
淑女：　紳士とほぼ併用

こんなとこですかね・・・
年齢の変化によって爺口調に変えてもいいかと思いますが
そこまでする必要もないかな

**154** · 2006/08/20(日) 18:12:07

バリエーション１００種類という目標の内訳について、
アイテム入手系イベントは、アイテムの設定種類数によって、
また被害系イベントは、主な被害はＨＰが中心で、回避条件の設定の仕方によって
自ずとバリエーションが限られてくるような気がします。

程度の大小もあるでしょうが、「何が起こってどれだけの被害が出たか」を
直感的にプレイヤーに知らせることが重要で、しかも頻繁に発生するのなら、
凝った情景描写を入れても読まれなくなるでしょうから、
極端な話、事務的な台詞で事足りるかもしれませんので、
ここで種類を増やす努力は報われないかもしれませんね。

戦闘･探索にしても同じで、内容がテンプレート化できてしまうような
イベントならば、とりあえず1個実装できれば、数を増やすのは簡単でしょう。

やはり一番面白いのは物語性や分岐のあるタイプでしょうから、
この部分で外部の協力を得られる受け皿を用意するのが良いと思います。

口調…。
極論かもしれませんが、この設定、無くても構わないんじゃないでしょうか？
分けるとしても、年代を考慮しなくて良いようにするべきですし、
性別と職業系スキルもしくは顔画像から分別する手段もあります。

３３ · 2006/08/20(日) 23:36:43

口調はやっぱり固有のパラメータが必要でしょう
性別や職で分けると敬語の盗賊とか男口調の女のような
イレギュラーが作れなくなるし、画像で分別っていうと
左上隅のドットの色で判断とか・・・？
まぁ最低限違和感が出なければ良いので７個もあれば上等でしょう

スタッフの募集はまずこのスレで話し合ってきたようなことを
わかりやすくＨＰにまとめてからでないといけませんねぇ・・・
あと装備と主要なアイテムも決めていかないといけないし
顔絵に名前と経歴、性格、生年なんかを付けていく作業もあるし
まだメインのストーリー（なんで探検隊を派遣するか）も決めてない・・・
暑さが和らげば作業もはかどるはず・・・

**154** · 2006/08/21(月) 21:04:36

企画の内容を逐次更新していくことは、
プロジェクトの目指している方向を示す上でも、アクティビティを示す上でも、
重要だと思いますので、是非進めていただきたいですね。
更新履歴を残しておくのも有効だと思います。

しかしながら、これまでに出てきた内容を反映して詳細な企画を示したところで
新たに募集をかけなおしてみても、
前回の募集時点と比べてぱっと見で劇的な変化に乏しいような気がしますから、
企画の内容に加えて開発計画や実現への見通しを示すことが必要だと思います。

これまでに判明した点として、相当長丁場な開発が予想されます。
おそらく、現時点で完成時期が見えない開発プロジェクトに最後まで
付き合ってくれるようなスタッフは簡単には見つからないでしょうから、
途中で人が入れ替わっても、リソースが無駄にならないようなパート分けを
考えておくと良いと思います。

例えば1ヶ月間で顔グラフィックだけ所定人数分そろえるとか、
所定数の敵キャラを設定するとか、一定の拘束期間と目標を設定して
集中的にスタッフを集めるというやり方はどうでしょうか？

**154** · 2006/08/23(水) 05:38:00

企画ページがずいぶんと加筆修正されて分かりやすくなっていますね。

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

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

表示内容の仕様は未定ですが、大体こんなイメージになるのではないかと思っています。
募集も必要でしょうが、それ以前にこのプロジェクトに興味を持っていただける方が
増えると良いですね。

彩色を担当された２７５氏も是非戻ってきてください。

３３ · 2006/08/23(水) 21:15:27

おぉいいですね！感謝です

早速展示しようと思うんですが一つだけ間違いが
パーティーは探検隊を派遣する時にメンバーを選抜して
帰還すると解散します
なので街に居るときはPTはありません
できれば会話中の画面として、顔グラと会話ウィンドウ（と適当なログ）
が表示されたところを造ってもらえるといいサンプルになるんですが

**154** · 2006/08/24(木) 04:30:56

派遣の際は、持っていく荷物の選択と食糧の購入のための選択がありますよね。
そのためにはパーティの編成、つまり人員の選択と装備選択が終わっていないと、
所持可能な重量が計算できません。

ゲームの性質上、パーティ選択は詳細なパラメータをチェックしながら
慎重に人選すべきだと思いましたので、結構時間を掛けると思いますし、
途中、セーブもしたくなるのではないかと思います。
なので、パーティ編成と装備を先に済ませておき、
出発直前に荷物整理と食糧調達だけしたら
すぐ冒険に出発するというメニュー編成を考えてみました。

例えば、>>211で挙げた画像は、
「王子（主人公？）がとりあえず2人雇ってみたが、
　装備品が足りなかったので街へ調達に来た」
ような、パーティ編成の途中で起き得るであろう状況をイメージしています。

パーティ編成していないと、せっかくの顔グラフィックの使いどころがありませんし、
街にいる間、暫定的なパーティ編成や旧編成が表示されていても
ゲーム進行上、特に問題にはならないと思いますが、いかがでしょうか。

３３ · 2006/08/24(木) 20:58:11

街ではＰＴの顔やデータは表示させない方がいいです
街では各自がそれぞれの生活をしているという設定ですし
PTが残ってると街でも一緒に行動してプレイヤーはPTを
操作してるような印象になってしまいますから

編制が長くなるという心配があるなら[編制]コマンドを
追加してもいいかもしれません
キャラ全員の能力を比較してメンバーを選出し
メンバーの所持限界重量に合わせて携帯アイテムを準備する

あと街でも[道具]コマンドは必要ですね
街ではアイテムの使用は無いかと思いましたが
使用することでスキルを覚えるとか能力が上がるアイテム
は街で使えるようにしたいですからね
アイテムの確認、使用、売買をできるコマンドが必要でしょう

装備の変更や各自の行動の設定は[情報]コマンドでいいでしょう

これらのコマンドのレイアウトや操作性は結構重要になってきますね

**154** · 2006/08/24(木) 21:45:04

開始直後のイメージ（主人公は王子・必須キャラということで）
ttp://gamdev.org/up/img/7263.jpg

パーティを編成しているイメージ（上の絵だと寂しいので）
ttp://gamdev.org/up/img/7264.jpg

ちょっと冒険中のイメージ(テスト画像)
ttp://gamdev.org/up/img/7265.jpg

ユーザインタフェースの設計は、凝りだすと時間ばかりかかるので、
ゲームバランスの調整をするときに、ついでに弄ればいいでしょう。

おそらく完成することには全然デザインが変わっていくでしょうから、
とりあえず、現時点でイメージの共有化のための参考画像と考えてください。

３３ · 2006/08/25(金) 20:44:49

ありがとうございます
早速２枚目と３枚目をサンプルとしてトップ頁に
使わせてもらいました

ところで主人公ですけど
もう「主人公」というキャラは無しにしようと思います
プレイヤーはキャラクターや国の経営を司る
王か神のような存在になりますが
キャラクターとして画面に登場はしないことになります
必要性を感じないので

今書き溜めておいた顔絵を取り込んで微修正して
アップする作業をしています
ある程度揃ったらキャラ設定や登場年代を大まかに決めて
バランス的に足りないキャラを追加で作っていくつもりです
とりあえず５０キャラくらいが目標ですね

**154** · 2006/08/25(金) 21:47:01

更新ご苦労様です。
多くの方に関心を持ってもらえるようになれば良いですね。

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

それから、主人公キャラなし、ということについては、
そうなりそうな気がしていましたので了解です。
けれども、下手をすると経営シミュレーションになってしまいますので、
キャラクタとストーリー性については、
ちょっと濃い目のものを用意することも視野に入れたほうがいいかも
しれませんよ。

３３ · 2006/08/25(金) 23:47:48

もしかしてあの画像はプログラムになってるんですか？
単なる一枚絵かと思ってましたが・・・
プログラムを担当してくれるのならもちろん大助かりです
今の所自分では絶対出来ないのがプログラムですからね

キャラ関連のイベントは数もそうですが、なるべくテキスト量を
抑えつつ、キャラの魅力を上手く表現できるようにしたいですね
複数キャラのからみ重視で

**154** · 2006/08/26(土) 06:37:34

企画ページ等に列挙されているデータを元に、
内部記憶とユーザインタフェースを構成したハリボテです。
C++で作成していますが、内部変数を「ルールに従って」操作するメソッド
を実装すれば、おそらくゲームらしくなると思います。

現状は、自前のテキスト処理プログラムで内部変数の初期値を書けることと、
選択やメッセージボックスなどの簡単な入力インタフェースを使って
内部変数の操作（一部）ができ、結果を画面に表示できることまでです。

で、その「ルールに従う」部分が大事なのですが、当初は非常に曖昧だたのですが、
ここしばらくのやり取りで、かなり確信が得られた、というところですね。

キャラクタ関連のイベントは、いろいろと構想が広がりやすい部分ですが、
現在のデータ構造では実装上（管理上）の制約がありそうな気がしますので、
もうちょっと良く考えて見ます。
できればこちらについても、２，３サンプルがあるとありがたいです。

３３ · 2006/08/26(土) 20:39:42

キャラ関連はまだキャラができてないので具体的なのは
作れませんが、問題となるのは発生条件の部分ですよね？

例えば

・イベント４５が既に行われ結果が１であった（全体フラグとして収容）
　and キャラＡとキャラＢが同行している

OR

・イベント４５の結果が２であった
and キャラＡとキャラＣが同行している

共通で
・地形が森、草原
・確率２％

というような条件は可能でしょうか
条件に関してはどこまでが可能かをプログラマーから
指定してもらったほうが良さそうです。シナリオはその制限の
中でやりくりしますんで

あと表現に関しては顔絵とメッセージ窓を上下に２つ並べて
対話風なことができるかとか、揺らすようなエフェクトは可能かとか
こちらから注文を出していった方がいいかもしれませんね

**154** · 2006/08/26(土) 20:59:48

実装上の都合で要望に添えない部分が出る可能性はありますが、
その都合でゲームデザインを束縛しては意味がありませんので、
遠慮なく要求仕様を出していただいて構いません。
その仕様に矛盾や問題点があれば、対案もだしながら指摘するようにします。

イベントの結果をゲーム中持続して保持してくことは可能ですが、
いかにしてプレイヤーにそのフラグが立っているかを示すことが問題になります。
よくあるのは、フラグが立っていたら会話が変化するという表現方法ですけれども、
それと、フラグと、イベントクリア条件の関連性をプレイヤーが推理できるような
シナリオの書き方が求められます。
その辺を>>193で心配していました。

他の方法としては、フラグの代わりにアイテム（備品）を使う方法で、これなら例えば、
　(存在を知らない/入手していない/所有したことがある/所有している)
の4段階程度の属性つきで保持できると思います。

**154** · 2006/08/26(土) 21:17:08

それからビジュアルエフェクトの関連は専門ではないので、
あまり高度なことに対応できるかどうかわかりません。
現状寂しいスレッドですが、そういう知識のある方がアドバイザとして
付いていただければ、こちらとしては勉強になります。

また多少のことは出来るかもしれませんが、使っている描画エンジンの関係上、
プレイヤーへの要求スペックが過剰に上がってしまうかもしれませんので、
その辺は必要に応じて打ち合わせ、ということでお願いします。

**154** · 2006/08/27(日) 12:26:25

なんか、>>220の答えになっていませんので、頭がすっきりしているときに補足しておきます。

イベントの開始・分岐条件にキャラクタの状態を使うことは可能です。状態とは、
・冒険者ストックに登録されているか否か
・パーティ内にいるか否か
・指定のスキルを持っているか否か（装飾品による追加スキルも含む）
・指定の装備品を装備している否か
・パラメータ値が参照値より大きい（小さい、等しい）か
など、企画ページの変数の項目で上がっているものすべてです。

なので、「キャラＡとＢがパーティ内にいる」という条件も可能ですし、
論理結合で他の条件を合わせることもできます。
ただし、ほどほどにしておかないとプレイヤーにとって分かりにくくなると思います。

実装上心配があるのは、キャラクタ個人を指定する手段で、現状は、
・登録している個人名
・パーティメンバの1人目～5人目、
・マウスでクリックしたパーティメンバ
・冒険者ストック中で現在参照中の人物
のどれかを使って評価する個人を特定し、上記の状態変数の参照・更新ができます。

シナリオスクリプト中から、個人名を使ってアクセスしていると、
その人物が退役するなどして冒険者ストックから消滅した場合、
そのスクリプト自体が無効になってしまいます。

なので、意図的に特定個人の活躍期間中に限定するイベントでなければ、
「パーティメンバ中で何かの能力が最大の人」というような抽象的な人物指定をしてください。

…というところがプログラマ側からのお願いですが、
これまでのサンプルは、そうなってますので全く問題ありません。

３３ · 2006/08/27(日) 18:01:24

ちょっとプレイ時間のことを考えたんですが

一回の探険が１０分くらいかかるとすると１年が最低３０分
すると１００年で５０時間、５０年でも２５時間もかかってしまいますね
キャラの現役期間を戦士系で３０年くらい（１５歳～４５歳）魔法系で
４０年くらい（２０歳～６０歳）とすると、一周は７０～８０年くらいは欲しい
でも数周プレイしてもらうつもりなら一周は１０～１５時間くらいが理想でしょう

実際ある程度出来上がってみないとわかりませんが
今のうちに解決策を考えておいた方がいいかもしれませんね

・探険を年一回にする　→　単調になるのは防げるがキャラを使う機会が減る
・一回の探険を５分くらいにする　→　盛り上がらない
・シナリオを分けて途中からでもプレイできるようにする　→　アイテムやシナリオをどうするか

**154** · 2006/08/27(日) 20:11:52

プレイ時間も大事ですが、プレイの目的の方が重要かもしれませんよ。
「最長距離を目指す」だけだったら、セーブ＆リトライを繰り返し、
不利なイベント、戦闘結果を避けまくるという攻略法をすれば、
１シーズン何時間かけてでもプレイするかもしれません。
逆に、遠征が無理だと判断されたらすぐ帰還するでしょうから、
平均的な探検時間を想定しても、思惑通りにはならない気がします。

遠征することは、イベント発生条件の一つとして考え、
それ以外に探検の目的を設定することを提案しておきます。

または、例えば１０００ｋｍまで到達できたなら、次回の探検は
５００ｋｍあたりからでも開始できるようにするとかによって、
プレイヤーのレベルに合わない作業を飛ばす救済策を用意してはどうでしょうね。

３３ · 2006/08/28(月) 21:48:50

探険の途中ではセーブは出来ないようにするつもりです
それと死者が出て強制的に帰還するのと帰還コマンド
で無事に帰還するのとでメリットデメリットの差を大きく
つけると緊迫感が出て面白そうですね

あと一応目標距離ってのを設定しておいて、到達すると
ニューゲームでも影響するボーナスがもらえるように
しますかね
・イベントコレクションが見れるようになる
・アイテムコレクションが見れるようになる
・アイテムを持ち越せるようになる
・死んだキャラが再登場するようになる
などのボーナスから一つ選べるようにする
最長距離を目指す場合はそこからさらに奥にも行けると

あと新しい数値として［発展度］というのを作ろうと思います
探検隊を派遣せずに奉仕活動をしたら［発展度］が上がることにして
［発展度］が上がると
・予算が増える
・強い武器、強力なアイテムが購入できるようになる
・学校、開発所などの施設が登場する
こうすることで探検隊を出さないメリットというのをつくり
バランス的に年に１～２回の派遣が最も効率良いようにする
あとは探険から帰還すると調子が絶不調になり、休むと
１ずつ向上するようにする（病気や怪我、幸運などで急低下、上昇もあり）

**154** · 2006/08/28(月) 22:39:16

探検隊を出してレアな材料を持ち帰ってくるか、
奉仕活動に精を出すか、良く考えよう、というところですか。

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

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

実装上必要なことは、
・発展度の単位、次元
・上昇要因別の上昇値
・上限値
・発展度の表現方法（数値、画像、メッセージ、選択肢）の具体的仕様
などですね。

発展度を上げることと探検することとのトレードオフを作ろうとするなら、
このパラメータに関しても相当量のイベントなどを用意することになりそうです。
こちらも、企画ページで具体例をまとめていただくと分かりやすいと思います。

３３ · 2006/08/29(火) 23:35:35

探検隊を派遣しなかった季節だけ発展度が上がるようにします
上がる量は冒険者全員の知力の合計（×α）とかでいいでしょう

あと冒険者一人につき春に一定額の給金を払うことにします
金が足りなかったらなんらかのペナルティ有

キャラの引退は任意にしようかと思ってます
能力が落ちてきたのをどの程度で見切りを付けるか
枠数や給料と相談して考えさせるのも面白いかと
引退コマンドは［情報］表示時でいいでしょう
逆に登場時期の方を変数にしようと思います
全員１５歳で登場とかだと不自然なので

あとは装備ですが、強力な装備を入手したとして
メンバー交代のたびに付け替えるのは面倒です
なので一度授与したら変更不可にしようと考えてます
引退の時に返還されることにして

あとキャラ情報の時に三国志の「列伝」的な経歴情報
を３０字程度で見れるようにしたいです

**154** · 2006/08/30(水) 22:10:49

先日のイメージを作っているデモプログラムの準備が出来たので公開しようと思います。
そこでちょっとご相談なのですが、このプロジェクトをどの程度の人数がチェックしているか興味があるので、
ダウンロード数をチェックできる自サイト(ttp://www7a.biglobe.ne.jp/~amadela/)に置きたいと思います。

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

さもなくばそれらのファイルを企画ページからダウンロードしてもらうように、ドキュメント中に書いておきますが、
その場合、まとめてダウンロードできるような形にしていただけたらありがたいです。
よろしくお願いします。

３３ · 2006/08/30(水) 23:15:28

よく解りませんが別々にダウンロードするのは面倒でしょうから
そちらで一まとめにしたほうが良いでしょう

でも　chr1～4はgifで８８×１０４、chr5～13はbmpで８０×９６なん
ですがそこは問題ないんですかね
とりあえずは適当でいいでしょうけど最終的には揃えないとねぇ
サイズはまぁ近々直すつもりですが、私の使ってるグラフィック
ツールではgifに変換できなかったりして・・・
画像の形式は何がいいとかはCG師さんが現れないと決められないかな

３３ · 2006/08/31(木) 22:26:03

画像のサイズと拡張子直しておきました

数えてみるとかなりキャラのバランスが悪いですね・・・
魔法使い系と盗賊系が多すぎるかも
学者、医者あたりを増やさないと・・・
あと親子とかも考えていかないとな・・・

**154** · 2006/09/01(金) 21:25:06

デモプログラムの公開を開始しました。
>>229 のHPから「ちょっと気になったゲーム」⇒「ミニRPG第一部」です。
まだゲームになっていませんが、とりあえず動くとこんな感じではないか、
というところです。

画像の形式は、WEBブラウザで見える形式なら必要に応じて変換しますので、何でも構いませんが、
縦長の画像なら、高さ128(２のベキ乗)で作ってもらえると効率が良いです。
今のままでも問題ありません。

人物は、仮で良いですから登場年数と現役期間を定め、
年表にしてみてはどうでしょうか？

３３ · 2006/09/01(金) 23:31:59

おぉ動くものが出来ていますね
ご苦労様です
これでゲームの雰囲気がぐんと伝わりやすくなりますね
興味を持つ人が増えてくれるといいですが

操作性とかレイアウトとか色々注文をつけるのは
まだ控えた方がいいんでしょうか
細かい所は置いておいてとりあえず気になったこと
だけいくつか挙げてみますが

・透過は見づらいのでやめたほうが良いかも
・フォントは６４０×４８０でちゃんと見えるサイズで
・個人の重量は要らないので全体の重量／限界重量
　を常にわかるようにしたほうが良い
・編制時の能力は比較しやすいように一覧表示が欲しい
・街にいるときは顔グラ表示は必要ない

とりあえずといいながら結構細かいことまで挙げてしまいましたが
まぁ画面に関しては洗練していく作業にかなり労力を要しそうですね・・・

**154** · 2006/09/02(土) 05:55:46

インターフェースのデザインに関しては、仮組みですからどんな風にもできますが、
「中断前」のレイアウトをベースに、デバッグの都合優先になっています。

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

しかし分かっている部分については、
次回リリース（戦闘システムの実装を予定）までに、可能な限り修正しておきますので、
気が付いた時点で問題点や要求仕様などを挙げておいてください。

とりあえずデモ版に関しては「公開中」ということで、
作業を先に進めたほうが良いと思いますよ。

３３ · 2006/09/02(土) 17:52:18

ＨＰにレイアウト案をアップしてみました

この通りにしろというモノではないので
一応参考程度にしてよりプレイヤーが操作しやすい
インターフェースを模索してみてください
作業はゆっくり自分のペースでやってください

**154** · 2006/09/03(日) 20:10:02

ユーザインタフェースデザインというのは結局、
プレイヤーが理解しやすく、使いやすいことが一番なので、
ゲームバランスの調整ポリシーが決まってきたころに考えましょう。
３３氏案拝見しましたが、ちょっと数字が多すぎて難解な印象を受けますから、
グラフ（棒グラフやレーダーチャート）を併用することになると思います。

それはそれとして、戦闘システムに関してですが、
まず、敵キャラクタの登場タイミングについては、地形イベントと同じときに、
乱数で判定しようと思います。
ゴブリンやセイレーンでは分岐によって戦闘になったりますが、
通常の敵も、登場台詞を省略するだけで同じ処理システムに載せられます。

そこでまず、敵編隊の構成パターンをどうするのかについての質問です。
①単一キャラか混成チームか
②常に５体セットか様々か（最大数は？）
③敵の出現パーティはパターン化するのかランダム生成か
④同種のキャラクタに能力差をどのように与えるのか？
　　※敏捷性が同じだと、敵全員が同時に行動ゲージが満タンになる？
⑤敵の強さに変化をつけるのか
　　※遠征距離に比例して敵が強くなるという考え方が自然ですが、
　　　このゲームシステムの場合、遠征するにつれ、
　　　物資が厳しくなることが最大の敵になる気がします。

３３ · 2006/09/03(日) 21:55:37

敵は１～５匹までで混成のパターンでいいでしょう
前衛、後衛もありますしね
一定距離ごとに区切って、各地形ごとにパターンを２０程度
決めておいてそれぞれ確率も決めておいてランダムで
という形でいいでしょう

例
距離１～５０・草原
１：前衛　野犬×５　　　　２％
２：前衛　コボルト×２　後衛　弓コボルト×３　　　２％
３：前衛　コボルト×３　後衛　弓コボルト×１　ゴブリン×１　　１％
４：前衛　岩石男×１　　０．５％
５：前衛　ヒクイドリ×３　　１％
・・・・２０パターンほど
といった感じ

敵の能力は同種でも小幅で変動があるのがいいですね
同時に行動ゲージが満タンになった場合は優先順を決めておけばいいでしょう

敵は序盤ほど弱く種類が多く、距離が長くなるほど強く種類は少なくがいいですね

戦闘の回数はかなり低くしようと思っています
ゲーム序盤は一回の遠征で１～２回、少ない時は一度も敵に出会わず帰る
くらいでいいと思います
敵の種類はイベント以外で１００種は欲しいですな

取得経験値の種類と割合を敵依存で決めるのか、それとも使用武器依存で
決めるのか、それをまだ考えてませんでしたね・・・うーむ
敵の表示方法も問題だ・・・

**154** · 2006/09/03(日) 22:34:30

敵５体が同時に行動ゲージ満タンになって、
敵が５回連続攻撃してくるのはさすがに厳しかろう、と思ったのですが、
良く考えてみたら、戦闘開始時の行動ゲージ初期値を分散させておけば済みますね。
エンカウント条件によって自分または敵の行動ゲージが規定されてましたし。

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

いずれにしても、敵キャラクタの設定や画像のデザインで作業量が増えますね。
３３氏がどこまで自分で作りたいかということと、予定している規模がどのくらいか、
というあたりを示してもらえると、ありがたいんですが。

３３ · 2006/09/03(日) 23:25:21

敵キャラの名前とか数値的なことはもちろん自分でやりますよ
問題は画像なんですが、その前に表現法を決めないといけないわけで

一番簡単なのは敵もパーティーと同じように枠で囲ってしまう
やり方ですが見栄えは最悪でしょうね・・・
ミニキャラを作ってクォータービューだと見栄えは良いし楽しいでしょうが
ドット絵師が必要になりしかも作業量が半端じゃない
一番無難なのはドラクエ式でしょうが、正面からの絵で前衛と後衛を
どう表現するかが問題ですね

３３ · 2006/09/05(火) 00:52:15

戦闘時のキャラの絵を３０×４０くらいで
武器ごとに７種　×　構え＆攻撃モーションで２種　×　男女　で２８パターン
敵は１００～１５０程度で半シルエット風
このくらいなら可能な気もしますね
やはり前後衛がぱっと見て解るようなのが好ましいですからね

３３ · 2006/09/05(火) 01:47:03

ＨＰの戦闘の項にイメージ図をあげてみました・・・

**154** · 2006/09/05(火) 22:37:00

とりあえず、魔法の種類と効果、使用可能条件と使用方法についての設定をお願いします。
魔法を使う敵を出すのかどうかによっては、プレイヤー側にも魔法耐性の設定（算定）が
必要になるかと思います。

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

プレイヤーパーティに合わせて、カード対戦ゲーム風に
抽象化した表現でも良いような気がしましたが、いかがでしょう？

３３ · 2006/09/05(火) 23:32:53

魔法は普通のゲームのように戦闘中に「メラ！」とかそういうのはありません
杖装備＝魔法攻撃　ということになっていて、物理攻撃との違いは
・威力が知力依存
・防御無視
・全体攻撃が出来る（スキル「魔道」があれば）
ということです
敵も同じような攻撃を使うものを登場させます

スキルで覚える「火炎」や「鉄身」などの魔法は戦闘前に使います
敵が気付いていない時に魔法を使うという選択ができ、火炎だと
先にダメージを与える、鉄身だと防御力を上げる、という具合です
他の「魅了」や「浮遊」「幸運」などは全てイベントで選択肢が出た時に使います

カード対戦風はあまりメリットは無いような・・・
画像サイズを統一しても違和感が無いというメリットはありますが
このゲームの戦闘はかなり単調で戦略性とか無いですからね
見栄えが良くて解りやすいのが良いと思うので、CGの作業量という
問題がクリアできるならオウガバトルのような感じが理想だと考えてます
横向きでミニキャラにすれば絵のクオリティも幾分誤魔化せるし
良いんではないでしょうか
ただプログラム的に難があったら遠慮なく言ってください

**154** · 2006/09/06(水) 22:47:02

魔法関係の確認事項です。よろしくお願いします。

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

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

(3)スキル系の魔法は戦闘開始時の１回だけ使用可能？
　　先制なら確実に使用可能
　　通常はランダムで２分の１
　　不意をつかれたときは使用機会なし

(4)スキル系の魔法は失敗しない？

(5)「火炎」のダメージ量は知力やスキルに依存しない？

(6)魔法攻撃は反撃を受けない？

(7)事故判定によって間違って味方全員に魔法攻撃することもあり得る？

(8)事故判定によって目に砂が入った場合でも魔法攻撃は確実に当たる？

(9)魔法攻撃にもクリティカル判定がある？

３３ · 2006/09/06(水) 23:27:04

うぉっ９項目も！

Ｑ
（１）　杖を装備すると誰でも攻撃は杖仕様（知力依存、防御無視、遠距離可）になります
　　　　ただしまだ倍率は決めていませんが　スキル無し・「魔術」有・「魔道」有では
　　　　ダメージ倍率に差をつけようと思ってます。スキル無しではカスダメージ、「魔術」
　　　　有で防御力の高い敵にはやや有利、「魔道」習得だとかなり強力、というバランスに

（２）　スキル系魔法は習得していれば杖を装備していなくても使えます。ただしスキルの
　　　　項に書きましたが「魔術」は知力２０以上でないと習得できません。威力や成功率に
　　　　関してはイベントの場合はそれぞれ判定式があったり一律だったりと色々な場合が
　　　　あるでしょう。戦闘前の魔法では「鉄身」は一律でいいでしょうし、催眠や死は知力・
　　　　スキル依存の成否判定式があったほうが良さそうですね。

（３）　戦闘開始時の魔法使用は一回だけ、しかも何を使用するかもランダムです。
　　　「しっ！・・・あそこにゴブリンが５匹いるぞ！」（先制攻撃を表す）↓
　　　「○○は火炎の魔法を使った！」↓
　　　「ゴブリンたちにダメージを与えた！」（個別の数値は不要かな）
　　　戦闘画面に移行
　　
　　　という感じで。通常（どちらの先制でも無い場合）では魔法、弓使用者が複数居たら
　　　各人について個別に５０％判定します。

３３ · 2006/09/06(水) 23:28:25

長すぎるといわれた・・・ので分割

（４）　戦闘開始時のスキル系魔法は「催眠」「死」は知力・スキル依存の成否判定有で
　　　「鉄身」「火炎」は失敗無しで。

（５）　「火炎」のダメージは戦闘中に杖で全体攻撃したのと同じダメージでいいでしょう
　　　敵には「魔法防御力」というステータスはありませんが、耐性のタイプとして
　　　「魔法耐性」「魔法無効」というものがあります。この手の敵の場合、ダメージも
　　　成否判定も５０％、０％になります。「催眠」は敵一匹ずつ個別に判定を、「死」の
　　　場合はランダムで一匹対象を決めますが「魔法無効」の敵とそうでない敵がいた
　　　場合、「魔法無効」の敵はランダムの対象から外したほうがいいでしょうね。

（６）　杖、弓での攻撃は反撃を受けません。また杖、弓装備者はどんな攻撃に対しても
　　　　反撃を出来ません。

（７）　味方の事故判定の場合単体に杖攻撃でいいでしょう。攻撃タイプが「全体」の敵の
　　　　場合は味方全体に攻撃ですね。

（８）　砂が目に入っても魔法攻撃は必中でいいでしょう

（９）　魔法にクリティカルはありません

まだまだ説明不足の箇所ありそうなんでドシドシ指摘してください

３３ · 2006/09/06(水) 23:45:28

修正

（２）（４）　「催眠」「死」の成否判定に知力・スキル依存

　　　　→　　　　　　　　　　　　　知力依存

「魔術」無しでは魔法スキルは習得できないので「魔術」と「魔道」
の差をつけるかということですが、これは同じでいいでしょう

３３ · 2006/09/06(水) 23:55:13

ＨＰの戦闘の項修正加筆しました

敵のパラメータちょっと変えました

耐性攻撃　→　受けたとき威力が５０％になる攻撃の種類
無効攻撃　→　受けたとき威力が０％になる攻撃の種類

例

ゴブリン　耐性：弓　無効：無し
ユニコーン　耐性：短剣　無効：魔法

ゴブリンは弓攻撃のダメージが半分になる
ユニコーンは短剣のダメージが半分になり、魔法は全く効かない。
杖のダメージは０になり、先制攻撃時の魔法も通じない。

３３ · 2006/09/06(水) 23:56:11

あ、「弱点攻撃」も設定したほうがいいな！

**154** · 2006/09/07(木) 20:57:15

丁寧にありがとうございます。では遠慮なく。

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

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

(3)近接武器しか持たないキャラが後衛に回されたら何もできない？
　　（戦闘中、前衛・後衛の入れ替えを指示することはできるのか？）

(4)「根性」スキルのあるキャラクタの復活判定は、被害直後（５）か連打完了後（９）？
　　また、魔法「死」を食らった場合にも復活できるのか？

(5)戦闘中、回復剤は使用可能なのか？

(6)敵は回復手段を持つのか？またアイテムを使ってくる可能性は？

(7)「防御、逃亡、道具」の選択は、確実に実行するのか、事故判定するのか？

(8)催眠中のキャラクタがダメージを受けたときの取り扱い

とりあえず、こんなところにしておきます。

３３ · 2006/09/07(木) 21:53:59

（１）　敵の場合というのは敵の思考アルゴリズムのことですね
　　　　敵が味方を攻撃してくる場合対象は攻撃可能範囲から
　　　　ランダムです

（２）　入れ替わるのは当人だけです。当人が唯一の前衛の場合
　　　　前衛がいなくなるので、自動的に全員が前衛になりますね

（３）　それは何も出来ません。入れ替えは１ターン消費で可能と
　　　　いうことにしましょうかね

（４）　一発のダメージ直後です。１で耐えた後に連打が来たら死
　　　　にます。魔法「死」には適用されません。

（５・６）　戦闘中の回復は非常に高価な（で重い）アイテムを使用
　　　　することでのみ可能ということにします。敵はアイテムを使
　　　　いませんし、回復もしません。

（７）　事故判定は攻撃を選択した直後のみです

（８）　「眠っている」という状態があるわけではなく、ただ戦闘開始
　　　　しばらくターンが回ってこないだけです（処理上は）。なので
　　　　ダメージを受けて起きるというようなことはありません。

ついでに敵からの魔法スキル、弓による先制攻撃は通常は無しに
しましょう。イベントでの戦闘ではあるかもしれません。

３３ · 2006/09/07(木) 22:13:23

よく考えたら事故判定は攻撃→対象指定の後の方が良いですね。
修正しておきます

３３ · 2006/09/07(木) 22:26:32

眠っているのに攻撃を避けたり反撃したりするのは不自然ですねぇ
行動ゲージがマイナスである、というのを条件に必中、反撃無し
にしましょうか
となると行動ゲージがマイナスの間はそれが判るエフェクトも欲しいし
そこまでするなら「催眠」以外にも行動ゲージがマイナスになる場面
を作りたくなりますね・・・
衝撃食らうとマイナスまで落ちることにしましょうかね・・・？
ちょっと検討してみます

３３ · 2006/09/10(日) 00:05:10

敵が攻撃する時に「かみつき」とか「炎」とか「体当たり」とか
「攻撃名」というパラメータを用意して表示した方がいいかな
計算パターンとしては味方の武器と同じものを使うわけだけど
攻撃の際にエフェクトと一緒にチラッとでもそういうのを表示したら
イメージがだいぶ違うかもしれない

**154** · 2006/09/10(日) 20:40:20

ダメージ計算式と対象選択方式のテーブルを増やすだけのことなので、
武器による７種以外に、敵専用パターンを設定しても大して手間にならないと思います。

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

また、防具の付帯スキルによって、火に強い法衣とかも定義できると思います。
「水の羽衣」＝鎧属性＋「火炎防御スキル」＋防御効果

どんな実装が良いかどうかは、登場する敵やアイテムの一覧表が出揃ってから
考えれば良いですので、今の段階で制約に思わないのが吉かと。
極端な話、「ある特定のスキルを持った人により、ある特定の敵にしか効かない武器」
というのも可能です。

ビジュアルエフェクトについては必要なものが絞り込めてから
グラフィックデザイナさんも交えて相談ということで遅くはないと思いますよ。

３３ · 2006/09/10(日) 22:50:58

今はキャラの相関図を作ってるんですが
戦闘の計算式も一応決めておいたほうがいいのかな？
どの道間違いなくかなりの調整作業が必要にはなるんでしょうが
暫定的な式ははそっちに任せてもいいんですかね

属性か・・・・すっぱり切ろうと思ってたんだけど
属性付けるとかなりややこしくなるしね
最近のRPGは大抵属性要素あるけど、面白さにちゃんと
繋がってるのかというと疑問だったりもしますね・・・

ところで「サブ武器」ってのはどうですかね
前衛になっちゃったら弓を捨てて剣に持ち替えるとか
このゲームはドラクエ１のように装備を外すってことが
できない仕様なんで、与えた武器は取り返すことができないし
武器を変更するためには前に持っている武器を捨てさせない
といけない（わざとそうしてるんですが）2本まで持てるように
したらいいんではないかと
ただ盾の処理がちょっと複雑になりますけどね

**154** · 2006/09/12(火) 04:02:55

際限なく攻撃力が上がって、何も考えずに打撃だけで勝ててしまうＲＰＧと違い、
割と狭い範囲で能力値が変動するようになっている本ゲームシステムでこそ、
攻撃・防御に属性が付いていると、戦略性が上がると思いますよ。
そこまで難解なものにしなくても良いかもしれませんが。

サブ武器ですが、
・全キャラデフォルトで護身用に短剣を保持していることにする
もしくは
・武器が使えないポジションでは素手で攻撃するしかない
という仕様でどうでしょうか。

あえてサブ武器を持たせてみても、めったに使わない気がしますし、
サブ武器を装備しているキャラクタは重量制限が相当厳しくなってしまいます。

３３ · 2006/09/12(火) 20:20:40

このゲームでは武器の種類が属性のような役割を
果たしてるんですよね。だから片手武器だけでも
持ち替えはありかなと思ったけど、とりあえずは今の
仕様で作ってしまいますかね

あと２つほど思いついたアイデア
まずキャラの登場時の能力、スキルをプレイごとに変化をつける
能力値なら各±５くらいの幅で、スキルはいくつかのスキルを
覚えてたり覚えていなかったりするようにランダムで決定
しかもセーブ・ロードでやり直せないように全登場人物の
能力・スキルを新スタート時に全部決めてしまう。例↓
１５　２０　２２　１０　１９　６　槍使８０％、健脚４０％、古代文字１０％　とすると
１９　１７　２７　６　　１９　７　槍使　　　　　　　　となったり
１２　２１　１８　１４　２３　９　槍使　古代文字　になったりする

もう一つは街の背景グラに通行人の絵（シルエットでも）をランダムで描いて
クリックすると町の噂を聞けたりする。

まぁ土台が完成してからの話ですがね

**154** · 2006/09/13(水) 23:20:02

「敵のステータス」のところの「攻撃」と「Ｔ」は、
それぞれ表現方法と、攻撃力計算方法ということでよろしいですね？

ちなみに「巨人」の場合、攻撃力５５、筋力５４のメイスだから
攻撃力は５５＋５４×２＝１６３で、
しかも受ける人の防御は半分キャンセルされると、無茶苦茶痛そう…

ところで、行動ゲージ蓄積の際、装備品の重量は無視しますか？

３３ · 2006/09/13(水) 23:38:47

味方の場合　攻撃力＝能力値＋武器性能　ですが
敵の攻撃力は計算後の数値です
じゃあ能力値は意味無いじゃん、ってことになりますが
そこは連打判定とか回避、反撃の判定に使うということで・・・
敵の能力値は適当に書いてったのでバランス無茶苦茶かも

行動ゲージは装備の重量は無視でいいでしょう

ところで１５４氏のＨＰはリンクしてもいいでしょうか？
リンクする場合はトップがいいんでしょうか

**154** · 2006/09/14(木) 06:14:26

数値が具体的だったのでこれを基礎資料にキャラクターの
標準的な能力を設定するのかと思いましたが、まだ暫定値、ということですね。

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

それからリンクは一応、トップページにお願いします。

**154** · 2006/09/14(木) 22:36:01

追加の確認事項です。

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

ついでに、
③戦闘時の計算では随所でスキルの支援効果がありますが、敵は一切なしで良いのか？

よろしくお願いします。

ちなみに、プレイヤー側のキャラクタについては、
・攻撃力＝　装備武器の攻撃力　＋　筋力×α　＋　技量×β　＋　知力×γ
　　　（α,β,γ):武器の種類別の定数。剣なら(1,1,0)、斧なら(0,2,0)など
・防御力＝　装備鎧の防御力　＋　装備盾の防御力
のような計算式（暫定）にして、敵のデータ構造と揃えることにしようと思います。

それから、
近距離武器＝｛剣、小野、メイス、短剣｝：前衛が相手前衛のみ攻撃可能
　※事故により後衛に下がった場合、１ターン消費で前衛に復帰
　　但し、全員後衛になった時点で、他のメンバー含めて強制的に前衛にされる（詰め寄られるイメージ）
遠距離武器＝｛槍、弓、(杖、全体)｝：どこからでも、誰にでも攻撃可能
　※杖は、対象選択時、単体だけでなく全体攻撃(要スキル)の選択が可能
というような感じになるかと考えいます。違ってたら修正してください。

３３ · 2006/09/14(木) 23:29:59

武器の項は古くて消すの忘れてました。「貫通力」とか無くなりました
武器の数値は攻撃力と重量と種類だけです。（あと両手か片手か）

敵にはスキル補正は無くていいでしょう

後半の理解はそれで間違いありません

敵のパターンを書き出すのが結構面倒なことが発覚・・・！
どうせプログラム化するときには数値の羅列にするんだから
その形で書いたほうが楽かもしれませんね

リンクはもうちょっと形になったものがダウンロードできるようになって
からにしましょうか。

**154** · 2006/09/15(金) 21:30:10

「敵のステータス」のページで、preタグの中を、
・名前やパラメータ名が書いてある行の頭に半角#を書く
・時々混じっている全角スペースを半角スペースに置き換える
としてもらえると、非常にありがたいです。

耐・無・弱の中にある「魔」は、杖による単体および全体攻撃のことでしょうか？
もしそうなら、「杖全」と書いてもらえるほうが処理しやすいです。
また、「Ｔ」のところも、短剣なら「短」、全体なら「全」にしてください。

その副作用で、弱点などに「メ槍斧」とか書いてもらえれば、３種類反映できます。

「もうちょっと形になる」というのが、どれぐらいのレベルをイメージされているか
わからないのですが、それをこの調子で我々だけで作ってしまうのか、
メンバ募集をかけてみて、もっといろいろなアイデアを話し合うのか考えてみても
良い時期かもしれませんよ。

まだゲームにはなっていませんが、「とりあえず動くもの」を作りましたから、
前回のメンバ募集とは多少違った反応があるかもしれませんし、
その辺は３３氏の裁量にお任せします。

３３ · 2006/09/15(金) 22:20:11

了解。こんな感じでいいんでしょうか
これでよければ残りも直しておきます
道具や装備も似た感じで書いたほうがいいのかな
あと敵の出現パターン
前衛　ゴブリン×２　後衛　ゴブリン弓×３
↑こういうのはどういう書式で書くのがいいんでしょうか

メンバ募集か・・・
今進行速度はともかく平穏無事にやっていけてるんで
動くのは結構怖かったりしますよね・・・

新しい人を加えるなら「こういうことをやってもらう」というのをはっきり
示せるように見本となるものをいくつか用意してからがいいと思うんですよね
なので私の仕事的には敵、アイテム、合成関係をちゃんとまとめて
キャラの相関関係を仕上げて、探険のイベントを３～４個作って
キャラ関連のイベントも例となるのをいくつか創ってから
プログラム的にはキャラの成長、アイテムの移動（売買とか）
開発関連を動くもので見せられるようになってから
それくらいまで進んだらメンバーを増やしてイベントとグラフィックを
仕上げながらインターフェースやバランス調整を並行してやっていく
という風にできたらいいなと思ってます

**154** · 2006/09/15(金) 22:40:14

# はコメント行の判断のためですので、コボルトなど実際に定義している行には付けなくて良いです。

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

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

そういえば、メンバ募集で思い出したのですが、そろそろ「ミニＲＰＧ」とは呼べない規模に
なってきましたから、何かプロジェクト名をつけてはいかがですか？

**154** · 2006/09/15(金) 22:57:06

敵の出現パターンについては、これももう少し検討してから確定したいですが、
今１行に並べたいのであれば、
　ゴブリン F 20; ゴブリン　F 25; ゴブリン弓 R 40; ゴブリン弓 R 50; ゴブリン弓 R 50;
のような形式かな、とか考えています。

つまり、
　名前設定文字設定文字 … ;
の形式で、名前は敵ステータスの名前に対応し、
設定文字には、
・F(前衛) R(後衛)
・能力値ステータス補正パラメータ(人間の年齢のようなもの)
などを設定できるようにして、個体差を乱数ばかりではなく、
明示的に設定できるようにしようと思っています。

敵ステータスも、出現パターンも、戦闘のテストプログラム上で編集・調整して、
テキストファイルに書き出せるようにしますので、もうちょっと時間を下さい。

また、可能なら何人かのプレイヤー側キャラクタについて、
典型的な装備状態、パラメータ設定（今は大小関係しか設定がありませんが）の
テストデータを設定してもらえると嬉しいです。
（人と、大体同じぐらいの能力を持った敵の名前を指定して下さっても結構です）

３３ · 2006/09/15(金) 23:36:16

#名前 HP 力敏体知技運武器　攻鎧盾防スキル
アストン 250 30 19 32 14 27 20 槍 10 7 槍使前衛
ダリア 230 32 21 26 12 24 15 剣 7 9 剣技前衛
ルトラ 180 21 31 20 18 30 33 短 5 4 前衛
クレア 160 14 14 13 28 26 25 メ 5 5 前衛
ワンジ 120 9 11 10 38 27 14 杖 3 3 魔道後衛

とりあえずこれを使ってください
スキルは適当に試したいのを付け加えてください

プロジェクト名ですか
思うにゲームの名前ってのはかなり大事です
プレイしてみようかと思う時結構名前で判断してたりしますからね
とりあえず決めてあるのは「簡単で短く日本語」ってくらいですか
「○○ＲＰＧ」っていう紹介にしてもなんて付けていいのやら
ちょっと判りませんね。どんなゲームかを短く説明できるテキスト
を考えておかないといけませんね

**名前は開発中のものです。** · 2006/09/15(金) 23:39:32

ず、ずれまくった・・・

#名前 HP 力敏体知技運武器　攻鎧盾防スキル
アストン 250 30 19 32 14 27 20 槍 10 7 槍使前衛
ダリア 230 32 21 26 12 24 15 剣 7 9 剣技前衛
ルトラ 180 21 31 20 18 30 33 短 5 4 前衛
クレア 160 14 14 13 28 26 25 メ 5 5 前衛
ワンジ 120 9 11 10 38 27 14 杖 3 3 魔道後衛

**名前は開発中のものです。** · 2006/09/15(金) 23:40:14

なんも直ってないし！

**154** · 2006/09/16(土) 20:00:02

試験的に、攻撃力の計算式を>>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)
としてみましたが、ちょっと強すぎるみたいなので、
係数や計算式を変えたほうが良さそうです。

アストン(槍)　10+30+27= 57
ダリア(剣)　　7+32+24= 63
ルトラ(短)　　5+32+30= 67
クレア(メ)　　 5+14*2= 33
ワンジ(魔道) 3+38*2= 79

修正案がありましたら、ご提案ください。

それから、バーバリアンの名前の直後と、その行の「耐」(=剣)の後ろに
全角スペースが残っています。

**154** · 2006/09/16(土) 20:08:59

間違えました。
ルトラ(短) 5+21+30=56
それでも黒ドラゴンより強いです。

攻撃力＝武器の攻撃力×技β＋筋α
とかで、どうでしょうね？（βは小さめに設定する）

**154** · 2006/09/16(土) 21:06:29

またしても確認事項です。

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

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

それから、全体攻撃しかしない敵というのは、相当嫌ではないかと思いましたので、
一応、「Ｔ」の項目は、「耐」等と同様に複数種類設定できるようにしておきます。

まあ、そういう敵もパーティに一匹ぐらいなら最初に袋叩きにするわけですが、
スモッグ×５（包む＝「全」）とか来られたら、うんざりするのではないでしょうか。

３３ · 2006/09/16(土) 21:52:36

敵の先制魔法攻撃はプログラム的に面倒かと
思ったんですが可能なら面白いですね
魔法スキルを持たせることにしましょうか

数値の件ですがこういうゲームって数値が
小さいほどバランスはとりやすいですよね
人間の限界を５０にしようかと思ってましたが
３０に減らすかなぁ・・・
でもそうするとアイテムの重量を小数点一桁まで
設定しないと厳しくなるんですよね
あとダメージにおける武器と能力値の影響の比率は
１：１～２くらいが妥当でしょうか
前出のような計算方式ならもっと細かくしてもいいかもしれません

剣(0.6,0.6,0)、斧(1,0,0)、メイス(0.8,0.3,0)
槍(0.7,0.5,0)、短剣(0.3,0.8,0)、弓(0,1,0)
杖(0,0,0.5) 魔術(0,0,1) 魔道(0,0,1.5)

#名前***HP**力*敏**体知技運武器**攻*防 **スキル
アストン*250**19*10*21**9*14*11 槍 ***12 **7 **槍使 **前衛
ダリア***230**20*12*16**8*12**8 剣 ****7 **9 **剣技 **前衛
ルトラ***180**13*23*11**9*19*21 短 ****5 **4 *********前衛
クレア***160**10*11*12*17*13**8 メ ****5 **5 *********前衛
ワンジ***120***6**9**8*24*14*16 杖 ****3 **3 **魔道 **後衛

とりあえずこんな感じでどうでしょう
敵も合わせて変更するんで待ってください

３３ · 2006/09/16(土) 21:54:55

あと敵の攻撃タイプを複数設定できる（2個まででいいかな）
ということですが、攻撃方法の名前もそれに合わせて2個に
できるでしょうか？
できるとかなり楽しくなりそうですが