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

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

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

■5455 / inTopicNo.1)  「重複状態生成システム」ツリーその2
  
□投稿者/ 鉄仮面大将軍 -(2007/04/10(Tue) 18:38:42) [ID:2eMbhZ9o]
    2007/04/10(Tue) 18:39:42 編集(投稿者)

    私は鉄仮面大将軍です。
    便宜上名乗っていますが、正式なものではありません。
    あまりこの名前を広めないでください。
    意見交換掲示板での議論が終わり次第ホームページ公開までこの名前は使いません。
    ご理解ください。

    中箱さんの言うとおり、新たなツリーを立てさせていただきました。

    中箱さんの案ですが、とりあえず決定している事項はこれだけです。

    このオプションを使うと、一定の条件を満たす場合に限り、同一マスに複数のユニットが存在できるようになる。
     (条件の設定方法は要議論。デフォルトをどのようにするかも)

    ・同一陣営のユニットが同一マスに複数存在する場合、「重複状態」という特殊な状態になる。
     (以下、重複状態にある一連のユニット群を「グループ」と便宜上呼ぶ)
    ・重複状態になっているユニット群は、移動・攻撃などは原則グループごとに行われる。
    ・グループには順番が存在し、攻撃やアビリティにはその順番が関係する。
    ・グループ(同一マスに存在する全ユニット)は、順番を含めてシステム配列で管理する。

    システム配列に関しての私の案

    SRCにおける文字列表記でいきます。
    変数部分には次の値が代入されます。

     小隊番号=小隊が作られた順番(小隊がひとつもない場合、番号は完全にユニットIDの番号部分に同調する)
     小隊順=その小隊内での番号(実際に攻撃を行うユニットは1)

    変数例1:"小隊[$(小隊番号),$(小隊順)]"
    変数例2:"小隊$(小隊番号)[$(小隊順)]"

    中箱さんは他にこのような案も考えておられます。

    「重複配置可能Lv*」

    突然出てきたので、効果や使い方がまったくわかりません。
    これの説明をお願いします。すみません。
引用返信/返信 削除キー/
■5456 / inTopicNo.2)  現案を理解していますか?
□投稿者/ 中箱 -(2007/04/10(Tue) 19:30:46) [ID:8NrUE61r]
    さて、
    >中箱さんの言うとおり、新たなツリーを立てさせていただきました。
    とのことですが
    案を大幅に見直した事で新ツリーに移行したのではなくて、
    私が言ったから新ツリーを立てた、と言いたいわけですね?

    私がNo.5453にて
    >・・・まあ私としては
    >>理由はこの時点で既にレスを付けすぎているからです。
    >は、この段階でツリーを立て直す理由にはならないと思いますが。
    と、ツリーの立て直しに対してはむしろ反対である旨を申し上げているにもかかわらず。

    一体ドコをどう解釈すれば、
    >中箱さんの言うとおり、新たなツリーを立てさせていただきました。
    などという無責任な発言に繋がるのでしょう?


    第一、少しでもツリー主として実際に議論を取り仕切る気があるのなら、
    このような、主体性の感じられない態度にはならないと思いますが。



    >中箱さんの案ですが、とりあえず決定している事項はこれだけです。

    私の案を採用することを決定したのは鉄仮面大将軍さんです。
    その時点で、「中箱の案」とは言うべきではありません。


    これも勘違いされているようですが、
    すでにこの案は、あなたが採用した、あなたの案です。
    この案に対しての疑問・確認などが出された時、回答するのはあくまでも原則として鉄仮面大将軍さんであり、
    私中箱が回答する必然性は存在しません。


    >中箱さんは他にこのような案も考えておられます。

    >「重複配置可能Lv*」

    >突然出てきたので、効果や使い方がまったくわかりません。
    >これの説明をお願いします。すみません。

    現段階において、説明する必要がある問題なのですか?




    念のため申し上げておきますが、
    議長自身が理解できていない案についての議論を取りまとめていくことは不可能だと思います。

    案を適切なものに変更するか、取りまとめ役を適切な人物に変更するか、のどちらかであるべきかと。



    では。
引用返信/返信 削除キー/
■5457 / inTopicNo.3)  Re[2]: 現案を理解していますか?
□投稿者/ 鉄仮面大将軍 -(2007/04/10(Tue) 19:56:17) [ID:2eMbhZ9o]
    決定案であり、変更分もないのですが、もう一度書きます。申し訳ありません。

    このオプションを使うと、一定の条件を満たす場合に限り、同一マスに複数のユニットが存在できるようになる。
     (条件の設定方法は要議論。デフォルトをどのようにするかも)

    ・同一陣営のユニットが同一マスに複数存在する場合、「重複状態」という特殊な状態になる。
     (以下、重複状態にある一連のユニット群を「グループ」と便宜上呼ぶ)
    ・重複状態になっているユニット群は、移動・攻撃などは原則グループごとに行われる。
    ・グループには順番が存在し、攻撃やアビリティにはその順番が関係する。
    ・グループ(同一マスに存在する全ユニット)は、順番を含めてシステム配列で管理する。

    システム配列に関しての私の案

    SRCにおける文字列表記でいきます。
    変数部分には次の値が代入されます。

     小隊番号=小隊が作られた順番(小隊がひとつもない場合、番号は完全にユニットIDの番号部分に同調する)
     小隊順=その小隊内での番号(実際に攻撃を行うユニットは1)

    変数例1:"小隊[$(小隊番号),$(小隊順)]"
    変数例2:"小隊$(小隊番号)[$(小隊順)]"

    意見は親記事ではなく、このレスにお願いします。
引用返信/返信 削除キー/
■5458 / inTopicNo.4)  Re[3]: 現案を理解していますか?
□投稿者/ 中箱 -(2007/04/10(Tue) 21:31:04) [ID:8NrUE61r]
    では改めて。

    システム配列に関しての案において "小隊" という、現行のSRCには含まれない用語が
    >小隊番号=小隊が作られた順番(小隊がひとつもない場合、番号は完全にユニットIDの番号部分に同調する)
    のような形で使われていますが、"小隊" とは何ですか?

    現在「決定案」として提示されているものの中には "重複状態" "グループ" という用語こそありますが、
    "小隊" という用語はありませんし・・・。
    案全体を改めて提示しているのですから、用語についての解説も改めて提示するのが基本でしょう。


    何度も同じ指摘をさせないでください。わざわざ指摘する方もするほうかもしれませんが。

    素早いレスは結構ですが、速度だけ早くても内容が薄ければ意味はありません。ツリーの無駄遣いです。


    頭を使った案やレスをお願いします。



    ちなみに少々気の早い話ですが、私は現案でのリクエストには反対ですので。
    実装を求める理由や実装の価値が、予想される機能追加やそれに伴う手間につりあうようには思えませんので。
    まあ今後の内容次第で、とも思っていますけれど。


    では。
引用返信/返信 削除キー/
■5459 / inTopicNo.5)  Re[4]: 現案を理解していますか?
□投稿者/ 鉄仮面大将軍 -(2007/04/10(Tue) 21:44:19) [ID:2eMbhZ9o]
    システム配列に関しての私の案(変更分)

    SRCにおける文字列表記でいきます。
    変数部分には次の値が代入されます。

     重複状態番号=グループが作られた順番(グループがひとつもない場合、番号は完全にユニットIDの番号部分に一致する)
     重複状態順=そのグループ内での番号(実際に攻撃を行うユニットは1)

    変数例1:"小隊[$(重複状態番号),$(重複状態順)]"
    変数例2:"小隊$(重複状態番号)[$(重複状態順)]"

    意見は親記事ではなく、このレスにお願いします。
引用返信/返信 削除キー/
■5460 / inTopicNo.6)  横槍、失礼いたします
□投稿者/ JAPANweb -(2007/04/11(Wed) 00:40:04) [ID:nPhfoJBm]
    2007/04/11(Wed) 00:53:39 編集(投稿者)
    2007/04/11(Wed) 00:52:42 編集(投稿者)

    どうも、はじめまして。
    SRCユーザーでアイコン描いております、JAPANwebと申します。
    どうぞ、よろしくお願いします。

    いままで審議の流れを見てまいりましたが、鉄仮面大将軍さんはこの提案を採決まで持っていきたいのでしょうか?

    やはり提案となると重要性もそうですし、何よりその提案に対する説明が足りないような気がします。
    中箱さんが説明を求めてるのに対し、鉄仮面大将軍さんは実装論ばかり述べているように見えてしまうのが、少々残念な印象です。

    そこで私からの提案…もとい、要望なんですが。

    ●案に対する、明確な説明
    中箱さんもNo.5458おっしゃっていたように

    >システム配列に関しての私の案(変更分)

    >SRCにおける文字列表記でいきます。
    >変数部分には次の値が代入されます。

    > 重複状態番号=グループが作られた順番(グループがひとつもない場合、番号>は完全にユニットIDの番号部分に一致する)
    > 重複状態順=そのグループ内での番号(実際に攻撃を行うユニットは1)

    >変数例1:"小隊[$(重複状態番号),$(重複状態順)]"
    >変数例2:"小隊$(重複状態番号)[$(重複状態順)

    これだけでは、説明不足かなと私も感じます。
    やはり「小隊」について詳しい説明があると、意見が広がるかと思うのですが。

    ●「小隊」実装に対する、メリットの説明
    No.5446にてメリットの説明をなされていますが

    >・「SDガンダムGジェネレーション」のシリーズに準ずる
    >  チーム編成インクルード作成可能。

    > 「Option「重複配置(仮)」」と組み合わせた場合のメリット

    > ・「第2次スーパーロボット大戦α」に準ずる
    >   小隊インクルード作成可能。
    > ・「サンライズ英雄譚」のシリーズに準ずる
    >  戦艦カードデッキインクルード作成可能。

    一言申し上げるようですが、SRCは必ずしもスーパーロボット大戦等だけの作れるツールではないことはご存知ですよね?

    他にも様々なSRPGが手軽に作れるツールでもあるわけです。
    (例えて言うなら、ファイアーエムブレムなどの等身大作品)
    私はスーパーロボット大戦もプレイしていますが、他のユーザー全てがスーパーロボット大戦をプレイしてるとは限りません。

    そこで私からの要望なんですが

    スーパーロボット大戦
    SDガンダムGジェネレーション
    サンライズ英雄譚

    以外のプレイユーザーでもメリットがあることを踏まえた上で、説明を求めたいのですがいかがなものでしょうか?

    これらを明確に説明してくれれば、他者からの意見が舞い込むかと思います。
    そこを検討していただけるように、私からお願いします。

    最後になりますが、長文失礼いたしました。

引用返信/返信 削除キー/
■5462 / inTopicNo.7)  Re[6]: 横槍、失礼いたします
□投稿者/ 鉄仮面大将軍 -(2007/04/11(Wed) 01:32:25) [ID:2eMbhZ9o]
    システム配列に関しての案(変更分)

    SRCにおける文字列表記でいきます。
    変数部分には次の値が代入されます。

     重複状態番号=グループが作られた順番(グループがひとつもない場合、番号は完全にユニットIDの番号部分に一致する)
     重複状態順=そのグループ内での番号(実際に攻撃を行うユニットは1)

    変数例1:"重複状態[$(重複状態番号),$(重複状態順)]"
    変数例2:"重複状態$(Wide(重複状態番号))[$(重複状態順)]"
    変数例3:"重複状態ID[$(重複状態番号)]"
         "重複状態順序$(Wide(重複状態番号))[$(重複状態順)]"

    これは「Option「重複配置(仮)」」の指定にかかわらず作成されるものです。
    変数自体に代入されるのはユニットIDです。
    「小隊」の記述は消去しました。


    このシステムに求めるのは「複数ユニットのグループ化」です。
    これが「小隊」であり、「重複状態」であり、「グループ」なのです。

    現状でもグループIDを使えば、汎用型ユニットを一度に扱うことが可能です。
    しかし、それだけではなく、名前のあるユニットをもグループ化して扱いたいのです。

    複数のユニットが組んで動くというのは戦略シミュレーションゲームによくありますね。
    それからグループヒーローの再現もいくらか楽になると思われます。
    今まではバラバラに動くままでしたが、常に一緒に行動することで扱いやすくなるというメリットもあります。
    コンシューマーですが、戦隊ヒーローを参戦させ、失敗した例があります。
    このシステムはそれを解決します。

    グループ化すれば戦闘は楽になりますが、敵も増やしてやればバランスは取れます。

    なによりもユニットでマップが埋まってしまうことも防げます。
    SRCのマップは有限(初めて知った時は驚きました)です。
    コンシューマーはともかくSRCは必ずアイコンが用意されているわけではありませんので、
    マップがユニットで埋まるとどのユニットがいるのかを一発で把握するのは困難です。
    そのためのシステムです。
    小隊が増えるとやはり埋まってしまいますが、制限次第では全ユニットを入れることも可能です。
    制限は完全にシナリオローカルなので、こういうこともできます。
    コンシューマーには1万人部隊編成というものもあります。
    これもシナリオの制限次第では可能です。


    頃合いを見てツリーを移行します。今すぐにというわけではありません。
引用返信/返信 削除キー/
■5463 / inTopicNo.8)  ツリー移行のタイミングについてのみ
□投稿者/ 中箱 -(2007/04/11(Wed) 01:55:49) [ID:8NrUE61r]
    2007/04/11(Wed) 02:12:17 編集(投稿者)

    むやみにツリー移行を繰り返すということは、意見交換の最中である他のツリーを後ろへ押し流してしまうことも意味します。
    このツリーの議題に興味がなく、他の議題で意見交換を行っている最中の方々への迷惑行為になりかねません。

    掲示板の注意書きとして
    >■ 15以上のレスがついたのを目安に新しいツリーを立てるようにしてください。
    >  20以上のレスがつくと、返信出来なくなります。
    と明記されているのですから、
    特に明確な理由がないのであれば、ツリーの移行タイミングについては大体目安にあわせるべきでしょう。


    元から目安に合わせるつもりがあれば、
    >頃合いを見てツリーを移行します。今すぐにというわけではありません。
    という発現は不要なのですから。



    他の点については、意見を述べるだけの意味があるかどうか熟慮した上でいずれ。
    では
引用返信/返信 削除キー/
■5464 / inTopicNo.9)  Re[7]: 横槍、失礼いたします
□投稿者/ JAPANweb -(2007/04/11(Wed) 02:33:58) [ID:nPhfoJBm]
    早い返答、ありがとうございます。

    >このシステムに求めるのは「複数ユニットのグループ化」です。
    >これが「小隊」であり、「重複状態」であり、「グループ」なのです。

    小隊の意味はわかりました、回答ありがとうございます。

    >それからグループヒーローの再現もいくらか楽になると思われます。
    >今まではバラバラに動くままでしたが、常に一緒に行動することで
    >扱いやすくなるというメリットもあります。

    いわゆる戦隊モノですね。
    確かに、共に行動する事に意義があるかとは思います。
    でも戦隊モノでも常々一緒とは限らず、誰かが窮地に陥ったりとする表現は出来なくなるのではないでしょうか?

    既存のデータを見てみますと、必殺技は合体技として定義されていますので
    常に一緒に行動することで扱いやすくなるというメリットは、
    必要なのかと疑問に思うのが正直な意見です。

    >コンシューマーですが、戦隊ヒーローを参戦させ、失敗した例があります。
    >このシステムはそれを解決します。

    私個人の意見ですが、既存のデータは完成度が高いのでそこまで失敗しないかと思うのですが。
    それに失敗の度合いにより、多少いじくるなどの工夫も必要かと思います。
    私が文面で感じた事なのですが、
    「自分が失敗したから、システム自体を改変したい」
    という道理にしか聞こえません。

    >グループ化すれば戦闘は楽になりますが、
    >敵も増やしてやればバランスは取れます。

    それだけ、プレイヤーの負担がかかると思います。
    低容量で遊べるのが、SRCの強みだと考えてますので。
    そこにも私は賛同できません。

    >SRCのマップは有限(初めて知った時は驚きました)です。

    足元すくう意見ですが、
    鉄仮面大将軍さんが最初におっしゃっていたメリットの中の
    「スーパーロボット対戦」も有限ですよね?
    あと、他のSRPGも大概は有限マップですが。

    >コンシューマーはともかく
    >SRCは必ずアイコンが用意されているわけではありませんので、

    すいません、アイコンでしたら自分で探すのがここでの道理じゃないかと。
    アイコン作者もいっぱい居ますので、そういう意味では失礼ですよ。

    >マップがユニットで埋まるとどのユニットがいるのかを
    >一発で把握するのは困難です。

    あの、SRCをプレイしてると分かりますが
    「全体マップ」ってコマンド、ご存知ですか?
    完全に把握できなくても、敵味方の判別ぐらいなら出来ますが。

    >小隊が増えるとやはり埋まってしまいますが、
    >制限次第では全ユニットを入れることも可能です。

    1つの「重複状態」という陣営に、全ユニット入れるメリットは
    果たしてあるのでしょうか?
    制限があるからこそ、戦略という遊びの幅が広がると私は思うわけです。

    >コンシューマーには1万人部隊編成というものもあります。

    どのコンシューマーかは存じませんが、
    他のSRCユーザーは本当に必要としているのでしょうか?
    そこをじっくり考えてみてください。

    >頃合いを見てツリーを移行します。

    あの、No.5456にて中箱さんが申し上げていますように
    「ツリーの乱立」は迷惑な行為だと思います。
    まだ、このツリーは十分に討論ができるスペースがありますので、
    タイトルを変えるなりして使用していったほうが良いかと思いますが。

    他の方も色々と提案を出して討論しているのに、
    ツリーばっかり立ててしまうと他の古いツリーが過去スレッドへと行ってしまいます。
    このツリーだけではなく、他にも討論してるツリーがあるので、乱立だけはご遠慮願います。

    では、失礼します。

引用返信/返信 削除キー/
■5465 / inTopicNo.10)  Re[8]: 横槍、失礼いたします
□投稿者/ 鉄仮面大将軍 -(2007/04/11(Wed) 03:06:21) [ID:2eMbhZ9o]
    戦隊云々に関してですが、
    それを表現するためのイベントコマンドではないのですか?
    イベントコマンドで分割できなければ不便なだけです。

    失敗のことは自分が失敗したわけではなくゲームとして失敗しているのです。
    少なくとも私はそう思っていますし、戦隊ヒーローが一人単位で扱いにくいことはわかると思います。
    戦隊ユニットは基本的にグループで行動し、欠けると不利になるというのが理想だと思われます。

    SRCにおいて「高いレベルでバランスを取る」という意味がここにあります。
    というよりこのあたりは全てシナリオローカルで制御しますので、問題ないでしょう。
    難易度の高低の問題ですね。

    アイコンに関してですが、
    ちょっとよくわかりません。
    どうも必ずアイコンがあるものと勘違いされているようです。
    アイコン作者はSRCの開発スタッフではありません。
    アイコンを作ることは義務ではありません。
    必ずあるとは限らないんです。考えて発言してください。すみません。

    敵味方の判別の話をしているわけではないのですが。
    アイコンのあるユニットはすぐにそのユニットだとわかりますが、
    アイコンのないユニットは敵味方がわかっても一発ではわかりません。
    いちいちカーソル(?)をあわせてやらないといけません。これでは一発でわかるとはいえません。

    重複状態に制限がないのであれば、他の面で制限をかければいいだけのことです。
引用返信/返信 削除キー/
■5466 / inTopicNo.11)  Re[9]: 横槍、失礼いたします
□投稿者/ JAPANweb -(2007/04/11(Wed) 03:37:44) [ID:nPhfoJBm]
    早いレス、ありがとうございます。
    私も自論で申し訳ないですが。

    >戦隊云々に関してですが、
    >それを表現するためのイベントコマンドではないのですか?
    >イベントコマンドで分割できなければ不便なだけです。

    常に一緒に行動することでしょうか?
    それで囲ってしまっても、戦隊としての機能は果たせるかとは思いますが、
    「自由」という幅は減るかと思います。
    クロスオーバーとかも、SRCの魅力の1つだと考えてます。

    >失敗のことは自分が失敗したわけではなくゲームとして失敗しているのです。

    これはSRCの本体機能として失敗だと、解釈してよろしいのでしょうか?
    そうだとすると、誠に遺憾です。

    >SRCにおいて「高いレベルでバランスを取る」という意味がここにあります。

    こちらは現存のSRCはレベルが低いと、解釈してよろしいのでしょうか?
    私からすれば、みんなで素材を持ち寄って作れるゲームとしてはレベルが高いと思いますが。

    >アイコンに関してですが、
    >ちょっとよくわかりません。
    >どうも必ずアイコンがあるものと勘違いされているようです。
    >アイコン作者はSRCの開発スタッフではありません。
    >アイコンを作ることは義務ではありません。
    >必ずあるとは限らないんです。考えて発言してください。すみません。

    >敵味方の判別の話をしているわけではないのですが。
    >アイコンのあるユニットはすぐにそのユニットだとわかりますが、
    >アイコンのないユニットは敵味方がわかっても一発ではわかりません。
    >いちいちカーソル(?)をあわせてやらないといけません。
    >これでは一発でわかるとはいえません。

    そうですね、必ずしもアイコンはあるとは限りません。
    ですが、無かったら自分で作るなどの工夫も必要です。
    おっしゃるとおり、アイコン作者はSRCの開発スタッフではありません。
    アイコンを作ることは義務ではありません。
    でも私はアイコン作者として、皆さんに使ってほしいから描いているんです。
    あと、いろんなところでアイコン埋めている作者さんも多々居ますので、
    そちらの方も探してみてはいかがでしょうか?
    リクエストという方法もあります。

    この件に関しては、私も言葉足らずでしたね。
    深くお詫びを申し上げます。

    >重複状態に制限がないのであれば、他の面で制限をかければいいだけのことです。

    そうですか、分かりました。
    でも実装するのに、どれだけの労力がかかるか考え直してみてください。

    では、失礼します。

引用返信/返信 削除キー/
■5467 / inTopicNo.12)  Re[10]: 横槍、失礼いたします
□投稿者/ 鉄仮面大将軍 -(2007/04/11(Wed) 04:17:55) [ID:2eMbhZ9o]
    SRCとして失敗だとは言ってません。
    ゲームというのはSRCのことではありません。
    家庭用ゲーム機のとあるゲームです。
    勿論スーパーロボット大戦の流れを組むゲームです。
    そのゲームに唯一戦隊ヒーローが出ているのですが、
    単独ユニットとしては別に弱くはないのですが、
    戦隊ヒーローとしての役割を果たすにいたってないのです。
    合体技があるので、5人で行動したほうがいいのですが、
    性能がバラバラでまとまって行動する際に非常に厄介なことになるのです。
    移動力もバラバラなので、足の遅いユニットが追いつけません。
    結果、その遅いユニットにあわせることになるのですが、
    それだとターン制限のあるシナリオで不利になります。
    こういう意味で失敗だといったのです。

    SRCのレベルが低いといっているわけではありません。
    シナリオの技術レベルが低いといっているのです。
    とはいっても今が普通のレベルならば普通のレベルです。
    そのシナリオにどれだけのシステムが使われているかです。
    使われるシステムが多ければ多いほど技術レベルが高いといえます。
    そしてその技術レベルに合わせてバランスを取れればいいのです。
    バランスなど無関係に難易度を最高まで上げる場合もあります。
    これも別の意味ではいいシナリオだといえます。
    少なくともクリアする方法がひとつだけでもあればそれは悪いシナリオではありません。

    別にアイコンの議論をしているわけでないので、
    あまり多くは答えません。
    それにアイコンを集めることとこの議題は無関係だと思います。
引用返信/返信 削除キー/
■5468 / inTopicNo.13)  Re[11]: 横槍、失礼いたします
□投稿者/ JAPANweb -(2007/04/11(Wed) 11:35:57) [ID:nPhfoJBm]
    返事が遅れて、申し訳ありません。

    >SRCとして失敗だとは言ってません。
    >ゲームというのはSRCのことではありません。

    申し訳ありません、私の勘違いです。

    >家庭用ゲーム機のとあるゲームです。
    >勿論スーパーロボット大戦の流れを組むゲームです。
    >そのゲームに唯一戦隊ヒーローが出ているのですが、
    >単独ユニットとしては別に弱くはないのですが、
    >戦隊ヒーローとしての役割を果たすにいたってないのです。

    ゲームは分かりましたが、これはSRCです。
    やはり、仕様が違うのは仕方のない事かと。

    >合体技があるので、5人で行動したほうがいいのですが、
    >性能がバラバラでまとまって行動する際に非常に厄介なことになるのです。
    >移動力もバラバラなので、足の遅いユニットが追いつけません。
    >結果、その遅いユニットにあわせることになるのですが、
    >それだとターン制限のあるシナリオで不利になります。
    >こういう意味で失敗だといったのです。

    確かに1体1体の性能は違いますが、例えに出した小隊システムを思い出してください。
    小隊ごとに特殊技能とかの性能の違いが出るのに、
    そのシステムをSRCに実装させるとなると、かなりの負荷がかかるかと思います。
    そういうことを踏まえたうえで、私は賛同できません。

    >SRCのレベルが低いといっているわけではありません。
    >シナリオの技術レベルが低いといっているのです。

    シナリオの技術レベルというのは、SRCの機能に比例するものなのでしょうか?
    今ある機能の中から、独自のインクルードを組んで制作されている方もいらっしゃいます。

    >そのシナリオにどれだけのシステムが使われているかです。
    >使われるシステムが多ければ多いほど技術レベルが高いといえます。

    ではお聞きしますが、システムを作る方はご存知ですよね?
    使われるシステムが増えるのは私もありがたいですが、SRCの製作者の負担がそれだけ増すということになります。

    >そしてその技術レベルに合わせてバランスを取れればいいのです。

    この意見にも賛同できません。
    その技術レベルを上げることが、どれだけ負担になるか考えた事がありますか?

    >バランスなど無関係に難易度を最高まで上げる場合もあります。
    >これも別の意味ではいいシナリオだといえます。
    >少なくともクリアする方法がひとつだけでもあればそれは悪いシナリオではありません。

    確かに方法は1つだけでも成り立つとは思いますが、
    今ここで言う意見ではないですよね?

    >別にアイコンの議論をしているわけでないので、
    >あまり多くは答えません。
    >それにアイコンを集めることとこの議題は無関係だと思います。

    確かにそうですね、申し訳ございません。
    アイコンの話は行き過ぎたと反省しております。


    話は戻しますが、例えに出したシステムで今のSRCに搭載するとなると、かなりの負荷がかかると予測してます。
    上記に述べたように、特殊技能とかの仕様で計算式がややこしくなるのではないでしょうか?
    もう少し簡略化した案があれば、ご提示していただきたいのですがよろしいですか?

    長文、失礼しました。
    また、話を脱線させて申し訳ございません。

引用返信/返信 削除キー/
■5469 / inTopicNo.14)  Re[12]: 横槍、失礼いたします
□投稿者/ 鉄仮面大将軍 -(2007/04/11(Wed) 15:56:17) [ID:2eMbhZ9o]
    2007/04/11(Wed) 16:16:54 編集(投稿者)

    Option「重複配置(仮)」(変更分)

    このオプションを使うと、一定の条件を満たす場合に限り、同一マスに複数のユニットが存在できるようになる。
     (条件の設定方法は要議論。デフォルトをどのようにするかも)

    ・同一陣営のユニットが同一マスに複数存在する場合、「重複状態」という特殊な状態になる。
     (以下、重複状態にある一連のユニット群を「グループ」と便宜上呼ぶ)
     (システム的にはどんな陣営のユニットとも重なることができるが、「重複状態」にはならない。)
    ・異なる陣営のユニットが重なった場合の動作は要検討。
    ・異なる陣営のユニットが重なっている場合でも
     重なっているいずれかのユニットと同じ陣営のユニットが重なった場合、
     同一グループに統合される。これはグループ同士でも同様。
     (同一マスに同一陣営のグループが複数存在することはできない。)
    ・グループ(同一マスに存在する同一陣営のユニット)は、順番を含めてシステム配列で管理する。

    とりあえずシステム的に陣営制限を解除してみました。
    これだと管理する変数もシナリオローカルでいけそうですね。

    特殊技能に関する懸念についてですが、
    どうなると思ってその心配は出てきたのでしょうか。
    変数で扱う以上、全体に影響する特殊技能を作らなければ、影響は出ません。
    そして、現時点ではそういった特殊技能は実装されていません。
    ちょっとよくわかりません。

    計算式の問題はありません。これは自身を持って言えます。
    なぜなら基本的には1対1の戦いになるからです。
    このオプションを使うだけでは複数がグループを組んでも
    敵はそのグループを各個撃破する以外に倒す方法がないんです。
    少なくともこのオプションのみを使った時はこうなります。
    他のシステムとあわせるとどうなるかはわかりませんが。

    データ共有に関しては考えておりません。
    変数で扱う以上、データ共有は必要ないですから。

    独自のインクルードを作ることもシナリオの技術レベルを上げる一因ですね。
    作者はそのシステムが必要だからそのインクルードを製作しているわけですから。
    そういう意味ではいくらでも技術レベルを上げられることになります。
    そういうことをしないシナリオは少なくともインクルードを使っていたりするシナリオよりは
    技術レベルは低いです。違いますか?
    決してSRC全体の技術レベルが低いといっているわけではありません。

    負担云々を言ったらどんなリクエストもそうなります。
    どうして私の時だけそういうことを言うのですか。
    探せば他にも言われているのかもしれませんが、ここまで露骨なものは見たことがありません。

    他のレスについてはこの議論とはあまり関係がないのでスルーします。


引用返信/返信 削除キー/
■5470 / inTopicNo.15)  No.5462以降のツリー主さんへのレス
□投稿者/ 中箱 -(2007/04/11(Wed) 18:20:00) [ID:8NrUE61r]
    2007/04/11(Wed) 18:24:03 編集(投稿者)

    レス内容が複数の記事にまたがる関係で、勝手ながらもこの場所へ枝を付けさせていただきます。
    また、非常に長いシロモノとなってしまいました読み辛い点もあるかと思いますが、ご理解ください。


    まず、No.5462について。

    ●●1
    >システム配列に関しての案(変更分)
    について。

    すでにシステム配列自体が不要だという結論に至っているのであれば無用な指摘かと思いますが、
    現段階(No.5469)までにおいて、システム配列案をやめる、という明示はありませんでしたので書かせていただきます。
    システム配列案をやめるのであれば、この点についてはスルーして構いません。


    >これは「Option「重複配置(仮)」」の指定にかかわらず作成されるものです。
    とありますが
    Option重複配置がoffの場合にも、このシステム配列は必要でしょうか?
    必要であるとお考えなのでしょうから、根拠を示していただきたく。
    根拠が示されなければ、無用な機能拡張を求めているとしか思えません。


    配列が必要である、もしくは有用であるなど、という点についての根拠を示していただくか、
    「このオプションがoffである時は配列は作成されない」と、案の訂正をお願いしたいのですが。


    ※なお、レスが無い場合は、ツリーを消費するのは心苦しいですが、再度レスを求めるつもりです。
    ※それでも返答をいただけない場合は、勝手ながら、
    ※「なんとなくで思いついた案を強引に押し通そうとしている」と解釈させていただきます。




    ●●2
    >このシステムに求めるのは「複数ユニットのグループ化」です。
    とあります。
    ここで問題になるのは "グループ化" とはどういうものを指しているのか、です。


    >これが「小隊」であり、「重複状態」であり、「グループ」なのです。
    とあるので、 "重複状態" にすることを "グループ化" と呼ぶことは分かります。

    けれどそうすると、この記述の下にある
    >現状でもグループIDを使えば、汎用型ユニットを一度に扱うことが可能です。
    >しかし、それだけではなく、名前のあるユニットをもグループ化して扱いたいのです。
    と明らかに繋がりません。


    「名前のあるユニットをも "グループ化" して扱いたい」と言っている時の "グループ化" とは
    *「"重複状態" として扱いたい」
    *「グループIDを拡張して、汎用パイロットと同様に扱いたい」
    の、どちらかの意図であると考えるのが自然でしょう。
    では、一体どちらなのでしょうか。


    前者であるならば、
    >現状でもグループIDを使えば、汎用型ユニットを一度に扱うことが可能です。
    という一文と矛盾しますので、不適切です。
    誤解と混乱を招きますので、適切なものに訂正するべきです。

    後者であっても、
    >このシステムに求めるのは「複数ユニットのグループ化」です。
    >これが「小隊」であり、「重複状態」であり、「グループ」なのです。
    と、グループIDとは無関係ですから、これもこの案件において出す根拠として不適切です。
    誤解と混乱を招きますので、適切なものに訂正するべきです。


    前者後者どちらであるか、もしくは別の解釈であるべきなのかについて、回答お願いします。


    その際、前者後者のいずれかであれば訂正もしくは撤回を。
    別の解釈であるのならば、その解釈内容と、その解釈が自然であるように文章の訂正をお願いします。


    ※なお、レスが無い場合は、ツリーを消費するのは心苦しいですが、再度レスを求めるつもりです。
    ※それでも返答をいただけない場合は、勝手ながら、
    ※「誤解や混乱を招く恐れがある表現だ、という指摘があったにもかかわらず、あえて放置した」や「提案者自身、案の目的や使用について把握しきれていない節が感じられる」
    ※と、解釈させていただきます。




    ●●3
    > 重複状態順=そのグループ内での番号(実際に攻撃を行うユニットは1)
    と攻撃を行うユニットについての言及する表現がありますが、
    現案であるNo.5457には、攻撃に関しては
    >・グループには順番が存在し、攻撃やアビリティにはその順番が関係する。
    としかありません。

    これは極端な話、
    「>システム配列に関しての私の案
     と、システム配列にのみ言及するフリをしておきながら実は、
     システム配列の枠を超えた、攻撃を行うユニットに関する仕様案も、こっそり通そうとしている卑怯な案である」
    との見方をされかねません。

    システム配列以外について、提示しておきたい鉄仮面大将軍さんの案があるのでしたら、
    "システム配列に関する案" の外のくくりで提示しなければ、誤解や混乱を招きます。
    訂正をお願いします。


    また、ここまでレスの回数を重ね続けて来たにもかかわらず、
    このような紛らわしい表現のまま(ツリー親記事のNo.5455からですね)、来てしまった理由はナゼなのでしょう?
    無論、私のように、言及しなかった側にも問題はあるのでしょうけれど。


    なんにせよ、現案さえ適切に把握しており、かつ、誠実で慎重な案出さえ心がけていれば、起こらないはずのモノかと思いますが。


    理由があるのであれば、理由の説明を願います。(凡ミス、思い込み、も理由の一つだと存じます)

    また、現在提案されている案に
    >実際に攻撃を行うユニットは1
    というものを含むのであれば、その理由の説明もお願いします。
    「なぜ、わざわざ攻撃できるユニットを1番目のもののみに制限するのか」の理由です。
    含まないのであれば、削除をお願いします。


    ※なお、レスが無い場合は、ツリーを消費するのは心苦しいですが、再度レスを求めるつもりです。
    ※それでも返答をいただけない場合は、勝手ながら、
    ※「意見を、案や文章として表現する能力に疑問のある提案者である」かつ「案に"実際に攻撃を行うユニットは1"は含まれる」+「持論にこだわり、強引に押し通そうとしている」
    ※と、解釈させていただきます。



    ●●
    以下、雑多なものも含みます

    ●●
    >複数のユニットが組んで動くというのは戦略シミュレーションゲームによくありますね。
    異論ありません。

    ●●
    >それからグループヒーローの再現もいくらか楽になると思われます。
    再現する方向次第でしょう。シナリオの領分であるとも言えます。
    再現可能な幅が広がることに異論はありませんが。


    ●●4
    >今まではバラバラに動くままでしたが、常に一緒に行動することで扱いやすくなるというメリットもあります。
    シナリオとデータ設計次第ですね。メリットであるかどうか疑問です。
    合体ユニットと違って、例えば5人のうち一人のみ別行動、という状況が現状よりも表現しやすいだろうとは思いますが。


    ちなみに、ここで言っておられる「扱いやすくなる」とは幾つかの解釈が考えられますが、
    誰の立場から見て、どのような観点から「扱いやすくなる」とお考えなのでしょう? お答えください。


    ※なお、レスが無い場合は、再度レスを求め、それでも返答をいただけない場合は勝手ながら、
    ※「イチイチ一体ずつ動かさなくて済むからプレイヤーの手間が減る。よって扱いやすくなる。それ以上のものではない」
    ※と、解釈させていただきます。


    ●●5
    >コンシューマーですが、戦隊ヒーローを参戦させ、失敗した例があります。
    >このシステムはそれを解決します。

    単なる、その「失敗したコンシューマーゲーム」のシステム設計やデータバランスなどの問題です。

    同時に、
    「現在SRCにて戦隊ヒーローを参戦させている全てのシナリオも失敗である」
    と暗に言いたいようにも取れますが。
    ・・・まさか違いますよね?


    違うのであれば、本案のシステムがなくとも解決できるということです。
    よって
    >このシステムはそれを解決します
    のような表現は明らかに誇大表現がすぎるものであり、改めるべきでしょう。


    「現在SRCにて戦隊ヒーローを参戦させている全てのシナリオも失敗である」と言いたかったのかどうか、
    違うのであれば適切な表現にしてくださいませんか。

    ※なお、レスが無い場合は、再度レスを求め、それでも返答をいただけない場合は勝手ながら、
    ※「他のシナリオについて言っているわけではないが、適切な表現ができない」
    ※と、解釈させていただきます。




    ●●6
    >グループ化すれば戦闘は楽になりますが、敵も増やしてやればバランスは取れます。
    ひとえにシナリオ側の問題です。

    Optionを設定するのはシナリオ側です。ですから戦闘が楽になるかどうかの比較はできません。
    多少詭弁じみていますが、シナリオの匙加減次第と言ってしまえば、どうあっても「バランスが取れない」状況は考え辛いですし。


    そもそも、鉄仮面大将軍さんは何を言いたくてこの一文を書かれたのでしょうか。
    私にはメリットを論じているようには思えませんから、別の何かがあると思われます。教えてください。


    ※なお、レスが無い場合は、再度レスを求め、それでも返答をいただけない場合は勝手ながら、
    ※「無意味なものであるであることに気付かず発言した」と、解釈させていただきます。


    ●●
    >SRCのマップは有限(初めて知った時は驚きました)です。
    無限だったと思っていた方が居るのだと、初めて知りました。驚きました。それだけ
    ・・・失礼。(バカにしているわけではありませんよ?)


    ●●7
    >コンシューマーはともかくSRCは必ずアイコンが用意されているわけではありませんので、
    >マップがユニットで埋まるとどのユニットがいるのかを一発で把握するのは困難です。
    どう考えても、そんなシナリオを作ったシナリオ作者の問題です。
    ここで論じるような問題でも、持ち出すようなメリットではないでしょう。

    判別のみを問題にするのであれば、ふさわしい既存のアイコンが見つからなければ最低限判別が付くぐらいのものは自作すれば済むのですから。
    (極論、ユニット愛称を文字で記した画像を用意すれば充分判別可能です)

    ・・・気分を害されたシナリオ作者・アイコン作者の方々がおられましたらお詫びいたします。


    一つ分かりやすいように、質問させていただきます。
    「あなたがシナリオを取得しプレイを始めたら、
     マップがユニットで埋まって、アイコンが用意されていないので判別が付きにくいシナリオだった」
    このような状況において、Option「重複状態」の存在はどのようなメリット・デメリットをもたらしますか?
    鉄仮面大将軍さんのお考えをお聞かせください。
    あくまでも、プレイヤーとしてどんなメリット・デメリットがあるのか、です。勘違いなされないよう。


    ※なお、レスが無い場合は、再度レスを求め、それでも返答をいただけない場合は勝手ながら、
    ※「何のメリットもデメリットも考え付かない。このような事態に、Option重複状態は無力である」
    ※と、解釈させていただきます。



    文字数制限に引っかかりましたので、まことに恐縮ながら続きは次のレス(↓)に書かせていただきます。
    http://www.src.jpn.org/neko/multibbs/cbbs.cgi?mode=one&namber=5471&type=5455&space=120&no=1

引用返信/返信 削除キー/
■5471 / inTopicNo.16)  No.5462以降へのレス続き
□投稿者/ 中箱 -(2007/04/11(Wed) 18:20:59) [ID:8NrUE61r]
    2007/04/11(Wed) 18:22:55 編集(投稿者)

    後半です。


    No.5465へのレスです
    ●●8
    >戦隊云々に関してですが、
    >それを表現するためのイベントコマンドではないのですか?
    JAPANwebさんの、具体的にどの辺りに対する返答であるのかが不明瞭です。

    引用を使うべきでしょう。
    以前の類似案における議論においても提案者が
    >レスを返すのであれば、最低限その相手の書いた文章の
    >どこに対してのレスになってるかわかるように引用文をつけて下さいね。
    >ただでさえ複雑な提案の上に、
    >「これはどこに対するレスなんだろう?」
    >って思いながら、わざわざ別ツリーまで覗きに行くのは面倒以外の何者でもないので。
    http://www.src.jpn.org/neko/multibbs/cbbs.cgi?mode=al2&namber=3123&rev=&no=1&KLOG=30 の、3128番の記事より)
    との指摘を受けた事があります。
    指摘を受けたツリー主は本ツリー主とは別のHNの人物ですが、
    過去の類似案件を持ち出されている限り、過去のツリーのでのやりとりはある程度踏まえていただきたく。


    さておき、

    「どのようなイベントコマンドを "それを表現する" 事が可能なように仕様変更すればいいか」
    もしくは
    「どのようなイベントコマンドを新設すれば "それを表現する" 事が可能になるか」
    を提示しなければ、
    >それを表現するためのイベントコマンドではないのですか?
    という発言には説得力がありません。


    イベントコマンドについて、どのように変更・新設を行えばよいかなどについては、
    現状で考えておられませすか?

    考えておられないのであればその旨を、
    考えがあるのであれば、どのようなものかを教えてください。

    (案の現状を鑑みるに、考えていなくても問題はないかと思いますが。
     説得力の無い発言だったな、とは思いますが)


    ※なお、レスが無い場合は、再度レスを求め、それでも返答をいただけない場合は勝手ながら、
    ※「今のところ、何も考えていない」と、解釈させていただきます。



    No.5468へのレスです
    ●●
    >なぜなら基本的には1対1の戦いになるからです。
    それを読み取れるだけの内容が、No.5468に挙げられた案には相変わらず含まれていません。
    上でも(●●3)でも述べましたが、
    案に含むのであればきちんと含めてください。
    含まないのであれば訂正してください。


    ●●
    >負担云々を言ったらどんなリクエストもそうなります。
    そうですね。
    ただ、物事には程度というものがあります。当たり前ですが。

    「負担があるからダメ」
    ではなく
    「負担が大きすぎることが容易に予想できるからダメ」or「負担の割に、メリットがあまりにも少ないからダメ」
    なのです。
    これがご理解できない事は無いと信じております。


    >どうして私の時だけそういうことを言うのですか。
    あなたの勘違いです。これについては "自信" をもって言えます


    >探せば他にも言われているのかもしれませんが、ここまで露骨なものは見たことがありません。
    ・・・私が前ツリーの最初のレスに挙げた、過去の類似案件の議論ツリーは見ていないということですか?
    鉄仮面大将軍さんが一番初めに提示された初案を見る限り、そんなことは絶対にありえないと思いますが。


    現に、件の過去のツリーにおける案への反対理由のうちの大きなものとして
    「SRC作者であるKeiさんの負担」が挙げられています。


    すぐ分かるハズのことですが、これは別にこの件に限りません、
    「SRC作者への負担」が反対理由にあがることはむしろ普通の光景だと存じます。
    議案に対する反対意見が出た場合、かなりの割合でその反対理由には「作者の負担と機能に対する需要」が含まれます。

    素直には議論が進まず、レス数が重ねられたツリーを見たことがあっての発言とは思えません。



    また、これほど負担負担と言及されてしまうのはそれだけ、

    ・鉄仮面大将軍の提案されている案を実装することをKeiさんが決定された場合に、大きな負担がかかるであろうこと、
    ・そもそも負担が大きければ、リクエストしたところで採用されず、無意味な結果に終わること
    を、
    言及されている方が強く感じられているという事に他ならないのでは。



    ●●
    >ここまで難癖をつけられては皆さんが私を追い出そうとしているように見えて仕方ありません。
    >皆さんにはそういうつもりはないのかもしれませんが、もうちょっと優しくしてください

    皆さんということは、私も含まれているのですね。
    難癖と言われるのは非常に心外です。

    ・・・心情的に分からなくもないですが、共感はできません。同情もできかねます。


    なぜなら私は以前のレスNo.5447にて
    >誤読・誤解を招いたり不明瞭な表現だと思われる点については
    >なるべく議論の初期段階で、はっきりとしたものに改めておくべきだと私は考えます。
    と忠告申し上げています。

    にもかかわらず、不明瞭な表現は今に至ってもあります。(●●2,3)
    案以外、レスにまで範囲を広げれば●●4,5,6,7,8が該当します。

    まあこういうものは、たとえ気を使っていても
    なかなか全て消せるものではないのも理解できますが、

    しかし後のレスNo.5458にて
    >素早いレスは結構ですが、速度だけ早くても内容が薄ければ意味はありません。ツリーの無駄遣いです。
    >頭を使った案やレスをお願いします。
    と、再度内容に注意を促す為の発言を行っている手前、

    こちらとしても一層の注意を払わざるを得ない立場だと思っています故。


    加えて、No.5453にて
    >こちらの誤読や誤解そして勘違い、失礼に過ぎる発言などに対する遺憾の意など、諸々ありましたら、
    >明確に言及していただけるとこちらとしても有難い限りです。
    とも申し上げているのですから、
    キツイと思われる箇所があったのでしたら明確に言及していただきたく。

    単に「優しく」と言われても、一体どこの力を抜けば良いのか判断に困ります。

    ここは今更言うまでもありませんが、相手の顔も見えなければ声も聞こえないただの掲示板です。
    ましてや、ほぼ改定案のみを提示するのみで、対話・議論を行いたいのかどうか疑問に思えた相手に対しては、どのような態度で臨むべきでなのか。
    ・・・恥ずかしながら、経験不足である私には分かりませんから。



    ちなみに、私自身は機能拡張には賛成なのですが、
    私自身が余計だと感じている機能拡張までは必要ないと考えていますし、
    機能拡張による負担についても考慮した上での意見を述べようとしています。

    また、リクエストが行われるのであれば、なるべく分かりやすく、良質なもので行われるべきだとも思っています。



    すでに何度も明言していることですが、
    確かに私は、鉄仮面大将軍さんのツリーの取り仕切りや案の練り方、表現方法など、さまざまな面で不安は感じています。
    しかし、別に追い出そうと画策しているわけではありません。そうであれば、初めから改案など提示しません。


    無論、
    このまま議論を続けることで得られる望ましいものよりも、続けることで起こる望ましくないものの方が、私自身が耐えられないほどに大きいと確信する事態になれば、
    「結果的に」鉄仮面大将軍さんを「追い出す」ような形になるやも知れません。

    けれども、それは目的ではありません。
    目的の為にはどうしても必要である、と確信した場合の、最後の手段であると考えています。


    疑問があるから問いただしている。不安があるから改善を求めている。不備があるからそれを指摘している。改善が見られないので、より強くそれを求めている。
    ただそれだけのつもりです。
    ・・・これは、議論に参加するものとして間違った態度なのでしょうか??


    私は、あくまでも案がより良いものとしてまとまり、リクエストを経て実装されることを期待し、それを本議論に参加している目的としています。



    非常に長くなりました。すいません。
    では。


    PS.
    上にも似たような事を書きましたが、
    もしも万が一本件が「議論を続けるべき案ではない」もしくは「議長が、議論のまとめ役としてふさわしくない」と私が判断した場合、
    議論の一参加者・掲示板の一利用者・SRCの一利用者として、議論の凍結や議長の交代を求めようと思っています。
    理由は今回のレスを読めば理解できるかと思いますので、改めて述べることはいたしません。
    重ねてご理解ください。

    無論、私が求めたところで強制力はございませんし、私の判断が間違っている可能性も充分ありえますので、誤解の無きよう。
    また、現段階においてそれを即実行する・した、という意思表示でもありません。


    ただし、最悪、掲示板管理人様に事態の収拾を求めることもありうる、とも明言しておきます。
引用返信/返信 削除キー/
■5473 / inTopicNo.17)  Re[9]: No.5462以降へのレス続き
□投稿者/ 鉄仮面大将軍 -(2007/04/11(Wed) 19:40:19) [ID:2eMbhZ9o]
    配列が必要なくなったのは行動終了ラベルで制御が可能だからです。
    重なってしまえば、その時点で同じ座標にいるユニットを配列に放り込めばいいわけですから。
    この説明だけでは不満ですか?

    グループID云々に関してもリクエストしても面白そうですね。
    しかし、今は議論の対象はそこではないので、
    言葉を借りるなら前者ということになりますね。
    この説明だけでは不満ですか?

    システム配列を使わない方針で考えるなら攻撃順序の設定には工夫が要りますね。
    グループリーダーの設定インクルードが必須になりますが、
    攻撃順序に関してだけはどうにもなりません。
    表示されたユニットだけが攻撃できるような仕様にしないといけませんね。
    もちろん特殊な武器属性があればその限りではありませんが、これは別件ですね。

    「実際に攻撃を行うユニットは1」

    これに関しては正確にはグループリーダー(ユニットアイコンがマップに表示されているユニット)ですね。
    こういったユニットはたいていの場合はシナリオライターが無条件で1にするでしょうから、
    1と言ったのです。わかりにくくてすみません。

    「扱いやすくなる」

    基本的にはプレイヤーとシナリオライターの両方です。
    どちらかと言えばシナリオライターですね。
    シナリオライターが扱いやすいならばプレイヤーの扱いやすさも当然考慮するはずですね。

    「SRCの失敗?」

    そこは皆さんの解釈にお任せします。私が口を出す問題ではありません。
    私が失敗だといったとしてそのシナリオが完全に失敗だとは限りません。
    極端な言い方ですが、一人の意見で世界は変わりません。
    「戦隊ヒーローが参戦している」というのはそのシナリオの一面でしかありません。
    その一面でしか失敗していないのに全体を失敗と言うことはできませんね。
    というより失敗しているシナリオなら最初からそのままにしたりはしないでしょう。
    家庭用ゲームならその時点で製作者が満足して発売し、その後はシナリオもシステムも訂正されません。
    そういう意味では家庭用ゲームよりはSRCは圧倒的に優秀であるといえます。
    なによりもSRCは無限の可能性を秘めています。訂正できない家庭用ゲームが劣っているのは明白です。

    「バランス取り」

    戦闘が楽になることはバランスが崩れることと同じです。
    そこで敵を増やしてバランスを取るのです。
    実際にそういうシステムを搭載しているゲームではそういうことをしています。

    アイコン云々の記述は別の方が持ち出した問題です。
    アイコン関連に関しては今後私もスルーします。
    答えを求められているのであれば答えますが。

    マップが埋まる状況ならグループ化しようとするでしょう。
    これは私だけの話ではないはずです。
    そしてアイコンのあるユニットをグループリーダーにします。
    それだけでわかりやすくなります。
    敵は戦う時に確認すればすむ話です。

    「イベントコマンド」

    今後案が出ればそれを採用しようと思っています。
    簡単に言えばイベントコマンドに関しては考慮外だったということになりますね。

    あれは酷かったですが、それをまたやろうということですか?
    他人を追い出して何が楽しいのですか? お答えください。

    やはり他の案に関しても全て解禁してしまったほうがいいのでしょうか。
    グループ内の複数のユニット(全体ではない)を一度に攻撃する武器属性なども考えているのですが。

    私が精神的にまいっているからなのでしょうか。
    時々酷い発言が混じってしまうことがあります。
    実は私は社会に出れない臆病者です。レスが素早いのもそのためです。
    それでもこうして掲示板などで会話することはできます。
    優しくしてほしいといったのはこのためです。
    皆さんは傷つかないのかもしれませんが、私は傷つきます。
    そんな人間もいます。ご理解ください。
    私の態度に疑問を持ったならすみません。

引用返信/返信 削除キー/
■5474 / inTopicNo.18)  レスの速度を落としませんか?
□投稿者/ 中箱 -(2007/04/11(Wed) 20:17:06) [ID:8NrUE61r]
    2007/04/11(Wed) 20:17:51 編集(投稿者)

    まず初めに


    読み辛いです。長文下記な私が言うと心外に思われるかもしれませんが。
    誰の、どこの発言へのレスなのかが分かりません。
    そこのところが分かるように明記していただかなければ、議論になりません。

    それゆえにNo.5471にて私は
    >引用を使うべきでしょう。
    と申し上げたのですが、読み落とされましたか?


    再度申し上げます。

    多くのレスをなさるのであれば、適切に引用を行ってください。

    そして、誰もあなたに素早いレスは求めません、求めておりません。
    今まで一度たりとも、「短時間でレスが欲しい」という求めはありませんでしたよ?


    >実は私は社会に出れない臆病者です。レスが素早いのもそのためです。

    と自称されるのでしたら尚更、

    ちゃんと時間をかけ、
    相手の文章を熟読し、
    丁寧に文章を書き、
    推敲をし、

    その上でレスを行うように心がけてください。
    ただ早いだけで実の無いレスでは、迷惑です。



    レスの間隔が一日空こうが二日空こうが構いません。
    一週間でも構いません。

    他の意見交換ツリーの速度を見てください。こんなに早いレスのやり取りを行っているのはここぐらいです。
    (速さの片棒を担いでいるのは私ですが・・・)


    >私が精神的にまいっているからなのでしょうか。

    と、自らが感じられる状態なのでしょう?



    ・・と、色々申しましたが、
    鉄仮面大将軍さんが上記のような状態であるといわれている以上、

    今回の鉄仮面大将軍さんのレス内容に関してレスしてしまうこと自体、
    議論を混乱させる元になると私は判断します。


    よって、せっかくレスをいただいておいて心苦しいのですが、
    私のNo.5470-5471の発言へのレスは、後日改めて行ってくださいませんか。


    異論が無いようでしたら、

       この記事が投稿された今現在において、No.5470-5471へのレスは一切行われていない、

    と認識させていただきます。
    (異論がなければ、レスは不要です)




    最後に申し上げるとすれば、
    SRCは娯楽です。神経をすり減らしてまで関わることはおやめになった方がよろしいかと。
    そちらにしてみれば、すり減らさせている張本人であろう私が言うと気分を害されるかもしれませんが。


    ご自愛ください。
    では。


    PS.
    なお、上で申したように、
    この私の発言後、鉄仮面大将軍さんのレスがしばらく返って来なくとも私は気にしませんのでご安心を。
    どこかしらにレスをなさるのであれば、私へのレスも求めますが。


    むしろくれぐれも、素早いレスなどなさらないでください。
    お願いします。
引用返信/返信 削除キー/
■5475 / inTopicNo.19)  Re[11]: レスの速度を落としませんか?
□投稿者/ 鉄仮面大将軍 -(2007/04/12(Thu) 05:12:05) [ID:2eMbhZ9o]

    「配列がいらないことについて」

    配列が必要なくなったのは行動終了ラベルで制御が可能だからです。
    重なってしまえば、その時点で同じ座標にいるユニットを配列に放り込めばいいわけですから。
    この説明だけでは不満ですか?

    「グループIDについて」

    グループID云々に関してもリクエストしても面白そうですね。
    しかし、今は議論の対象はそこではないので、
    言葉を借りるなら前者ということになりますね。
    この説明だけでは不満ですか?

    「攻撃順序について」

    システム配列を使わない方針で考えるなら攻撃順序の設定には工夫が要りますね。
    グループリーダーの設定インクルードが必須になりますが、
    攻撃順序に関してだけはどうにもなりません。
    表示されたユニットだけが攻撃できるような仕様にしないといけませんね。
    もちろん特殊な武器属性があればその限りではありませんが、これは別件ですね。

    「実際に攻撃を行うユニットは1」

    これに関しては正確にはグループリーダー(ユニットアイコンがマップに表示されているユニット)ですね。
    こういったユニットはたいていの場合はシナリオライターが無条件で1にするでしょうから、
    1と言ったのです。わかりにくくてすみません。

    「扱いやすくなる」

    基本的にはプレイヤーとシナリオライターの両方です。
    どちらかと言えばシナリオライターですね。
    シナリオライターが扱いやすいならばプレイヤーの扱いやすさも当然考慮するはずですね。

    「SRCの失敗?」

    そこは皆さんの解釈にお任せします。私が口を出す問題ではありません。
    私が失敗だといったとしてそのシナリオが完全に失敗だとは限りません。
    極端な言い方ですが、一人の意見で世界は変わりません。
    「戦隊ヒーローが参戦している」というのはそのシナリオの一面でしかありません。
    その一面でしか失敗していないのに全体を失敗と言うことはできませんね。
    というより失敗しているシナリオなら最初からそのままにしたりはしないでしょう。
    家庭用ゲームならその時点で製作者が満足して発売し、その後はシナリオもシステムも訂正されません。
    そういう意味では家庭用ゲームよりはSRCは圧倒的に優秀であるといえます。
    なによりもSRCは無限の可能性を秘めています。訂正できない家庭用ゲームが劣っているのは明白です。

    「バランス取り」

    戦闘が楽になることはバランスが崩れることと同じです。
    そこで敵を増やしてバランスを取るのです。
    実際にそういうシステムを搭載しているゲームではそういうことをしています。

    「アイテムについて」

    アイコン云々の記述は別の方が持ち出した問題です。
    アイコン関連に関しては今後私もスルーします。
    答えを求められているのであれば答えますが。

    「マップが埋まることに関して」

    マップが埋まる状況ならグループ化しようとするでしょう。
    これは私だけの話ではないはずです。
    そしてアイコンのあるユニットをグループリーダーにします。
    それだけでわかりやすくなります。
    敵は戦う時に確認すればすむ話です。

    「イベントコマンド」

    今後案が出ればそれを採用しようと思っています。
    簡単に言えばイベントコマンドに関しては考慮外だったということになりますね。

    「意見交換掲示板の惨劇」

    あれは酷かったですが、それをまたやろうということですか?
    他人を追い出して何が楽しいのですか? お答えください。

    「案の目的が不明瞭」

    やはり他の案に関しても全て解禁してしまったほうがいいのでしょうか。
    グループ内の複数のユニット(全体ではない)を一度に攻撃する武器属性なども考えているのですが。

    「失言について」

    私が精神的にまいっているからなのでしょうか。
    時々酷い発言が混じってしまうことがあります。
    実は私は社会に出れない臆病者です。レスが素早いのもそのためです。
    それでもこうして掲示板などで会話することはできます。
    優しくしてほしいといったのはこのためです。
    皆さんは傷つかないのかもしれませんが、私は傷つきます。
    そんな人間もいます。ご理解ください。
    私の態度に疑問を持ったならすみません。

    上記の意見に関しては私が自分で削除しました。
    酷い発言を見てのことだとは思いますが、気分を悪くされていたらそれは謝ります。


    とりあえず引用文を使わずタイトルで統一しました。
    今後からこの方法で行こうと思っているのですが、どうでしょう。


    精神的にまいっているというのはSRCについてではありません。
    社会を見て精神がまいっているのです。
    だからこそ娯楽のひとつとしてSRCを選択しました。
    しかし、議論に本気になるのは当然です。
    言うほどではないですが、まいっているのはあります。
    こちらは議論を進めたいのに議論が進まないのですから。

    勝手ながら新たなツリーを立てます。
    議論はそちらでお願いします。

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



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

このトピックに書きこむ

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

Pass/

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

- Child Tree -
- Antispam Version -