April 18, 2009 - Keizo Kokubo Interview

General Information[edit]

https://www.inside-games.jp/article/2009/04/21/34870.html

Japanese[edit]

ゲームで使うためのスクリプト言語開発とは〜 IGDA日本SIG-GTレポート

4月18日に、IGDA日本のSIG-GT第13回セミナー、「続・ゲームにおけるスクリプト言語の現状」が開催されました。ゲーム開発でのスクリプト活用事例とともに、組み込みスクリプト言語の開発についても講演がおこなわれ、クロノ・トリガーやサクラ大戦Vでの事例、さらに現在開発が進んでいるオープンソースの「Xtal（クリスタル）」の開発舞台裏などが紹介されました。

ゲームビジネスその他

2009.4.21 Tue 12:44

■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でも、とにかく使ってみよう」「いや、自分で作ってもいいし」というぐらいの感じで挑戦してみるのがよいのかもしれませんね。

English[edit]

Scripting Language Development for Use in Games ~ IGDA Japan SIG-GT Report

On April 18, IGDA Japan's SIG-GT 13th Seminar, "The State of Scripting Languages in Games," was held. The seminar featured examples of scripting in game development, as well as talks on the development of embedded scripting languages, including Chrono Trigger and Sakura Wars V, and a behind-the-scenes look at the development of the open source "Xtal" (Crystal), which is currently under development.

Game Business Others

2009.4.21 Tue 12:44

IGDA Japan's SIG-GT 13th Seminar, "The State of Scripting Languages in Games," was held on April 18. The seminar featured talks on the development of embedded scripting languages as well as examples of scripts used in game development, including Chrono Trigger and Sakura Taisen V, and a behind-the-scenes look at the development of the open-source Xtal (Crystal), which is currently under development.

Embedded Script Language in the SFC Era

Mr. Keizo Kokubo (now at HAL Tokyo), who was involved in the development of Chrono Trigger and Final Fantasy VII at Square, introduced ATEL (Active Time Event Language), a scripting language that can describe parallel actions of characters (actors), which he created during the development of Chrono Trigger. ATEL (Active Time Event Language/ether), a scripting language created during the development of Chrono Trigger that can describe the parallel actions of characters (actors), and its internal operations.

ATEL was developed with the goal of describing parallel interactions between characters with a level of difficulty equivalent to that of a batch file or BASIC program. The language was developed with the goal of describing interactions in a way that can be mass-produced by human labor. Furthermore, care has been taken to ensure that the system can be mass-produced by sea.

Since the goal was to successfully move characters scattered across the field and connect them to event scenes, fine control of the characters was also possible. From the planning stage, there was a clear need for the audience to be able to enjoy the action of entering the battle scene in the production, so a language was constructed to make this possible. The ability to "create a language to meet a need" like this is one of the advantages of a custom-made scripting language.

However, some of the scriptors at the time commented that the parallel actor model made it difficult to write a conventional series of event stories, so they created a virtual actor called "director" to control all of the events.

Mr. Kokubo mentioned the following points that were carefully considered in the script: keywords were used in Japanese that were easy to understand (e.g., plus and minus were used instead of add and subtract for addition and subtraction), errors and warnings were given early on, and error messages were written in a polite manner and included instructions on how to deal with the situation. error messages carefully and with instructions on how to deal with them.

In addition, as points to be careful about the driver (execution engine) on the actual device, we installed a powerful built-in debugger for development on the assumption that a deadlock bug, in which actors wait for each other in the request completion wait instruction, would occur because of parallel processing, and added code to display on the TV screen how many actors are waiting for each other. In addition, a code was added to display on the TV screen how many actors are waiting, and as a countermeasure after the release of the product, a mechanism was added to automatically cancel requests that have been waiting for a long period of time.

This work was important in the evolution of event scripts from simply writing messages and character movements in sequence to describing interactions.

■Example of Script Operation in Sakura Wars V

Haruki Akiba, Lead Programmer of Sega's 3rd CS Research and Development Department, explained an example of script operation in Sakura Taisen V, a recent work.

Two types of scripts were used in Sakura Taisen V: "Sakura Script" for programmers and "Macro Format" which can be converted to Sakura Script by a preprocessor.

SakuraScript is a language such as C without malloc or free, which allows scripters to maintain reusable tools by writing their own functions. Commands for drawing backgrounds, sorting characters in order of trustworthiness, and a module for executing a sequence to purchase bromides at a kiosk were written in scripts.

A unique feature of Sakura scripts is the limitation of the language specification that variables cannot be allocated from scripts. Only a pre-given fixed-length array called the flag area can be used, and three types of data are available: system flags (256) that are inherited by multiple plays, game flags (256) that are inherited by that play, and work flags (128) that disappear when the script module ends. Three are available depending on the life cycle of the data. The scripting language gives the impression that the VM manages memory so you can create variables freely, but Akiba said that in scenario-type games such as the Sakura Wars series, flag manipulation errors can easily lead to serious errors and progression failure bugs, and that the scripts allow you to create variables freely. He points out that there is a high risk that the location of the bug will be buried in the script.

While Sakura scripts are highly restrictive, they also have an enhanced flag checking function, and as a development support function, they display a pop-up on the screen when a flag is rewritten and save the writing history as a log. Mr. Akiba said, "The idea of flags may be old-fashioned. But it is better to be able to manage them than to have a script do it on its own and make it hard to check for bugs," he commented. Many developers may agree with this opinion.

On the other hand, the "macro format," a simple markup language for scenarists, was a format that allowed scenarists to concentrate on their messages, and was incorporated into the game by providing a macro-to-script conversion tool. However, the syntax of this macro was very ambiguous, and there were requests that keywords be full-width or half-width, that a few misspellings be allowed, and that the message be somewhat nice even if it directed a resource for which an ID had not yet been issued. In response to this request, the development team cut out the substitution rules and implemented a simple language dedicated to substitution.

He also showed how the right people were being put to work, such as moving the event management from scripts to Excel. Before Sakura V, the event judgment and scenario branching on the movement map were written in scripts, but the event judgment scripts became huge and complex, and the event specifications and scripts were separated. In some cases, the scripts became so large and complex that they had to tell the debugger, "Ignore the specifications for that scene, because the game is more correct.

To solve this problem, they prepared to manage the event list centrally in Excel and to input conditional branching in a VBA macro dialog. The advantage is that no scripting knowledge is required to manage the events, and the spreadsheet makes it possible to print out a list of the conditions under which events occur. The disadvantage is that VBA is difficult to use.

Mr. Akiba points out that the advantage of creating your own scripting language is that you can customize it to suit your project. On the other hand, he also pointed out operational considerations, such as not trying to create everything in scripts (e.g., using Excel for event management), not trying to do everything in scripts, and not hiding important elements in scripts.

During the Q&A session, he was asked, "Recently, some scenarios are written in Excel, but if you were to create Sakura Wars again today, how would you structure it? In response to the question, "It is difficult to ask all scenario writers to write in Excel. Moreover, it may be difficult to use Excel because the text is 5MB in size. I wonder if the next version will be in this form (script + macro format).

Xtal," a general-purpose scripting language created from scratch

Mr. Tatsunobu Ishibashi of NAMCO BANDAI Games Inc. gave a presentation titled "Design and Implementation of Xtal, a General-purpose Scripting Language," in which he discussed the features and implementation points of Xtal, which he is developing privately.

Xtal is a scripting language that is used to create tools in Ruby, and I was surprised at how quickly and easily it could be written. I want to write games quickly and easily with scripts! Xtal is an open source general-purpose scripting language engine that "aims to replace Lua," and is commercially available under the MIT license. Mr. Ishibashi declared, "In the future, we will make it looser and easier to embed! It seems that it will not be difficult to use it for commercial titles.

Lua" is already available as an embedded scripting engine suitable for games, but Mr. Ishibashi said, "Lua's handling of undefined variables is terrible. I suffered with global variables," and "subtle differences from C and C++ made me suffer. Array subscripts start with 1, blocks are not {}, and comment formatting is different," he said, showing how he came to the decision to create his own. He said that the language he wanted was "embeddability like Lua, popular scripting language features like Ruby and Python, and C-like syntax," summarizing the points where Xtal is trying to differentiate itself from Lua. He also said that at a genuine level, "I just wanted to create a language," but I think everyone would like to have practical embedded scripting that is similar in format to C and C++.

He also stated that he wrote the lexical analysis completely by hand, without using Yacc, etc. He tried writing the script in Boost.Spirit, but the compile time increased dramatically, so he gave up on it. As for lexical analysis and parsing, he says, "It's hard to go beyond that (e.g., byte code processing). Handwriting is sufficient for lexical analysis.

Mr. Ishibashi himself cited the following points as shortcomings of Xtal: "We have almost no experience with Xtal," "The executable file size is still larger than Lua," "Execution speed is also inferior to Lua in some cases," "Lack of testing and documentation," and "Debugger is not yet developed. In particular, documentation, testing, and a debugger are required for business use, so if these are prepared, it is likely that there will be more cases of adoption.

In the Q&A session, he said, "I would like to do model verification of scripts. I want a function to generate an instruction tree and analysis tree. Mr. Ishibashi responded in a positive manner, "We will consider it.

When asked, "What are the difficulties in implementing a home-grown language?" Mr. Ishibashi responded, "Around code generation. The part of converting syntax trees into bytecode. I had to rebuild the virtual machine three times in order to make it run at high speed. After reworking, there were times when I wondered if the previous version would have been faster. I have a gettext-like system built into the system. We are looking for someone who can translate them into English (laugh).

Processing systems often oscillate between dedicated and general-purpose languages. Rather than taking the stance of "If a definitive scripting language is developed, I will adopt it," it may be better to try a language that is reasonably stable and easy to try and error, such as Lua, Xtal, or CRI Script, or even create your own. It might be a good idea to try it out.

From: Interviews