Repository navigation
02.ScriptLssues
本システムでは、カートシステムおよび交易システムで利用する大量金額処理の軽量化を行っています。
CardWirth標準のゲーム中通貨(Sp)のやり取りは GetMoney / LostMoney の２定義で行われており
同一種多数購入や複数種類同時購入の仕組みには別途、 金額用ステップ と 購入数ステップ などが必要になるため
現在も主流は GetMoney / LostMoney どちらか一つで済む単品取引形式です。
この単品取引方式は、交易システムの大容量品を換金する際は売り切るまでクリックなど物理的に疲れるという問題があり
Py5以降ではコモン変数による提示中アイテムの個数変換と提示中アイテムを選択状態に固定ができるようになりました。
それでも、同一種多数購入や複数種類同時購入の実現にはGetMoney / LostMoney 定数指定での処理が前提となるため、
任意の金額を一括で加算・減算しようとすると大量の分岐が必要になります。
Py5以降ではコモン変数による数値管理が可能になったため、この仕様を利用してシステムを再設計しました。
https://github.com/swdf-kuroko/EDR-Archives/releases/tag/CW_relsase
元々このシステムは、
- カートシステム
- 交易システム
- 大容量商品の換金機能
向けに作成したものでした。
初期仕様では、
アイテムの使用回数を登録
↓
1個ずつ換金
↓
GetMoney実行
という方式を採用していました。
しかし大量のアイテムを処理すると、
+100G
+100G
+100G
+100G
...
と所持金ログが延々と流れ続けてしまいます。
そのため、
換金額を一括計算
↓
最後にまとめてGetMoney
という構造へ変更しました。
旧バージョンでは、
9999G
のような最終結果ごとに専用イベントを持っていました。
例：
if 9
getmoney 9999
elif 8
getmoney 9998
elif 7
getmoney 9997
...
この方式では、
9000
9001
9002
...
9999
をすべて個別定義しています。
実質的には、
金額を計算する
のではなく、
金額一覧表を持つ
方式です。
4桁対応の場合、
0000 ～ 9999
までの組み合わせが存在します。
さらに5桁対応に拡張すると、
00000 ～ 99999
まで扱う必要があります。
その結果、
- イベント数の爆発
- ファイルサイズ増大
- 編集の困難化
- 保守コスト増加
が発生します。
実際に旧方式の5桁版では、
GetMoney処理だけで5000KB超
という非常に大きなサイズになっていました。
さらに LostMoney 側にも同様の処理が必要なため、
システム全体ではさらに容量が増加します。
新方式では、
まず計算結果をコモン変数へ保存します。
例：
9583
↓
9
5
8
3
へ分解
↓
1000 × 9
100 × 5
10 × 8
1 × 3
として処理します。
購入対象の価格を合計します。
price_01
＋
price_02
＋
...
↓
Cart\Sumcale
へ保存。
setvar "Cart\Sumcale_str", 'STR(@"Cart\Sumcale")'
LEFT()
MID()
VALUE()
を利用して、
9583
↓
9
5
8
3
へ変換します。
Cart\calc\A(4)
Cart\calc\A(3)
Cart\calc\A(2)
Cart\calc\A(1)
へ保存します。
例：
9583
なら
A(4)=9
A(3)=5
A(2)=8
A(1)=3
となります。
最終的に
1000 × 9
100 × 5
10 × 8
1 × 3
として処理を実行します。
9583
↓
9583専用イベント
特徴
- 動作は単純
- 容量が非常に大きい
- 桁数増加に弱い
9583
↓
1000 × 9
100 × 5
10 × 8
1 × 3
特徴
- 容量が極めて小さい
- 桁数増加に強い
- 保守しやすい
この変更により、
- イベント数を大幅削減
- ファイルサイズを大幅削減
- 桁数拡張が容易
- 保守性向上
を実現しました。
旧方式では5000KBを超えていた金額処理部分も、桁分解方式への移行によって大幅な軽量化を行えています。
特にカートシステムや交易システムなど、大量の金額処理を行うシナリオでは効果が大きく、今後の共通システムの標準方式として採用しています。
現在のCardWirthPyでは、
GetMoney 定数
LostMoney 定数
という構造になっています。
将来的に、
GetMoney(変数)
LostMoney(変数)
のような変数指定が直接利用可能になれば、
本システムはさらに簡略化できる可能性があります。
ただし現行環境においては、桁分解方式が最も軽量かつ保守しやすいため、本システムではこの構造を採用しています。
この方式は単なる高速化ではありません。
本質的には、
「金額そのものを保存する」
方式から、
「金額の作り方を保存する」
方式への変更です。
CardWirthにおいては処理速度よりもイベント数や定義量がボトルネックとなることが多く、そのため本システムでは計算結果ではなく計算方法を保持する設計を採用しています。
本サイトは、 groupAsk様製作の"誰でもシナリオを作れるフリーゲーム"カードワースの シナリオや、素材を配布そして布教するサイトです