ＳＲＣ意見交換掲示板Mk2
(現在 過去ログ45 を表示中)
HOME
HELP
新規作成
新着記事
トピック表示
検索
新着情報
過去ログ
[
最新記事及び返信フォームをトピックトップへ
]
[ トピック内全9記事(1-9 表示) ] <<
0
>>
■5031
/ inTopicNo.1)
戦闘前の武器選択画面において
▼
■
□投稿者/ はる
-(2006/06/30(Fri) 00:55:46)
[ID:jRgvOdEO]
戦闘前の武器選択画面。
援護攻撃可能なユニットが存在する場合は援護攻撃の有無を選択できるようになっていますが、
そこにシナリオ製作者が任意に選択肢を記述できればいいなと思うのですがどうでしょう？
記述方法としては、以下のようなものを考えています。
-----------------------------------------------------------------------
戦闘オプション 機能 選択肢1 選択肢2 [連動する他の機能(複数可)]:
…
Switch
Case 選択肢1
…
Case 選択肢2
…
EndSw
…
Exit
-----------------------------------------------------------------------
「選択肢1」と「選択肢2」には武器選択画面に表示される文字列を記述します。
「選択肢1」が選択された状態で戦闘を開始した場合、イベント内の「Case 選択肢1」が
実行されます。「選択肢2」の場合も同様です。
「連動する他の機能」には、「機能」の「選択肢1」を行うときに、「選択肢1」を行いたくない
「他の機能」を記述します。
デフォルトでは「選択肢1」が選択されますが、「連動する他の機能」が存在し、
かつその機能が先に「戦闘オプション」イベントで指定されている場合には、
「選択肢2」がデフォルトとなります。
「連動する他の機能」に援護攻撃が選択された場合にも、「選択肢2」がデフォルトとなります。
例として、スパロボＭＸの「援護攻撃」、「支援攻撃」、「ダブルアタック」の関係を
再現する場合について以下に示します。
--------------------------------------------------------------------------
BattleOption 支援攻撃 使用する 使用しない 援護攻撃 ダブルアタック:
…
Switch
Case 使用する
…
Case 使用しない
…
EndSw
…
Exit
BattleOption ダブルアタック 行う 行わない 援護攻撃 支援攻撃
…
Switch
Case 行う
…
Case 行わない
…
EndSw
…
Exit
--------------------------------------------------------------------------
使用例としては、スパロボＭＸの「支援攻撃」や「ダブルアタック」、
携帯機版スパロボの「コンボ」、スパロボＪのストライカーパック等が再現出来、
他にも応用が利くのではないかと思います。
ここで、「インクルードを使えば再現可能では？」とも考えられますが、
現状では援護攻撃が絡んでしまうため再現は難しく、
「じゃあ、攻撃イベントで援護攻撃ユニットＩＤを参照すれば…」と試しても、
同イベント内では援護攻撃の有無に関係なく、ＩＤ内は空っぽか1つ前の
援護攻撃ユニットＩＤが格納されています。
そのため、このような機能があればと考えています。
引用返信
/
返信
削除キー/
編集
削除
■5097
/ inTopicNo.2)
Re[1]: 戦闘前の武器選択画面において
▲
▼
■
□投稿者/ はる
-(2006/07/09(Sun) 22:30:42)
[ID:jRgvOdEO]
もう少し待ってからリクエストしようと思うのですが、
よろしいですか？
引用返信
/
返信
削除キー/
編集
削除
■5101
/ inTopicNo.3)
Re[2]: 戦闘前の武器選択画面において
▲
▼
■
□投稿者/ せねっく
-(2006/07/14(Fri) 07:20:57)
[ID:JsXdxwaq]
私なんかが言うのもなんですが
反対意見が無ければリクエストしても良いと思いますよ
レスが付いてないのは、最初の段階でかなり完成されていたからかと
しかしふと気づいたのですが、選択肢を３つ以上付けたい場合はどうなるんでしょうか？
３つ目以降の選択肢が、[連動する他の機能]とみなされる可能性はないですか？
私の予想としては
１、Case〜〜で指定されていないものは、全て[連動する他の機能]とみなす
２、[連動する他の機能]として検出出来ないものは、全て選択肢とみなす
３、援護攻撃,防御などのようにON,OFFの切替がメインであるため、選択肢は二つまで
のどれかだろうとは思うのですが…
２番が一番スマートっぽいですが、バグとか出やすそうでもありますね
引用返信
/
返信
削除キー/
編集
削除
■5103
/ inTopicNo.4)
Re[3]: 戦闘前の武器選択画面において
▲
▼
■
□投稿者/ はる
-(2006/07/16(Sun) 13:38:44)
[ID:jRgvOdEO]
> しかしふと気づいたのですが、選択肢を３つ以上付けたい場合はどうなるんでしょうか？
> ３つ目以降の選択肢が、[連動する他の機能]とみなされる可能性はないですか？
> 私の予想としては
>
> １、Case〜〜で指定されていないものは、全て[連動する他の機能]とみなす
> ２、[連動する他の機能]として検出出来ないものは、全て選択肢とみなす
> ３、援護攻撃,防御などのようにON,OFFの切替がメインであるため、選択肢は二つまで
>
> のどれかだろうとは思うのですが…
確かに、「選択肢1」のみ重複させないとすると、選択肢を3つ以上指定しても
問題はありませんね。
機能Aの「選択肢1」と機能Bの「選択肢1」が同時に選択されなければよい、
ということですから。
以上のことを踏まえると、やはり私もせねっくさんの候補2が
シナリオ作成者側としては理解しやすいでしょうし、
プログラム的にも比較的安易に実現可能だと思います。
以下に示す内容で良ければ、1週間後にリクエストしようと思います。
○記述方法--------------------------------------------------------
戦闘オプション 機能 条件式 選択肢(複数可) [連動する機能(複数可)]:
…
Switch
Case 選択肢1
…
Case 選択肢2
…
Case 選択肢3
…
…
…
EndSw
…
Exit
○解説内容--------------------------------------------------------
「選択肢」には武器選択画面に表示される文字列を記述します。
「選択肢」は2つ以上であれば複数指定可能です。
「選択肢」同士は半角スペースでつなげて下さい。
選択肢1が選択された状態で戦闘を開始した場合、イベント内の「Case 選択肢1」
が実行されます。他の場合も同様です。
Caseに記述されていない選択肢が存在してもエラーにはなりませんが、
選択した場合は何も起こりません。
「条件式」には武器選択画面に「機能」を表示させるための条件を記述します。
「条件式」がない場合は「なし」と記述してください。
「連動する機能」には、「機能Aの選択肢1を行う際は機能Bの選択肢1は
行いたくない」という場合に、機能Bの名称を記述します。
デフォルトでは選択肢1が選択されますが、「連動する機能」が存在し、
かつその機能が先に「戦闘オプション」イベントで指定されている場合には、
選択肢2がデフォルトとなります。
「連動する機能」に援護攻撃が選択された場合にも、
選択肢2がデフォルトとなります。
「連動する機能」であっても「戦闘オプション」イベントで指定されていない
ものに関しては、すべて「選択肢」と見なされてしまうため
注意してください(援護攻撃は除く)。
引用返信
/
返信
削除キー/
編集
削除
■5104
/ inTopicNo.5)
問題点
▲
▼
■
□投稿者/ あかんべえ
-(2006/07/17(Mon) 01:25:38)
[ID:SNRAMkHb]
この機能追加の追求自体には賛成なのですが、リクエストの仕様には問題点を感じ
ます。
まず確認したいのですが、このリクエストは「戦闘オプションイベント」というイ
ベント新設ですよね？
だとするとこのイベントは、戦闘イベントの直後に起動し、いったん終了して本体
の武器選択画面ルーチンに移行した後、ふたたび Case 節の内容が実行されることに
なります。
こういうややこしい動き方をするイベントは、プログラムの保守性・統一性などを
損なわないかということ、これが問題の一つです。
もう一つは、「連動する機能」です。ある「戦闘オプションイベント」が別の「戦
闘オプションイベント」の基本動作を左右する仕様になっています。これもややこし
く、上と同じ問題がありそうです。
そもそもこの機能の実現は、イベント新設という形でないといけないのでしょう
か？ ちょっと考えたのですが、(1)武器選択画面の動作のためのパラメータ設定
(2)武器選択画面の結果を変数化して Battle.txt などで運用 というふうにしたほ
うが、ずっとすっきりするし拡張性もあると思います。こうすれば「条件式」も if
なりなんなり、ふつうのＳＲＣコードで実現することができますし。
それから「連動する機能」ですが、たがいに連動する複数の戦闘オプションは、三
つ以上の選択肢を持つひとつの戦闘オプションに置き換え可能なので不用だと思いま
す。むしろこのほうがプレイはしやすくなるかと。
引用返信
/
返信
削除キー/
編集
削除
■5105
/ inTopicNo.6)
Re[5]: 問題点
▲
▼
■
□投稿者/ はる
-(2006/07/17(Mon) 17:23:22)
[ID:jRgvOdEO]
> そもそもこの機能の実現は、イベント新設という形でないといけないのでしょう
> か？ ちょっと考えたのですが、(1)武器選択画面の動作のためのパラメータ設定
> (2)武器選択画面の結果を変数化して Battle.txt などで運用 というふうにしたほ
> うが、ずっとすっきりするし拡張性もあると思います。こうすれば「条件式」も if
> なりなんなり、ふつうのＳＲＣコードで実現することができますし。
形にこだわりはありません。
意見交換をするにあたって、内容が分かりやすいほうが良いだろうと
考えただけですので。
確かに、イベントという形では拡張性が低いですね。
ところでBattle.txtで適用する場合、新しい「コンフィグ対象」と
「バトルコンフィグ変数」をリクエストするということでしょうか？
> それから「連動する機能」ですが、たがいに連動する複数の戦闘オプションは、三
> つ以上の選択肢を持つひとつの戦闘オプションに置き換え可能なので不用だと思いま
> す。むしろこのほうがプレイはしやすくなるかと。
すみません。
内容が理解し辛いため、例を挙げてもらってもよろしいですか？
引用返信
/
返信
削除キー/
編集
削除
■5106
/ inTopicNo.7)
Re[6]: 問題点
▲
▼
■
□投稿者/ あかんべえ
-(2006/07/17(Mon) 22:24:44)
[ID:muBFLCVR]
> 確かに、イベントという形では拡張性が低いですね。
拡張性もだし、リクエストが採用されにくくなると思います。
“本体のルーチン→イベント→本体→イベント→・・・の繰り返しで動作する”
“イベントは互いに独立していて、変数の設定・参照によってのみたがいに影響を
あたえる”というＳＲＣの基本設計（だと思う。たぶん…(^^;;;）を乱してしまう
ので。
> ところでBattle.txtで適用する場合、新しい「コンフィグ対象」と
> 「バトルコンフィグ変数」をリクエストするということでしょうか？
これは、はるさんが盛り込みたい機能によると思います。
原案の switch〜case... で記述できる機能は、Battle.txt からのサブルーチン
呼び出しでも記述できますが、問題は原案の「機能」にあたる部分です。
はるさんはこの部分にどういう要求をお持ちなのでしょうか？ それが、ＳＲＣ
の既存機能で記述可能ならば追加リクエストは必要ないし、不可能ならリクエスト
内容を詰めなきゃならない。
私も含め、「スパロボＭＸ」「携帯機版スパロボ」「スパロボＪ」をやったこと
ない人も多いだろうし、このへんの機能要求の内容を説明していただけないでしょ
うか。
>> それから「連動する機能」ですが、たがいに連動する複数の戦闘オプションは、三
>>つ以上の選択肢を持つひとつの戦闘オプションに置き換え可能なので不用だと思いま
>>す。むしろこのほうがプレイはしやすくなるかと。
>
> すみません。
> 内容が理解し辛いため、例を挙げてもらってもよろしいですか？
“戦闘オプションＡ”が「選択」“Ａ１”“Ａ２”と「連動する機能」“戦闘オ
プションＢ”を持ち、
“戦闘オプションＢ”は「選択」“Ｂ１”“Ｂ２”を持っているとします。
この場合、“Ａ１”を選択すれば“Ｂ１”は選択されないということですよね？
（それともこれは誤解で、単にデフォルト値が変わるだけなのでしょうか？ だっ
たら話は別になってしまいますが・・・）
ならば、「選択」“Ａ１＋Ｂ２”“Ａ２＋Ｂ１”“Ａ２＋Ｂ２”を持つ一つの
戦闘オプションのほうがすっきりすると思ったわけです。
引用返信
/
返信
削除キー/
編集
削除
■5107
/ inTopicNo.8)
Re[7]: 問題点
▲
▼
■
□投稿者/ はる
-(2006/07/19(Wed) 21:32:12)
[ID:jRgvOdEO]
> 私も含め、「スパロボＭＸ」「携帯機版スパロボ」「スパロボＪ」をやったこと
> ない人も多いだろうし、このへんの機能要求の内容を説明していただけないでしょ
> うか。
失礼しました。
ではまず「支援攻撃」「ダブルアタック」「コンボ」の概要を以下に記述します。
○支援攻撃
攻撃を行うパイロット(主パイロット)が特殊能力「支援攻撃」を
所持している場合、能力レベル(最大Lv4)の値だけ周囲4マスにいる
味方ユニットが支援攻撃を行う。
支援攻撃を行うかどうか、またどのユニットが参加するかは選択可能。
支援攻撃は主パイロットの攻撃前に、支援攻撃用の武器でのみ行われる。
支援攻撃は援護防御の対象にならない。
敵機の反撃は主パイロットの搭乗するユニットにのみ行われる。
○ダブルアタック
攻撃先の敵ユニット(敵Ａ)に他の敵ユニット(敵Ｂ)が隣接している場合、
両方を同時に攻撃することが出来る。
ダブルアタックを行うかどうかは選択可能。
ダブルアタック専用武器でのみ行われる。
ダブルアタックは敵機の反撃前に行われる。
ダブルアタックは敵機の位置に関係なく、援護防御の対象にならない。
敵機の反撃は敵Ａからのみ行われる。
○コンボ
攻撃を行うパイロット(主パイロット)が特殊能力「コンボ」を
所持している場合、能力レベル(最大Lv4)の値だけ、
主パイロットと攻撃先の敵ユニット(敵Ａ)に対し、直線上に並んでいる敵機を
攻撃することが出来る(コンボLv2で合計3機)。
コンボ専用武器でのみ行われ、同武器を使用した場合は必ず発動する。
コンボは敵機の反撃前に行われる。
コンボは敵機の位置に関係なく、援護防御の対象にならない。
敵機の反撃は敵Ａからのみ行われる。
これらの機能は効果こそ異なりますが、「どれかを使用した場合は他の機能
(援護攻撃含む)は使用できない」という共通点があります。
現行のSRCでは、上記のような機能をインクルードで追加したとしても
援護攻撃の有無は操作できません。
よって、「追加した複数の機能を、援護攻撃のように武器選択画面で
操作することができ、かつその動作が援護攻撃を含めた他の機能と
連動できるようにしたい」と考え、書き込ませて頂きました。
> “戦闘オプションＡ”が「選択」“Ａ１”“Ａ２”と「連動する機能」“戦闘オ
>プションＢ”を持ち、
> “戦闘オプションＢ”は「選択」“Ｂ１”“Ｂ２”を持っているとします。
> この場合、“Ａ１”を選択すれば“Ｂ１”は選択されないということですよね？
>（それともこれは誤解で、単にデフォルト値が変わるだけなのでしょうか？ だっ
>たら話は別になってしまいますが・・・）
> ならば、「選択」“Ａ１＋Ｂ２”“Ａ２＋Ｂ１”“Ａ２＋Ｂ２”を持つ一つの
>戦闘オプションのほうがすっきりすると思ったわけです。
動作としてはあかんべえさんの考えておられるもので間違いはありませんが、
「戦闘オプションＡ」と「戦闘オプションＢ」を1つにした場合、
こちらの希望する形にはならないのではないかと思います。
引用返信
/
返信
削除キー/
編集
削除
■5108
/ inTopicNo.9)
Re[8]: 問題点
▲
▼
■
□投稿者/ あかんべえ
-(2006/07/20(Thu) 23:59:23)
[ID:zgEVYsI1]
はるさん、「支援攻撃」「ダブルアタック」「コンボ」の概要、了解しました。
実を言えば、これらの機能の実装が非明示のままリクエストに含まれてるのか
と心配してたのです。たいへん失礼しました。
これらの機能は、攻撃する Pilot または Unit自身のダミー特殊能力などを介
しインクルードによって実装されるわけですね。
なお、自前実装を前提した場合、Battle.txt の拡張は不要のような気がします。
なにか理解足らずの機能要求があるかもしれませんが、どうなんでしょう。
> 動作としてはあかんべえさんの考えておられるもので間違いはありませんが、
> 「戦闘オプションＡ」と「戦闘オプションＢ」を1つにした場合、
> こちらの希望する形にはならないのではないかと思います。
う〜ん。１つにしない理由は、それぞれのオプションを独立して設定導入でき
るようにするため、かなあ。機能の複雑化やプレイヤーから見て連動の有無が判
別しにくいことなどを考えると私は導入メリットに疑問も持ちますが、ともあれ、
リクエスト主が希望していることを前提に話を進めたいと思います。
で、機能を実現させる仕様ですが、現時点ではるさんはどのようにお考えでしょ
うか。
一例として、次のようなものはどうでしょう。あくまで一例にすぎず、また簡
略化のために討議された機能のいくつかを省いていますが。
＊ システム変数 戦闘オプション[数値]、戦闘オプション連動[数値]、戦闘オ
プション結果[数値] の追加
戦闘オプション[数値] には特殊能力名を、戦闘オプション連動[数値]には他
の戦闘オプション[数値]のリストを入れる。（それに加え援護も）
戦闘オプション[数値]にデータが入っており、攻撃パイロットまたはユニット
がその特殊能力を満たしている場合、戦闘オプション選択選択画面に、
「“特殊能力名” 使用する 使用しない」
という行が追加表示され、使用・不使用を選ぶことができ、その選択結果は同じ
数値の戦闘オプション結果[数値]に格納される。通常は「使用する」がデフォル
ト。ただし、いずれかの戦闘オプション連動[]に記入されたオプションではデフォ
ルトが「使用しない」となり、記入元オプションと同時に「使用する」ことがで
きない。
「使用しない」を選んだ場合、その戦闘において、その特殊能力があたかも
Disable されたかのように動作する。
ダミー特殊能力を使ってもよい。（Battle.txt、戦闘後イベントなどで運用す
る）
原案の「条件」は特殊能力の必要条件・必要技能を活用します。
選択肢の柔軟化など、この案から拡張するには変数を増やします。
システム変数ではなく、左辺値可能な関数にしたほうがいいかも。
既存の特殊能力にも導入可能なのは、副産物です。メリットがあるのはダミー
などに限られますが。
引用返信
/
返信
削除キー/
編集
削除
トピック内ページ移動 / <<
0
>>
このトピックに書きこむ
過去ログには書き込み不可
Pass/
HOME
HELP
新規作成
新着記事
トピック表示
検索
新着情報
過去ログ
-
Child Tree
-
-
Antispam Version
-
新着情報
新着情報
新着情報