変更案：シナリオ開始時の背景継承
Issue #411
resolved
ツイッター上でIraka.Tさんに指摘されましたが、開始エリアが背景継承の場合、yado2でレイヤが使用されていると表示が乱れるようです。実際に自分のシナリオの初期Verでは背景継承＋全体カラーセル#000000(0レイヤ)だったので50レイヤのjpy1で10レイヤのBGMカードを被せている最新のBloodWirthから突入すると以下のような表示になっています。
で、0レイヤ以外はシナリオ突入時に初期化したほうがいいんじゃないかなと思ったのですが、Iraka.TさんはバリアントではPCより上位のレイヤを継承したいものがあるかもしれないのでリセットすべきではないというお考えでした。
しかし、自分としてはやはり上記のような問題が実際に起こっていますし、他にシンプルな解決案も思い浮かばないので初期化するかセルの表示状態をキャッシュして0背景化するなりした方がいいように思えます。
Comments (25)
-
repo owner
-
少し考え方を変えて、再背面のフルサイズレイヤーが画像でない場合に、エディタで警告を出してはどうでしょうか。
@akkw さんのシナリオは、CWXEditorで制作したもので、カラーレイヤーを用いたために意図せず背景を継承してしまっているケースだと思います。CardWirthEditorやWirthBuilderで同様の問題が発生するシナリオは作られないでしょう。（塗りつぶしを行うのに、あえて背景を継承するメリットがないため）
考えてみれば、必要のないときに背景を継承しないというのはカードワースのシナリオ制作の基本ですし、意図せず背景を継承するエリアが生まれてしまう現在の仕様は少し危ういのではないでしょうか。
-
repo owner
たしかにそうですね。フルサイズの・不透明なカラーレイヤで背景を覆う場合、背景不継承を意図するものとして、その方法は間違っていると指摘する事は必要そうです。
そのような状況で本当に背景継承を行いたいのは、カラーレイヤの背後に前背景のJPY1セルを残してアニメーションを発生させたい場合くらいですが、おそらくそのような場合は現実には無いでしょう。
-
reporter
＞長月さん
シナリオの方では背景削除が使えるため、あまり顕在化しないように思いますので、 メリットは理解できますが、セル周りはすでに複雑化しすぎているきらいもあり、これだけの件で追加するには少し微妙という感想ですね。 逆にカードの使用時イベントの演出で残ったゴミがシナリオの演出を壊さないためのセーフティとしてはありかと思います。
＞Iraka.Tさん
いえ、その部分は1.28までのBlack.bmpを拡大して黒くする手法が感覚的に好きになれないものでカラーセルが追加されてからはそうするようにしているもので、XEditorに由来しているわけではありません（ビルダーでも背景には指定できないため）。 また「未指定」としての背景継承を好む方はわりといるように思いますので基本と取られるのは早計ではないかと。 自分のシナリオ以外でもそうなっているシナリオは複数確認しています（アルキンの王国など。おそらくWB製）。
-
いえ、必要以上に背景を継承しないことは基本だと思います。背景を継承するかぎり、隠された部分であってもセル情報が蓄積され、メモリなどハードウェアのリソースを圧迫するはずです。背景を不継承とすることでようやく、背景セルの情報がクリアされ、リソースが解放されるようになっていたはず。
現代のPC環境でカードワース程度でリソース不足を起こすことはまれでしょうけれど、それでも浪費することが良いことだとは言えません。Black.bmpなどを用いる手段は私もスマートではないと思いますが、継承の上カラーレイヤーで覆うことは、仕様に照らし合わせて問題のある手法だと思います。
-
例外を設定する場合を考えてみましたが、やはり設定するべきではないと思います。
使用時イベントなんかで一時セルを配置されたような時
など、スキンのカスタマイズ以外にも、シナリオ作者の意図しないタイミングで前面レイヤーが出現するケースはあります。
クラシック形式のシナリオで、エリア移動時にこれらのセルを取り除いたりレイヤー順位を下げるという例外処理をした場合、使用時イベントで背景セルを描画するカードは、シナリオによって挙動が変化するカードになってしまいます。これは、カード作者の意図を破壊します。
すべての形式のシナリオで同様に前面レイヤーを処理するとなると、大きな仕様変更ですから、1.28とそれ以前のような混乱をもたらすでしょう。互換性DBの仕事が急激に増えます。
-
reporter
うーん、まあカードを消してしまうのはカードワースではない云々もそうですが、 浪費はよくないというのはIraka.Tさんの美意識であって、（それはご自身の作品に反映される上では有益だと思いはします）、12.4での七篠さんのような「それが実装されるならもはやPyに着いていけない」というレベルの方向性に関わる議論ならある程度理解できるのですが、シナリオやスキンという千差万別の思想が籠もる媒体にそれを持ち出されると少し困惑します。
とりあえず自分はXEditorで意図せずしてそういう作り方をしたのではなく、 どうせ数シーンだからとあえてやっていることなので、XEditorでエラー扱いされるほどの間違いという認識であれば残念ですね。
-
repo owner
や、意図的に行うケースもあると思いますが、継承されている事に気づかずどんどん背景を重ねてしまうケースもありますし、作者のテストプレイ時は問題なかったのに、あるプレイヤーが遊んでいる時にメモリ不足で落ちるという事は充分ありえます(というか私が過去にやりそうになりました)。これはどちらかというと思想的ではなく物理的な問題です。それを理解した上で、背景変更はn回までしか発生しないから問題ないと考えるのは思想的な問題ですが、おそらくほとんどのケースはそうではありません。
ですから背景継承が発生しているという事は一目瞭然に分かるべきです。エラー扱いではなく、継承の有無をどこかに表示するのはどうでしょうか。
-
カードを消してしまうのはカードワースではない云々
こちらの思想でエンジンに対して求める何かがあるわけではありませんので、これについてこの場で主張するつもりはありません。加えて、そのようなスキンが作られ、使われることを危険視しているわけではなく、やりたい人はやればいいと思っています。
ただし、それによってシナリオのプレイに支障がきたされることは、スキン作者とシナリオ作者の責任であり、エンジン開発者の責任ではないはずです。継承されたときに問題を起こしうるデザインを行うことは、スキン作者が責任を負うべき部分ではないでしょうか。
エンジン開発者は常にユーザーをフォローし続けられるわけではありませんし、
#405でも申し上げましたが、仕様に対する無理解から生まれた問題に、仕様変更でフォローをして回るのはよくないはずです。仕様を理解し則していた人を不遇することにもなります。無論、仕様そのものに問題がある場合は開発者が改めるべきなのでしょう。ただ、今回の事象は後方互換を考えると問題がありますが、将来に対しては可能性をもたらしており、仕様を変更することが唯一の善ではありません。シナリオに応じて問題の起きないスキンに切り替えて遊ぶこともできます。ですから私は（プレイに障る可能性のあるスキンをデザインした者として）今回の事象はスキン作者が責任を負うべき部分だと感じました。
この主張もまた個人の美意識によった思想で、論じるに値しないことなのかもしれませんが。
-
reporter
＞長月さん
CWは短編と店が大半ですので、「ほとんどのケース」では仮にすべて継承し続けたとしても落ちない範囲で収まると思いますが、 明瞭化をされることに対しては異存はありません。
＞Iraka.Tさん
シナリオやスキンの制作者が責任を負うと言っても、「使わない」という消極的対応しか取りようがありません。
#405では「1.50環境で不具合のあるキーコード貫通カードに対応しよう」という話でしたので反対しましたが、 背景継承からの全画面セルはレイヤ概念のない1.28/1.50環境において、XEditorとは無関係に正常な動作ですし、 「それを考慮するとyado2でレイヤを全く使えない」というのは、 BloodWirthで件の表現ができない以外でもデータバージョン4対応スキン制作者すべてにとってのデメリットです。当初は完全に埋もれていた「種族」もそうですが、情報整備が進んだら、必然的にみんな使いたくなります。 レイヤを活用するPy専用の新規バリアントで前面レイヤの継承ができなくなるデメリットと比べてみても、 前者のデメリットの方が圧倒的に高いはずですし、 DV4・中世Ⅰ型から完全に独立する仮定である後者について、後から例外を設けるのは簡単です（スキン側のオプションにするなど）。
そもそも完全にPy専用・独立型のバリアントが成り立つためには、CW界で弱小である現在のPyがCW全体の規模以上に普及せねばなりません。 今後10数年単位で現実味のない可能性を憂慮していても仕方ないと思います。（自分の望みはまずはPyが他のエンジンと同程度以上に普及することです）
-
なぜ、本来の仕様に則しているものが例外扱いを受けなければならないのでしょうか？
無闇に背景を継承しているシナリオは、前述しましたが仕様に照らし合わせて問題のあるものです。それを優遇しなければならない理由がわかりません。
「使わない」という消極的対応しか取りようがありません。
いいえ。プレイに支障をきたすシナリオが存在することを受け入れた上で使うという対応もとれます。このようなシナリオは全体に対して少数です。私はこの選択をしております。
そもそも完全にPy専用・独立型のバリアントが成り立つためには、CW界で弱小である現在のPyがCW全体の規模以上に普及せねばなりません。
本当にそうでしょうか。未だ何ら形にはしておりませんが、私はそれを構想しています。Pyユーザーの増加とバリアントの成立に強い関係はないと思います。
加えて、私はPyを弱小であるとは思いません。
この問題を解決するための他の手段を考えていました。
背景よりも奥に表示される、マイナスナンバーのレイヤーというのは実装できないでしょうか。
-
reporter
なぜ、本来の仕様に則しているものが例外扱いを受けなければならないのでしょうか？
スキン機能やレイヤ機能はカードワース本来の仕様では無いからです。 本当に「仕様に照らして問題」でしょうか、「無闇に」は問題ですが、常識的な範囲、 開始直後に使用する程度のことは全く問題ないことでしょう。
Iraka.Tさんの意識は、それ自体は正しいですが、単独で根拠とするのには少し弱いように思えます。 なんだろうな…16色に減色するのが当たり前だった時代の意識でフルカラーBMPをカードに使うべきではないと言われている印象です。 今でも減量は出来る範囲でやるのが望ましいとは思いますが、現状に見合っているとは思えません。
プレイに支障をきたすシナリオが存在することを受け入れた上で使うという対応もとれます。
それはプレイヤー側の対応であって制作者側は対応できていません。少数だからと無視しているだけです。 BloodWirthの実装は右上の比較的目立たないところだからまだいいですが、目立つデザインで使えばそうは言っていられなくなります。
私はそれを構想しています。
BloodWirthとは別に、ということでしょうか？
余計な感想でしかないですけれども、一人でバリアントをいくつも抱えるのはどんなに速筆な方でも一つ一つのコンテンツがスカスカにならざるを得ませんし、BloodWirthのシナリオを増やしていく方がいいかと思えますね…
マイナスナンバーのレイヤー
スキン側で対処するのであれば、確かにそれでもいいですね。それか
debugOnly="Trueのような感じでシナリオに入ったら強制的に非表示になるようなシステムフラグとか。 -
わかりました。Iraka.Tは今後BloodWirthに関わらない言論を慎み、その他の創作活動は当名義では行いません。
-
reporter
えっ！？いえ、何気ない感想だったので、お気を悪くしたら申し訳ありません。
この上、真面目に言うのもおかしいかもしれませんが、その必要はないと思います。 名義を変えるだけで実態が違うのであれば意味はないですし、発覚した時は逆に悪印象をもたらします。
-
repo owner
ちょっと時間を置きましょう。
いくつも仕事を進行すると密度が薄まるのでは、という懸念に対し、名義を替える、というのはちょっと論理的に変です。売り言葉に買い言葉状態になっていないでしょうか。横から口を挟むようですが、落ち着くのが肝要だと思います。
マイナス値のレイヤというのは、考えないでもなかったのですが、実装上はちょっと(ことによるとかなり)面倒です。
私は背景の仕様を変えずに問題を解決する方法を他に考えていました。現在、宿には「パーティがいる時」「いない時」の2つのエリアがありますが、スキンによっては「シナリオを開始する時」のエリアを設けてもいいかもしれません。つまり、「パーティがいる時」のエリアからシナリオの開始エリアへ直行するのではなく、ワンクッション挟むわけです。
そうする事で、背景を整理したり(宿の親父と娘の他に謎の人物が映っているような背景をシナリオが想定しているデフォルト背景に戻したりできる)、変更していたBGMを
DefInn.midに戻したり、システム的に使っていたゴシップやらを整理したり、その他色々な事ができます。そのエリアが存在しないスキンであれば、これまで通り直行すればいいだけです。 -
えっとなんかよくわかんないんですが名前出ていたんでレス起こしてみます。
評価メンバの件はいまだに納得してませんが、いくら云っても伝わらないなら、
｢ハイハイ賛成賛成オセツゴモットモ｣ということで手を引くのは
十分に妥当な選択肢だと確信しています、七篠権兵衛です。
よくわかってないのですが、かいつまんで云えば、スキンの設計しだいでは
エリアに背景継承を設定していたシナリオで問題が出る可能性があるので
そうしたシナリオで問題を回避するよう、シナリオ開始の際に
背景のリセット処理を追加するべきだ
.......といった内容でよいのでしょうか。個人的には｢そもそも背景継承をむやみに使うのよくないよ｣というのは
美意識とか個人的ポリシーの問題ではなく、
実際よくないのではないかと思うところです。
といいますのも、背景継承つかって上書きを重ねる形で
ダンジョンの描画を行っていたシナリオで、
｢セーブ後の復帰に時間がかかる｣という問題が持ち上がったことがありまして。
おそらく10年位前の話になるのですが、たしか当時の自分は
CWHSのチャットで背景継承の上書きとフラグによる書き換えの
検証シナリオを起こした記憶があります。検証用のシナリオなので、
派手に(3桁くらい)上書きを重ねたというのもありますが、
マシンの性能しだいでは、確かロード時間に
数分くらいの差がついたかと記憶しています。
(いまPyの1.1で試したところ5秒差でした)無論コレが10年前の話ならば、昨今のGHzアタリマエなコンピュータ環境では
いくら背景継承を繰り返したところで問題はないのかもしれないんですが、
それもあくまで｢自分たちが普段使っているコンピュータ環境｣での話であり
他の環境でもまったく同じく成立するかどうかについて、個人的には
移植された場合などに支障をきたしかねないことを懸念するところです。
(問題なく動いたとしても｢バッテリの減りがはやい｣とか｢プチフリーズ｣とか
目立たぬところで問題を抱えていそうな気がするしだい。)
あと、｢1.20エンジンの敗残兵｣にとってはほとんど対岸の火事ですが
いまどきの手札カードは札の組み込みイベント使って
背景へお絵かきするものもあると聞きます。
たぶんその手の｢札イベントお絵かき｣は
おおかた背景継承+カラーセルあたりで
ドット絵めいたお絵かきをやってるのだろうと思うのですが、
札イベントで背景継承が乱用される中で
シナリオがなお背景継承を重ねるのもあまりほめられた話ではない、
という感はあります。
＃そういう｢お絵かき｣やるような｢演出の派手な札｣を
＃ユーザーさんが何度も使いたがるはずはないから
＃背景継承に対する懸念は杞憂だ、ということももちろん可能ですが。 -
ぁ、背景継承にばかり話を持っていっちゃったんで、本題についても一言(汗
k4nagatsuki さんの示した
｢シナリオ開始直前に特別なエリアに遷移して
そこでリセット処理を(スキンのほうで)やってもらう｣というのは
割と有効な処方箋じゃないかなと思います。
背景のみならずBGMなども整理できるという面では、
単純にエンジンで背景リセットの処理をするよりは、
つぶしの利くやり方だと思いました、ハイ。
もちろんエンジンが改訂されたときに
｢古いエンジンに依存してリセットをしてるスキンで問題が出る
→やっぱりエンジンにリセット処理がほしい｣、
みたいな話も考えられるので、
ことはそれほど単純じゃない、のかもしれませんが...... -
reporter
七篠さんの挙げられたような（ダンジョンやカジノシナリオなどで）「異常な回数の背景継承を繰り返す」というケースは 自分も「無闇には問題」と言っています。 つまり、この場では誰もそれを議論していません。 問題は「開始エリアで背景継承している（その後数回繰り返す程度の）シナリオがその無闇に当たるのか」です。
上にも挙げていますが、古いところでは1.20時代に作成された竜を滅せし者（DX版ではない方）でも確認しています。 つまり少数ではあるが、クラシック形式の作成時、エディタによらず実際に作られ得るパターンだということです。 このような短いシーン・エリアの作り方に対して、テストプレイなどで「でもその作り方は文法に反しているからすべきではないよ」と指摘が入るでしょうか。減色や未使用ファイルの削除に口うるさい世代でさえ、その程度のことはシナリオ作者に委ねていたように思います。
なので、それらが「無闇に背景継承を使っている基本に反する異常なシナリオ」と見なされないのであれば、 少なくともレイヤを想定していない1.50までのクラシック形式に上位レイヤを継承して持ち込むべきではありません。 1.50までは正常に表示されているものをスキン制作者側の都合で乱せるようにするということですから。
継承しない方をオプションにすると、「大多数では上手くいくから」と無視するスキンが出てくる構造的リスクが残ります。 それは「場合によっては進行不能になる」という被害の差はあれど、使用時イベント攻撃カードが現環境で作られるのと同じ方向性ではないでしょうか。
-
repo owner
評価メンバについてはもう1.50にあるのでどうしようもありませんが、評価条件についてはお互いが納得するまで話ができなかった事を私は残念に思っていますので、個人的には議論を蒸し返すのに賛成です。
七篠さんの主張を意図通りに理解する努力はするつもりですし(「伝わらない」というのは意図通りに伝わっていないという意味ですよね？)、実装してしまったものはものとして今後何もできないわけでもありません。issue
#294にコメントしていただければ対応します。充分時間が経ったので、議論の内容を読み返せば相手の主張を改めて理解できるというような事もあるかもしれません。
背景継承について技術面からちょこっと話をさせていただきますと……
背景継承のデータ構造は、元々CWの仕様の中でも筋の悪い部分だったのですが、1.28・1.50と状況が悪化の一途をたどってきました。他の背景がかぶさるセルでもJPY1のアニメーションを考えると削除できない、32bitイメージで透明部分が発生しうるからできない、というような事でどんどん問題が複雑化しているからです。イメージデータそのものが24bitでも、グラフィックボードの都合によって32bitとして読み込まれてしまったりして、アプリケーション側で正確な判断を下す事は実に難しいです(そのせいで散々な目に遭った事があります)。
ですから、技術面からいうと、エンジン側で自動的に判断して問題を解決しようとするのは無理筋です。背景継承の有無をシナリオ作者側から明示できるようにするというような方向ならいいかもしれませんが、クラシックなシナリオに対しては適用できません。つまりクラシックなシナリオに対して背景継承問題の解決手段を提供する事はたぶんできません。遺憾ながら、それはシナリオ側の問題です、悪しからず、という姿勢しか取れそうもありません。
それを理解した上で取れる限定的な解決方法は、エディタで背景継承の有無を明示したりする事によって、シナリオ作者の判断を助けるという事になるかと思います。そうすれば、作者が問題を理解した上で「背景変更回数がこのように限定されているから問題ない」と判断する事が可能になりますし、実際にそれで問題無い事も多いかと思います。
-
repo owner
pull request #1616
リソースにシナリオ開始前のエリアを追加しました。スキンに存在しない場合は
SkinBaseから読まれるのでスキンのアップデートは不要、かつ昨日までのCWPyではスキンに当該エリアが存在していても単に無視されるだけで影響無し、という構造にしてあります。内部的には、シナリオ選択ダイアログで選ばれたシナリオが記憶されており、到着イベントの
PostEventコンテントのStartScenarioコマンドでそのシナリオを開始、というようになっています。デフォルトのシナリオ開始前エリアは、背景継承、メニューカード無し、BGMは変更無しなので透過的に動作します。BgImagesを書けば背景の掃除が可能ですし、PlayBgmコンテントでBGMをデフォルトのものにする事も可能です。メニューカードを配置してシナリオ選択をキャンセルするような事も可能だと思いますが、試していません。テストしておかしかったら都度修正していく事にします。 -
04_StartScenario.xmlに手を加えていて気づいたのですが、どうもイベントが正常に動かないようです。エリア背景でリセットするのでなく、
<Lose type="BgImage">で前面セルを取り除こうとしたところ、シナリオ内の最初のメッセージの後で、シナリオが読み込めない旨のダイアログが表示され、宿に戻されました。<Post type="Event" command="StartScenario">を除いてもシナリオが自動的に始まります。また、<Talk>を挿入してみると、明らかに問題のある挙動をします。シナリオ開始前エリアの到着イベントが、シナリオの開始と並行して実行されている様子？ -
repo owner
ありがとうございます。pull request #1683で修正しました。
wx側のスレッドから、エリア移動の処理とシナリオ開始の処理を個別にpygame側へ渡してしまっているのが原因でした。エリアイベントの処理に平行というか、割り込んでしまっています。
-
repo owner
すみません、勝手にシナリオが始まる、という部分を見落としていました。そういえばそもそもシナリオ開始の処理がシナリオ開始エリアへの移動と共に実行されるのが不正です。pull request #1684で修正しました。
-
対応ありがとうございます。シナリオの開始に問題は起きなくなりました。
実装直後に試していればもっと早くわかったのでしょうね。急いで対応しなくていいだろうと思っていたもので今頃でした。
-
repo owner
- changed status to resolved
シナリオ開始エリアの追加によって問題は解決していると思うので完了にします。
- Log in to comment
ご提案ありがとうございます。
背景継承の基本的な動作との差異は持たせたくないところです。宿からシナリオ内への移動は特殊なエリア移動となりますが、通常のエリア移動との差は大きくない方がいいように思えます。
これは、例外はのちにややこしい問題を生むという肌感覚からの意見です。今具体的に指摘できる問題は、@IrakaTさんの仰る事くらいしか思いつかないのですが。
この件に関しては、例外を設けずに問題を解決する事は可能だと思います。例えば「このセルは継承されない」というようなオプションを追加するというのはいかがでしょうか。今回の問題を解決できるのみならず、シナリオの方でも、背景の上にマップを表示してマップだけを描き替えていく、というような使い方ができそうです。
しかしこれも使用時イベントなんかで一時セルを配置されたような時にまた別の問題を生みそうですね。他の手も含めてじっくり考える必要がありそうです。