仕様合わせ：戦闘中のキーコード所持分岐における手札カードの扱い
Issue #433
resolved
1.50では「戦闘時の現在手札に配布されているカードはアイテムカード扱い」になっているそうで、スキルやアクションカードもアイテムカード化するため、戦闘中キーコード所持分岐をアイテムカードで行えば「現在手札にこのキーコードを持っているか」という所持判定を行うのに有用なようですが、Pyでは動作しないということでした。
https://twitter.com/happydragoncat/status/797396543506563072
https://twitter.com/FlameDragon_JP/status/797408475810643968
Comments (26)
-
repo owner
-
やるなら仕様を合わせるより、正式に手札内の所持判定を追加したほうがいいのではないでしょうか。アクションカードとスキル・アイテム・召喚獣カードを指定できるようにすれば、キーコードよりも正確な判定ができますし。
キーコード判定はシナリオ外に持ち出せるメリットがありますが、これも戦闘時の手札内に対して判定するオプションを付ければ解決すると思います。
-
repo owner
- WSN仕様としてキーコード所持判定の対象に「手札」を追加する
- クラシックなシナリオでは「アイテム」が対象になっている場合は「手札」も対象になるようにする
これで対応できそうな気もしますね。
-
reporter
「カード種類：すべて」でも手札にあるアクションカードのキーコードが判定されるようです。 （Pyの実装で言えばアイテムのカードポケットに手札カードを全部突っ込んでいるような感じ？）
上記リプライにありますが、 「手札に会心の一撃を持っていたら技能カードを配布」というギミックの武器を入手できるシナリオがあるようです。 当該シナはNEXT専用ですが、ギミックは1.50でも実現できるので、ということは既に存在するか今後生まれる可能性があるので、個人的には変換のややこしさを考えるとストレートに合わせた方が良いように思います。
混乱についてはなにか特定条件下のバグがある気配ですね。
-
repo owner
上に書いたやり方であればややこしくなるほどではありませんし、対応はできます。
合わせる方が遥かに問題です。手札がアイテムカード扱いされるというのは完全にバグであって、そのバグのために一連のコードを書く方が遥かに混乱の元になります。もしそうするのであれば、最低でも互換動作にして、その挙動は通常オフになるようにしておくべきです。
-
reporter
NEXTだけならまだしも1.50でそうなっていて、変則的な実装になっているのはこれに限った話ではないですし、 CWのシステム上、手札にはアイテムが常にあり、その空きに山札からカードを引いてくるのですから 同じ枠で管理されていても別段不思議ではないでしょう。 特殊文字や効果音のシナリオ側によるオーバーライドやゲームオーバーコンテントで敗北イベントが発火するような仕様でしかないのでは。
自分には「戦闘中の手札がKC判定のアイテムカード(枠)扱い」と「付帯能力がKC判定の召喚獣(枠)扱い」に大した違いがあるようには思えません。 新しい仕様を作ってしまう方が遙かにシナリオ作者の混乱の元になると思います。
-
ちょっと待ってください。この仕様を合わせてしまうと、戦闘中にPCがキーコードを持つアイテムを所持しているかの判定が、永遠にできなくなります。このことはCW1.50と仕様差が生まれることによる混乱よりも、はるかに重大な問題だと思います。
-
reporter
1.50で出来ない以上は、現状「すべて」「アイテム」とされている枠で永遠にできないのは当然だと思います。
カード獲得コンテントで「全体（荷物袋含む）」と「フィールド全体」が場面によっては全くの同一効果であるように、 WSN側のキーコード所持分岐コンテントで「アイテム（現在手札含まない）」という項目を新設すればよいかと思いますし、「すべて」の適用範囲に現在手札を含めなくてはならないのはどの道同じです。
-
repo owner
- attached magic_boost.zip
現時点でも、このバグのせいで不具合が起きるカードが発生するはずです。しかもPCの手札という不確定な情報で挙動が変化するため、シナリオ作者は問題の所在に気づけない可能性があります。
添付したテストシナリオは発生しうるトラブルを意図的に起こしたものです。これはメジャーなキーコードを使用していますが、マイナーなキーコードはさらに危険です。
もうはっきり言ってしまいますが、このバグは有害です。厳しい条件をつけない限り対応してはいけません。
-
1.50でできないことはできないままであるべき、という考えがこの場においての正義であるならば、CWPyの独自機能のすべては悪になります。
常識的に考えて取捨するというなら、その常識はどこに定義されているのでしょうか。それは、個人の主観の中にしかありません。
あるいは、機能追加はありだが、それはどんなにいびつでもCW1.50の仕様の上に築かなければならないというのでしょうか。であれば、F9ゴシップバグなどの修正はあってはならないことです。互換性データベースは存在してはならないものです。これは極論ではないはずです。
-
repo owner
CWPyが目標に掲げている「互換性」の目的は、できるだけ多くのシナリオを問題なくプレイできるようにする事です。CWのために作られてきた資産を死なせないという事です。
しかしCW(そしてCWPy)というエコシステムはそれ自体が将来を持っている事を忘れてはいけません。死んだプラットフォームではなく、今も使われており、今後も変化し続けていくものです。現時点で新しいシナリオを作るのに有害だったり、将来有害になる事が明らかな問題を既存のシステムに見つけたら、身構える必要があります。
「互換性維持」は「どんな事でも合わせる」事を意味していません。将来に悪影響を及ぼす問題と互換性の問題が衝突した場合は、それをできるだけ無害化した上で取り込む可能性を模索する必要がありますし、CWの資産の状況がそれを許すのであれば取り込まない決断をしなくてはならない場合があります。@irakatさんの例を借りるなら、F9ゴシップの問題は無害化を試みた上で取り込んだ例で、F9終了印の例はさしあたり取り込まない事を決断した例です。
今回の問題は、実験以外の目的で利用しているシナリオが現にあるのであれば、取り込まざるを得ないバグと言えます。が、それは無害化の努力をしなくてもいいという事ではありません。
-
repo owner
すいません訂正。F9ゴシップの問題は現時点で取り込んでないですね(議論の経過はどこかにあるはず……)。
代わりに挙げるとしたら対象消去復活問題辺りでしょうか。
-
reporter
＞長月さん
以前も言いましたが、こちら側の発意による実装ではないものをバグと決めつけているのは印象が悪いです。 （KC所持分岐は1.28由来ではないので、個人的に今回は怪訝に思う程度ですが）
テストシナリオの例はトラブルというより、それを作ったシナリオ作者が1.50仕様を理解していない、 たとえば「魔法的物理属性」(魔法無効化貫通)やKC「魔法による攻撃」(気功法にも付ける)でしばしば起こっているような 勘違いとしか解釈されえないと思うのですが…。なるべく誤解を生まない仕様にすることは策定上においては推奨すべきではありますが、既に運用されているものを混乱を招くことを承知で正さなくてはならないほどの重大性があるとは思えません。
＞Irakaさん
F9バグもデフォルト有効のオプションにとどめるべきと自分は強く反対しましたし、セキュリティ上の問題という題目には納得していませんが、使用シナリオを紛失してしまい具体例を示すことができなかったので保留しています。
互換性データベースが存在してはならないというまでの語調には、ちょっと釈然としませんでした。 1.28で動かなくなったシナリオはエディタでセルフ修正がPy以前のユーザーの基本でしたので、なくても困りませんが、 あると便利程度のものだと思います。
-
repo owner
以前も言いましたが、こちら側の発意による実装ではないものをバグと決めつけているのは印象が悪いです。 （KC所持分岐は1.28由来ではないので、個人的に今回は怪訝に思う程度ですが）
「アイテム」を相手に所持判定したら「手札」が(しかもスキルやアクションカードまでも)相手になるという挙動が何をどうしたら仕様になるんでしょうか？ これはフォロー可能なレベルを遥かに超えています。プログラマの誇りを賭けて断言してもいいですが、明白にバグです。
-
reporter
自分の見解は前述の通り（システム上手札はアイテムを全て含むため）です。言い換えるとWB上の表記が手札（+アイテム）になっているべきところがアイテムと表記されているだけとも言えるでしょうか。
またそれは「ゲームオーバーコンテントを実行したのに敗北コンテントが発火するという挙動」や「PNGとして取り込んだのに実はBMPになっている」WB仕様にも言えるのではないでしょうか。後者については実際にそのような美意識でそのまま取り込むという選択をしたことで、意図せずPy専用シナリオを作る方が複数現れるという実害が発生しましたし、WSNシナリオでは格納が意味ないのでそうしているメリットも薄い(クラシック形式でPyを仮想称号分岐した上でPng画像を配布できるぐらい)です。
仕様かバグかは終局的には実装者（今回でいえばLyna氏）にしか判断できませんし、 ましてやかつてトラブルになっている相手への間接的な批判とも取れるので迂闊にすら思います。
-
1.28で動かなくなったシナリオはエディタでセルフ修正がPy以前のユーザーの基本
1.50やNextが出現してからもこれは変わりありません。1.50までとNextは、Pyのように「できるだけ多くのシナリオを問題なくプレイできるように」とは考えられていません。古いバージョンに向けたシナリオは新しいバージョンで動かないのが正常であり、それらのシナリオは作者が修正すべきで、エンジンでフォローしないのが1.50までとNextの正義です。これに倣うなら、新バージョンで動かないシナリオは淘汰し、より新しいものを生き残らせなければなりません。
そして、1.50の仕様を何よりも優先しなければならないのなら、やはりCWPyの追加機能はすべてが悪ですし、そもそもCWPyは存在してはならないはずです。
アイテムで手札のキーコードが判定できるというのは、私も明らかにバグだと思います。先にも言いましたし、k4nagatsukiさんの検証シナリオでも明らかですが、戦闘中にアイテムでのキーコードが判定できません。これが意図して設計されたものだとは、私には思えません。
k4nagatsukiさんの案
- クラシックなシナリオでは「アイテム」が対象になっている場合は「手札」も対象になるようにする
暗黒騎士さんの案
WSN側のキーコード所持分岐コンテントで「アイテム（現在手札含まない）」という項目を新設
これらは表面が異なるだけで、内部処理は同様になると私は想像しています。その上で、私はk4nagatsukiさんの案が理にかなっていると思います。
あまり現実感のない話ですが、今後CWPyがエンジンの主流となり、クラシックなCWに触れずにカードワースを始めるユーザーが現れるかもしれません。そういったユーザーは、歴史的な事情など知りません。なぜアイテムに手札のスキルやアクションカードが含まれるのか、理解できないと思います。「アイテム（現在手札含まない）」では、将来のユーザーに対してあまりにも不親切です。
-
repo owner
どう取り繕っても「手札」=「アイテム」ではありません。これは実装で横着をしてアイテムの枠を手札に流用した(かその逆を行った)ために発生した、リソースを節約する必要がある環境ではありがちなバグと想像します(ソースコードを見たわけではないので断言はできませんがおそらくCWの最初期からそうなのでしょう)。
バグを作ってしまうのはプログラミングでは当たり前で仕方のないことですが、こんな辻褄の合わない挙動を仕様として入れてしまうのはありえない事です。意図的にやったのだろうというのは設計者に対する侮辱です。
すみませんが今の私には@akkwさんがその主張で何を守りたいのかまったく理解できません。今後理解できるか不明ですが、ちょっと時間を置かせてください。
-
また、この仕様によって私のシナリオにはバグが生じているようです。発覚したため対策が可能ですが、それによって作者の望む形ではなくなります。
具体的には、アイテムキーコード「猫」があれば使用可能なスキルですが、スキル自体にもキーコード「猫」が設定してあるために、無条件に使用できてしまうようです。
-
reporter
＞Irakaさん
「できるだけ」レベルであれば1.29から何も闇雲に旧シナリオを切り捨てる仕様変更が重ねられたというわけではなく、 インフラの全ユーザーから不具合報告（今は撤去されましたが、愛護協会も専用フォーラムを用意していたはずです）を受けて、テスト版では変更された仕様をメジャーリリースでは元に戻したり、仕様変更で問題が生じると確認されたものは救済としてエンジン側でのオプションが用意されています。 かつて長月さんが直談判されたバリアント等の問題のように確かにそのような方向性が感じられるものもありますが、 互換DBにあるいくつかに限っては必ずしも旧仕様をジェノサイドするという方向性ではありません。 Pyはそれをよしとせず、自動判断する方向性なだけで互換動作を期待するユーザーにとって出力される結果は同じです。
「アイテム（現在手札含まない）」は一例で、内部処理がWSN側を付け加える形であればなんでも構わないと思います。 XEditor上の表記はわかりやすい方がよいでしょう。
＞長月さん
誇りを賭けるということでも明らかなのですが、それは長月さんの美意識なのであって、 インフラを継承する側がオリジナルのありのままを認められないのは絶対的にその挙動を肯定している側の反感を呼びます。 （前回で言えば紅月氏の反応が顕著でした）
どうにもオリジナルに対する敬意というかそういうものより「ここは間違いだからこうした方がいいだろう」的な思想が勝ちすぎに思います。 勿論WSNの実装としてその思想を役立てられるのは大いに有意義に思いますが、既存のCWに思想の混入は不要です。
最近はメイン使用がNEXTの人でも1.50やPyユーザーに配慮して 「1.50仕様で全エンジンに対応しよう」という考えの方が増えています。 この件にしても以前なら完全に挙動が違いすぎて無視されていたところを、Pyを認めた上で「ここで問題があるよ」と教えて頂いてるわけです。自分はそのような歩み寄りを無下にしてしまうことや無用な衝突を避けたいというだけです。
-
私の立場は、これまで述べた意見から察していただけるかもしれませんが、この不自然な仕様にPyが倣うと困る立場です。その上で、クラシックシナリオの挙動をこの仕様に合わせるべき理由を考えて述べます。
1.50とPyでコンテントが明らかに異なる挙動をすることは好ましくありません。k4nagatsukiさんも以前このようなことをおっしゃっていたように記憶しています。WSNシナリオをクラシック形式に変換したら、正常に動かなくなるというような仕様差は作るべきでない、という内容だった気がします。
そして、今回は同じクラシック形式のシナリオで挙動が異なってしまう事例です。Pyで正常に動作する「アイテムのキーコードを前提としたカード」は、CWでは正常に動作しません。私はPyで正常に動作するからと、CWでの動作確認を最小限にした結果、バグの存在に気づくことができませんでした。シナリオ作者として、Pyを信頼した結果、不利益を被っています。（私の心情としてはCWのバグに憤りを感じていますが、CWもPyも責める気持ちはありません。シナリオにバグを生じさせたのは私の怠慢です）
1.50を修正できない以上、挙動を合わせるならPyが折れるしかないでしょう。WSNシナリオにおいて正常な挙動が期待できるのであれば、クラシックシナリオでの異常な挙動の再現をしても、将来への悪影響はさほど大きくないと予想します。
また、WSN形式であれば手札もアイテムも正しく判定できるということになれば、WSN形式のシナリオの強みになるように思います。
-
repo owner
すみません、情報を遮断して頭を冷やしていましたが、予想以上に時間がかかってしまいました。
読み返してみた限りでは、私と@akkwさんのやり取りは、続きから再開してもどこにも着地せず問題も解決しないという事になってしまいかねないように思います。お互いに言ってはいけない事を言ってしまっている事ですし、いっその事、双方の発言を全て撤回して、最初から話をやり直すのはいかがでしょうか。
この問題を適切に解決できる案はすでにありますから、了解が取れればそこを起点にして改めて話を始めさせていただきたいと思っています。
-
reporter
この課題で途切れている、つまり自分が原因であることは明白ですし、勝手ながら心配していました。 なにかあったのでなければよかったです。
既存のCWに思想の混入は不要というくだりについて、Irakaさんから、エアリプで「人格を否定する暴言」だというような批判がありました。 またお互いに言ってはいけない事を言ってしまっている、ということから、長月さんもそのように受け止められたように見受けられます。 正直自分はそのように取られる理由が皆目見当がつきません。
「判定結果が1.50と食い違う」というのは、現時点においては、Pyも視野にいれてシナリオを作ろうとする作者ほど割を食ってしまう、CWプラットフォーム全体にとって有害な、「Pyのバグ」であり、 内的事情であるPyコードの健全性よりも、外的事情である1.50仕様クラシック形式の汎用性のために、正されるべきだというのが自分の考えです。
それが長月さんの方針と相反するものであれば仕方ありません。自分が諦めます。それはそれとして、根拠が想像でしかないのに、「ひどいバグ」「厳しい条件をつけない限り対応してはいけない有害なバグ」というような大上段からの物言いは ここでは陰口と取られかねないからやめてほしいと言ったつもりでした。 そもそも、これは本来長月さんがそう思っておられるのであれば、配布者である愛護協会やLyna氏に連絡して、修正ないし追認していただくのが真っ当なはずです。 経緯上それをしたくないというのはわかります。ならばそのようなことは言わないようにしておくべきでしょう。
自分が絶対的に筋が通っていないなと思うのはそこだけなので、自分的には合わせないのはモチベーションに関わりますが、最悪この問題は解決しなくても構いません。
-
repo owner
すみませんが、私はその話を続けるとまた揉めるとしか思えないので、反論はしません。
そしてこの問題を発展的に解決する事は可能です。もういっそ私の方で勝手に解決してしまった方がいいでしょうか？
-
reporter
わかりました。
発展的というと新規項目手札案かアイテム(手札含まない)案かですが、前者的な解決になる場合、手札にアイテムは含まれるのか、非戦闘時どういう挙動をするのか仕様衝突が生まれるような幅があるように思えたので、とりあえず合わせるのか合わせないのかを明白にしたかったのですが、前提で折り合えないのであれば、それでいいかと思います。
-
repo owner
issue
#436を作成しました。問題点・不明点があればご指摘ください。 -
reporter
- changed status to resolved
ありがとうございます。
ではこちらは閉じます。
- Log in to comment
ありがとうございます。
うーん、これはひどいバグと言うべきなんですが、合わせるべきなんでしょうか？ 他システムでもバージョンが上がると動かなくなる気がします。
やり取りを見ると、混乱カードの処理などもひどく混乱している(シャレじゃないぞ……)ようなので、下手に対応しようとしても手に負えない可能性もあります。