巻物読んで読んで読み倒す巻物巻物巻物表紙に戻る

間違いは誰にでもある!

望ましい圧縮形態とは?

  • フォルダにファイルを納め、相対ディレクトリ指定で圧縮する
  • ファイルに不可視属性は付けない

 要するにシナリオのファイルを一つのフォルダに収め、そのフォルダごと圧縮するのが望ましいということ。その際、フォルダ位置を絶対指定しないで、相対指定すること。でないと、展開したときシナリオが行方不明になる可能性がある。DLL や 圧縮ソフトのオプションをきちんと設定しよう。
 また、ファイルに不可視属性が付いていると、ファイルの存在そのものを無視されことがあるので、不可視属性は事前に外しておいた方が賢明だ。

 ★ 相対指定
c:\cardwirth\scenario\hoge の位置にある hoge フォルダを圧縮し、それをデスクトップに展開すると、デスクトップ上に hoge フォルダが生成される。これが普通。
 ★ 絶対指定
c:\cardwirth\scenario\hoge の位置にある hoge フォルダを圧縮し、それをデスクトップに展開すると、デスクトップ上に cardwirth\scenario\hoge というフォルダがまとめて生成されたり、c:\cardwirth\scenario\hoge というフォルダそのままが生成されたりする。これは迷惑!

不要なカードとは?

  • 敵やNPC用のスキル・アイテム
  • 戦うことのない敵やNPC
  • イベントに使用しない召喚獣

 上記のカードはシナリオ完成時には不要になる。これらを削除すると全体のファイルサイズが多少減る。特に色数が多いカードや、スキルをしこたま持ったキャストを削ると効果が大きい。
 ver.1.15まででは、削除したカードの詳細をシナリオ作者以外は知ることができなくなるので、敢えて残しておくというのも選択肢の一つだったが、1.20の登場でその意味はなくなった。ザックリ行こう。ただし、召喚獣のデータは残しておかないと詳細を知ることができなくなるので、これだけは残してみてもいいだろう。
 リューンで売っているカードは明らかに不要だ。必ず削除すべし。

不要な画像とは?

  • スキル・アイテム・召喚獣の画像
  • 「イメージ格納」に設定したメニューの画像
  • 会話で顔を出す必要がないキャストの画像
  • 宿や“MapOfWirth”などのシステム背景画像

 これらの画像は意味がないので必ず削除しよう。カードに使っている画像は、カードのプロパティから保存することができるので、誰でも使えるリソースとして残しておく意味はない。
 念のために書いておくが、いつもの宿屋や“MapOfWirth”などのシステム画像も必要ないぞ。

画像の減量

  • ベタッとした白と黒だけの背景画像なら2色に減色。BMPで保存
  • JPEG 向き画像か BMP 向き画像か、きちんと考える
  • JPEG 画像は色化けしやすい。High Color 環境で見栄えを確認
  • Card Wirth が認識する JPEG 画像の拡張子は ".jpg" か、".JPG" のみ

 Card Wirth シナリオのファイルサイズが肥大化する大きな原因は画像ファイルにある。減色、縮小、マスクの上手な利用、画像の使い回し等いろいろと工夫をして、全体のサイズを抑えよう。特に、画像の縮小は有効だ。最大サイズ 632×420 の画面に 800×600 の画像を表示するような無駄はやめよう。
 ver.1.20 になってファイルサイズが激減するJPEG形式の画像が使えるようになった。これを大いに活用したいところだが、なんでもかんでもJPEG化すればよいのかというとそうでもない。

★JPEGの特徴

  • True Color 画像のファイルサイズが激減する
  • サイズが減った分、画像が劣化する
  • High Color 環境で色化けが生じやすい
  • LHAやZIPによる再圧縮がほとんど効かない
  • 縮めたものを広げる分、表示が遅くなる

 大雑把な言い方をすると、同じような色の領域をまとめて単純化することにより、驚異的な圧縮率を叩き出すのがJPEG方式だ。その様子は極度に画像品質を落として(圧縮率を上げて)みると確認できる。
 JPEGにおいて、画像の劣化とファイルサイズの減少はトレードオフの関係にあり、品質とサイズのバランスをとるのになかなか根気がいる。
 ここにBTJ32という素晴らしいフリーソフトがある。リアルタイムに変化するプレビューを見ながら、画像品質とファイルサイズ双方に納得のいく変換をしよう。

 一つ注意したいのは、JPEG画像は High Color(15,16bits) 環境で色化けを起こしやすいということだ。画像品質を下げれば下げるほど無惨に色化けしてしまうのだが、True Color(24,32bits)環境ではその度合いが分からない。
 では、画像モードを High Color に設定すれば色化けを確認できるかというと、これがそうとは限らない。ビデオカードや画像ビュアーによっては、この色化けを補正して表示することがあるからだ。画像の最終チェック時には、補正を切るようにしよう。
 色化けがどんなものか見てみたければ、ディスプレイを High Color に設定してpinksea.jpgをクリックしてみよう。空の部分がジャギジャギになり、同心円状のグラデーションが確認できれば色化け実験成功だ。

 High Color 環境というのはかなり一般的な設定で、当サイトの調査によるとカードワース愛好者の半数以上が High Color 環境に設定している。
 となると、なんとかしてこの色化け問題を解消したくなるのだが、有効な手段は JPEG の画像品質をほぼ最高に設定するくらいしかない。だが、それではファイルサイズが膨らみ過ぎ、JPEG を使うメリットが薄れる。色化けしにくくなるよう画像を描き換えたり、画像の大きさを小さくし、その分画像品質を上げるなどの工夫が必要になってくるだろう。
 一番良いのは「細かいことは気にしない」ことか?

★JPEG化に向かない画像

  • 透過部分がある画像
  • はっきりした輪郭線や均一な塗りが持ち味の画像
  • 色数の少ない画像

 透過部分がある画像は、画像劣化(色むら・ピンぼけなど)によりその機能を損なう可能性が大きいので、絶対に JPEG 化してはいけない。その他は、圧縮率が悪かったり JPEG 化に伴う画像の劣化が大きくなったりするので、あまりお薦めしないということだ。これらの画像は BMP で保存した方が良い。
 普通、シナリオ配布時に LHA や ZIP、CAB などの形式でファイルを圧縮するわけだが、この時に画像のサイズの大幅減が期待できる。だいたいどの程度になるかは、256色あるいは16色の GIF 画像や PNG 画像を作ってみると目安になる。その際、誤差拡散をしない方がファイルサイズを小さく抑えられることも覚えおこう。これは BMP を圧縮する際にも言えることだ。
 もちろん、BMP として保存する際はきちんと減色することを忘れずに。true color の BMP ファイルのサイズを考えるとちょっとゾッとする。

★JPEG化に向く画像

  • 背景用の写真などの、色数が多くて(True Color)複雑な画像
  • ぼやけた画像

 GIF や PNG などの形式では色数を減らせばファイルサイズが小さくできるからといって、256色に減色した画像などを JPEG 化することは、あまり意味がないのでやめた方がいい。画像の品質を落とし、ファイルサイズを増やすという最悪の結果に陥ることがよくあるからだ。JPEG はやはりフルカラー画像で威力を発揮する。

 次のぼやけた画像が向いているというのが分かりにくいかもしれないが、これは高い圧縮率が出やすいという意味だ。試しにブラー(ぼかし)をかけた画像を JPEG 化してみると良い。同じ品質でセーブしても、ファイルサイズにかなりの開きが出ることが確認できるはずだ。背景だけぼかすなどの手法も有効だぞ。

 ただ、JPEG にはいろいろな魔物が棲んでいるので、思いもよらない問題が生じることがある。テストプレイの際には画像の見栄えもチェックしよう。

 なお、画像形式変換・減色に有用なソフトを以下に紹介しておくので参考にしてほしい。

 ★ BTJ32
画像形式変換ツール。JPEG変換前後の画像が表示される二つの窓を見比べて、品質とサイズとのバランスを納得行くまで調整できる。今まで、画像をセーブしては確認し、また調整して…という地道な作業を繰り返していた君に!
 ★ Padie
様々な方式での減色を試みることができる上、16bits color 環境(かなり一般的な環境だ)での見栄えを考慮したり、透過色を指定することができるのが特徴。ウルトラお薦め!

Readme.txt は書いたか?

  • 連絡先や著作権情報を記したテキストを必ず添付
  • シナリオを収めたフォルダ内においておくのが理想的
  • 段落の切れ目以外では改行しないか、70文字以内で改行する
  • 拡張子は ".txt" にする

 多少面倒かもしれないが、様々な説明を記したテキスト文書、いわゆる "Readme.txt" を必ず付けるようにしよう。バグ報告をしようにも連絡先が分からないのでそのままになってしまったり、添付文書に著作権についての記述がなかったために後でもめることになったりと、Readme がないといろいろ面倒な事態が予測される。よって、Readme文書の添付は必須と考えてもらいたい。

 Readme に最低限必要なのは以下の情報だ。

  • シナリオの名前
  • 制作者の名前と連絡先(メールアドレスやサイトの場所など)
  • 各著作物の著作権表示と連絡先(主にサイトの場所や素材集の名前など)

 この他にもファイル名やシナリオの簡単な説明、インストール方法や、配布条件、更新履歴などを書いておくことが望ましい。

 CardWirth のエンジンがver.1.20になってから、張り紙画面から「解説」ボタンを押すことで、Readme.txtを参照できるようになったので、この仕組みをうまく使いたい。
 そのためには、Readme を選択シナリオが収められたフォルダに入れておく必要がある。文書のファイル名は任意だが、拡張子部分は必ず".txt"でなければならない。また、参照画面内にうまく収めるために、行ごとの改行をしない方がいい。自動折り返しが効かないエディタなどを使って閲覧する人のことを考えて、半角70文字(Windows2000 等を考慮するなら64文字程度)以内で改行するのが理想的といえば理想的だ。

 「解説」で選択される文書は、現在のところカードワースではなくOSが決定している(正確に言えばファイルシステム)。そのためReadmeではなくネタバレ文書がいきなり表示されるのを避けるのは意外に難しい。完璧とは言い切れないが、以下のようにすればまず間違いないと思われるので参考にしてほしい。

  • ファイル名順で並べたときに読んで欲しい文書が先に来るようにする。
  • 先に読んで欲しい文書から作成する。

 文書更新やタイムスタンプの変更をしても、ファイルの作成順番は変わらない。作成順番を後で変えるには、いったん文書を別のフォルダーに移してから、読んで欲しい順に一つずつ移動するという手段が有効だ(Windows95/98の場合)。
 なお、次バージョンでは、ファイル名順で固定されるそうだ。

戻る


Copyright (C) Shu Koyama 1999-2000
No reproduction or republication without permission.

koyamas@dream.com

禁無断転載

表紙に戻る