WSN追加案:能力値やレベル上限の増減や後天的な耐性の追加・除去
Issue #312
new
シナリオ側でPCの能力値やレベル上限を増減出来るようにする追加案を提案します。
通常の方法ではレベルの上がらないPCを入れることが出来るシナリオというのをずっと前から構想していたのですが、現在の仕様では最初にレベル上限を決めることは出来ても後からレベル上限を増やすことは出来ません。(デバッグモードによるクーポンの編集と併用すれば可能かもしれませんが一般的なプレイではありません)
PCの消去と追加を用いて擬似的にレベル上限を変えるといったこともやってみたのですが、沢山のキャストタイプが必要で管理が大変、名前・画像・クーポンがLVを上げようとする度にリセットされる等々で難点が多いのです。そこでシナリオ側から能力値やレベル上限を増減出来るように、と追加案を提案(殆どお願いですが)したわけです。
突発的な望まない変化を防ぐために設定で「能力値やレベル上限の変動を許可する」といったような項目をつけて、その項目がオフの時はイベントが発生しても能力値やレベル上限が変わらないようにするとか(初期状態はオフ)どうでしょうか。
Comments (17)
-
repo owner
-
個人的にはこの案には賛成で、エンジン側の設定によるデフォルト拒否はシナリオの表現力・良い意味での強制導入力（たとえばPLにリスクを警告した上でレベルや能力ドレインの代償として本来助けられない人の命を助ける選択肢を用意するだとか）も損なってしまい、本末転倒のようにも思えるので別段セーフティは設けず、作者側の善意に任せた方が面白い物がでてくるのではないかと思いますね。
-
reporter
なるほど。ではエンジン側からは防止機能は設けず、能力値やレベル上限・特性(耐性や弱点など)で変化が発生したら
それを知らせる機能(○○の△△が[増加・減少・変化]した！とかのように)を設けるとかはどうでしょうか？
大まかでもどういう風に変化したのかが判れば、突発的な望まない変化だったとしても
プレイヤーの判断に委ねること(そのまま続けるなりデータをロードするなり)も出来ますし。 -
似たようなものに
＿消滅予約クーポンという前例がありますし、 出来る事は多い方が面白そうなので私も このWSN追加案には賛成です。宿帳登録したPC（通常のPC）をどう扱うのかが一番の問題だと思いましたが、 通常のPCであれば特に問題なくデバッグモードの再計算・再設定機能で正常な状態へ戻せますし、 暗黒 騎士 さんの案に賛成します。
ですが、デバッグモードが身近な存在というのもおかしな話なので、 その場合は「PCの能力値などに変更が加わるシナリオを非表示にする」オプションを追加するのが無難だと思います。
また、実際に変化があった際は宿帳登録PC・連れ込みキャストを問わず、通知が必要だと思います。 その際の通知は、レベルアップ通知のような形・タイミングが自然だと思います。
-
repo owner
ご意見ありがとうございます。
通知は通常・デバッグモード問わず常にあった方がよさそうですね。ゲーム内の雰囲気に馴染むようなさりげない通知にする必要がありますが、具体的には@crowstarさんの提案のような形になるでしょう。タイミングはシナリオ終了時というのに賛成です。その時点で通知されれば、保存せずに終了してからF9を押す事ができます。
後の問題は、具体的な変更方法と、仕様衝突の問題です。というかこれらが最大の問題なのですが、前者はともかく、後者は提案の内容からして簡単には解決不能な気がします。WSN仕様の提案には、常にこの問題がついて回ります。せっかくのご提案なのに、実現するのは、もしかすると相当な未来になるかもしれません。うまい解決策をひねり出せればよいのですが……。
-
reporter
追加案を提案した割にはあまり意見を出せていなくて申し訳ない・・・
方法としては、シナリオ中に変化は発生せずシナリオ終了時にメッセージの表示と能力値などの変化が発生する(レベルアップと同じ様な感じ)、
そして処理の順番としては能力値変更処理→レベルアップ処理というのはどうでしょうか。
また、どの仕様と衝突しそうなのかよろしければ教えてもらえると嬉しいです。 -
repo owner
仕様衝突という造語の詳細についてはIssue 184に記してありますので、ご覧ください(Issue番号で自動的にリンクが張られないようになったのはなんでだろう？ 不便なんだが……)。
今回の場合は、この機能に該当する仕様が現状のCWにはまったくない事が問題になります。既存の実装がないということは、実装する時にどのような形式でも選べるということです。しかし、ここでCWPyがクーポンでの操作を選択し、他のシステムではキャスト編集ダイアログのようなものでまとめて編集するというようなやり方を選択すると、将来的な仕様の統合やデータ形式の相互変換が容易ではなくなります。
究極的には、同じような事をする2つの異なる仕様を混在させるというような手が取れなくもないのですが、それは結局仕様の内部に永続的な混乱を残すという事になるので、できるだけ避けたい事態なのです。
将来を考えないという手段についても同様で、いざという時につけが回ってくるような種を撒くのは、よほどの事でない限り避けたいです。
ですので、本当にこのやり方を選んで実装してよいのかどうかは、周囲の状況を観ながらじっくり考えて判断しなくてはならないという事になります。CW互換システムの仕様が全てオープンで、風通しがよければよかったのですが、残念ながら現状はそうではありません。
-
#277にて後天的な対属性について希望しこちらに誘導していただきました。私としては、変化の適用はシナリオによる操作タイミングで反映し、シナリオ終了時にその変化を残すかどうかの確認をする（あるいはしない）というのがいいように思います。
というのも、変化を適用させるのに一旦シナリオを終了させなければいけないのでは、シナリオ中の一時的な変化（たとえば導入において望まぬ変化が起き、それを解決するためのシナリオ）ができず、大規模な追加機能であるにもかかわらず表現力にはあまり寄与しないからです。
能力値の補正について、例えば器用度なら「＠数値補正：器用度」クーポンの点数によって、Pyでのプレイ中に補正がかかる、というような仕様ではどうでしょうか。
対属性に関しても、「＠対属性：生命無効」等を持っているPCに、対属性があるものとして効果の処理を行う、というのは難しいことでしょうか。
さらにもしかすると、これらのクーポンは＠クーポンである必要がないかもしれません。普通の隠蔽クーポンであれば他エンジンに移ったとしても、ユーティリティで除去可能なノイズとして残るだけになります。
それは他エンジンに変化を持ち込めないことにもなりますが、はたして独自機能による変化を、本家含む他エンジンに持ち込むことは良いことなのか、とも思います。
-
repo owner
一点だけ、他の仕様との相互変換について私の考えを書いておきます。
各仕様が、異なる方法で同じ機能を実現しているのであれば、それらは相互に変換可能です。WSN側でシステムクーポンで実現している能力変更を、ある仕様Xではキャラクターに能力変化用のパラメータYを設ける事で実現していたとします。この場合、WSN仕様のシナリオを仕様Xへ変換する時、単純に問題のシステムクーポンをパラメータYに置換すればよいのです。逆もまた真です。
もし変換先にそうした機能がそもそも無い場合は、変換時に、単純にシステムクーポンを削除する事ができますし、「この機能を使っているキャラクターは変換できないよ」としてエラーにしてしまう事もできます(半端に変換して変換先で問題を起こすくらいなら全体を弾いた方がよいという考え)。
こういう風に変換を考えると、クーポンを新機能に用いるのであれば、使うべきは一般のクーポンではなく、システムで定められ、ユーザからは操作できない
＠クーポンです。なぜなら、一般のクーポンに混ぜてしまうと、変換先・元のデータに偶然同じ名前のクーポンがあった、というような時に正確な対処ができなくなるからです。＠クーポンであれば偶然同じ名前のクーポンがあるという事はありえませんので(同じ名前のシステムクーポンを別の機能に使っているという可能性はありますが、これは変換時に検出できます)、この問題は起こりません。 -
reporter
変化の適用はシナリオによる操作タイミングで反映し、
確かに、シナリオ途中で能力値に変化を起こせた方が表現力は高くなりますね。
シナリオ終了時にその変化を残すかどうかの確認をする
個人的には、やはり設定で[能力値などの変更を許可する]といった項目で操作の有無を選択できた方が良いと思っています。
その際に、「変更許可にチェックが入っていた場合に出てくるシステムクーポン」(ver情報のシステムクーポンみたいなやつ)とかあったら良さそうですね。
フラグ判定と併せて、シナリオ開始時に能力値変更許可が入っている場合のみ選択できる選択肢といったものが作れるようになって良いと思うのですが。それと後天的な耐性なども話として上がってきてますので、そちらの方も課題名に追加しておきますね。
-
reporter
- changed title to WSN追加案:能力値やレベル上限の増減や後天的な耐性の追加・除去
課題のタイトルの変更です。後天的な耐性についてタイトルに含めるようにしました。
-
repo owner
元の能力をそのままにして、後付のクーポンで補正が入るようにしたほうがいいかもしれませんね。そうすれば万が一の事があってもプレイヤーの意思で元に戻せますし、ボタン一発でそれを実行する事が可能ならあえてオプションをつけたり許可を求めたりする必要も無いかもしれません。
-
repo owner
人間以外の種族つきスキンの同梱が現実的になってきたので、付け替えの話は後にして、とりあえずは判定だけでもできるようにした方がいいかもしれません。
仕様衝突の問題は、上に書いたようにおそらく変換プロセスで吸収できるのでWsn.2で実装してしまっても問題ないと思います。クーポンを使う場合、きっちり決めなくてはいけないのは文言ですね。
-
クーポンの名前を後から変更すると問題になりますしね。
＠命を持たない＠武器が効かないのように日本語を元にする＠Type undead＠NoEffect weaponのように内部の表記を元にする
のどちらかになるでしょうか。
実装ですけれど、内部的にはクーポン所持判定を使って、エディタでは新規コンテントとして扱う、という実装はできないでしょうか？
brcoupon M,"＠対属性用クーポン"は、エディタ上の見かけだけが別のコンテントになるというような。ユーザーがクーポン名を覚えなくてよくなります。 -
repo owner
それを行うくらいなら、データとしても新規コンテントの方がよいです。というよりなんでもかんでも称号の中に押しこむのはよくないので、システム内部に関わる機能を追加するなら、新しいイベントコンテントを作るべきです。というわけで、その逆の事は以前考えた事があります。即ち、表面上は称号で操れるように見えるが内部的には専用コンテントを使っているという状態です。
それをあえて称号で行ったほうがよいのでは、と言っている理由は、上の方にも書きましたが、「あまりにも一般的でない操作なので専用のイベントコンテントを設けるほどではない」というものです。1つの新しいコンテントを設けるとツールバー上の1箇所を専有しますが、それが100本のシナリオ中99本が使わない機能ならば、邪魔なだけではないかという事です。
しかしスキンによって特殊な属性を持つPCが一般的になれば、少なくとも判定だけは一般的な操作になるので、またちょっと前提が変わってきます。専用コンテントを設けるべきかもしれません。
文言は、他のシステムクーポンの慣例に従って、日本語でよさそうな気がします。国際化で問題が出ますが、同じ機能を持つ別の名前のシステムクーポンを用意する事は容易です。
-
なるほど、であれば新規コンテントを用意したほうがいいのでしょうか。私は対属性をクーポンでも検出できたほうが便利だと思いますが、それは事前にクーポンを付与すれば間に合うことですし。
エディタ上で新規コンテントを用意せず、内部で新規コンテントとして処理されるという実装になるのであれば、
selmember true, valued, -1, ["：吸血鬼", 1] ["＠不浄な存在", 1]が意図した動作をするかどうかが気になります。 -
repo owner
ああ、評価メンバで使えるというメリットもありますね。見落していました。
こういう見落しがあるので、慌てずじっくり考えた方がよさそうですね。
- Log in to comment
Issue
#277の一覧に追加しました。ご提案ありがとうございます。レベル上限の操作が必要になる状況の実例としては、以下のようなものを見たことがあります。
ですから、限定的にでもそれを行えるようにする事は、私は賛成です。また、同じ文脈で、対属性や耐性・弱点も操作できるべきだと思います。「ホムンクルス」という称号を配付するシナリオは作れますが、PCを「魔法生物」にするシナリオは作れません。
これらは一般的な操作ではないので、新規イベントコンテントではなく、クーポンの付け替えなどの方法で行えるようにした方がよいでしょう(レベル上限は現在でも
＠システムクーポンで設定されています)。最も大きな問題はまさに
これが、プレイヤーの知らないうちに発生し得る事にあります。解決策は仰るものの他にもいくつか考えられます。
この機能には議論が必要だと私は思います。意見のある方はどんどん仰っていただけるとありがたいです。