昔会社の先輩が開発したというスクリプトエンジンを見せてもらった。
文法がどう見てもCにしか見えないけど、日本語が使えたりコルーチンが使えたりするらしい。
プリプロセッサまで使える、どう見てもCじゃん。

スクリプト側で呼び出すとシステム側の各マネージャーが処理して内部で勝手に破棄したりするつくりらしく、
実際のソース部分こそものすごく少ないものの、スクリプト自体は何百個ものファイル数。。。

そのためシステムバグはほとんどデバッグ中も来なかったらしく、
ゲームバランスの調整などに時間が使えたため、非常にクオリティの高い作品になったらしい。

スクリプトに追い出すことでビルド時間が圧倒的に減り、誰でもいじることが可能であり
直しもききやすくガンガン仕様変更があってもすぐに対応できたとのこと。

私もインタプリタの勉強を以前やっていたけどまだまだ不十分なので
今の仕事が終わったらまた勉強したい


ちょっと仕事中に見せてもらってすごく感動したため日記に書きます。

ほとんどスクリプトに追い出すくらいなら最初っからインタプリタ言語で開発すればよかったんじゃ・・・・

メモリ制限のキツイ環境ではスクリプトもコンパイルして中間コードに落としてパッケージしないと動かせないのでビルド時間の短縮というのはあまり実感なかったりします。
コンパイル時に文法などのチェックができるのでそちらのほうがよりメリットがあると感じますけど。
規模の大きいものでもリバースエンジニアリング対策でスクリプトのソースコードそのまま収納はないはず。

インタプリタ言語だと実行するまでエラーが分からなかったり、ゲーム仕様に準じた識別子のチェックとか入れると二度手間だったりしますしね。
独自にインタプリタを開発するメリットは少なからずあります。
汎用目指すのでなければインタプリタ作るのもさほど難しくないですし。

プリプロセッサはCの処理系に付いてるのをそのまま呼び出して使えるので新規で作ってはいないのでは？
わたしはケータイアプリの開発でJavaのソースコードをプリプロセッサ通したりもしてましたし。
IApplicationとMIDletの切り替えとか諸々ヘッダファイルにまとめてソースコードを共通化してました。

新月獅子さん
僕も同じようにJavaのインタプリタとか入れたらいいんじゃないですか？
って聞いたことはありますね。
ちょっと微妙な反応でしたけどやっぱり他所の人の作ったライブラリやフレームワークが信用できないんだろうなって思います。
というと結構表現悪いんですけど、現実問題プロジェクト内での権利問題だとかそのライブラリにもしバグがあった場合、それが開発に影響がでたとして誰の責任になるのかとか。

あとはそういうフレームワークを利用する場合ってちゃんとプロジェクトの一番偉い人に話しとおさなきゃいけなかったりなので
常にやりたいようにできる保証はないです。
そのへんの企業間の問題は結構面倒事なのでそのへんのリスクは負いたくないんだろうな～と話してて思いました。

ISLeさん
文法チェックがあったかは見てないのでわからないのですが
膨大な数のデータを扱うならばやっぱりスクリプトで追い出すというのはあるみたいですね。
スクリプトはアセンブリコードに吐き出してそれを実行していく、という感じだったのでソースを直接入れることは絶対ないと思います。