現状で理想のゲームスクリプト仕様は？
昨晩の続きだが、将来に備えて「プログラミング言語を作る」レベルの取り組みは絶対に続けるべき。しかし、現状のレベルでは、単体で完成されたプログラム言語を駆使するのではなく、イベントドリブンやコールバック主体に処理してゆくやり方が相性がよいと思う。スクリプトファイルの上から実行を開始して、下まで走るのではなく、ゲームエンジン（ゲームシステムプログラム）が特定の状況で、紐付けられたスクリプト関数側にパラメータを渡してコールバックする。ゲームエンジンがタイトル向けに特化あるいはチューンされていることが前提*1だが、このやり方はアクションゲームでも通用する。
今のLuaやポストLuaの組み込みスクリプトは、スクリプトの関数やクラスを C++ 側にバインドする考え方が主になっている。そのバインドはかなり直接的で、実体のアドレスにアプローチしたいというプログラマの本能に沿っている。
これはこれで本当に役に立つし、C++側がスクリプトシステムに依存しない（何者かにコールされるのを待つ存在）ので、モジュール設計もシンプルになる。しかし、このバインディングは、企画さんが触る仕様としては、メインの使い方にしてはいけないような気がする。逆に、C++側がスクリプトに依存関係を持って、特定処理をデリゲートするような、ある処理に関してC++とスクリプトがアスペクト指向っぽくアプローチできるような関係になっているほうが上手くいくのではないだろうか。
また、バインドは密な結合で、究極的にはスクリプトのビルトインやバインドシステムは、C++インスタンスのメモリ上の番地を直接掴んでメンバ関数やメンバ変数にアプローチする。これはスクリプト側にメインがある時は理にかなっているが、コールバック主体でいくなら、仮想マシンとゲームエンジン側が（時には非同期に）サービス間通信を行う機構を備えていれば、互いの強い参照を避けることができる。
バインドに比べれば複雑になるが仮想マシンにメッセージ処理機構があれば気にせずに済むし、C++側の各モジュールがスクリプトエンジンの詳細を知っているよりずっといい。それに、GCのあるスクリプト言語と、GCのないC++側の事情を考えると、スクリプト言語側がC++のインスタンスにダイレクトアクセスせずに済めばそれだけ色々楽になる。
LuaはポストPythonであり、その基本感覚は、アプリがガッツリ固まった後でも、C++を触っているレベルの調整や拡張を提供できる……というものだと思う。しかしゲームの場合は、現行の第７世代機のようなPCと比較して余裕のないハードウェア上で、時にフルHD60fpsのリアルタイムアプリをスクリプトと「協調して」動かさなくてはいけない。
パフォーマンスと企画さん重視だったゲーム製作スクリプトのノウハウと、組み込み言語の汎用性を合体できれば一番いい。ところが第５世代、第６世代のゲーム製作スクリプトがハードの事情で物凄く酷かったので、企画さんもプログラマもLuaのような単体完結のスクリプト言語を組み込む方へダーッと行ったのではないか。いや完璧にその中の一人なんですけど。
まぁ要は、未来に向けて進化を続けるゲームスクリプト言語を（VMを弄ってでも）どう組み込むかという話です。それでゲーム製作スクリプト的な良いところと、組み込みスクリプトの汎用性が生かせれば一番いい。
