はじめる！ Squirrel

刊行記念：ykandaさんインタビュー 第１回

「基本情報技術者試験に受からないと、本格的な勉強ってのはさせてもらえなかった。」

ykanda 20歳くらいのころに就職して、5年くらい、都内のゲームデベロッパーにいて、ずっとゲームを作っていました。

初めてパソコンというものを買ってもらったのが、中学校の時だったかな。 その頃にはソニーのバイオが出ていた世代なんですよ。 バイオにはK6-2が載っていて、メモリも64MBくらいありました。 それを中学校くらいの頃に使っていて、その時はHTMLを書いたりとか、普通にインターネットを見たりとかをしていました。 そのころ月刊アスキーという雑誌があって、餅月あんこさんという方がマンガを書いていたんですよ。 Webページ作るだなんて、メモ帳があればできるぜ！みたいなことを書いてらっしゃったんで、それを見てちょっとやってみようかなという感じで。 HTMLって要はマークアップ言語で、プログラミングとはちょっと違うと思うんですけど、コンピュータで最初に何かをやったというのはそれが最初です。

プログラミングということ自体はだいぶやってなかったんです。 画像編集ソフトを使って、いたずら描き程度の絵を描いたり、ネタ画像とかを作って遊んだりとかも多かったです。 あとは友達にホームページを作りたいという人がいて、それの画像を準備したりとか、そういうことはよくやってました。

あとは一時期Macとかも使っていたりして。 その友達は音楽とかやってた人だったんだで、一緒に音楽ソフトのCubase（Cubasis）をいじったり。

で、高校を卒業するくらいに、何しようかなかなって思ったとき、「ゲームを作りたいな」っていう感じで、専門学校に行って、本格的にプログラミングに触れたのはそこが最初です。 小さいころからゲームは好きだったので。

ゲームに関して一番古い記憶にあるやつだと、幼稚園ぐらいのころかな。 毎日朝御飯とか食べて支度をして、そうすると30分くらい待機時間があるんですよ。 その間に毎日ファミコンの電源を入れてマリオやってたりとか。 物心ついたころにはもう、おじが置いて行ったのかな、ファミコンがソフトと一緒に家にあっていろいろやってたんですよ。 ドラクエIともかやってた記憶がありますね。 その当時ってこう、バックアップが出来なかったんですね。 いわゆる「冒険の書」みたいなのがなくて。 あれ（ドラクエI）はパスワードなわけじゃないですか。 ところ、幼稚園とか、４歳とか５歳とかそのくらいだと、パスワードの概念を知らなかったんですよ。 毎日、王様から少しばかりのアイテムとお金をもらって、鍵を開けて、スライムを倒して、 レベルが２とか３くらいになったくらいになったころに時間が無くなって、というのを無駄に毎日繰り返してたのを覚えてます(笑)

話を戻して、高校卒業後後、専門学校みたいなところに行ったわけです。 専門学校なのか短大なのかよく分からないんですけど、短大卒の資格がもらえるみたいですね。 そういうところに2年間ぐらい行ってました。

そこでは最初はC言語をやりました。 あと、今は名前が変わってると思うんですけど、基本情報技術者試験というのがあって、 それの合格を目指して、ゲームじゃないけどいろいろコンピュータにまつわる勉強をするんですね。 その学校はそれを取らないと、ゲーム作らせてもらえませんよ、というのがあって。 ゲームを作ろうというクラスがあって、ぼくはそこに所属していたんですけど、基本情報技術者試験に受からないと、本格的な勉強ってのはさせてもらえなかった。

それに受かると、次はDirextXとかを使ってちょっと本格的に。 授業自体はあるんですけども、そうじゃない場合、その次の試験の勉強っていうんですか、 次の春には基本情報に合格しよう、っていうようなやつに無理やり組み込まされて、ゲーム作ってる暇が無くなるという感じだったんですよ。 なので、入学したその年の秋に基本情報をとって、そこからゲームを作ってました。

専門学校の人がゲーム会社に入るとき、特にプログラマーとかデザイナー系はそうなんですけど、物を作って持っていくのが多いんですね。 （注：企画系というのもあって、こちらも企画書などは作りますが） 作品という形で、ソースコードと実行ファイル、データなどをひとまとめにして提出するわけです。

東京ゲームショウというのがあって、ゲーム会社が集まって展示会みたいなのをやっているんですね。 その片隅に、グッズ屋さんとかゲーム学校とかが集まったエリアがありまして。 うちの学校も毎年出展していて、そのための作品を作ろうというのも兼ねていました。

第8回のスチューデントゲーム大賞(http://students.cesa.or.jp/2006/)。この回を最後に同賞は中止になり、日本ゲーム大賞のアマチュア部門に統合された。

あとは、スチューデントゲーム大賞だったかな、そういう賞に応募するんですね。 ゲーム系の学校に行ってる人の作った作品を公募して、優れた作品を表彰しようというものです。 この章の表彰式は、東京ゲームショウの中の一つの催し物でもありました。 そうゆう風にとにかく作品として実績を作ると、あとで就職活動をするときもやりやすくなりますよ、というわけです。

まあ、そんな感じに作品を作りながらC/C++、DirectXなどを勉強していました。 DirectXは触り始めたの頃はもう、DirectX 9とかの世代でしたね。 6〜8とかでこう苦労されてきた方の視線を感じて申し訳ない感じです。

それでも面倒だった部分もありますけどね。 COMの解放が云々とかいって、初期化と破棄の順番をそれぞれ逆にしなくちゃいけないとか、そういった細かいところとか。 僕ら世代のゲーム開発者って、何気にモジュールの初期化と破棄の順番をそれぞれ逆順にするっていう風なクセで書く人も結構多いと思いますよ。 全然DirectXと関係ないところでもやってる人が多い。 実際にはモジュール同士の依存関係に応じて適切に処理されればそれで良いはずなんですけどね。

とまあそんな感じで、簡単に描画できる環境が整っていたので、3Dとかも普通に触ってました。 行列の演算とかも、特に考えることもなくSDKの中に入ってたりして使い方を覚えればOK。

あとはJavaも授業でちょっとやってましたね。 僕達の世代ではi-modeがもうかなり普及していて、Javaで書くiアプリとか、そっちの方に進む人のためにJavaの授業もあったわけです。 プログラミングについてはそんな感じですね。

「DS、PSP、Wii、PS3、360辺りはひと通り触りました」

ykanda その後普通に就職して普通にゲーム会社に入りました。 そこでももうゲーム作りで使っているのはC/C++、ハードで言えばPS2がわりと終わりの頃、新しいハードではNintendo DSが出ていたという辺りから。 それ以前だとアセンブラとかもあったんでしょうけど、僕が入った頃はもうアセンブラってもうわりとナンセンスな感じになっていました。 ナンセンスってほどではないんですけど、結構コアなチューニングをする人じゃないとあまり使わなかったのかなという印象があります。

最初にプログラミングという形で触ったのは、PS2だったかな。 Linuxが積まれてて、出た当初は1台200万円近い値段だったかな、でっかい箱みたいなの（注：DTL-T10000のこと）を使って、ターミナル経由して接続してみたり、っていうことをやってました。

そのあと、本格的にゲームプログラマとして仕事するようになってからはDSとかが中心でした。 トータルでDS、PSP、Wii、PS3、360辺りはひと通り触りました。 でも、どれもこれもとりあえずC/C++が使えれば問題無かったですね。 うちはC++でしたけど、会社によってはもしかしたら、言語の透明性があるし、あっちの方が最適化賢くやってくれるよとか、 そういった理由でCにしますっていう会社さんもあったかもしれません。

あとはSDKのモジュール自体がCで書かれているような、単純にextern CしてあってC++のモジュールとして使えますよ、 みたいな風に組んであるっていうだけで、中身はほとんどCで書かれてますみたいなものも結構ありましたし。 とにかく、C/C++だけ押さえていればとりあえずは作れるといった雰囲気です。

「スクリプタさんがある程度ゲームの挙動を作ったり調整できる環境を準備しなくちゃいけないんですね」

ykanda 開発が大規模化してくると、DSとかでもそれなりの量のデータとかを扱ったりするようになってきます。 サイズというか、単純に数ですね。 そこで大量のファイルとかを扱ったりするときに、ワークフローを作るためにPerl、Python、Rubyといったいわゆる軽量言語に目を向けていました。

もう一つ、大規模化ということに関連していえば、ゲームの中身を全部C/C++で書こうとすると面倒くさい。 もちろん全部C/C++で書けるんですけど、ある程度大きくなってくると、ビルドが大変になってくる。 けっこうな時間をかけて毎回ビルドしないといけないのは非常に面倒が多くなってくる。

ゲームの作り方って、だいたいプログラマと、スクリプタと、デザイナとに分かれていることが多いんです。 ゲームの挙動を全部プログラマが書こうとすると、ある程度小さいソフトだったら問題ないんですけど、ゲームとして動き一番明確にイメージしているのは、 スクリプターさんとか、プランナーさんというところなんですね。 その人達の言ってることを聞いて、うちらがコーディングして、ビルドして、っていうと時間がかかる。

なので、スクリプタさんがある程度ゲームの挙動を作ったり調整できる環境を準備しなくちゃいけないんですね。 そこに登場するのがSquirrelとか、ああいう組込み系の言語なわけです。 といっても、それ以前にスクリプトっていう概念はもちろんあって、各社独自の言語を実装したりというのはあったと思います。

あとは、スクリプトとはいかなくても、データ構造を作るツールとかですね。 データがパラメタに当てはまるのでそれで動きを調整できますとか、わりと原始的なツールですね。 Excelを使ってシートを作って、それがパラメタにできるようになっているとか。 そういうのをVBAとか使って吐き出したりするといったツールは意外と良く使っていました。

話を戻して、DSくらいだったら、単にビルドをする時間はそれほどでもないんですが、ただ動きを確認するためにビルドをしなくちゃいけないとなってくると、 その時間がやっぱり重みになってきます。 これがPS3やXboxなどの環境になってくると、さらに状況は悪くなってきます。 そうなると、コンパイルがいらないスクリプト言語のようなものが活躍するという状況なわけです。

もっとも、以前から、一応社内でもスクリプト言語のようなものはありました。 スクリプト言語というよりは、「コマンド」という形で定義されていて、そのコマンドがゲームアプリケーションで提供しているAPIと対応していて、 任意のパラメータを与えつつ、コマンドを順番に並べて書けるっていう環境だったんです。 ただそれだと、ツール自体のメンテナンスとかも大変になってきますし、あまり高機能でもなかった。

なので、PS3やXboxに取り組み始めたときに、Squirrelとかもいろいろ調べ始めて、新しいプロジェクトの中で使い始めてみようかということがあって触っていました。 もう一年くらい前になるんじゃないでしょうかね。

Squirrel以外の話でも結構あると思います。 たとえばメタルギアソリッドなどは、ある程度日本語で打てるスクリプト言語を実装してやってましたというのが、CEDECだったかな？で例として紹介されていたと記憶しています。 スクリプターフレンドリーみたいな感じで。 表に出てないだけであって、独自言語を持ってる会社っていうのは結構あると思いますよ。

でも、ゲーム会社さんって表に物を出さなかったりするので、話題に上がることは少ないですね。 デベロッパであればパブリッシャさんとの契約もあるでしょう。 自由にできる成果物としてどこまで含めるのか、みたいなものにもよると思います。

Squirrelの前にはLuaとかもあって、海外とかだとわりと積極的に使われていたのではないでしょうか。 汎用的なものと組み込み言語というのはメジャーになってきた、というような雰囲気ですね。

SquirrelとLuaくらいしか挙げていませんが、JavaScript（ECMAScript）に準拠したみたいな言語があったり、 他にもいろいろ、Ioという言語を使おうって話も聞きましたし、AngleScript（AngelCode）とか、あるにはあったんですけど。 これは単純にゲームって話だけじゃなくて、アプリケーションに組み込むタイプのスクリプト言語っていろいろありました。 プラグインみたいなやつが書きやすいとか、簡単に拡張できるとか。

汎用言語じゃないし、ゲーム開発そのものではないけど、それに近しいもので印象的だったものは、Mayaっていう3Dのソフトウェア。 あそこにはMELっていう言語がくっついてくるんですよ。 これはちょっと毛色が違うんですけど、Maya自体がMELで出来ているというか、Mayaのコアの部分みたいなのが全部MELを解釈して動くっていうような仕組みになっていたと思います。 Mayaを立ち上げると最初は普通の編集のためのウィンドウが開くのですけど、ちょっとコンソールみたいなのを開くと、 そうするとMEL的にどうなっているの？みたいなのがパーっと流れてるのが観察できるんです。 さらにMELをスクリプトとして書いて、独自のインターフェースを構築できたり、編集中のデータに対して何か処理をかけるとか、そんなことができたりするんです。

Mayaに限った話ではないですけど、アプリケーション本体と、スクリプト言語による拡張っていう組み合わせという見方はその頃から広くあったというような気がします。 Emacs LispとかVim Scriptみたいなものというとプログラマには分かりやすいでしょうか。 Squirrelは、そんな中でゲームにフォーカスして紹介されたっていう感じですね。

「Squirrelの場合、クラスベースの考え方が通用する分、僕はやさしいなと感じます」

Squirrelのホームページ(http://www.squirrel-lang.org/)

ykanda いいところは、C/C++ライクなところですね。 ゲーム会社の人って、C/C++に慣れ親しんでいるっていう人が圧倒的に多いんで、 下手したらそれしか使えないよ、といった人もいるかもしれません。 そういった人たちがさくっと入れるのがいいかなと。

JavaScriptとかも、字面とかコードの見た目的にわりと似てるんですけど、文化がかなり違うじゃないですか。 なんでこう関数をいきなり書いて、それがインスタンスの雛形であるオブジェクトみたいな扱いになるの？っていう。 ああいった、考え方の違いっていうんですか、プロトタイプベースっていうものと、C/C++のクラスベースの考え方は違うかなという感じがしますし。 あと、動的言語と静的言語っていう違いもある。 Squirrelも動的言語ですけど。

Squirrelの場合、クラスベースの考え方が通用する分、僕はやさしいなと感じます。 Luaとかはわりとかけ離れているというか、かけ離れているとまでは言わないですが、単純に見た目としての問題って言うんですかね、 ある程度プログラミングのたしなみのある人が見えればやってることは理解できるんですけども、 ほんとにSquirrelの方が分かりやすいなっていう感じがします。 PythonやRubyも文法とか文化が違う感じが若干しますね。 まあ慣れの問題というか、規模とかによって感じ方は違うのかもしれませんけど。

まあ僕個人で言えば、どれを使うかってのは状況によって判断するというのはありますよ。 Squirrelであれば、例えば若干スピードが出ないということはいろんな方面から言われていて、 どうしてもそれがリクエストとしてクリティカルな部分にあるのであれば、もちろんLuaとかを使ってもいいんじゃないかとは思います。

少し話の流れが変わりますが、Pythonを以前いた会社で社内の標準にしたいと考えてたときがありました。 応用範囲が広いというか、ゲーム屋さんの使い方にいい具合にマッチするというか。 まず一つが、さっき言ったMaya、バージョンが8だったかそのあたりでPythonでも拡張できるようになったんですね。 なのでPythonの文法を覚えてると、Mayaもいけちゃうんじゃないっていうのがあった。 あとこれはもちろん他の言語にもあるんですけど、扱いやすいGUIツールキットの存在があって、簡単なGUIアプリやツールも作ることができるというのも一つ。 あとはさっき言ったような、ワークフローのためのスクリプトであるとか、そういったものも割と簡単に組めちゃいますよと。 普通に仕事の道具として広く応用できるツールって感じですね。

その会社ではみんな結構好き勝手なものを使っていて、（Windowsの）バッチ使うやつもいれば、 WSH（Windows Scripting Host）でVBScriptやJavaScriptで書く奴がいれば、PerlもRubyもPythonも、それぞれ使う人がいて。 さすがにこれだけとっちらかっているとまずいから、全部共通化しようということになって、今言ったことを理由にPythonでいいんじゃない、という感じでしたね。

あとはStackless Pythonだったかな、ゲームの組み込み言語としての応用例もあったりして。 なんていう名前だったか忘れましたが、ネットゲームでPythonを埋めこんであるというのがあるらしくて、 そっち方面にも一応目を向けつつ、軽量言語使うんだったらPythonにしようぜ、みたいなことを僕は社内で言っていました。

「一言で言えば、テーブルは単にデータ構造でいてほしかったという感じかな」

ykanda 話をそらしてしまいましたが、Squirrelの悪いところ……。 悪いところでは一つだけ不満みたいなものがあって。 グローバルな変数を定義するときの、「<-」の使い方。 あれは気になります。

あるテーブルのオブジェクトがあって、そこにスロット名を書いて、そこに「<-」を使うとテーブルに要素できます。

foo = {};   // テーブルの定義
foo.i <- 1; // テーブルへスロットを追加

一方、何もないところで、スロット名だけを書いて同じように「<-」を使うと、ルートテーブルというところにシンボルが追加される、 という動きになってるんですけど、あれはちょっと変えた方がいいんじゃないかと。

i <- 1; // グローバル変数の定義（ルートテーブルへスロットを追加）

ああいう風な書き方をするとルートテーブルに追加されて、Squirrel的にはグローバルな要素として管理される、 という仕組みだから当然なのですが、字面がほぼ同じじゃないですか。 ルートテーブルというものを知らないと、その挙動を字面からは理解しにくいって言うところがあると思うので。

単純に、裏方を知らないでSquirrelを使いたいという人にとっては、ルートテーブルなんてもちろん分かんないわけじゃないですか。 なんで、本当に「同じ書き方をするけど少し違う」という覚え方をするしかなくなっちゃうんで、 それがちょっと、ほんの少し嫌いなところかなという気がします。

例えば「root」みたいなキーワードがあって、それがルートテーブルという意味がある、でもいいかもしれません。 あるいは「local」というキーワードがあるなら「global」っていうのもあってもよかったんじゃないかという感じもしますね。 それか逆に「local」を省くだけでもいいかもしれないし。 ただそうすると、いきなり代入っぽくなってtypoしちゃう可能性があるんで、何かしらの形で一回宣言して、っていうんだったら、 「local foo = 0」みたいなのがグローバルな変数の宣言の方法として、あった方が良かったんじゃないかと思います。 この部分はちょっと、ほんの少しだけですけど、言語としてもやもやする部分です。

あと他はそんなに不満はなかったりするかなあという感じがします。 データ構造とかも、配列、ハッシュ（テーブル）が使えますし。 割とコンパクトにまとまったわりには使える機能が揃っていて、ブログにもちょっと書きましたけど、キュートな言語だなあと思います。

あ、これは別に言語自体の話ではないんですけど、メモリアロケータを差し替えようとするときに、ソースコードをいじらないといけないのがあって。 勝手にmallocを使うようになってるんで、その環境のランタイムが提供するmallocが勝手に使われてしまうというのがある。 一応それをどうにかするというテクニックは広く知られているところなんですけども、それくらいはさせて欲しいかも。

あと他はそんなにないかなあ……。 あ、デリゲートとかクラスの辺りかな。 テーブルのデリゲートとか、結局何に使うのよみたいな(笑)

あと、これは3.0で変わると言われてるんですけど、 2.4とかだと、クラスはインスタンス化する前だったら「<-」を使ってメンバを追加できるのですが、 3.0ではインスタンスを生成した後でもクラスのオブジェクトに対してメンバを追加できるんですよ。

クラスとテーブル周りとか、その辺は若干整理されてない印象があります。 どっちを使っても理屈としては同じようなことができそうな気がするにも関わらず。 おそらくクラスの実装のバックエンドにテーブルの概念があるっていうのが根本にある気がするんですけど、若干不思議に思うところが無くもない。

一言で言えばテーブルは単にデータ構造でいてほしかったという感じかな。 でも、若干気になりますよね。 それでもまあテーブルが関数が持てること自体は問題無い気がしますけど、テーブルのデリゲートはちょっとよく分からない。 メタメソッドとかの話で、テーブルっていう要素に対して、演算を定義できるっていうのはありかなあと思うんですけど、 最初元になるテーブルを書いておいて、それからデリゲートっていう風にしないと機能しないっていうのはちょっと。 テーブルの中に書いてあるんだったら普通にやってほしいなという気がしますね。 テーブルってデータ構造というか変数的な扱いですが、クラスで考えるとオブジェクトでありインスタンスであるというような風に見えてしまうというのがあって。 そこが若干気持ち悪いなあと。 ほんと、ただのデータ構造でいてくれよという反面、やっぱりこういう考えになっちゃうんだなあというか。 メタメソッドのことを考えると分からなくもないというか、「そのためにあるんだ」みたいな納得はできるけど、でも煮え切らない感じもします、という。 でもあれを上手く使う人もきっといるんでしょうね。

（「ykandaさんインタビュー第２回」に続く）