提案:キーコードを実質的にパッケージのように管理する

Issue #220 closed
ルンバ created an issue

課題 #79「追加案:イベント発火用キーコードの類似表記一括指定」と似ているのですが似て非なる内容なので別に立てます。

表面的インターフェースは何も変えず1.50までの保存形式のままでバトルやシーンでのイベント発火キーコードを実質的にパッケージのように管理する改良の提案です。 シナリオデータの保存と読み込みの際に処理を追加する必要があります。

  • かき氷マンA
  • ┣炎による攻撃
  • ┣火炎
  • ┗聖なる炎

↑複製したい一群例 これをパッケージ的に扱うためシステムクーポンのように@をつけた特殊キーコード「@パッケージ大元」と「@パッケージ」を定義します。

  • かき氷マンA
  • ┣炎@パッケージ大元
  • ┣炎による攻撃
  • ┣火炎
  • ┗聖なる炎

↑まず一つだけ大元のキーコード群を用意します。これは、シナリオデータ保存処理においても従来どおりこのまま保存します。 そしてこれと同じ炎グループキーコード群を設定したい別カードには

  • かき氷マンB
  • ┗炎@パッケージ

↑このようにパッケージ的感覚で複製を割り当てます。 こちらはシナリオデータ保存処理においては「炎@パッケージ大元」のキーコード群を引用コピーし実際には以下のように

  • かき氷マンB
  • ┣炎@パッケージ
  • ┣炎による攻撃
  • ┣火炎
  • ┗聖なる炎

として保存します。開き直す際にはXEditor上では再び『炎@パッケージ』のみに省略して表示します。 同シナリオ内に「XX@パッケージ大元」が同名で複数ある場合は警告を出す&優先順位を定義しておくなどの必要はあります。また先日増設していただいたフラグ参照先の表示同様に大元のパスを表示できるとよいと思います。

さて仮に他のエディターでこのデータを開き修正が入った場合ですが、

  • かき氷マンB
  • ┣炎@パッケージ
  • ┣炎による攻撃
  • ┣火炎
  • ロケットランチャー

聖なる炎削除) のような修正が「かき氷マンB」だけ行われ保存され直したデータを再びXEditorで開いた場合「炎@パッケージ大元」との差分で

  • かき氷マンB
  • ┣炎@パッケージ
  • ロケットランチャー
  • 炎@以下除外
  • 聖なる炎

として「@以下除外」キーコードを付記し記述し直します。 この「@以下除外」キーコードは他のエディターとの互換性のみでなく、単にパッケージに対する例外処理にも用います。

  • 神聖なホーリー氷マン
  • ┣炎@パッケージ
  • ┣不浄な攻撃
  • ┣炎@以下除外
  • ┗聖なる炎

↑のような感じです。これはセーブする際にも「炎@パッケージ大元」との差分で以下のように保存する事になります。

  • 神聖なホーリー氷マン
  • ┣炎@パッケージ
  • ┣炎による攻撃
  • ┣火炎
  • ┗不浄な攻撃

「@パッケージ大元」と「@パッケージ」「@以下除外」というのは(@以外に適切な記号の選択なども含め)説明上の仮称です。 実際にはパッケージと混同しないため別称が望ましく、より短い単語が望ましいでしょうが他のエディターで開かれた場合に尊重されやすい意味わかり易さの方が優先かもしれません(「@以下除外」は差分に応じてXEditor上だけに出現するキーコードなのでその配慮は不要)。単に「パッケージ」を「グループ」と置き変えるだけでいいのかも? カードワースエンジン上では単にこれらの特殊キーコード自体は発火しないで無視されるだけなのでゲームプレイ上は問題はないでしょう。 仮に店シナリオ作者等がスキルに埋め込みしてもその意図にそった発火になるでしょうから問題はないかと。非推奨がいいと思いますが。

この記述式を元に、シナリオデータ保存と読み込みの際にキーコードの置き換えや差分参照処理を行うシステムを設けていただけますと イベントツリーでの「大量コピペよりパッケージ化可能ならパッケージ可」するのと同様にキーコードの使い心地がとても向上するのではないかと思います。 個人的に今欲しい内容なので思いついたのですが、多様なキーコードを柔軟に扱える事はカードワースの将来性に貢献するかと思います。

素人考えですが保存データ上のサイズは「@キーコード」のせいで若干増えますが、XEditor作業時においてはキーコード数も減り使用メモリも軽減されるのではないかと思います。(めっちゃ微々なのでしょうが)

「@パッケージ大元」キーコードを用いずに別に、クーポンとか状態変数とかの管理のビューのようにキーコードパッケージ管理ビューの増設をした方が、よりわかりやすいかもしれませんが、正直そこまでやらなくとも実用上は特に差し支えないかと思いますし、シナリオデータの互換性を保つことを優先すべきなので不要な気がします。

Comments (9)

  1. k4nagatsuki repo owner

    ご提案ありがとうございます。

    複数のキーコードを1まとめにして取り扱うために特殊な文字列を使って処理する方法は筋が悪いと思います。

    • キーコードにはクーポンと違ってシステム文字列のような概念がありません。後から制限を加える事には常に互換性のリスクを伴います。
    • 既存の仕様に深く食い込む形で後付するせいで、仕組が煩雑になります。ユーザから見ても分かりやすい仕組にするのは非常に大変です。
    • 保存時に分解したものを再構築する処理に、どうしても例外処理が必要になります(たとえばパッケージの中の一部のキーコードが欠けているような場合)。場合によってはユーザが知らないうちにデータを失うような事故に繋がります。それを防ぐにはどうしても追加のデータが必要です。

    また、機能はコストと将来的なものも含むリスクを負って実装する事になるわけですが、その上でこの機能がどの程度必要になるのかが、私としては疑問です。

    同じキーコードのセットを取り回す場面が、追加機能が必要になるほど多いとは思えません。キーコード指定の大半は局所的になるはずです。

  2. ルンバ reporter

    >同じキーコードのセットを取り回す場面が、追加機能が必要になるほど多いとは思えません。キーコード指定の大半は局所的になるはずです。

    逆にキーコード指定に手間がかかるから、同じキーコードのセットを取り回すのが局所的にならざるを得ないという面もあると思います。

    普通にキーコードをコピペすればいいという発想もあると思いますが、カードの前後の重なりを考慮して配置をする都合もあるので、同じモンスターカードが単純に連番で並んでいるかというとそうも限らず変則的にもなりえます。そのたびに多数のモンスターに、必ずしも単純作業にもならないコピペを繰り返すのは楽ではありません。なので管理が一括化されていればとても助かるのです。

    またバトルギミックに限らず様々なキーコードへの対応のきめ細かいシナリオはその点自体が好まれる物でしょうからシーンビューでも同様な事情はあるはずなので潜在的な需要はあると思います。

    このやり方は筋が良くないとしても、同じキーコードのセットを取り回す場面の必要性は排除して考えるべきではないと思います。

    提案はやり方としては綺麗でないかもしれませんがシナリオを作る上で多くの人にプレイ可能なWSM形式のまま新機能が追加できる事に意味があるいう発想です。

  3. k4nagatsuki repo owner

    その目的であれば、それはシナリオのデータではなく、エディタの入力支援機能として実装された方がよいです。

    その方が無理がありませんし、他のシナリオでも使いまわせるようになります。

    そちらの方向であれば、いずれ実装したいと思います。

  4. ルンバ reporter

    これはやはりシナリオ制作者の中でもニッチな要望ではありましたので、課題優先度を下げます。ニッチゆえにWSMとの互換性も問いませんので先々なにか入力支援機能に追加があればと期待させていただきます。ありがとうございました。

  5. ルンバ reporter

    保存形式を展開されたWSNに一旦変えて、バトルをxmlエディタの機能を用いて編集してから、最後にWSMに戻せば、特に1.50対応で無理に新機能を設ける必要は全く無いとようやっと思い至りました。長々提示しておりましたが無駄な時間をお取りしました事お詫びし終了します。

  6. Log in to comment