メモ: WSN(XML)シナリオへの仕様追加案(一覧)
このIssueの内容をWikiページに移植しました。2016-08-30以降はそちらで一覧を保守していく予定ですので、以下の記述は古くなっている可能性があります。
0.12.4までに予定していた作業があらかた済んだので、そろそろ、現状CWPyの独自形式であるWSN(XML)形式のシナリオの機能追加に着手してよい頃合いではないかと思います。
このIssueは、機能のアイデアを列挙し、一覧するために用意したものです。個別の案は1行程度のメモで記しており、詳細はありません。
各々の機能案についての詳細は、個別のIssueを立てて記し、議論を経た上で実装されるべきです。議論の内容には、その機能がどの程度有用か・どのような応用範囲があるか・欠陥はないか・仕様の衝突の危険性はどの程度か(#184を参照)・実際のデータ構造や挙動などの情報が必要です。
以下がアイデアの一覧です(順不同。状況が変わった場合は編集します)。
- 無限ウェイト(ただしウェイト飛ばし無効を無効にする必要がある)
- フォントをシナリオに同梱できるようにする
- F9のように状態をリセットするイベントコンテント(ゴシップなども含む)
- キャストに固定された所持カード(デバッグモードで外せる)
- アイテム・召喚獣入手時に使用回数を設定する
- シナリオ名と貼紙表示名を分けられるようにする
- 効果中断にカード回数を消費させないオプション
- キャラクター選択でキャンセルを消すオプション
- 背景の透明度・合成方式
- カード画像の透明度・合成方式
- シナリオ作者名を複数入れる
- エネミーカードに自動選択(召喚獣も)のターゲットにならないオプション(#280)
- エネミーカードに任意キーコードを持たない・持つカードにしか自動選択されないオプション
- 適性の白丸→黒丸のどの段階かの能力判定を行う
- 完全回復効果(召喚獣の消去や能力修正の消去を選択可能に?)
- 背景切替方式の追加: 緞帳式、カーテン式、観音開き式……
- 行動しない敵
- システムキーコード追加: @Sys:全体攻撃など?
- キーコード分岐で使用中のカードのキーコードを判定
- キーコード分岐で該当したカードを選択状態にするオプション
- 選択状態のカードを使用するオプション→効果のみ適用で使用時イベントは無視。成功・失敗で分岐?
- 使用時イベント中にカードのキーコードと効果を上書きする
- 完全固定値のダメージ・回復
- 割合ダメージ・回復(最大値処理は割合100%に置換?)
- 効果コンテントに「適用後にゲームオーバー判定を行う」チェックを追加
- 死亡イベントに「使用時イベント後も発生」オプションを追加。あるいは旧バージョン死亡イベントと死亡イベントに分ける(
#405) - パッケージやイベント単位での変数
- パッケージ引数
- パッケージの返り値
- 貼紙表示条件はイベントツリーの実行結果で切り替えられた方がよいのでは?(要返り値機能とタイムアウト)
- カード画像でカード上に表示される名前と本当の名前を別に設定可能にする
- 武器が効かない……などの特性をクーポン操作で制御する(#312)
- レベル上限や能力値をクーポン操作で制御する(#312)
- #{coupon:クーポン名}でクーポン所持者の名前を出す
- 敵・味方の思考ルーチンのパターン切替(攻勢・守勢・その他の作戦等)
- 他のパーティがすでに入っていても入れるシナリオ
- 背景の記録・復元
- フラグ切替時にすぐカード表示を変更せず、背景更新コンテントで「カード」にチェックを入れた時に同時回転で切り替え
- エリア移動や背景変更時にカードや背景の表示をすぐに変更しないオプション
- JPY1でのフラグ参照をする命令(flag=NNN?)
- JPTXでの特殊文字を使う命令、折り返し命令
- JPDCファイル保存でクリックしなくてよくする命令
- テキストセルでの折り返し
- メッセージコンテントに禁則処理を使用するオプション(デフォルトで有効)
- クーポン「:イベントターゲット」を付与。使用時(カード対象全体)、死亡(死亡者)、キーコード(発火者)。使用時イベント中に付け替えると別のメンバーがカード効果の対象になったりする(
#303) - ループや分岐後の合流といった制御構造の追加。スタートコンテント的なものをイベントツリーの中間に置けるようにする?
- 使用者が麻痺していても動く召喚獣(
#278) - カード対象: 自分以外(#279)
- 使用者に対して使用されたカードのキーコードに反応する使用時イベント
- カードの発動前に発火する使用時イベント(#295)
- 使用中に「死亡」「回避」「抵抗」「防御」などを行った時に発火する使用時イベント
- *.widをサブフォルダに入れる
- font_?.bmpの強化。#{file:???.bmp}などの書式?
- パーティのすべてのメンバに同じ処理をするイベントコール。選択は戻る
- フォント色の強化。#{color:#RRGGBB}といった書式?
- 多岐ランダム分岐(等確率で子コンテントのどれかを実行)
- Variant変数(文字列も数値も入り、演算も可能で、セルの配置などの数値に使える)
- アクションカードを引かない敵(スキルとアイテムのみ、尽きるとカード交換のみ)
- カード交換を持たない敵
- PCに対するキーコード・死亡イベント
- バトルエリアにNPCや第三勢力を表示
- キャストの勢力切替コンテント(各PCも切替可にする)
- PCを個別に上げ下げ(隠蔽・表示)する(#298)
- ラウンド終了イベント
- 行動速度ボーナス・ペナルティ
- 任意のPCをコピーしたキャストカード(状態の回復有無は選択)
- メッセージ送りや戦闘開始音をシナリオ側で変更する(
#283) - 背景画像・カード画像を上下左右反転して表示する(#293)
- 音声再生でテンポやピッチを変更する
- バトルのBGMでそれまで流れていたBGMの継承を指定できるようにする
- カード画像の配置方法の指定(中央寄せ・左上合わせ)(
#336) - カード画像の位置をずらして設定できるようにする(左上を基準にX座標±nなど)
- ダメージ・吸収効果に防御修正を無視するオプションをつける
- 対象消去・ゲームオーバー時にロストクーポン(「旅の中、帰らぬ人となる…」など)を付与しない方法の追加(#335)
- 1つのメッセージコンテントで状況に応じたメッセージ分けを行う(任意のステップの値による場合分けなど)
- 「どれか一つを選択してください。」を置き換える1行メッセージ
- 台詞コンテントの「評価メンバ」で沈黙者も含むオプション
- メニューカードの縦横比率を可変にする(#372)
- メニュー・エネミーカードを100%スケール以外で配置した時にカードイメージを100%サイズで表示する(#374)
- バトル終了後に状態を回復させないオプション
- エリア移動時に時間経過をさせないオプション
- 効果時間を絶対値ではなく差分値で設定するオプション(呪縛を5ラウンド追加など)
- 音声再生でパンニング(再生位置の指定)を行う(#305)
- バトルで「逃げる」ボタンを非表示にするオプション(バトル自体に設定するか、その他の方法で指定するか)
- 人数判定分岐でステータス条件をつけられるようにする。行動可能な人数など。
- ステップにPCのステータスを入れる(issue 329)
- シナリオ側の高解像度対応(
#397) - 同行キャストが離脱・再同行した時にステータスを維持するオプション
- 戦闘終了・再戦闘時にエネミーカードのステータスを維持するオプション
- 効果失敗時の挙動を指定する(#398)
- カード台紙などのスキンリソースをイメージファイルのように選択・表示する
- キャストカードサイズのメニューカード
- 効果コンテントでキーコードを発火させるオプション
- フィールド・選択メンバのキーコード条件を発火させるイベントコンテント
以下の機能はCWNext(1.60)で実装されているはずのもので、衝突の危険性が低いので安全に実装できます。ただし仕様は詳しく調査する必要があります(よく知らないので、リストに抜けがある可能性もあります)。シナリオの変換は当面実装する予定はありません(#162)。
- メニューカードの移動(
#297) - バックパック
- 効果コンテントでの死亡時イベント(要互換性確保)
- ミリ秒単位の空白時間
- 効果コンテントで使用カードの効果目標に効果を与える
- 台詞コンテントで話者を選択状態にする
- カード配付でカードを荷物袋に入れないオプション
- クーポン非所持分岐
- 荷物袋の制限
- セーブの制限
- キャンプ画面制限
- メニューカード名の変数展開オプション
- メニューカードのアニメ無効化オプション
- 仮想ステップ(メッセージやカード名でPC番号から名前と番号を出力)
以下はWsn.1で実装済みです。
- 音声で音量の変更(
#269/ pull request #1114) - 音声のループ回数指定(
#269/ pull request #1114) - キャストの所持カード・召喚獣召喚効果で参照を行う(
#288/ pull request #1115) - 音声を複数チャンネルで流す機能(Issue
#269/ pull request #1126, pull request #1131) - 音声のフェードイン・アウト(Issue
#269/ pull request #1136, pull request #1142) - カード画像を複数重ねる(
#292/ pull request #1159, pull request #1160) - カードと背景の配置でレイヤー指定。000は背景、100はメニューカード、200はPC、1000はメッセージなど(
#301/ pull request #1153, pull request #1173) - 評価メンバ選択分岐(対象者がいない場合は失敗)(
#294/ pull request #1183) - 任意数ステップ(エディタ側の対応を完了。2015-11-15)
- 精神力回復効果で回復量を調節できるようにする(
#326/ pull request #1300) - 背景セルの再配置・置換・削除(
#296/ pull request #1341) - PCイメージを背景セルとして表示(
#341/ pull request #1372, pull request #1375) - メッセージ選択肢の列の追加(
#363/ pull request #1406)
以下はWsn.1より前に実装済みです。
戦闘時にカーソルを合わせると全員分の使用カードを表示する(0.12.2)キーコード数を任意にする(最初から実現済み)
Comments (73)
-
-
reporter - edited description
-
reporter - edited description
ご指摘の項目を編集・追加していくつかIssueを立てました。
Issueを書きながら仕様を考えましたが、意外と実装のやり方に選択の余地があって衝突の危険が転がっていますね。悩みどころです。
-
reporter 書き忘れていましたが、提案はいつでもしてくださってOKですし、いきなり新規提案のIssueを立てたり、リストにある案の中でまだIssueが立っていないもののIssueを立てたりするのも自由です(ここで報告してくださればリストにIssueへのリンクを付けます)。
Issueの表題は「WSN追加案:」で始めることを推奨します。
-
>意外と実装のやり方に選択の余地があって
ですね…。なるべく余地がなさそうなのを選んで取り上げたつもりだったのですが軽率でした。
ついでなので結構前に考えていたのですが、ちょっと変化が激しすぎてどうかなという案を晒してみます。
技能・アイテムの(欲を言えば能力修正も)速度ボーナスの実装
成功率修正値または使用時/所有時ボーナスの隣に1メモリ2ぐらいの行動順値(敏捷・大胆)ボーナス枠を作る。 +5(+10)だと絶対先制(ラウンドイベントが優先)ー5(-10)だと絶対後攻(ただし毒の処理より後にはならない) 絶対先制が複数いる場合、元々の行動順で行動。内部的には絶対の場合、行動順値に±30とかすれば運を排除できる?
欲しい理由:CWでは回避・抵抗・防御・行動力(命中率・成功率・威力)に補正を掛けられるが、 行動順だけ一切操作できないので。たとえばポ○モンの電光石火のようなスキルが作れないので、作りたい人は多いはず。 RPG定番の素早さアップ装備なども現在は所有時回避率ボーナスを与えるぐらいしかできないが、所有時行動順ボーナス枠をつくればより正確な表現にできるはず。
実装しても大丈夫だと思う理由:元々行動順は完全には解明されておらず、ギミックにも組み込みにくい。 そこに少し介入するだけなのでフォーマットに致命的な影響を与えることはまずないと思われる。 速度ボーナスの概念がない他形式への変換は単純にオミットしてしまえばよく、キーコード数と同様にバランスが多少変わる以外に障りはないはず。
-
reporter まだ仕様が不明なので、却って衝突が恐いですね。計算式が不明ということは、どこにボーナスを加えるかで結果ががらりと食い違う可能性があります(ある実装では+5ボーナスで125%速く+10ボーナスで150%速く、別の実装では+5は同じなのに+10は300%速いということがありえます)。
しかし行動速度ボーナスというのはいいですね。仕様の衝突問題がどうにかなればぜひ追加したいです。まとまった情報を書いていただいているので、よろしければそれをそのまま新規Issueとして立てていただけないでしょうか。
-
>計算式が不明
あぁ…そうでした。正確な式が明らかになってからにした方がいいか、というのも迷いの一つでした。
意外に好感触で安心しました。ありがとうございます。ただ自分的にはまだ時期が早いかと思うので、もうすこし状況が変わってからにしようかと思います。(他の方が(反対)意見ある場合は引用して先に議論を進めていただいても構いません)
-
reporter - edited description
分かりました。とりあえずリストに追加だけしておきます。
-
reporter - edited description
Issue
#283の提案他を追加。 -
reporter - edited description
-
reporter - edited description
Issue
#278で出たアイデアを追加。 -
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
Issue #298でご提案をいただいたので、リストの関連する項目にIssue番号を追加いました。
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
Account Deleted ・1つの台詞コンテントを所持クーポン等でPC台詞のように分岐できるようにするのは 可能でしょうか?現状は分岐で台詞コンテントをわければいいのですが 複数分岐の可能性や、頻繁に分岐が該当するNPCがしゃべるばあい 非常に複雑な構成になってしまいます。
-
reporter ご提案ありがとうございます。メッセージコンテントで台詞コンテントのような事をしたいという事ですね。
仰るとおり、例えば任意のキャラクターをパートナーとして同行させる事ができ、そのキャラクターが状況に応じて頻繁に喋る、というような場合には有用だと思います。現状ではそのキャラクターが喋るたびにツリーを分岐させて処理を継続させるためにスタートへのリンクを行うとか、喋る処理を別ツリーにしてコールするというような面倒な手順が必要です。
問題はそれをどのようにして実現するかです。シンプルで分かりやすく複雑な要求にも応えうるような仕様で、かつ仕様衝突の問題を回避しなくてはなりません。それについては新たにissueを立てて話し合った方がよいでしょう。一覧には今から追加します。
-
reporter - edited description
一覧の末尾に追加しました。
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
2つほど提案をしてみます。ただ、どちらもシナリオ外に持ち出せる要素なので、慎重に検討するべきかもしれません。
・後天的に対属性を設定する
たとえば流行りの吸血鬼など、後天的に変化する可能性のあるものですし、称号のようにシナリオの中で対属性を設定することができたら表現の幅が広がって嬉しいです。
・カウンタースキルや召喚獣
たとえば、現在でも召喚獣の使用時ボーナスが受動的な効果をもたらしますが、その際に効果モーションも作動できるようにする、等。
また、特定キーコードに反応して作動することができれば、味方との連携スキル等作成することができてこれも面白そうです。
-
reporter -
そちらが対属性を含めた議論だったのですね。ありがとうございます。
カウンタースキルに関して、使用時イベントとして実装するのは、個人的には良くないように思っていました。使用者の適性による差別化が図りづらい、という点においてなので、
#303での議論如何かもしれませんが。 -
reporter 適性については、この辺りの案と組み合わせるのはどうでしょうか。
- 選択状態のカードを使用するオプション→効果のみ適用で使用時イベントは無視。成功・失敗で分岐?
- 使用時イベント中にカードのキーコードと効果を上書きする
いずれにせよカウンターというのは結構複合的な機能な感じがします。CWには元々無いので、いかにこれまでのシステムに整合するように組み込むか……なかなか強敵です。
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
reporter - edited description
-
- 効果コンテントでキーコードを発火させるオプション
これについて、以下の案との兼ね合いも考える必要があるのではないでしょうか。
- 選択状態のカードを使用するオプション→効果のみ適用で使用時イベントは無視。成功・失敗で分岐?
- 使用時イベント中にカードのキーコードと効果を上書きする
効果コンテントにキーコードを実装するのなら、対象レベルではなく使用者の能力で計算されるオプションを同時に実装すれば、カードを使用するオプションやカードの内容を変更するオプションは不要になると思います。
-
効果コンテントで以下がすべて実現すれば完全に効果コンテントをカードアクション扱いできますね。 表現の幅が段違いに広がるので、店シナ勢には大きな需要があるかと思います。
- 対象レベル(と能力)で選択中メンバを参照
- カードと同じ効果目標(
#303が先に実装される場合は「特定クーポン所有者」という方が応用が利く?) - キーコードを入力・発火する/死亡時イベントを発火する
「フィールド全体で魔法が無効化されているというような場合、使用時イベント自体を動かしたくない事がある」 というケースについてはスタート直下で「魔法キーコードの付いた効果のない効果コンテント」を置けばいいかと思いました。
死亡時イベント発火タイミングを効果コンテント使用直後とするNEXT仕様をカバーする必要がある以上、 キーコードについてもその都度エリア/対象に発火する必要があり、それでいくと魔法キーコードイベントが発火し、効果中断されればそのカードは使用できない、というようなイメージです。
-
reporter いくつかの提案は、実装された暁には相互運用してより大きな問題を解決できる事を期しています。例えば使用時イベントにキーコード発火条件をつけられるようにして、
@イベント対象
を付け替えられるようにすれば、魔法の反射が実現できるとか。「じゃあそろそろこれもやろうぜ」というものがあれば、Issueを立てて議論を始めていただいて構いません。@IrakaTさんんが指摘されたような、「これとこれがあれば、これはいらない」というものも議論の中で洗い出せていけるはず。
-
reporter - edited description
-
改めてみると、Py1がリリースされたので試験実装の項目は正式リリースの方に移しても良いのでは。(改めてお疲れ様です)
そういえばちょっと前にNEXTの機能についてWsn.1の現状の比較表を作ってみたのですが、以下が抜けているようです。
- メニューカード名の変数展開オプション(#Mなどをそのまま表示させる互換性対策?)
- メニューカードのアニメ無効化オプション(エンジン側に瞬間表示オプションがあるPyでは重要性は低い?)
- 仮想ステップ(メッセージやカード名でPC番号から名前と番号を出力)
また、制限コンテントには荷物袋、セーブのほかにキャンプ画面制限があるようです。
-
reporter - edited description
-
reporter ありがとうございます。修正しました。
-
reporter Issueの状態だと私しか編集できないようだし使いづらいので、内容をwikiページに移植しました。
これなら、BitbucketのID持ちであれば思いついたアイデアを自分で追加できるはずです。
-
reporter - edited description
-
reporter - edited description
- changed status to resolved
wikiページの作成により、このIssueは必要なくなったので解決済みとします。
- Log in to comment
意外に山積みだった!
このへんはわりと簡単に実装できそうで、大きな変化を与えずにできることを増やせそうですし、是非欲しいですね。
最初エッと思いましたが、考えてみるとMP3が多用されてる今となっては数MB程度で変わらないですからありかもしれないですね。サウンドノベルなどではそうしているものも多いですし。
これらについてはPyも実装済みではないでしょうか? あとおそらく荷物袋やセーブの制限コンテントが抜けているでしょうか。 ギャンブル系シナリオでプレイヤーの事前セーブを防げるメリットがあるのでPyでも結構欲しいなと思っていた機能です。