■SFC時代の組込スクリプト言語
 |
スクウェアでクロノ・トリガーやファイナルファンタジーVIIなどの開発に携わった小久保啓三氏（現、HAL東京）が、クロノ・トリガー開発の際に作成した、キャラクタ（アクター）の並列動作を記述できるスクリプト言語「ATEL（Active Time Event Language／エーテル）」の文法と内部動作等を解説しました。
ATELは、バッチファイルやBASICプログラムぐらいの難易度で、キャラクタ同士の並列的なインタラクションを記述できることを目標に開発された言語で、ミニオブジェクトとして自立的に動作する「アクター」を定義し、各アクターにインタラクションでの実際の動作を記述していくというものです。さらに、人海戦術で量産できるようにも注意が払われています。
フィールド上に散らばっているキャラクタをうまく動かしてイベントシーンにつなげていくという目標があったため、キャラクターの細かいコントロールも可能になっています。これは企画段階から、演出でバトルに入るところのアクションを楽しませたいというニーズが明らかだったため、それを実現できる言語が構築されました。こういった「ニーズを満たすために言語を作る」ことができるのもカスタムメイドなスクリプト言語のよさでしょう。
ただ、当時のスクリプターから「並列アクターモデルは従来の一連のイベントストーリーが書きにくい」と意見があり、「ディレクター」という仮想アクターを作って、全部コントロールするという運用も行われたそうです。
スクリプトで気をつけた点として小久保氏は、キーワードをわかりやすい日本語的単語にしたこと（加減算の表現にaddやsubtractではなくplusとminusを採用、など）、エラーや警告は早い段階でおこなったこと、エラーメッセージを丁寧かつ対処法まで含む形で記述したことなどをあげています。
さらに、実機でのドライバ（実行エンジン）で気をつけた点として、並列処理であるため、リクエスト完了待ち命令でアクター同士がお互いが待ってしまうハマリ（デッドロック）バグは起こるという前提で、開発用に強力な内蔵デバッガーをつけ、テレビ画面でアクターが何待ちかとかを表示するコードをつけ、発売後の対策として長時間のリクエスト待ちは自動解除する仕組みも持たせたとのことです。
本作は、イベントスクリプトが単にメッセージやキャラクタの移動を順番に書き並べるだけだった段階から、インタラクションの記述へと進化していく中で、重要な作品だったといえるでしょう。
■サクラ大戦Vでのスクリプト運用事例
 |
最近の作品からは、セガ第三CS研究開発部リードプログラマの秋葉晴樹氏が、サクラ大戦Vでのスクリプト運用事例を解説しました。
サクラ大戦Vでは、プログラマ向けの「サクラスクリプト」と、プリプロセッサによってサクラスクリプトに変換可能な「マクロ形式」の2種類のスクリプトが使われました。
サクラスクリプトはmallocやfreeのないC言語といった言語で、独自の関数を記述することで再利用可能なツールをスクリプターが整備していける言語です。背景描画のコマンド、キャラクタを信頼度が高い順番に並べ替えるコマンド、売店でブロマイドを購入するシーケンスを実行するモジュールなどがスクリプトで書かれたとのことです。
サクラスクリプトの特徴は、スクリプトからは変数を確保できないという言語仕様の制限にあります。使えるのはフラグ領域と呼ばれるあらかじめ与えられた固定長配列のみで、複数回のプレイで引き継がれるシステムフラグ（256個）、そのプレイで引き継がれるゲームフラグ（256個）、スクリプトモジュルが終了すると消えるワークフラグ（128個）と、データのライフサイクルによって3つが用意されています。スクリプト言語というとVMがメモリ管理をするから自由に変数を作れるというイメージがありますが、秋葉氏は、サクラ大戦シリーズのようなシナリオ型ゲームでは、フラグ操作ミスが深刻なエラーや進行不能バグに結びつきやすく、しかもスクリプトで自由に変数を作らせているとバグの箇所がスクリプトに埋没するおそれが高いと指摘しています。
サクラスクリプトは制限が強い一方で、フラグチェック機能を充実させ、開発支援の機能として、フラグが書き変わると画面にポップアップ表示したり、書き込み履歴をログとして保存するようになっていたということです。秋葉氏は、「フラグという考え方は古くさいかも。でも、スクリプトで勝手にやられてバグチェックするのが大変になるより、管理できた方がいい」とコメント。この意見に同意する開発者は少なくないのではないでしょうか。
一方、シナリオ担当者向けの、簡易なマークアップ言語としての「マクロ形式」は、シナリオ担当者にメッセージに専念してもらうための書式で、マクロからスクリプトへの変換ツールを用意することでゲームへ取り込むというものでした。ただ、このマクロの文法は非常にあいまいで、キーワードが全角だったり半角だったり、多少の誤字脱字は許容してほしい、ID未発行のリソースを指示した場合でもなんとなく良い感じにしてほしい、といった要望があり、これに応えるため開発チームでは置換ルールを外に切り出して置換専用の簡易言語を実装したということです。
 |  |
また、イベントの発生管理をスクリプトからExcelに移すといった「適材適所」がおこなわれていたことも披露されました。サクラV以前は、移動マップでのイベント判定とシナリオ分岐をスクリプトで記述していたとのことですが、イベント判定スクリプトが巨大化複雑化したり、イベント仕様書とスクリプトが分離して、場合によってはデバッガーに「その場面は仕様書は無視して。ゲームの方が正しいから」と指示するような事態にもなっていたそうです。
このため、イベントリストをExcelで一元管理するようにし、条件分岐入力もVBAマクロのダイアログでおこなうように準備をおこなったとのこと。利点として、イベント管理にスクリプトの知識が不要になり、しかもスプレッドシートなのでイベント発生条件が一覧で印刷可能となります。欠点としてVBAが使いづらいというのがある
秋葉氏は、スクリプト言語を自作するメリットについて、プロジェクトにあわせてカスタマイズできることをあげています。一方で、スクリプトで全部作ろうとしない（イベント管理はExcelでおこなうなど）、スクリプトで何でもやろうとしない、重要な要素をスクリプトの中に隠させない、といった運用上の注意点も指摘していました。
質疑応答では、「最近はExcelでシナリオを書いてしまうケースもあるが、今あらためてサクラ大戦を作るとしたらどういう構成にするか？」という問いに対して、「すべてのシナリオライターにExcelで書くのを求めることは難しい。しかもテキストが5MBといった規模になるのでExcelでは難しいかも。次もこういう形（スクリプト＋マクロ形式）になるのかな」と答えていました。
■汎用スクリプト言語を一から作成する「Xtal」
 |
バンダイナムコゲームスの石橋立宣氏は、「汎用スクリプト言語Xtal設計と実装」と題して、自身がプライベートで開発している「Xtal（クリスタル）」の特徴や実装上のポイントなどについて講演を行いました。
Xtalは、「ツール作成をRubyでやってサクサク書けてびっくり。ゲームもスクリプトでさくさく書きたい！」と開発がスタートし、さらに「Luaの置き換えをねらった」というオープンソースの汎用スクリプト言語エンジンで、MITライセンスで商用も可能となっています。石橋氏は「将来、もっとゆるくして組み込みやすくします！」と宣言しておられたので、商用タイトルで使いにくくなることはなさそうです。
ゲームに適した組み込みスクリプトエンジンとしてすでに「Lua」がありますが、これについて石橋氏は、「未定義変数の扱いがひどい。グローバル変数で苦しんだ」「C、C++との微妙な違いが僕を苦しめた。配列添え字が1で始まる、ブロックが｛｝じゃない、コメント書式が違う」と、自分で作ろうと思うに至った経緯を披露。欲しい言語は「Luaのような組み込み性、Ruby、Pythonのような人気のスクリプト言語機能、Cライクな構文」なのだと語り、XtalがLuaから差別化しようとしているポイントをまとめています。本音レベルでは「ただ言語を作りたかったから」とも語っていましたが、CやC++に書式が近い実用的な組み込みスクリプトがほしいというのは誰しも思うところではないでしょうか。
実装については、字句解析はYaccなどは使わず完全手書き。Boost.Spiritで書いてみたらコンパイル時間が激増したためやめた、とも述べています。字句解析や構文解析については、「その先（バイトコード処理など）が大変。字句解析は手書きで十分」とのこと。
石橋氏は、Xtalの欠点として「実績がほぼゼロ」「実行ファイルのサイズがまだLuaより大きい」「実行速度も、ものによってはLuaに負けてる」「テストもドキュメントも不足」「デバッガ未整備」といったポイントを自ら挙げています。特にドキュメントとテスト、デバッガは業務で使う場合に求められるなので、ここが準備されると採用例も出てきそうです。
まさに開発中のエンジンということで、質疑応答では「スクリプトのモデル検証をやりたい。命令ツリー、解析ツリーを出す機能欲しい。バイトコードのニモニック形式を出して欲しい」といった要望が出され、石橋氏からも、前向きな感じの「検討します」という回答が出されていました。
「自作言語の実装で難しいところは？」との問いには、「コード生成のあたり。構文木をバイトコードに直すところ。仮想マシンを高速に動く構造にするため、3回ぐらい作り直した。作り直した後、前の方が速かったかも、とか思ったこともありましたが（苦笑）」と回答、さらに「エラーメッセージの国際化は可能か？」との質問には、「gettext風のシステムを組み込んであります。英語にトランスレートしてくれる人募集中です（笑）」と答えていました。
処理系は、しばしば専用言語と汎用言語の間で揺れ動くもの。「決定版のスクリプト言語が出来たらそれを採用するよ」というスタンスよりも、「それなりに安定しててトライアンドエラーがしやすい言語なら、LuaでもXtalでもCRI Scriptでも、とにかく使ってみよう」「いや、自分で作ってもいいし」というぐらいの感じで挑戦してみるのがよいのかもしれませんね。
