ＳＲＣ意見交換掲示板Mk2 [One Topic All View / リクエスト完了 / Page: 0]

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

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

■5854 / inTopicNo.1)

　移動に必要な移動力を取得する関数

□投稿者/ 中箱 -(2008/03/28(Fri) 13:37:06) [ID:TdSzoAHN]

2008/03/28(Fri) 13:41:37 編集(投稿者)

どうも、中箱です。

　１．指定するユニットが、現在地点から指定する座標まで移動する場合に、費やす移動力が取得できる関数「TotalMoveCost(仮)」
　２．指定するユニットが、指定する地形に進入するために必要な移動コストが取得できる関数「MoveCost(仮)」

という、移動力に関係する二種類の関数のリクエストを考えています。

●１の書式案
書式１
TotalMoveCost(ユニットＩＤ,移動先X,移動先Y[,出発X,出発Y,陣営,最大移動力,位置,移動方法,他？])
書式２
TotalMoveCost(ユニット名,移動先X,移動先Y,出発X,出発Y,陣営[,最大移動力,位置,移動方法,他？])
　"ユニットＩＤ"or"ユニット名"で指定したユニットが、
　座標("移動先X","移動先Y")まで移動した時に費やす移動力を返す。
　移動力が足りない場合やそもそも進入できない場合は「0」を返す。

・ユニットＩＤ、ユニット名
　　必要な移動力を算出する際に、基準とするユニット。
　　書式１の場合はメインパイロット名orユニットＩＤを指定。
　　書式２の場合は、ユニット名を指定する
・移動先X,Y
　　目標地点の座標を指定。

・出発X,Y
　　これらの指定を行った場合、"ユニット"が座標("出発X","出発Y")に存在するものとして費やす移動力を算出する。
　　省略、もしくは「-」を指定した場合は"ユニット"の現在座標を用いる。
　　書式２の場合は省略不可。
・陣営
　　陣営名を指定する。書式２の場合は省略不可。
　　書式１で、これを省略もしくは「-」を指定した場合は現在の陣営を用いる

・最大移動力
　　算出時に考慮する移動力の最大値。
　　省略もしくは「-」の場合は、ユニットの移動力が指定されたものとする。
　　数値のほか、例外的に「制限無し」が指定可。
　　※SRCのソースを見た所、考慮する移動力の最大値を設定することで処理が短縮できそうだったので入れている設定項目です。

・位置
　　ユニットのAreaを指定する。
　　省略もしくは「-」の場合、
　　書式１の場合はユニットの現在の位置、
　　書式２の場合は、CreateやLaunchなどでそのユニットが配置された直後の位置にいるとみなす。
・移動方法
　　ユニットの移動方法を指定する。
　　指定は「通常」「-」「ジャンプ」「テレポート」のいずれか。
　　省略や「-」「通常」の場合は通常移動とみなす。

○関数の返り値案
　・ユニットの移動力が"最大移動力"だけあっても指定した座標に進入できない場合は「0」を返す。
　・"最大移動力"に「制限無し」を指定した場合は、絶対に一度の移動では進入できない場合に「0」が返る。

　・通過できるが停止できない場合は「(-1 * 費やす移動力)」を返す。（他の味方ユニットや、透過移動時に敵がいる座標など）
　・それ以外は、「費やす移動力」を返す。

例：
　マップ上に居る、とあるユニットが次に移動したとき、座標x,yに移動できるかどうかは
　　TotalMoveCost(あるユニット,x,y) > 0
　という式で判別できる。（式が成立するなら「移動できる」ということ）

　マップ上に居る、とあるユニットが、(一回の移動で)座標x,yに移動するために最低でも必要な移動力は
　　TotalMoveCost(あるユニット,x,y,-,-,-,制限無し)
　で得られる。

○
今の所考え付く論点は、
・書式２が必要かどうか
・"出発X"以下が必要かどうか
　（最低でも"移動方法"は必要だと思いますが、他の省略可な引数はどれもイベントコマンドと併用することで代用が利きそうです）
・返り値は「費やす移動力」で良いか（移動できるか否かを0か1で返す関数もそれはそれで分かりやすそう）
・通過できるが停止できない場合を区別する必要はあるか。
・ＺＯＣや移動停止地形によって強制停止させられる座標かどうかは区別できなくて良いか。
・"最大移動力"を省略した場合は「ユニットの移動力」を指定した場合と同じで良いのか
・もっとふさわしい関数名は

・他に、設定できた方が良いものはあるか。
　例えば、
　　仮にＺＯＣを無視した場合の必要移動力
　　仮にユニットの移動可能地形に「水」が加わった場合の必要移動力
　…などが取得できたら便利そうな気もする。需要がないなら不要だろうけども

あたりでしょうか。

●２の書式案
書式１
MoveCost(ユニット,地形名[,位置,移動方法,他？])
書式２
MoveCost(ユニット,X,Y[,位置,移動方法,他？])

　書式１の場合、"ユニット"で指定したユニットが、"地形名"に移動する場合の移動コストを返す。
　書式２の場合、"ユニット"で指定したユニットが、座標("X","Y")にある地形に移動する場合の移動コストを返す。
(TotalMoveCostと違い、ユニットが現在いる座標は無関係です)

・ユニット
　　基準とするユニット。
　　メインパイロット名orユニットＩＤのほか、ユニット名も指定可。
・地形名
　　対象となる地形の地形名称
・X,Y
　　対象となる地形のある座標

・位置
　　ユニットのAreaを指定する。
　　省略もしくは「-」の場合、
　　書式１の場合はユニットの現在の位置
　　書式２の場合は、CreateやLaunchなどでそのユニットが配置された直後の位置にいるとみなす。
・移動方法
　　ユニットの移動方法を指定する。
　　指定は「通常」「-」「ジャンプ」「テレポート」のいずれか。
　　省略や「-」の場合は通常移動とみなす

○返り値案
　・進入できない場合は「9999」を返す。
　・通過できるが停止できない場合は「-1 * 移動コスト」を返す。（ジャンプ移動した時の、地形タイプが「空」になっている地形など）
　・それ以外は、「移動コスト」を返す。

○
論点は、
・書式２が必要かどうか。
・進入できない場合は「0」ではなくて「9999」を返すので良いか。
　（ソースを見る限り、「0」よりは「9999」に近い扱いになってるみたいなので、とりあえず案としては「9999」にしてみました）
・通過できるが停止できない場合を区別する必要はあるか。
・他に、設定できた方が良いものはあるか。
・関数名

あたりかなと。

●
ご意見、説明不足な所の指摘などあれば是非。
もちろん論点候補として上げた点以外についてでも。

では

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

■5860 / inTopicNo.2)

　Re[1]: 移動に必要な移動力を取得する関数

▲▼■

□投稿者/ Mr -(2008/04/03(Thu) 10:43:03) [ID:msSebhOJ]

どうも、Mrです。
口先だけロートルの分際で最近いろんなところに出没しててウザイですよね。でもやめない。

全体として

関数１「指定したユニットが指定したマスにたどり着けるかどうか」
関数２「指定したユニットが指定したマスにたどり着くにはコストをいくつ消費するか」
関数３「指定したユニットが指定したマスでコストをいくつ消費するか」

としませんか？

これなら仮想値が欲しい場合は関数２単独で使い、行ける範囲内で値が欲しい場合は関数１と組み合わせで使えます。

関数名案（パラメータに陣営が無いのは後述）
関数１　Movable(ユニットＩＤ,移動先X,移動先Y[,出発X,出発Y,最大移動力,位置,移動方法])
関数２　TotalMoveCost(ユニットＩＤ,移動先X,移動先Y[,出発X,出発Y,最大移動力,位置,移動方法])
関数３　MoveCost(ユニットＩＤ,{地形/X,Y}[,位置,移動方法])

関数１の仕様として、最大移動力に無制限を設定すると、どうやってもたどり着けない場合に0が返る。
返すのは1 or 0のみ。

以下、中箱さん提案の関数１、２に関してです。

パラメータ等

関数１について

＞・陣営
陣営を指定する意味を見出せません。ユニットＩＤで指定すれば不要だと思われます。

＞・最大移動力
ここに「加速」「神速」「覚醒」「再動」を指定すると、各ＳＰ適応時の結果が返るといろいろ使えそうです。

「通過できるが停止できない場合」でも、仮に停止できるものとしてコストは表示するべきです。
この関数では純粋に総移動コストのみを求めた方がよいでしょう。

書式２は不要でしょう。こういった一意性が大事な関数は、どうせユニットＩＤで指定しますし。

関数２について

＞・進入できない場合は「9999」を返す。
返すのはあくまで0にすべきだと思います。そっちの方が使いやすいからです。

といったところです。他に気がついたことがあればまた。

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

■5862 / inTopicNo.3)

　仕様案の理由が含まれたレス

▲▼■

□投稿者/ 中箱 -(2008/04/05(Sat) 20:19:41) [ID:TdSzoAHN]

2008/04/06(Sun) 00:10:05 編集(投稿者)

#4/6 00:00過ぎ、一部修正・追記

>Mrさん
＞どうも、Mrです。
＞口先だけロートルの分際で最近いろんなところに出没しててウザイですよね。でもやめない。

ご意見ありがとうございます。中箱と申します
場所柄+立場的に、ゆっくりしていってね、と言ってみるわけにもいかないのが無意味に悔しかったりしますが
…言ったところでどうせ滑るネタなのでさておき、レスや追加の説明などを。

●
・関数案「Movable」について

＞関数１　Movable(ユニットＩＤ,移動先X,移動先Y[,出発X,出発Y,最大移動力,位置,移動方法])

＞関数１の仕様として、最大移動力に無制限を設定すると、どうやってもたどり着けない場合に0が返る。
＞返すのは1 or 0のみ。

確かに　1or0　が返る関数があった方が使いやすそうではあるんですよね。ぱっと見で分かりやすいですし。
ただ、似通った(+ほぼ完全下位互換の)関数がどれだけ必要か、という疑問があります。

私としては、結果が簡潔で分かりやすい以外には、Movableが必要な理由が見つかりません。
もちろん分かり易いのは大事だとは思いますが…それだけではリクエストに含める理由としては弱いのでは、と。

Mrさんが挙げられた
＞これなら仮想値が欲しい場合は関数２単独で使い、行ける範囲内で値が欲しい場合は関数１と組み合わせで使えます。
についてですが、

現案の
「TotalMoveCostで最大移動力の指定を省略した場合はユニットの移動力で判定する」
という仕様にしておけば、
行ける範囲内で値が欲しい場合は
　TotalMoveCost(ユニットＩＤ,移動先x,移動先y)
一つで済みます。
（「0」が返ってくれば範囲外です）

今の所、Movable関数とTotalMoveCost関数の二つともは必要ないと思っています。

●
・TotaMoveCostの書式２について
前後しますが、陣営などのパラメータの必要不要に関わるのでこれについてから。

書式２は
「まだ作成されていないためにユニットＩＤを持たないユニットが、移動を行う場合の結果を得たい」
という場合を想定しています。

ユーザー全体としてはこのような場合は考慮した機能は不要なのかもしれませんが、
個人的にはあって欲しいので案に入れています。
（修正時追記：私が勝手に思ってるだけで、実際には明確な需要とまで行かなくとも無駄な機能だとは思われないかもしれませんし、と）

…まあ、一度Createでもして到達可否を調べ、その結果次第でEscapeさせてしまえば済む話ではあるので、
これ以上、不要という意見が付けば書式２に関しては削除して良いだろうと思ってもいますが。

●
・TotalMoveCostの陣営などパラメータについて

＞陣営を指定する意味を見出せません。ユニットＩＤで指定すれば不要だと思われます。

陣営を指定できる案になっている一番の理由は、「指定できないと書式２の時に困る」からです。
ユニットの属する陣営と初期位置が確定できないと、移動の可否は判定できないので。

ですから、
書式２を削除するのであれば、"陣営","出発X","出発Y"の３パラメータは案から削除しようかなと。
（もしも書式１でこれらを指定したいという場面であっても、ChangePartyやMoveコマンドで代用が利くでしょうし）

逆に書式２を残す場合は"陣営"指定が無いと困るので、削除はできないパラメータと考えています。

「書式１の場合は"陣営","出発XY"を指定できないが、書式２の場合は"陣営","出発XY"の指定が必須」
でも良いのかもしれませんが、
指定できるパラメータの並びはできるだけ共通にしておかないと紛らわしいと思ったので、現案のようになっています

●
・最大移動力

＞ここに「加速」「神速」「覚醒」「再動」を指定すると、各ＳＰ適応時の結果が返るといろいろ使えそうです。

○
覚醒＆再動についてですが、複数回の移動を踏まえての判定は果たして可能なのか、という疑問が。
不可能ではないでしょうけれど処理速度と実装における手間が心配です。

また、覚醒や再動を考慮可能にするのであれば
対象をＳＰに限らず、単純に２回・３回行動の場合にも対応しておかないと不便ですし、不自然だと思うので、案に含めるかちょっと迷います。

個人的には、リクエストする場合であっても「行動回数関連部分の優先度は低い」という旨は書いておきたい所かな、と。

○
加速、神速についてはあると便利かもしれませんが、デフォルトで添付されているSPにのみ対応させるのは反対です。
SP.txtをシナリオごとに定義できる以上、デフォルトのものでも特別扱いしない方向で。

ＳＰを考慮可能にするのであれば、ＳＰ名一般を指定できるようにするのが妥当でしょう。
また、その場合にＳＰ名を指定する場所ですが、
すり抜け移動や透過移動を与えるＳＰ効果が存在することから考えても、現案の　"他？"　の部分が一番適切かなと。

○
最大移動力のパラメータについては
　「+(数字)」を指定すると、数字分だけ移動力が増加(減少)した場合を判定する
　（数字は0.5刻み、マイナス可）
というのも良いかもしれません。

●
・「通過できるが停止できない場合」の扱い

＞仮に停止できるものとしてコストは表示するべきです。
＞この関数では純粋に総移動コストのみを求めた方がよいでしょう。

現案では
>・通過できるが停止できない場合は「(-1 * 費やす移動力)」を返す。
としていますので、正負逆とはいえコストは表示されます。

これは、実際に用いる時、
　・TotalMoveCost(～略～) > 0 なら移動先に選べるマス
　・TotalMoveCost(～略～) <= 0 なら移動先に選べないマス
で判定できる方が簡潔だと考えるからです。

ですから、ヘルプのコマンドの説明に
「純粋に総移動コストのみを求めたい場合にはAbs関数を用いるように」
といった感じの内容を書いてもらえば十分じゃないかな、と。

あるマスまでの総移動コストとそのマスに停止できるかどうかは、セットで考慮される事がほとんどなのではないでしょうか。
　停止できるかどうかは不要で、総移動コストのみが必要な場面
というものが私にはちょっとピンと来ません。

総移動コストの情報と、停止できるかどうかの情報は、わざわざ二つの関数に機能分けてしまうほどのものでは無いように思います。

停止できるかどうかで返り値が変化してしまう、という仕様が「TotalMoveCost」という関数名にそぐわなくなっているのであれば、
関数の名称を別のものに変えた方が良いのでしょうけれど。
（…とはいえ、ちょっと新たな名称を思いつかないわけですが）

●
・MoveCost関数について

＞＞・進入できない場合は「9999」を返す。
＞返すのはあくまで0にすべきだと思います。そっちの方が使いやすいからです。

うーん、使いやすいかどうかは個人的には微妙な所だと思うのですが、
TotalMoveCostと同様に「進入できないなら0」で統一した方が、誤解が無くて良さそうですね。
9999維持、という意見が出なければ

　・進入できない場合は「0」を返す

に変更しようと思います。

毎回のことですが、長々とすいません。
以上です。では

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

■5863 / inTopicNo.4)

　Re[3]: 仕様案の理由が含まれたレス

▲▼■

□投稿者/ Mr -(2008/04/07(Mon) 11:54:24) [ID:msSebhOJ]

どうも、うっかりレスにネガティブオーラをにじませてしまったMrです。
反省反省。

順番にレスするように書いてますので、内容が前後します。なので、読みにくいかもしれません。
特にレスが無いものに関しては了解で。

・関数を三つにすることに関して

関数の機能を少なくすればそれだけ作成・メンテナンスがやりやすいから、
また、組み合わせることで表現の幅が広がる、というメリットがあるからです。
一つの関数にいくつも機能を与えると、その分複雑・不安定になりバグの原因となります。
関数はいくつあってもいいんです。結果が同じならkeiさんが楽な方を選んでもらえばよいのではないでしょうか。
これに関してはもう少し後述します。

＞書式２は
＞「まだ作成されていないためにユニットＩＤを持たないユニットが、移動を行う場合の結果を得たい」
＞という場合を想定しています。

その観点はありませんでした。Info関数でユニットとユニットデータを使い分けるようなものですね。
ここらへんの意見は撤回します。

＞●
＞・最大移動力

＞個人的には、リクエストする場合であっても「行動回数関連部分の優先度は低い」という旨は書いておきたい所かな、と。

＞加速、神速についてはあると便利かもしれませんが、デフォルトで添付されているSPにのみ対応させるのは反対です。

これですが、良く考えたら「最大移動力を増加したとして判定する」に織り込めますね。
そちらがＯＫなら、織り込むということで。
他のＳＰに関しても同様に。

＞○
最大移動力のパラメータについては
＞　「+(数字)」を指定すると、数字分だけ移動力が増加(減少)した場合を判定する
＞　（数字は0.5刻み、マイナス可）
＞というのも良いかもしれません。

いいですね。ぜひ盛り込んでください。

＞●
＞・「通過できるが停止できない場合」の扱い

＞現案では
＞>・通過できるが停止できない場合は「(-1 * 費やす移動力)」を返す。
＞としていますので、正負逆とはいえコストは表示されます。

＞ですから、ヘルプのコマンドの説明に
＞「純粋に総移動コストのみを求めたい場合にはAbs関数を用いるように」
＞といった感じの内容を書いてもらえば十分じゃないかな、と。

＞あるマスまでの総移動コストとそのマスに停止できるかどうかは、セットで考慮される事がほとんどなのではないでしょうか。
＞　停止できるかどうかは不要で、総移動コストのみが必要な場面
＞というものが私にはちょっとピンと来ません。

＞停止できるかどうかで返り値が変化してしまう、という仕様が「TotalMoveCost」という関数名にそぐわなくなっているのであれば、
＞関数の名称を別のものに変えた方が良いのでしょうけれど。
＞（…とはいえ、ちょっと新たな名称を思いつかないわけですが）

これは関数を三つに分ける前提の話です。可否判定とセットで使うから、「仮に移動出来るとして」数値を返すわけです。

＞総移動コストの情報と、停止できるかどうかの情報は、わざわざ二つの関数に機能分けてしまうほどのものでは無いように思います。

この点に関して、どうも考え方が正反対のようですね。
どっちが正しいとは一概に言えませんが、ユーザビリティ優先ということになると、ちょっと自信がありません。
（最近主に弄っているのがSRCではないため）
ただですね、前にも書きましたが関数は一つあたりの機能を少なくして、組み合わせて使ったほうが表現の幅が広がるはずなんですよ。
もっとも、その分敷居は高くなってしまうのですが。
（例えばCreateコマンドがなくなり、いちいちUnit・Pilot・Ride・ChangeParty・Launchコマンドを実行するか、ユーザーがインクルードでCreateコマンドを作るようになるってことですね）
直前で書いたとおり、その辺のバランスに関しては自信がありません。
最終的には、おそらく私よりユーザー目線に近い中箱さんの判断にゆだねます。

大体以上です。漏れ疑問点あれば指摘願います。

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

■5865 / inTopicNo.5)

　Re[4]: 仕様案の理由が含まれたレス

▲▼■

□投稿者/ 中箱 -(2008/04/10(Thu) 03:23:14) [ID:TdSzoAHN]

…はて、自分のレスからは大体どんなオーラが出ているんだろう、とか思ってしまった中箱です。

●
＞関数の機能を少なくすればそれだけ作成・メンテナンスがやりやすいから、
＞また、組み合わせることで表現の幅が広がる、というメリットがあるからです。
＞一つの関数にいくつも機能を与えると、その分複雑・不安定になりバグの原因となります。
＞関数はいくつあってもいいんです。結果が同じならkeiさんが楽な方を選んでもらえばよいのではないでしょうか。

一般論としてはうなづけますが、
今回のMovableとTotalMoveCostに関して言えば少々事情が異なるんじゃないでしょうか。
見た目の機能が少なくとも、内部処理が複雑であればメンテナンス性・安定性は劣るわけですから。

○
まずは作成に関してなど、やや突っ込んだ視点での話が出たので、そのあたりについて。

以下、Map.basを見ての意見です。
（私はVBに関してあまり詳しくないので、もしかしたら完全に間違っているかもしれませんが…）

Map.basの1260～2240行あたりが、移動可能範囲の計算を行う部分になっているようです。(行数に関しては以下含めて数行間違えているかもしれませんが)

該当部分を見た限り、移動可能範囲は大雑把に
　１．進入可能な地形タイプなど、色々設定する(～1365行)
　２．各マスへ進入するための移動コストを、マスごとに算出する(～1721行)
　３．通り抜けられないマス、強制停止マス(ＺＯＣor移動停止地形)を調べる。(～1947行)
　４．各マスまで行くために必要な総移動力を算出する(～1992行)
　５．各マスへの必要移動力などから、停止できるマスとそれ以外のマスを判別する(～2236行)
という順番で求められています。

つまり、
　・あるマスが停止できるマスかどうか
という情報を得るために、
　・そのマスまでの総移動コスト
が、使われているようなのです。

であればMovableが実装される場合もまた、「総移動コストを計算後に、停止できるかどうかを判別する」というプロセスを含む可能性は高いのではないかと。
（もちろん、実際に実装された際にどのような記述になるかはわからないので予想の域を出ませんが）
そして、TotalMoveCostが総移動コストをそのまま返す関数にした場合、
Movableに含まれるであろう「総移動コストの計算」とは、TotalMoveCostの処理そのものに当たります。

となると、
可否判定であるMovableと、単純にコストのみを返すTotalMoveCostを併用するということは、
　移動できるかどうかをTotalMoveCost(と同じ処理)などを用いて判別し、
　移動できるなら、改めてTotalMoveCostを実行して値を得る。
という処理になります。

…これが非効率的な処理であることに異論は無いと思います。

私は
　移動可否判定にも使えるTotalMoveCostを使う。
もしくは
　停止できるかどうかを、停止できるかどうかのみを返す関数で判別し、
　停止できるならば、コストのみを返すTotalMoveCostを実行して値を得る。
のどちらかであるべきだと思います。

○
確かにMovable関数は機能が少ない関数ですが、
私としては上に書いたように、機能が少ない割には内部処理は複雑な関数になる、と予想しています。

返り値という見かけが単純であっても内部処理が複雑であれば、
メンテナンスがやり辛いことは言うまでも無いかと。

また、機能が被った関数が存在することはユーザーにとっては幾分プラスになるかもしれませんが、
メンテナンス性という観点から見れば、むしろマイナスに働く要素なのでは無いでしょうか。

以上が、Movable関数は別に必要ではない、という主張を続けている理由です。

●
＞＞総移動コストの情報と、停止できるかどうかの情報は、わざわざ二つの関数に機能分けてしまうほどのものでは無いように思います。
＞この点に関して、どうも考え方が正反対のようですね。
＞どっちが正しいとは一概に言えませんが、ユーザビリティ優先ということになると、ちょっと自信がありません。

私もさっぱり自信がありません。ユーザー目線…の範疇に収まった意見になっていれば良いのですが。

…んー、単独の関数にしてしまえば、
停止できない理由や、例外的に停止できる理由(合体先や味方母艦ユニットのいるマス)も、返り値に設定可能で便利な気もしますね。
例外がちょこちょこ見られる所ですし。

少し考えてみます。

●
＞＞・最大移動力
＞これですが、良く考えたら「最大移動力を増加したとして判定する」に織り込めますね。
＞そちらがＯＫなら、織り込むということで。

ええと、「書式末尾の"他？"の部分に、ＳＰ名を指定できるようにする」ということで良いでしょうか？

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

■5866 / inTopicNo.6)

　Re[5]: 仕様案の理由が含まれたレス

▲▼■

□投稿者/ Mr -(2008/04/11(Fri) 11:45:16) [ID:msSebhOJ]

レス返しの前に一つ。
あまり内部的な話ばかりしてると、他の方がレスつけにくくなりますから、お互いほどほどにしませんか？
keiさんの負担やプログラムとしての安定性も大事ですが、
基本的には「需要があってインクル再現が難しい」ものを「より実現可能っぽい案」として鍛え上げるのがこの掲示板の役目だと思いますので。
また、このままでは平行線になりつつあるな、というのもあります。
ぶっちゃけ、SRC本体のソースがどうたらという話になるとついていけません。
あの量のソースを環境なしで読むのはちょっとしんどいです。
意見交換参加者全てがソース読んでなきゃいけないという理屈もないでしょう。
まあ、そういう話になるように誘導してしまったのは私なわけですが、そこは一つ目をつぶってもらって。
別に都合が悪くなったから話すりかえようってわけではありませんよ。
一部の人間だけの議論になっちゃまずいと思ったからです。

ソース的な話も一応書いておきます。
Map.basを見ましたが、該当部分はSub（サブルーチン）になっているので返り値が設定できず、流用はできません。
そうなると、今回の機能実現のためには、改造というよりはFunction（関数）で新しくコードを打つことになると思われます。
であれば、既存の機能の話をしても仕方がありません。
ということで、上の話と合せて現在のソース絡めた議論はやめませんか？

＞●
＞＞関数の機能を少なくすればそれだけ作成・メンテナンスがやりやすいから、
＞＞また、組み合わせることで表現の幅が広がる、というメリットがあるからです。
＞＞一つの関数にいくつも機能を与えると、その分複雑・不安定になりバグの原因となります。
＞＞関数はいくつあってもいいんです。結果が同じならkeiさんが楽な方を選んでもらえばよいのではないでしょうか。

＞一般論としてはうなづけますが、
＞今回のMovableとTotalMoveCostに関して言えば少々事情が異なるんじゃないでしょうか。
＞見た目の機能が少なくとも、内部処理が複雑であればメンテナンス性・安定性は劣るわけですから。

内部処理が複雑なのはどちらも同じことです。返すものがシンプルな方が良いでしょう。

＞○
＞まずは作成に関してなど、やや突っ込んだ視点での話が出たので、そのあたりについて。

（一部省略）

＞であればMovableが実装される場合もまた、「総移動コストを計算後に、停止できるかどうかを判別する」というプロセスを含む可能性は高いのではないかと。
＞（もちろん、実際に実装された際にどのような記述になるかはわからないので予想の域を出ませんが）
＞そして、TotalMoveCostが総移動コストをそのまま返す関数にした場合、
＞Movableに含まれるであろう「総移動コストの計算」とは、TotalMoveCostの処理そのものに当たります。

＞となると、
＞可否判定であるMovableと、単純にコストのみを返すTotalMoveCostを併用するということは、
＞　移動できるかどうかをTotalMoveCost(と同じ処理)などを用いて判別し、
＞　移動できるなら、改めてTotalMoveCostを実行して値を得る。
＞という処理になります。

＞…これが非効率的な処理であることに異論は無いと思います。

一応ソースとか実装の話もしておきます。
実装される場合、Movable()とTotalMoveCost()を定義しておいて、内部的にPublic Function Calculate_MoveCost(OptionlでMovable・TotalMoveCostそれぞれに対応)のようなものを定義してそれぞれ呼ぶようにすれば効率も悪く無いでしょう。
Optionalであたえた、Movable()部分だけで終了するフラグを立てるなどして途中でCalculate_MoveCost()を切り上げるような処理にする、ということです。

分かりやすく書くと、（→が出力、←が入力と考えてください）

Movable関数スタート
　→Movableから始まったというフラグをもってCalculate_MoveCost関数を呼ぶ
　←移動可能かフラグが返ってくる
→シナリオに移動可能かを返す

TotalMoveCost関数スタート
　→Movableから始まったフラグをもたずにCalculate_MoveCost関数を呼ぶ
　←移動コストが返ってくる
→シナリオに移動コストを返す
　
Calculate_MoveCost関数スタート
　移動可能かを取得する
→ここでMovableから始まったフラグがあったら移動可能かを返す
　フラグがなければ続行
　移動コスト取得
→移動コストを返す

ということです。

とまあ、ここまで書きましたが、もはや完全にシナリオ作者視点からは外れまくっていますね。

＞私は
＞　移動可否判定にも使えるTotalMoveCostを使う。
＞もしくは
＞　停止できるかどうかを、停止できるかどうかのみを返す関数で判別し、
＞　停止できるならば、コストのみを返すTotalMoveCostを実行して値を得る。
＞のどちらかであるべきだと思います。

後者の案が、私の考えそのものですので、それで良ければその方向で考えていただきたいかなと。

＞○
＞確かにMovable関数は機能が少ない関数ですが、
＞私としては上に書いたように、機能が少ない割には内部処理は複雑な関数になる、と予想しています。

＞返り値という見かけが単純であっても内部処理が複雑であれば、
＞メンテナンスがやり辛いことは言うまでも無いかと。

＞また、機能が被った関数が存在することはユーザーにとっては幾分プラスになるかもしれませんが、
＞メンテナンス性という観点から見れば、むしろマイナスに働く要素なのでは無いでしょうか。

＞以上が、Movable関数は別に必要ではない、という主張を続けている理由です。

上のレスでも書きましたが、Movable関数はそんなに複雑にはならないはずです。
改造ではなく機能追加とすれば、の話ですが。

＞●
＞＞＞総移動コストの情報と、停止できるかどうかの情報は、わざわざ二つの関数に機能分けてしまうほどのものでは無いように思います。
＞＞この点に関して、どうも考え方が正反対のようですね。
＞＞どっちが正しいとは一概に言えませんが、ユーザビリティ優先ということになると、ちょっと自信がありません。

＞私もさっぱり自信がありません。ユーザー目線…の範疇に収まった意見になっていれば良いのですが。

＞…んー、単独の関数にしてしまえば、
＞停止できない理由や、例外的に停止できる理由(合体先や味方母艦ユニットのいるマス)も、返り値に設定可能で便利な気もしますね。
＞例外がちょこちょこ見られる所ですし。

＞少し考えてみます。

ここに関して、もっと他の方の意見が欲しいですね。
二人だけで考えてるとあらぬ方向へ行きかねません。

＞●
＞＞＞・最大移動力
＞＞これですが、良く考えたら「最大移動力を増加したとして判定する」に織り込めますね。
＞＞そちらがＯＫなら、織り込むということで。

＞ええと、「書式末尾の"他？"の部分に、ＳＰ名を指定できるようにする」ということで良いでしょうか？

いえ、ＳＰ名指定は不要、ということです。
加速を指定したければ最大移動力に対象の移動力+2を指定すればいいことですし、覚醒を指定したければ移動力×2を指定すればいいですから。

他の方が引かずにどんどんレスつけてくださることを願います。

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

■5867 / inTopicNo.7)

　Re[6]: 仕様案の理由が含まれたレス

▲▼■

□投稿者/ 中箱 -(2008/04/11(Fri) 17:37:55) [ID:TdSzoAHN]

●
＞このままでは平行線になりつつあるな、というのもあります。

ソースでの話を加えることで、平行線になるのを避けれるかもしれないから持ち出してみた、という面もあったり。
…こちらの判断ミスっぽい気もしていますが。いくつかの意味で。

＞ぶっちゃけ、SRC本体のソースがどうたらという話になるとついていけません。
＞あの量のソースを環境なしで読むのはちょっとしんどいです。
＞意見交換参加者全てがソース読んでなきゃいけないという理屈もないでしょう。

参加者全てが読んでなければならないワケじゃない、というのは確かでも、
ソースを読んでの意見交換は全面的に駄目、という理屈にもならないはずです。
程度問題、と言うか、匙加減の難しい点ではあるでしょうけれど。

そもそも、読まなければ一切参加できないような内容になっていますか？
ソースを持ち出した瞬間に参加できなくなる、というのは誤った考えでは無いでしょうか。
(敷居を上げてしまうことは確かだと思いますが…)

前レスで私が示したソースの解釈が正しいか間違っているか、という点にさえ目をつぶれば、
「ソースを読まないと意見を出せない」というのはただの思い込みだと思うんですが。
もちろん書いた本人が言っても説得力に欠けますし、意見を出しづらいのも分かるつもりですけれども。

ソース読みがしんどいのはなんとも返しようがありませんが、
該当部分はほとんど変数を弄ってるだけで、実際は大して特殊なことをやっているわけではなく、
VBの知識が薄くとも、SRCのサブルーチン読みに多少慣れていれば大体は読めませんかね。コメントも分かりやすいですし。

ただなんにせよ私は
自分自身でソースが読めなくとも、他人によって示された解釈さえ間違っていなければ、
その解釈を元にした議論は可能だと思います。

議論の元にする解釈が(故意にであれ能力不足であれ)間違っているという危険が存在するのは確かですし、
感覚的に、参加し辛くなることは否定できませんが、
それはソースを元にした議論をしない、とする理由にはならないでしょう。

現段階での明確な参加者は私とMrさんの二人だけですし、
今の所様子見という人など、見ている人にはすいませんが、ほどほどには続けます。

ソースが絡む部分は下の方に書きますので、興味の無い人は飛ばしてください。
無駄で邪魔で不当な意見交換だから、ソースがらみの話自体をやめろ、という方はその旨レスを。

●
＞＞　停止できるかどうかを、停止できるかどうかのみを返す関数で判別し、
＞＞　停止できるならば、コストのみを返すTotalMoveCostを実行して値を得る。
＞後者の案が、私の考えそのものですので、それで良ければその方向で考えていただきたいかなと。

誤解がある表現だったかもしれませんが、
「停止できるかどうかのみを返す関数」は、
Movable関数とは違い、ユニットの移動力は考慮しない関数を想定しています。
おそらく、Mrさんの考えそのものからはズレているのではないかと。

件の関数は、こんな感じの書式になるでしょうか
　Stopable(ユニット,地形名[,位置,移動方法,他？])
　Stopable(ユニット,X,Y[,位置,移動方法,他？])
（…こんな関数名でよいんでしょうかね。まあ名称も仮ということで）

リクエスト案には、Movableの代わりにこのStopableを入れようと思います。
StopableとTotalMoveCostでMovableは自作できますし。(レスの最後にプロセスを書いておきます)

Movable関係については記事の下部に。

●
＞＞ええと、「書式末尾の"他？"の部分に、ＳＰ名を指定できるようにする」ということで良いでしょうか？

＞いえ、ＳＰ名指定は不要、ということです。
＞加速を指定したければ最大移動力に対象の移動力+2を指定すればいいことですし、覚醒を指定したければ移動力×2を指定すればいいですから。

すいません、私自身が"他？"の部分にＳＰ名指定できたほうが良いと思うようになっていますので
とりあえず指定可能な方向で、他の人の意見待ちとさせてください。

単純な移動力の増減以外に、すり抜けや透過移動ＳＰ効果がかかった場合も想定できるようになりますから。

（…ユニットにかかっているSP効果（SP名ではなくて）を、
　SP.txtの内容に関わらず、汎用的に知る方法があればいいんですが）

なおこれは横道ですが、
ＺＯＣや追加移動力の影響が絡んでくるので、覚醒に関しては単純に*2するだけではまずいです。

●
案が未確定のもの含めて色々変わっているので、
一度まとめなおして再提示します。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以下、ソースが絡む話になります。
ただソース読解が意見を理解するために必須というわけでは無いことは、留意していただけると助かります。
前レスで示したソースの「解釈」が間違っていない、ということは前提にしていますが。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

●
＞Map.basを見ましたが、該当部分はSub（サブルーチン）になっているので返り値が設定できず、流用はできません。
＞そうなると、今回の機能実現のためには、改造というよりはFunction（関数）で新しくコードを打つことになると思われます。
＞であれば、既存の機能の話をしても仕方がありません。

「新しくコードを打つ場合は全く既存の機能とは関係ない」のといったような考え方は間違っていると思います。

サブルーチンそのものの流用ができず、新しいコードが必要になる場合であっても、
その新しいコードは、既存部分と似通ったアルゴリズムで作られると考える方が自然ではないでしょうか。

…私がしている「予想」は見当違いで、全くもっともらしくない予想でしょうか？
また、予想を前提とした話はやっても仕方の無いものですか？

私はそのどちらについても「No」と思っているから言っているわけなのですが。

●
＞Calculate_MoveCost関数スタート
＞　移動可能かを取得する
＞→ここでMovableから始まったフラグがあったら移動可能かを返す
＞　フラグがなければ続行
＞　移動コスト取得
＞→移動コストを返す

つまり、Mrさんが想定されているCalculrate_MoveCostは
「移動可能かどうかの判定に、移動コストは不要」
という前提の上に成り立っているわけですが、
私はそもそもその前提に無理がある、と踏んでいます。

もしもこの前提が成り立つのであれば、既存のMap.basの該当部分が今のようになっている理由が分からなくなりますので。

前レスで書いたように、既存機能における処理の順番は
＞　４．各マスまで行くために必要な総移動力を算出する(～1992行)
＞　５．各マスへの必要移動力などから、停止できるマスとそれ以外のマスを判別する(～2236行)
です。
移動コスト取得は、移動可能かどうかの判定の前に行われています。

もしも移動先に選べるかどうかの判定に移動コストが不要であるならば、
なぜ「４」が処理に含まれているのか、という疑問が生じます。

安定版の機能において、「移動に際して費やした移動コストの量」が移動後のユニットの状態に一切関わらない以上、
「移動先の判定に移動コストの情報は不可欠である」と判断するべきです。
…"べき" が言いすぎであっても、
少なくとも
「移動先の判定に移動コストの情報は不要である」という判断よりは
根拠のある判断だと言える筈です。

（もちろん、必ずしも合理的・効率的な理由の下に「４」が入っているとも限らない、という問題は残るわけですが）
（開発版に実装された「遊撃」能力に必要だから、安定版にもこの処理が入っている、という事もありえない話ではないでしょうし）

つまりCalculate_MoveCost関数があったとしてもその処理プロセスは
　Calculate_MoveCost関数スタート
　　移動コスト取得
　→ここでMovableから始まったフラグが無ければ移動コストを返す
　　フラグがなければ続行
　　移動可能かを取得する
　→移動可能かを返す
の順番になるのが妥当だと考えます。

ですから、MovableとTotalMoveCostを併用した場合、
　移動コスト取得してから移動可能かどうかを返し、
　移動可能であれば、改めて移動コストを取得する
という構造は変わりません。
やはり、移動コスト取得が2重に行われるという効率の悪さはそのままです。

●
もっとも、
実現方法を私が考え付かず、
実装がそうなっていないだけで、
Mrさんの想定するCalculate_MoveCostは実は実現可能なのであれば、
Mrさんの想定される方向で良いと思います。

けれども、
誰も実現可能であることを示しておらず、
実際の記述からも実現可能であることが読み取れないのであれば、
Mrさんの考えるCalculate_MoveCostは実現不可能である
ということを前提に考えるべきではないでしょうか。

○
まあ「どのような場合はＡ案、そうで無い場合はＢ案」
という形でのリクエストにするのがダメなわけではないのでしょうけれど。

でもそれですとリクエスト文が余計にごちゃごちゃしますし。
それに、まだ併記するには早く、詰める余地はある問題だと考えているのでレスを続けています。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
ソースがらみここまで
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

●
StopableとTotalMoveCost（コストのみ）を併用する、
Movableと同様の動作を得るものを自作する場合のイメージ概略

　（Movableラベル開始）
　仮に進入した場合に停止できるマスかどうかをStopableで判定する。
　　・停止できない
　　　→0を返し終了
　　・停止できる
　　　そのマスまでの総移動コストをTotalMoveCostで取得
　　　　・総移動コストがユニットの移動力以内
　　　　　→1を返し終了
　　　　・総移動コストがユニットの移動力を越える
　　　　　→0を返し終了
　(ラベル終了)

毎度長々と失礼しました。
では

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

■5868 / inTopicNo.8)

　中途まとめ

▲▼■

□投稿者/ 中箱 -(2008/04/11(Fri) 21:12:47) [ID:TdSzoAHN]

2008/04/11(Fri) 22:23:22 編集(投稿者)

当初案から幾つか変更などがあったので、今現在の案について一度再提示します。

　１．指定するユニットが、現在地点から指定する座標まで移動する場合に、費やす移動力が取得できる関数「TotalMoveCost(仮)」
　２．指定するユニットが、指定する地形(座標)に進入するために必要な移動コストが取得できる関数「MoveCost(仮)」
　３．指定するユニットが、指定する座標(地形)で停止できるかどうかを判定する関数「Stopable(仮)」
　４．指定する座標に働くＺＯＣのレベルを返す関数「ZocLevel(仮)」

という、いずれも移動に関係する関数のリクエストを考えています。

●１の書式案
TotalMoveCost(ユニット,移動先X,移動先Y[,出発X,出発Y,陣営,最大移動力,位置,移動方法,Option])

　・"ユニット"で指定したユニットが、座標("移動先X","移動先Y")まで移動した時に費やす移動力を返す。

　・"ユニット"にはメインパイロット名orユニットＩＤorユニット名称　を指定。
　・ユニット名称を指定した場合は、出発X,出発Y,陣営が省略不可。

　・指定した最大移動力以上の移動力が必要な座標だった場合は「0」を返す。

　※0が返らなかったからといって、指定した座標に移動できるとは限らない。
　　（指定した座標にすでに別の味方ユニットが存在する場合など、
　　　通過はできるが停止できない場合が存在するため）

　　移動できるかどうかの情報を確実に得たい場合は、Stopable関数と共に使用すること。
　　（ヘルプに具体的な記述を載せてもらったほうが良いでしょう）

○最大移動力
　算出時に考慮する移動力の最大値。
　省略もしくは「-」の場合は、ユニットの移動力が指定されたものとする。
　通常の式以外に、「制限無し」「+(数字)」が指定可。
　「+(数字)」を指定した場合は、数字分だけユニットの移動力が増減したものとして判定する。
　（数字は0.5単位でマイナス値も指定できる）

○Option
　ＳＰ名称を指定することで、そのＳＰがかかっているものとして、指定座標まで移動するのに必要な移動力を返す。
　ＳＰを複数指定する場合は半角スペースで区切る。

(引数の説明は長くなるので変更のあったもののみを。書いていない引数については親記事を参照してください)

●２の書式案
書式１
MoveCost(ユニット,X,Y[,位置,移動方法,他])
書式２
MoveCost(ユニット,地形名[,位置,移動方法,他])

　・書式１の場合、"ユニット"で指定したユニットが、座標("X","Y")にある地形に移動する場合の移動コストを返す。
　　書式２の場合、"ユニット"で指定したユニットが、"地形名"に移動する場合の移動コストを返す。
　　(TotalMoveCostと違い、ユニットが現在いる座標は無関係)

　・進入できない場合は「0」を返す。
　・それ以外は、必要な移動コストを返す。
　　（ジャンプ移動時や透過移動を持つユニットなど、
　　　通過はできるが停止できない地形や座標が発生することがある点には注意）

（下記のStopableとの関係で書式１と２を入れ替えました。
　書式を一つに統一するならば、書式２に統一したい所です）

●３の書式案
書式１
Stopable(ユニット,X,Y[,位置,移動方法,Option])
書式２
Stopable(ユニット,地形名[,位置,移動方法,Option])

　・書式１の場合、"ユニット"で指定したユニットが、座標("X","Y")上で停止できるかどうかを返す。
　・書式２の場合、"ユニット"で指定したユニットが、"地形名"上で停止できるかどうかを返す。
　　(ユニットが現在いる座標、移動力は無関係)

　・元々進入できない場合、進入はできるが停止できない場合には「0」を返す。それ以外は、「1」を返す。

　・Optionに「詳細」を指定した場合、停止できる/できない理由が特別にある場合はその理由を返す。
　　この場合の返り値は
　　停止可能な場合：「1」(通常)、「格納先」、「合体先」
　　停止不可能な場合：「0」（通常）、「ユニット」(いずれかのユニットが存在する場合)

　　※書式2の場合「詳細」を指定しても「格納先」「合体先」「ユニット」が返ることはありません

○
進入できるが停止できない座標は、
　・他の味方ユニットが存在する座標（例外あり、後述）
　・ジャンプ移動した場合、地形タイプが「空」である座標
　・テレポートやすり抜け移動の場合、敵ユニットが存在する座標など
　・透過移動する場合の壁など
などが存在します。

また、他の味方ユニットがいても例外的に停止できる場合として
　・味方の母艦上(格納)
　・2体合体の相方上(合体)
といったものがあります。

「詳細」指定によってこれらの例外を区別できるような案にしましたが、

そもそもこの「詳細」が必要かどうか、
他の返り値は必要ないかどうか、などの点についての意見があればお願いします。

○
なお、このStopableと上のTotalMoveCostを組み合わせることで、
指定したユニットが指定した座標に移動できるかどうかの情報を得ることができます。
（書式案にのっとった具体的な記述例が必要であれば、示せるかと）

指定した座標に移動できるかどうかを返す関数のリクエストは考えていません。

●４の書式案
ZocLevel(X,Y,ユニットor陣営)

　・指定した陣営orユニットにとって、座標("X","Y")に働くＺＯＣの強さ(レベル)を返す。
　・メインパイロット名、ユニットＩＤ、ユニット名、陣営のどれかが指定する。

　・強制停止させられる座標ではない場合は「0」が返る。

　・強制停止させられる座標だった場合は、そのＺＯＣのレベルが返る。
　　※Option ＺＯＣによるＺＯＣの場合は、「1」が返る。
　　　特殊能力のＺＯＣLv1によるＺＯＣの場合は、特異値が返る。
　　　移動停止効果を持つ地形の場合は、別の特異値が返る。

　・陣営以外を指定した場合、指定したユニットがＺＯＣ無効化能力を持っている場合、その能力を考慮した上での結果が返る。

○
この関数案に関しては、必要かどうか、という点から議論の余地がありそうです。

OptionのＺＯＣ、ユニット能力のＺＯＣ、ＺＯＣ無効化、隣接ユニットＺＯＣ無効化、広域ＺＯＣ無効化　が関係して煩雑なので
あるに越したことは無いとは思うのですが。

●
こっそり関数が一つ増えていますが、
それについても目はつぶらず意見などなにかあれば是非。

よろしくお願いします
では。

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

■5869 / inTopicNo.9)

　Re[2]: 中途まとめ

▲▼■

□投稿者/ マガツ -(2008/04/11(Fri) 22:20:19) [ID:QBPH74Wk]

こんばんは。マガツです。
一応ソース屋を名乗らせていただきます。

が、そっち系の話は興味のない方もいると思うので、後に回させていただきます。

まず、私の率直な疑問点なのですが、この関数が実装されたとして、どのようなことを行いたいのでしょうか？
そこが明らかにならねばちょっと賛成は致しかねます。

と言いますのも、特定地点へ移動するのに必要なコストや該当箇所に移動可能かどうかの関数の使い道がSRCでは思いつかなかった為です。
追加をする機能は特殊能力や状態異常と違い、追加されれば使い道のある機能とは違い、それ単独では用途を満たせない関数なのですから。

以下、ソースとかプログラミング的な話。

該当の処理はサブルーチンですが、VB5.0はSUBをFunctionに書き換えれば直ぐに関数に変換することが可能です。
(もう少し大きい話にすれば、返り値を返すようにすればどの言語でもどのサブルーチンも関数にすることができます。)
また、該当のサブルーチン呼び出し元が返り値を使わないように呼び出すことも可能です。
個人的には既存の機能と今回の関数の共通部分を抜き出してそこだけ別関数化して実装するのが楽だとは思いますが…… 実際の実装等はkei様もしくはソースを投稿する方に委ねます。

それでは。

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

■5871 / inTopicNo.10)

　Re[3]: 中途まとめ

▲▼■

□投稿者/ 中箱 -(2008/04/19(Sat) 19:49:23) [ID:TdSzoAHN]

●
＞まず、私の率直な疑問点なのですが、この関数が実装されたとして、どのようなことを行いたいのでしょうか？

単純な所では
　・CPUの思考モードに、シナリオ側でバリエーションを広げたい場合。
　・イベント発火の条件として。
　・既存の移動コマンド以外の移動ルールを用いたシナリオを作る場合
あたりでしょうか。

それぞれ軽く例を挙げるなら、

○
CPUの行動制御なら
「2体の目標のうち、より早く隣接できそうな(!=近いマスにいる)ほうを狙う敵」や
「特定の地形を避けながら（選びながら）移動してくる敵」

○
イベント発火条件なら
「あと一歩で目標地点に到達できる所で、立ちふさがる敵が出現」
（どちらかというとシナリオイベントの組み損ね防止っぽくなりそうですが。高移動力+移動力Upアイテム+加速系SPの見落としとか）

○
既存の移動以外のルールによる移動については、
例えば、
　「ユニットがいるマスは、合体や格納の場合を除いて移動先に選べない」
　「敵ユニットをすり抜けられる場合、必ずＺＯＣの影響も受けない」
…という移動に関する仕様を変更する術はありません。

けれど、そういった仕様とは違う仕様に基づいた移動を行わせたい場合もあるでしょう。

私の場合ここで真っ先に挙げるべきなのは、No5811～のツリーで話題にしている「グループ状態」ですか。

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

（既存のSLG,SRPGについてはちょっと長いので、すいませんがNo5721の真ん中少し下に書いてあるものを見ていただければと）

●
また、用途とか云々以前に
次の通常移動で行ける座標か否かという情報をシナリオ側から参照できないことは不自然だと思っています。

プレイヤーはコマンド一つで確認できるのに、
シナリオ側で確認しようとしたら豪く手間がかかる情報です。しかも完全に把握するのはかなり難しい。
（微妙に用途が違いますし蜜柑製品ですが、実際に作ってみたものを私の個人サイトに転がしています）

プレイヤーが利用できる情報を、シナリオを作る側からも把握できるようになるような機能は不要でしょうか？

●
＞追加をする機能は特殊能力や状態異常と違い、追加されれば使い道のある機能とは違い、それ単独では用途を満たせない関数なのですから。

微妙に分からない論ですが、
「単独で用途を満たせないような機能のリクエストに際しては、
　特殊能力や状態異常のリクエストのような、単独で用途を満たせるような分かりやすい機能の場合よりも詳しく用途の説明をするべきだ」
といった感じのご忠告、という解釈で良かったでしょうか。

それ単独で用途を満たせないのは、今回提案している関数に限らず関数一般に言えることですし。

以上です。
では

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

■5872 / inTopicNo.11)

　Re[4]: 中途まとめ

▲▼■

□投稿者/ マガツ -(2008/04/23(Wed) 21:54:16) [ID:JGP3bveD]

マガツです。

一点撤回で。
＞追加をする機能は特殊能力や状態異常と違い、追加されれば使い道のある機能とは違い、それ単独では用途を満たせない関数なのですから。

よくよく考えてみれば、状態異常であっても、コマンド、その他関数であっても、あれば利用用途を満たせているとは言えませんでした。
こちらに関しては撤回させていただきます。

言いたかったことは、
そのリクエストが実装されたとして、何がやりたいのかが伝わりません。
という部分ですので。

先ほどのレスでやりたいことがよくわかりましたので、
私としてもこの機能追加に賛成致します。

それでは。

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

■5880 / inTopicNo.12)

　リクエスト前、案再提示

▲▼■

□投稿者/ 中箱 -(2008/05/16(Fri) 21:12:18) [ID:TdSzoAHN]

2008/05/18(Sun) 23:58:17 編集(投稿者)

結構空けました。どうも、中箱です。

特に意見も無いようですので、以下のような内容の新機能を来週末あたりにでもリクエストしたいと思います。

この機能によって可能になることあたりに関しては、No5871にあります。

以下、リクエスト部分
＝＝＝＝
移動に関係する以下の関数をリクエストします。

１．指定するユニットが、ある地点から指定する座標まで移動する場合に費やす移動力が取得できる関数「TotalMoveCost」
２．指定するユニットが、指定する地形(座標)に進入するために必要な移動コストが取得できる関数「MoveCost」
３．指定するユニットが、指定する座標(地形)で停止できるかどうかを判定する関数「Stopable」
４．指定する座標に働くＺＯＣのレベルを返す関数「ZocLevel」

●１
TotalMoveCost(ユニット,移動先X,移動先Y[,出発X,出発Y,陣営,最大移動力,位置,移動方法,Option])

・"ユニット"で指定したユニットが、座標("移動先X","移動先Y")まで移動する時に費やす移動力を返す。
　ただし、"最大移動力"以上の移動力が必要な座標だった場合は「0」を返す。
・出発X以下については省略可。

○ユニット
　　メインパイロット名またはユニットＩＤまたはユニット名称　を指定。
　　（ユニット名称を指定した場合は、出発X,出発Y,陣営が省略不可）
○移動先X,Y
　　目標地点の座標を指定。

○出発X,Y
　　省略、もしくは「-」を指定した場合は"ユニット"の現在座標を用いる。
　　指定した場合は"ユニット"が座標("出発X","出発Y")に存在するものとして費やす移動力を算出する。
○陣営
　　陣営名を指定する。省略もしくは「-」を指定した場合は現在の陣営を用いる

○最大移動力
　　算出時に考慮する移動力の最大値。
　　通常の式以外に、「制限無し」「+(数字)」が指定可。
　　（「+(数字)」を指定した場合は、数字分だけユニットの移動力が増減したものとして判定する。
　　　この時の数字は0.5単位でマイナス値も指定できる）
　　省略もしくは「-」の場合は、ユニットの移動力を基に算出する。
○位置
　　ユニットのAreaを指定する。
　　省略もしくは「-」の場合はユニットの現在のAreaで算出する。
○移動方法
　　ユニットの移動方法（「通常」「-」「ジャンプ」「テレポート」）を指定する。
　　省略や「-」「通常」の場合は通常移動とみなす。
○Option
　ＳＰ名称を指定することで、そのＳＰがかかっているものとして、指定座標まで移動するのに必要な移動力を返す。
　ＳＰを複数指定する場合は半角スペースで区切る。

※指定した座標に他の味方ユニットがいる場合など、返り値が0以上でも移動できない場合があることを
　ヘルプに注意書きとして書いてあると良いと思います。

　移動できるかどうかの情報を確実に得たい場合には、Stopable関数と、
　例えば
　　IIf(Stopable(ユニット,X,Y),TotalMoveCost(ユニット,X,Y),0)
　のように、二つ組み合わせて使うことを想定しています。

●２
MoveCost(ユニット,X,Y[,位置,移動方法,Option])　or　MoveCost(ユニット,地形名[,位置,移動方法,Option])

・左の、座標を指定する書式の場合は、"ユニット"で指定したユニットが、座標("X","Y")にあるマスに移動する場合の移動コストを返す。
　右の、地形名を指定する書式の場合は、"ユニット"で指定したユニットが、地形名称が"地形名"のマスに移動する場合の移動コストを返す。
　(TotalMoveCostと違い、ユニットが現在いる座標は無関係)

・進入できない場合は「0」を返す。それ以外は、必要な移動コストを返す。（その座標/地形に停止できるかどうかは無関係）

○ユニット,位置,移動方法,Optionは、上記のTotalMoveCostのものと同じ。

※片方の書式のみ実装される場合は、地形名を指定するのほうの書式でお願いします。

●３
Stopable(ユニット,X,Y[,位置,移動方法,「詳細」])　or　Stopable(ユニット,地形名[,位置,移動方法])

・左の、座標を指定する書式の場合は、"ユニット"で指定したユニットが、座標("X","Y")上で停止できるかどうかを返す。
　右の、地形名を指定する書式の場合は、"ユニット"で指定したユニットが、"地形名"上で停止できるかどうかを返す。
　(ユニットが現在いる座標、移動力は無関係)
・元々進入できない場合、進入はできるが停止できない場合には「0」を返す。それ以外は、「1」を返す。

○「詳細」
　これが指定された場合、停止できる/できない理由が特別にある場合は返り値がその理由に変更される。
　　停止可能な場合：「1」(通常)、「格納先」、「合体先」
　　停止不可能な場合：「0」（通常）、「ユニット」(いずれかのユニットが存在する場合)

※地形名を指定した場合は「詳細」を指定しても意味がないので書式から外してあります。

※片方の書式のみ実装される場合は、「詳細」の関係があるので座標を指定するのほうの書式でお願いします。

●４
ZocLevel(X,Y,ユニットまたは陣営)

・指定した陣営orユニットにとって、座標("X","Y")に働くＺＯＣの強さ(レベル)を返す。
・メインパイロット名、ユニットＩＤ、ユニット名、陣営のどれかを指定する。

・強制停止させられる座標ではない場合は「0」が返る。
　強制停止させられる座標だった場合は、そのＺＯＣのレベルが返る。
　（Option ＺＯＣによるＺＯＣの場合は、「1」が返る）
　（特殊能力のＺＯＣLv1によるＺＯＣの場合は、特異値が返る）
　（移動停止効果を持つ地形の場合は、別の特異値が返る）
※特異値に関しては実装において都合の良い値で。

・指定したユニットがＺＯＣ無効化能力を持っている場合は、その能力を考慮した上での結果が返る。

＝＝＝＝＝

以上です。
では

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

■5888 / inTopicNo.13)

　リクエスト完了

▲▼■

□投稿者/ 中箱 -(2008/05/30(Fri) 02:54:50) [ID:TdSzoAHN]

しました。

解決済み!

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

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

このトピックに書きこむ

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

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

- Child Tree -
- Antispam Version -