SRC意見交換掲示板Mk2
(現在 過去ログ53 を表示中)

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

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

■5755 / inTopicNo.1)  マップ上の特定ユニット・地点を取得するコマンドSpec2
  
□投稿者/ コウ -(2008/02/01(Fri) 10:56:41) [ID:DheCHIua]
    コウです。
    ツリーを移動してレスレス。

    > 2.範囲の表示について

    このオプション自体はUnnamed氏の提案ですが、私も攻撃目標選択時と同じような表示だと思ってました。
    >「SPやMAP兵器のような操作でユニットや地点の選択を可能とするコマンド」
    のようにSPが起点だったため、最初は範囲を考えていませんでしたが、xy座標や最大最小を考慮した時点で
    攻撃や移動と同じ範囲選択の形を取るものにシフトしたと考えていいでしょう。


    > まず、オプション案追加についてですが、
    > 「『条件式』を満たす座標(ユニット?)のみ選択可」があると便利かな、と。

    便利ではあるのでしょうが、オプションもかなり増えてますし、これ以上は煩雑になりすぎてしまうのが怖いですね。
    何か良い案があればいいのですが。


    > >「直」「拡」「扇」
    > >「線 angle」

    基本的には中箱さんの考えでいいと思います。
    扇は、確かにレベル指定が必要でしたね。併記しておきますか。
    あと、うーん、投も要りますかね。

    線はx yが始点、選択して取得した座標が終点になると思います。
    角度は、Unnamed氏も書いていますし割愛。



    一応、以下に現状のリクエスト文草稿を。

    リクエストの趣旨は「SPやMAP兵器のような操作でユニットや地点の選択を可能とするコマンド」ですね。
    選択範囲の最大・最小を考慮する場合は、攻撃や移動と同じ形で範囲を表示するのが良いと思います。

    書式
    Appoint [option]
    Appoint x y min max [option]

    指定項目      説明
    x y min max     (x, y)を中心として範囲[min-max]が選択可能。これらを省略すると範囲無制限。

    option (複数選択可)
    「ユニット選択」      マップの地点ではなく、ユニット選択を待機します。
    「キャンセル可」      選択中右クリックでキャンセルします。X(目標地点)とY(目標地点)は空文字を返します。
    「非同期」         選択直後にマップの再描画を行いません。(範囲が表示されたままに)
    「マップ外選択可」     マップ外の地点を選択可能にします。「ユニット選択」とは同時に指定しても意味がありません。
    「直」「拡」「扇L*」「投L*」それぞれ、同じマップ武器属性と同じ範囲を取るようになります。扇、投はレベル指定が必要。
    「線 angle」        M線属性と同じ範囲を取ります。angleは範囲の取る角度(°)です。
    「味方/NPC/敵/中立」   指定した陣営が選択可能、指定されない場合は全陣営指定可能
    「行動可能/行動不可」    指定されている状態のユニットのみ選択可能指定されない場合は状態にかかわらず選択可能

    解説
    コマンドを実行すると、マップ画面にてプレイヤーによる座標選択を待ち、選択された座標をX(目標地点)とY(目標地点)に代入する。
    また、選択した座標上にユニットが配置されていた場合、当該ユニットのユニットIDを対象ユニットIDに代入する。


    ここまでは大体意見が一致している部分、以下は都合の良い方でお願いします。

    キャンセル選択時の挙動
    1.空文字を返す
    2.何らかの整数を返す

    「ユニット選択」指定時に「キャンセル可」を指定しなかった場合の挙動
    1.「キャンセル可」を無くして常にキャンセル可とする
    2.選択対象がなかった場合、キャンセル可が無くてもキャンセル同様の動作をさせる
    3.ユニットの存在しない座標を選択することで特異値を返す
引用返信/返信 削除キー/
■5757 / inTopicNo.2)  Re[1]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ 乾 -(2008/02/02(Sat) 01:28:38) [ID:KPaseBs2]
     乾です。
     
     とりあえず、選択対象になるユニット&座標を絞り込む機能については案があります。

     現状、オプションに条件式を入れることで対象となるユニットを絞り込むという
    プランが出ていますが、正直、あまり現実的な指定方法とは思えません。
    (ユニットコマンドやユニット用能力と違い、条件式が存在するユニットの数だけ
    コールされるわけで内部処理的にもイベントソース的にも筋のいい実装とはとても
    言い難いものになるのではないかと)

     なので、事前に選択対象を設定した後に選択用のコマンドを実行する形式として
    提示してみようと思います。
    (Wait Clickに対する、HotPointとClearObjのような関係になります)

     ただ、Appointの仕様を見ていて思ったのですが、やはりユニット選択機能と
    座標選択機能は、無理に一つのコマンドにしない方が、ユーザが理解しやすい
    ものとなるのではないかと思うのです。

     具体的には、ユニット選択機能を求めてAppointコマンドを参照したときに
    ユニットと座標の両方のプションが混在していて、把握しにくいというのがあります
     特定のオプションが指定された場合のみ、このオプションが有効 という様な記述は
    可能な限りなくした方が分かりやすくなると思うわけです。

     そこで、Appointコマンドを以下の二つに分割することを提案します。
    (ついでに上記のSetappoint/ClearAppointもユニット・座標用に分けたイメージを作成します)


    ============================================================================================
    【ユニット選択用コマンド】

    書式
    AppointUnit [option]

    option
    「キャンセル可」 選択中右クリックでキャンセルします。X(目標地点)とY(目標地点)は空文字を返します。
    「非同期」    選択直後にマップの再描画を行いません。(範囲が表示されたままに)

    解説
     コマンドを実行すると、マップ画面にてプレイヤーによるユニット選択を待ち、選択されたユニットのユニットIDを
    対象ユニットIDに代入する。
     キャンセルが行われた場合、対象ユニットIDには空文字列を設定する。

    -------------------------------------------------------------------------------------------
    書式
    SetAppointUnit unitid

     次に実行されるAppointUnitコマンドでSetappointUnitで指定したユニットのみ選択対象となる。
     SetAppointUnitが実行されて居なかった場合は、全てのユニットが選択対象となる。

    -------------------------------------------------------------------------------------------
    書式
    ClearAppointUnit

    SetAppointUnitによる選択対象指定をクリアします。

    -------------------------------------------------------------------------------------------

    (使用例)

     独自コマンドでEN回復させたい味方ユニットを選択させるというマップコマンドを
    準備する方法を提示します。


    *プロローグ:
    Set 補給物資投下残り回数 3
    Exit

    マップコマンド 補給物資投下 (補給物資投下残り回数 >= 1):
    Local 選択可能ユニット数 = 0

    ForEach 味方 出撃
    If (EN() < Info(ユニット,対象ユニットID,最大EN)) Then
    Incr 選択可能ユニット数 1
    SetAppointUnit 対象ユニットID
    EndIf
    Next

    If (選択可能ユニット数 = 0) Then
    Talk システム
    ENが減っているユニットが存在しません。
    End
    Exit
    EndIf

    AppointUnit キャンセル可
    ClearAppointUnit

    If (対象ユニットID = "") Then
    Exit
    EndIf

    Incr 補給物資投下残り回数 -1
    EN(対象ユニットID) = Info(ユニット,対象ユニットID,最大EN)

    Talk システム
    NickName(対象ユニットID)に補給物資を投下した。
    End

    Exit


    ============================================================================================
    【座標選択用コマンド】

    書式
    AppointSpot [x y min max] [option]

    指定項目    説明
    x y min max   (x, y)を中心として範囲[min-max]が選択可能。これらを省略すると範囲無制限。

    option
    「キャンセル可」 選択中右クリックでキャンセルします。X(目標地点)とY(目標地点)は空文字を返します。
    「非同期」    選択直後にマップの再描画を行いません。(範囲が表示されたままに)
    「マップ外選択可」マップ外の地点を選択可能にします。「ユニット選択」とは同時に指定しても意味がありません。
    「直」「拡」「扇」それぞれ、同じマップ武器属性と同じ範囲を取るようになります。
    「線 angle」   M線属性と同じ範囲を取ります。angleは範囲の取る角度(°)です。


    解説
     コマンドを実行すると、マップ画面にてプレイヤーによる座標選択を待ち、
    選択された座標をX(目標地点)とY(目標地点)に代入する。
     キャンセルが行われた場合、X(目標地点) / Y(目標地点)には空文字列を設定する。


     ※マップコマンドオプションを指定したときの範囲指定に関しては手を加えていません。

    -------------------------------------------------------------------------------------------
    書式
    SetAppointSpot x y

     次に実行されるAppointSpotコマンドでSetappointSpotで指定した座標のみ選択対象となる。
     SetAppointSpotが実行されて居なかった場合は、AppointSpotの有効範囲全ての座標が選択対象となる。

    -------------------------------------------------------------------------------------------
    書式
    ClearAppointSpot

    SetAppointSpotによる選択対象指定をクリアします。

    -------------------------------------------------------------------------------------------

    (使用例)

    (母艦が出撃する座標を4カ所から選ばせる)

    SetAppointSpot 3 3
    SetAppointSpot 3 18
    SetAppointSpot 18 3
    SetAppointSpot 18 18

    Talk システム
    母艦を出撃させる地点を選択してください
    End

    AppointSpot
    ClearAppointSpot

    Launch X(目標地点) Y(目標地点) ロイド=L=ロイド
    Organize 12 X(目標地点) Y(目標地点)

    -------------------------------------------------------------------------------------------

     以上です。

引用返信/返信 削除キー/
■5758 / inTopicNo.3)  Re[1]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ 中箱 -(2008/02/02(Sat) 01:37:57) [ID:TdSzoAHN]
    >コウさん

    >便利ではあるのでしょうが、オプションもかなり増えてますし、これ以上は煩雑になりすぎてしまうのが怖いですね。

    案のまとめに入ってからのややこしい提案ですいません。

    …もしかしたら、条件式をオプションに使えるようにするのではなく、
    条件式使用前提の別コマンドとしてしまった方が良いのかも、と少し思っていたりしますが。



    >あと、うーん、投も要りますかね。

    >線はx yが始点、選択して取得した座標が終点になると思います。

    「投」の追加と、「線」で終点を決めるとのことを受けての確認ですが、

    「線」でangleを指定しなかった場合と「投」の場合は、
     投下or終点座標を選択 → X(目標地点),Y(目標地点)に代入する座標を選択
    …と、コマンド終了までに2回座標を選択する、ということで良いのでしょうか。




    次に、No5747のあかんべえさんへのレスを含めて、条件式関連についてです。


    > この機能を加える場合、「条件式」で各座標データや各ユニットのデータを参照する仕組みが必要だと思います。

    確かにその通りですね。

    んー、システム変数で座標値を扱えそうなのはせいぜい「選択」ぐらいしかない上、「選択」にX座標,Y座標二つの情報を入れるわけにはいかないですね…

    となると、X(目標地点),Y(目標地点)とするのが一番妥当かなと。

    座標を選択した場合はもちろん、キャンセルした場合でも、
    コマンドの実行後は必ず X(目標地点)とY(目標地点) が書き換えられるのですから、動作上の問題は無いと思います。


    それと条件式であるかどうかを確実に判別する必要があることから考えて、
    オプションの書式としては
     条件 expression
    を提案します。


    具体的には

     Appoint 条件 (X(目標地点) > 5)
    (X座標が6以上の地点のどこかを選択)

     Appoint 3 6 0 5 条件 (Info(マップ,X(目標地点),Y(目標地点),地形名) = "基地")
    (座標(3,6)を中心とした5マス以内にある基地のどれかを選択)

    …のようになる感じでしょうか。
    (条件式であるかどうかの判別が確実にできるのであれば、条件式の前の "条件" は不要かもしれません)




    >Unnamedさん
    > 条件式として「0または0以外を返す式を文字列として与える」などのEval的方法は現在のSRCでは馴染みの薄いものなので、
    >柔軟ではありますが、それで構わないかどうかは議論があると思います。

    > 私としてはそのような条件式指定に反対はしませんが、既にコマンドのオプションがかなり多くなっていますし、
    >絶対必要と言うわけでもないので、とても便利と言うものでなければ無くても構わないのではないかとも思います。

    んー、条件式自体は Do,Ifコマンドなどで頻繁に使用されているものですから、「馴染みが薄いもの」という認識はないです。
    まあ、オプションとして条件式が使える イベントコマンドや関数は存在していませんが…。
    (そこまでプログラミング方面の知識があるわけではないので、多分私が"Eval的方法"などについて誤解しているのだとは思いますけれど)


    ただ、「絶対必要」であるかどうかは判断基準にしようが無いのではと。
    当初の用途案が武器・アビリティ選択のエミュレートであったとしても、どこまでのエミュレートを目的にするか決めていないわけですし。

    オプションが多くなっているのも確かですし、提案タイミングがちと遅かったことも事実だとは思いますが、
    少なくとも私個人としては、とても便利なオプションにはなると思っての提案です。
    マップ上のどの地点を選択させるのかを、条件式の工夫次第でシナリオ側が自由自在に設定することが可能になるわけですから。



    私からは以上です。
    では
引用返信/返信 削除キー/
■5772 / inTopicNo.4)  Re[2]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ あかんべえ -(2008/02/12(Tue) 19:25:53) [ID:p1N9wEsL]
     あかんべえです。しばらく議論が途絶えていましたが、打開意見(になってないかもしれませんが)をば。

    A.一つのコマンドか、二つか
     乾さんは、コマンドを二つに分ける理由として、分かりやすさをあげられ、
    >  具体的には、ユニット選択機能を求めてAppointコマンドを参照したときに
    > ユニットと座標の両方のプションが混在していて、把握しにくいというのがあります
    >  特定のオプションが指定された場合のみ、このオプションが有効 という様な記述は
    > 可能な限りなくした方が分かりやすくなると思うわけです。

    と、言われています。
     だが、ここには現在案(No.5755)への認識の違いがあります。現在案のオプションのうち、
    > 「直」「拡」「扇L*」「投L*」それぞれ、同じマップ武器属性と同じ範囲を取るようになります。扇、投はレベル指定が必要。
    > 「線 angle」        M線属性と同じ範囲を取ります。angleは範囲の取る角度(°)です。

    これらについて、乾さんの二分割案を見る限り、座標選択時のみ有効と考えておられるようですが、現在案ではその限定はなく、両方に有効なのではないでしょうか。
     とすれば、ユニット選択時と座標選択時とのオプションの違いは、以下の二点になります。
    (1) 「「マップ外選択可」     マップ外の地点を選択可能にします。「ユニット選択」とは同時に指定しても意味がありません。」
    (2) 「「味方/NPC/敵/中立」   指定した陣営が選択可能、指定されない場合は全陣営指定可能
    「行動可能/行動不可」    指定されている状態のユニットのみ選択可能指定されない場合は状態にかかわらず選択可能」

     (1)は、マップ外にはユニットが存在していないので、ユニット選択時には単に無意味なだけです。
     (2)は、マップ座標には陣営も行動もないので、単にその区別がないだけです。

     いずれも、オプションを動作させても意味ある結果が出ないだけで、コマンドの動作自体はマップ選択時とユニット選択時に違いがあるわけではないと思います。
     つまりこれは、選択範囲を限定していないときには「非同期」オプションは無意味なのと同じことです。

     というわけで、コマンドを二つに分ける必要はないと思います。ただ私も、一つのコマンドにこだわっているわけではないので、何か別の積極的な理由が提示された場合は話は別です。

     なお、乾さんのユニット指定コマンド案には上の「(2)」がありませんが、これは単なる書き落としですよね?


    B.柔軟な選択対象絞込みについて
     現在、中箱さんと乾さんから、それぞれ別の形で、選択対象を柔軟に絞り込む機能が提案されていますが、それについての意見です。
     結論から言うと、いずれは欲しい機能だと思うけれど時期尚早、「あとの楽しみ」(?)にとっておいて、とりあえずは現状のままのリクエストがよいと思います。理由はいくつかあります。

    (1) この提案を度外視すれば、Appointコマンドは大部分がSRCに組み込み済みの機能から成り立っています。マップ座標やユニットを指定する機能にせよ、マップ上の一点を中心にした範囲の限定にせよ、すでにあります。
     だから、このリクエストはかなり導入が楽なリクエストだと思います。
     対して、中箱さんの案も乾さんの案もこれまで SRCになかった新機能です。たぶん、実装の手間はコマンド本体以上ではないでしょうか。
     つまり、この追加によってリクエストが一気に「重く」なります。

    (2) このリクエストは応用範囲が広く、導入されれば実際に使用される人がけっこうおられると予想しています。
     他方、この追加機能は「とりあえず無くても動くが、あればプレイヤーにとってより快適」という性質の機能です。
     ならば、とりあえず無しで実装ししばらくしてから追加を検討したほうが、実際のシナリオ製作やプレイ体験を踏まえた多くの人にイメージしやすい議論ができるだろと思うのです。

     以上です。

            





引用返信/返信 削除キー/
■5773 / inTopicNo.5)  Re[3]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ 乾@汎用データ -(2008/02/12(Tue) 22:18:54) [ID:KPaseBs2]
     乾です。

     先のレスで上げたAppointコマンドの分割した仕様については、前提として
    まず、SetAppointXXXXの実装が行われていることが条件となっています。
    なので、SetAppointを先送りにするというのならば、オプションなど全て
    整理し直すことになると思います。

     分割については、SetAppointによる絞り込み方法をユニット・座標で切り分けた方が
    区分がしやすいのではないかという観点に立っています。

     また、AppointUnitコマンドのイメージで、陣営や行動条件を外したのは、
    その類の絞り込みはSetAppointUnitコマンドにより行う方針で一元化した方が、
    コマンドの役割分担が明確になるという観点から意識的に外しています。

     ただ、座標による範囲指定とMAP兵器用の範囲指定はたしかにユニットを指定する際にも利用できますね
    これはオプションとして導入すること前提に整理をしてみましょう。

    =========================================================================
    【ユニット選択用コマンド】

    書式
    AppointUnit [x y min max] [option]

    指定項目    説明
    x y min max   (x, y)を中心として範囲[min-max]が選択可能。これらを省略すると範囲無制限。

    option
    「キャンセル可」 選択中右クリックでキャンセルします。X(目標地点)とY(目標地点)は空文字を返します。
    「非同期」    選択直後にマップの再描画を行いません。(範囲が表示されたままに)
    「直」「拡」「扇L*」それぞれ、同じマップ武器属性と同じ範囲を取るようになります。
    「線 angle」   M線属性と同じ範囲を取ります。angleは範囲の取る角度(°)です。

    解説
     コマンドを実行すると、マップ画面にてプレイヤーによるユニット選択を待ち、
    選択されたユニットのユニットIDを対象ユニットIDに代入する。
     キャンセルが行われた場合、対象ユニットIDには空文字列を設定する。

    SetAppointUnitコマンドが事前に行われている場合は、オプションで指定された
    範囲のユニットで、SetAppointUnitが設定されているユニットのみが選択対象となる。

     SetAppointUnitコマンドが実行されていない場合、指定された範囲全てのユニットが
    選択対象となる。

    -------------------------------------------------------------------------
    書式
    SetAppointUnit unitid

     次に実行されるAppointUnitコマンドでSetappointUnitで指定したユニットのみ選択対象となる。
     SetAppointUnitが実行されて居なかった場合は、全てのユニットが選択対象となる。

    -------------------------------------------------------------------------
    書式
    ClearAppointUnit

    SetAppointUnitによる選択対象指定をクリアします。

    -------------------------------------------------------------------------

    (SetAppointをリクエストに含めるかどうか)

     この辺りになってくると、もはやKeiさんがどっちの方式でやった方がポリシーに
    あうかの話になってくるので、こちらで決めてしまうよりも、大まかにまとめて、
    実装イメージはKeiさんに任せてしまった方がいいのかも知れません。

     たしかに、SetAppoint等の絞り込み機能を盛り込んだ方が作業量は
    増えるのですが、どうせ後で盛り込みの要望が来るのが分かっている
    ようなものならば一気にやってしまった方がいい、という見方も出来るので。
     意見交換板で結論が出ない話を続けてもきりがなくなってくるのではないかと。

      
    (オプションの投L*について)

     このオプションは考慮する必要はないのではないかと思います。
     実際にM投型MAP兵器による選択を行うときのイメージは
    ユニットの座標を中心に射程分のMin,Maxを範囲とした選択を行い、
    その後、選択座標を中心としてmin=0,max=M投のレベル値の選択範囲が
    表示された後に、クリックで決定という流れになるため、
    Appointコマンドで再現する際もそれに準じたコマンドの組み合わせで作るのが
    分かりやすい実装になるのではないかと。

    (それにM投Lxで選択対象になりうる座標の範囲というのは、minとmaxを
    レベル分だけ広げた形になるため、M投用の選択をさせているという
    イメージにはなりにくいと思います)
引用返信/返信 削除キー/
■5774 / inTopicNo.6)  Re[4]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ あかんべえ -(2008/02/14(Thu) 01:01:44) [ID:BNJj0SoF]
    乾さん:
    >  先のレスで上げたAppointコマンドの分割した仕様については、前提として
    > まず、SetAppointXXXXの実装が行われていることが条件となっています。

     お伺いしたのは、Appointコマンド分割案の条件についてではなく、分割案の積極的理由なんです。
     「分かりやすさ」以外の理由はあるのか、また先の私の意見を踏まえてもなお、「分かりやすさ」を主張されるのか。
     それがあれば検討しなきゃならないし、なければわざわざ二分割する必要はないということです。

    >  分割については、SetAppointによる絞り込み方法をユニット・座標で切り分けた方が
    > 区分がしやすいのではないかという観点に立っています。

     これは SetAppointXXXXを分割する理由としてはわかるのですが、Appointコマンド自体を分割する理由にはならないでしょう。

    ------

     それから、SetAppointXXXXが Appoint分割の前提だということは、最初に明示して欲しかったです。
     乾さんの先のご発言(No5757)では、SetAppointXXXX案のあと「ただ、Appointの仕様を見ていて思ったのですが」とあり、さらに、その後では
    >  そこで、Appointコマンドを以下の二つに分割することを提案します。
    > (ついでに上記のSetappoint/ClearAppointもユニット・座標用に分けたイメージを作成します)

    と書かれています。「ただ、」「ついでに」という表現からはAppoint分割は全くの別件であるとしか読み取れません。
     他の人は、乾さんの文章から理解するしかありません。こんな重要事項を後になって開示されると、ちゃぶ台をひっくり返された気分になります。
引用返信/返信 削除キー/
■5775 / inTopicNo.7)  Re[5]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ 乾 -(2008/02/14(Thu) 22:38:59) [ID:KPaseBs2]
     乾です。

     なるほど、前回のレスで分割した理由の方をがついでの一言で片づけられてしまっていた
    ために、Appoint側を分割する理由が判断できなかったと
    いうことですね、了解しました。

     Appointをユニット選択用と座標選択用に分割した方がよいと考えたのは
    選択結果が格納される場所が2カ所に分かれているため、誤判定をするケースが
    増えそうで怖い。という点にあります。

     たとえば、

    質問
    「Appointコマンドでユニットを選択したのですが、選択したユニットの
    とは別のユニットのIDが対象ユニットIDに設定されてしまいます
    何故でしょうか?」

    回答
    「オプションでユニット選択が指定されていません、ユニット選択が
    指定されていない場合は、Appointコマンド実行前の対象ユニットIDが
    そのまま残っています。
     対象ユニットIDに結果を格納するにはユニット選択を指定してください」


     というやりとりが発生すること予想されるわけです。
     事前にコマンドを分割しておけば、オプションで"ユニット選択"を指定する
    ということを見逃す恐れはなく、AppointSpotならば目標地点だけを
    参照すればよい、AppointUnitならば対象ユニットIDだけを参照すればよいと
    コマンドのヘルプから読みとることが容易になるでしょう。

     また、SetAppointSpotとSetAppointUnitを採用した際、両方を指定した後に
    Appointコマンドを実行したときの振る舞いについて考えてみたのですが
    うまく整理が尽きませんでした。
     下手に機能の誤解を招くような状態にするよりは、座標選択は
    AppointSpot系コマンド、ユニット選択はAppointUnit系コマンド と
    切り分けてしまった方が結果的に仕様を理解しやすくなると思います。

     Appointコマンド一本化で採用した場合は、対象ユニットIDと
    目標地点の座標が同時に取れるというメリットがあるようにも
    見えますが、これも X(対象ユニットID) / Y(対象ユニットID)で
    取得が可能なため、ユニット選択の時は目標地点を意識しないで
    使用できる方が分かりやすいのではないかと思います。

     以上です。


引用返信/返信 削除キー/
■5777 / inTopicNo.8)  Re[6]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ あかんべえ -(2008/02/15(Fri) 23:48:46) [ID:xIpVrJ7F]
     乾さんの仮想質問応答ですが、現在案(#5755)の動作とは違います。現在案では、
    > 解説
    > コマンドを実行すると、マップ画面にてプレイヤーによる座標選択を待ち、選択された座標をX(目標地点)とY(目標地点)に代入する。
    > また、選択した座標上にユニットが配置されていた場合、当該ユニットのユニットIDを対象ユニットIDに代入する。

    となっており、これはオプションには左右されない、Appointコマンド共通の動作です。
     したがって、ユニットのいる場所を選択した場合、オプション「ユニット選択」をしていなくても「対象ユニットID」にそのユニットのIDが代入されます。だから、乾さんの言われる「誤判定」の可能性はありません。

    >  また、SetAppointSpotとSetAppointUnitを採用した際、両方を指定した後に
    > Appointコマンドを実行したときの振る舞いについて考えてみたのですが
    > うまく整理が尽きませんでした。

     これは理解しかねます。たとえば、単純に、「SetAppointUnit はユニット指定オプション時のみ有効だが SetAppointSpotはそうではない」とするだけですむでしょう。

    >  下手に機能の誤解を招くような状態にするよりは、座標選択は
    > AppointSpot系コマンド、ユニット選択はAppointUnit系コマンド と
    > 切り分けてしまった方が結果的に仕様を理解しやすくなると思います。

     そもそもここに誤解があるのではないでしょうか。このリクエストは、たしかに座標選択系とユニット選択系の並立というところから出発しましたが、議論のごく初期のUnnamedさんの#5645 以降、両方の機能を統合したリクエストになっています。
     この「統合」と言う意味は、単に“コマンドを一つにした”というだけにとどまりません。上にあげた現在案の「解説」に表されるような、機能上の統合です。
     その結果、Appointコマンドの現在案は、ひじょうにすっきりとまとまったものになっています。
     「ユニット選択」オプションも、本質的には選択対象を限定するオプションであり、他のオプションと統一感のあるものになっています。乾さんのお考えのような何か特別なものではありません。
     乾さんは現在案について、二つの別々の機能を無理に一つのコマンドに兼用させているかのようにイメージされているのではないでしょうか? そのようなものではありません。

    >  Appointコマンド一本化で採用した場合は、対象ユニットIDと
    > 目標地点の座標が同時に取れるというメリットがあるようにも
    > 見えますが、これも X(対象ユニットID) / Y(対象ユニットID)で
    > 取得が可能なため、ユニット選択の時は目標地点を意識しないで
    > 使用できる方が分かりやすいのではないかと思います。

     ここはますます理解しかねます。
     現在案はユニット選択時、別に目標地点への意識を強制するわけでもないのに、どうして「意識しないで使用できる方が分かりやすい」という話につながるかもわかりません。
     まさかとは思いますが、「二分割案は機能が足らないから分かりやすいんだ」とおっしゃりたいわけではないでしょうね?

    ------

    >  なるほど、前回のレスで分割した理由の方をがついでの一言で片づけられてしまっていた
    > ために、Appoint側を分割する理由が判断できなかったと
    > いうことですね、了解しました。

     う〜ん。話が通じてませんね。
     私個人が「判断できなかった」ことはたいした問題じゃありません。
     ご自身以外の誰にとっても判断できないような提案文を出されたことが問題ではないか、また、にもかかわらず「判断できなかった」相手側が無理解であるかのような表現を繰り返されることが問題ではないかと、申し上げているのです。
引用返信/返信 削除キー/
■5784 / inTopicNo.9)  Re[2]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ ワヅキ -(2008/02/18(Mon) 21:31:41) [ID:fbiBr0VL]
    2008/02/18(Mon) 22:15:16 編集(投稿者)

    こんにちわ、あるいはこんばんわ、ワヅキです。
    機能リクエスト自体には積極的な賛成の立場を取りつつ、意見しようと思います。

    個人的には、草稿のようなコマンドの使い方に加えて、
    乾さんの提案である座標の絞り込み用のコマンドがあればいいなと思いました。

    ユニットの絞り込みに関しては、選択した座標にユニットが存在した場合、
    目標地点とユニットIDの両方に値が入るみたいなので、必要ないと思います。

    乾さんのコマンドの魅力は、1度に複数の座標範囲を指定する事ができるという点と、
    事前に選択対象を絞り込む為の式を用意できる点ではないでしょうか?

    ついでに、選択範囲全体の描画に関わる制限をAppointのオプションに、
    選択範囲単一の描画に関わる制限をSet/Clearのオプションに分割する事で、
    草稿の問題点であるオプション関連の煩雑さが解消できると思うのですが、どうでしょうか?

    雑に取りまとめると下記のような感じです。
    テキストを強く加工した部分に関してのみ説明を記載しています。

    # -------------------------------------------------- #

    Appoint [option]

    [option]
    「キャンセル可」
    「非同期」
    「マップ外選択可」
    「直」「拡」「扇L*」「投L*」
    「線 angle」

    解説
    コマンドを実行すると、マップ画面が選択可能となり、選択された座標を X( 目標地点 ) と Y( 目標地点 ) に代入する。
    また、選択した座標上にユニットが配置はれていた場合、当該ユニットのユニットIDを対象ユニットIDに代入する。

    選択可能なマップの範囲は SetAppointSpot / ClearAppointSpot で変更する事が可能。
    コマンドが利用されていなかった場合、マップ全体が選択範囲となる。

    # -------------------------------------------------- #

    SetAppointSpot x y [min max] [option]

    解説
    Appoint で表示する選択範囲を追加する事ができる。

    [option]
    「ユニット選択」
    「味方/NPC/敵/中立」
    「行動可能/行動不可」

    # -------------------------------------------------- #

    ClearAppointSpot [x y [min max] [option]]

    解説
    Appoint で表示する選択範囲を除外する事ができる。
    引数を省略した場合、全画面選択可能になる。

    [option]
    「ユニット選択」
    「味方/NPC/敵/中立」
    「行動可能/行動不可」

    # -------------------------------------------------- #

    以上です。
    乱文、雑文失礼しました。 それでは。
引用返信/返信 削除キー/
■5787 / inTopicNo.10)  Re[1]: マップ上の特定ユニット・地点を取得するコマンドSpec2
□投稿者/ コウ -(2008/02/20(Wed) 19:00:06) [ID:DheCHIua]
    ども、コウです。
    そろそろ反応しておこうかな、と。

    とりあえずコマンドを追加して、後から機能を追加するのは結果的に手間が増えるだけじゃないかなー
    と思うので、途中切り上げはなしの方向で行きたいと思います。


    >投
    こちらはAppointを多重で実行することで実現可能だったことを失念してました。
    混乱させたようで申し訳ありませんでした。

    >線 angle
    終点を選択して得た座標と始点の座標を比較し角度を算出する、んでしょう。
    ちょっと解り難いかも知れませんね。


    で、イベント対象の選択方法に関してですが、個人的な見解としては、条件式を長々設定するよりも
    他コマンドと複合出来た方が運用の幅も広がるかな、と思います。
    HotPointとClearObjのような関係であれば、コマンドを把握している人なら違和感なく使いこなせるでしょうし
    機能毎で明確に分割してあった方がシンプルな指定になるかと思います。

    またAppoint自体の分割も一理あるんじゃないかと思います。
    似たようなコマンドが存在するのは美しくないですが、機能別に分かれていた方が直感的に指定し易いのも事実ですから。
    UnitとSpotを同時に指定したり、ひとつのルーチンの中で入れ替わり立ち代り指定するようなことになると
    それぞれ独立していた方が指定は楽になるでしょう。


    分割案がいいかなと思いますが、複雑になってきましたし、乾さんも言っているように、どちらの方がやり易いか
    ポリシーに合うかをkeiさんに判断して貰った方がいいかも知れませんね。
    とりとめのない文章になってしまいましたが、一応、個人的には分割案に賛成ということで。
引用返信/返信 削除キー/
■5788 / inTopicNo.11)  選択対象絞込み機能について
□投稿者/ あかんべえ -(2008/02/20(Wed) 22:51:59) [ID:aVwNlAIN]
     ども、あかんべえです。この書き込みは「より柔軟な選択対象絞込み」機能についてです。
     ただし、「この機能追加は、Appointコマンドの実動経験を積んだあとに議論したほうがいい」という意見は変わってません。また、ただちに議論する場合もせめて新ツリーでやり、Appoint本体はこのままでいったんリクエストしたほうがよいと思っています――追加的機能なのにかかわらず、論点がけっこう多いので。
     だから、以下の案は「もしこのツリーで結論を出すのならば」の意見です。コウさんがこれを無視してリクエストをまとめられてもかまいません。

     まず仕様案を書き、ついでいくつかの論点を書きます。


    **** 柔軟な選択対象絞込み機能 仕様案 *****

     この機能のために二つの仕様案を併記します。選択は Keiさんにお願いします。

    1.条件式オプション案
     Appointコマンドに以下のオプションを追加します。
    表記案(1) 「Where expression」
    表記案(2) 「expression判別式」

    いずれも、expressionには判別式を記入します。判別式は全体を括弧“( )”にくくります。表記案(2)後半の「判別式」は「判別式」という文字列を記入します。実装に採用するのは表記案(1)(2)どちらでもかまいません。

    解説:expressionに合致した目標だけが選択対象になります。
     expressionの中では、通常の式要素のほか以下の専用キーワードが使用可能です。
    * 「X(該当座標)」, 「Y(該当座標)」  判別中の目標候補地点の座標を返します。
    * 「該当パイロット」, 「該当ユニットID」  それぞれ、判別中の目標候補地点にいるユニットのメインパイロット名またはユニットIDを返します。ユニットがいなければ空文字を返します。この部分はリクエストにとって不可欠の要素ではありません。
    (オプション「ユニット選択」を付けなくても、「該当パイロット」「該当ユニットID」を入れた式は機能します。ただし、実行速度は付けたほうが早いかもしれません)


    2.事前登録案
     Appointコマンドに以下のオプションを追加します。
    表記案(1) 「In array」
    表記案(2) 「array変数」

    いずれも、arrayには連想配列の名前を指定します。表記案(2)後半の「変数」は「変数」という文字列を記入します。実装に採用するのは表記案(1)(2)どちらでもかまいません。
     連想配列の替わりにリスト変数を使う仕様でもかまいません。

    解説:配列array の要素の値として登録してある目標だけが選択対象になります。
     値には以下のものだけが有効です。
    * 座標のリスト  例:"7 11", "9 6"
    * ユニットのメインパイロット名またはユニットID(「愛称」などに拡張してもかまいません)。この部分はリクエストにとって不可欠の要素ではありません。

     両方のタイプの値が混在していても機能します。
     これらに合致しない値があった場合、エラーメッセージを表示し、そのデータは無視し、処理は続行されます。


    **** 論点 ****

    1.両案併記の理由
     理由の一つは甲乙つけがたく思えることです。

     乾さんは中箱さんの条件式オプション案に対し「筋のいい実装とはとても言い難い」と極めて辛らつに評されていますが、正当な評価とは思えません。
     この案ではたしかに、目標ごとに判別処理が呼び出され、Appointコマンドの実行時間もかかりそうです。しかし、事前登録案の場合も、Appointコマンドの外で事前の登録イベントとして同じ処理を行うことになるのですね。関連処理の総実行時間では、SRCの内部で判別処理をする条件式オプション案のほうがイベントコマンドで行う事前登録案よりむしろ早くなりそうです。
     そもそも<目標ごとに判別処理すること>は、「柔軟な対象絞り込み」という目的そのものによって必要とされる処理です。コマンド内部にせよ事前にせよ、どこかでやらなくてはならない。“中箱さんの案によってわざわざややこしい処理が生じた”と見るのは、不当です。
     むしろ、この<目標ごとの判別処理>という課題に対し、「判別式を設定しコマンド内部で処理する」というのは、SRCにおいて非常にすなおで正統的な発想だと思います。武器選択・攻撃目標選択時など似たような処理は少なくありませんし。

     「筋の良さ」をあえて問題にするなら、私の案も含めた事前登録案の「一つ一つの目標をいちいち登録する」ことのほうが、相当に筋が悪いです。
     そのかわり、事前登録案には<よりいっそう柔軟な処理が可能>という長所があります。
     この点では事前登録案が上、筋の良さなどでは条件式オプション案が上、甲乙つけがたいと思います。

     もう一つの理由は、両案の発想は大きく違い、この選択はSRC全体の方向というか、設計思想に左右されそうなことです。よって、選択は Kei さんにゆだねるべきと考えました。


    2.条件式オプション案で専用キーワードを使う理由
     これについて中箱さんは「X(目標地点),Y(目標地点)」を使う案を示唆されていますが、いくつか問題があると思います。
    * X(目標地点),Y(目標地点)は“プレイヤーが直前に選択した地点の座標を返すもの”、条件式オプションで必要なのは“繰り返し処理内の一つ一つの座標”ですから、意味が違います。
    * 条件式内で本来の意味で「X(目標地点),Y(目標地点)」を使いたいときもあります

     ユニット指定の場合も同様で、「対象ユニットID」などは使いづらいです。

     というわけで、ここは専用キーワードでなければならないと思いました。


    3.事前登録案を配列指定にした理由
     SetAppointXXX案の欠点に対応しようとした結果、こういう案になりました。その「欠点」とは、以下のことです。

    (1) コマンドが四つ(ワヅキさんの統合案でも二つ)も増えてしまいます。これはユーザーへの負担になります。Appointというたった一つのコマンドへの機能追加のためだけ、しかもAppoint本体にとっては本質的でない追加のためだけということを考えれば、これはやりすぎです。

    (2) SetAppointXXXで登録中のデータも、SetAppointXXXが現在働いていているかどうかも、シナリオ側で知る方法がありません。このことはデバッグや実動検査時に大きな障害になります。

    (3) Appointコマンドの動作が、本来まったく無関係なインクルードに書かれた SetAppointXXX、ClearAppointXXX の影響を受けてしまいます。つまり、インクルードモジュールやサブルーチンの独立性が侵害されています。
     Appointコマンド自身によってはこの影響を防ぐことはできません。それでも何とか対策しようとした場合、次の手続きが事実上義務化されてしまいます。

    ・ Appointコマンド直前に必ず ClearAppointXXXを入れ、必要に応じてSetAppointXXXする。
    ・ 他に迷惑をかけないよう、Appointコマンド直後には必ず ClearAppointXXXを入れる。

     これだけでもめんどうですが、さらにこの対策の結果、「登録内容をのちに再利用することはできず、毎回入れなおさねばならない」という不便なことになります。

     というわけで、配列変数にすることによって欠点(1)(2)を除去し、変数名を指定することとオプションで有効にすることで欠点(3)を除去しようと思ったわけです。

     なお、リストではなく連想配列にしたのは、普及度が高いことと ForEach コマンドに合わせたことによります。実行時間はリストのほうが速いかも知れません。


    **** 補足 Appointコマンドを分割した場合 ****
     「ユニット選択」オプション付きの場合を別コマンドで独立させるような単純な分割の場合は、上記の案を変更する必要はないと思います――コマンドの機能そのものに変更はないので。

     座標だけを返すコマンドとユニットIDだけを返すコマンドに分割するなど、機能縮小をともなう分割の場合は、上記仕様のうち「専用キーワード」と「有効な値」の部分を二つに分割して割り当てることになるかと思います。

    (なお、以前述べたとおり Appoint分割には反対ですが、単純な分割にはそう強く反対しません――ややこしくなるだけとは思いますが、それ以上の問題は感じていません。機能縮小をともなう場合には強く反対させてもらいます。)

     以上です。

引用返信/返信 削除キー/
■5790 / inTopicNo.12)  コマンドの分離と対象絞り込みについて
□投稿者/ 乾 -(2008/02/20(Wed) 23:48:31) [ID:KPaseBs2]
     乾です。

    >>あかんべえさん

     確かに仕様から読み取らなければ理解できない部分が多いのは
    私のレスポンスの傾向としてあるようで、申し訳ありませんでした、
     今後、ツリー参加者に理解していただくために、より具体的に
    内容を説明させていただきます。
     指摘していただいてありがとうございました。

     また、既に一度意見を統合の方向でまとめた後での変更だったということで
    今までの議論を軽視ししていると誤解させてしまったようで申し訳ありません。
     
     とはいえ、地点選択時にも対象ユニットをコマンド選択の結果として参照させることが、
    誤動作を招く実装だという点についての意見に変化はありません。


    >>ワヅキさん

     ユニットの絞込み機能は、スペシャルパワーの対象選択の再現や
    攻撃の対象ユニット選択の再現を行うために必要だと考えています。

     例えば、SP消費以外の方法で信頼などを再現しようとしたとき、
    HPがすでに完全回復状態のユニットが選択できた場合、プレイヤーがユニットを
    選択した場合に

    「$(対象ユニット)のHPは回復できません」

    などと表示して、再度プレイヤーに選択をさせることになってしまいますが、
    事前に選択対象からはずしておけば、無駄なステップを省くことが出来ます。



     では、ここから本文に入ります。
     事前に私のスタイルについて明確にして置きますね。

     コマンドと関連のある他のコマンド・オプション・システム変数の数を絞り込む
    ことは「コマンド機能の理解」「バグ解析時の理解のしやすさ」を向上させることに
    つながるというのが私の認識です。

     ただし、一つのコマンドで実行される動作が少なくなり、同じ機能を
    実現する際に実行する必要のあるコマンドの数が増加する傾向にあることも
    理解しています。

     あかんべえさんが言うところの機能が少ないというのはこの部分をさしていると
    判断しましたが、この部分はもはやポリシーの問題ということで、一概にどちらが
    正しいと断言できる性質のものではないと思います。

     このようにポリシーの違いで議論が平行線になっている場合は、いったん第三者の
    意見を待ち、それを聞いた上でどちらが主流なのかを判断する方が、議論のループに
    陥ることを避けられるかと。

     ただ、このAppoint機能を使用するライブラリは構成が複雑になることが事前に
    予測されるため、地点とユニットを切り離して実装して解析のしやすさを優先する。
    という方針で行ったほうが妥当ではないか? と考える次第です。


     では最初に、地点選択と、ユニット選択の切り分けについてまとめてみました。

    --------------------------------------------------------------------------------

    【本体の動作】

    @地点の選択

     Appointコマンドの地点を選択機能は、SRC本体機能で言えばMAP兵器の
    範囲指定のときに表示される範囲選択をイベントコマンドで実現することが目的と
    いう認識でいます。(範囲指定を行わない場合は若干異なりますが)

    この選択の動作を確認したのですが、マップ兵器の選択画面で地点選択を行ったとき、
    ユニットが存在する地点を選択しても相手ユニットIDの値は""になるという
    振る舞いが確認できました。(※1)
     本体の現状の動作を模倣して実装するならば、地点選択時にはユニットIDに
    ついての情報の取得は行わない方針となる、ということです。

    (※1) 本体機能では攻撃などを行うユニットが「対象ユニット」になり、
    目標として選択されるユニットは「相手ユニット」になる仕様になっています)


    Aユニットの選択

     スペシャルパワーの選択や、MAP兵器以外の攻撃で、「ユニット」を
    選択した場合は、X(目標地点) / Y(目標地点) にユニットの存在する座標の情報が
    設定されていました。
     これはプレイヤーがマップのどこかをクリックした瞬間に、マップ上のその座標を
    目標地点に記録するという本体の仕様によるもののようです。
    ただし、X(相手ユニットID) / Y(相手ユニットID)でも、まったく同じ座標が
    取得できるため、AppointでユニットのIDを取得→ユニットIDから座標を取得
    の流れの方をヘルプに記載したほうがわかりやすいのではないかと思います。

    --------------------------------------------------------------------------------

    【選択結果の判定について】
     
     地点選択のためにAppointコマンドを使用した場合に、選択した地点にユニットが
    存在した場合、対象ユニットIDに設定する機能を盛り込んだ場合のシナリオ側での
    判定の仕方を考えて見ます。

     なお、この動作については、プレイヤーが選択をキャンセルした場合は
    X(目標地点) / Y(目標地点)が空文字列("")として設定されることを前提として
    考えています。

     プレイヤーが選択を終了した時点で対象ユニットIDが空文字列になるケースとして

     ・プレイヤーが地点を選択しその地点にユニットが存在しない場合
     ・プレイヤーが選択をキャンセルした場合

     の二つが考えられます。

     このため、シナリオでは、まずX(目標地点)・Y(目標地点)を参照することで
    最初にキャンセルが行われていることを確認する必要があります。
     この時点でシナリオ側は地点の座標を認識して動作を行うわけですから、
    その後、選択した地点にユニットが存在するかどうかなどの情報取得も
    座標を指定する方法で取得する
    (Info(マップ,X(目標地点),Y(目標地点),ユニットID)などで)
    方針で作りこんだ方が、順序だった作りこみになるのではないかと思うわけです。

    --------------------------------------------------------------------------------

     上記の条件を満たしてコマンドを実装するならば、Appointコマンドを
    AppointSpotコマンドとAppointUnitコマンドに分割し、AppointSpotコマンドでは、
    選択結果として参照するのはX(目標地点) / Y(目標地点)のみ、AppointUnit
    コマンドでは選択結果として参照するのは対象ユニットIDのみとするのが
    一番ではないかと思うわけです。

     Appointコマンドのオプションで切り分けるという手法も考えられるのですが
    ヘルプの記述が「Appointでユニット選択オプションがない場合は○○に
    ユニット選択オプションがある場合は××に」と、分岐して混乱を招く箇所が
    増えるのではないかと。

     以上、分割を推進する理由の整理となります。


    --------------------------------------------------------------------------------
     
     続いて、対象を絞り込む方法論ですが、「2.事前登録案」は実に見事で、
    SetAppoint系を明確に上回っているプランだと思います。

     この方式ならばシナリオサイドで登録済みのリストを表示させるなどしてデバッグ時に
    状況を確認することが出来、設定・クリアも柔軟に行えるため、今まで上がったプランでは
    もっとも筋の良さ、明快さで上位に立つプランだと思います。
     
     それで確認ですが、この事前登録リストとx y min maxによる範囲指定の両方が
    指定されている場合は座標の範囲内に収まり、かつリストにも登録されている物のみが
    選択対象として選択可能となる という認識でよろしいですよね?


     ただし、私は、一つのコマンドで選択できる属性は一つの方が好ましい というポリシーの
    人なので、これもAppointSpotコマンドでは"xx yy"形式のみがリスト指定可能、
    AppointUnitコマンドではユニットID、対象パイロット等のユニットを識別する情報のみが
    リストに設定可能という方式を希望します。


     「1.条件式オプション案」の方は、正直なところ、想定される用途を考えると
    扱いが難しいと思われます。
     何故かと言いますと、対象となるユニットを絞り込む過程などで、

    1.ユニットのパイロット数を測定する。
    2.そのユニットのパイロット全員を指定しInfo関数で特殊能力の有無を確認する
    3.一人でも能力あったら対象として設定を行う。

     と言うようなFor文などを利用した判定が行われることが予想できるため、Appoint系コマンドの
    オプションとして指定するには冗長に過ぎると思うわけです。
     また、事前登録式の最大のメリットである、コマンド実行前のリストの情報を
    シナリオサイドで参照することが可能、という部分がなくなってしまいますし。

     絞り込みの方式に関する意見は以上です。


     あと、MAP兵器の選択について、現状のAppoint系コマンドのオプションですと
    指定方法が足りないように思われるため、書式の追加案を作成しています。
    分量が多くなってしまっているため、レスを分けて提示させて頂きます。
引用返信/返信 削除キー/
■5791 / inTopicNo.13)  MAP兵器範囲選択の考察
□投稿者/ 乾 -(2008/02/20(Wed) 23:54:58) [ID:KPaseBs2]
     乾です。

     あと、MAP兵器の範囲型指定について、本体の実際の動作と比較してみると
    現在提示されているオプションでは表現しきれないのではないかということで、
    各形状毎の書式案をまとめてみました。

     以下をご覧ください。


     まず、MAP兵器により攻撃を行った際の操作方法を整理します。
     (範囲の表示され方の説明はAppointコマンドのx y min maxを
     使用した指定の方式に準じます)

     @M直 / M拡 / M扇L?

     1.中心座標・最低距離・最大距離を元に上下左右の方向の選択範囲が表示される。
     2.プレイヤーが選択範囲の任意の座標をクリックする。
     3.選択された座標が上下左右いずれの方向か判定、その座標の方向のみ
       選択範囲を表示する。
     4.プレイヤーが範囲の中でクリックを行うと選択範囲が決定する。

     AM線

     1.中心座標・最低距離・最大距離から延ばす線の終点を選択できる範囲が表示される。
     2.プレイヤーが選択範囲の任意の座標をクリックする。
     3.中心座標とプレイヤーがクリックした座標、最低距離、最大距離から判定された
       選択範囲が表示される。
     4.プレイヤーが範囲の中でクリックを行うと選択範囲が決定する。

     BM投L?
       
     1.中心座標・最低距離・最大距離から判定された選択範囲が表示される。
     2.プレイヤーが選択範囲の任意の座標をクリックする。
     3.プレイヤーが選択した座標を中心座標に、最低距離が0、最大距離がM投のレベルとして
    設定された選択範囲が表示される。
     4.プレイヤーがクリックを行うと選択範囲が決定する。

     CM全
     1.中心座標・最低距離・最大距離から判定された選択範囲が表示される。
     2.プレイヤーが選択範囲の任意の座標をクリックし、範囲が決定する


     この動作を考えると、M投・M全に関してはオプションとして用意する
    必要がないように見えることがわかります。


     M直 / M拡 / M扇L? の範囲指定ですが、こちらは
     4方向全ての範囲が表示されるパターンと、上下左右のいずれか1方向
    だけが表示されるパターンの2種類にの表示イメージを用意することで
    本体の選択機能と同等のことが行えるようになります。
     これを再現するための書式として以下の書式の追加を提案します。

     書式(M拡等)
     AppointSpot x1 y1 min max type [direction] options
    (x:ユニットのX座標 y:ユニットのY座標 min:最低距離 max:最大距離
    type:"M線" or "M拡" or "M扇L?" direction:"上" or "下" or "左" or "右"
    options:その他のオプション)

    M線・拡・扇を指定する際は、MAP兵器種別の後ろに選択範囲の方向を設定する。
     方向を省略した場合、四方向に選択範囲が表示される。



     続いて1回目の目標地点選択後に表示されるM線の選択範囲を再現するための
    書式については以下の指定をデフォルトとするのが分かりやすいと考えました。

     書式(M線1)
     AppointSpot x1 y1 min "M線" x2 y2 options
    (x1:ユニットのX座標 y1:ユニットのY座標 min:最低距離
    x2:M線の目標X座標 y2:M線の目標Y座標 options:その他のオプション)

    ※目標地点が最大距離の位置になるため、maxの指定はいらないと考えています。
      ただ、他のコマンドとイメージを合わせるために指定は出来るけれども
      参照はされないオプションとするのが良いかも知れません


     また角度による指定も斜め45度方向のみ選択可能とするときなどに役立つと思われるので、
    併案として残してみるのも良いかもしれません。

     書式(M線2)
     AppointSpot x y min max "M線" angle options
    (x:ユニットのX座標 y:ユニットのY座標 min:最低距離 max:最大距離
    angle:線が向かう角度 options:その他のオプション)

     angleの方式の方は、本体でも共通処理があるかどうか分からない部分なので
    採用するかどうかはKeiさんに一任が良いのではないかと。


     以上、MAP兵器の範囲選択の考察でした。


引用返信/返信 削除キー/
■5792 / inTopicNo.14)  コマンドの目的・意義について
□投稿者/ あかんべえ -(2008/02/23(Sat) 19:12:43) [ID:aYt7asoV]
     あかんべえです。

     乾さんは、
    >  Appointコマンドの地点を選択機能は、SRC本体機能で言えばMAP兵器の
    > 範囲指定のときに表示される範囲選択をイベントコマンドで実現することが目的と
    > いう認識でいます。(範囲指定を行わない場合は若干異なりますが)

    と書かれ、続いてAppointコマンドの仕様を本体のMAP兵器動作に従属させる発言をされています。

     これはまったく違います。座標選択に限ったとしてもAppointコマンドの目的はあくまで「プレイヤーによる座標の選択」であり、「MAP兵器の範囲選択の実現」は数多くの選択対象限定方法の一つにすぎません。
     これはたいへんな問題と思います。なぜなら、このリクエストの独特な意義は応用範囲の広さにあり、もしMAP兵器の再現と認識されてしまうのなら、リクエスト自体の意義が見る影もなくなってしまうからです。したがって、このツリーで積み上げてきたすべての議論も、もちろんその一部であるコマンド分割議論も吹っ飛んでしまうほどの大問題だと認識しています。
     なのでこの書き込みでは、この問題だけを優先し、独立して扱います。


     このリクエストは、さいしょはコウさんによって「議論を経ない単独リクエスト」として始められ(リクエスト掲示板、2624)、対してあかんべえが意見交換掲示板への移行を要請(同、2625)、コウさんが応じて下さりここでの議論がはじまりました。以下、このときのあかんべえの発言の一部を再掲します。

    > このリクエストは、たいへん応用範囲が広そうです。パッと思いついただけでも、プレイアビリティの向上、Launch や Create コマンドなどとの組み合わせ、いわゆる「盤外砲撃」「大魔法」などシナリオ固有のゲームシステムへの利用、NPCユニットへの行動指定、デバッグなどあります。
    >  だからこそ、もし意見交換掲示板で議論すれば、実り豊かな追加提案が出るかもしれない、そういうリクエストだと感じました。

     つまり、応用範囲の広さがなければ意見交換掲示板への移行要請もなかったし、ここで議論が始められることもなかっただろうということです。


     移行後もしばらくは、MAP兵器エミュレートはまったく議論に現れませんでした。経過を言えば、
    (1) No.5645(議論開始後4つ目の発言)で Unnamed さんが「Appoint x y min max」を提起。
    (2) No.5648(七つ目の発言)であかんべえがそれを「攻撃目標選択画面のようなものを実現させる手段」と表現。これが武器仕様シミュレート関連発言の初出だと思います。
    (3) それを受けて、No.5649(八つ目)で Unnamed さんがオプション「直」「拡」「扇」「線 angle」を提起。ここではじめて MAP兵器関連の議論が登場します。


     乾さんの認識は、ひょっとするとその後の議論での諸発言を誤解されたものではないでしょうか?

     コウさんのとりまとめでは「リクエストの趣旨は「SPやMAP兵器のような操作でユニットや地点の選択を可能とするコマンド」」と書かれています(No.5717, No.5732, No.5755)。
     しかし、この発言での「MAP兵器」は選択操作方法のたとえにすぎません。MAP兵器動作をコマンド仕様の基準にすべきほどの「目的」とするものではありません。

     その後、「当初の用途案は武器・アビリティ選択のエミュレート」というUnnamedさんの発言(No.5754)がありました。
     しかしこれは、オプションの用途案が武器・アビリティ選択のエミュレートということであって、Appoitコマンドの目的そのものがMAP兵器動作の実現だということではないと思います。


     以上のように、AppointコマンドにとってMAP兵器風の選択は「オプションを通じた選択対象絞込み方法の一種」にすぎず、それはコマンドの「目的」ではありません。またこれらのオプションは「マップ兵器と同じような範囲選択」をするものであって、イベントコマンドでマップ兵器動作を再現するものではありません。したがって、コマンドそのものの動作が本体のMAP兵器動作をまねねばならないということはありません。

引用返信/返信 削除キー/
■5794 / inTopicNo.15)  ここまでのまとめ
□投稿者/ コウ -(2008/02/23(Sat) 22:41:52) [ID:fqOTLlqC]
    ども、コウです。

    選択対象の絞込み機能は、事前登録案が一番良さそうですね。
    シンプルなやり方もあったのに、どうも難しく考えすぎていたようです。
    使うのは、リストより配列の方がいい…かな。
    IfやらForやらForEachやらで操作するなら配列の方が都合良いでしょう。

    マップ兵器型の範囲選択は、本体の挙動を鑑みると、オプションよりも
    ケース毎に書式を分けた方が良さそうですね。
    乾氏の書式を参考に纏めて見ましょう。

    あと、今更ですが「マップ外選択可」を外しちゃおうと思います。
    振る舞いとしては「常に受け付けない」で。
    最初から「あってもなくてもどっちでもいいけど、とりあえず入れておこう」だったわけですし
    積極的に入れるべきという意見が無ければ消す方向で行きたいと思います。
    optionのシンプル化の一環ですな。


    以下、ここまでのまとめ。

    Appointコマンド
    マップ上でプレイヤーによる座標、ユニットの選択を行う

    書式1
    Appoint [x y min max] [option]

    書式2
    Appoint x y min max type [direction] [option]

    書式3
    Appoint x y min max 線 x2 y2 [option]

    書式4
    Appoint x y min max 線 angle [option]

    指定項目    説明
    x y min max  (x, y)を中心として範囲[min-max]が選択可能。これらを省略すると選択範囲は
             マップ全体となります。(省略可)
    type       "直" "拡" "扇L?" のいずれかを指定する。扇の場合はレベルを指定すること。
    direction    "上" "下" "左" "右"を選択可能。省略時は4方向の範囲を表示する。(省略可)
    x2 y2      線・移型マップ兵器の目標地点の座標を指定する。
    angle      線・移型マップ兵器の発射される角度を指定する。
    option      各種設定(省略可)

    解説
    optionには以下のものが指定可能です。
     マップ選択  マップの地点を選択する待機状態になります。
             コマンド終了後、選択したマップ地点の座標がX(目標地点)と
             Y(目標地点)で取得できます。
     ユニット選択 ユニットだけを選択する待機状態になります。
             選択したユニットのパイロットが対象パイロットに、
             ユニットIDが対象ユニットIDに設定されます。
     In 「array」 選択可能な対象を設定した配列名をarrayに指定します。
             x y min maxによる範囲指定が有効な場合は、範囲内で配列に設定されている
             もののみが選択対象になります。
             マップ地点選択の場合、x,y形式の値が配列に設定可能、
             ユニット選択の場合、ユニットID、パイロット名、パイロット愛称が設定可能。
             設定可能でない形式が設定されていた場合は無視されます。
     キャンセル可 マウスの右ボタンクリックを使ったキャンセルを可能にします。
              キャンセル実施時は、マップ地点選択時はX(目標地点)とY(目標地点)に
              空文字を返し、ユニット選択時は対象ユニットIDに空文字列を設定します。
     非同期    選択直後にマップの再描画を行いません。(範囲が表示されたままになります)
             選択範囲の表示を消す場合はRedrawコマンドを実行してください 

    コマンドを実行すると、マップ画面にてプレイヤーによる座標選択を待ちます。
    マップ地点選択の場合は、選択された座標をX(目標地点)とY(目標地点)に代入し、ユニット選択の場合は、
    選択されたユニットのパイロット名を対象パイロットに、ユニットIDを対象ユニットIDに代入する。

    書式2はM拡・M直・M扇型マップ兵器の選択範囲を指定させる場合に使用します。
    書式3,4はM線型マップ兵器の選択範囲を指定させる場合に使用します。
    マップ兵器用の範囲のイメージについては マップ攻撃に関する属性 を参照してください。


    以下は都合の良い方でお願いします。

    配列を渡した際の参照先
    1.配列のインデックス
    2.配列の要素

    書式4を選択した場合のmaxの有無
    1.書式2,3とのフォーマット統一の為に維持
    2.終端は座標で指定しているため排除

    キャンセル選択時の挙動
    1.空文字を返す
    2.何らかの整数を返す

    「ユニット選択」指定時に「キャンセル可」を指定しなかった場合の挙動
    1.「キャンセル可」を無くして常にキャンセル可とする
    2.選択対象がなかった場合、キャンセル可が無くてもキャンセル同様の動作をさせる
    3.ユニットの存在しない座標を選択することで特異値を返す
引用返信/返信 削除キー/
■5795 / inTopicNo.16)  Re[2]: コマンドの分離と対象絞り込みについて
□投稿者/ あかんべえ -(2008/02/24(Sun) 00:26:14) [ID:f1XaabwY]
    2008/02/29(Fri) 18:13:36 編集(投稿者)

     ども、あかんべえです。乾さんへのレスですが、とても長いです。ここまでの議論の展開上、詳細に語るべきと判断しました。


     乾さん、まず、提案理由開示の件、冷静な対応ありがとうございました。


    <「ポリシーの違い」ではないこと>

    >  コマンドと関連のある他のコマンド・オプション・システム変数の数を絞り込む
    > ことは「コマンド機能の理解」「バグ解析時の理解のしやすさ」を向上させることに
    > つながるというのが私の認識です。

     いや、シンプルなコマンドを求める「ポリシー」一般は別に否定していませんよ。そういう問題ではありません。もっとずっと具体的な問題、<AppointコマンドでユニットIDを設定しないことが、どのように「コマンド機能の理解」「バグ解析時の理解のしやすさ」の向上につながるのか>ということです。それをずっとお聞きしているのに、説得力のある答えはまったく返ってこない。で、ご提案を支持するわけにはいかないな、となってるだけです。
     これでは、同じポリシーの人にとってもメリットがあるとは思えません。実体をともなわない、ポリシー教条主義の押し付けにしか見えないのです。

    >  あかんべえさんが言うところの機能が少ないというのはこの部分をさしていると
    > 判断しましたが、この部分はもはやポリシーの問題ということで、一概にどちらが
    > 正しいと断言できる性質のものではないと思います。

     違います。ポリシーなどということではなく、Appoitコマンドによる設定情報という特定のことについてです。わざわざ機能を減らす以上それに見あったメリットの提示を求めているのに、機能を減らすこと自体がよいことのように言われるので、“それはないでしょう”と答えたにすぎません。

     乾さんは、私のスタンスに対しても大きく誤解しています。乾さんと異なる「ポリシー」を対抗させるなどという立場ではありません。そもそも、多機能コマンドか多数のシンプルなコマンドかという問題に対して固定した「ポリシー」など持ってもいません。
     議論を冷静に読み返してもらえばご理解いただけるはずですが、私のスタンスは、まず提案の趣旨と論拠を理解し、そのために必要に応じて質問し、ついでその妥当性や限界を吟味し、自分でも提案の長所と短所を探してみた上で、最後に提案を評価してみる、というだけです。ツリーの参加者として、議論の積み上げから生まれた統合案に一定の評価はありますが、それとてこだわりはなく、ある程度の理由さえあればあっさりと変更可能なものです。つまり、乾さんの言われる「第三者」の立場です。

     そもそも、「ポリシーの違いで議論」し他人と争うという立場に、疑問を感じます。
     自分の「ポリシー」でリクエストの追加希望をするのは、別にかまわないと思います。
     問題を分析し発言するとき「ポリシー」が反映してしまうのは、やむをえないことだと思います。
     しかし、個人の「ポリシー」のために他人の案や意見を否定したり、多くの人の議論により生まれた仕様を自分の「ポリシー」に合うよう要求するのはどうかと思います。
     なぜなら、発言者もリクエスト機能を使うことになる人も「ポリシー」は多様だからです。異なる「ポリシー」に配慮した発言でないと通用しないし、仕様を吟味するとき自分の「ポリシー」を超えた観点から見ていかないと皆にとって良いものは生まれません。

     でも、ここにきて、乾さんの出される論拠がどうしてこう、無理難題にしか見えないのかわかった気がします。それは<乾さんのポリシーだけを考えた論拠>だからです。これでは「第三者」には通用しません。違いますか?


    <今回出された論拠について>

    > @地点の選択

     MAP兵器の動作時、相手ユニットIDに空文字が設定されるのは次の理由からと思います。つまり、(1)武器使用時には相手ユニットIDを設定するのが原則 (2)しかしMAP兵器はユニットを目標にするものではない、という事情です。
     これはまったくMAP兵器独自の事情であり、「プレイヤーによる座標選択」という別の目的を持つAppointコマンドの事情ではありません。このことは、別メールで述べたとおりです。
     しかし、仮にMAP兵器動作に従った場合でも、乾さんの主張とは逆の結論になります。これは、「空文字を設定する」という動作です。「ユニットIDについての情報の取得は行わない」という動作ではありません。
     まあ、MAP攻撃は必ず攻撃イベント・使用イベントをともない、イベントはふつうユニット関係システム変数を設定するのだから、イベントならぬAppointコマンドで同じ動作をというのはやっぱり無茶でしょう。


    > Aユニットの選択

     う〜ん、この項は、論拠たるべき「本体の動作」と最後のご主張とがまったく切り離されていますね。ご提案を支持する理由にはならないでしょう。
     それどころか、ご報告の本体動作は、これまでのご主張への判断材料を与えてくれています。
    >  スペシャルパワーの選択や、MAP兵器以外の攻撃で、「ユニット」を
    > 選択した場合は、X(目標地点) / Y(目標地点) にユニットの存在する座標の情報が
    > 設定されていました。

     これはつまり、ユニット選択時に座標情報が設定されることが、「コマンドの理解」にとっても「バグ解析時の理解のしやすさ」にとっても何の障害にもなっていない、ということです。
     また、既存機能がユニット選択時に座標情報を設定するということは、Appointコマンドで設定しないのは不自然だということにもなります。

     こちらは追加情報です。
    >  これはプレイヤーがマップのどこかをクリックした瞬間に、マップ上のその座標を
    > 目標地点に記録するという本体の仕様によるもののようです。

     もしそうだとすると、ご主張に反して「ユニット選択時にマップ座標を設定しないようにするのは不可能」という結論になりますが、ソースコードを見るとそうではない可能性が高いです。ちょっと疑念もあり、未確定情報と扱ってほしいのですが、目標地点を記録することはSRCの各機能ごとに逐一設定されているようです。


    > 【選択結果の判定について】

     仮定と特殊ケースを積み上げすぎです。乾さんの議論を追うと、「X(目標地点) / Y(目標地点)が空文字列("")として設定される」という仮定は事態を左右しないので度外視しても、
    (1) 選択地点にユニットがなかった場合とキャンセル時に対象ユニットIDがどうなるかは未議論ですが、両方とも空文字列が入り、したがってキャンセルされたことの特定は 座標データ X(目標地点)などで行わねばならないと仮定し、
    (2) キャンセル時を他と分別して把握する必要があるケースで、
    (3) なおかつ、この分別をユニット情報の取得に先立って行う場合、

    この場合はじめて、ユニット情報取得の前に座標情報が取得されているのだから、ユニット情報はAppointコマンドからの取得でなくて座標情報から Info関数で取得する方針が「順序だった作りこみになる」かもしれないわけです。この議論はいくらなんでも苦しすぎます。
     しかも、乾さんの仮定と論理をすべて承認したとしても、結論は「このケースではユニット情報は座標情報から取得するのが有力」というだけです。乾さんの主張はこれと違って、「ユニット情報の取得は、座標選択時のAppointコマンドにとって、無いほうがよい」というものでしょう? こちらを証明してください。


    > とはいえ、地点選択時にも対象ユニットをコマンド選択の結果として参照させることが、
    > 誤動作を招く実装だという点についての意見に変化はありません。

    > 地点とユニットを切り離して実装して解析のしやすさを優先する。

    > ヘルプの記述が「Appointでユニット選択オプションがない場合は○○に
    > ユニット選択オプションがある場合は××に」と、分岐して混乱を招く箇所が
    > 増えるのではないかと。

     これらのご発言はいずれも対話になっていません。たとえば、一つ目の引用の「誤動作」については、乾さんの出された例はAppointの挙動に対する誤解であり起こりえないことをすでに示しています。ご主張を続けられるなら、(1)あかんべえの指摘は誤りであり、やはり起こりえることだと示すか、 (2)別の妥当な例を示すか が筋でしょう。二つ目、三つ目も同様です。議論を踏まえ、ご主張に当てはまる実例が存在することを示してください。


    <「対象を絞り込む方法論」について>

     乾さん、私の改良案への高いご評価、ありがとうございます。
     便乗してしまいますが、もしできますなら、この案が「柔軟な対象絞込み」をリクエストに即座に入れることには反対の立場から提出されたということ、またこの案は原案の手直し版にすぎませんが、原案の欠点に注目したことが原案の否定ではなく手直しを生んだことをご吟味いただければ幸いに思います。


    >  それで確認ですが、この事前登録リストとx y min maxによる範囲指定の両方が
    > 指定されている場合は座標の範囲内に収まり、かつリストにも登録されている物のみが
    > 選択対象として選択可能となる という認識でよろしいですよね?

     固執はしませんが、その動作がすっきりしてるし、SRCでのオプション重複の通例でいけばそうなると思っています。


     以下、判別式オプション方式についてですが、
    >  と言うようなFor文などを利用した判定が行われることが予想できるため、Appoint系コマンドの
    > オプションとして指定するには冗長に過ぎると思うわけです。

     このような長い判定の場合は、判別式の中にサブルーチン呼び出しを含めれば可能です。
     それに、これが不可能だと仮定しても、この方式への否定的評価にはつながらないと思います。
     なぜなら、<汎用的な判別を簡潔に実現でき、登録手続きも必要ない>ということがこの方式の美点だからです。
     一般に、簡潔な仕様はどこかで切り捨てられる部分が出てきます。この場合、「登録手続きが必要ない」ことが、ご指摘の「事前に情報取得ができない」ことをともないます。長い判定は関数呼び出しでクリア可能ですが、そうした場合にはイベントコマンドが必要になり、簡潔さという長所が無効になってしまいます。
     このように、欠点と長所はしばしば一体で、判別式オプション方式にとってこれらの欠点は織り込み済みのものです。事前登録方式も同様で、イベントコマンドと登録手続きが不可欠という犠牲のもとで、より高い柔軟性を確保しています。

     疑問に思うのは、なぜ乾さんは判別式オプション方式か事前登録式かという問題に「ポリシーの違い」という論理を適用しないのか、ということです。これこそポリシーの違いであり、したがって「一概にどちらが正しいと断言できる性質のものではな」く、対立案の欠点をあげることで否定し去ることはできない問題に見えるのですが。

引用返信/返信 削除キー/
■5797 / inTopicNo.17)  Re[2]: MAP兵器範囲選択の考察
□投稿者/ あかんべえ -(2008/02/25(Mon) 18:39:53) [ID:QTltKd4Y]
    2008/02/26(Tue) 15:51:42 編集(投稿者)
    2008/02/25(Mon) 18:49:32 編集(投稿者)

     ども、あかんべえです。

     乾さん、ご提案の検討の前に確認しておきたいのですが、このご提案の前提として、「Appoitコマンドの基本性格を『演出動作を含め、MAP兵器全動作を再現するコマンド』に変更する、またはこの性格を追加する」ご意見であると考えていいですね?

     というのは、以下の理由により、ご提案の仕様はコマンドの性格変更によってはじめて構想しえるものだからです。

    (1) 既存のイベントコマンドにおける「書式」はすべて、そのコマンドのもっとも基本的な機能に属することに限られています。複数の書式が表しているものは、以下がすべてだと思います。
     コマンドの複数の基本的設定方法(Ask, Center, Local, Wait)
     複数の制御構造(Do, ForEach, If)
     非表示や取り消しを別書式にしているもの(ChangeUnitBitmap, IntermissionCommand)
     同じ機能の別の記法(Set)

     また、ヘルプで書式はすべて対等に扱われており、ユーザーはすべての書式がそのコマンドの基本的目的を表すものだと受け止め、まず書式を通じてコマンドの性格・目的を把握します。
     そして、ご提案は書式の過半を MAP 攻撃関係で占めるようにするものです。

    (2) 「直」「拡」「扇」のMAP攻撃での一方向のみの領域表示は、プレイヤーによる座標指定や座標指定を通じた方向指定などをともなうものではなく、演出上の機能です。したがって「direction」指定機能は、「プレイヤーによる座標指定」という目的とは無関係で、「演出面を含めたMAP攻撃の再現」というコマンド目的設定によってはじめて発想しえるものです。

    (なお、乾さんの環境で、MAP攻撃の発動に先立ち二度のクリックが必要というのは確かなのでしょうか? こちらでは、一度のクリックだけで動作しています。戦闘アニメ表示、メッセージスピードなどの設定には無関係に、常に一度だけです)


     というわけで、ご提案はコマンドの性格・目的変更の提案であると受け止めています。これでよろしいですね?
     また、これまで乾さんから、「プレイヤーによる座標指定」という目的の廃止という提案はなかったと思います。したがって、「Appintコマンドを『MAP攻撃の再現』と『プレイヤーによる座標指定』の二つの目的を持つ複合的なコマンドにする」というご意見であり、そのようなポリシーであると解釈してよろしいですね?

    (2/26 編集追記)
     なお、この書き込みの意図は、「意思確認」です。また、乾さんにその意図がなかった場合は「目的が変わっちゃうよ」という意味になります。
     No.5792を書いたときには「コマンド目的の誤解では」と思ってましたが、その後、明確なご意図があるかもしれないと思い直しました。
     けっして「詰問」の意図はありません。そのようにとられた方がおられたら、私の表現力不足です。その場合はごめんなさい。

引用返信/返信 削除キー/
■5798 / inTopicNo.18)  Re[2]: ここまでのまとめ
□投稿者/ あかんべえ -(2008/02/25(Mon) 20:35:28) [ID:QTltKd4Y]
     コウさん、ご苦労様です。

    > 選択対象の絞込み機能は、事前登録案が一番良さそうですね。

     両論併記リクエストにする理由のうち、二つ目の「設計思想」関連、かんたんすぎたようなので再説明させていただきます。

     事前登録方式というのは、SRCの既存機能からみて、相当飛躍した機能なのですね。
     これは、<事前にイベントコマンドを組まないと動作しない>オプションなんです。そうまでして「柔軟な汎用性を実現したい」という強烈な主張を持った機能です。
     これは、既存のコマンドにはまったく類例がありません(Call も、「それ自体がサブルーチンを呼び出す」という役割りなので、このオプションが「これまで処理された別の場所のイベントコマンドに依存している」のとは違います)。このオプションは、いわば、「独立して完結していない」のですね。ソフト開発者のなかには、そういう仕様を拒絶されるかたもおられるかもしれません――ひょっとしたら、Keiさんも。

     「飛躍」と言う点では、判別式オプション方式もかなりのものです。何てったって<式形式のオプション>ですから。けれど、事前登録方式は、そのずっと上を行きます。
     「柔軟な判別」という需要は他の機能にもあるので、どちらが採用された場合も後に他のリクエストが続きそうです。
     初心者対応の面からコマンド仕様をどう考えるか、ということもからみます。

     というわけで、この選択はSRC全体の設計思想の問題であり、まだしも「おとなしい」判別式オプション形式もそえて、Keiさんに判断をゆだねたいと思うのです。
     リクエストの採用可能性ということもあります。両方式はいずれも「飛躍」したものなので、方式特有の設計が Keiさんの設計思想と合わず不採用になることを防ぎたい、と。

     これらの事情を承知の上で、それでもあえて事前登録案一本に絞りその実現を目指そう、と言われるのなら私も支持します。でも、そこまで決意した場合でなければ、両案併記のほうがまだしも安全確実かと。


     マップ兵器関連のことは、乾さんへのレスに書きましたのでお読みください。


     「マップ選択」オプションの新設ですが、これだとこのオプションか「ユニット選択オプション」かのどちらかを指定しなければならなくなります。
     コマンドが一つで、かつ各オプションは座標かユニットかどちらか一方の情報だけ設定する仕様は、これまでの案とも乾さんの案とも違っています。何か積極的な理由があるのでしょうか。
     その理由しだいで改めて考えたいと思いますが、現時点での印象では中途半端な気がします。「座標選択が機軸、座標のユニット情報を追加」というこれまでの案のまとまりがなくなり複雑なコマンドになり、他面、ユニット選択専用コマンドを明示して「ユニット選択もできる」ことを直截に示すということもありませんから。

引用返信/返信 削除キー/
■5799 / inTopicNo.19)  Re[3]: ここまでのまとめ
□投稿者/ コウ -(2008/02/26(Tue) 00:54:59) [ID:fqOTLlqC]
    ども、コウです。
    コマンドの意義とか、そういう難しいことは一切考えてません。


    >  両論併記リクエストにする理由のうち、二つ目の「設計思想」関連、かんたんすぎたようなので再説明させていただきます。
    対象を細かく限定するための条件式を、判別式で実現するためには関数の呼び出しを含めればよい、とされていますが
    これがどういった処理の流れになるのか理解できませんでした。
    事前登録式はその字の通り、事前に限定した変数をコマンドへ渡すだけなので、判りやすいのですが。

    あと、少なくともポリシーに合わないので却下、という事態は無いんじゃないかと。
    両案の違いは実質呼び出すタイミングだけですから、もし却下されるとしたら実装自体が難しい場合だと思います。
    まあ実現難易度はわからないので、考えても仕方ありません。
    ここで話し合うということは、ユーザーにとって都合の良い形式を、ユーザーで考えるためなわけですから
    私でも理解できる程度に判りやすい形式、を考えてるわけです。


    >  マップ兵器関連のことは、乾さんへのレスに書きましたのでお読みください。
    書式を追加するのに反対、ということでいいんでしょうか?

    乾氏の文章からは、マップ兵器の選択範囲を実現するための書式を提案していることしか読み取れませんでした。
    私もoptionのみで実現するのは指定が冗長になり過ぎるなぁ、と思ったので追加した次第です。


    >「マップ選択」
    すいません、書いてるうちに(省略可)をどっかに吹っ飛ばしてしまったようです。
    ユニット選択はあってマップ選択はないのか?という疑問に対するエクスキューズとして
    明示的に省略可能であることを示すために併記してみました。
    が、逆に紛らわしいかも知れませんね。
    解説中に「ユニット選択を指定しなかった場合は座標を待機する」ように書くだけに留めておきます。


    とりあえず説明は簡潔にお願いします。
    正直、余計な修飾が多すぎて、本文が読み取り難くて敵いません。
引用返信/返信 削除キー/
■5800 / inTopicNo.20)  気になった事
□投稿者/ 猫王@管理 -(2008/02/26(Tue) 02:39:17) [ID:HiLnpauB]
    こんばんは。猫王です。

    やりとりを拝見しましたが、いくつか気になった点がありますので、
    参加者に注意して頂きたいと思います。


    1.文章は出来るだけ短く要点のみを伝え、長文は避ける事

    やはり読み易いのが一番です。
    長文が連発されている現状では当事者以外読む気がなくなってしまいます。


    2.攻撃的な態度を取らない事

    相手の意見を否定するあまり、攻撃的な態度になっていませんか。

    色々な意見が出る中で自分の考えを主張する為、熱くなるのは分かります。
    まずは文章を書く手を休めてクールダウンしましょう。


    宜しくお願いします。
引用返信/返信 削除キー/



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

このトピックに書きこむ

過去ログには書き込み不可

Pass/

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

- Child Tree -
- Antispam Version -