…だと個人的に考えているモノ(各自の考えでアレンジすれば良いだろう)。デバッグに関してはデバッグに関するTIPSを参照。
Config.tjs編
- saveMacros(栞にマクロの情報を保存するかどうか)はfalseにする
- マクロ定義自体に不具合があった場合、パッチでマクロ定義を修正するだけで済む
- type(BGM再生メディア)はWaveにする
- MIDIは再生環境に依存しやすくトラブルの元
- Windows Vista以降、MIDIマッパー機能が廃止され、ますます使いにくくなった
- CD-DAはメディアをドライブに挿入せねばならず煩わしい。ノートパソコンにはCD/DVDドライブを内蔵していない機種もある
- 音声ファイルはWAVEかOgg Vorvis形式のいずれか。今のパソコンのスペックを考えたらOgg Vorvis形式で問題なし
- MIDIは再生環境に依存しやすくトラブルの元
KAGシナリオファイル編
- copylayタグは重ね合わせ順(index属性値)までコピーすることに注意する
- iscript~endscriptタグ内にテストの済んでないTJSスクリプトを記述するのは避ける。また、iscript~endscriptタグ内に大量のTJSスクリプトを記述するのは避ける
- iscript~endscriptタグ内でエラーが発生しても、何行目で発生したのかすぐに判らないため
- laycountタグは可能な限り使わない
- 特定のルートで前景レイヤの数が合わず、エラーに…という事態が防げる
- videoタグのmode属性ではlayerを指定する(レイヤモードを使う)。下表も参照
- 再生負荷が気になる場合はミキサーモードを使うと良い。なお、最新版の吉里吉里/KAGで、かつDirectX 9以降がインストールされている環境下なら、mode属性にoverlayを指定しても内部的にはmixerで動作している(ちょっとややこしい)
- コンフィグ画面で描画モード(レイヤとミキサー)を変更できるのが理想か
- 再生負荷が気になる場合はミキサーモードを使うと良い。なお、最新版の吉里吉里/KAGで、かつDirectX 9以降がインストールされている環境下なら、mode属性にoverlayを指定しても内部的にはmixerで動作している(ちょっとややこしい)
- セーブ可能なラベルで「*|」形式は使わない
- パッチを当てたときセーブデータの互換性が損なわれやすくなる
- 同じ理由でどこでもセーブプラグインの類も使わない
- ラベル名を振るのが面倒ならツールを使って自動生成するのが楽
- パッチを当てたときセーブデータの互換性が損なわれやすくなる
- マクロ(やサブルーチン)を駆使して記述量を少しでも減らす
- [[背景、立ち絵の切り替えはセーブ可能なラベルより前に済ませる>四方山話//小ネタ/]]
- ロード直後、一瞬だけ違う画像が表示されるのを防げる
- パッチを当てた際、セーブデータの互換性が保てるようにする
- サブルーチン内にセーブ可能なラベルを記述しない
mode属性 | メリット | デメリット | 備考 |
layer | 最も安定して動作する | 再生負荷が大きい | |
mixer | layerに較べて再生負荷が小さい | 古いパソコン(目安としてはXPより前のパソコンでDirectX 9より前のグラフィックボードのもの)では再生できないときがある | タグリファレンスに詳しく書かれていない |
overlay | 古いパソコン(目安としてはPentium 4以前)では再生負荷が小さい | Vista以降では上下反転で再生したり、ジャギーになる不具合が発生しやすい | グラフィックボードのドライバを最新にすると直る可能性あり |
パッチ編
- 既存のセーブ可能なラベルは削除しない
- セーブデータの互換性が失われるため
- パッチで新しいシステム変数、ゲーム変数を追加した場合、事前にvoidかどうか確認するなどして、パッチ適用前のセーブデータと適用後のセーブデータのどちらも動作するよう配慮する
- Config.tjsのsaveMacrosがtrueの場合、既存のマクロ定義内容を変更しない
- もしマクロ定義そのものに不具合があった場合、そのマクロを使用しているKAGシナリオファイル全てがパッチの対象になるので、saveMacrosはfalseにした方が楽
素材編
- 立ち絵、ボタンなどの画像素材はαチャンネル付きTLGかαチャンネル付きPNGにする
- 今どきマスク画像ファイルを使うなど有り得ない
配布編
- xp3形式でリリースする
- exe形式でリリースすると、吉里吉里コアに不具合があったとき、パッチ適用が面倒になる
- ただし、体験版の配布ならexe形式でリリースするのはアリだと思う
- exe形式でリリースすると、吉里吉里コアに不具合があったとき、パッチ適用が面倒になる
- エンジン設定(エンドユーザー向けの)、ファイル破損チェックツールは必ず同梱。もちろん署名もしておく
- 同梱しないと吉里吉里/KAGのアドバンテージは失われる
- ゲーム本体を%ProgramFiles%(通常はC:\Program Files)フォルダ以下にインストールする前提の場合、吉里吉里設定(krkrconf.exe)でデータ保存場所(-datapath)を$(appdatapath)、$(personalpath)、$(vistapath)のいずれかに設定する
- CD/DVDで配布する場合、インストーラ本体(プログラム)とキャビネットファイル(圧縮アーカイブファイル)は分離する
- 一体化させてインストーラ本体のファイルサイズが巨大になると、オートランでもたつくため
開発運用編
- 開発ツールはしっかりと選定する
- ツールの良し悪しや、どの程度使いこなせているかで開発効率はガラッと変わる
- テキストエディタにメモ帳とか論外
- 特にインストーラ作成ツールの選定は念入りに行う
- 作りの甘いインストーラ作成ツールが多数公開されている(フリーのモノに多い)。ましてインストーラ作成ツールを自作するなどもってのほか
- 開発中はConfig.tjsのdebugMenu.visibleをtrueにする(リリース時にはfalseに戻す)
- バージョン管理システムを使ってバージョン管理する
- リリース、署名などの定型作業は自動化する
- Perl、Rubyなど何でも構わないからスクリプト言語を一つ習得しておくと有利