四方山話/小ネタ

Last-modified: 2016-11-30 (水) 21:13:44

吉里吉里2（TJS2）

辞書配列の内容を配列にコピー

Array.assign()に辞書配列オブジェクトを渡せば、キーと値が交互に並ぶ配列が得られる（キーと値のペアの順序は入れ替わる可能性がある）。

var dic = %["red"=>0xff0000, "green"=>0x00ff00, "blue"=>0x0000ff];
var arr = [];
arr.assign(dic);  // キー☆、値☆、キー◎、値◎、キー△、値△…の配列になる

配列の内容を辞書配列にコピー

逆に、Dictionary.assign()に配列オブジェクトを渡せば、要素０=>要素１、要素２=>要素３…となる辞書配列が得られる。

var arr = ["red", 0xff0000, "green", 0x00ff00, "blue", 0x0000ff];
var dic = %[];
(Dictionary.assign incontextof dic)(arr);  // 要素０=>要素１、要素２=>要素３…の辞書配列になる

Arrayクラスにスタックのメソッドを追加

startup.tjsの先頭に、以下の２行を追加する。

Array.push = function(e) { add(e); }
Array.pop = function { var result = this[count-1]; erase(count-1); return result; }

以降、Arrayオブジェクトでスタックが実現できるようになる。

var stack = [];
stack.push(10);
stack.push(20);
var x = stack.pop();

メッセージマップの書き換え

本来は多言語対応のための機能だが、メッセージを関西弁にするといったお遊びにも使える。

メッセージマップの出力

  1. 吉里吉里を起動し、Shift+F1でコントローラを表示
  2. コントローラ上でマウス右クリックし、コンテキストメニューから「メッセージマップファイルの作成」を選択
  3. 吉里吉里（krkr.eXeまたはそれをリネームしたもの）と同じフォルダにmsgmap.tjsを保存する

メッセージマップの書き換え

  1. テキストエディタでmsgmap.tjs内のメッセージを書き換え、上書き保存する
  2. 以降、吉里吉里を起動すると、このmsgmap.tjs内のメッセージを参照、表示するようになる

吉里吉里Releaserのバッチ実行

逆引きマニュアルの「XP3アーカイブファイル作成を一括処理するには」の補足。
以下のようなバッチファイルを作っておけば、XP3アーカイブファイル（EXE形式含む）作成を自動化できる。
なお、このサンプルの場合、吉里吉里の解凍先フォルダがC:\kirikiri_kag、プロジェクトフォルダがC:\MyProjectのときに正しく動作する。

  setlocal
  rem 吉里吉里の解凍先フォルダ
  set KIRIKIRI_FOLDER="C:\kirikiri_kag"
  rem リリース対象のプロジェクトフォルダ（default.rpfがあること）
  set PROJECT_FOLDER="C:\MyProject"
  title %PROJECT_FOLDER% のバッチリリース
  if not exist %PROJECT_FOLDER%\default.rpf (
    echo エラー： %PROJECT_FOLDER%\default.rpf が見つかりません
    goto :SKIP
  )
  pushd %KIRIKIRI_FOLDER%\kirikiri2\tools
  krkrrel.exe %PROJECT_FOLDER% -go
  popd
:SKIP
  endlocal
  pause

コンソールの表示

コンソールを表示させるだけなら、以下のTJSスクリプト（ファイル名はconsole\startup.tjsとでもしておく）で充分。試しにTJS式を評価させてみる場合など意外と使える。

Debug.console.visible = Debug.controller.visible = true;

KAG3

タグで書くかTJSスクリプトで書くか

吉里吉里/KAGで凝ったことをしようとすると、すぐTJSスクリプトに頼らなければならないためか、定期的に「最適化の呪い」を受けた人（要するに費用対効果を無視している人）が現れるのでメモ。

TJSスクリプトで記述する価値のないモノ

タグで記述できるモノを、わざわざTJSスクリプトで記述する価値はない。
理由は以下の通り。

処理速度上のメリットがない
タグの解析にかかるコストの差など、トランジションなどの画像処理に比べたら無いに等しい。これを気にしている人は多いが、もっと広い視野で物事を考えた方が良い
テストにかかる工数を考慮していない
タグならテストも動作実績も充分に積み重ねられている。それをTJSスクリプトで記述すると言うことは、テストを１からやり直さなければならないということを意味する。貴重な工数はもっと重要な作業に割いた方が良い
KAGの前提に反する
元もとKAGはKAGシナリオファイルで制御する前提で設計・実装されている。TJSスクリプトでKAGを制御するのは、基本的にイリーガルな手段なのだという認識を持った方が良い

TJSスクリプトで記述する価値のあるモノ

以下のことに関してなら、TJSスクリプトで記述する価値がある。
KAGプラグインにするか、AfterInit.tjs、Override.tjsに記述することが望ましい（KAGそのものを改造するのは最後の手段）。

  • 現状のKAGでは実現できないモノ
    • 存在しない機能（タグ含む）を追加する
    • すでにある機能（タグ含む）を改造する
  • タグで記述するより、TJSスクリプトで記述した方が開発効率が高いモノ（処理速度と書いていないことに注目）
    • 複雑なデータ処理ルーチンを記述する
    • ミニゲームを組み込む

プロジェクトフォルダのKAGをバージョンアップするには

以下は、吉里吉里2/KAG3のインストール先がC:\kirikiri_kagフォルダ、
プロジェクトフォルダがC:\MyProjectだった場合の例である。
それ以外のフォルダにしている場合は、フォルダ名を読み替えること。

KAGを改造していない場合

  1. プロジェクトフォルダの以下のファイルを新しいKAGで上書きする
    • C:\kirikiri_kag\kag3\template\startup.tjsをC:\MyProjectに上書きコピーする
    • C:\kirikiri_kag\kag3\template\systemフォルダ内の全ファイルをC:\MyProject\systemフォルダに上書きコピーする
  2. 以下のいずれかの方法でC:\MyProject\system\Config.tjsをマージする
    • Config.~newとConfig.tjsの内容を比較し、差分をConfig.tjsに反映する
    • krkr.eXeを起動し、C:\MyProjectを開けば、マージするか問い合わせてくるので、この機能を使う
  3. C:\MyProject\system\Config.~newを削除する

KAGを改造している場合

  1. 以下のファイルの差分をC:\MyProject側のファイルにマージする
    • C:\kirikiri_kag\kag3\template\startup.tjsとC:\MyProject\startup.tjs
    • C:\kirikiri_kag\kag3\template\systemフォルダ内の全ファイルとC:\MyProject\systemフォルダ内の全ファイル（ただしConfig.tjsとConfig.~newを除く）
  2. 以下のいずれかの方法でC:\MyProject\system\Config.tjsをマージする
    • C:\kirikiri_kag\kag3\template\system\Config.~newとC:\MyProject\system\Config.tjsの内容を比較し、差分をConfig.tjsに反映する
    • krkr.eXeを起動し、C:\MyProjectを開けば、マージするか問い合わせてくるので、この機能を使う
  3. C:\MyProject\system\Config.~newを削除する

Override.tjsでKAGWindowのサブクラスを定義しkagオブジェクトを作る、AfterInit.tjsを活用する…といった方法なら、マージすることなく簡単にKAGをバージョンアップできる公算が高い。
KAGそのものを改造するのは最後の手段と考えた方が良い。*1

about.ksの制限事項

first.ksなどで定義したマクロは、about.ks内で使用できない。
about.ksでマクロを使用するには、再度about.ks内でマクロ定義する必要がある。
このため、マクロ定義を別のKAGシナリオファイル（サブルーチン）に分離しておき、first.ksとabout.ksから呼び出すと良い。

吉里吉里/KAG製ゲームをCDから起動するには

Config.tjsのreadOnlyModeをtrueに変更すれば、吉里吉里/KAG製ゲームをCDから起動することが可能。

ただし、バグが発覚した場合、パッチを当てることが出来ないという致命的な問題がある。
体験版ならともかく、正式版をCDから起動するような仕様にするのは避けた方が良い。

  • KAGを改造すればある程度まで問題を解消できるが、制作者・プレイヤー共に煩わしくなることに変わりはない
  • 修正版CDを配布するという手もあるが、コストが割に合わない
  • 「仕様」と言い張って無視する手もあるが、信用が失われるのは言うまでもない

また、ハードディスクとCD-ROMではデータの読み取り速度などに差がありすぎるため、パフォーマンスの大幅低下は避けられない。
データ量を減らしたり、吉里吉里設定（やコマンドラインオプション）である程度緩和できるだろうが、それ相応の試行錯誤が必要になる。

ロード直後の画像のちらつきを軽減

セーブ可能なラベルの後に背景・前景レイヤを切り替える（トランジション含む）ようなKAGシナリオは、ちらつきの原因になるので避けた方が良い。
過去ログ5822・9135も参照のこと。

[p]
*label|セーブ可能なラベル
[cm]
[image layer=base page=fore storage="背景"]
[image layer=0 page=fore storage="前景" visible=true pos=center]

上記のKAGシナリオの場合、「セーブ可能なラベル」でロードすると、以下のように処理される。

  1. 「セーブ可能なラベル」をロード
  2. それまで表示されていた（セーブ直前の）背景・前景が一瞬だけ表示される
  3. 「セーブ可能なラベル」の後の背景・前景が表示される

次のように記述すれば、ちらつきを防ぐことができる。
少なくとも背景の切り替えはセーブ可能なラベルより前に済ませておいた方が良い（ちらつきの影響が最も大きいため）。

[p]
[image layer=base page=fore storage="背景"]
[image layer=0 page=fore storage="前景" visible=true pos=center]
*label|セーブ可能なラベル
[cm]

前景レイヤのサイズが小さかったり、枚数が少なければ、セーブ可能なラベルの後で前景を切り替えても特に問題ない模様（この辺りはゲームの仕様次第か）。

前景用画像ファイルの運用

storage属性値は、画像ファイルに関してのみ拡張子を省略できるので、

  1. 制作中は前景用画像ファイル（立ち絵など）をPNG形式に揃えておく（確認しやすいので）
  2. storage属性値に前景用画像ファイルを指定する場合、拡張子は省略しておく
  3. ゲームが形になったら前景用画像ファイルを一斉にTLG6に変換、変換元の前景用画像ファイル（PNG形式）は削除してしまう

とすれば、KAGシナリオを修正することなく、前景用画像ファイルをTLG形式に差し換えることができる。
総ファイルサイズの低減や表示速度の向上が見込める。

*1 掲示板のやり取りでは、直接KAGを改造するような回答が多いため、誤解している人が多いかも知れない。