戦闘関連の半自動化＆機能向上

[snext1220]

#2 を受けて、Issueを分離しています。

互換性の問題が大きい問題の為、他の改定案件を先行しながら、進めます。
一度修正してしまうと、方向転換が困難のため、既存／将来シナの用途を想定しながらのご意見戴ければ幸いです。
＃ 本Issueの中でも、とりあえず影響の小さい1、2番目を優先して、3、4番目の対応は最後になるかと（現在は関連するテーマを見渡すためにまとめていますが、より具体化してきたところで更に分離の予定です）。

enemy要素にdrop属性（ドロップアイテム）を追加

<enemy drop="tue:3">

• イベントアイテム、自由アイテム、七惑星の欠片などを指定可能（ただし、初期改定では欠片のみを許可）
• drop属性無指定の場合は、従来通り、敵の属性に応じてカケラをランダム入手
• 【懸案】［ステータス反映］ボタンで反映のため、イベントアイテムは入手忘れが心配

モンスター一覧のアイコン追加（ときのじさんへ要相談）

• 各sceneに表示するモンスターの属性／攻撃方法をアイコン化
• 項目追加にと伴う横幅の節約のため、アイコンで見た目をシンプル化

［ステータス反映］ボタンで反映

• ボタンクリックでダメージ式をステータスに自動判定可能にする
• プログラム的に認識できるよう、ダメージ式の制限を強化する（下記）
• 【懸案】自動計算なので、ダイスの意味が曖昧に（ダイスクリックでボタンクリックが中途半端？）
• 【懸案】ボタンを何度もクリックしてしまうおそれあり（トースト表示すべき？） → ボタンクリックでステータスダイアログを開くか（面倒だが、視覚的に確認はできる）
• 【懸案】状態異常は自動化しないという意見あり（自動手動混在が中途半端なのが気になる）

ダメージ式の制限強化

以下の形式で統一する。

nL+nR+n-nSTR-nINT-nDEX-nKRM

ただし、以下の制約があります。

• nは任意の数値
• 符号（̟プラスマイナス）は差し替え可能
• すべての項は省略可能＆順番も入れ替え可能
• カッコは利用できない

既存のシナリオでダメージ式を利用していないものは修正の必要あり（互換性の問題）

以下は実装用メモ

var ex = /([\+\-]?)(\d*)(R|L|STR|INT|DEX|KRM)?]?/gi;
var str = "-L+2R+2STR+5STR-350";
let result;
while ((result = ex.exec(str)) != null) {
  if (result[0] === '') { break; }
  console.log(result);
}

[Salvadors-cabin]

#2からの続きです。
例えば、以下のような構文で実現できるとありがたいです。
scene id="29" params="-5MP"
※シーン29に移行後にMPが5減算される。
scene id="30" spells="mNOILA-TEM"
※シーン30に移行後に全ての星-1(NOILA-TEM)が実行される。

魔法実行前に手動で星を減算していた場合は確かに悩ましいですね。
これについては、ボタンを押しても「星が不足しています」のようなトーストが出で、実行されない、が理想かなと思います。（あくまでも理想です）

戦闘の半自動化については、私としては必須ではないと思っています。
各シナリオで戦闘が多様化しているので、今からの統一は難しいような気がするのです。

[snext1220]

魔法減算について

scene要素で明示的に指定するか、従来の魔法条件ボタンからの移動で無条件に減算するかは、要検討かと。

[魔法確認用（HEAL）](12 "mHEAL")

前者の場合

• ボタン側と次のシーンと双方で重複した記述が必要
• 魔法条件ボタンとの不整合が起こる可能性あり（あくまでシナリオ側の責任）。
• 魔法条件ボタンで減算するものとしないものがわかれる可能性あり

後者の場合

• 重複／不整合等の問題はなし（実装については要検討）
• 魔法条件ボタンでの移動では、無条件に減算処理（例外を許容しない）

星不足時の対応

トーストで恐らく問題はないと思います（自由移動ボタンとも同じ挙動なので、システムとして統一がとれているかと）

ステータス

• 戴いた構文の場合、ダイスは加味しない形となり、用途が限定される？

ダイスを加味することはできるが、初期表示時なので、ダイスの振り直しもできず（あくまで反映は一度だけ）、いきなりページ下部でランダム表示されているダイスの目で、ステータスが増減するのは把握しづらそう

• 「七惑星の欠片」をシナリオ側で自動加算させる機能 #2 でも出ましたがステの自動反映を適用できるのが、ごく限定的な状況になるため、プレイヤーの混乱が心配（慣れと言えば慣れですが…積み重なると、結局、ルールの複雑化を招くので、原則避けたい）
• 以前からの問題ですが、ステータスが勝手に変動するので、プレイヤーが把握できなくなる可能性あり。結果の表示は要検討（そもそもHP、MPが0以下になった場合？）

半自動化について

上記のような問題を受けての半自動化でした。

こちらでは、明示的にボタンを押してステータスを反映させるので、ルールはある程度まではシナリオ側で自由に変更できます（たとえば複数回押せば、繰り返しダメージを発生させることができます）。
＃ 基本、新・王杖／ゼロレベルであれば、問題なく対応できるはず

ステータス反映結果の表示方法について要検討なのは、同様です。

[Salvadors-cabin]

魔法減算について

私の意見としては、「後者」押しです。

ステータス

私の意見としては、「ダイス値は加味しない」です。
ダイスのランダム要素を入れてしまうと、分岐後の状態が不定になるのでシナリオからコントロール不能になってしまうからです。

以前からの問題ですが、ステータスが勝手に変動するので、プレイヤーが把握できなくなる可能性あり。結果の表示は要検討（そもそもHP、MPが0以下になった場合？）

分岐表示にはパラメータの残量条件(例:"oMP4+")を入れられるので、ランダム要素がなければHPやMPが0以下になるかどうかも想定して分岐後のストーリーを作成できると思います。

同じ画面で何度もボタンが押せる「戦闘の半自動化」では、HPやMPが0以下になった場合の表示ができないのでこの問題が発生すると思います。そういう意味で、「分岐後のパラメータ自動変更」だけを要望しています。

あと、ステータスの変更はHP,MPだけでなくFREEも変更したいです。私のシナリオ都合で申し訳ありませんが、FREEをGP(金貨枚数)として転用したいと考えています。（つまり、GPに適用したい、という意味です）

[snext1220]

HP／MPの自動換算については悩ましいところでして。

固定的なMP10減算などの状況は限られるため、（たとえば）同じようなトラップダメージでも、自動／手動が混在してしまいそうで（要はダイス判定の要否によって対応が割れる）；
先述のようにルール混在は避けていきたいので、対応するのであれば半自動で統一化を図っていきたい、という趣旨でした。

HPやMPが0以下になった場合の表示ができないのでこの問題が発生すると思います。

こちらについては、先述の通りでして、
ゼロ問題に関わらず、半自動ボタンクリック時になんらかの結果フィードバック（トースト表示？）が必要になると考えています（意図しない二重押し防止が目的）。

HP/MPがゼロになった場合については、これまで通り、システム側では対応せず、文章中で「戦闘でHPがゼロになった場合は～～～へ移動せよ」のような指示になっていくのかと。

余談

free1、2属性を追加した時に、合わせてstr、int、dex、krmなどの属性も追加しようと思ったのですが、こちらはシナリオ中でもさほど頻度が多くないと思われるため、見合わせました。リクエストがあれば検討したいと思います。

[RYU-DS]

＞enemy要素にdrop属性（ドロップアイテム）を追加
これでテストプレイでも指摘されていた「強い敵を倒す意義」が出せます。

＞モンスター一覧のアイコン追加（ときのじさんへ要相談）
私が勝手に攻撃方法を増やしたのが原因かと思いますが、アイコンで統一されるとその攻撃方法しか使えなくなる、という事はありませんでしょうか？その他の攻撃方法も設定可能な柔軟さが欲しいのですが…

＞［ステータス反映］ボタンで反映
＞ダメージ式の制限強化
これも私の戦闘複雑化が原因で、計算式もそのスレのものを採用していただいておいて何なのですが…
そのスレで現状コレを組み込まれてしまうと、盾防御/回避の判定が出来ず、待機敵からの半減DMだけを手動計算しなければならないという非常に煩雑な事になってしまい、実質戦闘が崩壊してしまいます。
なので自動戦闘を採用するかどうかをシナリオ側で選択できるようにしていただきたいです。
もしくはとりあえず自動で計算し、その結果の数字をさらにプレイヤーが加工してから反映できるようにする、というのはどうでしょうか？

[snext1220]

ドロップアイテム

こちらは #26 で実装しておりますので、ぜひ活用ください。

その他の攻撃方法も設定可能な柔軟さが～
自動戦闘を採用するかどうかをシナリオ側で選択できるように～

こちらはまさに自動計算の裏表だと思いますが、自動化を進めれば制限は強まると思います。
＃ 二重化はシステム（主にテスト）の負荷を考えても、プレイヤーの混乱を考えても避けた方が良いと考えています。

また、今のところ、皆さんの反応を拝見してきて、やはりかなり温度差があるのかなという気が。仕様的にも様々な思想が絡み合うのは良くないので、条件分岐／戦闘計算の自動化を実装するならば、Ver.1を凍結＆別コードでのVer.2という形になるのかなという気がしています。

＃ おそらく大枠のコードは一からの作り直しになるので、ホントにやる？は要議論ですが^^;

[RYU-DS]

自分は難解さ複雑さを平気でプレイヤーに押し付けている立場なので、柔軟性が得られるなら情報過多による混乱をあまり問題視していない、というのがそもそも問題なのかなとも思いますが…
ここまでを見た自動化についての意見は「プレイヤーの利便性のために、創作側に大幅に制限がかかるというのは、eとはいえゲームブックであるstextとしては本末転倒ではないだろうか？」というものになります。
「ゲームブックに必要最低限以上の戦闘が必要か？」というのはまた別の議論ということで。

[snext1220]

はい、もちろん、できるだけの柔軟性を維持していく、が基本スタンスです。

ただ、「情報過多」と「思想の乱立」は、システムのわかりにくさにつながり、プレイヤー／開発者双方のハードルを高めるという意味で、避けるべきだと思っています。一見、なんでも受け入れるというと聞こえは良いのですが、大概、思想が一貫していないシステムは理解しにくく、不要に難解になっていくので。

＃もちろん、異なる思想の排除にもなりがちなので、なにが乱立かという判断は難しいのですが；

思想、といえるほどにはまとまっていませんが、現時点では以下が、現状システムの基本スタンスにはなるのかなと。

https://sorcerian.hateblo.jp/entries/2018/04/29

勿論、絶対のルールではありませんが、こちらから大きく乖離する機能の追加は、（最初の設計で想定していないという意味で）困難であるか、改訂規模が膨らみがちのため、慎重になりがちとなります。

[snext1220]

以下、互換性を保ちつつ、半自動化を進める案（仮）です。
本Issueがかなり長くなっているので、後日、こちらは一旦Closeして、もう少しブラッシュアップした案で新Issueを立ち上げる予定です。