タスク: スキンが固有のエリアを持てるようにする

[k4nagatsuki]

issue #826で、スキンが固有のエリアを持てるようにする事に需要がある事が分かったので、その仕様を考えます。

少し考えた感じでは、問題はエリアIDくらいではないかと思います。宿のエリアはプラスのIDを持っていますが、事実上ID固定のシステムエリアです。今後システムエリアの追加が必要になった時の事を考えると、スキン固有のエリアには制限を設けるべきです。さもなければ、システムエリア追加のたびにすべてのスキンを調査してIDが被らないか確認するという非現実的な作業が発生してしまいます。

とりあえず、ID:10001～20000をスキン固有のエリアIDとして開放する、というような方法を考えています。

[k4nagatsuki]

pull request #2572

試験的に実装してみました。スキン固有エリアで右クリックした時の挙動は、どうすればよいか判断できなかったので、とりあえず何もしないようにしてあります。エリアごとに指定できるようにした方がよいのかもしれません。

[k4nagatsuki]

pull request #2573

右クリック時の挙動を指定できるようにしました。Property/BackgroundActionで指定します。

<Area>
  <Property>
    <Id>10001</Id>
    <Name>スキン固有エリア</Name>
    <BackgroundAction>ReturnSystemArea</BackgroundAction>
  </Property>
    :
</Area>

ReturnSystemAreaで通常の宿エリアへ戻り、ReturnTitleでタイトル画面へ遷移、Closeでエンジン終了です。

[k4nagatsuki]

性急に作ってしまったので仕様に不備があるかもしれません。

問題を見つけた方はご指摘ください。

[k4nagatsuki]

pull request #2582

BackgroundActionで指定可能な挙動にエリア移動ChangeAreaを追加しまし、ReturnSystemAreaと共に背景切替方式も指定できるようにしました。

<BackgroundAction id="10002" transition="PixelDissolve" transitionspeed="5">ChangeArea</BackgroundAction>

[暗黒 騎士]

次期JUDGMENTで色々試してみているのですが、独自エリアに居る際のスキン変更は禁止するようにできないでしょうか？

現状はエリアID：10001から他のスキンの10001に移動が可能かつ、到着イベントが発生しているようです。また、エリアが存在しないスキンの場合はリソースだけ更新され、同名のファイルでない限りメニューカードが空欄になってしまいます。

たとえば口調ユーティリティみたいな複雑なことをしている最中に到着イベントを再発生させたり、別のスキンで初期化処理を通さずに通常宿エリアに戻られると困ったことになるのでYado2に戻すみたいな挙動になるよりは禁止がいいように思います。

[k4nagatsuki]

プレイヤーの意思による自由なスキンの切り替えを抑止する事は、できるだけ避けたいです。操作の自由度が落ちるという事もありますが、スキンはシナリオと違ってF9が効かない事の方が問題です。場合によってはファイルの直接操作などの特殊な手順を踏まなければエリアを抜け出せないような状態が発生するかもしれません。

少なくとも当面の間は、スキンの切り替えを抑止しない事で、スキンの作者の方が注意深くエリアを実装せざるを得ない状況にしておいた方がよいのではないかと考えます。処理経過が残ってしまう問題は、固有エリアに入る時に状態変数等を一括でリセットするような処理を用意する事で、比較的簡単に対処する事ができるはずです。

とりあえず、スキンの切り替えの際に固有エリアから離脱する処理は今から作ります。

[k4nagatsuki]

pull request #2592

スキン変更時に固有エリアから離脱するようにしました。

[暗黒 騎士]

固有エリアに入る時に状態変数等を一括でリセットするような処理を用意する事で、比較的簡単に対処する事ができる

状態変数はそれでいいのですが、一時的な管理クーポンの類をイベントを跨いで配布できないんですよね。たとえば、現状では宿内では番号クーポンが使えないため、スキン側で選択メンバにするために仮に番号クーポンを振っているのですが、そのような例外的な抜け方で通常エリアに戻ってパーティから外すことを許容すると潜在的にゴミを残すパターンが生まれてしまいます。(別スキンになった時点でお手上げかつクーポン名が被っていた場合そのスキンの処理に干渉しかねない)

もしくはスキン変更によるYADO2帰還時に未指定のエリア移動のようにシナリオ終了処理が走れば時限クーポンに限っては自動で削除されるので安全に使えるのですが。

---

BackgroundActionについてですが、実際の運用でReturnTitle、Closeを使うケースはほとんどなく、ChangeAreaからの到着イベントでイベント処理する需要が圧倒的に見えます。しかも上記実装で行える表現はパッケージ内のエリア移動 or postコンテントですべて代替できるので、(他の方も言ってましたが、エリア移動を噛ませてしまうと同じエリアに戻す時にメニューカードの回転アニメを防げないので)指定したパッケージを実行するオプションも(もしくはそれだけが)あった方がいいのではないでしょうか。

[k4nagatsuki]

クーポン・ゴシップ名の重複は古くからあるCWの仕様の問題ですが、重複しない名前を選択するというアドホックな解決方法が取られてきました。ゴミが残るのが気になるのであれば、パッケージを利用してイベント都度クーポンを付与・剥奪する必要があります。

スキンの変更を禁止するほど強い方法を取るのは、もっと解決困難または解決不能な問題があった時ですが、そういう方法を取らざるを得ないようなイベントをスキンで作り込む事はあまり推奨できません。

---

指定したパッケージを実行するオプション

イベント実行の新しい経路を作る事になってしまうので難しそうですが、検討してみます。

[暗黒 騎士]

どうもこちらの指摘とはややズレた設計思想を語られているような印象なのですが、
「スキン禁止にはしたくないし、スキン変更による独自エリアの離脱時にシナリオ終了処理のような共通したリセット処理を入れることもできない」ということであれば、不格好にはなりますがシナリオ作者が「このシナリオでは背景切り替え方式：アニメーション無し・最速にして下さい」と書くように、スキン作者も「このタイミングではスキンを変更しないで下さい」と書けばいい話なので、そうした潜在的な問題を許容するのであれば特に云々して頂くことはないと思います。

[k4nagatsuki]

シナリオは、バグが発生する事を前提に、脱出手段がシステムとして用意されています。スキンにはそういうシステムがありませんから、バグが無い事を前提にするか、スキンの切り替えや削除を脱出手段にするしかありません。

バグが無い事を前提にするのは不可能なので、切り替え禁止にはできかねますし、スキン作者が切り替え禁止を要求することも推奨できません。また、スキン切替時に行われるクリンナップ処理をスキン作者が行えるようにすると、結局は同じ問題が発生しますから、その選択肢も採れません。

---

ところで、この問題について考えている間に思ったことですが、時限クーポンはスキンの切替時(とシナリオ開始時)に削除する処理を入れた方がよさそうです。

時限クーポンは、性質上、明らかに他のスキンやシナリオへ持ち込まれるべきものではありません。

このような時限クーポンの性質は、シナリオでそうだったように、一時クーポンの始末の問題を解決するのではないかと思います。

[k4nagatsuki]

pull request #2594

時限クーポンの件は実装しました。

パッケージの実行は、イベントの新しい発火条件を設けるというような、イベントの実行経路を増やさない別の方法もあるので、考え中です。

発火条件を増やすのもそれはそれで問題があるので、パッケージ実行の方がいい気もします。

[k4nagatsuki]

pull request #2595

今の所問題を思いつかないので、背景クリック時のアクションにCallPackageを追加しました。

[k4nagatsuki]

実装済みなのでクローズします。