WSN追加案: 使用時イベントにおける死亡条件発火の問題への対応
Issue #405
resolved
現状の死亡イベントの発火条件には問題がある事が知られています。カードの使用時イベント内の効果コンテントによって死亡した場合、死亡イベントが発火しないのです。そのため、例えば「敵に召喚獣を付与し、その召喚獣がカード所持者にダメージ」というようなカードで敵を倒した場合、死亡イベントが発火しません。
これは明白な問題ですが、簡単に対処できるものではありません。というのも、単純に効果コンテントやイベント全体の後で死亡イベントが発火するようにすると、誤動作するシナリオが発生するからです。
例えば「一定確率で召喚獣によって自分自身を攻撃し、退場する敵」というようなものがいて、自分の攻撃によって退場した場合は何も起こらず、PCの攻撃によって倒された場合は死亡イベントによって何か行う、というようにしておくと、上記した単純な対策では確実に誤動作します。
この問題については長いこと「新仕様の死亡時イベントを用意して、そっちは使用時イベント中でも発火するようにすればいいのでは？」と考えていましたが、検討してみるとこの対応にも問題があります。というのは、死亡イベントを発火させないと進行が止まるなどの不具合が出るシナリオがすでに大量に存在するからです。
新仕様の死亡時イベントを追加したとしても、それらのシナリオには対応できません。互換性DBを使えば可能かもしれませんが、余りにも大量であると予想されますし、多数の漏れも確実に出ます。それでは安心して使用時イベントで攻撃を行うカードを作成できません。
そこで、以下のような形での対応を考え出しました。
- 「シナリオ名と作者名が一致するカードの使用時イベントであれば発火しない」というオプションをカードに設定可能にする
- クラシック形式からの変換時はデフォルトでオン
- ただしエディタでWSN形式を編集している時の初期値はオフでよいか
- それ以外は、常に発火する
1.は、上述したような「死亡イベントが発火しない事を前提としているために誤動作する」シナリオは、ほぼ確実にそのシナリオ内のカードによって自分自身を攻撃しているはずだ、との考えに基づいています。他のシナリオから持ち込まれた未知のカードを相手にそんな繊細なイベントを作る事はできないはずです。唯一、その「他のシナリオ」が問題のシナリオとセットになっており、持ち込まれるカードが想定されている場合は別ですが、おそらくその数は少ないため、互換性DBで対処できる範囲に収まるはずです。
2.は、今後使用時イベント内で敵を攻撃するカードを安心して作るために必要です。
CWNextは、使用時イベント中(あるいはそこから呼び出されたパッケージイベント中)で効果コンテントで敵を倒した場合、その場で死亡イベントを発火させ、その後使用時イベントに戻ってくるという実装を行っているようですので、仕様衝突の回避のためにはそれに合わせる必要があります。
ただ、この仕様にはまた別の問題があって、それは例えば「使用時イベントの途中で一時クーポンを配るなどし、敵を攻撃し、最後に後片付けをする」というようなカードが誤動作する可能性があります。具体的には、エリア移動や別のバトル開始・効果中断などが死亡イベント内にあった場合、使用時イベントが中止されてしまい、「後片付け」が動かなくなります。これへの対策は今のところ思いつきません。そもそもそんなカードが存在しないようであれば、問題無いと言えるのですが。
Comments (36)
-
-
reporter
ご意見ありがとうございます。それは面白そうですが、死亡イベントとキーコードイベントは別の話として考えた方がいいかと思います。ただでさえややこしいので、話の混乱は避けたいです。
NEXT仕様ではキーコード発火を見ないのでボス演出でよく見る「攻撃・麻痺・即死系キーコードを全て弾く」というような処理を貫通してしまって、結局のところ攻撃スキルへの利用が非推奨となっているように見えます。（仕様を勘違いしてたらすいません）
この問題は確かにその通りですね。効果コンテントというより、キーコードイベントを発火させる新しいイベントコンテントを追加した方がよさそうな気もします。
-
キーコードイベント・死亡時イベントの流れは
エリアキーコード発火→目標キーコード発火→命中・効果処理→麻痺・死亡した場合、キーコード「逃走」か効果コンテントでなければ死亡時イベント→○×キーコードの成否判定
とまたがって一体化していますのでキーコードコンテントみたいなものを作って効果コンテント・死亡時イベントと切り離してしまうのは（それはそれで使いではありますが、）あまり良くないように思えます。
NEXTとの仕様衝突を回避するには相反する仕様を共存させなければなりませんが、効果コンテントでキーコードが発火すれば、死亡時イベントの発火有無についても特殊キーコード「逃走」をつければ（通常の効果コンテントを同等の扱いにすれば）処理を増やさずに選択制にできます。
またNEXTシナリオの効果コンテントにはPyへの変換時に一律でキーコードをつければ「（デフォルト設定の）効果コンテントでは死亡時イベントが発火しない」という従来の仕様を崩すことなく、死亡時イベントの有無を両立できるのではないかなという意見です。
混乱、ということはまた自分が見当違いなこと言ってる可能性がありますが…。
-
reporter
仰る通りです。私が見当違いをしていたようです。たしかにキーコードイベントはカード効果の段階で発生するものなので、効果コンテントと一体化させるべきですね。
○・×についてもその通りだと思います。それとは別個に考えるべきかもしれませんが、フィールド全体で魔法が無効化されているというような場合、使用時イベント自体を動かしたくない事があるので、フィールド・選択メンバのキーコードイベントを発火させる方法がほしくも感じます。
キーコードの件はこのIssueで検討するのはちょっと荷が重いです。とりあえずここでは死亡イベントの問題だけに絞らせていただけないでしょうか。
#277の一覧に以下の2件を追加しました。- 効果コンテントでキーコードを発火させるオプション
- フィールド・選択メンバのキーコード条件を発火させるイベントコンテント
-
表題についてですが、長月さんが現在想定されている新仕様は 「使用時イベントおよびそこから呼び出されるパッケージの効果コンテント」と「戦闘やその他のイベントツリーでの効果コンテント」で 死亡時イベントがデフォルト発火するかどうかを切り分けるという理解で問題ないでしょうか？
以下四点の懸念があることを先にいっておくべきだったかもしれません。
・オプションなしに使用時イベントとそれ以外とで挙動が変わるのでは混乱を招きかねない。
・自分のようなASK至上主義/CW再現性重視の観点から見て、「効果コンテントでは死亡イベントが発火しないのがデフォルト」という正規の挙動を崩すのは少し抵抗がある。システム的な効果なのだからデフォルトでイベント発火しないのは自然という認識。
・消極的な活用に留まる「シナリオ名と作者名が一致するカードの使用時イベントであれば発火しない」という項目を作ると将来的に死にオプション、長月さんの仰る技術的負債にならないか。
・この変更でのメリットは「今後使用時イベント内で敵を攻撃するカードを安心して作るために必要」だが、それには結局キーコード発火が推奨されるので、これだけを達成した状態でWsn.X仕様を確定するとキーコードなしの使用時イベント攻撃スキルが作られているNEXTの二の舞になりそう。
-
「シナリオ名と作者名が一致するカードの使用時イベントであれば発火しない」をオプションにすることは反対しておきます。死亡時イベントの発火を（実質的に）抑制することは、フラグなどを適切に設定することで可能ですし、オプションでなく回避不能の仕様として実装すべきだと思います。
というのも、この意味を瞬時に理解できるシナリオ作者は意外と少ないと思うからです。このオプションを出現させては、この仕様の存在意義が破壊されるように私には思えます。
-
キーコード・死亡時イベントの流れは暗黒騎士さんが挙げてくださっていますが、その他に、ラウンド終了時に中毒死した場合にも発火します。その流れの中では、カードの効果が適用されたタイミングで発火しているにすぎません。
効果コンテントの効果で死亡することと、キーコードが適切に設定されていないカードの効果で死亡することには、死亡時イベントが発生するか否かの差しかないように思います。今後、効果コンテントにキーコードを設定できるようになっても、シナリオ作者が「カードや効果コンテントには適切にキーコードが指定されていない場合がある」と留意するだけでいい状況になるのでは。
ただし、「シナリオ名と作者名が一致するカードの使用時イベントであれば発火しない」がオプションでは、そのオプションが無意味に変更される可能性がある以上、状況が悪化するような気がします。
-
CWNextに仕様を合わせるとしても強制的に処理を割り込ませるのが問題であって、 死亡イベントの発火タイミングは使用時イベント後が無難だと思います。
-
コンテントによるキーコード設定・発火について。ものぐさな方のために、カード本体に設定されたキーコードを効果コンテントへ継承する、というオプションがあるといいかもしれません。
-
考え方のひとつとして、効果コンテントを受けた対象もカード本体の選択範囲（カード本体のキーコードの対象）に含めるというのはどうでしょうか？ ただ、攻撃と回復を同時に行う、なんていう奇特な効果を持つカードには対応しきれないという欠点がありますが……。
NEXT仕様ではキーコード発火を見ないのでボス演出でよく見る「攻撃・麻痺・即死系キーコードを全て弾く」というような処理を貫通してしまって、結局のところ攻撃スキルへの利用が非推奨となっているように見えます。（仕様を勘違いしてたらすいません）
話の内容としては別件となりますが、麻痺や対象消去など特に致命的な効果モーションを個別に無効化できるオプションがキャストカードの設定にあると嬉しいですね。欲を言えば中毒なども。
-
-
単純に効果コンテントやイベント全体の後で死亡イベントが発火するようにすると、誤動作するシナリオが発生するからです。
説明が頭に入っていなかったようです。すみません。
しかし、本当に頭が痛くなる話ですね……。 -
シナリオ名と作者名が一致するカードの使用時イベント.......
ん～、なんというか、いささかややこしすぎるような気がしますし、
下手打つとよそのエンジンに迷惑いきそうな気もするところです、
ご無沙汰してますです、七篠です。※以下、｢手札カードの組み込みイベントで敵を倒すこと｣を
｢札イベントkill｣と勝手に略しちゃいます(汗
個人的には、
｢｢札イベントkill｣で発火する死亡イベント｣を起こせるのは、
wsnの新形式なシナリオで入手した札に限るあたりはどうかなー、と思います。
既存形式由来の札で｢札イベントkill｣やっても
死亡イベントは一切起こらないよ、とも換言できます。シナリオ内専用カードの札イベントkillを死亡イベント発火の例外とする、よりは
いくらかシンプルかなーと思うのですが、どうでしょうか？
あと、死亡イベントの発火しない札イベントkillって、
かつては｢禁じ手｣扱いだったかと記憶してるんで、
こいつ実装した札が宿変換などを通じて別のエンジンへ持ち出せるようになっていた場合、
Py以外のよそのエンジン、wsn以外のよそのシナリオで問題起こすリスクがあります。クラシック形式などwsn以外の形式の札でむやみに｢札イベントkill｣を実装させぬよう、
仕様を注意深く策定すべきかな、とも愚考します。 -
クラシック形式などwsn以外の形式の札でむやみに｢札イベントkill｣を実装させぬよう、 仕様を注意深く策定すべきかな、とも愚考します。
これに強く同意するのですが、「wsnの新形式なシナリオで入手した札に限る」というのは、あまり良くないように思います。
Nextとの仕様合わせを行っているのは、将来にNextデータがをPy等他エンジンで利用できるようになる可能性を考慮してのことだと思いますが、そうなったとき、PyではNext製カードで死亡時イベントが発生しないということになりませんか。Nextにかぎらず、他エンジン製カードでも。
-
wsm7(NEXT1.60仕様)をPyで読み込む、またはwsm7→Wsn.xコンバータみたいなツールを別に作って変換する際に「本来の効果コンテント」として読み込むのではなく「死亡イベントが発火する効果コンテント」として置き換えて変換してしまえばいいと思います。
そのカードをPy→1.50以下に変換する場合、そのカードはWsnの専用機能を使っている扱いなので変換できないということで安心ですし、Py→NEXTをする時は両効果コンテントの差(オプションにしろ別コンテントにするにしろ)を取り除けばいいです。 問題はwsm4(1.20-1.50仕様)なのに、対象エンジンはNEXTを想定して死亡イベント発火を利用している場合ですが、 wsm4を選択する以上は、シナリオ側でエンジン判定を行うなど他で不具合が出ないような構造にしてくれるでしょうし、 そうでない場合でも互換DBの範囲内になるかと思います。
-
wsm7(NEXT1.60仕様)をPyで読み込む、 またはwsm7→Wsn.xコンバータみたいなツールを別に作って変換する際に 「本来の効果コンテント」として読み込むのではなく 「死亡イベントが発火する効果コンテント」として 置き換えて変換してしまえばいいと思います。
なる、そのままではイベント発火しない可能性があるなら
持ち込むときに発火できる形式に変換してしまえばよい、と。
私見を述べますと、
札イベントkillへの対応の詳細が、Pyとヨソのエンジンとで共通ならば
(あるいは札イベント内でエンジン判定を取って仕様の差を吸収しているならば※)、
はじめからPy向けに作られた札、つまりwsn形式由来の札に限定せず、
Pyの｢｢札イベントkill｣で発火する死亡イベント｣を動かしてよいと自分も思います。ただしこの｢共通ならば｣というところが曲者で、
ヨソのエンジンがPyとぴったり共通の処理をするとは限らないし、
(互換性に配慮する前提はあれど)Pyが他エンジンの仕様を
そっくり完コピするとも限らないわけです。
実際札イベント真っ最中に割り込み発火するNEXTの仕様は
筋が悪いという話が出ていますし、自分も筋の悪さは同意する次第です。
大体開発者の性格からして(以下検閲削除
一言で言って
｢札イベントkillへの対応が、先方とPyとで同じである保証はないから慎重にやろうよ｣
という考えだったんですが
｢持ち込む際に同化させれば問題ない！｣というのはコロンブスの卵でした。著作権やら変換失敗リスクやら再持ち出し時の扱いやら
ひち面倒くさい話もあるにせよ、個人的には興味深いアイデアです。
※ちょっと気になるんですが、
互換性DBってシナリオ単位で動作モードを切り替える機能だと思っていたんですが、
カード単位で｢他エンジンへの移動を考慮したイベント組んでる札は
発火を許可したり変換処理をスキップする｣とか、
そういったことも最近はできるようになってるんでしょうか？
組み込みイベントのことを考えると札の単位でも互換性DB
(か、それに類する機能)があるといいな、とは思うところですが。 -
reporter
すいません、なんか通知メールがまとめて来て反応しきれない状態なので、返信すべきと思ったところだけ返信させてください。「この意見に対してもなんか言うべき」というところがあったらご指摘ください。
また、私が使用時イベントの問題を一度に解決しようとしているのではなく、問題を一つ一つ潰していこうと考えている事をご理解いただけるとありがたいです。正直なところ、この問題は一度で片付けるには大きすぎます。議論を煮詰める必要があるので、解決を急ぐつもりもありません。
とりあえずこのIssueでは死亡イベントの発火に絞って話を進めていただけるとありがたいです。そうしないと話が発散してしまって手に負えなくなるので……。
- オプションなしに使用時イベントとそれ以外とで挙動が変わるのでは混乱を招きかねない。
これはCWNextですでにそうなっていますが、そこまで混乱が起きてはいないようです。普段やるような事ではないからでしょう。しかしややこしいので、エディタ側でヒントを出すなどしてサポートする必要はあるかもしれません。
- 消極的な活用に留まる「シナリオ名と作者名が一致するカードの使用時イベントであれば発火しない」という項目を作ると将来的に死にオプション、長月さんの仰る技術的負債にならないか。
なります。実のところ私自身もそれを大きな問題と感じています。しかしこのオプションは必要です。この切替ができないと、店と戦闘の両方があるシナリオで、購入したカードが使用時イベントで敵を攻撃するような性質のものだった場合、シナリオ内の戦闘で正常に機能しなくなってしまうからです。他に上手い解決策があればよいのですが。
また、(それが行われるとして)仕様の統合の時にもこのオプションが必要になります。CWNextのシナリオは、常に死亡イベントが発火する事を前提として作られているはずです。
CWNextに仕様を合わせるとしても強制的に処理を割り込ませるのが問題であって、 死亡イベントの発火タイミングは使用時イベント後が無難だと思います。
私もそう思いますし、そうなっているものと思っていましたが調べてみたらそうでもなかったという事で、これは仕方ありません。仕様の衝突を避けるために、遺憾ながら合わせるべきです。
ただしこの｢共通ならば｣というところが曲者で、ヨソのエンジンがPyとぴったり共通の処理をするとは限らないし、(互換性に配慮する前提はあれど)Pyが他エンジンの仕様をそっくり完コピするとも限らないわけです。
これは、例えば他のエンジンが「Wsn.N対応」とした時に処理が食い違った場合には、仕様で決めている事を正しく実装していないという事になるので、バグとして修正すべき案件になると思います。それはそれで個別の問題にはなりますが、仕様上の問題にはならないかと思います。CWPy側が間違った実装をした時も同様です(今までもCWとの挙動の食い違いを大量に修正してるし)。
互換性DBってシナリオ単位で動作モードを切り替える機能だと思っていたんですが、カード単位で｢他エンジンへの移動を考慮したイベント組んでる札は発火を許可したり変換処理をスキップする｣とか、そういったことも最近はできるようになってるんでしょうか？
実はこれは最初からできます。互換性DBの情報は
*.widの単位で指定する事ができます。あるシナリオのSkill1.widは互換モードで動くけどシナリオ全体はそうでない、という事もできます。ただし互換性DBは今のところクラシックなシナリオだけを相手にしているので、WSN形式から他形式への変換の時も使うとすると、新しく何事かを追加する必要があります。
-
まとめてみます。（他の方の意見に見落としがあればすいません）
長月さん案
- Py/WSN側の仕様：使用時イベントの効果コンテントのみで死亡時イベントが発火する（NEXT仕様を標準化）
- 互換対策：「シナリオ名と作者名が一致するカードの使用時イベントであれば発火しない」というオプションをつける
- NEXT1.60(wsm7)形式対応：仕様を一致させる
- クラシック形式(wsm4)対応：自動的にオプション有効にする(13の魔女の話などを想定？)
暗黒騎士案
- Py/WSN側の仕様：使用時イベントの効果コンテントでもデフォルトでは発火しない（従来仕様のまま）
- 互換対策：効果コンテントを拡張し、発火するオプションをつける(使用時イベント以外でも)／デフォルト発火の拡張効果コンテントVer2(仮)を別に作る
- NEXT1.60(wsm7)形式対応：自動的にオプション有効にする／Ver2に置き換えする
- クラシック形式(wsm4)対応：従来通り
両者の違いは「デフォルトで死亡イベント発火する／しない」と「オプションの範囲を使用時イベントに限定すべきか」です。
前者について。 「使用時イベントで死亡イベントが発火する」ことを想定して作られている、NEXT仕様/Wsn.xシナリオで入手した札イベント攻撃カードを変換する際、 専用機能を使っていない場合に(ランダム選択コンテント利用など)1.50以下にカードを持ち込むことが出来てしまい、 七篠さんが懸念されるところの「Py以外のよそのエンジン、Wsn以外のよそのシナリオで問題起こすリスク」がある構造が残ってしまうように思えます。 NEXT仕様の方をオプションにすればオンになっているカードを弾くだけで済みます。
後者について。「シナリオ名と作者名が一致するカードの使用時イベントであれば」という条件は用途が限定的すぎ、 前述の通り、カード効果では「逃走」キーコードの有無で死亡イベント発火を操作できるので 効果コンテントで発火有無を統一しなければならない必要性は薄いと思います。 それならば逆に並列してしまった方が使い道が残ります。
-
まとめわかりやすいです。ありがとうございます。
暗黒騎士さんの案が収まりが良いように思えますね。クラシック環境で問題を起こしうるカードが持ち出される心配がないのがいい。
のですが、Next製カードのどの効果コンテントで死亡時イベントを発火させればいいのか、その判定基準がないために困難ではないかと思われます。
キャストカードが所持しているカードは死亡時イベントを発火させない？ → 戦闘中に所有カードの入れ替えを行うと誤動作を起こす可能性。また、同行キャストの所有するカードである場合、そのカードは死亡時イベントを発火できなくなる。それが連れ込みNPCであれば、クラシック環境に持ち込める問題カードが生まれてしまう。
対象を死亡させうる効果コンテントはすべて発火させる？ → 最初に挙げられている、「一定確率で召喚獣によって自分自身を攻撃し、退場する敵」の問題が解決できない。敵キャストが使用する場合には例外処理をする？ それで解決できるかわからない。
-
どうも前提の認識に食い違いがあると思うのですが（自分が根本的に仕様を勘違いしている可能性が怖い）、 NEXT仕様wsm7シナリオの変換時にはキャスト所有だったり死亡させうる効果をもっているか等は一切関係なく、「すべてのカード」の使用時イベントの効果コンテントで発火オプションを自動で有効化する（か別コンテントとして解釈する）ということです。PCが入手できるようになっている場合は「死亡イベントが発火するカード」が入手されます。
そのカードをクラシック形式シナリオに持ち込んで「一定確率で召喚獣によって自分自身を攻撃し、退場する敵」を倒したとしても、死亡イベントが発火するので、従来通り「PCの攻撃によって倒された場合」の挙動をすると思います。召喚獣には影響を与えません。その召喚獣は従来仕様で、死亡イベントが発火しないためです。
XEditorで制作されるWsn.xシナリオについては使用時イベントで攻撃するカードを作りたい作者が任意にチェックを入れれば良いです。
-
reporter
私が解決したい問題を挙げておきます。
- 効果コンテントで敵を攻撃するカードはすでに存在しており、どれくらい存在するかの把握が難しい。
- 死亡イベントが発火しないと止まるシナリオが存在している。これも把握が難しい。
この両方が存在する事が問題で、どちらか片方だけなら問題はありませんでした。その上、どちらも相当数存在するはずで、互換性DBでの対処は難しいです。
WSN形式や、その他のこれから作られる新しい仕様の中でだけ問題を解決するのであれば、話はもっと簡単なのですが、必要なのは過去に作られた莫大な数のシナリオがある程度正しく(シナリオ作者の想定通りに)動く解決策でした。
おそらくCWNext側でも同じことを考えて無条件に死亡時イベントが発火するようにしたものと思われますが、それにも問題があるので、条件付きの方法をひねり出す必要がありました。その結果が最初に書いた案です。筋が悪い事は認めるしかありません(自分でも気持ち悪いし)。しかし従前の2つの問題を両方とも解決できるアイデアは今のところこれだけです。
互換対策：効果コンテントを拡張し、発火するオプションをつける(使用時イベント以外でも)／デフォルト発火の拡張効果コンテントVer2(仮)を別に作る
これでは1.が解決できないのです。
逆変換の事は、とりあえず問題視してはいません。というのも、問題を起こすカードを逆変換時に弾いてしまう事は簡単だからです。あるいは弾かなかったとしても、それは1.2.の問題が元々ある世界に戻っていくだけであって、新しい問題を発生させるわけではありません。
-
失念していましたが、使用時イベントに効果コンテントを持つNEXT仕様wsm7シナリオで入手したカードを「専用機能を使っている」と認識させるのでそのカードは他のNEXTの機能を使っていなくても1.50以下には変換できなくなりますね。 NEXT仕様wsm7シナリオという時点で本来1.50以下で入手できないカードなので問題はないと自分は思いますが、人によっては変換したいかもしれません。
-
これでは1.が解決できないのです。
すいません、自分はそれで1.も解決できると思うのです。できない理由を教えて頂けないでしょうか。
-
Nextの仕様について誤解していたようです。Nextではカードの使用者によらず、使用時イベント内の効果コンテントでは死亡時イベントが発火するのですね。すみません。先の「Next製カードのどの効果コンテントで死亡時イベントを発火させればいいのか」というのは、これを理解していなかったがための発言です。撤回します。
＞@k4nagatsuki さん
1.効果コンテントで敵を攻撃するカードはすでに存在しており、どれくらい存在するかの把握が難しい。
これは、1.50までのカードにそのようなカードが存在する、ということを指しているのでしょうか。
そうであるという仮定のもとに申し上げますが、それらに対応することは、クラシック環境で問題を起こしうるカードの増加を助長します。なぜなら、クラシック形式で作成したカードはPyでもNextでも使用できるからです。
Pyを普段使いし、Nextシナリオを遊ぶときにのみ宿を逆変換してNextに持ち込む、という遊び方をするユーザーは（数まではわかりませんが）増えています。それらのユーザーにとって、キャラクターに持たせるカードの需要は、1.50までのもの（最適）＞Py仕様のもの＞＞Next仕様のもの（不要）です。たとえクラシック環境で問題を起こそうと、PyとNextの両方をターゲットにしたカードが作られるでしょう。
私家版エンジンの判定は、Pyならば容易ですが、Nextは使用時イベント内で完結できる手法がないはずです。よって、使用時イベント内で私家版を判定し、効果を変更できる安全なカードは作成できません。せいぜい購入時に注意をするなり、カードの解説に短く書き添える程度でしょう。実際に使用する際には、それらの危険性は忘れ去られます。
それでも1.50までのカードで死亡時イベントを発火させるべきでしょうか？
-
reporter
うわ、すいません。通知が来なくて今日まで話の進みを見逃してました。
そうであるという仮定のもとに申し上げますが、それらに対応することは、クラシック環境で問題を起こしうるカードの増加を助長します。なぜなら、クラシック形式で作成したカードはPyでもNextでも使用できるからです。
確かにそうですね。そういうカードが既存しているという現実は、そのカードにはバグがある、と言ってしまって無理な手段で解決しない方がいいのかもしれません。実際には効果コンテント以外にも問題のある挙動はいくらでも作る事ができます。
考えを改めます。私の提示した方法は強引すぎましたし、不必要と言っていいです。
それを前提にすると、クラシック形式は無視できるので、解決へのアプローチは次の2つに絞れそうです。
- 効果コンテント側で解決する。すなわち効果コンテントのオプションで死亡イベントが発火するようにする
- 死亡発火条件側で解決する。すなわち効果で発火する新しい死亡条件と旧バージョン死亡条件の2種類の発火条件を作る
@akkwさんの提案通り、効果コンテントの方がスマートな気がします。
-
reporter
落ち着いて考えると死亡発火条件側での解決は過去のシナリオの問題をまるで解決できませんね。すいません、慌てすぎました。撤回します。
これで打つべき手は@akkwさんの案に絞られたでしょうか。
-
通知がいっていないのかな？とは思っていたのですが、直前の文脈から急ぐこともないだろう的な無言なのか微妙な感じでした。 とはいえ、自分もクールダウンできたのでよかったです。
1が解決できるだろうという点について一応補足しておきますと、1,50以下で使用時イベント攻撃カードが増えた背景は1.30から追加されたランダム選択コンテントが原因なので、問題となるのはここ数年の期間に作られた実験的な（Lyna氏が想定していたFFの「みだれうち」を再現するような）技能やアイテムカードです。（1.28以前は七篠さんが仰られたように使用時イベント攻撃は禁じ手と周知されていたはずです。） なので、それを解決したいのだと解釈しました。が、自分の見立てではそれは恐らくプライベートシナリオを回っても10…はないのではないか、という感触でしたので、それらに無理矢理対応するとしても互換DBで対処可能と判断しました。 いやいやもっと多いだろうという方がいれば話は変わってくるかもしれません。
-
reporter
オプション案を堅牢な仕様として採用した上で、個別の問題に対して私の無理やり案を互換性DB利用で使うというのはありかもしれませんね。
ただ、それを始めるとその他の諸々のシナリオバグが次の課題として浮上してきてしまいます。これはちょっとプラットフォーム側としては深入りを避けたいですね……。
-
仕様に対する無理解から生まれたバグ（というと乱暴ですが）に、エンジンでフォローをして回るのはやめたほうが良いと思います。
互換性DBは、かつて正しい仕様に則っていたものを救済する目的で用いるべきだと。それらはエンジンの勝手によって歪められてしまった被害者ともいえるものですから。
-
reporter
そうですね、私も最初と言っている事が違いますが、その部分の蓋は開けるべきではないです。互換性DBの本来の目的はまさに仰られている通りのものですし。
では、だいたい結論が出たと思うので、時間ができた時にでも試験実装をしたいと思います。
なんか他に色々やる事が発生してWsn.2の作業に全然手がつかない……。
-
reporter
そろそろ効果コンテントの死亡発火有無を実装するか、と思って再検討したのですが、問題が1点見つかりました。
CWNextの効果コンテントは常に死亡イベントを発火させるわけではなく、「使用時イベント中に使用されたときだけ発火する」という挙動をします。これは現行案の「発火する・しない」のオプションでは再現できない挙動です。変換時にカードの使用時イベント内だけデフォルト値を変えればいいかな、と思ったのですが、パッケージ呼び出しが可能なのでやはり再現できないようです。
これに対応するには「常に発火する」「使用時イベント中は発火する」「発火しない」の3点を選択可能にする必要があるのではないかと思います。
それで特に問題なさそうなら、試験実装してみます。
-
reporter
pull request #1625
対応するエディタはcwxeditorの20161103版以降です。
以下は実装にあたってのメモ。
- CWNextでは、使用時イベント内部で発火した死亡イベントは、使用時イベントの一部ではないと看做されるようです。つまり、死亡イベント内で対象を再度死亡させても重ねて死亡イベントが発生する事はありません。
Effectコンテントに追加した属性はdeadevent="DoNotRun|Run|InCardUsed"です。DoNotRunは発火しない・Runは発火する・InCardUsedは使用時イベントのみ発火する、です。
-
reporter
issue
#428の行方次第でdeadeventの名前は変わるかもしれません(ignite辺りがいいだろうか)。その場合、このオプションを使用したシナリオは修正が必要になると思われるのでご注意ください。
-
であれば
igniteはbool値にしてNEXT仕様への対処はエディタでのチェック項目にせず 前述した＠NEXT仕様というような特殊キーコード(使用時イベントのみ死亡イベントを起こす)を追加するようにした方が インターフェース上の負債にならないのではないでしょうか？ 文字列処理だと重くなるかもですが… -
reporter
たしかに「使用時イベントのみ」は気持ち悪い感じがあるので分けた方がいいかもしれないですねぇ。そもそもWsn.2ではそれを実装せずに、あとで必要になったらフラグをもう1個追加すればいいのかもしれません。
特殊キーコードはあまり綺麗ではない気がします。処理速度はほとんど変わらないと思いますが、単純に属性を1つ増やすだけでいいのではないでしょうか。
-
完全に好みなので聞き流して頂いて構いませんが、バックパック対応スキルオプションなどもそうですが、 互換を保つためだけで使う価値、頻度の少ない選択/チェック項目がエディタインターフェースに増えるのは嫌なので 簡素さを保つために基本的にクーポン/ゴシップ/キーコード/特殊文字で済ませられるものは済ませた方が嬉しいという感じですね。
-
reporter
内部的にはフラグとして扱い、エディタ上ではキーコードに見えるという方法もありますよ。
もっとも、「使用時イベント中のみ」を見送るとしたら、それを決めるのは将来の話になるでしょう。
-
reporter
pull request #1626で
ignite="True/False"に変更しました。さしあたりは発火する・しないだけになります。「使用時イベント中のみ」は、必要になった時にまた方式を考えて実装する事になると思います。
-
reporter
- changed status to resolved
効果コンテントでイベントが発火できるようになった事で解決しているので、完了にします。
- Log in to comment
効果コンテントの拡張オプションとして効果コンテント自体にキーコードをつけられるようにするのはどうでしょう。
一つでもつけた場合、カードのキーコードより先にその効果のキーコード発火を見る→効果処理→死亡時イベント→キーコード成否（○×）判定→その後使用時イベントに戻ってくる感じで。つけなかった場合は1.50まで通りにシステム効果として発火なしで。 NEXT仕様シナリオの変換時には、効果コンテントに＠NEXT仕様というようなキーコードを自動でつければ大体カバーできるのではないかと。
NEXT仕様ではキーコード発火を見ないのでボス演出でよく見る「攻撃・麻痺・即死系キーコードを全て弾く」というような処理を貫通してしまって、結局のところ攻撃スキルへの利用が非推奨となっているように見えます。（仕様を勘違いしてたらすいません）