| 補足部分
＝＝＝＝＝
●目標について
ツリーの目標は親記事に書いたとおり
> 「グループ状態であるユニット群が行動(戦闘など)を行う」ことが、
> 何らかの方法で可能になるような機能拡張案群をリクエストする
ですが、
私自身の個人的な願望としては、
既存システムを再現するのに必要最低限の機能よりはもう少し広く、
「俺式小隊システム(攻撃する順番とか色々細かい)」や「ツインじゃなくてトリプルユニット」
みたいな感じのものも、それなりに実現しやすいような案にしたいな、とは思っています。
これは、あくまでも「実現できて欲しい」であって、「実現できなければならない」や、「実現することが目的である」ではありません。
ですから今後の議論において仮に、
小隊システムの再現への需要が強く、シナリオ独自で調整可能な部分や、ツインユニット・スタック制の需要が明らかに弱い
ようであれば、
その後の議論は、小隊システムの再現に最適化した案を目指すことを最優先として進めても良いでしょう。
ただ、一度、一つの形式を実現する機能が実装され、後々にその機能を再拡張した場合、
プログラムが効率の悪いものになったり、機能として無駄な部分が発生したりする恐れがあります。
もしかしたら、既存の機能との兼ね合いの問題などで実装自体が困難な部分が出てくるかもしれません。
それらを考えると、再拡張はなるべく避け、一度で済ますに越したことはないはずです。
(もちろん、実装作業の手間という問題があるわけですが…)
この観点からも、
最低限の機能のみでの実装よりは、初めからある程度のカスタマイズを許容する機能の実装であって欲しいな、とは。
＝＝＝＝＝
★１−Ｂ−ｂについて
不可能ではないが面倒、というのは私が5721で述べたほか、
なめさんが、No.5808にておおまかな実現方針とともに、面倒である、という見通しを示されています。
この形式のシステムをそのまま再現するには、移動コマンドと同等のものを再現する必要があります。
現機能ではHotPointを利用するしかありませんが、
HotPointを利用する場合、クリック待ちしている最中、アブジェクトの下に表示されるマップ範囲を移動させられない、という欠点があります。
移動先マスとは別に、マップ範囲を移動させるためのHotPointを作れば対応可能だとは思いますが、
ドラッグして表示範囲を変えられる移動コマンドと比較して操作性が著しく劣ることは確実です。
＝＝＝＝＝
以下、遅ればせながらレスとなります。
●
>なめさん
初めまして。ご意見ありがとうございます。
＞指定した座標が移動可能範囲かどうか？を調べる関数さえあれば
＞中箱さんの考えるグループ状態の作成など後はユーザー側でインクルを組むなりで大抵は解決できると思います
(略)
＞X座標(),Y座標()がメインパイロットの乗ってるユニットの移動可能範囲に含まれれば1を、できなければ0を返すという関数です
これは、No.5721における私案で
> ・指定したユニットが、指定した座標に(、指定した移動方法で)、次の移動で到着可能であるかどうかを返す関数「Reach(仮)」
> （オプションとして、指定座標に味方/敵がいても、その座標のユニットのみ無視するようなものを設定可能にする）
という形で提案していたものの機能を絞って、具体的にした感じでしょうか。
（提案が分かりづらかったようですいません）
作成に関してはそれがあれば大体可能になると思います。
5721の私案に関してはとりあえず棚上げ・保留にしていますが、
今後案をつめて行く際には参考にさせていただきます。
＞グループを組ませたいAとBがいるとして
＞Bの座標を記憶させて一時的にエスケープさせ、AがBの座標まで辿り着けるなら
＞Bを戻して、Aをグループに組み込ませればこれでグループは組めると思います
CPU操作のユニットを合流させる方法としてはそれで良いと思います。
この点が解決すれば、
シナリオで利用する場合の残る問題は、Aを、Bと合流させるかそれとも他の場所に移動させるか、の判定方法になりそうですね。
（そこは、CPUユニットの制御に関することして、別件で検討した方が良さそうですけれど）
重ねて、ありがとうございました。
では。
●●
>乾さん
一月経ってしまいました。レスが遅くてすいません。
●
＞ 検討の段階でシナリオで具体的にどのようなコマンドを組み合わせて使う物なのかの
＞イメージが固まらない状態では、そのコマンドを実際に使用する際の問題点の
＞洗い出しなどが行えないため、明確な目的が見えないまま
＞「なんとなくこれがあったら便利じゃないか」程度の機能が追加されてしまう恐れがあります。
確かに、最後までイメージが固まらない状態で議論が続けば、使い勝手の悪い機能が追加されてしまう恐れはあるでしょう。
しかし、「単一の方法を"実装として決め"た上で議論を進めなければならない」という主張は明らかに極論です。
それを前提とした乾さんの考え方には無理があります。
「使い勝手の悪い機能が追加されるのを防止する」ことは必要な視点だと思いますが、
それを達成するために選んだ手段が「極論を持ち出す」ことでは、賛同しろと言う方が厳しいでしょう。
さて、
想定する実装を絞った上で議論を進めることは、参加者間のイメージを固めやすくなると同時に、
想定した実装に沿って使えば使い勝手は悪くないが、それから外れると非常に使い勝手が悪い機能が追加されること、
言い換えれば、
柔軟性(や拡張性)に欠ける機能が追加されることに繋がる恐れがある
ということでもあります。
例えば、OGsのツインユニットのみを想定して議論を行った場合、追加される機能は、
ツインユニットの再現は非常に簡単であるが、2&3次αの小隊システムやGジェネシリーズのスタック制の再現は困難な機能
となってしまう恐れがあります。
もちろん機能が不足しているならばその機能を追加すれば良いわけですが、
補足部分でも似たようなことを書きましたが、後から追加する形になると、当然、構成に無駄な部分が生じます。
データ・シナリオの互換性を保つために、既存の機能の変更には慎重なSRCにおいては尚更です。
つまり、
想定するものを絞りすぎれば、柔軟性に欠けたものが追加され、後の再拡張にも悪影響を及ぼしかねない。
かといって絞りこみを行わなければ、議論自体がまとまらなかったり、使い勝手の悪い機能が追加されてしまう。
です。
そういう関係が存在する以上、「まったく想定するものを絞りこまない」や「一つに絞る」という極論は、
少なくとも議論を始めようという段階で選ぶ方針としてふさわしくありません。
●
＞ そして、このツリーの目的はユニットが既にいるコマに進入するときのコマンドの
＞実現をする事なので、それをシナリオで実装するとどうなるかのイメージを提示し
＞現状の機能で実現可能なので、もっと他の部分を検討するのが優先ではないかと
＞理解して欲しかったと言うことなのです。
考え方の前提から食い違った意見ですし、ツリーの目的の時点から誤解しています。
乾さんが繰り返し述べていたのは
「ユニットが既にいるコマに進入するときのコマンド」が「シナリオで実装するとどうなるかのイメージを提示し」
それが「現状の機能で実現可能」であること
だけです。
「一つの方法が実現可能である」
ことを
「もっと他の部分を検討するのが優先ではないか」
という主張につなげるには
「シナリオで実現する方法が一つでもあれば、それ以外の方法は不要である」
という考えが抜けています。
そしてその、「シナリオで実現する方法が一つでもあれば、それ以外の方法は不要である」という考え方を、私はしていません。
ゆえに、
実現可能であることだけを何度繰り返し主張しても、
「他の部分の検討を優先するべきだ」という主張には説得力が生じません。
再現可能であることをわかっている相手に「再現可能である」ことを主張し続けていただけでは
一番言いたいはずの主張に繋がりません。
再現可能であるかなんかよりも先にまず「一つあればいい」ことを説明する(最低でも、自分がそういう前提で意見を出していることを相手に示す)べきだったでしょう。
●
私はNo.5721にて
>○３
> 「グループ」の作成＆解散はユニットコマンドで実行するものですので現状で再現可能かと。
と書き、
その上で
> "すでに味方ユニット(グループ)が存在するマスに、他の味方が移動先に指定して進入する"
ことを実現するための機能追加を提案しました。
「実現方法は一つあればいい」という前提で考えると、この提案が論理的におかしい、もしくは飛んでいることは明らかです。
中箱の書いた文章の論理がおかしい場合、その原因は
・中箱の書いた論理がおかしい（中箱の頭が悪い、もしくは文章が下手）
・中箱がわざとおかしい論理を使った（中箱の性格が悪い）
・読んだ人間が読み間違えている
のどれかです。
であれば、ご自分の読解力を信じるのであれば、論理がおかしいことを指摘する事から始めるべきでしょう。
そうでなければ、もしも「書いた論理がおかし」かった場合、会話が通じない、という事態に陥りかねません。
…というか、現に陥ったわけですが。
乾さんは私の示したものを理解していませんでしたし、私も乾さんのご意見を理解できていませんでした。
●
親記事の最後にも書いたことの繰り返しですが、
以後、このような無駄の多いやり取りを避けるためにも、
不自然さ、おかしさを感じたのであれば、それを「解釈」した上で意見を続けることは控えてくださいませんでしょうか。
実際にここまで見事にズレた意見の応酬をしてしまったわけですし。
汎用データ管理人という議題と密接な関係にある立場で、戦々恐々なり興味津々なりになるのは仕方が無いんだろうなーとは思いますが、
であればなおのこと、レスをつける際には慎重であるべきだと思います。
●
あとこれはちと余談気味な話で、一ヶ月経った今ではもう割とどうでも良くなった疑問なのですが、
乾さんは5721のどこを読んでレスしていたのかな、と。
なにせ、
> ３．「SRWOGs」のツインユニット@PS2
や
>○３
> 「グループ」の作成＆解散はユニットコマンドで実行するものですので現状で再現可能かと。
と書いた直後のレスで
＞現状の機能でも「合流先の座標orユニットID」を取得することは可能です。
＞ （隣接後にコマンドを表示するタイプのSLGでは良くある形式ですし、SRW-OGのツインユニットシステムもこの形式です）
と、私から見れば分かりきったことをわざわざほぼそのまま繰り返して書かれたものですから、
正直、「一体5721のどこを読んだんだろう？」と心配になりました。
もちろん、レス元の文を書き、直後の5725の時点で指摘しなかった私にも問題があったのは確実でしょうけれども。
●
5724,5726,5730ですが、意見の前提があまりに違いすぎるので、すいませんがレスは控えさせていただきます。
どうしても外せない意見が含まれていたのであれば、前提の違いを考慮した上で再度お願いします。
なお、ツリーへの参加不参加はご自由になさってくださって結構です。事前の宣言は一切不要ですので
では。
|
新着情報