WSN追加案: メンバ選択分岐に評価メンバ式を追加
Issue #294
resolved
CW 1.50の台詞コンテントの話者選択に使用できる「評価メンバ」のように、点数方式で選択されるメンバが変化する機能をメンバ選択分岐に追加する事を検討します。
これによりパーティ内の役割や担当に応じた選択を容易に行う事が可能になります。
これは評価メンバ選択分岐というような単独のイベントコンテントとして実装する事を考えていたのですが、本質的にはメンバ選択なので、メンバ選択分岐の追加機能として実装した方が妥当と考えました。他のエンジンの実装で単独コンテントとなった場合などは、変換時に「評価メンバ選択分岐はメンバ選択分岐(評価メンバ)に変換する」などといった形で対処できるので、実際の衝突の危険性はあまりないと思います。
具体的な実装としては、「手動で選択」「ランダムで選択」の他に「評価式で選択」を設け、それを選択した場合は台詞コンテントと同様にクーポン条件を設定していく形がよいでしょう。「動けるメンバ」「パーティ全員」の条件はそのままでいいかと思います。
全員の得点が0以下になった場合は、選択失敗です。
Comments (24)
-
reporter
-
reporter
- changed status to resolved
-
御免なさい、あまりに多くの申し上げたいことがあったので実装に追いつかなかったのですが、今からでもお受付できますでしょうか？
-
reporter
もちろん大丈夫です。正式にリリースでもすれば変更は容易ではありませんが、そのためのα期間です。
-
reporter
- changed status to open
いただいていたメッセージとやり取りを全文公開して意見を募るため再オープン。
-
reporter
- attached issue_#294_direct_message_log.htm
この機能について、昨年に七篠権兵衛さんから内々にご意見をいただき、これまで議論を続けていましたが、事実上不調に終わりました。このまま議論をなかった事にする事もできませんので、七篠さんの了解の下にここで全文を公開します。
末尾付近を読めば分かるように、七篠さんとの議論は最終的に相互が納得する結論が出ないまま終了という事になりそうです。結論として機能を載せ続けることに賛成せざるを得ないと仰っていますが、それは内容に納得した上での事ではありません。私としては、この機能をこのままWSN1に入れてリリースしてよいものかどうか、迷っています。この機能に対する反対意見や懸念(特に将来的な互換性問題に発展しそうなもの)をお持ちの方は、ぜひ仰ってください。
-
reporter
- attached branch_valued_member.wsn
作りかけて放置していたものですが、「評価条件」の応用例をいくつか入れたシナリオを添付しておきます。多様な応用例は現場で必要に迫られた時に出てくる事が多いので(少なくとも私はそう)、ここで出した例は数も少なく貧弱です。たぶん他にも色々と使い出はあるはずです。が、確信を持っては言えません。
-
reporter
議論の進め方について。七篠さんの最後の方のご意見で、私の態度・姿勢の問題で話ができないと仰っているものと理解しました。さすがに自分でも気づいていますが、私はその気もなく人を怒らせたり引かせたりしてしまう所があるようです。しかし私は双方の妥協・納得・合意を目指しています。ですからこれは本意ではなく、書き方の問題です。
私は反論している時、「私を納得させる根拠を示してほしい」と考えていますし、実際にそう言った事もあります。根拠は、論理的に主張と繋がっていなければなりません。論理に飛躍があると、根拠は根拠でなくなってしまいます。
例を挙げます。
なんとなく、Issue #54のときも今回も、｢原則全て退ける｣とか｢まったく賛同できない｣という調子で 相手に倍する理屈を積み上げてでも、兎に角それを全力で阻止却下しようとしているといいますか、 お互いの納得も合意形成も知ったことではないという様な姿勢で臨まれているようにも、個人的には感じました。
Issue #54の問題はセキュリティ問題でした。ソフトウェア開発者の責任云々を措いたとしても、セキュリティ問題でダメージを受けるのはユーザです。私はユーザの不利益は極力避けたいと考えています。また、セキュリティホールは、過去の事例からして、ソフトウェアの寿命を縮めてしまいます。従って、セキュリティホールを空ける事柄は「原則全て退ける」必要があります。
さて、この考えを否定するには、
- ゴシップ問題はセキュリティホールである
- セキュリティホールはユーザにダメージを与える a. ユーザの不利益は避ける必要がある
- セキュリティホールはソフトウェアの寿命を縮める
- だから穴を空ける事は原則退ける
このうち前提の1.や根拠の2.3.が成り立たない事を示すか、2.3.と4.の間に論理的繋がりが無い事を示すか、2.3.よりも強い根拠がある事を示す必要があります。上記の議論の中では1.2.の部分の否定や、より強い根拠の提示が試みられています。具体的な内容は議論のログを見ていただくとして、反論側で示された根拠(穴も含めてCWとの互換性を維持する必要がある)も正しいものと思われたので、
実際にF9の問題で対応が必要なシナリオが改めて出てきたら、可能な限り安全な方法を探してそれで対応する
という形で一旦結論を出しています。
ついでに言っておくと、「全て退ける」の前に「原則」という言葉がついているのはそのためであって、充分な根拠があれば例外を設ける必要が生じるかも、という事を意味しています。
今回の七篠さんとの議論で私が言った「まったく賛同できません」は、(途中で一度念押ししていますが再度言っておくと)「こうした機能を取り込む事はユーザの自主性を奪う」「将来性を阻害する」といった主張に対してのものです(これももう一度言いますが、長文のご意見全体に対してのものではありません)。
私はその一言を書くためにいくつか根拠を挙げました。機械語と高級言語の対比、自動車の運転方法の対比、CWの台詞コンテントの例です。これに対して反論する時、「賛同できない」という言葉自体やそれを言った態度を云々しても、私の挙げた内容に対してなんら意見を言っていないため、意味がありません。
私の主張を否定するには、
- 例と実際の問題との間に論理的な繋がりが無い事を示す。
- 根拠として示された例よりも強い根拠を示す。例えば似たような事例で実際にユーザが自主性を奪われた例や、将来を破壊された実例が過去にあり、それがCWPyにも当てはまる証拠を示す。
といった理屈が必要です。もしも私の挙げた根拠が否定できず、根拠と主張の論理的な繋がりも否定できないのであれば、その主張は正しいと認めるしかありません。これは私にとっても同じ事で、私が七篠さんの挙げた根拠と論理を否定できなければ、私はその主張が正しい事を認めざるを得ません。もちろん、挙げられた根拠が正しくない事を示せたり、論理に繋がりが無い事を示せる場合は、私はそれを書いて反論するでしょう。これを繰り返せば、最終的には、どちらの主張が正しいか、あるいは結論を出す事が不可能な問題か、どこかに妥協点はあるか、がはっきりするはずです(もちろん双方に根気は必要です)。
私の態度や姿勢が悪いのは、以上の事とは独立の問題と思われます。私の態度や姿勢と主張の内容との論理的な繋がりが示されていないようだからです。態度については本当に申し訳ありません。それはそれとして、反論される際には、態度・姿勢と主張の内容との論理的な繋がりを示すか、関係ない場合には別問題として論じていただけるようお願いします。
-
私はこの機能をこのままWSN.1に入れるべきだと思います。 いえ、入れない理由がよく分かりません。
現在までのCardWirthは作りかけのエンジンを無理矢理動かしている、という印象が個人的ですがあります。 例えば、変数の操作すらまともにできません。十数年経ってもフラグとステップのみです。 数字を数えるだけなら桁にあわせたステップを数個 用いることで楽に実現可能ですが、もしもステップが存在しなかった場合は無数のフラグとその処理方法等を用意する必要があった と考えると実に恐ろしい話です。そこまで行くと力技といえるかもしれません。
WSN.1(CWPy)ではまさに そういった足りない部分や作りかけと思われていそうな部分の改修・実装が行われているわけですね。 なぜエンジン側で機能を提供・充実させてはいけないのか。これが分かりません。
リンクにある七篠権兵衛さんの言い分はどうにも権利やら自己を尤もらしく主張し、 振りかざしたいようにしか感じられませんでした。 目的と手段が逆転してしまっているようにも思えます。
余談ですが。話は変わって@k4nagatsuki さんの物腰といいますか。 本来ならばここに書き込むのではなく、個人的にメッセージを送るべきかもしれませんが……。
私個人がこれまでに感じた印象になりますが、 @k4nagatsuki さんは同じ生きた人間なので個人の感情や意見や多少の茶目っ気などは当然持ち合わせていますが、とても合理的であり正論で会話を行う誠実な方であると思っています。 他人を怒らせる一番簡単な方法は正論を並べるだけとも言いますが、間違った事はされていませんよ。 嫌いか好きかと問われれば好きですね。とても好感の持てる良い方です。ここまで誠実な方を他に見たことがありません。
この文に問題があれば、後ほど余談部分を削除します。
-
reporter
ありがとうございます。私も入れた方がいいと思っていますし、七篠さんの意見を全て読んだ上で、現時点で自分の主張は正しいと思っています。そうでなければ主張しないか、取り下げます。
ただ、自分で正しいと思っている事こそが心配です。後から思わぬ間違いが見つかって面倒な事になるかもしれません。ですから、私の主張を他の人の目で観察・検討していただき、穴があったらそこを突いてもらう事が必要です。私はそうした意見を欲しています。いただいた意見の根拠や論理が弱いとか、関係ないと思った場合はもちろん反論しますが、それに対する再反論も欲しています。そうした反論の応酬の中で、当初人々が思いもかけなかった事実が見えてくるものと信じています。
特に恐いのは、これが将来の互換性問題や技術的負債に発展してしまう事です。互換性を重視する方針上、一度仕様として積み込んでしまった物は永遠にサポートする必要があります。ですから、その辺りに懸念を見つけた方は指摘していただけるとありがたいです。
-
reporter
あとできれば、私に対しては構わないのですが、七篠さんの言い方などを批判するのはできれば控えていただけるとありがたいです(私が言えた義理ではないのかもしれませんが……)。
言い方・態度などよりも、主題に関係する主張の内容、根拠・ロジックなどに集中して話をした方が、議論の内容をまとめなければならない人間としては助かるという事もあります。
-
自分はSARUO氏の例のシナリオをプレイしていて、長月さんともわりと意見がぶつかっているので、七篠さんのお気持ちは若干ながらお察しできていると思いますが、論理だけで言うなら長月さんを納得させるほどの理屈はつけられないと思います。
ただ、実益で言うなら、この件はIssue #162の「道義的・心情的問題となるとそうばっさり判断してしまっていいものでもない」という方針に変化がないうちは、その一部として保留でも構わないんじゃないかと思います。 また、方針を変えるなら先にNEXTに出来ることを全て実装してしまう方が、互換性問題もなく有益に思います。
同時に七篠さんのご懸念については、この機能はWSN1専用ですから、他のエンジンはWSN0もWSN1も読めないので、この機能がPyに実装されたとしても、STARがクラシック形式(wsm ver4)で有益なパッケージという優位性は不動なのでそこまで心配はいらないのではないかとも思います。どうにか折合案を見つけることはできないでしょうか。
-
reporter
ありがとうございます。
Wsn.1で保留にするのは私個人としては構いません。この機能が早いうちにぜひ欲しいという方、急いで導入するべきではないという方、導入に反対の方、がどれくらいいらっしゃるかといった事を含めて考える必要はあります。
保留にする具体的な方法ですが、エンジン側の内部実装はとりあえず外さず、エディタ側から機能にアクセスできなくするような形を取ると思います。たぶんそれが一番トラブルが少ないでしょう。
-
七篠さんの言い方などを批判するのはできれば控えていただけるとありがたいです
正直なところツッコミ所が満載すぎて、これでも大分削りに削ってオブラートに包んだ方です……。 七篠権兵衛さんに対してのくだりは、批判（人格攻撃）というよりは指摘だと思っています。 他人に言われて初めて気付ける事柄もあるかもしれませんので。 （これが私自身へのブーメランにならないとよいのですが……。）
-
reporter
- changed milestone to 0.12.4
次のリリースまでに保留か実装かを決定する必要があるので、一旦マイルストーンを設定します。
保留になった場合、問題は次々回リリース以降へ持ち越しという事になります。
-
七篠です。
ゴネ得のような形で保留を導くのは本意ではありません。
なので自分は、この機能の実装を希望します。｢ユーザの自主性を奪う｣とか｢将来性を阻害する｣など
表現が大仰過ぎたかもしれません。
とにかく、仕様に組み替えのきかない機能、粒度の大きな機能がふえることに、
じぶんは危機感や懸念を感じていました。
(粒度の基準が先方はせりふコンテント、
自分はSTARシステム(を構成するコンテント)なので出発点から平行線かもしれないですが)
ですが、この懸念を(先方にとって理解できる)論理的理由にできない以上、
私は保留の立場を掲げる大義名分を持ち得ないことになります。実装してください。よろしくお願いします。
-
reporter
ありがとうございます。
何はともあれ、まだしばらくリリースへの時間はありますから、もっと多くの方の意見をいただければと思います。
-
「是非にも欲しい！」って事はないですけど、できる事が増えるならそれに越したことはないかなぁと思います。
今まで創意工夫を凝らさなくては出来なかった事を何も考えずに出来るようになったからといって、創意工夫を凝らすことが出来なくなるなんて事はないと思いますし。
なんやかや、物足りなければみんな自作しますよ。きっと。
-
reporter
ありがとうございます。
頑張ってしていた事が簡単にできるようになると、その先のもっと複雑な事が現実的にできるようになってくると私は思います。台詞コンテントなどが典型例で、無くても口調分けは可能でしたが、連続した会話などは至難の面倒さで、さらに役割選択を絡めて……などというのは現実的に考えられもしなかったのではないかと想像します。
今のところ意見は実装側に傾いている感じでしょうか。保留の考えを述べられているのは@akkwさんで、その前提としての道義・心情の問題は、@GhonbeNANASHINOさんについては現在はご本人から実装側の意見をいただいているので、他に同様の問題を仰る方がいない限りは成り立ちにくいものと思います。
このまま行けばβリリースと共に実装決定という事になるかと思いますが、とまれまだ時間はありますので、これまで意見を述べてくださった方も、述べられていない方も、ゆっくり考えてご意見をいただければと思います。私も技術的な面などから将来問題が出ないか考えてみます。
-
自分は実装肯定側ですね。
理由は二つあって、一つは自分がこの機能が欲しいから。
もう一つは私が実装を保留する理由を、現在このIssueを見ていない人達に説明できないからです。今現在、このwebページには極少数のユーザーしか見ていませんが、 将来見る人が増えた場合の事を考えると、
採用する理由はもちろんこと、保留にする理由も明確にするのがベストでしょう。私はこのissueの保留側の意見を明確に説明できません。そのため実装を支持します。
-
自分も技術面や実装の難易度などで問題が無ければ実装して良いと思います。
理由は単純で、あれば便利だからです。
また、この機能が実装されてもゲームバランスに影響は無く、既存のシナリオに支障は出ないはずですので、
ゲーム面では実装しない理由は無いでしょう。 -
reporter
ありがとうございます。
βリリースはたぶん来月になりますので、引き続きご意見募集中です。言うべき事があったり思いついた方は、どんどん仰ってください。
-
reporter
皆さんご意見ありがとうございました。
本日中にバージョンCardWirthPy 1(with Wsn.1)のβリリースを行いますので、そこで評価条件のリリースは確定という事になるかと思います。
β期間中しばらく間を置いて、新たに問題や議論が発生しないようであれば、このIssueは再度クローズさせていただきます。
-
reporter
- changed status to resolved
β期間中に議論が再燃する事もありませんでしたので、この辺りでクローズさせていただきます。
皆様ご意見ありがとうございました。
- Log in to comment
pull request #1183
特に問題の指摘などなかったので試験実装を行いました。仕様の詳細として「選択が失敗した時に誰が選択状態になるのか」というものがありますが、これは自動選択時の選択メンバを変更しないという挙動に合わせています。おそらくこれが最も妥当な選択で、他の実装が表れてもこのようになると思います。
対応するエディタはcwxeditorの20151115d版です。