WSN追加案: 宿に状態変数をくっつける

[req]

考えていて思ったのです。

以前、ステップ<=>クーポン＿n変換（ステップ<=>クーポン連番変換）の他に ステップ<=>ゴシップ＿n変換（ステップ<=>ゴシップ連番変換）を考えていた ことを思い出しました。

宿に状態変数の状態を保持・復帰させたいのです。

ということは、考えると 宿に状態変数をくっつける こと考えたほうがスマートなんじゃないかと思いました。よく考えると、WSNというかPyはシナリオはXMLです。拡張効きやすいんじゃないですか？ということで、課題作成しました。

[req]

これは忘れていることが多い自分よりも、使い勝手の良さは理解してもらえると思います。アイテム倉庫系などのニーズが考えられます。

ゴシップとの兼ね合いがあるので、ゴシップに＜ステップのインデックス（数値）＞を持たせる拡張の方がいいかもしれません。

ゴシップ追加・ゴシップ分岐・ゴシップ削除にステップ付ける（というかゴシップ文字列とステップを切り替える）のどうでしょう?

とにかく　宿に状態変数の状態を保持・復帰させたい　ので、アイディアよろしくお願いいたします。

[k4nagatsuki]

これはゴシップを絡めるよりずっと簡単な方法があります。フラグやステップの状態変数に、シナリオを出ても状態が保存されるというオプションをつければいいです。実装としては状態変数のパスと値を宿に保存するだけです。

懸案としては、あるシナリオで使っていた状態変数を他のシナリオで流用したいというような場合にどうするかです。

1. ゴシップのように純粋に名前(パス)だけで管理する。実装に難しい点はありませんが、シナリオ作者は意図しないと被らないような名前をひねり出す必要があります。
2. 状態変数にもカードのようにシナリオ名と作者名の情報をつける。

2.は1.をシステム的に強制するかどうかというだけの話になりそうです(「<作者名>\<シナリオ名>\<状態変数名>」というデータと「<状態変数名>+シナリオ名と作者名」というデータの違い)。たぶん1.の方が簡単で柔軟でしょう。

ただし、ここの考え方の違いは仕様衝突を招くかもしれません。

また、シナリオ側でデータを掃除したい時に、記録した値を削除する方法が必要です。

[req]

長月さんが土・日でコメントできるうちに聞いておかなくては。すぐ上のコメントに同意します。

フラグやステップの状態変数に、シナリオを出ても状態が保存されるというオプションをつければいいです。

オプションというのはステップ・フラグのダイアログに宿書き出しフラグを設けてそれにチェックが入っていたらとかですか？

あるシナリオで使っていた状態変数を他のシナリオで流用したいというような場合にどうするかです。

自分は1．を推します。ゴシップは元々シナリオ間で名前が被らないように工夫して付けていましたし、もしリレーシナリオとかで共用で使いたい場合などは、その状態変数名を決めてしまえばいいからです。

宿に状態変数保持

• シナリオ終了時、宿書き出しフラグをONにした状態変数を宿に保存する（すでにその状態変数がある場合は修正、なければ追加）

宿から状態変数復帰

• シナリオ開始時に、シナリオにある状態変数と同名の状態変数が宿にある場合、状態変数変更を行う

といった感じですかね？

[k4nagatsuki]

オプションというのはステップ・フラグのダイアログに宿書き出しフラグを設けてそれにチェックが入っていたらとかですか？

書き出し・復帰の条件はほとんどそれでいいと思うのですが、もう1つあります。おそらくですが、シナリオ終了コンテントに変数を宿へ書き出すかどうかのオプションをつけた方がいいでしょう。そうしておけば、最終的に終了印をつける時などに掃除するのも簡単です。

シナリオの終了ルートはもう2つあって、それはゲームオーバーとF9です。F9は考えるまでもないのですが、ゲームオーバーは少し厄介です。全滅によってゲームオーバーコンテントを経ずに発生する事があるので、その時に状態変数を保存するべきかどうかの判断はシナリオ作者が行えません。

全滅はプレイヤーが操作可能な箇所であれば所構わず発生する可能性があるので、各変数の状態が中途半端になって作者の手に負えない事態になるかもしれない、と考えると保存しない方がよさそうですが……。

正直ちょっと考えがまとまりません。ゆっくり考えてみます。

自分は1．を推します。

私もそっちがいいと思います。あとは他の仕様が2.を選択した時にどうカバーするかですが……何かうまい統合方法があるような気がしていたのですが思い出せません。これも改めて考えてみます(あ、疲れてるなこれ)。

[req]

自分が想定している点を挙げます。

• この機能に今ゴシップ削除に相当する機能がないのですが、これはチェックで絞っているから残しててもいいということになりますか？シナリオ作者が消したいと思ったらどうしましょう？

• 宿から状態変数復帰は、宿書き出しフラグがONのものだけを対象にしたほうがいいですか？

• 全滅は保存しないで良くないですか？　セーブしていたら状態変数の値はセーブ状態で生きているので、そこからやり直した時も状態変数によるアイテム反映などはされているわけですし。

• もし仮に別仕様が2.を選択して、その仕様のシナリオコンバートを試みるときには、<作者名>\<シナリオ名>\　宿コンバートも？　外したらどうでしょう？

[k4nagatsuki]

状態変数の保存は状態変数を個別にではなく、シナリオ1つの単位で行った方がいいと思います。シナリオ終了時に全部残すか、全部消すかです。

宿から状態変数復帰は、宿書き出しフラグがONのものだけを対象にしたほうがいいですか？

はい。状態変数の書き出しがオフになっているという事は、シナリオの開始時点で初期値が決まっている事を意味しており、書き戻すと作者の想定外の挙動が起きます。

全滅について。ロードする場合の事は考える必要はないのですが、CWはゲームオーバーを受け入れてゲームを続ける事ができます。シナリオ側では、全滅したパーティの遺産を次に来るパーティに引き継がせたいような場合があるかもしれません。

上述した作者が予測不能な全滅の場合は残さない方がいい気がしますが、ゲームオーバーコンテントにもオプションをつけて、意図的に残す方法も用意した方がいいです(特にデメリットも無いはずだし)。

もし仮に別仕様が2.を選択して、その仕様のシナリオコンバートを試みるときには、<作者名>\<シナリオ名>\　宿コンバートも？　外したらどうでしょう？

シナリオ名と作者名(場合によってはその他のID的な情報)は、状態変数のパスとは別にあるデータになるはずなので(混ぜたら仕様上の混乱が起きます)、その方法は通用しない可能性が高いです。

[req]

全部消すか

全部消すかについて危惧していることがあります。それは、例えばリレーシナリオ７本で状態変数を共用していたとします。６本目の作者が誤って状態変数を消してしまったとします。すると、プレイヤーは５本目までの状態変数の状態の蓄積をリセットされてしまいますという危惧です。

全滅について。CWはゲームオーバーを受け入れてゲームを続ける事ができます。シナリオ側では、全滅したパーティの遺産を次に来るパーティに引き継がせたいような場合があるかもしれません。

例えば、ウィザードリーも昔遊んだ記憶が確かなら、全滅したら次に来るパーティにアイテムを引き継がせるために、全滅位置まで取りに来ないといけません。自分は全滅の場合は全般的に残さない方がいい気がします。

効果で毒の沼地、バリアとかで、パーティー全体に１歩ごとにダメージ直値１０とかいう場合も全滅の可能性があります。そうなったら効果にもオプションとかいうことになって、もういっそシナリオの詳細にオプション付けちゃえよということになりませんか？

状態変数のパスとは別にあるデータになるはず

これならなおのこといいと思います。他仕様が 2．を採用していても Wsn は １．がいいと思っていればそのように挙動すればいい話なので、手間がその分なくていいです。

[k4nagatsuki]

全部消すかについて危惧していることがあります。それは、例えばリレーシナリオ７本で状態変数を共用していたとします。６本目の作者が誤って状態変数を消してしまったとします。すると、プレイヤーは５本目までの状態変数の状態の蓄積をリセットされてしまいますという危惧です。

私はそれには逆の感覚を抱いています。宿への持ち帰り機能が必要になるような状態変数は、単独で完結するようなものではないと思われます。おそらく複数の変数が絡んだ構造物のようなものになるはずです。

それらはまとめて扱うべきで、もしバラして扱い、一部が抜けたりすると、結果はよく分からない誤動作となります。そのようなバグは往々にして調査も難しいです。

そうした点と、単純な使い勝手も含めて、私はまとめて扱った方がいいと思っています。この考えが決定的なほどによいとは思いませんが。

効果で毒の沼地、バリアとかで、パーティー全体に１歩ごとにダメージ直値１０とかいう場合も全滅の可能性があります。そうなったら効果にもオプションとかいうことになって、もういっそシナリオの詳細にオプション付けちゃえよということになりませんか？

私も基本的にはそう思いますが、リスクがないならゲームオーバーコンテントくらいには付けてもいいと思います(ちゃんと注意してシナリオを作っていれば、戦闘以外での全滅は例外的な事態ですし)。

なお、全滅によるゲームオーバーの検出や抑止については、#406で計画があります。

他仕様が 2．を採用していても Wsn は １．がいいと思っていればそのように挙動すればいい話なので、手間がその分なくていいです。

これは他仕様をWSN形式に変換して遊ぶ話ですから、吸収できないとまずいです(プレイヤーの利益を考えるなら、仕様は相互乗り入れができた方がいいです)。

で、改めて考えてみたのですが、これについては別に問題はなさそうです。シナリオ名や作者名を含めないのがWSN形式の仕様であり、他の形式がそうでないなら、その形式をWSNに変換する必要が生じた時、その形式が使用しているID的な要素をWSN形式でも扱えるようにして、過去のWSNシナリオの状態変数は、そのIDを「無し」ないしWSN固有の値を持つ状態として扱えばよいだけです。

それより、パス名だけで管理する事については別の心配事が沸いてきました。状態変数にチェックを1つ入れるだけで書き出しができるのであれば、それはあまりにも簡単なので、シナリオ作成初心者などは、よく分からずに他とかぶりやすいパスで書き出しを行うかもしれず、それは他のシナリオの状態変数を上書きしたり、構造の一部を壊してしまったりするかもしれません。

全員にパスがかぶらないよう正しく扱えと言っても無理な注文だと思います。やはりフェールセーフとして、初期状態で各状態変数にシナリオ名・作者名が記録され、一致する場合だけ書き戻しが効くようにした方がいい気がします。特定のシナリオの状態変数を他のシナリオでも取り扱えるようにしたい場合は、インポートやコピーで持ってきた時にシナリオ名・作者名が維持されるようにすればよいです。

[req]

私はそれには逆の感覚を抱いています。・・・そうした点と、単純な使い勝手も含めて、私はまとめて扱った方がいいと思っています。

なるほど。

私も基本的にはそう思いますが、リスクがないならゲームオーバーコンテントくらいには付けてもいいと思います(ちゃんと注意してシナリオを作っていれば、戦闘以外での全滅は例外的な事態ですし)。

ゲームオーバー時は、ゲームオーバーコンテントのオプションチェックを見て、全滅を受け入れてゲームを続けた場合は、シナリオの詳細のオプションチェックを見るということになりますかね？

特定のシナリオの状態変数を他のシナリオでも取り扱えるようにしたい場合は、インポートやコピーで持ってきた時にシナリオ名・作者名が維持されるようにすればよいです。

なるほど、リレーシナリオなどでこうしてこれをコピーして使いましょう、ゲームオーバーやシナリオ詳細、ステップ・フラグのチェックを忘れずにと決めてしまえばいい訳ですね！

[req]

全部解決とします。

[k4nagatsuki]

実現の見込みがあるアイデアなので再オープンします。

[req]

そっちでやってくれると有難いです。UnofficialPy、PyLiteXE は内部的にはWsn.1000か何かで完全上位互換？でやろうと思っています。技術的に自分に出来るのか分かりませんが・・・(拡張子も変えろ、そんなことするなとおっしゃっていただいてもいいです。）

[k4nagatsuki]

後々の事を考えると、番号をそのまま増やすのは避けた方がいいです。たぶん派生を示す文字なり記号なりを加えた方がいいでしょう。WSNという名前を変えてもいいかもしれません。

バージョン判定用のシステムクーポン(Data/SystemCoupons.xml)や、cwxeditorの設定の保存場所(%AppData%\cwxeditor)などには注意してください。アプリケーションのアイデンティティに関わるそうした部分は、別のアプリケーションとして独り立ちするのであれば、真っ先に変更しておかないと面倒な事になると思います。

---

ところで、これまでの提案の内容を見ると、どうも@namereqさんが作りたいのは純粋なCWの発展形というより、それに似たビジュアルノベルツクールであるように思えます。多くの提案が反発を受けた原因は、おそらくそこにあります。

いっそのこと、名前を変えて、CWから派生した別のゲームとして出発するのはいかがでしょう。

CWの仕様の開発に議論が欠かせないのは、CWが確立したプラットフォームで、すでに大量のユーザがいるからです。

新しいゲームならばそのようなしがらみとは無縁です。従って議論を避けても許されます。「そんなのCWじゃない」式の文句を言われる筋合いもありませんし、開発者が自分で全てを決める事ができます。何より、現在のCWPyユーザと将来の全てのCWユーザに対しての責任を負わずに済みます。

私としてはWSN仕様が分岐する事でユーザに混乱が広がる事を懸念していますが(「このシナリオは3つあるうちのどの形式で、5あるうちのどのエンジンでプレイすればいいのか？ 私のシナリオはどの形式で作ればいいのか？」)、その問題も回避する事ができます。

[req]

長月さんって、そんなところに閉じこもってないで、自分のツイッター見てください。そこに書きました。

[k4nagatsuki]

私がIssueをよく使うのは、SNSを好まない性格もありますが、第一に記録を残すためです。記録が残っていなければ私の行動を後から検証・批判できません。

Twitterのつぶやきを読みましたが、「分岐関係などのCWとしての成果は無視されたのか？」という反応を見るに、私のコメントのリンク先の文書は実質的に読まれなかったのだと思います(それには@namereqさんの成果を入れていたのですが)。

読まないというのは、議論を回避する姿勢であれば必然的な帰結だとは思います。ですのでこのコメントも読まれない(理解されない)事を前提に書いています。実際に読まれなくても悪く思ったりはしません。

---

@namereqさんが選んだ道を進むと、ものを言う相手を無視し続けるか(賛同者だけに応答する)、過酷な議論の連続に取り組むかのどちらかの選択を迫られる公算が大きいです。しかし後者はすでに放棄されていますので、前者を選ぶしかない事になりえます。

後者が破棄されてしまうと、議論重視の私が@namereqさんにできる事は結局何もないという事になりそうです。

前者を選んだ時に問題を避ける方法の1つが、既存のCWユーザにかかる迷惑を避けて新しいゲームを立ち上げ、「自分の」ユーザを得るという道です。それがだめという事は、既存のCWユーザを取り込みたいという事です。つまり批判者・反対者の集団をも取り込もうとする事になります。このジレンマを解決する事はかなり難しいはずです。

この問題は、あらかじめ頭に入れておけば、実際に争い事が起きた時の衝撃が少しは軽いかもしれません。覚えておく事をおすすめします。

---

ところで、@namereqさんは、これまで私がやりたくてもやれなかった困難な技術的な課題にも取り組まれるようですね。成果を楽しみにしています。頑張ってください。

(毎度書き方が下手くそなので皮肉のように見えてしまうかもしれませんが、そんな意図は本当に無いです)

[req]

13分前ってことは、50分前の私たちは系列企業のベンチャー企業で、大会社のあなたたちはいくらでも取り込んで魔改造出来る。そしたら私たちはその機能について合流を図るも読んでいるってことですよね。若い頃の本田宗一郎さん。ならいいです。

それがだめという事は、既存のCWユーザを取り込みたいという事です。つまり批判者・反対者の集団をも取り込もうとする事になります。このジレンマを解決する事はかなり難しいはずです。

自分は、エクセル関数に殆どの人が使わないような関数がいっぱいあったりするのと同様に、１人でも欲しいものがあったら提供できればと思っています。それは長月さんにも伝わっていると思います。

本当は長月さんにもっと教えてほしかった。だけど、細々とやります。では。

[k4nagatsuki]

Duplicate of #822.