吉里吉里2(TJS2)
辞書配列の内容を配列にコピー
Array.assign()に辞書配列オブジェクトを渡せば、キーと値が交互に並ぶ配列が得られる(キーと値のペアの順序は入れ替わる可能性がある)。
var dic = %["red"=>0xff0000, "green"=>0x00ff00, "blue"=>0x0000ff]; var arr = []; arr.assign(dic); // キー☆、値☆、キー◎、値◎、キー△、値△…の配列になる
配列の内容を辞書配列にコピー
逆に、Dictionary.assign()に配列オブジェクトを渡せば、要素0=>要素1、要素2=>要素3…となる辞書配列が得られる。
var arr = ["red", 0xff0000, "green", 0x00ff00, "blue", 0x0000ff]; var dic = %[]; (Dictionary.assign incontextof dic)(arr); // 要素0=>要素1、要素2=>要素3…の辞書配列になる
Arrayクラスにスタックのメソッドを追加
startup.tjsの先頭に、以下の2行を追加する。
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();
メッセージマップの書き換え
本来は多言語対応のための機能だが、メッセージを関西弁にするといったお遊びにも使える。
メッセージマップの出力
- 吉里吉里を起動し、Shift+F1でコントローラを表示
- コントローラ上でマウス右クリックし、コンテキストメニューから「メッセージマップファイルの作成」を選択
- 吉里吉里(krkr.eXeまたはそれをリネームしたもの)と同じフォルダにmsgmap.tjsを保存する
メッセージマップの書き換え
- テキストエディタでmsgmap.tjs内のメッセージを書き換え、上書き保存する
- 以降、吉里吉里を起動すると、この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スクリプトで記述すると言うことは、テストを1からやり直さなければならないということを意味する。貴重な工数はもっと重要な作業に割いた方が良い
- KAGの前提に反する
- 元もとKAGはKAGシナリオファイルで制御する前提で設計・実装されている。TJSスクリプトでKAGを制御するのは、基本的にイリーガルな手段なのだという認識を持った方が良い
TJSスクリプトで記述する価値のあるモノ
以下のことに関してなら、TJSスクリプトで記述する価値がある。
KAGプラグインにするか、AfterInit.tjs、Override.tjsに記述することが望ましい(KAGそのものを改造するのは最後の手段)。
- 現状のKAGでは実現できないモノ
- 存在しない機能(タグ含む)を追加する
- すでにある機能(タグ含む)を改造する
- タグで記述するより、TJSスクリプトで記述した方が開発効率が高いモノ(処理速度と書いていないことに注目)
- 複雑なデータ処理ルーチンを記述する
- ミニゲームを組み込む
プロジェクトフォルダのKAGをバージョンアップするには
以下は、吉里吉里2/KAG3のインストール先がC:\kirikiri_kagフォルダ、
プロジェクトフォルダがC:\MyProjectだった場合の例である。
それ以外のフォルダにしている場合は、フォルダ名を読み替えること。
KAGを改造していない場合
- プロジェクトフォルダの以下のファイルを新しいKAGで上書きする
- C:\kirikiri_kag\kag3\template\startup.tjsをC:\MyProjectに上書きコピーする
- C:\kirikiri_kag\kag3\template\systemフォルダ内の全ファイルをC:\MyProject\systemフォルダに上書きコピーする
- 以下のいずれかの方法でC:\MyProject\system\Config.tjsをマージする
- Config.~newとConfig.tjsの内容を比較し、差分をConfig.tjsに反映する
- krkr.eXeを起動し、C:\MyProjectを開けば、マージするか問い合わせてくるので、この機能を使う
- C:\MyProject\system\Config.~newを削除する
KAGを改造している場合
- 以下のファイルの差分を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を除く)
- 以下のいずれかの方法でC:\MyProject\system\Config.tjsをマージする
- C:\kirikiri_kag\kag3\template\system\Config.~newとC:\MyProject\system\Config.tjsの内容を比較し、差分をConfig.tjsに反映する
- krkr.eXeを起動し、C:\MyProjectを開けば、マージするか問い合わせてくるので、この機能を使う
- 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シナリオの場合、「セーブ可能なラベル」でロードすると、以下のように処理される。
- 「セーブ可能なラベル」をロード
- それまで表示されていた(セーブ直前の)背景・前景が一瞬だけ表示される
- 「セーブ可能なラベル」の後の背景・前景が表示される
次のように記述すれば、ちらつきを防ぐことができる。
少なくとも背景の切り替えはセーブ可能なラベルより前に済ませておいた方が良い(ちらつきの影響が最も大きいため)。
[p] [image layer=base page=fore storage="背景"] [image layer=0 page=fore storage="前景" visible=true pos=center] *label|セーブ可能なラベル [cm]
前景レイヤのサイズが小さかったり、枚数が少なければ、セーブ可能なラベルの後で前景を切り替えても特に問題ない模様(この辺りはゲームの仕様次第か)。
前景用画像ファイルの運用
storage属性値は、画像ファイルに関してのみ拡張子を省略できるので、
- 制作中は前景用画像ファイル(立ち絵など)をPNG形式に揃えておく(確認しやすいので)
- storage属性値に前景用画像ファイルを指定する場合、拡張子は省略しておく
- ゲームが形になったら前景用画像ファイルを一斉にTLG6に変換、変換元の前景用画像ファイル(PNG形式)は削除してしまう
とすれば、KAGシナリオを修正することなく、前景用画像ファイルをTLG形式に差し換えることができる。
総ファイルサイズの低減や表示速度の向上が見込める。