ゲーム開発で独自言語が生まれるわけ
続:ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ? - kなんとかの日記
トラックバックを頂いていたことに、W.Deeさんの日記経由で上記記事を見て初めて気づいた体たらくなわけですが。話題は「ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ？」というお話です。
さて、周辺議論でも指摘されていますが、この場合の「言語」というのが何を指しているかをはっきりさせないと議論がかみ合いません。そこらへんから整理してみようかと思います。
まず、ゲームで使われる言語には、次のような種類のものがあります。実機上で動くバイナリを作成するためのプログラミング言語、開発 PC 上でプロジェクトをビルドしたりデータを変換したり、はたまたデータを作成するGUIツールを作ったりするためのツール用言語、そして、ランタイムにデータに含まれているスクリプトが解釈され、ゲーム内の制御を行うためのスクリプト言語です。
実機バイナリのためのプログラミング言語としては、リアルタイム性能のためにC++かC言語しか選択肢がないのが現状だろうと思います。一方、ツール用言語は PC 上で動くものですので、なんでもOKです。ここをわざわざ俺言語で開発する人は少なく、.NET や Java, Python, Ruby などなど既存の言語を有効活用していると思われます。
独自言語が多いと話題となりうるのは、最後のスクリプト言語となります。
独自のスクリプト言語が生まれるわけ
根本の理由はただ一つ。ゲーム開発に利用できる既存の実装が世の中にない（なかった）から、です。
さらに細かく理由を見ていくと、「歴史的な問題」「メモリサイズの問題」「スクリプト利用者の問題」「外部のコードを使用するという問題」の4つがあります。
歴史的な問題
PC-98 用のゲームが全盛だった時代は、まだインターネットもなく、スクリプト言語の実装がフリーで流通している、なんて世界とはかけ離れたものでした。そういった時代から開発をしているデベロッパは、当然、自分たちでスクリプトの実装を行うしかなく、自分たちに必要な機能だけを持った独自のスクリプト言語が生まれました。
今となっても、その頃の資産を受け継いで開発しているところはありそうです。これは、従来うまく行っていた手法からの変化を嫌う、という開発現場にありがちな状況になっているという面もあるでしょう。
ただ、独自のスクリプト言語を開発できたデベロッパはまだ進んでいたのかもしれません。PS時代くらいに、シナリオスクリプトが全てC言語のマクロだったという事例を見かけた気がします。しかし、これで開発可能であるなら何ら問題ないわけです。今でも、イベント部分が少ないゲームでは、C言語＋マクロを使ったDSL(?)という形で開発を続けている所もあるのではないでしょうか。なお、こういった現場にスクリプト言語を導入するとどんないいことがあるのか、については（たぶん） Lua 本 を参照、ということで。
メモリサイズの問題
さて、近年になってスクリプト言語の実装がオープンソースで出回るようになりました。だったらすぐにゲーム開発に採用できるか、というとそんなことはありません。
最大の問題は、使用メモリサイズです。家庭用ゲーム機はPCとくらべて格段にメモリが貴重なため、たかがスクリプトエンジンのために何百キロバイトや下手すると何メガバイトもメモリを割くわけにはいきません。既存の Python などをそのまま組み込むというのは、PC 用ゲームならともかく、家庭用ゲーム機用のゲームではあり得ない選択肢です。
最近はメモリが潤沢になってきましたので、ようやくそういった事例が出ようかどうかというところまで来ました。
一方、組み込みを念頭に、メモリサイズを最小限に抑えたコンパクトなスクリプトエンジンも登場して来ました。Lua や Squirrel が代表的なものです。しかし、まだ課題はあります。
スクリプト利用者の問題
ゲーム用スクリプト言語の一番大きな特徴は、その言語の利用者がプログラマとは限らない、という点です。
ゲーム開発では膨大な量のデータを作成する必要があります。スクリプト言語で記述するイベントも作成するデータの一部です。それを全てプログラマが行わなければならなくなると、大きなボトルネックとなります。
分業のために、ゲーム用のスクリプト言語は、プログラマ以外の人が編集できるようになっていないといけません。しかし、スクリプト言語の設計にもよりますが、どうしてもプログラム色は残ってしまっています。そのために、プログラマほどではないが、それでもプログラマ的な素養がある人を、スクリプタという職種にして、その人にスクリプトを書いてもらう、という分業が一般的です。
とはいえ、C言語やJavaそのものの文法は多くのスクリプタにとって敷居が高いのは間違いありません*1。理想的には、細かい記述は専門性の高いプログラマが行い、大量に量産する必要のあるイベントの記述は簡潔に書けるようなスクリプト言語が求められます。可能ならば、スクリプタを介さず、シナリオライターが直接イベント部を編集できることが理想です。この件に関しては、以前になぜシナリオスクリプト言語には2層構造が必要となるかという記事でも触れたことがあります。
ただ、まぁ、分業のために簡単に作るというのは理想的な話で、歴史的な理由で受け継がれたエンジンは、プログラマですら裸足で逃げ出すような入力しか受け入れないこともあります。その場合、実はスクリプタさんが高度に専門的な職種になっている場合もあるとか……。
それはそれとして、ゲーム開発において、既存のスクリプト言語が全く効率的ではないと考えられているのは、プログラマではない利用者にとって、括弧やセミコロンなどの半角記号の嵐が非常に取っつきにくいこと、そして、関数などの抽象概念が難しいこと、といったところが理由となります。BASIC は偉大だったわけです*2。
外部のコードを使用するという問題
Lua や Squirrel の登場で、全てが解決するかといえば、そんなことはありません。製品開発の現場で、外部からコードをもらってくるというのは、リスクを伴う行為だからです。
まず、ライセンスの問題があります。組み込み用言語のライセンスの多くは当然のことながら製品に組み込みが可能なライセンスになっていますが、表示義務があることが多いです。それを受け入れられるか、というのが一点。
そして、オープンソースな as is のライセンスは、それ自身が著作権や特許の侵害をしていたとしても何の保証もしてくれません。仮に Lua に何かの知財の侵害があったとして、それを組み込んだ製品が一斉に訴えられるという可能性があります。
リスクとメリットの天秤をかければ、メリットのほうが大きいでしょう。少なくとも開発現場にとっては。しかし、会社の判断がどちらに傾くか、というのは会社次第です。
欧米では、PCゲームの開発からの流れということもあり、全体的にオープンです。そのため、Lua などの採用は積極的に行われているようです。Wikipedia に Lua の採用タイトルリストがあります。
しかし、日本では、内部で開発できるならばわざわざリスクは取らない、という理由で独自に処理系を実装することが多いのではないかと思います。言語を独自実装するのであれば、そのプロジェクトで必要な仕様だけを備えた言語にするのが自然ですので、独自言語となることが多いのでしょう。
あー。そうそう、他人のソースなんて俺のプログラムに使えるか！という職人堅気な人が多かった、という事情もあるかもしれません。最近はそんなこと言っていると開発コストが鰻登りですので、だいぶん柔軟になってきた気がしますけれど。
まとめ
以上のような様々な理由があって、ゲーム開発の現場では独自言語を開発会社毎やタイトル毎に産み出してきたのでした。
ただ、国内でも開発を効率化しようという流れは強いですので、良いものが安全に利用できそうであれば、一気に共通のスクリプト言語を使う、という流れになるかもしれません。Lua は、コンパクトさや事例の多さから、その筆頭候補ではないかと思います。
フリーで公開しつつ、知財リスクやサポートなどが気になる会社のために有料でライセンスを販売するような組み込みスクリプト言語実装がでてくると、日本でも普及しやすいかもしれませんね。そういった点では、CriScript の今後の展開が期待できるのでしょうか。可能性としては、CryEngine に Lua の処理系が含まれているような形で、ゲームエンジンパッケージにスクリプト言語処理系が含まれていて普及するというシナリオもあったのですが、最近の日本の開発の流れを見るとそれはなさそうですね。
補足
Lua は、コンパクトで、ライセンス的にも大丈夫っぽい、という理由で組み込みスクリプト言語として及第点なだけで、プログラマ以外が書ける言語では全くありません。シナリオスクリプトを書くために Lua を使うには、何かコンバータを作成して別の階層で書いてもらわないとだめでしょう。
この、ゲームデザイナにスクリプトを書かせる、という行為がそもそも無理っぽいというのは皆が感じているところです。この問題へのアプローチとしては、スクリプト言語を頑張って平易にするという方向性もあるのですが、欧米の大規模開発の現場では、開発ツールでサポートしようという流れもまた大きくなっています。
自分が知っている範囲では、UnrealEngine3 の KISMET や CryEngine2 のフローグラフエディタ などがあります。が、これは効果的だった！という事例紹介をいまいち聞いた覚えもないんですよね……。Visual Programming は難しい。
ただ、ゲームシナリオ記述という一点に絞ってしまえば、統合開発環境でのサポートは現実的ではないかなぁ、と思っているんですがどうでしょう。統合開発環境っていっても、フローグラフがバーンと出てくるようなものではなくて、基本はテキストエディタで、ただモードを切り替えると演出用のコードがパネル状に小さくまとまって、スクリプタさんが余計なコードに煩わされずに編集できる、みたいな。
