□投稿者/ あかんべえ -(2007/12/29(Sat) 02:01:18) [ID:Odg8GJ46]
| ども、あかんべえです。
> 意見交換＆本体の更新が盛んであれば、本当はもっと夢見がちな案を私案にしたかった所なのですが(笑)
> 機能の実装を手伝えるわけでもないですし･･･
あ、それは言えますね。VB5 は有料の企業ソフトの上、もう古くなりすぎてるので、今さら入手元を捜して修得するのは二の足踏んでます。
重複を本格導入する方向、私も実はめちゃ長い目で見ていて、SRCの VB2000 など無料ダウンロード可能な基盤への移行＝実装作業者の増大 を待たねばならんかも、とか考えてもいます。
> この議論を、私案から出発して「特別な状態としては扱わない」方針で進めていくことになったのであれば、
> その後は、その問題を発生させている「限界」を広げるために必要な機能拡張案を、
> 元の案に順次追加していきたいと思っています。
>
> 私案でかなり限界近くまで絞った(と思う)ので、
> 次は「現実的」な範囲でどこまで広げられるか、広げるか、を議論したいなと。
当面の議論の方向としては、了解です。
ただ、拡張することができるにしても、やはり、重複状態をシステムに直接組み込むこととの差は大きく、直接組み込みは長期課題として残り続けると思います。
> ちなみに、思考ルーチンの問題についての私の解決案は
>
> 案の方向１：CPUが各ユニットの行動させ始める直前に実行されるラベルの新設
> (思考ルーチンは既存のものを用いる。詳細はサブルーチンで制御)
おおっ。実は私も、ほとんど同じことを考えてました。違いは、考えてたのは各ユニットの行動決定ルーチンの直前の動作タイミングだということ、ルーチン中の定数を操作可能な変数にしたり操作可能な係数を付け加えるなど思考ルーチンをちょこっと変更することです。
まあこれは、議論するとしても別のツリー、別のリクエスト課題でしょうね。これはこれで汎用性が高いので。
> プレイヤーの操作を考えた場合、
> 「移動コマンドの拡張」という形でないと、通常の移動とユニットを重ねる為の移動が別々なユニットコマンドになってしまいます。
> それは操作し辛いかなと思ったのでとりあえず私案のような形に。
「別々なユニットコマンド」になるのではなく、システム組み込みの「移動」コマンドが使われない、のだと思います。追加されるとすれば範囲内マップ座標を指定するオプションなので、どちらのタイプの移動にも対応できますから。
> 少なくとも、現在進行中の他のツリーで進めている案への採用を前提としてしまうのはできれば避けたい所です。
了解しました。まあ、私が「合流」と言ったのも広い意味で、かたちは別々のリクエストでも中身は関連提案という場合も含んでいたのですが。その意味で、今でも有力案だと思っています――これは別便にて。
> >細かい仕様はシナリオ作者に任せた方が良いのではないかなとも。
>
> と書いたとおり、現状で仕様を詰めてリクエストし、実装されたとしても、そこまで自由自在な仕様にはならない気がします。
この問題、あるいは「特別な状態として扱わない／扱う」「スタック可能／不可能」と表現されている対比について、私は二つの問題に切り分けて考えています。（論点整理の意味合いも込めて、ややくわしく書きます）
１．一つは、重複を本格導入するか、擬似的に表現するか という選択です。
「本格導入」と言うのは、マス目内重複をＳＲＣのシステムに組み込む、ということです。もっと厳密に言えば、「同一マス目に複数の『出撃』ユニットを許容し、ＳＲＣの各種機能をこれに対応させる」ということです。
ＳＲＣは「『出撃』中のユニットはマス目にせいぜい一つ」ということを前提に組み立てられているのだから、これは非常に大規模な改変にならざるをえない――これが、「重複」を考えるに当たって、まずこの選択が大問題になる理由です。
２．もう一つは、リクエストをめぐる発想の選択です。
(1)「何か特別なゲームシステムを導入する」リクエストをめざすか、
(2)「具体的なゲームシステムは導入せず、作者がゲームシステムを自由に追加できるような（汎用的な）機能」をリクエストするか、という違い。
このツリーの話題では、小隊システム、スタックごとの移動、複数ユニットでの戦闘、スタック最上部ユニット破壊時の他のユニットの登場などが「特別なゲームシステム」です。
３．「１．」と「２．」は別々の選択です。
つまり、「本格導入」かつ「２．(2)」もありえるということです。
単にマス目に複数の「出撃」を許し、その影響を受ける機能の仕様を再調整するだけ、という方向です。この方向では、戦闘も従来どおり「一つのユニットが一つの目標を選択して戦闘する」だけで、目標選択時のインターフェイス問題はありますが、戦闘システム自体には何も追加されません。
この場合、「擬似的に表現」かつ「２．(2)」の場合とくらべ、柔軟性・拡張性はほとんど違いがないと思います。
既存の戦闘システムによって制約されるということも、同じです（戦闘システムの柔軟化もいずれは欲しいと思ってますが）。
だからこの方向が否定されるとすれば、「本格導入」の困難性だけが理由になるだろう、と。
４．選択「２．」は、個々人の発想の違いもあり、ツリーでの意思疎通の問題でもあると思います。
中箱さんや私は「２．(2)」の発想で、ついついこちらを前提として話を進めてしまいます。これが、読む人によっては説明不足になってしまうかもしれない。
「(2)」の発想のリクエストが増えたのはこの１年ほどだけで、それまでずっと「(1)」タイプがリクエストの圧倒的大部分を占めていました。だから、「(1)」の発想が多数派だと思ってまちがいない。ということは、書き手にそのつもりがなくても、「この提案の具体的な、できあいの、すぐに使える、『魅力的な』、『利点』のあるゲームシステムは何だろうか？」という発想で発言を解釈されてしまうかもしれない、ということで、注意が必要だと思います。
また、「(1)」の発想が強い方にもお願いいたします。いくつかの発言はまったく別の発想に基づくもので、特別なゲームシステムは何も付け加えず、ただそれを作るための「道具」だけを付け加えるリクエストだということを、ご理解ください。
> ですから、この方針でのリクエスト議論が無駄だと思えませんし、する価値は存在すると思っています。
> 先頭切って積極的に推し進めたいかと言われると、多少迷いますが(笑)
了解しました。
長期的な諸課題を頭に入れつつ、あくまで原案を基盤に検討を進める、といった線でしょうか。
|
|
新着情報