WSN追加案:クーポン連番増加コンテントの追加

[req]

タイトルはアイディアが修正されるたびに変わることが想定されますが、そこはご容赦ください。

私は、ジョブの街シナリオが好きで、ジョブを付けて他のシナリオで戦闘をし、ジョブレベルを上げたり、ジョブチェンジしたり、しまいには改造して新たなジョブを追加したり、バグ修正したりして、ネットに上げようとして許可も取らずにそんなことするなと怒られたりしていました。

それもあり思っていたのですが、クーポンをカウントするようなものというのはコンテントと分岐が複雑になりすぎるということです。それを簡略化出来ないかというのがご提案です。

すごいポカやってたので、再度アイディア直します。更に変更します。

クーポン連番増加コンテント１つが欲しいです。

[req]

思い出しましたが、私の好きなＦＦ６には血塗られた盾があります。これを英雄の盾にするには２５６戦闘が必要です。これに似たようなことをＣＷでしようとすると、使用時イベントで、クーポン：１があったら、クーポン：１を削除して、クーポン：２を取得・・・・というのを２５５回書かなくてはならなくなります。

アイディア出したの元々自分で、結局立ち消えしてたので、掘り起こして、練り直して出したのです。いいじゃないですか。

そうか、そうですね。ありがとうございます！ やはり "＿ステップ名＝使用回数”みたいなクーポン名の操作が必要ってことですね。

[req]

課題の説明にアイディア修正しました。３コンテントも使ってすることなの？と言われそうではあるのですが。ステップ・クーポン変換は、ステップ指定と方向指定します（選択中のメンバ固定？）。クーポン回数上下分岐はステップ指定と回数指定です。クーポン回数増加は、ステップ指定です。

[jinto_]

まず最初に言うと反対です。 理解する限り、この処理を実行するには新コンテントが三つ必要ということでしょうか。 コンテントが置かれる場所はエディターにおける花形ポジションだし、置ける場所にも限りがあるので、よほど有用でないと１コンテントであっても賛成できません。 やりたいことはわかるのですが、処理も中々煩雑なようだし、他のやり方でできないこともないし、それほどのことなのと思います。

クーポン多岐分岐で多少簡略化することはできるようになりましたし、nextのクーポン追加・連番を作成で後ろに数字のついたクーポンを一気に作れるようになりました。(これはpyにはないんでしょうか？ないならほしい) 昔より需要は下がってると思います。

[req]

はっきり言ってくれて助かります。今クーポン回数増加とクーポン回数制御（ステップ・クーポン変換＋クーポン回数上下分岐）の２コンテントに纏めようとしていたところですが、昔より需要は下がってるとか、よほど有用でないと１コンテントであっても賛成できないという感想も良く分かります。かなりやりやすくしますし、エディタのUIも複雑ではないですし、Pyの内部処理も複雑ではないことが見込めますが、狂い系を公式サポートするのかとか、仰る点は分かります。基本あらゆる意見は聞いているつもりです。

---

ちょっと待ってください。nextのクーポン追加・連番を作成で後ろに数字のついたクーポンを一気に作れるようになりました。(これはpyにはないんでしょうか？ないならほしい)　とは何ですか？　それの説明をお願いいたします。いや自分でNEXT動かして調べてみます。

調べました。これはpyというかXE(cwxeditor)の機能ですよね。やればいいんじゃないですか？自分はゲーム音楽聞きながら、初期エリアの作成していますが、異論が無ければ初期エリアの作成が何とかなれば試してみてもいいです。

---

アイディアを、jinto_ さんの言うように修正します。

連番に合わせて、クーポン回数増加をクーポン連番増加コンテントにして後ろに付いている連番の増加・クーポン名変更機能にして、クーポン連番増加　が欲しいのです。実体はクーポン名を変えるだけです。勘所のいい方は分かってもらえると思いますが、この短縮効果は大きいです。上記ＦＦ６には血塗られた盾の例が、１コンテントになるのです。（血塗られた盾を英雄の盾に変えることは出来ませんが。）

そして、連番増加はある一定の値でストップする必要があるので、上限値を追加します。これで追加するのは１コンテントになります。

そこで title と説明変えます。

使い方はそれぞれですが、アイテムを１０回使ったら使用できなくなりました（１０回使ったら無くなりましたではない）。 などもやりやすくなります。クーポン多岐分岐と連番で、アイテムを１０回使ったら使用できなくなりましたを書くと、

start "使用時イベント"
    brcouponm M
    if "＿クーポン10"
        break
    elif "＿クーポン09"
        losecoupon M, "＿クーポン09"
        getcoupon M, "＿クーポン10", 0
    elif "＿クーポン08"
        losecoupon M, "＿クーポン08"
        getcoupon M, "＿クーポン09", 0
    elif "＿クーポン07"
        losecoupon M, "＿クーポン07"
        getcoupon M, "＿クーポン08", 0
    elif "＿クーポン06"
        losecoupon M, "＿クーポン06"
        getcoupon M, "＿クーポン07", 0
    elif "＿クーポン05"
        losecoupon M, "＿クーポン05"
        getcoupon M, "＿クーポン06", 0
    elif "＿クーポン04"
        losecoupon M, "＿クーポン04"
        getcoupon M, "＿クーポン05", 0
    elif "＿クーポン03"
        losecoupon M, "＿クーポン03"
        getcoupon M, "＿クーポン04", 0
    elif "＿クーポン02"
        losecoupon M, "＿クーポン02"
        getcoupon M, "＿クーポン03", 0
    elif "＿クーポン01"
        losecoupon M, "＿クーポン01"
        getcoupon M, "＿クーポン02", 0
    elif none
        getcoupon M, "＿クーポン01", 0
    fi

こうなります。ここで、クーポン連番増加のCWXスクリプトを仮に、上限値10で、

addcoupon M,"＿クーポン", 10

と書けるとします。すると、

start "使用時イベント"
    addcoupon M,"＿クーポン", 10
    brcoupon M, "＿クーポン10"
    sif true
    break

こう書けます。使用時イベントの下が３コンテントになってスッキリするということです。自分は選択中のメンバのことしか考えていませんでしたが、パーティー全体に対して、死の宣告、毎ラウンドや使用時イベントでクーポン連番増加で５カウント、連番05がある対象全体を戦闘不能とか、メニューのクリック数のカウント（：クリック回数を連番増加）とかいろいろできる可能性は、シナリオ作者が模索されてください。

[k4nagatsuki]

たぶんですが、称号の得点を操作する処理が将来的に追加される事は必然だと思います。もちろん操作だけで済むわけがありませんので、得点がいくつかを調べる処理も必要となります。

ここで念頭に置いておくべきはissue #400です。これはあらゆる方面に使える汎用変数のIssueです。汎用変数に対しては色々な値を取り出す事ができ、かつ汎用変数の値を色々なデータに対して設定できるようにする必要があるわけですが、それが実現できた暁には、クーポンの得点だけを相手にするコンテントのような、個別の操作機能はまったく不要になります。

汎用変数の実現は簡単な話ではないですが、それまでの繋ぎとしてクーポン限定の機能を用意するべきか、となると、ちょっと判断が難しいところです。

[req]

汎用変数の実現は簡単な話ではない

何とか汎用変数を用意し、汎用変数操作用のコンテントを用意したとします。

汎用型の変数だけに、そのコンテント数がどの位になるか、利用しやすいようにエディタのＵＩを設計できるか、などを考慮すると、

クーポンにはすでに　クーポン分岐、効果での適用範囲：称号所有者、クーポン削除　があります。上記の様に　クーポン連番増加　は有用性があると私は考えます。

[k4nagatsuki]

提案の内容を改めて読んでみたのですが、操作できるのがクーポン「名」となると問題がありそうです。本来文字列であるものを数値のように扱うというのは本質的な設計のまずさを感じます。Javaでよく言われていた「"10"+1はなんなのか」問題と同様のまずさです。

例えばあるシナリオでA10という称号がつけられたキャラクターに対し、別のシナリオでA9という称号がつけられ、しかもA9が加算されたらどうなるでしょうか。そうした問題が果てしなく出てくる事が予想されます。

クーポンを使うよりは、キャストがなんらかの状態変数を持てるようにした方がいいです。

---

ここからは本題とは全然関係ない話ですが、

汎用型の変数だけに、そのコンテント数がどの位になるか、利用しやすいようにエディタのＵＩを設計できるか、などを考慮すると、

汎用変数に使うべきコンテントは1～3つです。

1. 関数や演算を実行するコンテント(Excelが想像しやすいと思います) …… 必須
2. 値を取得するコンテント …… 1.が流用できそう
3. 値を設定するコンテント …… 1.が流用できるか、2.と一体化させられそう

あとは全ての文字列・数値入力欄で汎用変数を指定できるようにするだけです。

[req]

操作できるのがクーポン「名」となると問題がありそうです。本来文字列であるものを数値のように扱うというのは本質的な設計のまずさを感じます。

マクロのところを今読んでいるところで、長月さんには設計・思想についていろいろ語っていただかないとと思っています。今日はコメントいただいていて感謝いたします。

さて、自分は設計については全く詳しくないですが、シナリオ内ならまず問題ない（シナリオ終了時に消滅するクーポンを使えばいい）ことは分かっておられるでしょうし、

基本的に、シナリオ外で使用するときは、　＿ジョブ１：アイテム１：01　のように長めに、他のシナリオとは被ることのないクーポン名にしておけばいいだけだと思うのですが。

[k4nagatsuki]

伝わらないのは挙げた例がまずかったせいですが、他のシナリオではなく同一のシナリオ内でも問題は起きますよ。

この設計だと、A10とA9は本質的に同じクーポンという事になります。しかしそれらは実際に違うもので、称号として扱えばまったく無関係のものに化けてしまいます。問題の根はそこにあります。

例えば、

• A10を称号削除で取り除こうとした時、シナリオのロジックにバグがあるせいで加算が足りず、A9だったら？
• A10とA9が同時にある時、Aが加算されたら？

これらの結果がシナリオ作者の直感通りになるか、あるいは思わぬバグを生む元となるか、結果は明らかなように思います。

[req]

A10を称号削除で取り除こうとした時、シナリオのロジックにバグがあるせいで加算が足りず、A9だったら？

これは、自分は想定していません。なぜなら、基本的に、10回使ったらアイテムが使えない。30回メニューをクリックしたら夜になる、255回戦闘したらアイテム獲得、5カウントで戦闘不能みたいなことを考えているので、9回の段階のクーポンに対して操作することを念頭に入れていません。（上でクリック数をといいましたが、それを判定するにはクーポン多岐分岐で長く書かなければならなくなります。そういう意味では汎用性に欠けますが、かなり有用であることには間違いありません。）

A10とA9が同時にある時、Aが加算されたら？

これについてはどうしようか迷っていますが、これも基本的には想定していません。確かに別のクーポンです。ですが、それはシナリオ作者の使い方で、このクーポン連番はこのエリアで使用する。このクーポン連番はこのバトルで使用すると決めてしまえばいい話です。

[k4nagatsuki]

それは想定してください。設計は漏れなく行うもので、未定義動作は事故の元です。ちょっと応用したらすぐに事故を起す仕様は、拡張性にも利便性にも欠けてしまい、使うたびに細心の注意を要求され、結局は便利なものとはなりません。

シナリオは、場合によっては大量のパッケージやイベントツリーが絡み合った巨大で複雑な構造物になります。その中での使用に耐えるものを設計しなくてはなりません。この機能をそのように設計するのは例示したように困難なのですが、それはまったく異なるものを無理に組み合わせてしまっているためです。要求仕様を満たすためにまったく新しいものを作る方が筋がよいです。

[req]

それは想定してください。

分かりました。

A10を称号削除で取り除こうとした時、シナリオのロジックにバグがあるせいで加算が足りず、A9だったら？

クーポン削除は、A10していなのにA9しかないので当然削除されません。残ります。

A10とA9が同時にある時、Aが加算されたら？

A10が加算されてA11になることにします。

要求仕様を満たすためにまったく新しいものを作る方が筋がよいです。

汎用変数を導入するためにどれだけの労力が必要かを考えると、まったく新しいものを作る方が筋がよいと考える長月さんのセンスは尊重しますが、クーポンという使い慣れたものの応用の方がむしろいいと私は考えます。

今だって、Aが無ければA1取得、A1あればA1削除でA2取得、と書いているわけです。それがA9まで来るのにクーポン連番９回で書けるという短縮効果が大きいということです。

今思った問題点は、A9とA09の扱いです。これは、

連番は、先頭の0を含まず、A09,A009～ はクーポン連番の対象から除外します。とします。

addcoupon ＜適用範囲＞,"A", ＜上限値＞　と書かれていて、A連番がない場合、A1がクーポン取得されることにします。

[k4nagatsuki]

想定してください、という事には、どう動くかというのも含まれますが、どういう合理性があってそう動くのかとか、それがシナリオ作者の直感通りになるかとか、その挙動がシナリオのバグで起きてしまった時に作者がバグを見つけやすいかどうかとか、そういった事まで含まれています。

機能には合理性と一貫性が必要です。そうでないと使う人にとって意味の分からない動きをするからです。しかもそれは往々にして作者ではなくプレイヤーの元で起こり、意味の分からない動きなので、どう調べればいいのかすら分からなくなったりします。

機能には汎用性があった方がいいです。色々な事に応用できるという事です。応用するためには合理的な動きをしなければなりません。Aという使い方をしたら想定通りに動くがBという使い方をするとよく分からない事になる、という場合、大抵の場合は根本の部分で何かを間違えています。

例えばこの機能の場合、アイテムカードの使用回数のカウントは、他の誰かにそのカードを渡しただけで動かなくなります。末尾が数値のクーポンを誰かに転送するコンテントを作ればよいのでしょうか？ また、得点がn点以上か未満か、というような判断を行う事も簡単にはできません。上下分岐も作ればよいのでしょうか？ このように次々とほころびと繕いを重ねるような状況に陥ってしまうのは、クーポン名という、これまで文字列で表された識別子としてしか扱われてこなかった要素を無理に他の事に流用しようとしているからです。他に方法が無いなどの理由で流用するのもやむを得ない場合もありますが、新機能の設計でそうなるというのはおかしな事です。

この機能は、土台の部分でクーポンの名前に数値を含めるという無理な事をしているために、表面上に様々なほころびができてしまっています。一つ一つほころびを繕う事はできますが、土台が脆いと次々と想定外の問題が起きてしまいます。

設計は土台の部分を強固にするべきです。強固で筋の通った土台さえ築いていれば、ほころびは少なくて済み、しかも合理的な形で修正できます。

[req]

今しろねこさんから、シナリオの数値管理はステップが直観的で使いやすいから、PCにステップを持たせて外部持ち出しして使えるようにするアイディアを頂いたことをご報告いたします。

さらに分かりにくい・混同するというご意見いただきました。

アイテムカードの使用回数のカウントは、他の誰かにそのカードを渡しただけで動かなくなります。

というより渡した相手が使ってもリセットされて連番増加してしまうってところですかね。

汎用変数の開発コストが膨大なことが想定されるので突っ張ってみましたが、概ね同意しました。 解決にします。

[k4nagatsuki]

この提案で解決したい課題について考えてみたのですが、これは根本的には状態変数をシナリオ外でも使えるようにしたいというものだと思います。その状態変数はキャストに属したりカードに属したりできなければなりません。しろねこさんの指摘は正しいです。

汎用変数を持ち出したのは私ですが、持ち出した時は目的が全然分かっていませんでした。そもそもこの課題は汎用変数では解決できません(汎用変数がカードに属せない限りは)。申し訳ないです。

で、カードに状態変数をくっつけるにはどうすればいいか、という事になります。CWはそういう風に設計されていないので、それはどうしても後付になります。後付のものを分かりやすく合理的で一貫性のあるものにするのは本当に難しいのですが、妥協せずに考えれば強固な土台を築く事ができ、課題の解決に近づけると思います。

[Iraka.T]

これを実装する前に、カードの使用回数操作を実装すべきだと思います。アイテムと召喚獣（付帯能力）にはすでに使用回数という固有の可変数値があります。

これを先に実装すると、現在、ゴシップやクーポンで擬似的に行われているように、カードの使用回数制限がこの機能によって代替されるようになるでしょう。それは、新たな代替機能ではなく、カードの使用回数操作機能によって実現されるべきです。

[req]

これ

これというのが、カードに状態変数をくっつける を指しているのであれば、カードの使用回数に置き換えると、じゃあスキルでの使用回数を知りたい場合はどうなる？という汎用性の乏しいことが起こります。やはり、状態変数をくっつけるを模索したほうが良さそうです。

[暗黒 騎士]

カードに状態変数をくっつけるにはどうすればいいか、という事になります。

NEXT1.70ではカードの使用時イベントに内蔵するカード変数を想定していたようですね。 NEXT1.70仕様の使用時イベントでは通常変数は使えず、カード変数のみが使える(参照先をそっくり切り換える？)というかなり思い切った仕様変更だったようで、Lyna氏も筋が良いと思っていなかったのか決めかねていたようです。