日本最高のエンジニアblog、Radium Software developmentの過去ログを読んでいたら２００１年の過去ログでゲームのスクリプト制御の話があった。
動機については以下のようにまとめている。
ゲーム制御の設計／実装の作業をプログラマの外に出すという目的だ。RPGやアドベンチャーゲームなんかでは，イベント制御やNPC制御，UI制御やフラグ管理など，そういった雑多な処理が大量に発生するんだけど，これらすべてをプログラマがプログラム内で実装するってわけにはいかないので，これらの仕事をデザイナー／プランナーに引き渡すために，スクリプト制御の仕組みが必要になることがある。
ここでスクリプトとは、イベントとか、簡単な制御を処理するフレームワークみたいなものが定義されていて、それに適切な変数を与えることで、制御の構造を簡単に記述できるみたいなものを考えている。しかし、この部分は自由度が高すぎると、逆に恐ろしいコードを非エンジニアが書く原因になってしまうため、綿密に仕様を定義してあげると述べている。
たぶん、今の感覚だと、すぐにじゃーイベント定義はXMLでって話になると思うけど、そういう枠組みよりも違うスクリプト言語というアプローチを指向したのがおもしろい。
第２の動機として、イベントとかの定義をビルドの必要なソースから、スクリプト系の外にだすことがあげられている。なにかの変更がメインブランチに影響を与えてしまうとそのたびにリビルドが必要になりめんどくさい。そういう意味で、バイトコードを処理し、動的に実行をおこなうスクリプトはありがたい。この、バリッドなシステムなどにスクリプトって、どうなの？って、話は当然生まれてくるが、実際、おもしろい例として、Rubyの開発者まつもとひろゆきさんの日記で、海底探査機に搭載されたRubyの例が載っている。Rubyが選ばれた理由として、ソースコードがわかりやすいこと、コアが小さいことがあげられているが、これも2001年にはきちんとしては存在してないので、まー、あれですね。今、思えばってことですね。
しかし、あるフレームワークというかライブラリーを用意しておいて、イベントとか、変更が起きやすい部分はRubyでっていうのは、すごい魅力的な提案である。コアの小ささ的にも申し分ないし。スクリプト制御の取り込み、インターフェースにFlashなどを利用可能など、開発の労力を減らせる取り組みっていうのはいくらでも存在すると思うので、いろいろ考えてみたい。