経過シーンでの条件分岐

[snext1220]

現在、ステータスでも経過シーン数を持っていますが、
この大小でリンクの条件分岐をできないか、という提案です。

経過シーンなので、イコールではありませんが、経過時間でリンクを切り替えたいようなケースでの利用を想定しています。

[toki-sor1]

すみません、こちらチェックもれてました……！
経過時間でリンクを切り替えられると、制限時間付きのシナリオが作りやすくなりそうですね。良いと思います！
ゲームブックはじっくりと遊ぶタイプのゲームだと思うのですが、そこに制限時間という概念が追加されることで焦りや緊張感が生まれるのが面白いかなと。

[snext1220]

はい～あとは、時間経過型のシナリオなどで利用できないかなと想定しています。
＃ 夜になったら、朝になったら～のような感じですね。

よって、単なる大小だけでなく、以下のような条件分岐になるのかなと考えています。

• e3%1：経過シーン数を3で割って1余る場合（同じく0、2の場合もセットで朝、昼、夜を表現）
• e100：経過シーン100以上（もちろん、大小も表現）

こちらは引き続き皆様のご意見をお待ちしてから、判断していければと思います～
もう少々お待ちくださいませm(_ _)m

[cocotori]

時間変化で状況が変わるシーンが作れるのは、
面白い試みだと思います。賛成です！

[toki-sor1]

経過シーンは、今のところ状態異常の時くらいにしかあまり意識したことがなかったりします。
そのため、時間経過型シナリオでゲーム内の時間の流れが意識できるのは面白いなと思いますし、よりシナリオの世界に没頭できて良いなと思います！　私も賛成です～！

[snext1220]

先の仕様があまり意味がなかったので（1ずつのループでは；）、今一度仕様を書き直しました。

• e40:4:1：0～10、11～20、21～30、31～40...（1周40までを4等分）としたときの1番目のグループ1～10、41～50...の範囲にマッチ
• e100：経過シーン100以上（もちろん、大小も表現）

最初の条件式がどうしても若干複雑になるため、仕様として今一度皆さんのご意見を戴ければ幸いです。このような指定の方が判りやすいなどあればお願いします。

開発メモ

x = 13
n = 4
l = [(x + i) // n for i in range(n)]

[cocotori]

確かにこの文法は覚えにくいかもしれませんね・・・

他の、ステータス条件式などを見ても思ったのですが
STextでは不等号記号><は使えないのでしょうか？

バトルでは使用できるようなので、全くだめということはないと思っているのですが。
もし使えるのであれば、

二番目は

e>99のほうがわかり易くないでしょうか。
100以下ならば101>e？

また、大小があるなら範囲も使いたいと思いますので

(e>5)&(10>e)
などの応用もしやすいかと思います。

この方法であれば、1番目の式も、

(e%40>0)&(11>e%40)

などの表現が可能だと思いました。

[snext1220]

@cocotori さん：
ご意見ありがとうございます！

STextでは不等号記号><は使えないのでしょうか？

結論としては、現在のままでは使えないが、条件分岐のロジックを見直すことで可能です。
ただし、以下の理由から避けておりました。

• 不等号／アンパサンドはXML（SGML）のタグと一致することから制限があり、SGMLを直接記述する場合に問題が出ていました（分岐の新構文の際に結構な混乱の原因となっていました）。
  • PgFlowでは内部的に処理するので問題は軽減されているのですが、それでもエディターでの編集を併用されている方も多いことから極力避けていました。
• SGML式では「id記号 + 数値」で～以上を表す構文が多く、記法を極力統一しておきたい（ステータスのoSTR5+も実は鬼っ子で、統一性から言えばoSTR5のように改定すべきかと考えています。その場合も現在の構文は非推奨扱いで残すと思いますが…）。
  • 今から他の構文も不等号表記にすることは可能ですが、恐らく却って冗長になるものが多いのかなと。

ということで、大小についてはもし必要であれば

• e100:150：100～150sceneの場合

のような構文を設けた方が既存構文との統一は取れるかなと。
＃ ただ、範囲で変化するような用途は「e40:4:1：40シーンサイクルで4等分」のようなサイクル用途がほとんどか、さもなくば「以上判定」でフロー自体がどんどん先に遷移していくのかなとも？

如何なものでしょうか。
引き続きよろしくお願いいたします～

[cocotori]

そういった事情があるのであれば、挙げて頂いたような構文で
大丈夫だと思います。

[snext1220]

ありがとうございます！
とりあえず再確認になってしまい恐縮なのですが、、、

• e100:150（範囲指定）は要りますでしょうか。
• e40:4:1：こちらの構文は他に比べても難解と思われますが、大丈夫でしょうか（代案もないので決めと言えば決めなのですが、もしこんな書き方が、などあればお知らせください）

引き続きよろしくお願いいたします～

[cocotori]

範囲指定はそうですね・・・最初必要かと思いましたが、
おっしゃって頂いたようにループでまかなえるように思いますので
わたしの方ではなくても大丈夫です。

e40:4:1について

こちらで大丈夫です！

[snext1220]

了解です！
範囲指定もあとから入れることは可能なので、他の皆さんのご意見もお待ちしつつ、現時点では優先順位低で考えてまいります。サイクル構文についても承知いたしました～

[toki-sor1]

e40:4:1：0～10、11～20、21～30、31～40...（1周40までを4等分）としたときの1番目のグループ1～10、41～50...の範囲にマッチ

す、すみません……こちらの理解力不足で仕様がよく分かっていないのですが（大汗）、
上記の場合、0～10シーン経過（朝）→11～20シーン経過（昼）→21～30シーン経過（夜）→31～40シーン経過（朝に戻る？　未明？）という意味なのでしょうか？
【追記】ループするとなると、41シーン経過で朝に戻るのかなと思いつつ、いまいち理解できておらず……；

e100：経過シーン100以上（もちろん、大小も表現）

こちらは分かり易くてよいですね。

[snext1220]

上記の場合、0～10シーン経過（朝）→11～20シーン経過（昼）→21～30シーン経過（夜）→31～40シーン経過（朝に戻る？　未明？）という意味なのでしょうか？

と、スミマセン、確かに4区分はおかしかったですね^^;
改めて以下のイメージです（e30:3:1の場合）。

• 0～10：朝
• 11～20：昼
• 21～30：夜
• 31～40：朝（以降繰り返し）

時間経過を表現する場合、恐らくこのループ構文は欠かせないと思うのですが、表現はどうしても複雑になってしまうので、少々気にした次第でした^^; 改めていかがなものでしょうか。

[toki-sor1]

あわわ、お手数をおかけしてしまい、申し訳ありません……！
とても分かりやすくご解説いただき、どうもありがとうございました！

e30:3:1の場合は、31〜40から繰り返しで朝になり、41〜50が昼になる、という感じなのですね！
複雑な表現ですが、時間経過には必須な構文であり、具体的な説明があれば内容が理解しやすいことから、この表現のままでも大丈夫そうです！

[snext1220]

こちらこそご確認ありがとうございます！
皆さんのご賛同も得られましたので、こちら改めて実装に移っていきたいと思います。

[snext1220]

本件対応し、GitHub Onlyにて反映済み、マニュアルも記載しております。
ご確認戴けますと幸いです。

Monthly Updateの間隔延長に伴い、本番環境へは任意のタイミングで反映してまいります。ご了承ください。

[snext1220]

本件、「e100：経過シーン100以上（もちろん、大小も表現）」のみ対応に改め、GitHub Onlyで反映しております。関数の実装に伴い、サイクル、範囲判定は関数に移動しましたので、ご了承ください。
詳細は、 #279 も合わせて参照ください。

[Salvadors-cabin]

Win10+Edgeで経過シーンでボタンキャプション表示が制御できることを確認しました。

[cocotori]

#279 でご報告したように、
正常に動作していました。

[toki-sor1]

Win 8.1/Chrome 92.0.4515.131(64bit)にて動作確認。
ココさんと同じく、 #279 でご報告したとおり正常に動作していました！

[snext1220]

皆さま、ご確認ありがとうございます！
なお、 #279 でのfn:cycle関数の他、e100のような分岐も可能になっております。
＃ あるいは埋もれてしまったかもしれませんので、念のため。