カードーワースシナリオの『エリアファイル』の重量のうち、
占める割合の高いコンテンツってのは何ですかね？
例によって調べるのは苦手なので、誰か教えてください。

たとえば、フラグを新たに作って対応させる場合と、フラグを初期値に
戻して汎用的に再利用するのとではどっちが軽量化につながるか、とか。
画像や音響は仕方ないとしても、これを知ればシナリオが軽量化できる
のではないか、という浅知恵……

(記事番号9837へのコメント)
呑珠庵さんは No.9837「コンテンツの重量について教えて」で書きました。
>カードーワースシナリオの『エリアファイル』の重量のうち、
>占める割合の高いコンテンツってのは何ですかね？
>例によって調べるのは苦手なので、誰か教えてください。
>
確たる根拠は有りませんが。多分数バイト単位の差だと思います。ＣＷのファイル
容量は以前からいわれてきた問題点なのですが、その程度の差はディスク容量には
事実上無関係です。HDDにはファイルが4KB単位で保存されますので。
 それでも調べてみたいとは思っていますが、そんな余裕もないもので…

一つ重要なのは、カードの効果や効果コンテントでの「召喚」です。これは召喚獣の
カードをまるごと含んでしまうので、少なくともKB単位の大きさになります。

(記事番号9838へのコメント)
ＩＢさんは No.9838「Re:コンテンツの重量について教えて」で書きました。
>事実上無関係です。HDDにはファイルが4KB単位で保存されますので。

　揚げ足取るようで申し訳有りませんが、１ファイルに最低限使用される容量は、１クラス
タ当たりの容量だそうで、ＨＤＤのファイルシステムの種類などによって変化します。　ら
しいです。

　ちなみに我がマシンのＨＤＤは８ｋｂ単位です。

(記事番号9837へのコメント)
呑珠庵さんは No.9837「コンテンツの重量について教えて」で書きました。
>カードーワースシナリオの『エリアファイル』の重量のうち、
>占める割合の高いコンテンツってのは何ですかね？

やはりセリフコンテンツではないかと……。あとは効果系コンテンツ。
効果系コンテンツに関しては、似たような効果のものをパッケージでまとめる
ことで、微々たる容量を稼げる可能性はありますね。

興味があれば、.widファイルをバイナリエディタで開いてみるとよく判ります。
正常に読み書きはできませんが、Windows付属の「メモ帳」にドラッグ＆ドロ
ップしても、だいたいのことが判ります。
（ただし、自己責任の元でやるようお願いします）


> たとえば、フラグを新たに作って対応させる場合と、フラグを初期値に
> 戻して汎用的に再利用するのとではどっちが軽量化につながるか、とか。

フラグ／ステップなどの変数に関しては、呼び出されるたびに「変数名の文字
数」分の容量を食うようです。
実際に試した訳ではないので断定はできませんが、エリアファイルに関して言
えば、いちいち呼び出しコストをかけて初期化するよりも、新しいフラグ／ス
テップを用意した方が、サイズは小さくなると推測されます。
ただし、その分Summary.wsmのサイズは「変数名の文字数＋変数の状態名」分
だけ増えるので、（初期化が一回のみである場合）、理論上では「変数の状態
名」分のファイルサイズが増えるはずです。
即ち、状態名が「ＴＲＵＥ」と「ＦＡＬＳＥ」であれば、使いまわした状態変
数1つにつき4byte文字9文字分＝36byteの容量削減になるはずです（10個の状
態変数を使いまわせば360byte＝0.3KB＝全角文字で90文字分）。……状態名が
「T」「F」であれば2byte文字2文字で4byteの容量削減です（10個の状態変数
を使いまわせば40byte＝0.04KB＝全角文字で10文字分）。
即ち、全部のフラグ／ステップを使いまわして容量を削減したとしても、余計
なセリフコンテンツを一つ削除した方が、余程容量の省略化になる可能性があ
ります。

ただし、直前のツリーで「フラグ／ステップが増えるとエディター側の処理が
重くなる」という報告が出ていましたし、フラグの使い回しにもメリットはあ
るようです。
処理速度の問題は、CPUパワーに余裕があれば解決できるのですが。


さて、使用頻度の高いフラグ／ステップを、デバッグが終了した完成直前に、
「表示：CAST＿宿の親父」「ステップ：現在のストーリー進行状況」などの名
前から「a」とか「b」とかの名前にリネームすれば、幾らか（フラグ名を使い
まわすよりも余程）容量を稼げる可能性はありそうです。
しかし、まあ、「変数名に短くわかりにくい名前をつけて容量を稼ぐ」という
のは、データの可視性が悪くなる、具体的には、デバッグや修正作業が非常に
困難になるので、あまりお勧めはできません。
十数年前にはプログラムをコンパクトにする常套手段でしたが、近年のプログ
ラミング技法では禁じ手中の禁じ手とされているものです。

(記事番号9839へのコメント)
>さて、使用頻度の高いフラグ／ステップを、デバッグが終了した完成直前に、
>「表示：CAST＿宿の親父」「ステップ：現在のストーリー進行状況」などの名
>前から「a」とか「b」とかの名前にリネームすれば、幾らか（フラグ名を使い
>まわすよりも余程）容量を稼げる可能性はありそうです。
>しかし、まあ、「変数名に短くわかりにくい名前をつけて容量を稼ぐ」という
>のは、データの可視性が悪くなる、具体的には、デバッグや修正作業が非常に
>困難になるので、あまりお勧めはできません。
>十数年前にはプログラムをコンパクトにする常套手段でしたが、近年のプログ
>ラミング技法では禁じ手中の禁じ手とされているものです。

この技をセルに対応させているフラグで使用するとそのセルへのリンクが切れます。
その他のフラグ(カードに対応させている物など)、ステップなら大丈夫です。

(記事番号9840へのコメント)
wweさんは No.9840「少々補足させて頂きます」で書きました。
>この技をセルに対応させているフラグで使用するとそのセルへのリンクが切れます。
>その他のフラグ(カードに対応させている物など)、ステップなら大丈夫です。

セリフコンテンツに埋め込んだフラグ／ステップも、同様にリンクが切れますね。

セルへのリンクが切れるというのは、（恥ずかしながら）実は初耳でした。
貴重な情報有り難うございます。