ＳＲＣ意見交換掲示板Mk2 [One Topic All View / Re[2]: (20日AM2時ごろ修正有)目標・方針等再提示 / Page: 0]

ＳＲＣ意見交換掲示板Mk2
(現在過去ログ54 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■5661 / inTopicNo.1)

　複数のユニットが重なっている状態を可能にする機能追加案について

□投稿者/ 中箱 -(2007/12/22(Sat) 19:04:28) [ID:8NrUE61r]

もうすっかり週末ですね、見通しよりも遅れ気味ですが中箱です。
一応、No.5633にて開始された意見交換の一部のみを引き継いでの仕切りなおしということで。

･･事前に自案を固めすぎたせいか、イマイチどこから煮詰め直すべきなのか判断に迷っているのですが。

●
まずは、
「複数のユニットが同じマスに存在する状態」を、
「母艦に格納されている状態」のような特別な状態として扱うような機能追加を、案に含めるか否か。
からでしょうか。

特別な状態として扱えば、
重なっている状態での戦闘などについての仕様も詰める必要が出ます。
戦闘やコマンドなどに統一性が図れますし、従来の機能では代用困難な動作もリクエスト案に含めることで可能になるかもしれません。
しかし、仕様追加が多くなることが予想される為、リクエストを行った場合の実装可能性に劣るでしょう。

逆に、
特別な状態として扱わない場合は、
最低限の仕様追加をリクエストし、その追加された仕様を利用したサブルーチンを用いて、
「重なっている」ような動作(戦闘、ユニット操作等)を再現することになります。
そのため、重なった状態の扱いはシナリオ作者が組むサブルーチン次第となり、選択肢が広がります。
ただ、重なった状態を実現するためにはサブルーチンが必須になるため、シナリオ作者の負担は増しますし、動作速度の低下など、プレイアビリティへの影響が考えられます。

私としては、「特別な状態として扱わない」の方を採りたいと考えています。

これは、リクエストの実現可能性という面もありますが、
特別な状態として扱うことで「ユニットが重なっている戦闘はこうなる」と規定されてしまうと、
実装されたものが、利用すること自体は手軽ではあっても、細かい調整が利かずに使い辛いものになりそうな気がしてしまうので。

既存のゲームにおいて複数のユニットが重なった状態の戦闘は、良く出る"小隊システム"だけに限らず、それぞれ独自のルールで行われますから、
細かい仕様はシナリオ作者に任せた方が良いのではないかなとも。

●
なお、今のところ、自案としては以下のような動作が可能であることを目標に考えています

○他のユニットが存在するマスも、(ある条件下では)移動先に指定可能になる。

○ただしあくまでも、1マスに複数のユニットは存在できないままで、
　ユニットが重なりそうな場合の扱いは
　　・移動できない（従来の仕様と同じ）
　　・下になるユニットはEscapeと同様の扱いとなる。(もしくはEscapeさせ、必要に応じてサブルーチン制御でもとの位置に戻す)
　　・元いたユニットは隣接マスに強制移動させられる
　などなど、これに限らずシナリオ作者が(サブルーチンを用いて)独自に設定する。

○戦闘に関しては基本的に変更無し。必要であれば必要に応じてAttackコマンドなどを用いて再現してもらう。

具体的なリクエスト内容としては、
　移動先の選択肢の拡張＋移動先を選択した時に実行されるようなイベントラベルの新設
のような感じになるでしょうか。

●
文章の内容が漠然としていて分かり辛いなど、色々あるとは思いますので、
何かしらご意見がある方はよろしくお願いします。

では

引用返信/返信削除キー/

■5669 / inTopicNo.2)

　Re[1]: 複数のユニットが重なっている状態を可能にする機能追加案について

▲▼■

□投稿者/ 小一郎 -(2007/12/25(Tue) 01:15:47) [ID:S6yWlcX9]

提案が抽象的な気もしますので必要最低限の仕様、或いは方向性を決めても良いのでは？
と思いまして、意見させて頂きます。

リクエストの方向ですが、単純に重複(スタック)が可能になる、だけで良いのでは
ないでしょうか？特別な状態として扱わない、方向で。

個人的に抱いているイメージとしては、スタックがあることで、一番上に存在している
ユニットが破壊されても、次に控えているユニットが上に繰り上がって戦闘が継続出来る
と言う程度の内容が判りやすいかと。

主に敵が使用する事で難易度を調整するメリットがあるぐらいの物、と言う事です。

決めておくべき点としては、スタックできる上限数、スタックしている時の移動力を
最低or最高or平均にするのか？ぐらいかと思います。

それと疑問点ですが、敵ユニットを重複で出現させる時はどのようなコマンドや
書式を想定されているのでしょうか？敵使用を考えていないのであれば、ChangeModeで
対応できるのか、出来ないのか？

スタックした場合、ユニットの序列は自由に変更できるのか？
これはダメージを受けそうになったら下位の序列に下げて、破壊を免れたいという時に
使える利点なので。

序列が自由に変更できるのであれば、別途ステータス画面で序列を確認できる
手段もデフォで欲しいところです。

また、スタックしている場合、視覚的にはどのような識別になるのでしょうか？
現状の表示と変わらないと、敵がスタックしていると判別がつかないですし
味方機だと、行方不明というか、プレイヤーが把握するのに困難な場合も
有るかもしれません。

あと、インターミッションであらかじめ編成などが出来るのか？或いは
戦闘終了後は自動的に重複は解消されるのか？この部分をライター任せでは
利用しにくいですからシステムで選択できるのか、できないのかは決めておいて
欲しい部分です。

小一郎

引用返信/返信削除キー/

■5671 / inTopicNo.3)

　Re[2]: 複数のユニットが重なっている状態を可能にする機能追加案について

▲▼■

□投稿者/ 中箱 -(2007/12/25(Tue) 02:50:10) [ID:jwikVFnr]

小一郎さん、どうもお久しぶりです。

･･･うーむ、やはり親記事の文章が悪かったようですね。

●
まず、えー、これは考え方の違いに尽きるのだとは思うのですが
＞スタックがあることで、一番上に存在しているユニットが破壊されても、次に控えているユニットが上に繰り上がって戦闘が継続出来る
や
＞スタックしている時の移動力を最低or最高or平均にするのか？
のように「スタックされている」ことで(サブルーチンによらず)システム的に特別な扱いが生じるのであれば
それは「特別な状態である」と言うべきだと思うのです、私の認識では。

つまり、
　スタック可能にする＝スタック状態という特別に扱われる状態を新設する
と。
ゆえに、「スタックは可能にするが、特別な状態として扱わない」という選択肢はこの場合ありえないだろうとも。

とりあえず、親記事の

>特別な状態として扱えば
の部分は　「スタック可能にすれば」　に。

>特別な状態として扱わない
の部分は　「スタックは不可能なまま」　に。

それぞれ読み替えていただければ、あの親記事も多少はわかりやすくなるでしょうか？

その上で改めて
「特別な状態として扱う＝スタック可能にする」
と
「特別な状態としては扱わない＝スタック不可能なまま」
のどちらの方針で行くべきだと思われるか、ご意見をいただけませんでしょうか。

●
なお、私は「スタック可能」よりは「スタック不可能なまま」を方針として選びたいのですが、（理由は親記事に書いた通りです）
「スタック可能」の方が強い需要と実現性が望めるのであれば、その方針で行くべきかな、とも思っています。

●
ちなみに、親記事に挙げた私案は
>○ただしあくまでも、1マスに複数のユニットは存在できないままで、
と書いたとおり、「スタック不可」を前提として考えています。

そして、スタック可能にする案とする場合の仕様は、今のところ考えていません。

説明不足な点などまだあると思いますので、その辺り含めてなにかあればよろしくお願いします。
では

引用返信/返信削除キー/

■5672 / inTopicNo.4)

　Re[1]: 複数のユニットが重なっている状態を可能にする機能追加案について

▲▼■

□投稿者/ あかんべえ -(2007/12/25(Tue) 02:58:25) [ID:dYQ1XiqD]

2007/12/25(Tue) 03:22:19 編集(投稿者)

　中箱さんご苦労様です。あかんべえです。

●
　中箱さんのたたき台には、“設計仕様（データ・処理の構造やコマンド仕様など）の前に、まず要求仕様（なにを実現させたいか？）を煮詰めよう”という議論の方向があると思います。これには強く賛同します。
　一般に、「設計」は「要求」がしっかり固まってはじめて定めえるものだし、特にこの案件はとても複雑になる可能性があるので、一気に「設計」に突き進んでも混乱した議論になるのがオチだからです。
（余談ですが、SRCかいわい、特に質問掲示板の質問者では「要求仕様を明確にする」ということがしばしば軽視されているように感じています。まあ、これはプログラムの経験を積んだりシステム設計の勉強をしてはじめてわかることなんで、しょーがないと言えばしょーがないのですが、何とかならないかなあ）

●
　たたき台は、非常に大胆に「要求」を絞り込んでいます。おそらく、この絞込みの是非が当面の議論になるかと。
　私は、たがいに矛盾する二つの思いを抱きました。

１．目的を「移動先の選択肢の拡張」などに限定することは、「現実的」な選択だと思います。「ユニットの重ね合わせ」を文字通り実現させるための数々の難題を回避しているので。
　が、この案には限界があります。とりわけ大きいのは「プレイヤー制御ユニット（味方ユニット）の動作はサブルーチンで実現できるが、思考ルーチンは対応できない」ということです。
　この制限があまりに大きいので、「絞込みすぎた結果、独立したリクエストとし、独自の機能追加する価値が無くなってる？」とも感じています。
　早い話、これだけならば、現在進行中の他のリクエスト案「マップ上の特定ユニット・地点を取得するコマンド」
http://www.src.jpn.org/neko/multibbs/cbbs.cgi?mode=all&namber=5638&type=0&space=0&no=1
に「特定地点からの特定移動力範囲のマップ地点を選択するオプション」を追加するだけで実現可能だと思います。しかもこの場合、イベント新設の必要はありません。

２．他方、文字通り「ユニットの重ね合わせ」を実現する方向は、難題です。影響を受けそうなシステムは数多く、詰めるべき仕様も多岐に渡り、内部的な変更点も少なくない。
　それでも、実現できたとき広がる世界は、大きい。
　なので、この方向の議論をやめてしまうのはもったいない気もします。
　といっても、このツリーの議論だけで《採用されうるリクエスト案》に仕上げられる自信はないのですが。むしろ「予備議論だけでも」という気持ちです。

　以上をまとめると、
・　とりあえず現実的な、「移動先の選択肢の拡張」リクエストとしては、他のリクエスト案との統合を
・　長期的な目標として「ユニットの重ね合わせ」の議論の継続を
要望します。

引用返信/返信削除キー/

■5674 / inTopicNo.5)

　Re[2]: 複数のユニットが重なっている状態を可能にする機能追加案について

▲▼■

□投稿者/ 中箱 -(2007/12/25(Tue) 22:29:58) [ID:8NrUE61r]

変なところに枝が付いてしまったようです、むぅ。

No5671が小一郎さんへのレスになります。ご了承ください

引用返信/返信削除キー/

■5675 / inTopicNo.6)

　Re[3]: 複数のユニットが重なっている状態を可能にする機能追加案について

▲▼■

□投稿者/ 小一郎 -(2007/12/26(Wed) 00:58:11) [ID:S6yWlcX9]

> 小一郎さん、どうもお久しぶりです。

こちらこそ、ご無沙汰しております m(_ _)m

> その上で改めて
> のどちらの方針で行くべきだと思われるか、ご意見をいただけませんでしょうか。

スタックであれば、重複させる事の利点や欠点など考えられるのですが
特別でない状態として扱う、という言葉だけでは想像する手ががりに乏しいので、
私の方で想像してみますので、認識が間違っている点などを指摘していただければと。

特別でない状態と言うのは、

１)移動が終了した場合に重複は起こる。ゆえにCreateやLaunchで事前に重複させる事は出来ない。
２)重複した場合、移動や攻撃は戦艦の収納のようなスタイルになる。
３)視覚的に現行の表示方法である。ユニット表示の変化は無い(重複の有無は確認できない)

４)重複した場合、戦闘時に小隊システム等の攻撃力の割増や防御の修正はつかない。
５)ＳＰの使用なども、重複した場合は制約がある。
６)移動したユニットが下位に収納され、戦闘のメインにはならない。
７)重複は制約がある(スタック数制限など)

この認識であっていれば、特別な状態でない重複と言うのは精々、母艦の収納と
違って巻き添えで破壊される事は無いぐらいが利点かな？と。その上味方だと
戦闘に参加する機会が失われる分、重複と言うのは魅力に欠けると思います。

重複状態が積極的に戦闘で役立つ…例えば重複ユニットにも経験値は入るなど
付加価値や、重複の利点をＰＲして頂ければ、特別でない状態でも面白い物に
なると思いますので、それが出来るのであれば特別でない状態での再現で良いと思います。

小一郎

引用返信/返信削除キー/

■5678 / inTopicNo.7)

　レスふたつ

▲▼■

□投稿者/ 中箱 -(2007/12/27(Thu) 17:17:23) [ID:8NrUE61r]

2007/12/27(Thu) 17:20:09 編集(投稿者)

●●
>小一郎さん

　特別な状態として扱わない＝スタック不可＝重複させる事はできない
です。
ユニットが重なっていて、表面のユニットが撃破されても即座に下にいたユニットが出てくるのでは
前回のレスで「特別な状態である」と書いたものそのものですし。

用語をうかつにそちらに合わせたのが悪かったようですね。すいません

●●
>あかんべえさん

意見交換＆本体の更新が盛んであれば、本当はもっと夢見がちな案を私案にしたかった所なのですが(笑)
機能の実装を手伝えるわけでもないですし･･･

●思い１について
＞が、この案には限界があります。
＞とりわけ大きいのは「プレイヤー制御ユニット（味方ユニット）の動作はサブルーチンで実現できるが、
＞思考ルーチンは対応できない」ということです。

限界の存在と、それによって問題が発生することは間違いないと思います。

ただ、方針を決める段階では気が早いかと思っていたので書いていませんでしたが、
(親記事の内容の分かりやすさに自信がもてなかったせいでもありますが･･･)

この議論を、私案から出発して「特別な状態としては扱わない」方針で進めていくことになったのであれば、
その後は、その問題を発生させている「限界」を広げるために必要な機能拡張案を、
元の案に順次追加していきたいと思っています。

私案でかなり限界近くまで絞った(と思う)ので、
次は「現実的」な範囲でどこまで広げられるか、広げるか、を議論したいなと。

もちろん、私案よりも出発点として適切っぽい案があれば、そこから拡縮して行くことにしたいです。

○
ちなみに、思考ルーチンの問題についての私の解決案は

　案の方向１：CPUが各ユニットの行動させ始める直前に実行されるラベルの新設
　　　　　　(思考ルーチンは既存のものを用いる。詳細はサブルーチンで制御)
or
　案の方向２：CPUの思考ルーチンの自作機能を追加

です。
例によって、１はシナリオ作者の手間と負担が、２はKeiさんの手間と負担がかかる案ですね。
（方向１に関しては、既存の機能だけでも何とかかんとか代用できそうな気はするのですが･･･）

●
＞　早い話、これだけならば、現在進行中の他のリクエスト案「マップ上の特定ユニット・地点を取得するコマンド」
＞に「特定地点からの特定移動力範囲のマップ地点を選択するオプション」を追加するだけで実現可能だと思います。
＞しかもこの場合、イベント新設の必要はありません。

ええそのツリーも見ています。
実際、本ツリーを立て直す前に、そのツリーにオプションの追加提案を出そうかとも考えたんですが、
プレイヤーの操作を考えた場合、
「移動コマンドの拡張」という形でないと、通常の移動とユニットを重ねる為の移動が別々なユニットコマンドになってしまいます。
それは操作し辛いかなと思ったのでとりあえず私案のような形に。

今後「移動コマンドの拡張」を向こうに合流させるにしても、今度は別の機能追加を提案することになると思います。
また、上にも述べたとおり、方針決定後は私案に必要そうなものを追加していく方向を考えていますから、
少なくとも、現在進行中の他のツリーで進めている案への採用を前提としてしまうのはできれば避けたい所です。

向こうの意見交換が収束せずリクエスト自体行われない可能性はあるか無いかで言えば「ある」ですし、
オプション追加案が採用されない可能性がありますから。
向こうの議題の具体的なリクエスト仕様が、親記事以降曖昧な段階であれば尚更。

･･･タイミングが良いような悪いような、どうにも複雑な気分ですが。

対応としては、
・向こうのツリーが収束するまで待つ
・予想される結論に応じてとりあえず幾つか案を併記しておく
のどちらかあたりでしょうか。

現段階で完全合流することは考えていません。

○思い２について

色々考えていたら、この方針にはすごく後ろ向きな検討ばかりしたがる自分に気がつきました。なんてこった

散々考えて行き着いた私案とはかなり真逆に近い方針ゆえ、過剰に悲観的に見ている気もしますので、
その辺りも踏まえて読んでいただけるとあり難いかなと･･･。

＞　それでも、実現できたとき広がる世界は、大きい。

確かに大きそうにも思えるのですが、親記事に

>「ユニットが重なっている戦闘はこうなる」と規定されてしまうと、
>実装されたものが、利用すること自体は手軽ではあっても、細かい調整が利かずに使い辛いものになりそうな気がしてしまうので。
>
>既存のゲームにおいて複数のユニットが重なった状態の戦闘は、
>良く出る"小隊システム"だけに限らず、それぞれ独自のルールで行われますから、
>細かい仕様はシナリオ作者に任せた方が良いのではないかなとも。

と書いたとおり、現状で仕様を詰めてリクエストし、実装されたとしても、そこまで自由自在な仕様にはならない気がします。

それは、例えば戦闘のルール・仕様であれば、
複数のユニットでの戦闘は、現行の基本単体同士の戦闘システムを元にデザインされるだろうと予想するからです。
現行のものを元にしてしまえば、
必然的に、現行の仕様に拠る限界の多くもまた、複数のユニットでの戦闘の限界として存在し続けるでしょう。

そのため、広がる世界の広さという面では、細かい仕様を各シナリオ作者に決めてもらえる方が勝っているのではないかとも。
(もちろん手間と安定性などと引き換えに、でしょうけれど･･･)

とはいえ、この方向でのリクエスト議論(予備議論でも)をするべきでは無いとまでは思いません。

可能性が広がっても、それを活用するユーザーがいなければ広がった意味は薄いでしょう。(無意味ではないにしても)
逆に、どんな仕様でも実装されたらされたで、その仕様に合わせたシナリオを作れば良いと言えます。

そもそも、上を見たらキリが無いわけですし、どんなに自由自在に見えてもどこかしらに必ず限界は存在するわけですから、
結局、どこで妥協するか、という主観の問題とも言えます。
主観の問題であれば、「リクエスト案は、多数のユーザーが望む仕様がふさわしい」もダメな決め方ではありません。

ですから、この方針でのリクエスト議論が無駄だと思えませんし、する価値は存在すると思っています。
先頭切って積極的に推し進めたいかと言われると、多少迷いますが(笑)

なにせ、この方針で行く場合の個人的な「理想」は、
まず先に現行の仕様を十分に拡張してもらい、
その上で、シナリオ作者の裁量が広く取れるような形で、複数での戦闘(等)の機能の実装をリクエストする。
という流れが良いなー、とか思っていたりするので。
（･･･自分で書いててなんですが、さすがに先が長すぎて笑った鬼が顎を外すんじゃねーかな、とか。
　まーあくまでも理想ですから、こんなものかもしれませんが）

●
今回は以上です。

･･･さてはて、意見が少ないのは、機能に対するユーザーの興味の程度だったらどうしましょう。
とりあえず、文面の分かりにくさと仕切り役の人望＋時期の問題だと信じることにしてますがっ

えー、引き続きご意見等何かしらありましたらよろしくお願いします。
では。

引用返信/返信削除キー/

■5684 / inTopicNo.8)

　Re[2]: レスふたつ

▲▼■

□投稿者/ あかんべえ -(2007/12/29(Sat) 02:01:18) [ID:Odg8GJ46]

　ども、あかんべえです。

> 意見交換＆本体の更新が盛んであれば、本当はもっと夢見がちな案を私案にしたかった所なのですが(笑)
> 機能の実装を手伝えるわけでもないですし･･･

　あ、それは言えますね。VB5 は有料の企業ソフトの上、もう古くなりすぎてるので、今さら入手元を捜して修得するのは二の足踏んでます。
　重複を本格導入する方向、私も実はめちゃ長い目で見ていて、SRCの VB2000 など無料ダウンロード可能な基盤への移行＝実装作業者の増大を待たねばならんかも、とか考えてもいます。

> この議論を、私案から出発して「特別な状態としては扱わない」方針で進めていくことになったのであれば、
> その後は、その問題を発生させている「限界」を広げるために必要な機能拡張案を、
> 元の案に順次追加していきたいと思っています。
>
> 私案でかなり限界近くまで絞った(と思う)ので、
> 次は「現実的」な範囲でどこまで広げられるか、広げるか、を議論したいなと。

　当面の議論の方向としては、了解です。
　ただ、拡張することができるにしても、やはり、重複状態をシステムに直接組み込むこととの差は大きく、直接組み込みは長期課題として残り続けると思います。

> ちなみに、思考ルーチンの問題についての私の解決案は
>
> 　案の方向１：CPUが各ユニットの行動させ始める直前に実行されるラベルの新設
> 　　　　　　(思考ルーチンは既存のものを用いる。詳細はサブルーチンで制御)

　おおっ。実は私も、ほとんど同じことを考えてました。違いは、考えてたのは各ユニットの行動決定ルーチンの直前の動作タイミングだということ、ルーチン中の定数を操作可能な変数にしたり操作可能な係数を付け加えるなど思考ルーチンをちょこっと変更することです。
　まあこれは、議論するとしても別のツリー、別のリクエスト課題でしょうね。これはこれで汎用性が高いので。

> プレイヤーの操作を考えた場合、
> 「移動コマンドの拡張」という形でないと、通常の移動とユニットを重ねる為の移動が別々なユニットコマンドになってしまいます。
> それは操作し辛いかなと思ったのでとりあえず私案のような形に。

　「別々なユニットコマンド」になるのではなく、システム組み込みの「移動」コマンドが使われない、のだと思います。追加されるとすれば範囲内マップ座標を指定するオプションなので、どちらのタイプの移動にも対応できますから。

> 少なくとも、現在進行中の他のツリーで進めている案への採用を前提としてしまうのはできれば避けたい所です。

　了解しました。まあ、私が「合流」と言ったのも広い意味で、かたちは別々のリクエストでも中身は関連提案という場合も含んでいたのですが。その意味で、今でも有力案だと思っています――これは別便にて。

> >細かい仕様はシナリオ作者に任せた方が良いのではないかなとも。
>
> と書いたとおり、現状で仕様を詰めてリクエストし、実装されたとしても、そこまで自由自在な仕様にはならない気がします。

　この問題、あるいは「特別な状態として扱わない／扱う」「スタック可能／不可能」と表現されている対比について、私は二つの問題に切り分けて考えています。（論点整理の意味合いも込めて、ややくわしく書きます）

１．一つは、重複を本格導入するか、擬似的に表現するかという選択です。
　「本格導入」と言うのは、マス目内重複をＳＲＣのシステムに組み込む、ということです。もっと厳密に言えば、「同一マス目に複数の『出撃』ユニットを許容し、ＳＲＣの各種機能をこれに対応させる」ということです。
　ＳＲＣは「『出撃』中のユニットはマス目にせいぜい一つ」ということを前提に組み立てられているのだから、これは非常に大規模な改変にならざるをえない――これが、「重複」を考えるに当たって、まずこの選択が大問題になる理由です。

２．もう一つは、リクエストをめぐる発想の選択です。
(1)「何か特別なゲームシステムを導入する」リクエストをめざすか、
(2)「具体的なゲームシステムは導入せず、作者がゲームシステムを自由に追加できるような（汎用的な）機能」をリクエストするか、という違い。
　このツリーの話題では、小隊システム、スタックごとの移動、複数ユニットでの戦闘、スタック最上部ユニット破壊時の他のユニットの登場などが「特別なゲームシステム」です。

３．「１．」と「２．」は別々の選択です。
　つまり、「本格導入」かつ「２．(2)」もありえるということです。
　単にマス目に複数の「出撃」を許し、その影響を受ける機能の仕様を再調整するだけ、という方向です。この方向では、戦闘も従来どおり「一つのユニットが一つの目標を選択して戦闘する」だけで、目標選択時のインターフェイス問題はありますが、戦闘システム自体には何も追加されません。
　この場合、「擬似的に表現」かつ「２．(2)」の場合とくらべ、柔軟性・拡張性はほとんど違いがないと思います。
　既存の戦闘システムによって制約されるということも、同じです（戦闘システムの柔軟化もいずれは欲しいと思ってますが）。
　だからこの方向が否定されるとすれば、「本格導入」の困難性だけが理由になるだろう、と。

４．選択「２．」は、個々人の発想の違いもあり、ツリーでの意思疎通の問題でもあると思います。
　中箱さんや私は「２．(2)」の発想で、ついついこちらを前提として話を進めてしまいます。これが、読む人によっては説明不足になってしまうかもしれない。
　「(2)」の発想のリクエストが増えたのはこの１年ほどだけで、それまでずっと「(1)」タイプがリクエストの圧倒的大部分を占めていました。だから、「(1)」の発想が多数派だと思ってまちがいない。ということは、書き手にそのつもりがなくても、「この提案の具体的な、できあいの、すぐに使える、『魅力的な』、『利点』のあるゲームシステムは何だろうか？」という発想で発言を解釈されてしまうかもしれない、ということで、注意が必要だと思います。
　また、「(1)」の発想が強い方にもお願いいたします。いくつかの発言はまったく別の発想に基づくもので、特別なゲームシステムは何も付け加えず、ただそれを作るための「道具」だけを付け加えるリクエストだということを、ご理解ください。

> ですから、この方針でのリクエスト議論が無駄だと思えませんし、する価値は存在すると思っています。
> 先頭切って積極的に推し進めたいかと言われると、多少迷いますが(笑)

　了解しました。
　長期的な諸課題を頭に入れつつ、あくまで原案を基盤に検討を進める、といった線でしょうか。

引用返信/返信削除キー/

■5685 / inTopicNo.9)

　リクエスト目標の検討

▲▼■

□投稿者/ あかんべえ -(2007/12/29(Sat) 09:54:52) [ID:d5zOjiqE]

2007/12/30(Sun) 00:02:37 編集(投稿者)

　あかんべえです。このカキコでは、原案の「目標」を検討させてもらいます。

> ○他のユニットが存在するマスも、(ある条件下では)移動先に指定可能になる。
>
> ○ただしあくまでも、1マスに複数のユニットは存在できないままで、
> 　ユニットが重なりそうな場合の扱いは
> 　　・移動できない（従来の仕様と同じ）
> 　　・下になるユニットはEscapeと同様の扱いとなる。(もしくはEscapeさせ、必要に応じてサブルーチン制御でもとの位置に戻す)
> 　　・元いたユニットは隣接マスに強制移動させられる
> 　などなど、これに限らずシナリオ作者が(サブルーチンを用いて)独自に設定する。
>
> ○戦闘に関しては基本的に変更無し。必要であれば必要に応じてAttackコマンドなどを用いて再現してもらう。
>
>
> 具体的なリクエスト内容としては、
> 　移動先の選択肢の拡張＋移動先を選択した時に実行されるようなイベントラベルの新設
> のような感じになるでしょうか。

１．「目標」の矛盾
　ひとつすっきりしないのは、「細かい仕様はシナリオ作者に任せた」というのを通り越して、「細かい仕様をシナリオ作者が付け加えないと、動作しない」仕様になってるということです。ここには、移動先指定の機能でありながら、とりあえずの移動処理も完結してないという矛盾があるように思います。

　これを解決するには、二つ方法がありそうです。

Ａ案：目標をさらに絞り込み、「ユニットのいるマス目を含め、移動力範囲のマップ座標を指定する機能」に絞ること。
　要するに、以前から議論していた他のツリー関連の機能になりますが、一応独立したリクエストという方向で。
　この案の欠点は、
(1) 既存のユニットコマンド「移動」が浮いてしまう。
(2) 「スタックを（擬似的にでも）実現する」という終局目的からますます離れてしまう。採用シナリオの減少という結果をまねくので、この要素はけっこう重要かも。

Ｂ案：とりあえず「ユニットが重なりそうな場合の扱い」として挙げられた例の一つ（「移動できない」はいろいろふつごうがありそうですが）を実装する。ただし、サブルーチン設定などで作者が修正可能であること。
　この場合、必要な追加機能がいくらか増えそうです（後述）。
　修正しやすい選択は Escape（離脱）処理でしょうか？

２．副次目標
　原案・Ａ案・Ｂ案いずれの場合も、ユニットの「離脱」・「出撃」状態間の入れ替え処理が多用されそうです。そのため、

＊　特定座標に「存在する」（つまり、特定座標データを保持している）「離脱」状態のユニットを知る機能が欲しいです――自動で Escape される案（Ｂ案でデフォルトがEscape処理の場合）では不可欠、他の案では Escape 処理時に変数データを設定すればなくても何とかなりそうですが、煩雑すぎる気がします。

３．「移動先を選択した時に実行されるようなイベントラベル」の動作タイミングなど
　移動戦闘を考慮に入れると意外と複雑で、きっちり決めといたほうがよいと思います。

　Ａ案の場合は、このイベントラベル自体が不必要です。そのかわりシナリオでユニットコマンドを設定する必要があり、また、移動戦闘ができるようルーチンを組めばなりませんが。

　移動戦闘は攻撃目標が確定するまでクリア可能ですから、タイミングはそれより後でなくてはなりません。また攻撃実行後にユニットの状態や位置が変わってしまうのはまずいので、それ以前でなくてはならない。
　したがって、Ｂ案の場合、攻撃目標確定直後、攻撃実行直前が唯一のタイミングになると思います――それでも、イベントでの処理によってはおかしなことになる可能性はありますが。
　一番やっかいなのは原案の場合です。該当ユニットと目標地点にいるユニットの状態が未定のまま、攻撃目標確定まで持って行かねばならないので。
　それとも、「擬似スタックする移動では、移動後戦闘不可」とすべきでしょうか？　制限が増えてしまいますが。

　今のところ思いついたことは以上です。

引用返信/返信削除キー/

■5686 / inTopicNo.10)

　Re[1]: 複数のユニットが重なっている状態を可能にする機能追加案について

▲▼■

□投稿者/ ナマモノ -(2007/12/29(Sat) 16:43:08) [ID:d5YcKxwJ]

「重複」という言葉とにらめっこしていたような感覚に襲われた、ナマモノです。

根底を揺るがすような書き込みで申し訳ないのですが、そもそも
『自分が選択して、その後に移動・攻撃・アビリティ使用などを行う味方ユニットが、一マスに何体も重なる。
もしくは重ならせることが前提』となっている「実例」を示したり、説明みたいなものがないと
いくら作者ごとにシステムを自在に設計できるものを最終目標にすると言われても、個人的に
ピンと来ないのが本音です。
細かい仕様はシナリオ作者に任せられるようにするなら、数種類の「ユニットが１マス以内に存在できるシステム」を
例示した上で、それの簡単な作り方みたいなものを示しながら固めるべきではないか？
と、私自身は考えるのですがどうでしょうか。

あと、個人的には「ユニットを重複できる」という仕様よりも、スーパーロボット大戦で採用された小隊システムや、
バハムートラグーンで行えた、チームをキャラを選んで編成した後に、そのチームを１つのユニットとして動かしていく、
「ユニットを1つに纏め、動かせる」ことができる仕様のほうがまだイメージが沸いたりします。
纏めることが出来る仕様へと選択肢を絞ると、自在性は確かに落ちるかもしれませんがこちらの方が
まだSLGやS・RPGというジャンルの中でもモデルが多く、そこから話を膨らませるのが楽そうなのですがどうでしょうか？

ちなみに、複数のユニットが1マスに複数存在できるようになる仕様に関しては反対はしておりません。
気に入った沢山のキャラが沢山の敵に立ち向かうというシチュエーションに憧れる身としては、
通ることを祈っております。

それでは…

引用返信/返信削除キー/

■5693 / inTopicNo.11)

　完全な横道になるかもしれませんが。。。

▲▼■

□投稿者/ マガツ -(2007/12/30(Sun) 13:48:23) [ID:CkQwkdvv]

こんにちは、マガツです。

＞ちなみに、思考ルーチンの問題についての私の解決案は
＞
＞　案の方向１：CPUが各ユニットの行動させ始める直前に実行されるラベルの新設
＞　　　　　　(思考ルーチンは既存のものを用いる。詳細はサブルーチンで制御)
＞or
＞　案の方向２：CPUの思考ルーチンの自作機能を追加
＞
＞です。
＞例によって、１はシナリオ作者の手間と負担が、２はKeiさんの手間と負担がかかる案ですね。
＞（方向１に関しては、既存の機能だけでも何とかかんとか代用できそうな気はするのですが･･･）

方向１に関してですが、既存の機能でも敵の行動順序を把握できれば一応は可能です。

１．敵ユニットの行動順を行動順管理変数に入れる。
２．敵ユニットが破壊されるたびに行動順管理変数を最適化する
３．敵のターン開始イベントにて、行動順管理変数から最初に動くユニットを調べ、行動ルーチンを決定。
４．敵の行動終了イベントにて、
　ａ．行動回数が１以上なら自分に
　ｂ．行動回数が０なら、行動順管理変数から次に動くユニットを調べ、
　行動ルーチンを決定。

ただし、再行動アビリティや再行動イベントが絡むと破綻しますが。

ノシ

引用返信/返信削除キー/

■5694 / inTopicNo.12)

　Re[3]: 完全な横道になるかもしれませんが。。。

▲▼■

□投稿者/ あかんべえ -(2007/12/30(Sun) 15:54:43) [ID:6kALhJFF]

　すみません。これも完全な横道です。

> 方向１に関してですが、既存の機能でも敵の行動順序を把握できれば一応は可能です。
>
> １．敵ユニットの行動順を行動順管理変数に入れる。
> ２．敵ユニットが破壊されるたびに行動順管理変数を最適化する
> ３．敵のターン開始イベントにて、行動順管理変数から最初に動くユニットを調べ、行動ルーチンを決定。
> ４．敵の行動終了イベントにて、
> 　ａ．行動回数が１以上なら自分に
> 　ｂ．行動回数が０なら、行動順管理変数から次に動くユニットを調べ、
> 　行動ルーチンを決定。

　いや、それはわかっているし、中箱さんもそうだと思うんですが、あまりに迂遠で非効率だと思うのですね。
　「１．」は、本体にそのルーチンがあるのに、わざわざイベントを組み立てて別途に算出するわけだし。
　最後の「行動ルーチンを決定」のところも、攻撃目標の優先順を変えるには行動ユニットではなく味方ユニットのほうに手を入れ（美しくないよ～）、一時的に装甲を付けたりせにゃならず、終わってから逐一、元に戻すことも必要。
　おまけにこれは、バグがあっても、本体のバージョンアップで不適切になっても、極めつけにわかりにくそう。
　てなわけで、私自身、どうにもサブルーチンを作る気になれないのです。

引用返信/返信削除キー/

■5702 / inTopicNo.13)

　年またぎレス

▲▼■

□投稿者/ 中箱 -(2008/01/04(Fri) 15:50:13) [ID:8NrUE61r]

年明け前に一度レスをするつもりだったのに、なぜかニュースでは仕事始めとか言ってますね･･･
どうも明けましておめでとうございます。中箱です。

レスが溜まったまましばらく止めてしまいましたが、年末年始だったということでご勘弁をー。

●
>あかんべえさん

論点の整理など、ありがとうございます。
先走ってたなぁとか無意識に混同してたなぁとか、色々気がつきました。助かります

ただ、意見交換はまだ
＞１．一つは、重複を本格導入するか、擬似的に表現するかという選択です。
＞２．もう一つは、リクエストをめぐる発想の選択です。
の所を続けるべき段階かと。

私とあかんべえさんの意見は大まかに一致していても、
意見を出す以前の段階で迷われている方が少なくとも複数レスをされているのですから。

具体的には、小一郎さん、ナマモノさんに、･･･私の説明がアレなため、この意見交換の意図・目的などを満足に伝えることができていないように思います。
これは、今はまだ意見交換を始められる状態ではない、ということでしょう。

･･･現在、親記事に当たるものを書き直していますので、それまで今しばらく議論を進めないようにお願いします。

ということで、No5685についての細かいレスも、すいませんが、原案を詰める段階になってから必要であれば改めてということで。

以下、やや横道となる箇所に関してのレスです。

No5684の
○
＞　重複を本格導入する方向、私も実はめちゃ長い目で見ていて、
＞SRCの VB2000 など無料ダウンロード可能な基盤への移行＝実装作業者の増大を待たねばならんかも、とか考えてもいます。

そもそも基盤を移行するのかどうかについての明確なアナウンスはなかったと思うので（情報として出ているのは「検討してみる」までだったような？）
私としては、「リクエストして、実装してもらう」を前提に考えています。

○
>思考ルーチン関連
＞　まあこれは、議論するとしても別のツリー、別のリクエスト課題でしょうね。これはこれで汎用性が高いので。

私も、それが妥当かなと。
当初は親記事に書いた私案に含めてしまおうかとも思ったのですが、
ちょっと含めるには大きすぎるかなと思って外した件だったりもしますし。

○
＞> 「移動コマンドの拡張」という形でないと、通常の移動とユニットを重ねる為の移動が別々なユニットコマンドになってしまいます。
＞　「別々なユニットコマンド」になるのではなく、システム組み込みの「移動」コマンドが使われない、のだと思います。

使われないとしても、「移動」コマンドは表示されてしまうので、
通常の「移動」コマンドと、重なることが可能な「移動改(仮)」コマンドの、両方が表示されることになります。
完全に下位互換なコマンドが表示されてしまうのは、プレイヤーに不親切かな、と。

･･･まあ、通常のユニットコマンドを任意で非表示にできればそれで良いのですが、できませんし。

○
＞　長期的な諸課題を頭に入れつつ、あくまで原案を基盤に検討を進める、といった線でしょうか。

おそらく
> ですから、この方針でのリクエスト議論が無駄だと思えませんし、する価値は存在すると思っています。
> 先頭切って積極的に推し進めたいかと言われると、多少迷いますが(笑)
この部分で誤解されたのでしょうけれど、

これは最初のレスの
＞・　とりあえず現実的な、「移動先の選択肢の拡張」リクエストとしては、他のリクエスト案との統合を
＞・　長期的な目標として「ユニットの重ね合わせ」の議論の継続を
の「両方を今後の方針として採用すると決定した場合」を仮定した上での発言だったのです。

前回レスは、その辺りが全く明確ではありませんでした。すいません

●マガツさん
あかんべえさんに早々と代弁されてしまいました。レスが遅くなってすいません。

＞＞（方向１に関しては、既存の機能だけでも何とかかんとか代用できそうな気はするのですが･･･）
＞方向１に関してですが、既存の機能でも敵の行動順序を把握できれば一応は可能です。

代弁されてしまった通り、「可能だろうな」とは思っていました。
「何とかかんとか代用」というえらく曖昧な表現を使ったのは、脳内でプロセスを考えていただけで、敵の行動順序を把握する最初期段階すら実際に試していなかったからです。
思考のみでも大きめの穴が幾つか見えていて、実際に組むとかなり面倒なのも予想できていました。

そういうものを試し組みすらせずに「可能だ」と断定したくなかったので、あんな歯切れの悪い表現になった、とまあそういうわけでして。
いや、まさか、そこにアドバイスが来るともまさか。

個人的には(ツリー的には横道話題であっても)、思考ルーチン自作に関しては結構前からちょくちょく思考だけしている案件だったりしまして、
やっぱり発想は大体間違っていないんだな、ということが分かっただけでも嬉しかったりします。

･･･と、そろそろ横道もとい言い訳すらぶち抜いて私信になっているのでこの辺で。

わざわざありがとうございました。

●ナマモノさん
分かり辛い親記事ですいませんでした。

＞根底を揺るがすような書き込みで申し訳ないのですが、～

具体例を挙げることで視野を狭くしてしまうことが嫌で、具体的なものはついつい避けてしまっていたのですが、
その結果、抽象的過ぎて理解困難なものになってしまっては逆効果でしたね･･･。

ご指摘の点を踏まえて、親記事に当たるものを書き直して再提示しようと思っています。
今後も、提示したものに相変わらず問題が見られるようでしたら、遠慮なくお願いします。

ありがとうございました。

引用返信/返信削除キー/

■5721 / inTopicNo.14)

　(20日AM2時ごろ修正有)目標・方針等再提示

▲▼■

□投稿者/ 中箱 -(2008/01/19(Sat) 20:13:33) [ID:TdSzoAHN]

2008/01/20(Sun) 02:18:27 編集(投稿者)

#イベントコマンドなのか、ユニットコマンドなのかが紛らわしい箇所を修正しました。

まただいぶ空きました。中箱です。

●
まず、議論の目標、到達点の再確認から。

最終的には
「複数のユニットが一つのマスに存在し、一塊になって行動(戦闘など)を行う」ことが、何らかの方法で可能になるような機能拡張案
を目指したいと考えています。
（以下、「複数のユニットが一つのマスで重なって、一塊になって行動できる状態」を、「グループ状態」呼びます）

例えば、SRW二次＆三次αにおける小隊システムや、SDガンダムGジェネレーションシリーズ(の一部)におけるスタック制
…などの再現が容易になるような機能拡張案、と考えていただければ。

"何らかの方法で"　ですので、案の内容は
　・本体機能として「グループ状態」が完全にサポートされるような新機能の仕様案
でも
　・単体では「グループ状態」を実現できない、いくつもの新機能(イベントコマンドや関数、ラベル、状態など)
　　からなる案（新機能を用いたサブルーチンを利用することで実現が可能となる）
でも良いということです。もちろん両方が混じったようなものでも

また、あくまでも"最終的に"ですので、一度に全部をリクエストするには限らず、
案が切り分け可能であれば、それぞれ個別にリクエストしても良いでしょう。

同時に、実現できる「グループ状態」の仕様はシナリオ作者による調整幅が広いものであって欲しい所です。
（小隊システムとスタック制を比べるだけでも、ずいぶん仕様は違いますし。
　個人的な意見としては、例えば「小隊システムを実現するためだけの新機能」のように拡張性に乏しそうな機能ではイマイチだなとも）

●
まず、「グループ状態」の実現には
　・「グループ状態」の場合、どのようなルールで戦闘が行われるか
はもちろん必要ですが、同時に
　・どのようにして「グループ状態」を作成するか
も無くてはなりません。

さて、既存のSLGやSRPGの中にはユニットを「グループ状態」にすることが可能なものがあるわけですが、
私が思いついた主なものとしては

　１．「第二次＆三次SRWα」の小隊システム@PS2
　２．「バハムートラグーン」@SFC（スクウェア）
　３．「SRWOGs」のツインユニット@PS2
　４．「SDガンダムエモーショナルジャム」@WS 及び「Gジェネレーションシリーズ(WS･GBA･DS版)」のスタック
　５．「ポケットキング」@GBC、「サモナーズリネージュ(多分テイルズシリーズのうち)」@GBA（ナムコ）

あたりが「グループ状態」が存在するものに該当するでしょう。
（"主な"の割に一部微妙なマイナーゲーが混じってますがまあ）

　　※注：２についてはうろ覚えなので間違いがあるかも。
　　　　　３にはOG外伝も入るかもしれませんが、未プレイなので割愛。

ここで、"どのようにして「グループ状態」を作成するか"　に着目し、
これら１～５のそれが、今のSRCの機能で実現可能かどうかという面から見てみると

○１＆２
　これらにおける「グループ」はインターミッションで作り、マップ中での組み替えは原則として不可能です。
　インターミッション中であれば、サブルーチンでグループの組み換えシステムを再現することは十分に可能でしょう。
　（もちろん、既存のイベントコマンドによるサブルーチンではなくて、グループを作成するためのインターミッションコマンドの新設を案に含めるのもアリだと思いますが）

これに対して、３～５はマップ中で「グループ」の構成メンバーを変更させる事ができますし、変更する事が前提で作られています。
○３
　「グループ」の作成＆解散はユニットコマンドで実行するものですので現状で再現可能かと。
○４＆５
　問題はこれらの場合です。
　これらの作品における「グループ」は、
　　"すでに味方ユニット(グループ)が存在するマスに、他の味方が移動先に指定して進入する"
　ことによって作成されます。

　この　"すでに他のユニットがいるマスを(移動先に)指定する"　を、現行の機能で再現することは
　（不可能では無いと見ていますが）かなり難しい、というか面倒な事です。

●
そこで、目標である
「複数のユニットが一つのマスに存在し、一塊になって行動(戦闘など)を行う」ことが、何らかの方法で可能になるような機能拡張案
の手始めとして何がもっとも良さそうかと考えた結果、
まず上の４＆５に見られる
　"すでにユニットがいるマスを指定する"
機能を実現するような案から手をつけてはどうかなと。

なぜそこからか、という理由については、

　・「グループ状態」での戦闘ルール部分は、論点が膨大である事が予想され、議論が長引くであろうこと。
　・戦闘を「グループ状態」の場合に拡張するよりも、援護行動など、先に拡張しておくのが望ましそうなものがあること。

という点から、戦闘周りは、手の付けはじめとして適切では無いと考えるからです。

○
また、　"すでにユニットがいるマスを指定する"　ことが可能になれば、
「グループ状態」とも、既存のものとも違ったゲーム性を持つシナリオを作る（既存のSLG,SRPG再現の助けになる）ことが可能になるでしょう。

既存のSLG,SRPG、と書きましたが、それは
グループ状態にはならないが、　"すでにユニットがいるマスに進入を試みる"　ことが許されているものです。

例えば、
　「ガシャポン戦記１～４」@FC、ディスクシステム(バンダイ)　などでは(ずいぶん古いゲームですが…)
"敵対勢力の存在するマスに進入を試みる"　ことで戦闘が発生します。
(戦闘そのものはアクションであったりコマンドバトルだったりしますが。
ちなみにこのシリーズの場合、グループ状態にはなりませんので、戦闘後は侵入した側・侵入された側双方が一定のルールによって必要であれば再配置されます。

また、
　「ファミコン・ゲームボーイウォーズシリーズ」等においては、
同じ種類の味方ユニットが存在するマスに進入する事で、二つの部隊ユニットを一つの部隊に合体させる事が可能になっています。
　　（※ファミコンウォーズシリーズのGBA以降のものには触れてませんが）

●
"すでにユニットがいるマスを指定する"　ことを実現するための具体案ですが。

私案としては

　・指定したユニットが、指定した座標に(、指定した移動方法で)、次の移動で到着可能であるかどうかを返す関数「Reach(仮)」
　　（オプションとして、指定座標に味方/敵がいても、その座標のユニットのみ無視するようなものを設定可能にする）

　・指定したユニットが、指定した移動方法で移動しようとしたときの移動可能範囲を表示する（+マップ上をクリックで座標取得）イベントコマンド「ShowMoveRange(仮)」
　　（※これは、現在別ツリー(No5638～)にて意見交換が行われているAppointコマンド案に追加してもらうように提案するのもアリかも）

　・デフォルトで表示されてしまうユニットコマンド（移動、攻撃、スペシャルパワー、特殊能力一覧、武装一覧など）を、強制的にユニットコマンドに表示させないようにする
　　非表示特殊状態の新設、もしくはDisableコマンドあたりの拡張。

のような感じのものを考えています。

この案は、"すでに他のユニットがいるマスを(移動先に)指定する"　を可能にすることが元の目的だったわけですが、
　既存の移動コマンドの拡張
という形はではなく、
　関数、イベントコマンド、特殊状態の拡張・追加等
という内容になっています。

そのため、これらだけでは「グループ状態」は実現できません。
けれどもこれらは「グループ状態」を実現するためには役立つものです。
それに、移動コマンドの拡張であれば移動以外には使えませんが、関数・イベントコマンドであれば、それを各種イベントラベル内で利用する事ができます。

また、現状では移動関連の情報を得るイベントコマンドや関数が殆ど存在しません。

例えば、ユニットの今の移動可能範囲がどうなっているかは、移動コマンド(味方)や移動範囲コマンド(味方以外)によってプレイヤーは確認できます。
しかし、その表示を強制的に表示させることも、指定した地点への移動の可否をシナリオ側で参照することも不可能になっています。
もちろんサブルーチンを組めば同様の情報を得ることは理論上可能でしょうけれど、(繰り返しになりますが)かなりの手間が予想されます。

つまりプレイヤーが普通に確認できる情報を得るために、シナリオ側は複雑なサブルーチンが必要なわけで、これには違和感を感じます。

プレイヤーが確認できるのですから、基本的に特別新しい機能ではありません。
ですから、その情報を取得・表示するためのイベントコマンド・関数を実装する手間という面においては、まったく新規の機能を追加する場合に比べれば少なくて済む……んじゃないかな、と。
…まあ、この実装の手間に関してはあくまでも予想と希望的観測なのですが。

以上が、上のような形の私案となっている理由です。

●
えー、長いですし、出発点と提示した私案がかけ離れているようにも見えてしまいますので、
最後に短くまとめておきます。

☆「グループ状態」を実現することを目指したい。（とりあえずの最終目標）
☆「グループ状態」を実現するためには、　"「グループ状態」はどういう動作をするのか"　と、　"どうやって「グループ状態」を作るのか"　の両方が必要。
☆「グループ状態」の動作についての議論よりも先に　"「グループ状態」を作る"　部分から考えたい。
☆ "「グループ状態」を作る"　ためには　"すでにユニットがいるマスを(移動先として)指定する"　新機能が欲しい。
　　☆"すでにユニットがいるマスを(移動先として)指定する"　機能があれば、「グループ状態」以外のシステムの再現なども可能になる。

☆ "すでにユニットがいるマスを指定する"　ための私案としては、関数・イベントコマンド・状態の追加＆拡張を。（議論の開始点？）
　　☆案が、素直な　"移動コマンドの拡張"　ではなくて、　"関数やイベントコマンド"　で構成されているのは、
　　　　一、その方が、実装された場合の応用範囲が広くなるから
　　　　二、現状、シナリオ側で移動関連の情報を得て利用することができないから
　　　　三、プレイヤーは確認できる情報なので、実装の手間が、まったくの新機能に比べれば軽いだろうと予想するから
　　　などの理由から。

以上のような感じになります。

●
いまだ分かり辛くなっている点や、内容についての意見等ありましたらよろしくお願いします。
では。

引用返信/返信削除キー/

■5724 / inTopicNo.15)

　グループ編成の為のコマンド拡張について

▲▼■

□投稿者/ 乾 -(2008/01/20(Sun) 01:19:56) [ID:FGrzbgFn]

　乾です。

　ユニットの合流のみを主眼に置くのでしたら、

・移動前or後に、合流可能なユニットが隣接している場合のみ、合流を
　するためのユニットコマンドを表示するようにユニットコマンドの条件式を作る
・隣接可能なユニットが複数存在する場合、あるいは合流先を再確認するために
ユニットコマンド内でHotPointコマンドなどを使用して最終的に合流するユニットを
クリックさせる。

　という２段階の手で、現状の機能でも「合流先の座標orユニットID」を取得することは可能です。
　（隣接後にコマンドを表示するタイプのSLGでは良くある形式ですし、SRW-OGのツインユニットシステムもこの形式です）

　なので、既存の移動形式を封印して、合流専用のコマンドで移動させるようなことはしない方が
プレイヤー的に分かりやすい機能になると思うのですがいかがでしょう？

引用返信/返信削除キー/

■5725 / inTopicNo.16)

　表現にミスがありました

▲▼■

□投稿者/ 中箱 -(2008/01/20(Sun) 02:12:55) [ID:jwikVFnr]

2008/01/20(Sun) 02:35:28 編集(投稿者)

>　合流専用のコマンドで移動させるようなことはしない方が

「合流専用のコマンド」のようなものは含んだつもりは無かったのですが。
……イベントコマンドなのか、ユニットコマンドなのかが一部紛らわしかったようですね。

No5721で単に「コマンド」と書いてあったものは、全てイベントコマンドの事です。ユニットコマンドではありません。

すいませんでした、その点修正しておきます。

せっかくいただいたご意見ですが、誤解があるまま進めるのは危険ですので
内容に関してのレスは、修正したものでも基本的にご意見が変わられないのであればその時に改めて、とさせていただきたいと思います。

では

引用返信/返信削除キー/

■5726 / inTopicNo.17)

　Re[4]: 表現にミスがありました

▲▼■

□投稿者/ 乾 -(2008/01/20(Sun) 02:52:56) [ID:FGrzbgFn]

　乾です。

　修正版を確認しましたが、やはり意見としては変わらないです。

　シナリオ作者が新機能を盛り込みやすくするために、イベントコマンドの拡張を行うのが目的だと思うのですが
具体的にシナリオ作者がどのような実装を行うのか、の具体例を提示しないままに
応用が利く方法を　とやっている間は、具体的な実装を決めるのは困難だと思われます。
　
　なので、とりあえず今回の目的の一つである、合流の判定の方法を提示してみたわけなのです。

　それと、移動後にユニットコマンドを使用して合流を計る判定の方が、
提示されていたReachコマンドやShowMoveRangeコマンドを使用するより、
シナリオ側での実装が簡単になるのではないかと、思っているのですが
いかがでしょう？

（移動後に隣接ユニットの情報を調べて、選択対象となるユニットを
シナリオサイドでチェック、合流可能か否かを判定後、可能ならば
ユニットコマンドを表示し、移動先としてHotPointで選択先として
表示を行う、という形で実装イメージが出来るのですが、
提示されたShowMoveRangeコマンドのイメージですと、
「選択することが出来ないユニット」を
あらかじめ除外するなどの実装イメージが出来にくいですし、
様々な移動手段を持つユニットでの合流をさせるコマンドを
プレイヤーにどのように見せれば良いかなどの判断が煩雑になると思われます）

　あるいは、ユニットコマンド式にした場合でもあった方が便利な機能は
あるのかも知れませんが、現在提示されているイベントコマンド案では
グループ化を目的とするならば遠回りな方法を探っているように見えます。

引用返信/返信削除キー/

■5730 / inTopicNo.18)

　現状での合流再現

▲▼■

□投稿者/ 乾@汎用データ -(2008/01/21(Mon) 23:16:15) [ID:KPaseBs2]

2008/01/21(Mon) 23:20:00 編集(投稿者)

　乾です。

　隣接時のユニットコマンドで合流を再現するためのシナリオを作成してみました。
（http://drydog.hp.infoseek.co.jp/JoinTest.zip)

　移動・ジャンプ・テレポートの３通りの移動の後の隣接時に、隣に
合流可能なユニットが存在する場合のみ、合流コマンドが選択可能になり
合流先を指定するという仕組みです。

　ShowMoveRange(仮)の案ですと、移動種別毎に範囲が変わってしまいますし、
選択できないユニットを除外する等の処理が帰って煩雑になりそうです。

　ということで、グループ化の為の移動先指定では現状のユニットコマンドで
十分ではないかと思うのですがいかかでしょうか？

(ただし、Reachコマンドなどは他の用途が期待できます(敵ユニットの思考ルーチン制御など)ので、グループ化とは切り離して、仕様を整理してみるのも良いかも知れません、
どちらにせよ、完全にシナリオ作者に使用方法を任せっきりにするのではなく、具体的な使用方法を提示した上でなければ仕様はまとまらないと思いますが)

　それでは

引用返信/返信削除キー/

■5737 / inTopicNo.19)

　Re[6]: 現状での合流再現

▲▼■

□投稿者/ 中箱 -(2008/01/28(Mon) 00:26:40) [ID:TdSzoAHN]

前ツリーから読み返して、乾さんのNo5654の内容について触れていなかったことに(今更ながら)気づきました。
内容的にも無視したような形になっていました。話がさっぱりかみ合わないわけです、すいません。

ただ、私には乾さんが結局何を言いたいのかが見えません。
一貫して
　・私の5721の内容では説明不足である
　・同記事で示した私案は、議論の出発点として適切ではない
という2点が含まれていることは分かるのですが、
それだけではなくてもっと色々明示されていないものが含まれているようでもあり、私の考えすぎかもしれず。

●
・・と、疑問なところ、不明な点が色々ありすぎて一向にまとまらないので、

とりあえず今回は食い違いの根本に近そうなところのみを。

No5654で
＞単体のコマンド追加・仕様変更から話を始めるのではなく、
＞ゲームをプレイするに当たってどのようにプレイヤーに操作させるのか、
＞また同一スクエア内のユニットへの攻撃選択はどういう風になるのかなど、
＞より上階層のイメージをまとめるところからの仕切直しをしてもらいたいと思います。
と書かれていることと、一連のご意見を読む限り、

明記されていない乾さんご自身の中の大前提として、
「単一の方法を"実装として決め"た上で議論を進めなければならない」
というものがあるようにお見受けします。

そしてそのような大前提の下に、
「グループはテストシナリオのようにマップ上で作る。それ以外の方法ではグループは作らない」ことを前提として議論を進めるべきだ
と、主張されているのだと。

ですが、
少なくとも「どうやってグループ状態を作成するか」の部分に関して、
具体的な　"実装を決める"　ことは、議論の開始のために不可欠でしょうか？
なぜ具体"例"ではなく、　"実装を決め"　なくてはならないのでしょう。

おそらく「実装を単一のものに決めることでイメージをまとめるのだ」ということだとは思いますが、
そもそも　"実装を決める"　ことは、基本的には議論を狭める事に繋がります。
ある程度絞ることは必要かもしれませんが、単一のものにまで絞ってしまうのはいくらなんでもやりすぎかと。

それでもなお、乾さんが考える、単一に絞らなければならない理由とは、一体何なのでしょうか？
私には「ツリーを見る人にとっての分かりやすさ」以外には、わざわざ絞りきって議論の幅を狭めてしまう理由が考え付かないのですが。

引用返信/返信削除キー/

■5763 / inTopicNo.20)

　Re[7]: 現状での合流再現

▲　■

□投稿者/ 乾 -(2008/02/03(Sun) 02:00:59) [ID:KPaseBs2]

　乾＠汎用データです。

　他のツリーの更新で下に流れていたのか、レスされていたことに気が付きませんでした、申し訳ありません。

　はっきりと言えば、「使い勝手の悪い機能が追加されるのを防止するため」です。

　検討の段階でシナリオで具体的にどのようなコマンドを組み合わせて使う物なのかの
イメージが固まらない状態では、そのコマンドを実際に使用する際の問題点の
洗い出しなどが行えないため、明確な目的が見えないまま
「なんとなくこれがあったら便利じゃないか」程度の機能が追加されてしまう恐れがあります。

　それ故に、まずシナリオでどういう場面で使うのかを提示出来ていないままでの進行を
食い止めようとしているのが、一連のレスの目的です。

　そして、このツリーの目的はユニットが既にいるコマに進入するときのコマンドの
実現をする事なので、それをシナリオで実装するとどうなるかのイメージを提示し、
現状の機能で実現可能なので、もっと他の部分を検討するのが優先ではないかと
理解して欲しかったと言うことなのです。

　ただ、「何となく便利になるかも知れない機能」を増やすことが目的だとしたら
これ以上意見する事に意味はないので、これ以上はこのツリーに参加することはないと
思います。

　それでは

引用返信/返信削除キー/

次の20件＞

トピック内ページ移動 / << 0 | 1 >>

[このトピックに返信]

HOME HELP 新規作成新着記事トピック表示検索新着情報過去ログ

- Child Tree -
- Antispam Version -